Re: More efficient "dbl_raise"

[Ethan M. <merritt@u.washington.edu>]

On Monday 09 April 2007 15:35, Daniel J Sebald wrote:
> > The real problems aren't with pow() vs. dbl_raise() --- pow() would just 
> > fail in a different way on the [NaN:NaN] range example that re-triggered 
> > this discussion.
> 
> In a different way, but also an acceptable way if one looks at the result, a 
> blank plot.  GIGO, not GIHFFM (garbage in, hang for five minutes).

Could we please decouple discussion of dbl_raise() from possible
bugs in parsing 'set xrange'?   If it bothers you that much to have 
xrange accept NaN on input, then please submit a patch to prevent it. 
 
> > And that's before we consider that we have exactly zero control over the 
> > quality of a given C compiler's math library, and thus their pow() 
> > function.  dbl_raise() may not be the shiniest tool in the shed, but at 
> > least it's _our_ tool.  Its behaviour may vary a good deal less from one 
> > platform to the next than that of pow().
> 
> Assuming the way the compiler handles floating point multiply for large overflow 
> numbers, as Ethan described, is more consistent than the pow() function, then 
> yes.

That is *not* an overflow.  
"Overflow" is when you exceed the range of numbers that can be represented;
i.e. not enough bits in the exponent.
What you are seeing is a limitation of the precision; i.e. not enough
bits in the mantissa.

> On the other hand, I'm not sure it is good practice to second guess  
> library functions without evidence of a bug.

It's not even a question of library functions. It's a consequence of the
IEEE floating point format.  Presumably you wouldn't see this on a, say,
a VAX if you chose one of the native double precision  representations
rather than IEEE. They give you the option of spending more bits on the
precision (mantissa) and fewer on the range (exponent).
Of course then you'd hit true overflow sooner.  You can't win.

-- 
Ethan A Merritt