I was bored, spent an half hour writing a non-recursive, relatively-high-allocations, somewhat slow Fibonacci function.

Here you go:

@frogstair Because they followed some tutorial where this was done

@frogstair

It is a dilemma.

Write a better documented uint or make int so everybody can use my code.

@frogstairI guess this is not intended ad production code due to OP’s comment.

But one reason to use uin instead of in is that it will never handle negative numbers and using int halves the max number you can use.

I have made quite a lot of use if uint in c# for similar reason, the value was never going to be a negative one so compatibility with int was redundant.

And for an example like this (judging from the description, high allocation and slow) its even more irrelevant.

@frogstair
> "can't use this function unless everything else is uint"
Can't you just cast them? I like to use uints because it eliminates the need for error handling on negative, which is often the only kind of error handling I'd have to do in mathematical code. Having functions that can never throw is a big advantage.

@frogstair What you said are all reasons to force the caller to do an explicit cast, which will make them think about the possibility of negative numbers.

@frogstair Because you shouldn't be able to pass a negative number to a Fibonacci function. It's either an exception or a compile-time type mismatch, and the latter is always preferable when sufficient information is available at compile time.

@frogstair Since the return value is also always positive, making it an uint makes it easier to pass to other functions expecting a positive number. The only mistake I see here is that uint can't be implicitly casted to int,even though it's literally a subset (not considering overflows).

My favorite Fibonacci solution is to realize you only need to store the last two numbers at any one time.

@Lor-inc I guess that's the heart of the problem. uint is not a subset of int once you consider overflows.

@korrat I still think that overflows would be less of a risk than allowing negative numbers while coding for positives.

@frogstair Always make invalid state unrepresentable! Like people have already said, if a function can't meaningfully handle negative numbers then use uint. Else you introduce invalid state that you and all of your callers have to tediously deal with.
Same goes with null pointers which shouldn't exist (but you can't do much about that when it's in the language)

@here now that I'm available (read: awake), let me clear a few things up. Like some people said, the reason for the choice of uint was that it can't go negative.

Regardless, @AmyShackles I think I'm going to see if I can try your method next. I may make this kind of project a once a week thing.

@12bitfloat @AmyShackles @Lor-inc @Voxera @frogstair @korrat @mr-user @zemaitis

User @pseudonim requested to mention everyone in this comment section. He/She probably has something important to tell...
Look above!

And for anyone who's wondering, I've optimized the approach of this method: https://devrant.com/rants/3113115

@12bitfloat @AmyShackles @Voxera @frogstair @homo-lorens @korrat @mr-user @zemaitis

User @pseudonim requested to mention everyone in this comment section. He/She probably has something important to tell...
Look above!