Re: More efficient "dbl_raise"

[<HBB...@t-...>]

Daniel J Sebald wrote:

> The issue in dbl_raise is a multiplying loop for raising a value to an integer 
> power.  I'm guessing the library function pow() does such a thing more 
> efficiently in addition to handling the pathological NaN.  

Maybe so, but at the same time, there's a solid probability that it is 
just too inaccurate to work.

Tics generation is extremely sensitive to rounding error, mainly in 
extreme cases: very large or small arguments, arguments already slightly 
distrubed by earlier rounding errors.

A while ago we had a long-standing bug where tic generation was broken 
just by turning on -O2 in GCC, but only on some platforms.  Suffice it 
to say that this is a kind of problem I'd rather not have to face again.

> In some way it also removes the question that Hans raised in the code.  I'm sure 
> you can't recall that far back, Hans, but a question I have is just exactly was 
> this approach supposed to achieve?  

Basically, it's that pow() isn't required to treat integer exponents 
specially, so it can easily destroy more precision than dbl_raise() in 
its existing form does.

> One thing I wonder about is the following.  Say I modify the above code to be:
[...]
> Wouldn't you think that this is a better formulation in terms of precision? 
> That is, we've a direct division in one case, and avoid a double division in 
> another case.  But if I run this version of gnuplot on all.dem, the result is 
> differences other than just the times and dates.  

Well, you've just proved that it's not a better formulation, haven't you?