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 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.
Mike On Sep 22 2014, at 14:41 , Brian Burkhalter <brian.burkhal...@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. > > Brian > > On Sep 22, 2014, at 2:24 PM, Mike Duigou <mike.dui...@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. >
