More efficient "dbl_raise"

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

I've placed a patch on SourceForge that fixes a pathological example of range 
setting involving NaN.  Yes, I know, no big deal.  But, I've changed things to 
remove a routine for which Hans put forth the following question:

/* {{{ dbl_raise() used by quantize_normal_tics */
/* FIXME HBB 20000426: is this really useful? */
static double
dbl_raise(double x, int y)

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.  So, the following 
mimics the behavior of dbl_raise():

     exponent = floor(log(arg)/log(12.0));
     power = floor(pow(12.0, abs(exponent)) + 0.5);
     if (exponent < 0)
	power = 1.0 / power;
     /* approx number of "duodecades" */
     xnorm = arg / power;

The line of logic is that we know 10^E where E is a positive integer is an 
integer value, therefore rounding to the nearest integer should remove any 
arithmetic precision error that pow() might introduce.

That fixes the original issue I had in mind.  And I've generated all.dem output 
in PostScript format.  Everything agrees, except the dates and times inside the 
PS files.

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?  I'm assuming it had something to do with 
nice tic range generation.  But at the same time I wonder if there isn't a more 
straightforward computation.

One thing I wonder about is the following.  Say I modify the above code to be:

     /* order of magnitude of argument: */
     exponent = floor(log(arg)/log(12.0));
     power = floor(pow(12.0, abs(exponent)) + 0.5);
     /* approx number of "duodecades" */
     if (exponent < 0)
	xnorm = arg * power;
     else
	xnorm = arg / power;

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.  So which is the preferred 
result formulation?

Dan