Hi.
> FastMath aims to give the best accuracy possible given the
> constraint of IEEE binary double precision representation, while
> also giving superior performance.
This what I meant by:
> >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 big advantage of StrictMath over Math is that its results are
> portable.
This contradicts a statement made in the previous post:
> >>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.
> 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.
I don't agree here, if we are talking about "FastMath" being a replacement
of "StrictMath".
One use of reproducibility is... hmm, reproducibility [As in: Some programs
might need to produce the _same_ results on different platforms.]
Of course, if "StrictMath" is not able to provide this feature (as is
implied by sebb's comment), then what we have is that "FastMath" is portable
while "StrictMath" is not; so, again, "FastMath" is not a replacement of
"StrictMath".
To be quite clear; I don't see this as a problem. I just want to replace the
Javadoc:
Faster, more accurate, portable alternative to {@link StrictMath}.
by
Faster, more accurate, portable alternative to {@link Math}.
That's all, folks! ;-)
> 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.
So, I think that I got this part right too when I said:
> >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".
Best (and thanks again for contributing "FastMath" and "dfp"),
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
