Scott McMurray wrote:
On 2 April 2010 13:43, Chad Nelson <chad.thecomfychair@gmail.com> wrote: [...] I think is_nan(Inf) should be false, but is_finite(Inf) should also be false.
Well is_finite(NaN) should be false as well; is_infinity would be a more appropriate predicate.
it's not something that can be calculated with, generally.
[...]
If I don't add an infinity value, I could. I'm leaning toward adding one (with sign), but it will act exactly like a NaN except for comparisons.
Actually, you *can* calculate with infinity. That's the reason for having it separate from NaN, and why it needs a sign. Any operation with NaN gives a NaN, but at least the following for Infs don't give NaNs (for any x, y where is_finite(x) && !is_nan(y)):
-(Inf) => -Inf -(-Inf) => Inf x + Inf => Inf x - Inf => -Inf x % Inf => x Inf + Inf => Inf -Inf - Inf => -Inf x < Inf => true x > -Inf => true y <= Inf => true y >= -Inf => true x / Inf => 0 x / -Inf => 0 if (y != 0) y * Inf => sign(y)Inf if (y != 0) y * -Inf => sign(-y)Inf
But the indeterminate forms do, of course, give NaNs:
Inf - Inf => NaN -Inf + Inf => NaN 0 * Inf => NaN 0 * -Inf => NaN Inf / Inf => NaN Inf / -Inf => NaN Inf % y => NaN
Hopefully that'll make you lean further :P
Don't forget (assuming a single unsigned 0): x / 0 => NaN and I think you'd want Inf to compare equal with itself (unlike NaN, which does not compare equal with itself...and doesn't compare unequal with itself, either :/ ). This is of secondary consideration to the core set of algorithms that should just throw whenever something bad happens (e.g., division by 0), though. Another topic: Chad, how natural is it, implementation-wise, to have a signed zero? I'm guessing you have a sign bit, leading naturally to either providing both a +0 or a -0, or ensuring after each operation that -0 is normalized to +0. What are the arguments against a signed zero? Is it possible to simply be agnostic to the sign bit when the mantissa is 0? - Jeff