Talk:Circle–ellipse problem

An easy solution

The solutions currently posted in the article do not include the following: use more than one class of circles.

· Define the class Ellipse as superclass of two classes for circle as follows.

· Define the class EssentialCircle (or just Circle) as subclass of Ellipse. Use it when its parameters can never be changed in such a way that the objects of this class would cease to comply with the requisites of representing circles.

· Define the class AccidentalCircle as subclass of Ellipse. Use it when a change of parameters might make the object a non-circle. That is: the object is created as an ellipse, of class Ellipse; the object is also an object of class AccidentalCircle only if its parameters allow it to be a circle (for example, equal axes). For instance, interrogate the object through Ellipse method(s) to learn whether AccidentalCircle methods can be used on it. Alternatively, create the object as an AccidentalCircle but provide a method to interrogate whether it continues to be a circle before using other circle methods.

What do you think of this?

Note: I cannot give any references to this solution because it just occurred to me. Kurt Artindagi (talk) 10:48, 7 April 2014 (UTC)

Circle is an ellipse indeed

In 'Possible solutions -> The "IS"-Test' is stated, that a circle IS not an ellipse. Mathematically this is not correct at all and there is no other criterion (named 'IS' specifically as opposed to 'is') given. Can somebody correct this (or me)? Antsan (talk) 20:41, 14 April 2011 (UTC)

An anti-pattern?

PJTraill 06:06, 23 January 2007 (UTC) I see you, User:EngineerScotty, have removed my assertion that it is an anti-pattern. Is that because you disagree, or because it is not generally said to be one? I reckon it fulfills the requirements (which are not actually strictly sepecified at anti-pattern). Good luck with your restructuring efforts, I shall look again in a while.

• It isn't an anti-pattern per se; anti-patterns usually refer to practices which are consistently bad. This is more of a theoretical issue. One comment I did remove is the bit about OO not being well-grounded theoretically (the "OO lacks math" argument, I guess)--it's not relevant to this issue. While the formal footings of OO are still being debated; the circle-ellipse problem is quite easily explained in terms of type theory.
• A few suggestions:
  • Don't cite dbdebunk as a source. Pretty much everything Date said about this can be found in The Third Manifesto and its successors (the recently published Types and the Relational Model, which I'll buy when I can find a cheap used copy...). As a printed, published work it's a much more reliable source that Fabian Pascal's website.
  • Other useful sources: [1], Object-Oriented Software Construction, More Effective C++ by Scott Myers, Alistair Cockburn's paper Constructive Deconstruction of Subtyping [2], [3].
  • Related topics: Predicate types, Four out of five rule.
• --EngineerScotty 17:34, 23 January 2007 (UTC)

---

Introduction

I do not want to get into describing the nonsense of the "problem". However, I would like to suggest that the following phrase : "The problem concerns what subtyping/inheritance relationship should exist between classes which represent circles and ellipses."

should be written as

"Assuming there is a relationship between circles and ellipses, the problem concerns what subtyping/inheritance relationship should exist between classes which represent these two notions." Dpser 15:46, 29 January 2007 (UTC)

PJTraill 17:04, 4 February 2007 (UTC) How strange! ...

• Circles and ellipses are well-defined and well-known mathematical objects with at least one very clear relationship, namely that every circle is an ellipse. So it would be better to say something more like "the problem is whether inheritance should be used to represent the relationship between circles and ellipses.". It is, of course, representative of a wide class of design problems, in many or most of which the relationship is less clear cut. If there are other concepts of circle and ellipse out there, they are a distraction from the question of OO modelling of sub-classes.
• I don't understand what you mean by "describing the nonsense of the problem". It is definitely a topic on which a good deal has been written, dealing with genuine pitfalls into which I believe many have stumbled. My personal feeling is that many contributions, while correct, have caused more confusion than they have cleared up.

Hello PJTraill, I agree with the quoted sentence in point one above to some extent. However, I think you are slightly mislead to think that there is such a relationship namely that a circle is an ellipse. This is by no means true, since they are both merely conic sections. Therefore you should also create an article about whether a hyperbolla is a circle in exactly the same sense.

I regret I cannot get into the esoterics of the nonsense of this problem. I try to restrict myself from getting too much into original research even in the talk page ;-). Just to give a hint, I personally classify this problem in this kind of problems that are simply badly formulated just like "do chicken come from eggs or eggs from chicken?". I take the expression of your personal feeling like an indication that I may be right and here I stop. However and in order to justify my proposal for modification of the wording, I could say that within the scope of object orientation, the problem is also completely badly formulated because OO and in particular OOP is a representation of knowledge: therefore one needs first to describe the world the classes will live in. The phrase "is a circle a parent of an elipse or vice-versa" cannot exist on its own because it tells us nothing about the context the "circle" and "ellipse" live in. Depending on the world, I can translate the above in many ways (and I suspect there are more):

