On 2021-09-28, 21:03, "Gilles Sadowski" <[email protected]> wrote:
Hi,
I've discovered that there is additional red tape I have to handle before I can
contribute.
Cheers
Erik Svensson
Hi.
FTR: https://issues.apache.org/jira/browse/MATH-1630
Gilles
Le lun. 6 sept. 2021 à 21:18, Gilles Sadowski <[email protected]> a
écrit :
>
> Hi.
>
> Le lun. 6 sept. 2021 à 15:26, Erik Svensson <[email protected]> a
écrit :
> >
> > On 2021-09-02, 18:11, "Gilles Sadowski" <[email protected]> wrote:
> >
> > WARNING - External email; exercise caution.
> >
> > Le jeu. 2 sept. 2021 à 16:30, Erik Svensson
<[email protected]> 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: [email protected]
For additional commands, e-mail: [email protected]
*******************************************
CONFIDENTIALITY AND PRIVACY NOTICE: This e-mail and any attachments are for the
exclusive and confidential use of the intended recipient and may constitute
non-public information. Personal data in this email is governed by our Privacy
Policy at https://www.nasdaq.com/privacy-statement unless explicitly excluded
from it; please see the section in the policy entitled “Situations Where This
Privacy Policy Does Not Apply” for circumstances where different privacy terms
govern emailed personal data. If you received this e-mail in error,
disclosing, copying, distributing or taking any action in reliance of this
e-mail is strictly prohibited and may be unlawful. Instead, please notify us
immediately by return e-mail and promptly delete this message and its
attachments from your computer system. We do not waive any work product or
other applicable legal privilege(s) by the transmission of this message.
*******************************************
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
