From: KU
To: Editor

 

This morning I had the pleasure of reading your article Type Inheritance: Is a Circle an Ellipse? It and the ensuing debate were at turns enlightening, provocative, and challenging. Much thanks.

 

Down to brass tacks I herewith propose a second representation of CIRCLE and ELLIPSE.

In the real plane, take a line D and a point F not on D. Determine the locus of points P such that for every point in P, the distance [P,F] divided by the (tangential) distance [P,D] is a constant E. If E = 0, the locus of points P is a CIRCLE; if 0 < E < 1, then the locus of points is an ELLIPSE.

 

Now, in your representation a value X may simultaneously be of type CIRCLE and of type ELLIPSE. More precisely, X is of specific type CIRCLE and supertype ELLIPSE when X exhibits the following property the length of the major axis equals that of the minor axis or, equivalently, when the foci of the ELLIPSE are coincidental. (I am attempting to adopt your nomenclature; please correct me if I am in error.)

 

In mine, though, the two types distinct X may be of type CIRCLE or type ELLIPSE, but not both (adjectives and prefixes not withstanding). This assumes, of course, you are willing to concede that E cannot be "zero" and "not zero" (that is, strictly greater than zero) simultaneously.

 

The only change introduced by the new representation pertains to classification, i.e., how values are partitioned between the two types. Every other aspect of the model -- whether concerning variables or values, operations or properties -- is perfectly preserved the two are isomorphic with respect to each other. More than that, they are demonstrably isometric, a fact that speaks for itself.

 

I only have one question, then: how do you reconcile the two representations? In this regard

 

1. The question is a trick

2. Don't answer it.

 

Again, I thoroughly enjoyed your treatise and look forward to your response.
 
 

Chris Date Responds:  KU wrote to say that my article on circles and ellipses, and the ensuing debate, were "at turns enlightening, provocative, and challenging." Well, many thanks! But he or she then went on "to propose a second representation [sic--I don't really think representation, as such, is relevant to the matter at hand, but let that pass] of CIRCLE and ELLIPSE," as follows:

 

“In the real plane, take a line D and a point F not on D. Determine the locus of points P such that for every point in P, the distance [P,F] divided by the (tangential) distance [P,D] is a constant E. If E = 0, the locus of points P is a CIRCLE; if 0 < E < 1, then the locus of points is an ELLIPSE.”

 

Of course, I recognize what's going on here -- D is the directrix, F is the focus, and E is the eccentricity. Though I feel bound to add that:

 

a.      I think that parenthetical qualifier "(tangential)" is incorrect -- the distance in question is surely just the conventional straight-line distance between two points (?);

b.      I also think it's slightly naughty not to state explicitly that in the case of a circle the directrix is supposed to be at infinity. 

 

Be that as it may, the key observation is that all we're really doing here is playing games with terminology. The assertion that "0 < E < 1 defines an ellipse" must be understood to mean, precisely, that "0 < E < 1 defines an ellipse that isn't a circle"! So what KU is calling an ellipse tout court is exactly what I would call, more specifically, a noncircular ellipse. 

As an aside, I remark that I could--of course!--have done the equivalent thing in terms of semiaxes a and b (I mean, there's no need to drag in this stuff about eccentricity and the rest in order to make the point that KU is apparently trying to make). To be specific, I could have defined type ELLIPSE to have a > band type CIRCLE to have a = b. And then of course, I would have to agree that CIRCLE isn't a subtype of (this redefined version of) type ELLIPSE.

 

The question then becomes: Is the foregoing revision to the definition of type ELLIPSE useful? Well, KU doesn't mention any types apart from CIRCLE and his redefined version of ELLIPSE; so if these are the only types we have, we clearly lose value substitutability. I mean, we wouldn't be able to substitute a value of type CIRCLE wherever the system expected a value of type ELLIPSE. Thus, for example, we couldn't have a single AREA() operator that computes the area of a general ellipse and can thus be applied -- thanks to subtyping and inheritance -- to a circle in particular. (And so we lose some code reuse, too.)

 

(Still assuming the revised definition of type ELLIPSE:) Of course, we could go on to define a type hierarchy in which ELLIPSE and CIRCLE are distinct immediate subtypes of the same supertype (which might perhaps be called ELLIPSE_OR_CIRCLE). At least such a type hierarchy would mean that we regain some kind of value substitutability, because we would now be able to substitute a value of type CIRCLE (or a value of type ELLIPSE, come to that) for a value of type ELLIPSE_OR_CIRCLE. But then again, type ELLIPSE_OR_CIRCLE wouldn't have any values whose most specific type was ELLIPSE_OR_CIRCLE -- by definition, every such value would simply be either a value of type ELLIPSE or a value of type CIRCLE (and type ELLIPSE_OR_CIRCLE would be what Hugh Darwen and I call a union type). Thus, it might be argued that this revised type hierarchy gives us back at least some of the advantages that our original design (in which CIRCLE was a subtype of ELLIPSE) gave us -- but it does so at the cost of having an extra type and a more complicated type hierarchy (there might be other costs, too).

 

KU goes on to assert that "Every other aspect of the model--whether concerning variables or values, operations or properties--is perfectly preserved." I don't know, here, whether KU is talking about the ellipses-and-circles example in particular or our model of type inheritance in general. If it's the former, well, I think I've discussed the issue sufficiently. If it's the latter, well, I certainly don't think KU's alternative design in any way invalidates our original design. Furthermore, KU doesn't address a crucial aspect of our approach, an aspect in which we clearly differentiate ourselves from just about every other approach I've ever seen described in the literature. I'm referring to the aspect we call specialization by constraint (S by C) and generalization by constraint (G by C), according to which--to talk extremely loosely!--(a) "squeezing" an ellipse to make a equal to b converts that ellipse into a circle and (b) "stretching" a circle to make a greater than b converts that circle into a (noncircular) ellipse. I find it extremely interesting that nobody has refuted, or even disputed, our claims that (a) S by C and G by C correspond to what actually happens in the real world and (b) we believe we know how to implement them (efficiently, too).

 

 

Posted 04/05/02

 

 

 

[ABOUT] [QUOTES] [LINKS]