Originally Posted by Pointy Warning: Spoiler! (Click to show)
Whos philly? Quote:
Originally Posted by RagingCain
Philly is actually the one that found it.. It turns out I made a mathematical booboo but .NET CLR did too
It doesn't catch an overflow mistake I was having last version and this one. It really helped getting test results.
Nobody cares about floats. It's all int32, int64, and double penetrations.
I did have a eureka moment earlier to make up for it and figured out how to squeeze 4Billion numbers into a 2Billion space without compression.
oh just another member. right?
so it was just a coding mistake?
and we were your debuggers?
Yep, just a case where I overlooked the structure of floating points and a case where my hand wasn't overly held by .NET. Something that was partially working in 4.6 straight up broke in 4.6.2 due to floating points limitation.
A floating point can hold this number:
A huge number - but that's mostly zeros.
The maximum whole number a float can actually have is 16,777,216 before precision is lost.
Just an honest mistake combined with something we thought was working but now wasn't working, on only one data type, that Intel has a known hardware bug - but like I said, I didn't want to jump to conclusions.