#533 ELLIPSEARC and ELLIPSEARC2 angle issues

[Eugène Schifflers]

Both ELLIPSEARC and ELLIPSEARC2 functions do not seem to interpret the first argument correctely (angle). This argument is, in both cases the angle swept, but it is blatently not correct in the resulting drawing: for arcs near the end of the major axis, the length is too short, and for arcs near the minor axis, the length is too long.
It looks as if instead of sweeping the required angle, it sweeps by an amount such that the surface area swept is, as a fraction of the total area of the ellipse, the same as the ratio angle/360. For example, if the required angle is 36 degrees, it will not sweep 36 degrees, but it will sweep an angle such that the area of swept inside the ellipse is 1/10 of the total ellipse area.

This would explain other previously reported bugs, and explain why it does work with 90 and multiples of 90.

[DanielAjoy]

for arcs near the end of the major axis, the length is too short, and for arcs near the minor axis, the length is too long.

please give a concrete example.

[Eugène Schifflers]

Hello and sorry for the late reply. I hardly ever use this account. Here is
a concrete example below :

to bug
cs
pu home pd
ellipsearc 60 100 200 0
ellipsearc 60 200 100 0
end

Both ellipsearc functions should sweep the same angle (60 degrees), but the
result I get is this :

[image: image.png]

It is quite obvious that the angles swept are different. If they were the
same, the left-hand ends of the ellipse arcs and the turtle would be
aligned, as are the starting ends. It seems to me (I did not actually
measure) that the surfaces swept are the same. If you add the following
three lines in the program :

setpencolor 2
ellipsearc 60 100 100 0
ellipsearc 60 200 200 0

the problem is even more obvious. The above are just circle arcs, and the
angle swept is correct.

I hope that helps! Thanks.

Le mar. 20 août 2019 à 21:08, DanielAjoy danielajoy@users.sourceforge.net
a écrit :

for arcs near the end of the major axis, the length is too short, and for
arcs near the minor axis, the length is too long.

please give a concrete example.

• [bugs:#533] https://sourceforge.net/p/fmslogo/bugs/533/ ELLIPSEARC and
  ELLIPSEARC2 angle issues*

Status: open
Group: v_6.06x
Created: Thu Aug 15, 2019 10:48 AM UTC by Eugène Schifflers
Last Updated: Thu Aug 15, 2019 10:48 AM UTC
Owner: nobody

Both ELLIPSEARC and ELLIPSEARC2 functions do not seem to interpret the
first argument correctely (angle). This argument is, in both cases the
angle swept, but it is blatently not correct in the resulting drawing: for
arcs near the end of the major axis, the length is too short, and for arcs
near the minor axis, the length is too long.
It looks as if instead of sweeping the required angle, it sweeps by an
amount such that the surface area swept is, as a fraction of the total area
of the ellipse, the same as the ratio angle/360. For example, if the
required angle is 36 degrees, it will not sweep 36 degrees, but it will
sweep an angle such that the area of swept inside the ellipse is 1/10 of
the total ellipse area.

This would explain other previously reported bugs, and explain why it does
work with 90 and multiples of 90.

---

Sent from sourceforge.net because you indicated interest in
https://sourceforge.net/p/fmslogo/bugs/533/

To unsubscribe from further messages, please visit
https://sourceforge.net/auth/subscriptions/

[David Costanzo]

It took a few days, but I understand what ELLIPSEARC is doing. I think you are correct in your equal area hypothesis. As you probably know, the code in FMSLogo was copied from MSWLogo, which was copied from UCBLogo. However, UCBLogo only had ARC (arc of a circle) where the major/minor axis have the same length. MSWLogo generalized this to support ellipses, but incorrectly.

ELLIPSEARC first mentally calculates the points on an ellipse in the way you'd find in a math textbook, with the major axis along the x-axis and the minor axis along the y-axis. It determines which segment of the ellipse to draw in this orientation using the standard parameterized equation for an ellipse.

(x,y) = (a cos(t), b sin(t)), for 0 degrees <= t <= 360 degrees

Then it rotates the ellipse to the turtle's heading. Then it translates the ellipse to the turtle's position.

The problem is that the parametrized equation does not sweep equal distances for equal increments of t. This can be visualized in two ways.

First, consider a circle cut into 12 equal segments and an ellipse.

cs
setpc 0
circle 100
repeat 12 [ fd 200 bk 200 rt 30 ]
repeat 12 [ ellipsearc 30 100 200 30*(repcount-1) setpc repcount ]

Observe that the points where the circle is 12-sected have the same X coordinate as where the segments of the ellipse change color. This shows that angle cacluation is done on the circle, then the circle is elongated into an ellipse.

Another way to visualize it is to look at the distance (or time) it takes to trace 1 "pseudo-degree" with ELLIPSEARC.

repeat 360 [ setpc repcount ellipsearc 1 50 400 repcount wait 1]

Even if you can't see it by time, you can zoom in and see that the color segments near the top and bottom are about 1 pixel and the ones near the middle are 5-6px.

Although I haven't found or come up with a proof that this is mathematically equivalent to saying that ELLIPSEARC sweeps equal areas, Wikipedia says that "t" in the standard parametrized equation is the "eccentric anomoly" which defines an orbital position in a Kepler orbit. I haven't found an easy reduction from the standard parametric equation to Kepler's second law, but I'd be interested if someone can provide a straight-forward proof.

[David Costanzo]

I have a fix for this. It's strange, but the fixed behavior feels worse. Consider some code that draws an dashed ellipse in 10 degree lengths.

REPEAT 18 [ ELLIPSEARC 10 200 50 REPCOUNT*20 ]

With the fix, the dashes have a much more varied length.

I've attached some screenshots:

buggy-ellipsearc.png - the dashed ellipse, drawn with the buggy FMSLogo 7.7.0.
fixed-ellipsearc.png ** - the dashed ellipse, drawn with the fix.
fixed.png ** - Eugène Schifflers's "concrete example", drawn with the fix.

[David Costanzo]

I've committed the fix as [r5396]. This fix will be release as part of FMSLogo 8.0.0.

This obviously changes behavior when the angles are not multiples of 90 degrees. I tried to retain compatiability for the other MSWLogo behavior (negative angles, angles >360, 0 lengths, negative lengths). There were more special cases than I would have thought, so I might have missed something. If anyone wants to test this before it is released, post a message here and I'll upload a pre-release version of 8.0.0.