[x] I added an entry to CHANGES.md if knowledge of this change could be valuable to users.
Two Regressions. One minor & One Major
When solving the direct problem, bad values f64::INFINITE & f64::NAN won't result in the output being 0, only extremely close to 0. Not really worried about this, sort of falls in the case of "garbage in, garbage out".
1/50k of the GeodTest.dat cases fails 😱 (by 6.9e-7 the % error is 3e-12). This (AFAIT) comes down to quadrant normalization. It down is seems that sincosd differs from .to_radians().sin_cos() by ~1e-16 when dealing with values extremely close to +/-180°.
In my local testing
It is amusing at the atan2 of the 2 values is correct to within e-16, but just not the sin/cos.
Technically a regression, by nearly the smallest order (I'm not joking, there are only 2 64bit floating point values between the two results). I'll let project management judge if that is deal breaking.
valarauca
commented
9 months ago
As a side effect also remove fmod (as now it is deadcode)
CHANGES.mdif knowledge of this change could be valuable to users.Two Regressions. One minor & One Major
When solving the direct problem, bad values
f64::INFINITE&f64::NANwon't result in the output being0, only extremely close to0. Not really worried about this, sort of falls in the case of "garbage in, garbage out".1/50k of the GeodTest.dat cases fails 😱 (by 6.9e-7 the % error is 3e-12). This (AFAIT) comes down to quadrant normalization. It down is seems that
sincosddiffers from.to_radians().sin_cos()by~1e-16when dealing with values extremely close to +/-180°.In my local testing
It is amusing at the
atan2of the 2 values is correct to withine-16, but just not the sin/cos.Technically a regression, by nearly the smallest order (I'm not joking, there are only 2 64bit floating point values between the two results). I'll let project management judge if that is deal breaking.