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)

Perhaps using ConicalSection as a superclass is much simpler? Methods and properties (like radius and stretchX()) not shared by subclasses should stay exclusive to those subclasses. Klassica 20:04, 25 November 2015 (UTC) — Preceding unsigned comment added by Klassica (talk • contribs)

Even easier

I propose that class Ellipse() exists as it ought to be with radiusXsize and radiusYsize. To make a class Circle(), we extend Ellipse(), however do a simple override to radiuses i.e. when Circle() is invoked and a radius size defined, it is applied to both directions (X and Y), thus:

• Ellipse() is a parent
• Ellipse() integrity is not questioned
• Circle() can be a child
• Circle() has one extra property (inherited from Ellipse())

Lovescream (talk) 13:31, 7 April 2018 (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)

Person vs. prisoner

There is a problem with the example of the person and prisoner. It states "a prisoner is not free to move an arbitrary distance in any direction, yet the contract of the Person class states that a Person can." But no person is ever free to move any distance in any direction; we are all restricted in our movement. We are restricted by walls, fences, hedges, roads, the private property of others, rivers, mountains, oceans, political borders, gravity, planets, stars etc. So I consider it a bad example; if the contract of a person says that it can move freely in any direction, that contract is bad in the first place. And that makes the whole prisoner example invalid, because a prisoner is just a person that is (temporarily) more restricted than most other persons are. There is no such thing as a FreePerson that can move freely in any direction; there are only RestrictedPersons with a varying set of restrictions. And in that case a Prisoner can easily inherit from RestrictedPerson, as a Prisoner only has an extra, specific physical restriction in the set of restrictions; a very narrow one for sure, but not really categorically different from any other restriction.

Maybe Person and Prisoner can be kept, but the methods changed into something that really is categorically different between a Person in general and a Prisoner.

If I had a good idea for a better, more realistic and valid alternative, I would simply replace the example. But right now I don't have that idea. I just wanted to point to and describe the problem, which is the first step to solving it. Maybe someone else can come up with a good solution. --Jhertel (talk) 01:16, 13 October 2016 (UTC)

External links modified

Hello fellow Wikipedians,

I have just modified one external link on Circle-ellipse problem. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Added archive https://web.archive.org/web/20150905081111/http://www.objectmentor.com/resources/articles/lsp.pdf to http://www.objectmentor.com/resources/articles/lsp.pdf

When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at {{Sourcecheck}}).

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 03:58, 25 November 2016 (UTC)

External links modified

Hello fellow Wikipedians,

I have just modified one external link on Circle-ellipse problem. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Added archive https://web.archive.org/web/20110719101727/http://www.informatik.uni-augsburg.de/de/lehrstuehle/dbis/db/publications/all_db_publications/1996_koe_kie_isotas96/1996_kow_koe_kie_isotas96.pdf to http://www.informatik.uni-augsburg.de/de/lehrstuehle/dbis/db/publications/all_db_publications/1996_koe_kie_isotas96/1996_kow_koe_kie_isotas96.pdf

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 02:14, 8 August 2017 (UTC)

This article probably needs reworked

All circles are ellipses. All ellipses are circles, if their x and y dimensions are the same. Which one is the parent, which one is the child in a single-inheritance hierarchy? ...

...

The entire premise is a contrived (on purpose) academic exercise to try and illustrate to computer science students that, correctly used, OOP should model externally visible behavior, not *literal* set-relationships. It says right in the liked source:

"A square might be a rectangle, but a Square object is definitely not a Rectangle object. Why? Because the behavior of a Square object is not consistent with the behavior of a Rectangle object. Behaviorally, a Square is not a Rectangle! And it is behavior that software is really all about."

Unfortunately, unless I'm mistaken, the article and much of the talk page goes on at great length and seems to have taken the problem seriously. It goes down some particularly contrived rabbit holes, offering some questionable-at-best solutions.

"code written in an object-oriented language that models shapes will frequently choose to make class Circle a subclass of class Ellipse, i.e. inheriting from it."

None that I've wrote ever did. We model the externally visible behavior not the literal real-world set-relationships.

In the given example, using OOP these would be implemented as siblings - thus avoiding the entire problem - because that's the whole point. They behave differently, thus they are different types. That's what a type is in programming. A type is a behavior. It behaves as an int, it behaves as a float, it behaves as a Circle, it behaves as an Ellipse, it behaves as a Whatever.

In almost any OOP language, I can explicitly typecast these into one another following whatever behavior is required to be visible to external users. I can even write comparison operators if I need to compare them in some way - all entirely using OOP and it works quite well.

To use this purposefully contrived example problem as a serious argument against OOP, (as the article implies) is a fundamental misunderstanding of how to apply the OOP paradigm and is contrary to the paper it references.

C++, Java and Python programmers cleanly implement Circles and Ellipses using OOP every day. 65.121.126.226 (talk) 22:13, 20 September 2022 (UTC)