You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
However, this causes some really weird behavior with certain pairs of complex numbers where they will rotate the long way around.
For instance, if you slerp() from e^(-3pi/4) to e^(3pi/4), this code will interpolate the angle counter clockwise from -135° to 135° even though going clockwise is the shorter path.
use std::f64::consts::PI;let c1 = UnitComplex::new( -135.0f64.to_radians());let c2 = UnitComplex::new(135.0f64.to_radians());// left = Complex { re: 1.0, im: 0.0 }// right = Complex { re: -1.0, im: 1.2246467991473532e-16 }assert_relative_eq!(c1.slerp(&c2, 0.5), UnitComplex::new(PI), epsilon=2e-10);
Of course, do say so if this is intended, but I would imagine going clockwise here would be the more natural choice?
The text was updated successfully, but these errors were encountered:
jsmith628
added a commit
to jsmith628/nalgebra
that referenced
this issue
Mar 21, 2022
So I was poking through the code for rotational interpolation, and I saw the definition for
slerp()
forUnitComplex
wasHowever, this causes some really weird behavior with certain pairs of complex numbers where they will rotate the long way around.
For instance, if you
slerp()
from e^(-3pi/4) to e^(3pi/4), this code will interpolate the angle counter clockwise from -135° to 135° even though going clockwise is the shorter path.Of course, do say so if this is intended, but I would imagine going clockwise here would be the more natural choice?
The text was updated successfully, but these errors were encountered: