The problem of overloading operators that _appear_ to have certain properties, but don't, is one that I've complained about for years [http://home.pipeline.com/~hbaker1/ObjectIdentity.html]. Your example of non-transitive "equals" is but the tip of the iceberg. Unfortunately, there doesn't seem to be any way to provide the object-oriented system with a _proof_ of the properties that are desired, so that these properties can be utilized by a compiler, for example. My current pet peeve is the lack of any mathematical elegance behind so-called "sync" operators -- that operation that "syncs" your PDA with your computer, or "syncs" your iPod with your computer. In my mind, "sync" is a lattice operation, e.g., "meet" or "join". Two important properties of such an operation is that it is _symmetric_, in that "sync"-ing should pass information in both directions so that both machines have exactly the same information; and it is _idempotent_, in that "sync"-ing twice shouldn't do any more than "sync"-ing once. Unfortunately, I've run across many so-called "sync" operations that were neither symmetric nor idempotent, and I wouldn't want to call them "sync" operations. At 06:56 AM 4/20/2006, Michael Kleber wrote:
Franklin T. Adams-Watters wrote:
In a programming context, non-transitively can happen by accident in an object-oriented language, if one creates two classes that know how to compare themselves to a third, but not to each other. E.g., Rational, Float, and Integer; 2/1 = 2, 2.0 = 2, but 2/1 != 2.0.
...and Ray Tayek responded:
yes, but that works by overloading ==.
But Ray, your original question was based on comparing floating-point numbers using |a-b|<epsilon, which is itself redefining the equality operator! The "real" equality operation on floating-point values is one that requires perfect matching, which is flawed in the opposite direction: too *few* things are equal, not too many.
(When the "true" answer to some computation is not perfectly representable by your favorite floating-point scheme, two mathematically equivalent but computationally distinct evaluation techniques might result in non-identical answers. For instance, C tells me that (1/10)^2 != 1/100.)
The problem here isn't with equality, it's with the associative and distributive laws for the arithmetic operations that generated the numbers in the first place.
--Michael Kleber
-- It is very dark and after 2000. If you continue you are likely to be eaten by a bleen.