Pair comparison (was: native? :==)

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?). [...]

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

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

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

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:

== 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" ;

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/ .

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/ .

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!

== [1x1 1x2 2x1 2x2]

== [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).

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-

<snipsnips>

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