Le dim. 29 août 2021 à 12:57, sebb <seb...@gmail.com> a écrit : > > On Sun, 29 Aug 2021 at 01:07, Gilles Sadowski <gillese...@gmail.com> wrote: > > > > Le sam. 28 août 2021 à 14:36, sebb <seb...@gmail.com> a écrit : > > > > > > On Sat, 28 Aug 2021 at 13:25, Gilles Sadowski <gillese...@gmail.com> > > > wrote: > > > > > > > > Hello. > > > > > > > > What would be a sufficient condition for removing the "AccurateMath" > > > > (previously named "FastMath") in the upcoming major release? > > > > > > > > I'd think that the following should hold (when running on JRE 11): > > > > > > Math currently targets JRE 1.8+, so why assume JRE 11? > > > > A corollary question is whether we should support usage of the > > upcoming release on Java 8, even if the library stays source > > compatible with Java 8 (to allow such usage). > > That is a separate discussion.
In effect, it's not: If the 2 conditions are satisfied, Java 11 users are forced to use "FastMath" though it is slower than "Math". And Java 8 users who use "FastMath" on the rationale that they need the performance edge over "Math" in that version of the JVM then have a good reason to upgrade to a more recent JVM. > > Dropping "FastMath" would mean that the library and applications > > using it can benefit from the performance enhancements of Java > > 11 (if the conditions below hold). > > Huh? > Why would it be necessary to drop FastMath to benefit from using Java 11? Cf. above (since currently "FastMath" is used throughout CM). > > > > * no "AccurateMath" function is faster, and > > > > * no "AccurateMath" function is more accurate. > > > > > > Otherwise the conditions are OK. > > > > > > Note: the class(es) should be deprecated for one or two releases first. > > > > The upcoming release (4.0) is a major one. Users would anyways > > have to adapt their code to the package's name change (and to the > > class name change too in this case); doing that would not be any > > simpler than searching calls to "FastMath" and replacing them with > > calls to "Math". > > > > Gilles --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
