On Wed, Jan 26, 2011 at 12:12:47PM +0000, sebb wrote: > On 26 January 2011 11:05, Gilles Sadowski <gil...@harfang.homelinux.org> > 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". Gilles --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
