On Jun 1, 7:45 am, Carl Banks <pavlovevide...@gmail.com> wrote: > On Sunday, May 29, 2011 8:59:49 PM UTC-7, Steven D'Aprano wrote: > > On Sun, 29 May 2011 17:55:22 -0700, Carl Banks wrote: > > > > Floating point arithmetic evolved more or less on languages like Fortran > > > where things like exceptions were unheard of, > > > I'm afraid that you are completely mistaken. > > > Fortran IV had support for floating point traps, which are "things like > > exceptions". That's as far back as 1966. I'd be shocked if earlier > > Fortrans didn't also have support for traps. > > >http://www.bitsavers.org/pdf/ibm/7040/C28-6806-1_7040ftnMathSubrs.pdf > > Fine, it wasn't "unheard of". I'm pretty sure the existence of a few high > end compiler/hardware combinations that supported traps doesn't invalidate my > basic point. NaN was needed because few systems had a separate path to deal > with exceptional situations like producing or operating on something that > isn't a number. When they did exist few programmers used them. If > floating-point were standardized today it might not even have NaN (and > definitely wouldn't support the ridiculous NaN != NaN), because all modern > systems can be expected to support exceptions, and modern programmers can be > expected to use them. > > > The IEEE standard specifies that you should be able to control whether a > > calculation traps or returns a NAN. That's how Decimal does it, that's > > how Apple's (sadly long abandoned) SANE did it, and floats should do the > > same thing. > > If your aim is to support every last clause of IEEE for better or worse, then > yes that's what Python should do. If your aim is to make Python the best > language it can be, then Python should reject IEEE's obsolete notions, and > throw exceptions when operating on NaN. > > Carl Banks
Why can python not have an fpu object (class?) where one can go and turn on/off the button that makes nan signalling? In short, cant we have the cake and eat it too? -- http://mail.python.org/mailman/listinfo/python-list
