Infinity and NaN are a bit different. You can do some arithmetic on infinity, e.g. infinity is greater than every number, and negative infinity is less. But NaN just corrupts everything with its NaN-ness.
Ya, NaN includes more than just Infinity. At least in the case of IEEE Floating point, NaN gets used as the catch all error state. I am too lazy to actually look up all of the possible places to get NaN from, but as far as I know, it includes both positive and negative infinity, positive and negative number overflow (too big), and positive and negative number underflow (too small). But yes infinity is at least order-able (you can sort it) whereas NaN is not equal to anything (even itself), not smaller than anything, and not bigger than anything
As for the result of dividing something by zero, it depends on the rules of math that you are using. Non-calculus math completely ignores division by zero. If your
James Anderson then it is a nullity. If you are the IEEE Floating point representation it is NaN. Others (like Qent) consider division by zero to result in +/- infinity. According to Microsoft Visual C, division by zero results in "-1.#IND00" when represented as a string.
Also, I forgot to do this before. I figured I should add this, because the way Battuta and The_E tell it, I just pulled the idea for this out of my ass (which I don't mind
), but I though I would explain my thought process of how I got to the fact that is was caused by speed match, which I hope may be useful to other coders or even mission testers.
At some point I was fiddling with the logging, because I don't have the patience to frame-step through the engine like The_E (props man
). So, I was adding more logging to the engine and fiddling with debug_filter.cfg because for some reason I could get the bug to happen but not have the Assert that The_E mentioned appear (still not sure why this was happening, there very well could be another bug, but I could not get it to happen repeatably). In the fiddling with the logging, I noticed that sometimes the bug would be completely gone, then when I would try and verify that this new logging fixed the problem (yes, I know, WTF!) it would happen again. I had a hunch at this point that it was something the user was doing to the engine that was causing the bug to manifest, but still had no idea what the source was.
I fiddled some more, and I started to get frustrated, because I was running out of options short of searching for every time the engine writes to the player position and sprinkling Asserts (which I may still do as the core of the engine just assumes that everything it gets all kosher) or log statements just to see if I could figure out which part of the engine the error was coming from so I could try and narrow it down. As a last resort, I eventually got to just rerunning the mission pressing different buttons and trying different inputs to see if I could get the error to subside, because I noticed that the logging didn't seem to help reliably. At some-point I started ramming the other other ship in the mission and of course, not setting speed match every time because Battuta or The_E would distract me or I was playing the afterburner to make the ramming more fun
. Obviously I eventually noticed that it didn't happen if match speed was set. So I tried enabling match speed then disabling it; the bug happen. Tried again and kept speed match on the entire time; it bugged out! I tested this theory several more times, I then asked in the channel if they could confirm if the bug went away when speed match was disabled.
I then started trawling through the code to see if I could find where the engine did calculated the speed match and I seen that that there was a division that was not protected (ie. no range checking on the divisor). Yay a simple fix to a seemingly nonsensical problem.
