FS#2635 - RVector::rotate(rotation) should not attempt to rotate with zero rads.
Andrew,
A minute flaw (may) occurs when we rotate an RVector by zero rads around (0, 0).
rotate() is based on: The magnitude, getAngle(), cos() and sin()
getAngle() is based on: The magnitude, a dot product, divisions and acos()
getMagnitude2D() is the hypotenuse and based on sqrt()
These functions all have some degree of error.
Accumulated and reflected in the returned RVector while that should remain steady.
I then propose that the initial test also verifies isZero.
/**
* Rotates this vector around 0/0 by the given angle.
*/
RVector RVector::rotate(double rotation) {
if (!valid || rotation == 0.0) {
return *this;
}
double r = getMagnitude2D();
double a = getAngle() + rotation;
x = cos(a) * r;
y = sin(a) * r;
return *this;
}
The extra cost is an OR clause and an equality test.
I suppose that this is not a major hurdle.
Comparing with NaN is always false.
As expected, rotating with an angle value NaN gives x=y=NaN.
Neither z, nor the valid flag are affected.
The resulting vector is considered to be valid.
Eventually x=y=NaN will fail somewhere else.
Returning NaN for any calculation with x and/or y.
For now ...
The workaround is to verify it yourself for all RVector rotations that occur in a script:
// For all in the nature of:
pos.rotate(angle);
// Replace code with:
if (angle !== 0.0) {
pos.rotate(angle);
}
What is more costly because ‘angle’ can be the inline result of an equation.
That must then be store in a variable or calculated twice.
In many cases we are not able to fix it. For example:
- Rotating RVector’s forth and back is rather common in various REllipse resources.
With the major axis and major point aligned with +X that serves no use ...
... But the things do shift.
As key resource the issue is not at all limited to ellipse methods only.
Regards,
CVH