Lonely and not so lonely caches

[brdad]

I didn't know there was a GetNear() function. My thought was that if you are iterating over all n^2 (n is number of caches, so 4534 I guess) and calculating distance (using the sqrt((x1-x2)^2+(y1-y2)^2) or whatever formula) you would be better off with a query that computes the n^2 distances but likely has less overheard. However, with GetNear() that may not be the case. On the other hand, we have no way of knowing what GetNear() is doing behind the scenes so it could have some crazy overhead of it's own. I'm curious now, so if I have time maybe I'll fool with it a little tonight

GSAK has a decent explanation of its macro functions and abilities in it's help section. Another way I can have it take less time is to only update the caches which are affected by new caches or the loss of a cache by archival. That way, the first time it was run it would be slow, but subsequent runs would be faster. That is the way the elevation macro works now.

Cano told me about an evolution algorithm he came up with that would predict where new caches are being placed based on current cache density. It sounded pretty impressive, but when he explained the theory to me my eyes glazed over a little bit. Maybe you can get his thoughts? I think he mentioned that he'll be at one of the upcoming events, but I'm not sure which one(s).

The only thing I know about evolution is I definitely evolved from an ape! I'll have to ask him or perhaps he can enlighten me here, or at least help predict the dates, let alone the place!