Re: More efficient "dbl_raise"

[Ethan A M. <merritt@u.washington.edu>]

On Saturday 07 April 2007 15:58, Daniel J Sebald wrote:
> Move the patch into CVS or dump it?  (Discussing things and not resolving=
 them,
> even for as trivial a patch as this, isn't productive.)

Was there a real problem that this was supposed to solve?
If not, drop it.

	Ethan


>=20
> Dan
>=20
>=20
> Daniel J Sebald wrote:
> > Hans-Bernhard Br=F6ker wrote:
> >=20
> >>Daniel J Sebald wrote:
> >>
> >>
> >>>Hans-Bernhard Br=F6ker wrote:
> >>>
> >>>
> >>>>Daniel J Sebald wrote:
> >>
> >>
> >>>>>In some way it also removes the question that Hans raised in the=20
> >>>>>code.  I'm sure you can't recall that far back, Hans, but a question=
=20
> >>>>>I have is just exactly was this approach supposed to achieve? =20
> >>
> >>
> >>>>Basically, it's that pow() isn't required to treat integer exponents=
=20
> >>>>specially, so it can easily destroy more precision than dbl_raise()=20
> >>>>in its existing form does.
> >>
> >>
> >>>Right.  But the premise, I guess, is that for the application in=20
> >>>question we're interested in raising an integer to an integer power,=20
> >>>which results in an integer. =20
> >>
> >>
> >>No. We're interested in raising a double to an integer power, which=20
> >>results in a double.  For simple cases, the input and output doubles=20
> >>will have integer values, but they're not integers by design.
> >=20
> >=20
> > This equation
> >=20
> >      double power =3D dbl_raise(10.0, floor(log10(arg)));
> >=20
> > from a purely mathematical standpoint, is raising an integer, 10, to an=
 integer,=20
> > floor(), power.  Generally, that's a rational number.  Now, looking mor=
e closely=20
> > at dbl_raise(x,y), we have
> >=20
> >      int i =3D abs(y);
> >=20
> > An integer raised to a positive integer power is an integer.  (I forgot=
 to=20
> > clarify it is a positive integer power last time, maybe that's where th=
e=20
> > confusion is.)
> >=20
> > We are free to round the value and remove any finite math effects.
> >=20
> >=20
> >  >  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 1=
0^9
> >  > would suffice.  But that's not the case.
> > [snip]
> >  > As good as it can be.  It's still likely to be better than that of t=
he
> >  > typical naive implementation of pow(x,y):
> >=20
> > If the ultimate result can't be represented with a binary float, that's=
 a=20
> > different matter.  But I'm saying that isn't unique to pow() because ne=
ither can
> >=20
> > 10*10*10*10*10*10*10*10*10*10*10*10*10*10*10*10*10*10*10*10*10*10*10*10=
*10
> >=20
> > be contained in binary float.  It reaches a point along the way in the=
=20
> > multiplication loop that the ability to represent the large integer is =
gone and=20
> > each multiplication results in poorer and poorer resolution relative to=
 the=20
> > increasing product.  Who knows?  Perhaps the pow() function has better =
numerical=20
> > behavior and ends up being more accurate in some circumstances.
> >=20
> >=20
> >=20
> >>For the fun of it, be sure to make some plots of this function:
> >>
> >>    powdiff(base,power) =3D (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))
> >=20
> >=20
> > Interesting plot, and that is the issue at hand.
> >=20
> >=20
> >=20
> >>>We aren't guaranteed that will come out to be exactly the exponent=20
> >>>desired. =20
> >>
> >>
> >>No, we're not.  Which is why this result is used only as a guide, not a=
s=20
> >>the single piece of information, by quantize_tics.  There's a reason=20
> >>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=
=20
> >>>between log10() and pow(), by which I mean it would be nice that if
> >>>
> >>>  E =3D floor(log10(arg))
> >>>
> >>>then
> >>>
> >>>  pow(10,E) <=3D arg < pow(10,E+1)
> >>>
> >>>is always true. =20
> >>
> >>
> >>No, the best we can do is avoid having to rely on such assumptions.  Th=
e=20
> >> code in quantize_tics() does that.
> >=20
> >=20
> > You're looking at this in one level broader scope than I am.  I'm just =
focused=20
> > on getting xnorm to be accurate given whatever the value of arg is, i.e=
=2E, the=20
> > correct value of the exponent E rather than possibly being off by one..=
=2E which=20
> > is a little subjective in itself meaning that E being one less than the=
=20
> > mathematically correct value won't result in overly bad number of tics =
anyway.
> >=20
> > Dan
> >=20
> > -----------------------------------------------------------------------=
=2D-
> > Take Surveys. Earn Cash. Influence the Future of IT
> > Join SourceForge.net's Techsay panel and you'll get the chance to share=
 your
> > opinions on IT & business topics through brief surveys-and earn cash
> > http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=
=3DDEVDEV
> > _______________________________________________
> > gnuplot-beta mailing list
> > gnu...@li...
> > https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> >=20
>=20
>=20

=2D-=20
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742