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 "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. AIUI, the original purpose of the FastMath package was to provide faster and more accurate (if possible) calculations. 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. 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? > > Regards, > 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]
