"a simple Print (to a window) statement in each cycle brings the search down
to a crawl."
Too right! I put lots of prints in each run at first until I realised how
much time it took
----- Original Message -----
From: Stephen R. Riese <[EMAIL PROTECTED]>
To: O'Brien, Graham [MI] <[EMAIL PROTECTED]>
Sent: Saturday, January 01, 2000 4:18 PM
Subject: Re: MI Looking for Nearest Object Distance Functions
Message text written by "Graham O'Brien"
>Stephen:
I had a similar problem - I needed to find the distance from a number of
given points to their nearest contour line of a given height. This was
before I found this list, so I solved it in a typical O'Brien brute-force
manner, using a kind of binary chop algorithm:
For each point I created a buffer (with 32 sides as a compromise between
size and circularity) and checked for intersection with the line. If no
intersection, I doubled the buffer radius and tried again.
Once intersection had been achieved I used the usual binary chop method to
successively change the radius by halving increments (adding if no
intersection, subtracting if intersection) until the increment size was
within the tolerable error (I used 0.1 metre).
It worked, but is NOT elegant, and I'll send a .mb file should you so wish.
But I DO hope that someone has a better answer - when applied to a grid of
2,000,000 points it took several weeks of overnight runs (on a P166) to
complete!
Would I do it that way again? No, I'd post on this list and hope!<
Graham,
Thanks. Your method gives me a few ideas I hadn't considered yet.
Actually, I had thought about incrementally expanding a radius of search to
find objects, but had no clue as to how to go about it. The expanding
buffer intersection algorithm (EBIA??) seems reasonable. I like the idea
of bracketing the object separation and halving the distance until within
tolerance. Kind of like the typical strategy to minimize the number of
guesses to pick a hidden number.
I'm experimenting now with a small grid that has 750 cells and must find
the closest of about 50 point objects. It actually runs faster than I
expected (P200) using the brute-force method. The time is measured in
minutes, not tens of minutes, which is a good sign. I also learned how
slow graphic operations are compared to numeric operations. Inserting a
simple Print (to a window) statement in each cycle brings the search down
to a crawl. My eventual grid will likely have tens of thousands of cells
and need to find (for each cell) the closest of hundreds or low thousands
of objects in each of ten to fifteen categories. The old combinatorial
monster is creeping up my back -- much like your problem with 2 million
cells.
Thanks again and Happy New Year!
Steve
[EMAIL PROTECTED]
----------------------------------------------------------------------
To unsubscribe from this list, send e-mail to [EMAIL PROTECTED] and put
"unsubscribe MAPINFO-L" in the message body, or contact [EMAIL PROTECTED]
