Hi. FTR: https://issues.apache.org/jira/browse/MATH-1630
Gilles Le lun. 6 sept. 2021 à 21:18, Gilles Sadowski <gillese...@gmail.com> a écrit : > > Hi. > > Le lun. 6 sept. 2021 à 15:26, Erik Svensson <erik.svens...@nasdaq.com> a > écrit : > > > > On 2021-09-02, 18:11, "Gilles Sadowski" <gillese...@gmail.com> wrote: > > > > WARNING - External email; exercise caution. > > > > Le jeu. 2 sept. 2021 à 16:30, Erik Svensson <erik.svens...@nasdaq.com> > > a écrit : > > > > > > Hi! > > > > > > > > > > > > I’ve implemented profiles, where you can choose to use either > > AccurateMath or jlM and it works on j8. > > > > Can you provide a link to the code? > > > > https://github.com/perf-coder/commons-math/tree/math-profiles-j8-am > > Thanks. > > > My changes are all in org.apache.commons.math4.legacy.core > > The MathProfile.java API might warrant some work. > > The MathProfile static block will check for a property (currently > > org.apache.commons.math.provider ) which can have JDK_MATH as optional > > value. > > All other values will default to AM as math provider. > > For java 8, the code builds just fine > > It should not, unless you've disabled "CheckStyle", "PMD", ... ;-) > > > and works as intended. For java versions > 8, it will not build since AM > > doesn't implement all methods in StrictMath (or so the tests say anyway). > > > > NB that the code is not release-ready. I need to add doc:s. > > There is a feeling of things being upside down: You've moved all the > "AccurateMath" code to a new "AccurateMathImpl" class (whereas the > *implementation* was indeed the former). > > Then, the new "AccurateMath" now computes results that depend on > the selected "profile", entailing that there is no accuracy guarantee! > > The "MathAPI" class conjures the idea of some "new" API (defined by > this project) whereas the API is defined by the contents of the JDK's > "Math" class. > > Allowing any application to globally change the implementation (through > "MathProfile") seems quite unsafe. > > > What about the following approach: > ---CUT--- > public final class JdkMath { > /** Property identifier. */ > private static final String PROPERTY_KEY = > "org.apache.commons.math.jdkmath"; > /** max(x, y). */ > private static final DoubleBinaryOperator max; > /** sin(x). */ > private static final DoubleUnaryOperator sin; > /** random(). */ > private static final DoubleSupplier random; > > /** Available implementations of {@link Math} functions. */ > public enum Impl { > /** {@link AccurateMath Commons Math}. */ > CM, > /** {@link Math JDK}. */ > JDK > } > > static { > final String prop = System.getProperty(PROPERTY_KEY); > final Impl impl = prop != null ? > Impl.valueOf(prop) : > Impl.CM; > > switch(impl) { > case CM: > max = AccurateMath::max; > sin = AccurateMath::sin; > random = AccurateMath::random; > break; > > case JDK: > max = Math::max; > sin = Math::sin; > random = Math::random; > break; > > default: > throw new IllegalStateException("Internal error"); // > Should never happen. > } > } > > /** > * @param x Number. > * @param y Number. > * @return max(x, y). > */ > public static double max(double x, > double y) { > return max.applyAsDouble(x, y); > } > > /** > * @param x Number. > * @return sin(x). > */ > public static double sin(double x) { > return sin.applyAsDouble(x); > } > > /** > * @return a random number between 0 and 1. > */ > public static double random() { > return random.getAsDouble(); > } > > // ... > } > ---CUT--- > ? > > Regards, > Gilles > > > > > Cheers > > Erik Svensson > > > Building on later versions of the jdk fails on the > > AccurateMathTest.checkMissingAccurateMathClasses test (not surprise there). > > > > > > I can implement the missing methods using the same algorithms as > > OpenJDK, > > > > Do you mean copying (Java?) code that is maintained somewhere else? > > > > > we can remove the test or maybe something else? > > > > Perhaps refactor the test using assumptions.[1] > > > > > The second alternative depends on if AccurateMath is going to keep on > > being a drop-in replacement for jlM. > > > > "FastMath" was a rewrite of the functions defined in "java.lang.Math" > > as of Java 8. > > Its usefulness was in the implementations being equally or more > > accurate and sometimes faster (on Java 5). > > As mentioned in another thread, we should know whether that's still > > the case in environments where the upcoming version of CM could > > potentially be used. > > > > > > > > How do you guys want to play this? > > > > > > > [1] > > https://junit.org/junit5/docs/current/user-guide/#writing-tests-assumptions --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
