[REBOL] Re: Rebol interpreter bug with comparison of dates
From: joel:neely:fedex at: 4-Dec-2002 14:57
Hi, Jan,
Just to take the "road less travelled"... ;-)
Jan Skibinski wrote:
> But what does this mean:
> >> safe-greater? 2x4 1x3
> == true
>
> This is a classical example of concept stretching and this
> is what bites later on...
>
I'm actually sympathetic toward your skepticism re "concept stretching"
and have raised questions about how much we can sweep under the rug of
polymorphism
.
However, on the specific issue of comparing PAIR! values, we've had
this debate on the list a while back, and my personal conclusion was
that
2x4 > 1x3
should evaluate to TRUE (and, of course, reversing the values should
return FALSE ;-) My basis for arguing that position was that REBOL
already has "unified" a number of data types through the concept
(though without official terminology) of ordered composite values.
Specifically, there are many types for which FIRST , SECOND , and so
on, are defined. For example, in addition to the series types, for
which the ordinal selectors have the obvious meaning, REBOL applies
the selectors to dates as follows:
>> foo: now/date == 4-Dec-2002
>> first foo == 2002
>> second foo == 12
>> third foo == 4
to times as:
>> foo: now/time == 14:27:01
>> first foo == 14
>> second foo == 27
>> third foo == 1
and so on. (And we have the shorthand of X/1 for FIRST X and so on.)
Now, if we have a type which is a sequence of component types, where
each component type posesses a set of ordering relations, it seems
perfectly reasonable to define the ordering relations on the
(top-level) type in terms of the lexicographic ordering across the
collection. In pseudo-REBglish,
a < b
whenever
any [
a/1 < b/1
all [a/1 = b/1 a/2 < b/2]
all [a/1 = b/1 a/2 = b/2 a/3 < b/3]
... and so on ...
]
This works exactly as expected for DATE! and TIME! values, but also
works for heterogeneous series values! (See the postscript for an
exhaustive/exhausting illustration. ;-) The same game can be played
for tuple values, BTW.
That said, even though I completely agree that there is no "natural"
ordering for cartesian coordinates *as spatial coordinates* I believe
that there *is* a natural ordering for ordered pairs of integers,
namely the lexicographic order. The PAIR! type certainly has all of
the symptoms of being an ordered pair of integers, and has FIRST and
SECOND (or /1 and /2) defined. Allowing PAIR! values to be treated
as ordered pairs (including the support for lexicographic ordering
in support of such an interpretation) shouldn't break any code that
simply uses them as e.g. pixel coordinates, but would extend their
range of possible applicability.
In short, things that otherwise behave as tuples (in the Mathematical
sense of the word, not in the REBOL TUPLE! sense) should all be able
to participate in meaningful tuple-like behavior, including the
ability to be lexicographically ordered.
I'm now climbing down off my soapbox... ;-)
-jn-
Here's a generated example showing how REBOL handles order inquiries
over heterogeneous blocks. (This is output from a wad of nested loops
that actually set up the values and printed the output; I assume it
is too obvious to waste bandwidth on.)
[1 "A" #"a"] < [1 "A" #"a"] = false
[1 "A" #"a"] < [1 "A" #"b"] = true
[1 "A" #"a"] < [1 "B" #"a"] = true
[1 "A" #"a"] < [1 "B" #"b"] = true
[1 "A" #"a"] < [2 "A" #"a"] = true
[1 "A" #"a"] < [2 "A" #"b"] = true
[1 "A" #"a"] < [2 "B" #"a"] = true
[1 "A" #"a"] < [2 "B" #"b"] = true
[1 "A" #"b"] < [1 "A" #"a"] = false
[1 "A" #"b"] < [1 "A" #"b"] = false
[1 "A" #"b"] < [1 "B" #"a"] = true
[1 "A" #"b"] < [1 "B" #"b"] = true
[1 "A" #"b"] < [2 "A" #"a"] = true
[1 "A" #"b"] < [2 "A" #"b"] = true
[1 "A" #"b"] < [2 "B" #"a"] = true
[1 "A" #"b"] < [2 "B" #"b"] = true
[1 "B" #"a"] < [1 "A" #"a"] = false
[1 "B" #"a"] < [1 "A" #"b"] = false
[1 "B" #"a"] < [1 "B" #"a"] = false
[1 "B" #"a"] < [1 "B" #"b"] = true
[1 "B" #"a"] < [2 "A" #"a"] = true
[1 "B" #"a"] < [2 "A" #"b"] = true
[1 "B" #"a"] < [2 "B" #"a"] = true
[1 "B" #"a"] < [2 "B" #"b"] = true
[1 "B" #"b"] < [1 "A" #"a"] = false
[1 "B" #"b"] < [1 "A" #"b"] = false
[1 "B" #"b"] < [1 "B" #"a"] = false
[1 "B" #"b"] < [1 "B" #"b"] = false
[1 "B" #"b"] < [2 "A" #"a"] = true
[1 "B" #"b"] < [2 "A" #"b"] = true
[1 "B" #"b"] < [2 "B" #"a"] = true
[1 "B" #"b"] < [2 "B" #"b"] = true
[2 "A" #"a"] < [1 "A" #"a"] = false
[2 "A" #"a"] < [1 "A" #"b"] = false
[2 "A" #"a"] < [1 "B" #"a"] = false
[2 "A" #"a"] < [1 "B" #"b"] = false
[2 "A" #"a"] < [2 "A" #"a"] = false
[2 "A" #"a"] < [2 "A" #"b"] = true
[2 "A" #"a"] < [2 "B" #"a"] = true
[2 "A" #"a"] < [2 "B" #"b"] = true
[2 "A" #"b"] < [1 "A" #"a"] = false
[2 "A" #"b"] < [1 "A" #"b"] = false
[2 "A" #"b"] < [1 "B" #"a"] = false
[2 "A" #"b"] < [1 "B" #"b"] = false
[2 "A" #"b"] < [2 "A" #"a"] = false
[2 "A" #"b"] < [2 "A" #"b"] = false
[2 "A" #"b"] < [2 "B" #"a"] = true
[2 "A" #"b"] < [2 "B" #"b"] = true
[2 "B" #"a"] < [1 "A" #"a"] = false
[2 "B" #"a"] < [1 "A" #"b"] = false
[2 "B" #"a"] < [1 "B" #"a"] = false
[2 "B" #"a"] < [1 "B" #"b"] = false
[2 "B" #"a"] < [2 "A" #"a"] = false
[2 "B" #"a"] < [2 "A" #"b"] = false
[2 "B" #"a"] < [2 "B" #"a"] = false
[2 "B" #"a"] < [2 "B" #"b"] = true
[2 "B" #"b"] < [1 "A" #"a"] = false
[2 "B" #"b"] < [1 "A" #"b"] = false
[2 "B" #"b"] < [1 "B" #"a"] = false
[2 "B" #"b"] < [1 "B" #"b"] = false
[2 "B" #"b"] < [2 "A" #"a"] = false
[2 "B" #"b"] < [2 "A" #"b"] = false
[2 "B" #"b"] < [2 "B" #"a"] = false
[2 "B" #"b"] < [2 "B" #"b"] = false
--
----------------------------------------------------------------------
Joel Neely joelDOTneelyATfedexDOTcom 901-263-4446
