Re: More efficient "dbl_raise"

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

Daniel J Sebald wrote:
> Hans-Bernhard Bröker wrote:
>> Daniel J Sebald wrote:

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

> Right.  But the premise, I guess, is that for the application in 
> question we're interested in raising an integer to an integer power, 
> which results in an integer.  

No. We're interested in raising a double to an integer power, which 
results in a double.  For simple cases, the input and output doubles 
will have integer values, but they're not integers by design.  If we 
only had to worry about cases where the power is small enough for the 
result to be integer, a table of all 10 powers-of-ten from 10^0 to 10^9 
would suffice.  But that's not the case.

> Your statement may be true for relatively small numbers.  To confirm 
> that for larger numbers, one would have to look at the pow() code.  I 
> mean, the way gnuplot is programmed, what if someone enters numbers on 
> the order of 1e30? What's the precision of 10*10*...*10*10 as a floating 
> point number?  

As good as it can be.  It's still likely to be better than that of the 
typical naive implementation of pow(x,y):

	exp(y*log(x))

For the fun of it, be sure to make some plots of this function:

	powdiff(base,power) = (base**power / exp(power*log(base))) - 1.0

E.g.

	set samples 301 ; plot [0:60] powdiff(10,x)

to see just how badly wrong this can go.

> floor(log10(arg))
> 
> We aren't guaranteed that will come out to be exactly the exponent 
> desired.  

No, we're not.  Which is why this result is used only as a guide, not as 
the single piece of information, by quantize_tics.  There's a reason 
that there are cases of that switch outside the expected range of [2:20].

> Maybe the best we could hope for is some kind of internal consistency 
> between log10() and pow(), by which I mean it would be nice that if
> 
>   E = floor(log10(arg))
> 
> then
> 
>   pow(10,E) <= arg < pow(10,E+1)
> 
> is always true.  

No, the best we can do is avoid having to rely on such assumptions.  The 
  code in quantize_tics() does that.