Can an arc be greater than 360 degrees or less than 0 degrees.

Question

Can an arc be greater than 360 degrees or less than 0 degrees? Is the (angular) arc length a signed scalar?

I'm creating a Graphics and basic geometry software library. I believe an arc can be defined by 5 scalars, the x and y components of the start point, the x and y components of the centre point and the signed value of the rotation. However I'm concerned that this data definition could lead to unnecessary rounding errors on the end point of the arc, the precise value of which is generally of greater concern than the precise value of the arc's centre point. So I'm leaning towards defining arcs by the 6 scalar definition of the start point, the end point, and the mid point of the circumference of the arc. This data definition has the added advantage that you don't have to worry about reflections, but would exclude arcs of greater than 360 degrees. Is this mathematically sound?

A successful software library will get used in ways unimagined by the library authors. So this where I place a strong priority or weighting on following mathematical definitions, because those more rigorous,robust and tried and tested definitions can hopefully pre-empt problems further down the road.

Answer 1

So I think the issue here is the difference between an angular position and an angular displacement. The suggested What is the exact and precise definition of an ANGLE? triggered me to towards What is the difference between a point and a vector?. Prior to this I had been using the same class to represent 2 dimensional points and 2 dimensional vectors with the same class. I'm now separating them. In the same way that 2 o'clock is not the same thing as 2 hours duration. While you can kind get away with it with points, you can't with angles.

An angular position of -10 degrees is equal to an angular position of 350 degrees. But an angular rotation of -10 degrees is not equal to an angular rotation of 350 degrees.

So I think the answer is that I need separate classes for angles and rotations.

Answer 2

The first definition sounds more natural to me. You are speaking too roughly here so it's hard to tell what issues you're foreseeing with it. Of course the 2nd definition is also valid i.e. is minimal and is sufficient to define that arc.

In math in principle an arc can be greater that 360 degrees or negative but for practical purposes probably you don't need such arcs. It depends on the goals of that library you're developing.

Answer 3

Heading

Circular arc case: You can define the arc using the $5$-tuple $\langle x_c, y_c, r, \theta_1, \theta_2\rangle$ where $(x_c,y_c)$ is the cartesian coordinate of the arc center, $r$ is the radius of the arc, $\theta_1$ is the start angle and $\theta_2$ is the end angle. Angles are measured in either degrees or radians and we follow the convention of counterclockwise angles as positive and clockwise angles as negative.

One optional normalization that you can perform in your routines, based on use cases of your library is to reduce the angles to the range $[0,2\pi)$ or $[-\pi, +\pi]$ radians.

If you want to avoid mixing cartesian and polar coordinates in the tuple representation, you can convert $(x_c,y_c)$ also into $(r_c,\theta_c)$ polar form so that you have $\langle r_c, \theta_c, r, \theta_1, \theta_2\rangle$.

Elliptical Arc case: The above works for circular arcs. If you need elliptical arc also to be covered, you need to specify the focal point (instead of center of circle), $r_s, r_e$ that measure the length of the line segments from the focus to the end points of the arc and the angles of the line segments relative to an axis.

If you prefer cartesian coordinates, then the $6$-tuple is $\langle x_f, y_f, x_s, y_s, x_e, y_e \rangle$ where $(x_f,y_f)$ is the focus, $(x_s,y_s), (x_e,y_e)$ are the start and end point of the arc respectively. You only need one other $x$ coordinate $x_m$ to differentiate between the reflections. So, the $7$-tuple becomes $\langle x_f, y_f, x_s, y_s, x_e, y_e, x_m \rangle$. You can calculate $y_m$ from the equation of the ellipse. If you want to avoid the performance penalty of calculation, you can store a redundant $y_m$ as well making an $8$-tuple $\langle x_f, y_f, x_s, y_s, x_e, y_e, x_m, y_m \rangle$ for the general elliptical arc.

Whether you want to treat circles and ellipses separately depends on other considerations such as the primary use of your library. Separate representations help with compact data representations for different use cases while complicating handling of the data. This decision is purely dependent on what makes sense for the primary uses of your library.

A good library should provide helper methods to convert from one representation to another for commonly used representations.