FS#2700 - RMath.getAngleDifference does not revert to zero when almost circular
Andrew,
Probably not OS or QCAD version related.
Similar resources evaluate near 2Pi or over as zero.
if (ret >= 2*M_PI - RS::AngleTolerance) {
ret = 0.0;
}
Other like getAngleDifference do not.
Then it is at least equal or over.
double RMath::getAngleDifference(double a1, double a2) {
double ret;
if (a1 >= a2) {
a2 += 2*M_PI;
}
ret = a2 - a1;
if (ret >= 2*M_PI) {
ret = 0.0;
}
return ret;
In this forum topic I gave an example where:
- A slightly deformed bulge factor -0.4142135623730875
and not -0.4142135623730950 (-90°).
- So that the start angle becomes 1.5707963267948708
and not Pi/2 or 1.5707963267948966 as intended.
- So that ret = 6.2831853071795479
or only 3.85769e-14 (about 45 ULP) less than 2Pi
Returning an Arc length form start that is (almost) the full circumference of a circle.
While expecting zero because the point in question almost coincides with the begin.
Fine when you are merely using getAngleDifference() locally and can guard for that.
By comparing a position with an Arc ending based on RVector.equalsFuzzy()
But in the case at hand we use RPolyline.getDistancesFromStart() extensively.
The flaw can only be circumvented by replacing this resource in JS code.
The typical solution for our problem is using the first returned distance for cropping ...
... Disregarding the other returned distances ...
... If we can rely on that the first is equally valid as the rest ...
The example proves otherwise.
Next hurdle are more than two distances from the start of a Polyline. 
Regards,
CVH
Some additional notes:
The used pattern has 2 endless horizontal lines.
One in the zero degree direction alternated with one in the 180 degrees direction.
An early flaw was to deduct the orientation of a Hatch-segment on zero degrees or not.
It seems there are segments returned by the Hatch engine in the 360 degrees direction.
Somewhere in the midst of RHatchData::getPainterPaths segments in the zero degree direction are re-oriented to the +/-2Pi direction.
Comparing needs to be fuzzy based on RS.AngleTolerance because:
'=== 0.0', '=== Math.PI' or '=== 2*Math.PI'
won't hold for all perfectly horizontal Hatch-segments.
Not a issue on its own but it proves that 'nearly' zero may also be 'nearly' 2PI.
I also see the disadvantage for this most basic RMath function.
You won't be able to calculate the delta angle between 'nearly' 2Pi and 2Pi.
But I see resources that figure that out without the use of getAngleDifference.
Regards,
CVH