Currently, rs.IsEllipse() finds not only closed ellipses, but also open ellipse segments (elliptical arcs) and circles and circular arcs… Methinks this is not useful/selective enough…
Of course, technically, a circle is a limit case of an ellipse, but practically, with these types of functions we are most often trying to find certain specific types of objects that are different from others. So the general mathematical case may not be the most useful for the user.
IMO rs.IsEllipse() should not include either circular arcs or circles.
As to open or closed elliptical arcs, that is a good question. We already differentiate between circular arcs and circles in both base Rhino and Rhinoscript. And base Rhino already differentiates between full ellipse objects and elliptical arcs in the description in Properties.
Therefore I think Rhinoscript should do the same. IsEllipse() should find only closed ellipse objects and IsEllipticalArc() - to be added - could find open ellipse arc segments.
All of the above is already possible in scripts with the addition of a line or two of code, so it is not a horrible problem, this request is just for more clarity and consistency among the various methods.
Yes, personally I think it is right that IsEllipse returns True for circles, and this should not be changed.
Assuming that all users want a technically incorrect answer because it is often used informally in that sense seems risky.
I agree though that having it distinguish between open and closed curves could be good.
I understand the basic math and I don’t want to upset the math purists, just seems bothersome to me, as long as there is a IsCircle() method, and the rhino object is called “Circle”, it should not be returned by IsEllipse() function. Rhino returns “Ellipse” for Ellipses on “what” and “Circle” on Circles. As long as that stands, IsEllipse() should make the same distinction in my mind. If Rhino would return “Ellipse” for a Circle object on “what”, then I see your point, but for now, it’s not.
Hmm, I see your point. I guess it comes down to whether the method is telling you if the object is of type ellipse, Vs whether it is geometrically an ellipse.
I was pretty sure someone would put forward that argument. While mathematically speaking of course a circle is a “limit case” of the family of ellipses, we are talking about practical scripting methods here. The IsSomething()... group of Rhinoscript methods are specifically designed to distinguish between different types of objects easily. Otherwise there is no need to have something like rs.IsCircle, or rs.IsArc - we should just all use rs.IsEllipse and test additionally for seeing if it really is a circle or an arc.
There is also the case of rs.IsPolyline which as implemented currently does not find lines, one can argue also that in fact it should include single line segments because that is a limit case of polyline with just two points. Fortunately it doesn’t adhere to the ‘purist’ philosophy in this case.
All circles are arcs, and all circles are ellipses, but not the other way around, so when you are interested in knowing if it is one of the particular subcases you can test for that directly. So IsCircle still has a use.
It’s just when you are interested in knowing that a curve is an ellipse but not a circle that you’d need to do 2 checks, which seems fine to me.
The official description for the IsEllipse method is
Test a curve to see if it can be represented by an ellipse within RhinoMath.ZeroTolerance
That is unambiguously true of a circle. I don’t think it’s just purist pedantry, and people may have written code reasonably expecting it to return true, and changing it could break things.
Surely we all agree that this should evaluate to true, even when a=b new Ellipse(Plane.WorldXY, a, b).ToNurbsCurve().IsEllipse()
As for polyline, I think that’s a little more debatable. You could take the view that the poly part means >1 segment, or you could say that since the constructor for Polyline works even on a list of just 2 points then a single segment is still a polyline. Anyway, I wouldn’t argue for changing how IsPolyline works now.