Re: JDK 9 RFR of 4477961: java.lang.Math.toDegrees(double) could be optimized

Hi Brian Le 23/09/14 00:34, Brian Burkhalter a écrit : > I created an alternate webrev using compile-time constants per your > suggestion: > > http://cr.openjdk.java.net/~bpb/4477961/webrev.01/ On a very minor formatting detail, the change in StrictMath has a misplaced empty line (before the RAD

Re: JDK 9 RFR of 4477961: java.lang.Math.toDegrees(double) could be optimized

On 09/23/2014 07:12 PM, Brian Burkhalter wrote: >> Ah, sorry for confusing language about "compile-time constants", I meant >> "compile-time constant expression", as per JLS 15.28. Constant >> expressions are FP-strict, so it should be just fine correctness- and >> performance-wise, and less crypti

Re: JDK 9 RFR of 4477961: java.lang.Math.toDegrees(double) could be optimized

Hi Aleksey, On Sep 22, 2014, at 11:42 PM, Aleksey Shipilev wrote: > On 09/23/2014 02:34 AM, Brian Burkhalter wrote: >> I created an alternate webrev using compile-time constants per your >> suggestion: >> >> http://cr.openjdk.java.net/~bpb/4477961/webrev.01/ >>

Re: JDK 9 RFR of 4477961: java.lang.Math.toDegrees(double) could be optimized

Hi Brian, On 09/23/2014 02:34 AM, Brian Burkhalter wrote: > I created an alternate webrev using compile-time constants per your > suggestion: > > http://cr.openjdk.java.net/~bpb/4477961/webrev.01/ > Ah, sorry for confusing language about "co

Re: JDK 9 RFR of 4477961: java.lang.Math.toDegrees(double) could be optimized

Hi Mike, Thanks for the review. For the sake of completeness I tested converting 89.0 * Double.MIN_VALUE to radians and Double.MAX_VALUE / 89.0 to degrees. The old version gives 0.0 and Double.POSITIVE_INFINITY, respectively, whereas the webrev.01 version gives the respective results 1.0E-323

Re: JDK 9 RFR of 4477961: java.lang.Math.toDegrees(double) could be optimized

Looks fine to me! Mike On Sep 22 2014, at 15:34 , Brian Burkhalter wrote: > Hi Aleksey, > > On Sep 22, 2014, at 2:43 PM, Aleksey Shipilev > wrote: > >> Hm, and this compiler transformation works in strictfp context? I hope >> compilers do the constant folding in strictfp/fdlibm mode… > > Y

Re: JDK 9 RFR of 4477961: java.lang.Math.toDegrees(double) could be optimized

Hi Aleksey, On Sep 22, 2014, at 2:43 PM, Aleksey Shipilev wrote: > Hm, and this compiler transformation works in strictfp context? I hope > compilers do the constant folding in strictfp/fdlibm mode… Yes. > I would probably just go and declare the private compile-time constants. > This is safe

Re: JDK 9 RFR of 4477961: java.lang.Math.toDegrees(double) could be optimized

Hi Mike, It’s definitely worth mentioning and something which should be taken into consideration when considering the change. Thanks, Brian On Sep 22, 2014, at 2:48 PM, Mike Duigou wrote: > I thought it was worth mentioning because I had had to deal with the > underflow issue in the mapping

Re: JDK 9 RFR of 4477961: java.lang.Math.toDegrees(double) could be optimized

Hi Aleksey, On Sep 22, 2014, at 2:43 PM, Aleksey Shipilev wrote: > I would probably just go and declare the private compile-time constants. > This is safer, since: a) you are not at the mercy of optimizing compiler > anymore (have you tried the benchmark with C1?); b) the initializing > express

Re: JDK 9 RFR of 4477961: java.lang.Math.toDegrees(double) could be optimized

Hi Brian; I thought it was worth mentioning because I had had to deal with the underflow issue in the mapping software for the Audi/Stanford autonomous. For various reasons that system ends up with many very-tiny-but-non-zero quantities in it's mapping and heading component and I initially had

Re: JDK 9 RFR of 4477961: java.lang.Math.toDegrees(double) could be optimized

Hi Brian, Looks OK. On 09/23/2014 01:10 AM, Brian Burkhalter wrote: > Summary: Change constructs like “a * B / C” and “u / V * W” to “x * > (Y / Z)” where lower case denotes a variable and upper case a > constant. This forces the constant value (Y / Z) to be evaluated only > once per VM instance,

Re: JDK 9 RFR of 4477961: java.lang.Math.toDegrees(double) could be optimized

Indeed these considerations made me a little nervous about the change. For the edge cases which would have previously overflowed or underflowed this does not seem like a problem, i.e., to obtain a valid result where one would not have done before. For the cases in between however I suppose that

Re: JDK 9 RFR of 4477961: java.lang.Math.toDegrees(double) could be optimized

Looks fine. I think it is always important note when a change may result in different results for some inputs. I will reiterate for the record what's mentioned in the bug: > However, one caveat is that this may affect the results of some calculations. > For example, some range of numbers that u

JDK 9 RFR of 4477961: java.lang.Math.toDegrees(double) could be optimized

Hello, Another relatively small numerics fix: Issue: https://bugs.openjdk.java.net/browse/JDK-4477961 Webrev: http://cr.openjdk.java.net/~bpb/4477961/webrev.00/ Summary: Change constructs like “a * B / C” and “u / V * W” to “x * (Y / Z)” where lower case denotes a variable and upper case a con