|Re: HP-35 powers with negative numbers|
Message #12 Posted by Dale Reed on 26 Jan 2012, 2:24 p.m.,
in response to message #8 by Marcus von Cube, Germany
All of this is specified in IEEE-754 (for binary float) and IEEE-854 (later, for binary and decimal float and others).
[As an aside, note that calculators generally use decimal floating point math, so that 0.1 is an exact number. PCs and other systems (using a C math library, etc.) often use binary floating point math, where the mantissa is binary and the exponent is a power of 2. In these systems, 0.1 decimal is a repeating binary fraction that cannot represent 0.1 exactly, so 0.1 * 10.0 results in a number slightly less than 1.0 (0.9999998 for example).]
I have a fair amount of experience with binary float --- less so with decimal. But I think what follows still applies...
In single precision binary float, +0 is the bit pattern:
(sign, exponent, mantissa all zero bits)
and -0 is the bit pattern:
(negative sign, but exponent and mantissa still all zero).
IEEE says that -0 and +0 must compare equal, but many systems take the shortcut of comparing the underlying bit patterns and will result in 'not equal'. (These systems generally are coded to NEVER generate -0, sort of as a "workaround" -- so you'll never have to compare a -0 -- but a -0 received over a comm link will mess them up.)
IEEE 754 also has bit patterns for +/-Infinity, Indefinite, and both "signaling" and "quiet" NaNs (Not a Number). If a variable "x" has NaN (any) for a value, IEEE says x==x should compare FALSE (a NaN never compares equal to anything), but in a system which only compares the underlying bit patterns, x==x will compare TRUE, even if x is NaN.
So is -0==0? Not if the float library was written for speed at the expense of compliance with standards.