Nicely summarized by an AI:
Comparing two floating-point values within a tolerance is NOT
the same as comparing their squared values within the squared tolerance.
Squaring changes the scale of values and the distance between them.
This breaks the linear logic used in standard tolerance checks, especially for values near zero or larger values.
Why These Methods Are Not Equal:
- Different scaling near zero:
If a = 0.1 and b = 0.2, their absolute difference is 0.1.
Their squared values are 0.01 and 0.04, with a difference of 0.03 (three times smaller).
- Different scaling for large values:
If a = 1000.1 and b = 1000.2, their difference is 0.1,
but their squared values differ by about 200 (2000 times larger).
- Tolerance distortion:
A linear tolerance epsilon allows a fixed window [a-epsilon < b < a+epsilon]. Squaring maps this to a non-linear, asymmetric range that grows much faster for larger base values.
When It Fails:
- Small values (<±1):
The squared difference becomes much smaller than the linear difference.
A tolerance that passes linear values might fail squared values.
- Larger values (>±1):
The squared difference becomes much larger than the linear difference.
A tolerance that passes linear values will likely fail squared values.
- Negative values: Squaring loses the sign.
If (a = -1.001) and (b = 1.001), they are far apart linearly,
but their squared values are nearly identical (1.002 vs 1.002).
Recently implemented at various places in QCAD.
For example to compare a distance in XY with a value within tolerance avoiding the
sqrt() for the vector magnitude.
Where the distance d = sqrt(dX²+dY²+dZ²) is compared with a positive value v within a small tolerance (e.g. RS.PointTolerance = 1e-9)
Including dZ because there is no 2D variant for RVector::getSquaredMagnitude().
Or for example where the squared distance is calulated in direct as dSqr = dX²+dY².
Typically worked out as fabs(d - v) < 1e-9 (analog of RMath.fuzzyCompare).
What results in fabs(sqrt(dX²+dY²) - v) < 1e-9.
And then falsely replaced by fabs(dX²+dY² - v²) < 1e-9*1e-9
Or comparing a difference to within 1e-18.
In the case of larger numbers (>1):
Subtracting 2 much larger but near equal values with no more than 17 significant digits.
Also algebraically incorrect ! …
Squaring both sides of (|d - v| < tol) to exploit d² instead of d results in: ((d - v)² < tol²)
And this expands to: (d² - 2dv + v² < tol²) where the root d is still present.
(fabs(d - v) < tol) is already a reduction of a window comparison: (d > v-tol && d < v+tol)
At best, avoiding the subtraction of a small value in floating point: (d+tol > v && d < v+tol)
We then also avoid digit cancellation when subtracting larger values in fabs(d - v).
But squaring this also leads to ((d+tol)² > v²) or (d²+2*d*tol+tol² > v²) for the first test.
With the initial window comparison:
Squaring (d > v-tol && d < v+tol) results in: (d² > (v-tol)² && d² < (v+tol)²)
In wich we can replace d² and the intended value v ≈ sqrt(d²) to compare with:
(dSqr=dX²+dY² > (v-tol)² && dSqr=dX²+dY² < (v+tol)²)
This may fail when (d == v).
And always when tol is too small to be added or subtracted in floating-point.
When comparing (squared) values within a small tolerance we must thus include equality:
if (dSqr >= (v-tol)*(v-tol) && dSqr <= (v+tol)*(v+tol)) {...}
Programmatically more complex …
… and perhaps no longer a faster method than taking the root.
The second test is skipped when the first is true.
It certainly avoids the absurd comparison with 1e-18.
Because that is mostly true for real near equal distances.
Regards,
CVH
If a given point p is on the major axis then REllipse::getVectorTo(p) returns one of the major points. In the code this is handled as a special case when the point is in-line (collinear) with the major axis.
This is only correct for points outside the evolute.
On the major axis is defined by getAngle().
This may fail for a magnitude equal to or less than 1e-6.
A point that close to the center should not have a single solution at zero degrees.
The correct solutions are:
- If p is equal to the center ⇒ Two vectors to the two minor points.
- On the major axis and strictly inside the evolute ⇒ Two mirrored vectors.
- On the major axis and on or outside the evolute ⇒ The nearest major point.
- On the minor axis ⇒ The nearest minor point.
An additional problem is now what to return on a duality with full ellipses.
Or for an ellipse arc where both of two results are valid.
getVectorTo() typically returns but one unique result.
For example:
RCircle::getVectorTo(p) returns an invalid vector when the point is near the center.
Then there are an unlimited number of solutions.
Further discovered that the point related to the returned vector may fail x²/a²+y²/b²=1
Although almost on the ellipse within 2.299e-10 … f(x,y) may return 9.5310
This example would fail REllipse::contains while the border is considered as inside.
Meanwhile implemented a 'simple method' to find the nearest point(s) on an ellipse.
Fast converging in 3 steps, no trigs and very accurate, about 24 lines of code.
f(x,y) returns mostly 1.000 with so far:
- a minimum of 0.9999999999999997
- a maximum of 1.0000000000000007.
In other words, it is only off for the last meaningful decimal digit.
With this all methods that are based on REllipse::getVectorTo(p) can be implemented very reliable with tolerance, border flag, … and so on.
By default the normal for a point is given with high accuracy and a tangent is that rotated.
… ..
.
Regards,
CVH
I see a similar behavior from the Drawing Preferences, with respect to Printing - Page.
I didn't start noticing this behavior until I changed my computer to an M4 based Mac Mini running Tahoe. With that change, I started using the ARM based version of QCAD. So, I'm wondering if the problem is ARM based rather than on other operating systems, including Intel based Macs, like my previous one.
]]>
In RCircle::getDistanceTo
getDistanceTo2D is based on getMagnitude2D().
This should be compared with RS.PointTolerance (1e-9), not squared (1e-18).
! ! !
Only true in an arbitrary (unlimited) precision.
The method using the magnitude or the squared magnitude cannot be compared in floating point.
The squared magnitude will hardly ever have a meaningful 18th digit after the comma.
As it is the subtraction of the vector components with no more than 17 significant digits.
A method missing here is RVector::getSquaredMagnitude2D() avoiding + 0.0*0.0 for dz²
Here you use a circular tolerance area in 2D: Less than 1e-9 away in any 2D direction.
Or a spherical tolerance in 3D.
Positions are typically compared using an axis aligned square shape as tolerance range in 2D (RVector::equalsFuzzy2D) or a cubic box in 3D (RVector::equalsFuzzy):
Less than 1e-9 to 1.414214e-9 away in any 2D direction
Or less than 1e-9 to 1.732051e-9 away in 3D.
40 to 70% more tolerant depending 2 or 3D and the direction.
Regards,
CVH
PS:
I can start a comment on GitHub like before but that is no longer accepting inputs.
Claude included major/minor swapping in REllipse::getVectorTo().
This is an existent resource and already used in most cases.
I never encountered a major radius less than the minor but it is plausible.
For a ratio over 1.0, correctMajorMinor() caches the minor point (Line 1205).
Sets a corrected ratio (Line 1206).
And then it sets the major point using REllipse::setMajorPoint() (Line 1207).
setMajorPoint() calls REllipse::correctMajorMinor() again.
This time the ratio is less than 1.0 and nothing is altered.
Because correctMajorMinor() is setting things straight it can simply update
the public attributes: 'ratio', 'majorPoint', 'startParam' and 'endParam' in this order.
correctMajorMinor() is typically called for:
- The valid REllipse constructor.
- When setting the REllipse major point, the ratio
and thus also when setting the minor point.
- When setting the properties of an REllipseEntity.
There is a second analog to REllipse::correctMajorMinor().
The method REllipse::switchMajorMinor() does practically the same but then based on an external test.
In open source only used in RShape::getIntersectionPointsEE (Line 1275 and 1279).
Then called when the major radius is less than the minor radius.
The main difference is that it is skipped when the ratio is less than 1e-9.
fabs(ratio) in line 314 is odd because a negative ratio is invalid … Not rendered.
switchMajorMinor() triggers correctMajorMinor() twice.
It first set the major point equal to the minor point based on the former ratio.
This triggers correctMajorMinor().
Then it sets the reciprocal of the ratio.
This also triggers correctMajorMinor().
switchMajorMinor() can also update the public attributes in direct.
For the record: REllipse::getTangents also swaps major/minor in direct when the point is on the minor axis. This method handles an ellipse as full and doesn't correct end parameters.
Regards,
CVH
Layer is not frozen.
See also:
https://forum.qcad.org/t/manage-viewport-layers-not-persisting-save-and-reopen/11902