🚀 go-pugleaf

On 15 Oct 1995, Shimpei Yamashita wrote:

> In comp.sys.mac.advocacy, Ben Hutchings  <worc0223@sable.ox.ac.uk> writes:
> >
[...]
> >2^47 can cause problems because double-precision numbers use a 
> >47-bit mantissa. So there could be overflow from the mantissa into the 
> >exponent, or something like that (I'm not too familiar with the
> >floating-point number bitfields). I don't believe this is intentional.
> 
> No no no no no no no. You're mixing things up.
> 
> 47 bit mantissa in a double-precision floating point number does not
> mean the maximum value for the mantissa is 47.  It means that you can

No, but during the conversion from a text string to a floating-point 
number there could be a bug which leads to incorrect bit-packing for 2^47.

> have 47 significant binary digits and 16 bits for your exponents
> (the last bit is for the sign). You need a bit for the exponent sign, too,
> so you can express up to 2^(2^15-1)-1 with your format, which is
> considerably bigger than 2^47. It isn't a rounding error.

No, it's a bug.

> As an aside, does Excel's internal math use a 47-digit mantissa for

The IEEE double-precision standard uses this, and Excel will probably do 
the same so that it can easily utilise maths coprocessors (which use the 
IEEE standard formats).

> doubles? The native format for MacOS on PowerPC uses 52 bits
> (cf. _PowerPC Numerics_ volume of _Inside Macintosh_, p. 2-11). And if
> there is an "overflow" from the mantissa into the exponents, it is a
> bug, plain and simple. I doubt that's the case, though. I haven't read

While the bits are being shifted around, there could be an overflow if 
a test condition is not quite right.

> up on the 68K or x86 floating point treatment, but IEEE compliant
> environments (which the PowerPC is, as well as Pentium) are supposed
> to handle overflows cleanly by returning NaNs. 

I'm not suggesting that the error is occurring during floating-point 
operation.

> >> It also makes me wonder what other intentional bugs are present in Microsofts
> >> products.  
> >
> >If they are intentional, they can't be bugs. Go look up the definition of 
> >`bug'. Certainly there are undocumented features in Microsoft products, 
> >but I do not believe this is one of them.
> 
> Well, they certainly are harmful under certain situations (and aren't
> useful to the user under any conceivable situation) and nobody outside
> of Microsoft was informed about it from the company, so it's certainly
> a bug for all we care. If they were intentional, then this is a more
> insidious issue than bugs, because it would be a confirmation that
> Microsoft doesn't give a whit about the well being of its customers.

As if we needed more evidence...!

> 
> -- 
> Shimpei Yamashita, Stanford University           shimpei@leland.stanford.edu
>            <http://www-leland.stanford.edu/~shimpei/index.html>