develooper Front page | perl.perl5.porters | Postings from February 2001

Re: IV preservation (was Re: [PATCH 5.7.0] compiling on OS/2)

From:
Ilya Zakharevich
Date:
February 19, 2001 12:10
Subject:
Re: IV preservation (was Re: [PATCH 5.7.0] compiling on OS/2)
Message ID:
20010219151007.A7343@math.ohio-state.edu
On Fri, Feb 16, 2001 at 09:28:32PM +0000, nick@ing-simmons.net wrote:
> >Is -0 an integer?  
> 
> Yes 0.
> 
> (Though ±0 is an area if IEEE floats that makes me sick...)
> 
> >Is
> >-Inf?  
> 
> No, (and it is out of range anyway...)
> 
> >Is NaN?  
> 
> No. It isn't a number, so how can it be an integer.
> 
> >Etc etc etc.

"For every problem there is a solution which is simple, obvious, and wrong."

I'm not completely sure that the particular solutions you are
proposing are "wrong".  But I pretty much doubt that they are right too.

The problem with the numeric stuff is that to design how things
*should* work you do not go into the Oxford Dictionary, or apply
common sense, or find analogies with how things are done in "pure
math".  Instead you should know a pool of "typical" examples of
"boundary cases", and should try to deduce the influences of the
decisions on the "straightforward" implementations of these examples.

The goal of IEEE is to make "numeric math accessibe for
numerically-challenged" (say, with less than 3 years of intensive
thoughtful numeric work ;-).  This requires an absense of
"catastrophical loss of precision" in calculations.  It is OK if you
lose 1/2 of significant digits in degenerate cases, but you should not
lose *all* of them.

A typical example is the average value of exp(x) on [0,b].  It is a
"nice function" of b which has no special behaviour at b==0, but the
formula for it (exp(b)-1)/b leads to 0/0 for b near 0.  Division is
not that bad for floating point stuff, what is much worse is
subtraction of 1, which removes a lot of precision of exp(b).  But it
turns out that with a "good enough" definition of how exp(small
number) should round, you get a good approximation even for small b.

Or take (an artificial example of) atan(1/x**555).  It it is almost
constant for small x, but takes different value for small negative x
and small positive x.  For |x| below approx 0.3 it will underflow.  So
the formula makes sense, but to apply it you need to keep the sign of
the underflowed values.  Etc etc etc.

With your decision $x + 0 becomes 0 if $x is -0.  This is a loss of
information.  I'm not sure we *want* this.

Ilya



nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About