I don't think there is any real magic here. The only thing I can
think of is nested if's in your testing. This allows each check to
exit as soon as one of the coordinates does not match. I believe
that this would be faster than stringing all checks together with
"AND" because Lingo evaluates all items of an if before proceeding.
(Untested:)
global gBigList
on FindMatch theH, theV
nItems = count(gBigList)
repeat with i = 1 to nItems
lThisSet = gBigList[i]
if theH >= lThisSet[1] then
if theH <= lThisSet[2] then
if theV >= lThisSet[3] then
if theV <= lThisSet[4] then
-- Found it
return i -- this returns the number of the rect
-- or
-- return lThisSet -- to return the list of four coordinates
end if
end if
end if
end if
end repeat
alert("No match")
end
At 10:33 AM -0700 6/27/02, Watson, Christopher wrote:
>OK, I need a little guidance here.
>
>I have a list with 9500+ elements in it. Each element in this big list is a
>four-item list which acts as bounding box limits. Looks like this...
>
>[[0.0, 2.5, 0.0, 2.5], [2.5, 5.0, 0.0, 2.5] ... [350.0, 360.0, 88.5, 90.0]]
>
>The first item in each internal list is the minimum horizontal value (the
>left) for that particular bounding box, the second is the maximum horizontal
>value (the right), the third is the minimum vertical value (the top), and
>the fourth is the maximum vertical value (the bottom).
>
>Then I have two floating point values, which act as x and y (or h and v)
>coordinates, like these...
>
>124.357892
>20.736474
>
>What I need to do is search the big list for an element which contains a
>bounding box within which BOTH the floating point values would physically
>lie. For example, if I were to successfully find the "box" element in which
>124.357892 and 20.736474 resided, I might find the element [122.5, 125.0,
>20.0, 22.5]. That specific "box" element contains the horizontal coordinate
>(124.357892 falls between 122.5 and 125.0) and the vertical coordinate
>(20.736474 falls between 20.0 and 22.5).
>
>I hope that makes sense.
>
>Important: There is only ONE bounding box in the big list in which the
>coordinates will lie, and there will always be ONE. The bounding box values
>are not in numeric order of any kind, and it can't be reliably sorted in
>such a way that a binary search can be implemented on this.
>
>What would be the speediest way to perform this search? I'm sure there's a
>tricky way to do this. I just can't come up with it.
>
--
Lingo / Director / Shockwave development for all occasions.
(Home-made Lingo cooked up fresh every day just for you.)
[To remove yourself from this list, or to change to digest mode, go to
http://www.penworks.com/lingo-l.cgi To post messages to the list, email
[EMAIL PROTECTED] (Problems, email [EMAIL PROTECTED]). Lingo-L is for
learning and helping with programming Lingo. Thanks!]
