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