[orionblastar]

This is basically a table lookup. You could do the same for any series of numbers like the prime numbers.

You could store them in a database table even and then pull out the result by a key with the number assigned to it that represents the Nth Fibonacci number. It might even be faster than an array loaded from a text file, and if you happen to have limited memory and cannot store the entire array in memory some how later on when you use a different data type for large numbers and go past 96 numbers, the database method may even be faster and use less memory. You might even have to store the big numbers as a blob or text or something if the database cannot handle numbers that big.

[protomyth]

If I don't have room to store 96 numbers in an array in the function, I am going to have problems elsewhere.

[orionblastar]

You have to think ahead. You have 96 numbers now, but after 96 you have to change the data type to a larger storage to be able to store larger numbers. So when you pre-calc say 10,000 numbers what happens to your array then? What if the program is run on an embedded system for some reason that has memory limits? Like say someone finds a reason to use Fibonacci numbers on an embedded system to monitor machines and control machines and other stuff?

You don't know a reason to use Fibonacci numbers, but that doesn't mean someone else might find a way to use them.

[protomyth]

Given the limits of the data type, I really am not going to think ahead until I change the data type[1]. If the new datatype can hold 10,000 numbers, then I will probably go back to an algorithm.

I am really not sure about these embedded systems that have more RAM than ROM / EPROM / Flash. 384 bytes used for constant time performance in and embedded situation sounds pretty good to me.

1) not only would that be premature optimization, it would also change a function from constant time to variable. I do wonder about how big the stack frame is.

[groby_b]

You haven't worked with embedded systems, have you? 96 numbers is 384 bytes. That's a lot of space for some applications.

[protomyth]

actually, in the distant past, I did. I don't remember a lot of embedded systems where Fibonacci numbers were important or where floating point was a real option (been awhile, probably same length of time since 384 bytes was the killer). I was always RAM constrained more than ROM /EPROM.