Re: More efficient "dbl_raise"

[Daniel J S. <dan...@ie...>]

Ethan Merritt wrote:
> 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. 

What bothers me is a FIXME that is a red herring.  Like I said, I would have 
probably just written a patch to disallow NaN in set.c.  Of course, if like you 
say there are some implementation such as VAX that aren't IEEE standard then 
will checking for a value of 'NaN' even compile on VAX systems?


>>>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.

OK, mantissa overflow, i.e., precision, is what I meant.


>>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.

So this means dbl_raise() implementation is better than pow()?

Dan