Circles Aint Ellipses

Seems like this page and CirclesAreEllipses could use a healthy dose of ThereforeBut. Both sides appear blindly dogmatic here, and both probably ought to know better. Why not argue the matter through rationally (no pun intended) and let the conclusion occur naturally?

If circles are ellipses, then a one dimensional line segment is a rectangle. And a rectangle is a rectangular prism. And a rectangular prism is a hyper-rectangle. And so on up to as many dimensions as you please. Furthermore, a zero dimensional point is a one dimensional line segment ... therefore a zero-dimensional point is an N-dimensional hyperspace.

Sure, that makes sense.

Perhaps the problem is with that pesky word "is". Try it in EprimeLanguage.

Recall that the definitions of sine and cosine are based on the ratios of the hypotenuse to one of its sides. You could look at a triangle with a hypotenuse of 1, a side 1, and another side 0--essentially, a horizontal or vertical line (depending on where in the circle this occurs)--and this results in certain values of sine and cosine to be either 1 or 0. So, yes, sometimes it makes sense to view a line segment as a two-dimensional object (in this case, a triangle); I see no reason why it can't make sense to expand this to higher dimensions. -- Alpheus

The argument about standard elementary / high-school definitions of circle, ellipse, integers, and rational numbers has been moved to CirclesAreEllipses. A circle is a kind of ellipse, in which both foci are coincident. An integer is a kind of rational number, in which the denominator is one (or an integral factor of the numerator).

Now, to the point: if I subclass Circle from Ellipse then I have no problem with affine operations. But topological operations become problematic. In almost all common cases there is no need to operate topologically on these beasts, so NoWorries?. But if I subclass Integer from Rational then there is an issue, because there are lots of simple arithmetic operations on Integers that don't fit the paradigm. If an Integer is a Rational, then does division by Integers round to an Integer or does it produce an object that is no longer an Integer? There's no one answer that fits all contexts of use.

These are two different kinds of divisions.

Ordinary division of two rationals produces another rational. That rational is an integer if its denominator is one.

Then there is truncating or rounding division, which can be seen as an application of ordinary division followed by a normalizing operation which selects a nearby integer by closeness, or toward zero, or toward positive or negative infinity.

Why?

In a programming language, it's useful to have these operations combined into special division operators.

Why?

There is no one answer, because several answers are useful simultaneously.

Instead of arguing, why not just try it? If an Integer is a subclass of Rational, then the division of a Rational by an Integer is the same as the division of a Rational by a Rational.

These are different type signatures, and can therefore correspond to different method specializations.

The result of the operation will be as defined by the Rational base class.

No; the result is defined by the method that matches the argument signature Rational X Integer. Time to re-read the AlternateObjectOrientedProgrammingView!

If you want to convert theRational to an Integer, provide the appropriate conversion routines in Integer to round up, round down, go to the nearest multiple of 23, or whatever you may desire.

Let's try division in Lisp:

   ;; integer X integer -> integer 
   (/ 10 10) ->  1
   (type-of (/ 10 10)) -> INTEGER

   ;; integer X integer -> ratio
   (/ 10 3) ->  10/3
   (type-of (/ 10 3)) -> RATIO

   ;; ratio X ratio -> integer
   (/ 10/3 5/3) ->  2
   (type-of (/ 10/3 5/3)) -> INTEGER

   ;; ratio X ratio -> ratio
   (/ 10/3 5/2) ->  4/3
   (type-of (/ 10/3 5/2)) -> RATIO

Where is the problem again?

I'm reminded of blind men and elephants. Just how many of these answers must we implement to keep your dogma afloat?

We must implement as many kinds of operations as we need to get the job done.

Combinatorial explosion of types sinks so many systems ... why not set things up sensibly to begin with -

What combinatorial explosion of types? The existence of various forms of truncating division and normal division is hardly an explosion. These are distinct operations with different semantics. No one of them is more correct than any other. I don't view the return type of a generic function as a specializable parameter. Moreover, the difference between various truncating divisions isn't expressed in type anyway; they are all rational X rational -> integer mappings.

- don't derive circle from ellipse because CirclesAintEllipses. Don't derive Integer from Rational because IntegersAintRational.

This is real dogma. My "dogma" is "derive them this way if it's convenient and works."

Unless you can define some consistent PolyType from which we can derive all subtypes by classification ... for which I'll not hold my breath ...

Okay, so what is the alternative? Suppose I have a psychological block against deriving integers from rationals. What else can I do to achieve the same convenience, so that I don't have to introduce superfluous tests and coercions into my program?

Second question: under what conditions should we use inheritance at all? It follows from your arguments that any given pair of types can be extended so that their ontology breaks the inheritance, so we should not ever derive anything from anything in anticipation of such extensions.

Then to the muddying concept of type, or as you seem to interpret it, archetype. You assert that type is a matter of classification of representation. But this ignores the intent of representation, that being to account for process ontology. You are free to assert that bit strings represent any metric, unit, or value you please. But there are empirical limits you're not considering; in order to maintain a bijection from sensory patterns to bit patterns you have to account for the ontology of the sensory patterns, and that will determine whether your type of interpretation is an adequate or inadequate classification.

Therefore we'll do better to consider the exigencies of representation for different process ontologies, rather than to create castles in the air about the filiation of types.

Snore, pseudo-philosophical clap-trap with big words.

Ah, the FuzzyMath? defence :-) So ... which parts of this don't you get? I've done you the courtesy of attempting to follow your arguments, and I trust you'll return it. So I'm happy to dumb any of this down ... if you'll let me know what to dumb down.

I don't get any of it. In particular, I don't follow how empiricism or sensory perception enters into this at all, or why these subjects are non-fuzzy math. I also don't follow what value judgments about the adequacy of a classification have to do with anything. A classification schema is valid if it can support the operations that are needed to solve the problem. If two different representations are rolled under one type, then it is still possible to have generic operations that specialize to the representations. Sure there are issues regarding efficiency and conversion from one to the other. I really don't see how such observations negate the idea that a circle is an ellipse, or at least that it can be if we want it to be and are willing to put in some work to make it so. I never made any assertion that exactly the same procedure that works with circles will work with ellipses. At some level, there is specialization, but it doesn't have to pervade into the entire program.

I'm arguing purely from a pragmatic viewpoint; do what is convenient. If some type classification is inconvenient in your problem domain, then don't try to impose it.

Errrm, you both appear to be agreeing with each other. Circles are not ellipses, unless you need them to be. I.e. pragma over dogma. --RH

What a load...

Mathematically, a circle is an ellipse. In a "mathematical" (functional) language, Circles are subtypes of Ellipses (although possibly you might not care).

Many of us use languages where objects can change state. An ellipse which can be stretched never has type Circle, even if it happens to currently have focus1==focus2. It is an Ellipse which is momentarily circular, just as the string 'X' is not a Character; it is a String which is currently of length 1.

Mathematics don't matter in this context. Class hierarchies are defined to meet the needs of the program. As an aside, it is usually bad practice to derive one final use class from another. If both circles and ellipses are required, it would be better to derive both from a common class. The other alternative would be to use only an ellipse class and instantiate it for both ellipses and circles.

Why is it bad to derive one final use class from another? If you have good reasons (or even just authorities), I think they would be worth a page of their own: NoConcreteBaseClasses --- I think it may be relevant to consider this discussion in the light of the discussion given in http://alistair.cockburn.us/crystal/articles/unlmboomp/usingnaturallanguageasametaphoricbase.html, where he picks at the issues of theoretical specialization versus efficiency in implementation, and the consequences for computer programs.

CategoryPolymorphism