[E-Lang] Operators #2: Comparison
Ralph Hartley
hartley@aic.nrl.navy.mil
Mon, 09 Apr 2001 16:30:48 -0400
Mark S. Miller wrote:
>
>> Not defining it at all has its merits, but comparing the sets of keys isn't
>> right anyway. The comparison of two maps should depend on the values, not
>> just the keys. Here is a try at a definition: [...]
>
>
> Wow. This is a very clever (and, I think, beautiful) extension of the idea
> of lexicographic ordering. I'm not going to think about this yet.
Fair enough. But I will continue on the principle that *I* might not
have time latter, or might forget. The one operator I would really want
to have is <=>. Immutable maps are almost never going to be ==, so a way
to find out if two maps are "the same" would be nice to have.
The definition of <=> ought to be something like "x<=>y iff ( a<=>b
implies x[a]<=>y[b])" , that is, all their key/value pairs are <=>.
That's the math definition for equality of maps.
The definition I gave in the previous message agreed with this one for
keysets with total orders. For unordered keysets I think the previous
definition was broken, it sometimes gave NaN when it should have been 0.
There are a lot more ways to order maps than there are equivalences, so
>, <, >=, and <= are a lot less clear cut. For instance you might also
define x<y iff (x keyset() is a propoer subset of y keyset() and for any
a in x keyset() x[a]<=>y[a]. That would be the submap relation, where x
and y agree for any key they are defined on but x is defined on a proper
subset of y's keys. This definition also agrees with <=> but not with
the lexicographic order. For strings as maps from [0..N] to chars it
would be the "prefix" relation.
There are enough definitions of < for maps that it would be odd to
support one without supporting them all. It WOULD be nice if I could
decide on one (in java you do this by overriding compare()). I don't
know how often I would use it. Nowhere near as often as <=>, I think.
For <=> the only choice is if the keys and/or values need to be == or
only <=>. That gives three meaningfull definitions of <=>:
Strict - Each key a of x must be == some key b of y and x[a]==y[b].
rare.
Canonical - Each key a of x must be <=> some key b of y and x[a]==y[b].
more common - given a key they always give the exact same value if
the keys are <=>.
Loose - Each key a of x must be <=> some key b of y and x[a]<=>y[b].
common.
I think there is a equivalent issue defining <=> on sets. Do the
elements need to be the same or just equivalent?
(I know I left out a posibility, but don't remember ever needing
Co-Canonical).
Ralph Hartley