Pair comparison (was: native? :==)
[1/9] from: hallvard::ystad::helpinhand::com at: 5-Feb-2002 9:13
Dixit [holger--rebol--com] (23.03 04.02.2002):
>Yes, but for string and block series there is a natural order
>(left-to-right). For pairs there is not. Do you want x or y to
>take precedence ?
Precedence or not, when presenting X/Y coordinates, I have yet to meet with someone who
places the Y before the X (ever heard about Y/X coordinates?).
[...]
>Joel Neely:
>> Since "first" and "second" are just as defined for pair data as for
<<quoted lines omitted: 4>>
>So you are arguing to give x precedence over y ? In layout-oriented
>calculations y tends to be dominant though...
What tends to be dominant doesn't prevent rebol from persuing it's left-to-right ordering
in other cases. E.g. most programming languages evaluate 4 + 4 * 4 to 20, rebol evaluates
it to 32, unless you add parentheses. So in my opinion, one could defend the use of simple
left-to-right order comparison also for pairs.
...but I'm just a Bear of Very Little Brain...
~H
[2/9] from: rebol:optushome:au at: 5-Feb-2002 18:58
----- Original Message -----
From: "Hallvard Ystad" <[hallvard--ystad--helpinhand--com]>
To: <[rebol-list--rebol--com]>
Sent: Tuesday, February 05, 2002 6:13 PM
Subject: [REBOL] Pair comparison (was: native? :==)
> Dixit [holger--rebol--com] (23.03 04.02.2002):
> >Yes, but for string and block series there is a natural order
> >(left-to-right). For pairs there is not. Do you want x or y to
> >take precedence ?
>
> Precedence or not, when presenting X/Y coordinates, I have yet to meet
with someone who places the Y before the X (ever heard about Y/X
coordinates?).
> [...]
Pairs also represent size. If you only compare X then this falls apart when
dealing with size. Which is greater 5x1 or 3x2 ??
Cheers,
Allen K
[3/9] from: hallvard:ystad:helpinhand at: 5-Feb-2002 10:26
Dixit Allen Kamp (09.58 05.02.2002):
>Pairs also represent size. If you only compare X then this falls apart when
>dealing with size. Which is greater 5x1 or 3x2 ??
You miss my point. What I mean is, although there _are_ different ways to look at this,
a simple left-to-right ordering is what is implemented in other cases, so...
But as I said, I'm just a Bear of Very Little Brain...
~H
[4/9] from: joel:neely:fedex at: 5-Feb-2002 6:42
Thanks, Allen, for an example that helps me focus on the key
issue I've been thus far unable to make clear!
Allen Kamp wrote:
> From: "Hallvard Ystad" <[hallvard--ystad--helpinhand--com]>
> > Dixit [holger--rebol--com] (23.03 04.02.2002):
<<quoted lines omitted: 8>>
> Pairs also represent size. If you only compare X then this falls
> apart when dealing with size. Which is greater 5x1 or 3x2 ??
An ordered-pair data type could be used to represent many things.
Some of those things have an intuitive total ordering and others
do not. Some have multiple plausible total orderings, depending
on what's being done with them.
For example, to take Allen's illustration further, which is "larger",
a 6x1x1 package or a 3x2x1 package? Although they are both 6 cubic
units in volume, the 6x1x1 configuration is more "extreme" in terms
of being able to pack it neatly in a cargo container, aircraft, etc.,
and so may be considered "more" for some purposes.
However, we're talking about a data type in a programming language,
which is different than talking about all of the things I might be
able to represent with it (with all of their varying "intuitive"
baggage). Let's not confuse the capabilities of the data type
AS A PRIMITIVE DATA TYPE with all of the range of possible uses
that could be made of the type in applications.
For example, in the US, wire is commonly specified by "AWG gauge",
based on inches. 38-guage wire is .004 inch in diameter, 10-guage
wire is just over 1/10-inch (.1019), etc. (The relationship is
essentially a geometric series with ratio ~1.123, for the maths
geeks among us.) The British SWG system is similar, with slightly
different numbers.
What's my point? Simply that -- for wire gauge -- a larger number
means finer wire, so that a comparison function that interpreted
numbers as gauge and told which *wire* was larger would have the
result that
larger-as-AWG? 10 36
would be true. However, I would NEVER use this as an argument to
claim that numbers can't be compared. When comparing numbers
*as*numbers* it should be obvious that 10 > 36 is false.
REBOL already observes this data-type-versus-usage distinction in
other ways. Consider the string comparison:
>> "237 Washington Street" < "1150 Washington Street"
== false
Every human being knows that 237 Washington Street is closer to the
middle of town than 1150 Washington Street, and therefore this
answer is clearly wrong! But is it? No! The built-in LESSER?
test on strings is doing its work based only on the (well-defined)
properties of strings as ordered collections of characters. The
STRING! value "237 Washington Street" follows the STRING! value
1150 Washington Street
based on those properties, regardless of
where the strings came from or what meaning I may attach to them
in my application.
If I want to have a function that imposes an "intuitive" ordering
on the application-level concept of "street address", then I'm free
to define and implement one in my own code (and bear the total
responsibility for its correspondence to my users' expectations!)
If I choose to represent street addresses as strings, I'll have
an interesting time writing that function! ;-)
I've clearly thwacked this moribund equine quadruped sufficiently.
My much-belabored point is simply that data types per se (as
component concepts of a programming language) are different from
all of the possible things they might represent. The data types
themselves should have simple, uniform treatment by the language.
Whenever there are sufficiently common interpretations of those
data types, it is nice to have features that support those
meanings. (And, of course, any modern programming language should
allow the programmer an easy means of representing application-
level concepts in terms of the built-in data types.)
However, the absence of such intuitive guidance should not deprive
the data type (again, per se) from having a consistent set of
capabilities such as are common to other data types, else they
give up their first-class citizenship in the community!
-jn-
--
; sub REBOL {}; sub head ($) {@_[0]}
REBOL []
# despam: func [e] [replace replace/all e ":" "." "#" "@"]
; sub despam {my ($e) = @_; $e =~ tr/:#/.@/; return "\n$e"}
print head reverse despam "moc:xedef#yleen:leoj" ;
[5/9] from: lmecir:mbox:vol:cz at: 5-Feb-2002 14:25
Hi Joel,
<<Joel>>
...
However, the absence of such intuitive guidance should not deprive
the data type (again, per se) from having a consistent set of
capabilities such as are common to other data types, else they
give up their first-class citizenship in the community!
-jn-
--
; sub REBOL {}; sub head ($) {@_[0]}
REBOL []
# despam: func [e] [replace replace/all e ":" "." "#" "@"]
; sub despam {my ($e) = @_; $e =~ tr/:#/.@/; return "\n$e"}
print head reverse despam "moc:xedef#yleen:leoj" ;
<</Joel>>
Hear, hear! I would say, that a datype, for which the expression:
(type? a)
has got a different meaning, than
(type? (a))
has lost its first class citizenship for sure.
[6/9] from: chalz:earthlink at: 5-Feb-2002 12:28
There's always the case to evaluate for area; whichever coordinate pair would take up
the most area in a plane, that would be the greater one. If they take up the same, then
obviously (2x3 > 3x2) would fail - because it's equal area. It's one solution :/
--Charles
****
> Precedence or not, when presenting X/Y coordinates, I have yet to meet
with someone who places the Y before the X (ever heard about Y/X
coordinates?).
> [...]
Pairs also represent size. If you only compare X then this falls apart when
dealing with size. Which is greater 5x1 or 3x2 ??
Cheers,
Allen K
--
To unsubscribe from this list, please send an email to
[rebol-request--rebol--com] with "unsubscribe" in the
subject, without the quotes.
--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web.com/ .
[7/9] from: chalz:earthlink at: 5-Feb-2002 12:30
I think I get what you're at. Ie, if you can compare a "which comes first?" on strings,
why not order simply based upon left-to-right in pairs, treating them as if they were
strings as well. So, 5x1 is greater than 4x9, but less than 5x2 .. yes? Although, what
actual use this would be, I'm not sure of.
*blinks* What use /do/ you need (pair! > pair!) for, anyways? *pokes original poster*
;) Thought exercise? :)
--Charles
****
Dixit Allen Kamp (09.58 05.02.2002):
>Pairs also represent size. If you only compare X then this falls apart when
>dealing with size. Which is greater 5x1 or 3x2 ??
You miss my point. What I mean is, although there _are_ different ways to look at this,
a simple left-to-right ordering is what is implemented in other cases, so...
But as I said, I'm just a Bear of Very Little Brain...
~H
Prętera censeo Carthaginem esse delendam
--
To unsubscribe from this list, please send an email to
[rebol-request--rebol--com] with "unsubscribe" in the
subject, without the quotes.
--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web.com/ .
[8/9] from: joel:neely:fedex at: 5-Feb-2002 13:23
Hi, Charles,
[chalz--earthlink--net]
wrote:
> I think I get what you're at. Ie, if you can compare a "which
> comes first?" on strings, why not order simply based upon left-to-
<<quoted lines omitted: 3>>
> *blinks* What use /do/ you need (pair! > pair!) for, anyways?
> *pokes original poster* ;) Thought exercise? :)
Please see my post earlier today for more on that last issue. To
me the question is, "Why*shouldn't* there be a built-in meaning
for comparison of *all* built-in data types? The burden of proof
should be on the exception (in this case, not to be able to compare
ordered pairs of integers) to justify its existence as an exception."
To respond more directly to your question, we can *apply* the idea
of an ordered pair of integers to represent all kinds of things.
As soon as the decision is made to forbid ordering of pairs, we have
a limit on the convenience of making future applications of the type.
After all, taking a collection of same-type values and sorting them
is a common enough operation that it seems strange to forbit it
for ordered pairs of integers. Ooops! REBOL *can* sort pair data!
>> foo: [1x1 1x2 2x1 2x2]
== [1x1 1x2 2x1 2x2]
>> sort foo
== [1x1 2x1 1x2 2x2]
Given that "sort" means "put in order" it seems *very* strange to
have a data type that can be sorted but not compared, regardless of
what future uses programmers may make of that data type! It is
certainly unaesthetic to have to define
less-for-pairs?: func [a [pair!] b [pair!]] [
to-logic all [a <> b a = first sort reduce [a b]]
]
just to access the built-in order used by SORT (regardless of
whether that order is "intuitive" -- or not -- for any specific
application).
> ****
> Dixit Allen Kamp (09.58 05.02.2002):
<<quoted lines omitted: 4>>
> implemented in other cases, so...
> But as I said, I'm just a Bear of Very Little Brain...
Not so little, IMHO!
And, as far as the idea of using pair data to represent size, that
is clearly as much a specific application as using string data to
represent street addresses. If one wants to use ordered pairs for
that purpose, then one can define an application-specific order
test:
less-area?: func [a [pair!] b [pair!]] [
(a/x * a/y) < (b/x * b/y)
]
foo: [1x1 1x2 2x1 2x2]
forall foo [
foreach item foo [
print [first foo item less-area? first foo item]
]
]
1x1 1x1 false
1x1 1x2 true
1x1 2x1 true
1x1 2x2 true
1x2 1x2 false
1x2 2x1 false
1x2 2x2 true
2x1 2x1 false
2x1 2x2 true
2x2 2x2 false
because now we're dealing with a specific interpretation of the
data type that has different implications from the notion of a
simple ordered pair of integers.
-jn-
[9/9] from: chalz:earthlink at: 5-Feb-2002 23:35
> Hi, Charles,
>
<snipsnips>
> > ****
> > Dixit Allen Kamp (09.58 05.02.2002):
<<quoted lines omitted: 8>>
> >
> Not so little, IMHO!
Not that I'm the one who said it ;) I forget who posted many of those
ideas, and that particular statement, but t'weren't me - such a compliment
is due someone else ;)
-c
Notes
- Quoted lines have been omitted from some messages.
View the message alone to see the lines that have been omitted