computing expontential as repeated multiplication for small integer exponent

An earlier message on this topic seems to have gotten eaten by my computer, but the considerations in different implementations of the "same" semantics occur in other languages, e.g. Java.  What should Java numerics do when the underlying hardware gives, say,  MORE accuracy than IEEE floats?

See the discussion of Borneo vs. Java.

Answer (from W. Kahan, basically)  ... legislating against extra accuracy is a bad idea.

RJF

----- Original Message -----
From: Robert Dodier <robert.dodier at gmail.com>
Date: Monday, July 30, 2007 8:35 am
Subject: Re: [Maxima] computing expontential as repeated multiplication for small integer exponent

> On 7/30/07, Raymond Toy <raymond.toy at ericsson.com> wrote:
> 
> > Your example of 1.2345678901234567d0^3 just illustrates that expt 
> and> multiplication are different. As best as I can tell, (expt x 
> 3) from
> > cmucl (and sbcl?) is more accurate than repeated multiplication.
> 
> At this point, I think it is more important to get various Lisp
> implementations to agree, rather than getting maximally-accurate
> results for some implementations. I say this after having crunched
> more than a few numbers in various contexts.
> 
> That said, I would be equally happy with an implementation of
> EXPTB which didn't treat small integer exponents as repeated
> multiplication. All I want is for different Lisps to get the same 
> result.
> > I think rtest8 #69 shouldn't expect exactly the same result.  We 
> should> add a fuzz factor, like in some of the other tests for 
> approximately equal.
> 
> Well, this fuzz factor business is problematic. There is already
> a fuzz factor; it is 8 * (64 bit float epsilon). Test #69 comes out
> with a greater error because it is the result of an iterative 
> algorithm(namely find_root); a small discrepancy in EXPTB causes 
> find_rootto take a different number of steps for different Lisps.
> 
> In general it is difficult to gauge an acceptable discrepancy.
> For one of the test cases for lsquares which I was recently working
> on, different Lisps agree to only 3 decimal places.
> When floating point operations aren't guaranteed to come
> out the same, we can't find a suitable fuzz factor without
> considering each case, which is tedious.
> 
> best
> Robert
> _______________________________________________
> Maxima mailing list
> Maxima at math.utexas.edu
> http://www.math.utexas.edu/mailman/listinfo/maxima
>