🚀 go-pugleaf

In comp.sys.mac.advocacy, Ben Hutchings  <worc0223@sable.ox.ac.uk> writes:
>
>On 5 Oct 1995 elarson@ux1.cso.uiuc.edu wrote:
>
>> In <DFzGE9.1rF@yew.pfc.forestry.ca>, briel@branch.pfc.forestry.ca ("Bill G. Riel") writes:
>> 
>> >>Try the same test on Excel for the Mac and guess what - now the
>> >>value magically morphs to ... 1.28!
>> 
>> >Nope.  Didn't really intend to either.  Just wanted to point out one of
>> >the joys of moving along to that "new standard"
>> ===========
>> 
>> The sad part of the Excel "bug" for lack of a better derogatory term, is that it's
>> not a random unlikely number.  2^47 is no unexpected as a number being used
>> by folks who use computers.
>
>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
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.

As an aside, does Excel's internal math use a 47-digit mantissa for
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
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. 

>> 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.

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