JDK 9 RFR of 4477961: java.lang.Math.toDegrees(double) could be optimized
mike.duigou at oracle.com
Mon Sep 22 21:48:25 UTC 2014
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 trouble matching results against the Matlab implementation. Since I had to also reduce quantities to -π < x <= π and -180 < x <= 180 I combined the reduce and convert using an approach similar to this revised implementation.
On Sep 22 2014, at 14:41 , Brian Burkhalter <brian.burkhalter at oracle.com> wrote:
> 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 there will be some numerical inconsistencies between the two versions.
> On Sep 22, 2014, at 2:24 PM, Mike Duigou <mike.duigou at oracle.com> wrote:
>> 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 used to overflow to infinity by
>>> performing the multiplication by 180, will now not overflow and will return a
>>> valid result.
>> This also applies to very small quantities in toRadians where dividing by 180 may have previously resulted in a zero.
More information about the core-libs-dev