Hi,
although your question has a little in common with Rebol, my answers are as
follows:
1. It would be more precise to interleave each bit - ie. each binary digit -
as the smallest unit of information
2. in that case the bit - sort yields:
[0,0 2,2 1,5 5,1]
3. as you pointed out, the result of the sort doesn't depend on the
representation, but on the comparison function, any suitable representation
can do
4. your suggestion doesn't work, because you need close things in the terms
of distance to remain close in the terms of sort. Your suggestion works only
in the neighborhood of the 0,0 point
Best regards
Ladislav
----- Original Message -----
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, September 25, 2000 1:04 PM
Subject: [REBOL] Interleaving of strings question
> I was thinking about the earlier postings about
> sorting coordinates by interleaving digits of the 2
> axis values. The interleaving, it would seem, is to
> make the longitude as significant as the latitude, in
> terms of distance from other points. Ignoring the
> need to have the lat/long pairs stored that way for
> later processing, and ignoring stated expected values
> for the coordinates I thought:
>
> 1. Wouldn't it be more precise to interleave each
> digit?
>
> 2. In terms of a regular x,y system, even that would
> be incorrect sometimes. E.G.: [ 0,0 1,5 2,2 5,1 ] (a
> sorted set of simplified coordinates) isn't correct.
> 2,2 is closer to 0,0; 1,5 and 5,1 are the same
> distance from 0,0.
>
> 3. Could pairs or tuples be used? Answer: pairs
> didn't sort that way and I have no reason to assume
> sort would think of tuples as coordinates.
>
> 4. Wouldn't it be the least convoluted to have a
> /compare function for sort that understood that all
> components of the coordinate were equally significant?
> That way there's no manipulating the coordinates, and
> it should be the most precise.
>
> Would a Pythagorean type thing work, because it looks
> like simply summing the absolute differences between
> each coordinate component isn't right:
>
> 1,1 to 1,5 = 4 ((1-1)+(5-1))
> 1,1 to 2,4 = 4 ((2-1)+(4-1))
>
> yet 2,4 is closer to 1,1 than is 1,5. Until the real
> distance is needed, I don't think you'd have to take
> the square root of the sum (and how do you do that for
> 3-dimensions, does it become cubed and cube root -
> aha)
>
> (ABS(x1-x2) to the nth) + (ABS(y1-y2) to the nth) ...
> + (ABS(n1-n2) to the nth)
>
>
> Comments? Is this right?
>
> __________________________________________________
> Do You Yahoo!?
> Send instant messages & get email alerts with Yahoo! Messenger.
> http://im.yahoo.com/
>
>
