Hi!
On 2021-09-06, 21:21, "Gilles Sadowski" <gillese...@gmail.com> wrote:
WARNING - External email; exercise caution.
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.
np
> 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", ... ;-)
For functional testing I turned those off.
> 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).
My reasoning was that that by coring out AM I wouldn't have to rewrite all the
downstream code that uses AM and that could benefit from a better performing
implementation.
Then, the new "AccurateMath" now computes results that depend on
the selected "profile", entailing that there is no accuracy guarantee!
That is true, see my above comment. One solution would be to have a wrapper
class (as my AM is) with another name that defaults to AM for implementation.
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.
Finding good names is hard.
Allowing any application to globally change the implementation (through
"MathProfile") seems quite unsafe.
That was just an half-baked idea I had that you might want to insert your own
profile.
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---
?
Note that this will not solve the problem of failing the StrictMath conformance
test.
I'll check it out with JMH. The performance improvements from
@IntrinsicCandidate are impressive but quite fragile. It does not need much to
totally consume it.
I have a branch that uses enum:s for math profiles but I thought it might be
interesting to be able to insert your own profile.
Cheers
/Erik
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
>
>
> *******************************************
> 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: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
*******************************************
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.
*******************************************
