QCAD.org Forum

It seem that I need to address this issue as a new topic with a newly created example file.

Related to FS#2693, follow up of FS#2685
Related to post 48576
Related to Ellipse Arc length (post 48990) and what the intended length is ( topic 11887)


In the attached example drawing using the latest stable QCAD release 3.32.4:
- Try removing segment A with D2 ... Undo (OO)
- Try removing segment B with D2 ... Undo (OO)

This doesn't remove only the segments A or B, the action removes the ellipse completely.
Functional for segments C or D.

The workaround would be using B2:
- Indicate the ellipse.
- Indicate 2 intersection points for A or B.
- Indicate the segment A or B to remove.

- - - - - - - - -

Using D2 makes more sense in this case.
It is much less work and there is less chance of making mistakes.
But it fails for start or end parameter equal to 180°(Pi rads).

The reason for this is that the shape left after trimming with D2 has no defined length.

Let's create this so-called 'invalid' shape in a different way...

Revert to the drawing as given:
- Auto Trim (AX) segment A or B.
- Cancel the tool (R-Click).
- Select the remaining segment, its length is approximately 5.53593457 units.
- In the Property Editor set Reversed to 'Yes'.

This is the intended shape after trimming with D2, its length is NaN and therefore not created as result.

The estimated(*) length should be 48.4422411027384 - 5.53593457(*) ≈ 42.90630653...(*)
42.90631933 is fair enough ...
... The estimation can be enhanced with a good full (or 1/2 or 1/4) ellipse length and only estimating the flatter parts.

For the record, the near exact length using elliptic integrals is:
42.9063062975608


Hoping that this is more clear now and that the reported bug may be solved soon.
Regards,
CVH

Making progress ...

As already pointed out in April, 2024, 17 months ago, in a comment on the bug report FS#2565:

The a1<a2 branch has a non-strict inequality allowing for Pi.
Some non-strict inequalities should be implemented for the second branch.

In REllipse::getLength():

For the second branch where a1 is not strictly smaller than a2 while they can't be equal at this point.
In essence meaning: Where a1 is definitely larger than a2.

Current line 564 should read: Also allowing that the end parameter angle a2 is equal to Pi or 180°.
The returned length is then: L(start..360) + L(0..end)

Current line 567 remains AS IS: Only the condition for a2 is the opposite from the above.
Together they form the a1>M_PI branch and can be simplified as such.
The returned length is then: L(start..360) + half ellipse + L(180..end)

Current line 570 should read: Now the condition for a1 is the opposite from the above two combinations, also allowing a1 = Pi or 180°.
The condition for a2 is strict because it must be smaller than a1 even when a1 is Pi.
Also ruling out the fourth combination of the 2 comparisons.
The returned length is then: L(start..180) + half ellipse + L(0..end)


This would fix the problem of returning NaN when none of the former 3 boolean combinations resolved to true ...
... Returning at least a valid number value ...

However, the returned results are not so great in all cases.



- = - = - = - = 20 intervals is not the answer, it was an example = - = - = - = -

REllipse.getSimpsonLength(a1, a2) estimates the ellipse arc length based on the 'Composite Simpson's 1/3 rule'.
In the same article one can read how to determine the number of intervals for a desired accuracy.
As per given example: 22 intervals for integrating sin(x) from zero to Pi to within 1e-5 in absolute.
Other sources may also tend to promote a fixed number of 20 or so intervals in their examples.
The implementation in QCAD uses 20 intervals as in these examples.

Remark that this is only to keep the example simple.
Other examples exits, this site uses the same technique with 1000 intervals but the accuracy is (very) limited.

• We are not integrating a simple sin(x) function.
  Lower and upper bound are not zero and Pi per definition.
  One can overdo it, attempting to chain-sum a vast amount of (much too) small values using floating point.
  About 8 of 16 significant digits would be nice, the more the better.
  ...
  ..
  .

Also, QCAD uses the same number of 20 intervals for estimating any ellipse arc up to 1/2 full ellipse.
Disregarding it is less than 0-Pi/2 or beyond.
Then an estimation for 0-Pi or Pi-2Pi uses much coarser intervals to integrate.
The result should not degenerate because of the case or because of adding a half ellipse length.

Turns out that the ideal number of intervals is highly exponential ... To start with.
Similar to the eccentricity of an ellipse.

For integrating an ellipse arc from zero to Pi/2 its length, I came up with a rule of thumb that returns rather correct values:

• Even n intervals = 2 * floor(7.7 / ratio) where the ratio is the minor radius over the major radius.
  A simplified version of the function for a fitted curve on a list of almost ideal numbers of intervals vs ratios.

For a ratio of 0.75 or over the number of intervals would be 20 and as low as 14.
What is fine for the orbit of planets in a solar system for example ... The major field of interest ...
... We tend to draw different kinds of ellipses.

• Ratio = 0.50 >> 30 intervals.
  Ratio = 0.35 >> 44 intervals.
  Ratio = 0.20 >> 76 intervals.
  Ratio = 0.10 >> 154 intervals.
  Ratio = 0.05 >> 308 intervals.
  Ratio = 0.01 >> 1054 intervals.
  Beyond that the ellipse starts to look more like a line going back and forth.

Hits and misses:
A) While the rule of thumb is 'the solution' for estimating the length of a quarter, a half or a full ellipse very precise.
It doesn't holds for estimating the length of an arbitrary ellipse arc.
The number of intervals doesn't decrease, it get bigger, unpredictable bigger.

B) Beyond a few hundreds or so intervals, the computational effort is simply too large, especially if this concerns an entity property.


The only solution I see is to implement elliptic integrals of the first and second kind as I did.
Coding the Math in not that hard and it is not really demanding compared with 2-3 calls to the REllipse.getSimpsonLength(a1, a2) function
Limited to 20 intervals itself already:
21 cosine, 21 sine, 21 square root, 42 squares, 19 modulo operation, 2 divisions, 106 multiplications, 84 addition/subtractions, 40 if-else, 61 comparisons, 87 assignments

An example can be found in the old but legendary Cephes Math Library, available under a '3-clause BSD license'.
Phyton SciPy and others includes this just the same, also see https://www.npmjs.com/package/cephes.

Translation to JS under QCAD posed some unexpected and hard to figure out specialties ...
It was very instructive to see how badly things go for ellipse eccentricities from 0.66 up to 1.0 or ratios below 0.75 and towards zero.

Regards,
CVH

Thank you Andrew.

This should be fixed in an upcoming release.
See related commit

Regards,
CVH