Path: utzoo!dciem!nrcaer!sce!sunray!roberts
From: roberts@sunray.UUCP (Robert Stanley)
Newsgroups: comp.sys.mac
Subject: Re: Bug in EXCEL v. 2.2, and a flame
Summary: But what does this have to do with square roots?
Message-ID: <6769@sunray.UUCP>
Date: 10 Aug 89 13:07:52 GMT
References:  <1989Aug1.193850.4999@mdivax1.uucp>
Reply-To: roberts@cognos.UUCP (Robert Stanley)
Organization: Cognos Inc., Ottawa, Canada
Lines: 76

In article <1989Aug1.193850.4999@mdivax1.uucp> hiebert@mdivax1.uucp
           (Graeme Hiebert) writes:
>In article  jk3t+@andrew.cmu.edu
>           (Jonathan King) writes:
>> 
>> Interesting.  My calculator (a Sharp EL-512 II) gives virtually the same
>> erroneous square root as Excel!  That is, the square root of .999975 is
>> given as .999987499.  It looks like this problem is not unique to Excel;
>> to make its way into the entirely silicon brain of my calculator this error
>> must be the result of an ancient and honorable (although badly conditioned)
>> numerics routine...
>> 
>> jking
>
>Very interesting indeed.  My Sun gives
>        sqrt(0.9999750000000000000000000) = 0.9999874999218740234222409
>and
>        0.9999749992187 * 0.9999749992187 = 0.9999499990624
>
>   [hand calculation of *same* equation to get same result omitted]
>
>   Well look at that.  My Sun multiplies the same way I do.  Shame on us.

And this demonstrates what?  The sqrt function yielded zero point four-
nines eight seven four three-nines two one eight seven...

All the rest of the posting talks about zero point four-nines seven four
three-nines two one eight seven - what happened to the eight between the
four-nines and the seven?

No wonder the result of the multiplication is nowhere close to the number
for which the square root was originally calculated.

I'm already having a bad day, as you can tell.  Microsoft have already
released the information that Excel has a proprietary set of floating-point
routines, and does not use SANE.  Over the past two years we have had at
least three public (in comp.sys.mac) demonstrations that Microsoft's
numeric routines are both incorrect and inconsistent in certain limit
cases.

Of much more interest would be a detailed comparison of these limit cases
across a range of floating-point routines, e.g., SANE, 68881, 68882,
Microsoft.  More importantly, because we tend to take underlying routines
of this kind as gospel truths, we (as users) really need accurate
documentation from the vendor as to where the truth stops and the fuzzies
start creeping in.  However, as has been pointed out many times before, by
far the majority of users never find themselves outside the limits.  What
I have problems with is the implicit assumption on the part of the vendors
that anyone who *does* step outside the limits will automatically be smart
enough (well-trained enough?  cynical enough?) to first identify and then
correctly attribute the problem.

Microsoft: the Apple guidelines to developers clearly state the philosophy
           behind SANE.  You have unilaterally side-stepped those guide-
           lines.  You owe it to all Mac users to tell them that you have
           done this, and where the differences will show up.

           If you don't know (implies don't care), then you should probably
           add SANE support as a user-selectable option, and let the user
           make the performance/accuracy trade-off at his or her *informed*
           discretion.  Either way, it NEEDS  DOCUMENTATION.

From the instruction label on the back of my very first Japanese hand-held
calculator (circa 1972): "Flashing display does not indicate battery low;
battery low is indicated by wrong answer."!!!  No, while I still have it,
it no longer works at all, and it didn't have a sqrt function anyway.

Have you ever considered what it would actually take to 100% verify that a
full 32-bit multiply hardware instruction is functioning correctly?

Robert_S
-- 
Robert Stanley - Cognos Incorporated: 3755 Riverside Drive, P.O. Box 9707, 
Compuserve: 76174,3024                Ottawa, Ontario  K1G 3Z4, CANADA
uucp: uunet!mitel!sce!cognos!roberts             Voice: (613)738-1338 x6115
arpa/internet: roberts%cognos.uucp@uunet.uu.net    FAX: (613)738-0002