Hacker News new | ask | show | jobs
by kenjackson 5521 days ago
(The asymptotic complexity is surely the same, in any case.)

The closed form complexity is not the same (not sure how it could be). Here's the code written in standard most language psuedocode:

   fib(n) {
      double c = 1.6180339887;
      return round((power(c, n) - power(1-c, n))/sqrt(5));
   }
Note: I assume your point wasn't that computing the golden ratio exactly is... well ummm... time consuming.
4 comments

> The closed form complexity is not the same (not sure how it could be)

I disagree. Both variants are more similar than it may seem at a first glance. In essence, the question here is which of the following calculations is more efficient for big n:

a) the power function for arbitrary precision floating point

b) the power function for 2x2 matrices of arbitrary precision integers

Assuming that we can ignore the initial effort to calculate the golden ratio (can we?), Binet's formula is based on a), while the article's best algorith is an application of b).

I'm absolutely undecided which one works better, mostly because both kinds of power functions are working essentially the same way, with a complexity of O(log(n)).

Also, the precisions required for both cases seem to be quite similar.

Indeed. I thought the OP was referring to the recursive algorithm, not the final algorithm.
Note that you can optimize this by removing the "(1-c)^n" part, because its absolute value is smaller than 0.5 for big n, so it can't influence the (rounded) result.

This trick is especially funny when performed using a hand calculator. For instance, just calculate the powers of the golden ratio and observe numbers like "xxxxx,0000yyy" "xxxxx,9999yyy", which become closer and closer to integers.

Actually I think that roughly was my point. :-)

You can’t get an exact answer in general by using fixed-size floating-point numbers, as your pseudocode does. The number of bits of precision you need to get an exact answer is going to depend on the input value, presumably linearly.

When you round you'll always get the exact integer answer, even using the precision of the golden ratio I gave in the code.
That’s really not true. You don’t have to take my word for it: try it with fib(1000), say.

The answer should be:

  43466557686937456435688527675040625802564660517371780402481729089536555417949051890403879840079255169295922593080322634775209689623239873322471161642996440906533187938298969649928516003704476137795166849228875
Oh, the old n=1000 trick. Well played.
can't wait to break this out next time it comes up in an interview!