Re: HP35 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 IEEE754 (for binary float) and IEEE854 (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:
0_00000000_00000000000000000000000
(sign, exponent, mantissa all zero bits)
and 0 is the bit pattern:
1_00000000_00000000000000000000000
(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.
