[sp332]

Well, that's because it's an awful way to calculate a fibonacci number! At least you could memoize the function, remembering what the (n-1) number was instead of recalculating every time. Or, since you only need the last 2 numbers to keep going, forget everything but those 2:

  unsigned long long fib(int a) {
      unsigned long long x, y, temp;
      while (a > 0) {
          temp = x;
          x = y;
          y = y + temp;
          --a;
      }
      return y;
  }

This is much faster and won't blow up your stack.

[NAFV_P]

> Well, that's because it's an awful way to calculate a fibonacci number!

To be more precise, it is an inefficient method of calculating a Fibonacci number. Using your function, if you were to measure the execution time of fib(n), then divide it by the execution time of fib(n-1), would you get a more precise value of the Golden ratio?

> This is much faster and won't blow up your stack quite so much.

Or we could use an iterative version ... wait up your code changed to an iterative implementation. Man that's weird.

EDIT:

Your code:

  unsigned long long fib(int a) {
    unsigned long long x, y, temp;
    while (a > 0) {
      temp = x;
      x = y;
      y = y + temp;
      --a;
    }
    return y;
  }

I just noticed: x, y and temp have not been initialised.

[sp332]

I have to admit, I did not understand your earlier comment until just now.

Sorry about the code change, the first version was from an old memory and the new version is what happened after I stared at it for a while :) Primitive values are automatically initialized to 0 in C. As for the ratio, it will probably just give a good approximation of 1 as a gets large! Also if you have a good square root function, you can use it to find a Fibonacci number in constant time, so your ratio will always be 1 (until the square root is too big to be computed in a single instruction).

[mattst88]

> Primitive values are automatically initialized to 0 in C.

No, they're not. Automatic variables without an initializer have an indeterminate value. See http://stackoverflow.com/questions/6212921/is-un-initialized...

[NAFV_P]

> I have to admit, I did not understand your earlier comment until just now.

From the number of downvotes, I think it was mis-parsed by several HN readers. This happens to me quite often, on many a website, but I have no inkling why.

> Sorry about the code change, the first version was from an old memory and the new version is what happened after I stared at it for a while

No worries, I thought the original slice of code that you posted was more interesting and novel, it wouldn't have occurred to me off the top of my head.

> Primitive values are automatically initialized to 0 in C.

I had to look that up, good old Stack Overflow has again furnished us with an explanation.

http://stackoverflow.com/questions/10089551/what-are-primiti...

[sp332]

Oh, C, C++, what's the difference. (D'oh!)

[NAFV_P]

One of the reasons I stick to old C, less confusion.

[TheLoneWolfling]

Why not just directly get an approximation of the golden ratio by taking fib(n) / fib(n-1)?

If you use an iterative / tail-recursive version you can actually do this directly, without even the overhead of having to calculate it twice.

(I.e. define fib to return a tuple / struct / etc consisting of (fib(n), fib(n-1)).)

[NAFV_P]

> Why not just directly get an approximation of the golden ratio by taking fib(n) / fib(n-1)?

That has been done millions of times over the past 800 odd years. My method has no practical uses, but plenty of educational ones.