Page 1 of 5 12345 LastLast
Results 1 to 10 of 41

Thread: Lonely and not so lonely caches

  1. #1
    Join Date
    Jun 2004
    Location
    Bangor, ME
    Posts
    6,059

    Default Lonely and not so lonely caches

    I was prodded by someone in chat for some numbers regarding what caches were the most remote, so I made a macro in 5 minutes that took 1.5 hours to run to come up with these (useless?) stats. It's too bad it takes so long to run or I might incorporate some of this into the regular stats. I have a few ideas on how to speed it up, but I am not sure it will speed it up enough to satisfy me.

    The loneliest active cache in Maine is Little Falls Cache (GCWMFE) by Sudonim (2/2). It is just under 17.5 miles from any other cache in the state. Second loneliest is a distant second at 14.5 miles, Harrow Mountain Fault (GC1GDJZ) by Northwoods Explorer (5/5), and third drops into the 11's.

    Number active of caches between 11 and 12 miles from another cache: 2
    Number active of caches between 10 and 11 miles from another cache: 1
    Number active of caches between 9 and 10 miles from another cache: 1
    Number active of caches between 8 and 9 miles from another cache: 2
    Number active of caches between 7 and 8 miles from another cache: 2
    Number active of caches between 6 and 7 miles from another cache: 7
    Number active of caches between 5 and 6 miles from another cache: 24
    Number active of caches between 4 and 5 miles from another cache: 56
    Number active of caches between 3 and 4 miles from another cache: 73
    Number active of caches between 2 and 3 miles from another cache: 202
    Number active of caches between 1 and 2 miles from another cache: 651
    Number active of caches between .5 and 1 mile from another cache: 931
    Number active of caches between 0 and .5 mile from another cache: 2581
    Number active of caches between 0 and .4 mile from another cache: 2306
    Number active of caches between 0 and .3 mile from another cache: 1899
    Number active of caches between 0 and .2 mile from another cache: 1298
    Number active of caches between 0 and .1 mile from another cache: 328*

    Bear in mind, this includes events, eathcaches, virtuals, and mystery caches which are often allowed within .1 miles of another cache.

    The average distance between Maine caches is .38 miles.

    The median distance of all Maine caches is .39 miles. This means 1/2 of the total Maine caches are further then .39 miles from another cache, and the other half is less than that.
    DNFTT! DNFTT! DNFTT!

    "The funniest thing about this particular signature is that by the time you realize it doesn't say anything it's to late to stop reading it..."

  2. #2
    Join Date
    Sep 2005
    Location
    Bangor, ME
    Posts
    3,961

    Default

    I like the lonely caches, last month I had 2 co-ftfs on caches that were placed almost a year ago. (GC1HF5B, GC1HF4N) They may be lonely, but they're worth the drive, I'll use any excuse to get out...
    Once the game is over, the king and the pawn go back in the same box.

  3. #3
    Join Date
    May 2009
    Location
    Orlando, Florida
    Posts
    285

    Default

    Speeding up algorithms is fun Any way I could help?

    Is the script's runtime n^2 (so comparing each cache to each other cache)? If so, maybe you can try out SQL to speed it up? I don't know how familiar you are with SQL or if that was what you already had in mind, but I have some ideas that I THINK would let you get that data with a single SQL query rather than nesting loops. The query will use a cross product, so all records will still be compared to each other, but my guess would be that it will likely be a little bit quicker than the nested loops. Let me know if you'd like to hear out those ideas

  4. #4
    Join Date
    Jun 2004
    Location
    Brewer, Maine
    Posts
    1,808

    Default

    Cool slant on cache density. I think that overall, Northwoods Explorer wins the lonliest cache as Little Falls cache is about 1.5 miles away from a Canadian cache. Lonliest in Maine, yes, lonliest overall, no.
    Harrow Mountain looks very isolated, but if you park in the right spot, looks like a 2/3 mile over fairly level ground to get to the cache spot. May have to try that before snow flies...
    Thanks again Dave for the cool views you can generate. For a "not about the numbers" guy, you sure give us all lots of them to see

  5. #5
    Join Date
    Jun 2004
    Location
    Gainesville, Georgia
    Posts
    3,875

    Default

    Quote Originally Posted by benandtina View Post
    Speeding up algorithms is fun Any way I could help?

    Is the script's runtime n^2 (so comparing each cache to each other cache)? If so, maybe you can try out SQL to speed it up? I don't know how familiar you are with SQL or if that was what you already had in mind, but I have some ideas that I THINK would let you get that data with a single SQL query rather than nesting loops. The query will use a cross product, so all records will still be compared to each other, but my guess would be that it will likely be a little bit quicker than the nested loops. Let me know if you'd like to hear out those ideas
    HUH?????
    Just smile it won't crack your face

    The statistics on sanity are that one out of every four persons is
    suffering from some sort of mental illness. Think of your three best
    friends -- if they're okay, then it's you.

  6. #6
    Join Date
    Jun 2004
    Location
    Solon, Maine
    Posts
    5,940

    Default

    Quote Originally Posted by Haffy View Post
    HUH?????
    Sheesh! I'm still on Google, trying to figure out what language what was.

  7. #7
    Join Date
    Jun 2004
    Location
    Bangor, ME
    Posts
    6,059

    Default

    Quote Originally Posted by benandtina View Post
    Speeding up algorithms is fun Any way I could help?

    Is the script's runtime n^2 (so comparing each cache to each other cache)? If so, maybe you can try out SQL to speed it up? I don't know how familiar you are with SQL or if that was what you already had in mind, but I have some ideas that I THINK would let you get that data with a single SQL query rather than nesting loops. The query will use a cross product, so all records will still be compared to each other, but my guess would be that it will likely be a little bit quicker than the nested loops. Let me know if you'd like to hear out those ideas
    The macro I use for the stats created an SQL database, and a good portion of the stats is calculated from the resulting SQL.

    However, for this I just made a macro using GSAK's GetNear function. It cycles through each cache and enters the coordinates into the GetNear function and the result is a delimited string which includes the distance to the 2 nearest caches (the first nearest is the cache I am checking the distance to). This is the simple macro:

    Code:
    GOTO position=top
    WHILE NOT($_EOL)
    	$Data = getnear($d_latitude + " " + $d_Longitude, "M", 2)
    	$Distance = Extract($Data, ";", 7)
    	$d_User2 = $Distance
    	GOTO position=next
    ENDWHILE
    	MsgOK msg="Finished!"
    ENDSUB
    I might try using my stats SQL database at a later time, I knew this would work and it was quick to write. GSAK is migrating to a full SQL database in the near future which will make a lot of this much easier.

    The hardest part I have about using SQL is efficiently getting the distances to the nearest caches using only the coordinates. In order to do this you currently have to calculate the distances from each cache 4534 times (the number of available caches in the state in my DB). That is over 2 million distance calculations! But I am open to any ideas!

    While we're talking math, if you or anyone else can come up with a better formula for me to predict the "Future Milestone Date Predictions" section of my stats I'd be all ears. I know little about how to calculate predictions, my 10 second lame formula is

    Code:
    $PredictedCachesPerDay = (($TotalCaches/(DateDiff($DateFirst,$DateToday))) + ($LastYearTotal/(DateDiff($OneYearAgo,$DateToday))*2))/3
    I'm not even sure I remember what that code does! But IIRC it puts more emphasis on the average number of caches placed per day in the last year than it does the average for all time.

    I then take and calculate at what date at the calculated rate per day will occur.
    Last edited by brdad; 09-09-2009 at 03:59 PM.
    DNFTT! DNFTT! DNFTT!

    "The funniest thing about this particular signature is that by the time you realize it doesn't say anything it's to late to stop reading it..."

  8. #8
    Join Date
    Jun 2004
    Location
    Bangor, ME
    Posts
    6,059

    Default

    I actually let this script run again today, but I calculated the 100 cache radius.

    For this lonely cache story:

    The cache which has the greatest radius to 99 other caches is Moody Bridge Spring (GC16E79) by Northwoods Explorer (2/2).The 100 cache radius from this point is 73.5 miles.


    The cache which has the smallest radius to 99 other caches is Baxter Sundial (GC150MN) by NorthCumberMouth Cachers (2/2). There are 100 caches within 2.01 miles of this cache!
    DNFTT! DNFTT! DNFTT!

    "The funniest thing about this particular signature is that by the time you realize it doesn't say anything it's to late to stop reading it..."

  9. #9
    Join Date
    May 2009
    Location
    Orlando, Florida
    Posts
    285

    Default

    Quote Originally Posted by brdad View Post
    The macro I use for the stats created an SQL database, and a good portion of the stats is calculated from the resulting SQL.

    However, for this I just made a macro using GSAK's GetNear function. It cycles through each cache and enters the coordinates into the GetNear function and the result is a delimited string which includes the distance to the 2 nearest caches (the first nearest is the cache I am checking the distance to). This is the simple macro:

    Code:
    GOTO position=top
    WHILE NOT($_EOL)
    	$Data = getnear($d_latitude + " " + $d_Longitude, "M", 2)
    	$Distance = Extract($Data, ";", 7)
    	$d_User2 = $Distance
    	GOTO position=next
    ENDWHILE
    	MsgOK msg="Finished!"
    ENDSUB
    I might try using my stats SQL database at a later time, I knew this would work and it was quick to write. GSAK is migrating to a full SQL database in the near future which will make a lot of this much easier.

    The hardest part I have about using SQL is efficiently getting the distances to the nearest caches using only the coordinates. In order to do this you currently have to calculate the distances from each cache 4534 times (the number of available caches in the state in my DB). That is over 2 million distance calculations! But I am open to any ideas!
    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

    Quote Originally Posted by brdad View Post
    While we're talking math, if you or anyone else can come up with a better formula for me to predict the "Future Milestone Date Predictions" section of my stats I'd be all ears. I know little about how to calculate predictions, my 10 second lame formula is

    Code:
    $PredictedCachesPerDay = (($TotalCaches/(DateDiff($DateFirst,$DateToday))) + ($LastYearTotal/(DateDiff($OneYearAgo,$DateToday))*2))/3
    I'm not even sure I remember what that code does! But IIRC it puts more emphasis on the average number of caches placed per day in the last year than it does the average for all time.

    I then take and calculate at what date at the calculated rate per day will occur.
    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).

  10. #10
    Join Date
    May 2009
    Location
    Orlando, Florida
    Posts
    285

    Default

    Thinking a little more, I wonder if there would be a kinda hackish way to optimize? For all I know, GetNear() already does something along these lines, but this is me thinking about it out loud...

    I wrote a macro that can go through a database and determine which DeLorme grid every cache is in. Suppose you run this on the set of all Maine caches and store the values.

    Now, suppose you also store a mapping of which grids are adjacent to each other.

    At the most, you probably only want to compute distances between caches in the same grid or in one of the 8 adjacent grids. The rest of the caches are guaranteed to be way more than 12 miles away. Right?

    Just some thoughts. I don't know if the overhead of figuring out what to/not to compare would make it not be worth it.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •