Comparison: when operator<() is better than opCmp()

Giuseppe Bilotta giuseppe.bilotta at gmail.com
Sat Sep 8 06:31:54 PDT 2007


On Saturday 8 September 2007 14:13, OF wrote:

> It's sound like it's not worth it. It might be, but you need a
> better example to show it. The use of operator overloading in
> your example isn't very solid.
> 
> There's no naturally defined order. This easily makes operator
> overloading of compare operators more confusing than helpful.
> You need to read the documents or code to fully understand a <=
> b, and that !(a > b) doesn't equal a <= b even with correct
> input.
> 
> I'd recommend functions like aboveRange, inRange and belowRange
> or something similar for this.

Sorry, but there *is* a naturally defined ordering of intervals,
although it's (obviously) not a total ordering, in the sense there
may be intervals which are distinct and for which neither i1 < i2
nor i2 < i1 is valid.

Observe that this is no different from the fact that not all reals
are comparable either, if any of them is a real.nan --does this
mean we should use a syntax different from a < b for reals? I
don't think so.

The fact that it's not a total ordering is in no way disturbing or
confusing; on the contrary, it's a pretty standard notion across
pure and applied mathematics that not all orderings are total, and
in particular for interval analysis this definition of < & friends
is pretty standard and universally acknowledged (see e.g. page 6
of the 'red bible' (Interval methods for systems fo equations, by
Arnold Neumaier)).

The package I'm creating is aimed at numerical analysis, and its
target is people which have knowledge in the field, and would
therefore not be surprised by the fact that !(i1 < i2) does not
imply (i2 <= i1). I don't really see why I should cripple the
syntax when the common syntax is perfectly legit.

-- 
Giuseppe "Oblomov" Bilotta



More information about the Digitalmars-d mailing list