Re: More efficient "dbl_raise"

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

Hans-Bernhard Bröker wrote:

>> Given gnuplot's behavior, can we come up with a comparison at the 
>> command line the reflects the behavior of C routines?  I've followed 
>> the parsing to internal.c and see that ** operator does in fact use 
>> the C library pow(,) function.
> 
> 
> It's not quite as simple as that.  f_power uses pow() (and some 
> trigonometry) for floating-point arguments, but iterated multiplication 
> for integer**integer.

Hence why I used 10.0 in the plots.


>> Very strange.  Not concrete proof, but my conjecture about not knowing 
>> which is more accurate, outright multiplying via dbl_raise() vs. 
>> pow(), does seem a pertinent question.
> 
> 
> Not really, because utmost accuracy is at most half the picture here. 
> Trying to "make sure we get exactly the right result for xnorm" is a 
> futile effort, because we a) don't need it exactly right, and b) we 
> can't get it, anyway.

I agree.


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


>  They're with the overall result of 
> quantize_{normal|duodecimal}_tics(), for inputs that don't quite lie on 
> the integer values the users think they see, because of rounding or 
> sampling inaccuracies that took place before scaling even began.  E.g. 
> if the actual y range is [0:100+epsilon], how should the tic interval 
> and auto-extended range endpoint depend on the sign and magnitude of 
> epsilon, at small values?

This issue has come up before, as part of a bug report.  And I think I have an 
acceptable solution for that situation as part of a patch, although the belief 
seems to be that this is impossible to address.


> 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.  On the other hand, I'm not sure it is good practice to second guess 
library functions without evidence of a bug.

Anyway, if we think that the dbl_raise() is the preferred route, all that need 
be done is remove the comment "FIXME, is this needed?" and give a short 
explanation why it is needed.

Dan