* Analytical geometry: both are subclasses of conic section.

* Function space: circle is a specialization of an ellipse

* Topology and graphics: they are unrelated

* Geometrically: among others, they are both aggregations of arcs

* As orbits: the ellipse extends a circle

* Lexically: they are unrelated

* In a world of projections there may be only circles or ellipses

* In a world of transformations (including non-affine) you might live only with circles

Therefore on its own this question is (in my opinion) nonsense, as it assumes a very particular relationship between circle and ellipse, namely that one is always parent and the other child. I think this should be made clear in the article.Dpser 22:50, 4 February 2007 (UTC)

Complications

I do not know if it should be mentioned in the article, but the most general ellipse may have its axes at angle relative to X and Y axes. In other words, in the most general case, an ellipse has 5 parameters ((X,Y) origin's coordinates, Major Radius, Minor Radius, angle of Major Radius relative to X axis) vs. circle's 3 parameters ((X,Y) origin's coordinates, Radius). Thus, you have really 3-class hierarchy - general ellipse, ellipse oriented to axes, circle. The genreal ellipse may have a method to rotate it by angle $\theta$, oriented ellipse should forbid this method, and circle may treat it as a NOP. Tddpirate (talk) 12:56, 27 August 2008 (UTC)

That is not relevant to this article, as it is not about properties of circles and ellipses specifically. It is not really important what example one takes, the point is that if you use an OO class to model some set, and it has a modifying method not preserving a subset, you cannot model that subset as an OO subclass without some unconventional features. E.g. if Man has a modifying method marry, you have a problem forming a subclass Bachelor — you could just as well call it the "Bachelor-Man"

You don't need "features" to model. You need a brain. You need features to implement, in the context of some economic constraints and optimizations (target platform, available tools, time to market, etc). OOP doesn't have "features"; OOP implementations do. If something is missing from OOP, the way you learned it and stands in your way, then fix it, if you can. KazKylheku (talk) 01:12, 5 October 2011 (UTC)

problem. —Preceding unsigned comment added by PJTraill (talk • contribs) 00:26, 20 October 2008 (UTC)

I find it confusing that the example abstraction meant to subsume square and rectangle is a precise definition of a rectangle. —Preceding unsigned comment added by 76.102.134.241 (talk) 12:18, 8 April 2011 (UTC)

Radius

The example of why it is a bad idea to make an elipse an extension of a circle gives the example that an ellipse cannot provide a radius method. An ellipse DOES have a radius or rather a continuum of radii parameterised over angle from an arbritrary reference point. Providing this parameter to a circle will give the same radius throughout the continuum. In the same way it is also possible to rotate a circle, it just doesn't affect anything. Therefore a better example is needed whereby an elipse cannot simply extend a circle.

---

The crux of the problem was hinted to at the end of the article. The concept of a subclass is that it is intended to extend the parent class, but a circle is a restriction, rather than an extension. It reveals an ambiguity in language: When we say "A is a B...", it can mean two things: A is an extension of B, or A is a restricted form of B. Possibly we can create a programming concept of restricted inheritance. (This may have been touched on in the article.) 67.101.59.207 (talk) 19:55, 8 November 2012 (UTC)D.Kantor

Challenge the premise of the problem - Monkey is an Animal

In the "Challenge the premise of the problem" section, it is suggested that perhaps Circle should not be a subclass of Ellipse, because it restricts the implied freedom of an ellipse, whereas the same problem would not arise if Monkey was a subclass of Animal. That idea seems to side-step one of the major problems communicated by the article (perhaps not explicitly enough), namely that a Circle could be altered (as an ellipse) to contradict its own labelling as a circle, and thereby, implicitly could be made to contradict some aspect of its implied identity. It's a philosophical idea that could equally be applied to the Monkey-Animal relationship. As a hypothetical example, if all animals are composed of cells, and those cells are mutable, e.g. by altering their DNA, then (in theory) all animals could be changed in this way. Since a monkey is an animal, then all of its cells could (in theory) be changed so that it now appears and functions exactly like a duck. Therefore, the Monkey is no longer a monkey, but it is still an animal. This is the same kind of semantic problem arising with circles being changed (according to their inherited allowance) into something that contradicts their own label. Of course, that ties in with the other ideas of mutable types, e.g. when a Circle becomes a non-Circle by virtue of being a mutable Ellipse. — Preceding unsigned comment added by 129.67.47.59 (talk) 11:45, 9 January 2014 (UTC)