On Thu, January 20, 2011 10:20, John F. Sowa said:
> The discussions in the OMG forum raised an old puzzle about two
> different ways of defining circles and ellipses. Euclid's way
> makes circles a special case of ellipses, but some programmers
> might define them as two independent classes. (01)
What is being referred to is two uses of the *word* "ellipse"
to refer to two similar, but not equivalent meanings. (02)
> Examples like this arise in any ontology. What happens when
> different people define two types with specifications that
> might sometimes, but not always coincide? (03)
They define them in different ontologies. They then define the
inter-relationship between the two. In this case,
O1:Circle subClassOf O1:Ellipse
O2:Circle disjointFrom O2:Ellipse (04)
The two ontologies have the same definition of Circle
O1:Circle subClassOf O2:Circle
O2:Circle subClassOf O1:Circle
but not of Ellipse
O2:Ellipse subClassOf O1:Ellipse
O1:Ellipse subClassOf (O2:Ellipse U O2:Circle)
(O2:Ellipse U O2:Circle) subClassOf O1:Ellipse (05)
> John
>
> -------- Original Message --------
> Subject: Re: [architecture-strategy] Relationship between types, classes
> and sets
> Date: Thu, 20 Jan 2011 10:08:43 -0500
> From: John F. Sowa
> To: architecture-strategy@xxxxxxxxxxxxxxx
>
>> It would help things along is you could you explain what you see the
>> predicates for the OO uses of Circle and Ellipse in
>> http://en.wikipedia.org/wiki/Circle-ellipse_problem are.
>> And what you see the interpretation of OO inheritance may be, where this
>> shows circles inheriting from ellipses - where mathematicians would
>> expect ellipses to be sub-types of circles. (06)
> The puzzle about circles and ellipses does not violate the following
> criterion: (07)
> Every class C has a predicate isinC(x), which is true iff object x
> is in class C.
>
> As for the circle-ellipse issue, it is misleading to say that one
> definition is more "mathematical" than the other. Both are equally
> mathematical (in the sense that they are defined by mathematical
> specifications).
>
> But mathematicians since Euclid have preferred to say that a circle
> is a special case of an ellipse because that assumption simplifies
> and generalizes the theorems and proofs. But the other definition
> could be assumed if anybody found it useful for some purpose.
>
> Solution: There is a trivial solution to the so-called problem
> that is not mentioned in the Wikipedia: drop the requirement that
> two isomorphic figures must belong to the same classes. That would
> imply that no stretched ellipse could ever *be* a circle -- the
> specification would take priority over the appearance in determining
> class membership. (08)
This issue discussed in Wikipedia is not figures, it is OO representations
of figures. The distinction needs to be noted. A Euclidean circle or
ellipse is of fixed size and shape. Such an ellipse can not stretch or
flatten. An OO representation of a circle or an ellipse can change from
representing one ellipse or circle to another, merely by changing the
parameters of the representation. Let's call these OOCircles and
OOEllipses to be clear. (09)
This solution is that OOEllipse does not inherit from OOCircle or
vice versa. Any figure modeled by an OOCircle can be modeled by an
OOEllipse. (010)
> Re mutators: If you define a circle as having one center, and an
> ellipse as having two foci, you don't get any problems with mutators
> or inheritance. By that definition, a stretched ellipse with both
> foci at the same point would not be a circle, even though it looked
> like a circle. (011)
An OOCircle is defined as having one center and an OOEllipse as having
two foci. If one instance of each is defined as representing the
same Euclidean circle, the OOEllipse can be stretched to represent
a different Euclidean ellipse (which is not a circle), but the OOCircle
has no mutator allowing it to stretch. (012)
> Re inheritance: Since no circle would ever be an ellipse, no circle
> could inherit two foci from the definition of ellipse. (013)
The OOCircles would not have foci. (014)
A second solution would be to allow OOCircle to be a subclass of
OOEllipse, but any mutator acting on an instance of OOCircle would
mutate it into being an instance of OOEllipse, and no longer an instance
of OOCircle. (015)
> Euclid's definition is more "elegant" and "general", but elegance and
> generality are not prerequisites for being mathematical. (016)
We are not discussing mathematical properties here. We are discussing
properties of Object-Oriented languages. (017)
-- doug (018)
> John
> (019)
=============================================================
doug foxvog doug@xxxxxxxxxx http://ProgressiveAustin.org (020)
"I speak as an American to the leaders of my own nation. The great
initiative in this war is ours. The initiative to stop it must be ours."
- Dr. Martin Luther King Jr.
============================================================= (021)
_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/
To join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J
To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx (022)
|