Circles Are Ellipses

It is possible to construct an ellipse that appears to be a circle. But an ellipse possesses a distinct ontology, a second focus, that no circle can possess. Similarly, although the function f(x) = 0 appears identical to the x axis, it possesses an ontology that the X axis does not possess (ie. a Y coordinate).

This ontological difference is a trivial issue for simple right-orthogonal geometry because it induces no important distinction in geometric results. But it is essential to the efficient representation of more complex spaces. For example, almost all AI "spaces" fail to represent a consistent ontology among their contents, and so what ought to be simple arithmetic operations become procedural, heuristic, statistical, and combinatorially explosive.

The real problem with this page are the first two words: Circles Are. Where are they? ;)

A circle is just an ellipse in which the two foci coincide. Just like an integer is a rational number in which the denominator is one, or the function (x - 1)(x - 1) has two roots that are equal; in other words a root at 1 of multiplicity two.

Non-affine operations on an ellipse may cause its coincident foci to diverge. The same is not true of a circle.

No. In mathematics, we don't destroy objects. If we apply a transformation to some object, the old one remains what it is. A new object pops out, possibly with completely new, different properties. We can achieve this in programming too using the functional programming paradigm, in which objects are immutable. If we allow mutation, on the other hand, then we can nevertheless adjust the type of an object. If a mutable circle is transformed so that its foci diverge and it becomes a "proper" ellipse, then the class of that object can be updated, and at the same time, the representation can radically change. For example, the circle can go from a point-radius representation to a two-point plus length representation. It really becomes an ellipse; no vestiges remain of its once having been a circle. The AlternateObjectOrientedProgrammingView page makes this idea perfectly clear.

The problem of mutating a circle so it has non-coincident foci, yet being stuck with its circle class, is simply an artifact of programming languages that don't support dynamic typing and dynamic type adjustment. Well, the real world does. If you burn a candle, its type changes to puddle-of-wax. When you chop up cabbage and pickle it, its type changes to sauerkraut.

Sorry, I still don't understand you. In mathematics no integer is identical with a rational; rationals have infinite strings of fractional digits to carry around with them. Similarly a mapping from a circle to an ellipse is a different object from a mapping from an ellipse to an ellipse. If you confine your comments to representation, then I believe the points made in the introductory section of this page remain valid.

Integers are in fact a subset of the rational numbers. Every integer is also a rational number. So every integer is identical with some rational number, in other words, itself.

The expansions of some rational numbers, in some numeric bases, have repeating digits. This is not manifested when rationals are expressed as fractions, and is base-dependent. 1/3 has infinite digits in base 10, but not in base 3. A rational number is an abstract object. Digits are just a typographical representation. Whether or not it is infinite depends on convention. Consider the bar notation in which a line is written over the digit pattern to indicate that it repeats. You could store rational numbers typographically using something isomorphic to the bar notation. Operations like addition, multiplication and so forth would be defined so that they work with that representation. Implementations of languages that have rationals, like CommonLisp, typically implement them as pairs of integers (which might be fixed or bignums) representing the numerator and denominator. Except in the special case of those rationals that are integers, which have a simpler representation.

The choice of typography is irrelevant; it doesn't matter whether you make their representational burden a denominator or digits just as it doesn't matter whether you represent a 2D point with cartesian or polar coordinates. The issue is the necessity of making one of these typographic distinctions. So this point remains; rationals are distinct from integers because operations upon them are distinct.

And as mentioned this point is trivial in these cases. It becomes important only when the ontologies to represent become complex, as is typical in most OO systems. The poor choice of representation leads to needless and often disastrous combinatorial complexity - cf. Amarel's CannibalsAndMissionaries.

The question is at what level do you need the distinction to manifest itself. Indeed, I know that the machine can store ratios differently from integers. But I can write programs without caring about the representational detail. If I divide two unequal integers, a ratio pops out transparently. If I add two ratios that add up to an integer, an integer object results. I don't have to care about the distinction. When I do need the distinction, I ask a rational number whether it is a ratio or integer. If I ask either of them whether it is rational, it will say yes. I can specialize methods to these subtypes, if I need to handle some behavior differently for integers and rationals. None of this conflicts with the idea that every integer is also a rational. Heck, I can have multiple, completely different representations of *one* type, why not? Imagine a type system in which the programmer need not be aware whether a complex number is cartesian or polar. The system chooses whatever representation is convenient for it to carry out the calculation, dynamically. Of course this would be bad from a numerical stability vantage point, due to the properties of floating-point representations, but the principle is valid. I don't follow how efficiency-of-representation concerns invalidate the idea that a circle can be an ellipse. Even if we just have circles, and no ellipses, we can have more than one low-level representation for them. Representation is not type! Type arises when we interpret and classify representations. We can do this however we want; for instance, we can interpret two completely different representations as being manifestations of the same type.

What a marvelous example of folks talking past each other by emphasizing two distinct domains of practice.

It is also a good example of folks who do not quite know the subject they are discussing. Mathematically, we can show that any object that meets the definition of a circle also meets the definition of an ellipse. We can also show that ellipses with coincident foci are circles. This makes the statement about non-affine transformations false, as any transformation that maps ellipses with coincident foci to ellipses without would also map circles to ellipses without coincident foci.

The situation with integers and rationals is more complex. In mathematics, whether integers are rationals or not is independent of their definitions (such as they are defined). If you go with the closest thing there is to a standard model (build the Natural numbers with 0 = {}, 1 = {0} u 0, 2 = {1} u 1, etc. Integers are equivalence classes of ordered pairs of natural numbers, rational numbers are equivalence classes of ordered pairs of integers), integers are not rationals. On the other hand, most people (and probably most mathematicians) would probably start with the reals; define integers as 0, 1, -1, 2, -2, etc., and define rationals as those reals that can be reached by dividing an integer with another. In this case, any integer is also a rational.

As a mathematician, I can't help but be puzzled by the debate over whether circles are ellipses or not. Clearly, they are, by mathematical definition, and if you are working on a mathematical problem where you need to seamlessly change between the two, then your object system had better support that feature. On the other hand, if you are working on a problem where the seamlessness is unnecessary, or even harmful, then you should implement them as separate objects.

Just for some thought, I will point out something that most of us is going to think is absurd, at least at first: circles are lines. Don't believe me? In the complex plane, if you give me any two of a line or a circle, you could map one to the other in a very nice way; indeed, if you include a "point at infinity", any line is just a circle that goes through infinity. The relationship between lines and circles are so clear, than one book I have (I can't remember the title of it off the top of my head) resorts to calling circles and lines, collectively, as "circlines".

Of course, if you're doing something where the distinction between lines and circles matter, it would be foolhardy to design an object system where they are one and the same; on the other hand, there are indeed situations where you will want to seamlessly convert between one and the other! --Alpheus

What do you mean by `very nice way`? A property-preserving homeomorphism?

[Lines are also dots, so are circles really just a bunch of dots, as are lines? Lines are a useful abstraction though. MindF*ck]

Huh? Lines aren't points. You might claim a point is a line segment of zero length, but even that would be dubious if you argue that orientation is a property of a line segment's ontology.

EverythingIsRelative. You can model circles in many different ways and from many different classification systems.

Models might be relative, but EverythingIsNotRelative. For example if it is windy outside, it's windy outside. There's nothing relative - windy means windy. If it is sunny outside, it is sunny - and that is a fact - there is nothing relative like "well another man's sun, is another man's cloud". That's the AnythingIsPossible fallacy.

CategoryPolymorphism