Path: csiph.com!x330-a1.tempe.blueboxinc.net!feeder1.hal-mli.net!border3.nntp.dca.giganews.com!Xl.tags.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local2.nntp.dca.giganews.com!news.giganews.com.POSTED!not-for-mail NNTP-Posting-Date: Wed, 11 May 2011 15:55:23 -0500 Message-ID: <4DCAF7BA.3010700@SPAM.comp-arch.net> Date: Wed, 11 May 2011 13:55:22 -0700 From: "Andy \"Krazy\" Glew" Reply-To: andy@SPAM.comp-arch.net Organization: comp-arch.net User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5 MIME-Version: 1.0 Newsgroups: comp.arch Subject: Re: Computer arithmetic problems worth exploring References: <4DC5C0AE.5000200@SPAM.comp-arch.net> <8l9gs6d9ckhfqcmq4u261qqgtu3mu0a1ft@4ax.com> <4DC854BF.8090308@SPAM.comp-arch.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Lines: 86 X-Usenet-Provider: http://www.giganews.com X-Trace: sv3-Dc9JUHiXaJtFs5s7aC6GdxBEWI64LPfoGyl7G4fvOPQyhIT5lcdfKDSrA3qOBoSVQ7cV8TRdYLiXNOq!BQ6td4sDPjK5r9m/lUk4tX++noLJpkcwalpzfFR4ZyOb6yUEhLvd7sUWHRKM X-Complaints-To: abuse@giganews.com X-DMCA-Notifications: http://www.giganews.com/info/dmca.html X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.40 X-Original-Bytes: 4845 Xref: x330-a1.tempe.blueboxinc.net comp.arch:1460 On 5/10/2011 1:05 AM, nmm1@cam.ac.uk wrote: > In article<4DC854BF.8090308@SPAM.comp-arch.net>, > Andy \"Krazy\" Glew wrote: >> If we don't go that far, IEEE FP is about as good of a floating point >> standard as can be achieved. It eliminates most of the FP surprises for >> unsophisticated programmers that can be eliminated, and still remain FP. > > Grrk. It doesn't do it significantly better than most of the better > traditional arithmetics do. Is IEEE FP better than IBM hex FP? IMHO yes. Better than CDC 60 bit FP? IMHO yes. But I concede the point: yes, we can imagine better FP. I vaguely remember reading some of the proposals considered and rejected during the IEEE FP standardization effort - or perhaps I saw or read one of Kahan's presentations. Now, the real question: is it worth fixing? Is it feasible to fix? Could, for example, some SW guy build a "Better FP" library that uses some of the things Nick has mentioned, like -0,0,+0, and popularize it? If it was in wide use, then HW might add support? Or could some really brave HW company add the support, probably with an enable that allowed conventional IEEE FP to be supported. My guess is that this could not be done in 32 bit - the encodings are too tight. Perhaps in 64 bit. Or in a new, wider, format. > The thing that IEEE gets spectacularly wrong is its handling of > exceptional values (including zero, but that's not visible except > via infinities). And I mean WRONG. > > It is completely and utterly wrong that x = y does not mean that > 1/x = 1/y. > > The argument that it sets a flag would hold water if it were not > for the fact that the flag handling is seriously sick, as well as > incompatible with the arithmetic model of all relevant computing > languages. And, by sick, I mean false positive, false negatives > and dubious semantics. Yes, the idea of setting sticky flags seems to have been a compromise that made almost nobody happy. Personally, I'm all for traps and exceptions as the standard way of reporting errors. * http://andyglew.blogspot.com/2009/07/error-handling.html * http://semipublic.comp-arch.net/wiki/Error_Reporting But,. it's hard to get traction. > And its NaN handling is utterly and completely broken, though it > wasn't half as bad when it was designed. Blame the fanatics who > got that into C99, but not only them. > > If IEEE 754 had the following modifications, then it would be > about as good as could be achieved: > > 1) There is a mandatory trap-diagnose-and-terminate mode, as > on traditional mainframes and in LIA-1. The objection to this > is and was purely dogmatic. > > 2) Division by zero creates a NaN, not an infinity, thus > removing the main gotch caused by the inconsistent interpretation > of the sign bit. Which is better: -0,0,+0 such that 1/-0=-inf, 1/+0=+inf, 1/0=inf of unknown sign? Or 1/0 = NaN? > 3) ALL numeric operations on NaNs return a NaN or raise a > (hard) exception if they can't (including comparison), and the > ONLY way to lose a NaN is by an explicit non-numeric test for > such a value. Wasn't Kahan conducting a survey about this in CAM a few years ago? No, actually, it looked like he was asking leading questions that pointed in the direction of getting rid of silent NaNs.