On 2021-08-29, 14:05, "Gilles Sadowski" <gillese...@gmail.com> wrote:
WARNING - External email; exercise caution.
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.
I have a branch that allows for what I call math profiles. IE, if you pass in
the right flag the code will run either FastMath or JDK or any other math
profiles that follows essentially the FastMath contract (extracted to an
interface).
I would push it to GitHub but I don't have the privs for it.
NB that the code is not finished, there are no jdocs and I don’t quite know
where the code ought to be put.
I've put it into math4.legacy.core right now.
> > 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
Erik Svensson
Principal Architect
Strategic Programs, Platform & Product Engineering
<http://www.nasdaq.com/>
Desk
Mobile
Email
Address
+ 46 8 405 66 39
+ 46 73 449 66 39
erik.svens...@nasdaq.com
Tullvaktsvägen 15, Stockholm
<https://www.facebook.com/nasdaq/>
<https://twitter.com/nasdaq>
<https://www.linkedin.com/company/nasdaq>
<https://www.instagram.com/nasdaq/>
<https://www.pinterest.com/nasdaq/>
rewritetomorrow.com <http://rewritetomorrow.com/>
---------------------------------------------------------------------
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.
*******************************************
