Solving Fizz Buzz with Cosines

https://joelgrus.com/2016/05/23/fizz-buzz-in-tensorflow/

Well, there must be an obvious solution where the fizzbuzz sequence is seen as a spectrum of two frequencies (1/3 and 1/5), and a Fourier transform gives us a periodic signal with peaks of one amplitude at fizz spots, another amplitude at buzz spots, and their sum at fizzbuzz spots. I mean. that would be approximately the same solution as the article offers, just through a more straightforward mechanism.

What a neat trick. I'm thinking you can abuse polynomials similarly. If the goal is to print the first, say, 100 elements, a 99-degree polynomial would do just fine :^)

EDIT: the llm gods do recreational mathematics as well. claude actually thinks it was able to come up with and verify a solution...

https://claude.ai/share/5664fb69-78cf-4723-94c9-7a381f947633

Inspired by this post & TF comment I tried symbollic regression [0] Basically it uses genetic algorithm to find a formula that matches known input and output vectors with minimal loss I tried to force it to use pi constant but was unable I don't have much expreience with this library but I'm sure with more tweaks you'll get the right result

  from pysr import PySRRegressor

  def f(n):
      if n % 15 == 0:
          return 3
      elif n%5 == 0:
          return 2
      elif n%3 == 0:
          return 1
      return 0

  n = 500
  X = np.array(range(1,n)).reshape(-1,1)
  Y = np.array([f(n) for n in range(1,n)]).reshape(-1,1)
  model = PySRRegressor(
          maxsize=25,
          niterations=200,  # < Increase me for better results
          binary_operators=["+", "*"],
          unary_operators=["cos", "sin", "exp"],
          elementwise_loss="loss(prediction, target) = (prediction - target)^2",

  model.fit(X,Y)

((cos((x0 + x0) * 1.0471969) * 0.66784626) + ((cos(sin(x0 * 0.628323) * -4.0887628) + 0.06374673) * 1.1508249)) + 1.1086457

with compleixty 22 loss: 0.000015800686 The first term is close to 2/3 * cos(2pi*n/3) which is featured in the actual formula in the article. the constant doesn't compare to 11/15 though

[0] https://github.com/MilesCranmer/PySR

HN is a great place to learn non-trivial things about trivial things, and that’s why I like it. My comment won’t add much to the discussion, but I just wanted to say that I learned something new today about a trivial topic I thought I already understood. Thank you, HN, for the great discussion thread.

I once had a coworker who used the FFT to determine whether coordinates formed a regular 2D grid. It didn't really work because of the interior points.

There are a surprising number of ways to generate the fizzbuzz sequence. I always liked this one:

  fizzbuzz n = case (n^4 `mod` 15) of
    1  -> show n
    6  -> "fizz"
    10 -> "buzz"
    0  -> "fizzbuzz"

  fb :: IO ()
  fb = print $ map fizzbuzz [1..30]

I think that implementation will break down around 2^50 or so.

So, there’s a similar way to do it with a function that produces one of the characters in “FizBu\nx” and a while true loop that

- increases i on every \n,

- prints i when that produces x, otherwise prints the character

(Disregarding rounding errors)

That would be fairly obfuscated, I think.

Very cool! There's definitely some similarity to Ramanujan Sums, though the approach here sort of packages the fizz-buzz divisibility properties into one function. https://en.wikipedia.org/wiki/Ramanujan%27s_sum

Made me envision this terrible idea.

arr = [];

y = 0;

setInterval(()=>{arr[y]=x},10)

setInterval(()=>{x=y++},1000)

setInterval(()=>{x="fizz"},3000)

setInterval(()=>{x="buzz"},5000)

setInterval(()=>{x="fizzbuzz"},15000)

This seems like a great benchmark task for LLMs.

Where the madness leads: https://cspages.ucalgary.ca/~robin/class/449/Evolution.htm

This is very nice.

I wonder where this is coming from. I saw on USENET in comp.os.linux.misc a conversation about fizzbuzz too. That was on Nov 12.

Anyway an interesting read.

While it's cute use of mathematics, it's extremely inefficient in the real world because it introduces floating point multiplications and cos() which are very expensive. The only thing it lacks is branching which reduces the chances of a pipeline stall due to branch prediction miss.

(The divisions will get optimized away.)

There are several mentions of "closed-form expression" without precisely defining what that means, only "finite combinations of basic operations".

TFA implies that branches (if statements and piecewise statements) are not allowed, but I don't see why not. Seems like a basic operation to me.

Nevermind that `s[i]` is essentially a piecewise statement.

The article conceit is fantastic. That said, is the going-in algo wrong?

I see a case for 3 * 5 in here:

  for n in range(1, 101):
      if n % 15 == 0:
          print('FizzBuzz')
      elif n % 3 == 0:
          print('Fizz')
      elif n % 5 == 0:
          print('Buzz')
      else:
          print(n)

If we add 'Bazz' for mod 7, are we going to hardcode:

  for n in range(1, 105):
      if n % 105 == 0:          # 3 * 5 * 7
          print('FizzBuzzBazz')
      elif n % 15 == 0:         # 3 * 5
          print('FizzBuzz')
      elif n % 21 == 0:         # 3 * 7
          print('FizzBazz')
      elif n % 35 == 0:         # 5 * 7
          print('BuzzBazz')
      elif n % 3 == 0:
          print('Fizz')
      elif n % 5 == 0:
          print('Buzz')
      elif n % 7 == 0:
          print('Bazz')
      else:
          print(n)

  for n in range(1, 105):
      out = ''
  
      if n % 3 == 0:
          out += 'Fizz'
      if n % 5 == 0:
          out += 'Buzz'
      if n % 7 == 0:
          out += 'Bazz'
  
      print(out or n)

Sort of fun to muse whether almost all FizzBuzz implementations are a bit wrong.