On Wed, 26 Jan 2011, Gilles Sadowski wrote:
On Wed, Jan 26, 2011 at 12:12:47PM +0000, sebb wrote:
On 26 January 2011 11:05, Gilles Sadowski <[email protected]> wrote:
Hi.
I'd wish to make it clear that I referred to this statement:
The Javadoc for FastMath says that it is a replacement for
StrictMath,
which is why I tested against that.
An my understanding was:
Unless I'm missing something, this is a doc mistake then.
So we have:
[Please correct me if the following statement is wrong.] "StrictMath" must
reproduce the _same_ results on any JVM.
Not quite. From the StrictMath Javadoc [1]:
"To help ensure portability of Java programs, the definitions of some
of the numeric functions in this package require that they produce the
same results as certain published algorithms"
So some StrictMath methods may produce different output on different systems.
[Note that the StrictMath code is not portable - AFAICT it uses some
native methods.]
Then, to be replacement, "FastMath" must reproduce those _same_ (i.e. same
as "StricMath") results.
Is that the case?
Not all StrictMath results are necessarily portable or indeed the most accurate.
If so, then it doesn't make sense to me that they call it "StrictMath".
[Some results are reproducible, some not; some are accurate, some not.]
This would make me even less happy to refer to "StrictMath" in the Javadoc
of "FastMath".
If "FastMath" is as fast (or faster), for all methods, than "Math" (while
being as accurate), then it is a replacement of "Math".
Is that the case? [Luc already answered "Yes" to that question.]
To be a replacement for either StrictMath or Math it needs to
implement all the methods they provide.
It currently implements all of the StrictMath 1.6 methods (by
delegation if necessary), but not all the Math 1.6 methods.
Why not?
Isn't it just a matter of delegating all methods that don't provide a
specific implementation?
AIUI, the original purpose of the FastMath package was to provide
faster and more accurate (if possible) calculations.
Agreed.
Also to use pure Java so that the code is portable. This has the
additional benefit that the code is usable with other JVMs which may
not be so performant.
Agreed.
Now what we seem to be discussing is exactly which methods should be
in FastMath.
Should we aim to implement all of Math? or just StrictMath (as at
present) or some smaller subset?
What should the criteria for incuding a method be?
- that it is more accurate than Math/StrictMath?
- that it is faster than at least some implementations of Math/StrictMath?
- something else?
I'd say (and the name "FastMath" reflects that) that it is a fast
replacement of "Math". Thus all "Math" functions should be present and at
least as fast (and as accurate).
The fact that "FastMath" is more accurate is a bonus but not the main reason
for being in CM. IIUC, high accuracy is the main purpose of the classes in
package "dfp".
FastMath aims to give the best accuracy possible given the constraint of
IEEE binary double precision representation, while also giving superior
performance.
The big advantage of StrictMath over Math is that its results are
portable. Well, FastMath is portable too, but that doesn't mean that
FastMath and StrictMath have to produce the same answers. The whole
reason StrictMath was created was to allow people to compare numerical
results that were produced on differnt platforms. FastMath allows that as
well.
The dfp package offers very high precisions, but it does so by dropping
the IEEE constraint and the performance constraint. It competes with
BigDecimal, and its advantage is that it provides a bunch of functionality
not available in BigDecimal such as IEEE traps, more elementary functions,
etc.
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
