QCAD Bugtracker

Attached to Project: QCAD Bugtracker
Opened by CVH - 21.03.2026
Last edited by CVH - 22.03.2026

Andrew,

Concerning commit: https://github.com/qcad/qcad/commit/73a3b141bbe7438f36adad7219545e7b85d4304f

The sane number limits within -1e+12 to 1e+12 are removed.
RMath::isSane(value) is now reduced to an analog of RMath::isNormal(value).

This means that every numeric value except NAN and +/-INF is normal AND sane.
About sure that I can give counter indications of that.

I do not consider the used coordinate values as sane.
Please explain why we should support things in real world size
(A chair, about 500 by 500mm)
placed at X = 3440898387387.5750mm (+/-1ULP is about +/-0.0005mm)
and Y = 15219137016394.785mm (+/-1ULP is about +/-0.002mm)
While the longest distance on Earth is about 40075017000mm.
Or about and less than 1/100 of those in the drawing file.

The origin of these insane values is probably:
"A metric unit represents one point (1/72 inch)"
"Divide the metric value by 185771 for mm"
Then the coordinates are about 84 and 82 km from some reference point.
Instead of about 8-9 times the distance to the Moon.

But that won't hold because the page border is 42000 by 29702mm.
Almost exactly A3 scaled up 100 times and used in scale 2.00.
The file data is probably edited in multiple applications.

---

---

Allowing larger numbers is one.
But why is this suddenly associated with shorter (not smaller) Arc segments?
And also with longer Arc segments.

Shorter Arc segments has always been problem.
Even when far over the common RS::AngleTolerance (Not PointTolerance).
Polyline Arc segments are considered to be straight with a bulge of less than 1e-6.
atan(0.000001)*4 = 3.9999999999986666e-6 rad
… Not the end of the story … The chord between the two vertices must be over 1e-6 long.
Otherwise the chord has always an undefined orientation equal to zero.
The center is then limited to vertically up/down from the midpoint.

The biggest flaw sits in 'Longer Arc segments'

        if (ret > 2 * M_PI - 1.0e-16) {
            ret = 0.0;
        }

IMHO, 6.283185307179586 minus 1e-16 remains 6.283185307179586
Meaning that you can subtract 1e-16 from 2Pi several times over and still end up with 2Pi.
2Pi - 1e-16 - 1e-16 - 1e-16 - 1e-16 - 1e-16 === 2Pi

1ULP of 2Pi is 8.881784197001252e-16
Subtracting about half of that would have an influence on the LSB by binary rounding.
2Pi - 5e-16 = 6.283185307179585
All depends on the rounding scheme.

As 'FIXED' a near a full circular Arc is now 2Pi or more and not a fraction less.

---

---

The so-called 'FIXES' are only applied in RArc::getAngleLength
Checking for near zero rad or near 2Pi occurs at various places.

---

---

Since some time my near 2Pi limit is defined as 6.283185307179584.
Based on a survey that DXF records values ending in 179586 or 1795862.
(The 2 is a flaw, 4 or 5 is expected)

Also defined 2Pi as 6.28318530717958647692528676655900577
(36 digits, analog to RMath)

QCAD code is riddled with the multiplication of Pi times 2 and the division by 2.
RMath specifies M_PI, M_PI_2 and M_PI_4 (36 digits) but JS and C++ may still use derivatives of Pi.

It is a bit faster with various well defined (and effectively used) constants.
A JS equation must be translated, evaluated, passed on to C++ and the result back.
Even if that is merely a binary exponent shift.

Regards,
CVH