Page 4 of 5

Re: Point System ideas

Posted: February 22nd, 2012, 2:17 pm
by Redfist
I'm using DATEDIFF(day,date1,date2). That returns the # of days. If we then want N points per year, just multiply that by the appropriate ratio.

Re: Point System ideas

Posted: February 22nd, 2012, 5:18 pm
by rocketsciguy
Redfist wrote:I'm using DATEDIFF(day,date1,date2). That returns the # of days. If we then want N points per year, just multiply that by the appropriate ratio.
It's déjà vu all over again! I think we went down this road a month ago. I'm guessing Corfman Clan would rather use his routine to calculate the cache age instead of this SQL function, because of the desire to accurately mark the cache's birthday/anniversary.
rocketsciguy wrote:CC, not to beat a dead horse to death (because that would be redundant), but I take it you have some canned routines or functions to do date comparisons like you've shown? I only ask because I know how surprisingly and strangely difficult it can be to do date differences like you've shown, separating the full-year age from the days elapsed in the current year. I assume the database will store published and find dates as serial/Julian days rather than as separate year, month, and day fields, or as year and day-of-year fields, which is why I figured you would do an arithmetic subtraction to get the age in days (because that's how I'd do it), rather than age in years plus days since "birthday". I'm not sure how date data is delivered via the API, so maybe it is trivial to just convert and store the data in what ever form is easiest.

I concede that this sort of data is not what I handle on a regular basis, and certainly the code required already exists. I'm just not sure what kind of flexibility you have with user functions (e.g.) in making your SQL queries, etc. Then again, in the time it took me to write this post, I probably could have dug up an appropriate algorithm in my language of choosing, or devised and written my own... :) (BTW, like I've said before, I don't mean to doubt your or RedFist's abilities -- I'm just thankful you've volunteered to do it! :D )

Re: Point System ideas

Posted: February 22nd, 2012, 5:51 pm
by Corfman Clan
rocketsciguy wrote:
Redfist wrote:I'm using DATEDIFF(day,date1,date2). That returns the # of days. If we then want N points per year, just multiply that by the appropriate ratio.
It's déjà vu all over again! I think we went down this road a month ago. I'm guessing Corfman Clan would rather use his routine to calculate the cache age instead of this SQL function, because of the desire to accurately mark the cache's birthday/anniversary.
My assumption is that the ratio that Redfist mentions is: 1/365.25. So for N=100, That's not exactly 100 points a year (99.932 in a normal year and 100.205 in a leap year), but I think it is close enough. I must admit, I like my algorithm more, however I'm very happy to use Redfists because there is a huge benefit to using it.

Using my algorithm, we'd need to calculate the points outside of the database engine. That means that to update the points in the database, we would need to perform a separate database update for each and every cache. With Redfist's algorithm, we let the database engine calculate the points for an update to all caches at once. That's a huge savings.

Re: Point System ideas

Posted: February 22nd, 2012, 5:55 pm
by Redfist
Corfman Clan wrote:
rocketsciguy wrote:
Redfist wrote:I'm using DATEDIFF(day,date1,date2). That returns the # of days. If we then want N points per year, just multiply that by the appropriate ratio.
It's déjà vu all over again! I think we went down this road a month ago. I'm guessing Corfman Clan would rather use his routine to calculate the cache age instead of this SQL function, because of the desire to accurately mark the cache's birthday/anniversary.
My assumption is that the ratio that Redfist mentions is: 1/365.25. So for N=100, That's not exactly 100 points a year (99.932 in a normal year and 100.205 in a leap year), but I think it is close enough. I must admit, I like my algorithm more, however I'm very happy to use Redfists because there is a huge benefit to using it.

Using my algorithm, we'd need to calculate the points outside of the database engine. That means that to update the points in the database, we would need to perform a separate database update for each and every cache. With Redfist's algorithm, we let the database engine calculate the points for an update to all caches at once. That's a huge savings.
Agreed on all points. With the update query I'm currently running (my db only has ~14000 caches), it finishes in less than 1 second. To do so otherwise would either be doing the update query in code manually (acting as the query processor) or integrating a stored procedure for the QP to call which then becomes pretty tightly bound to 1 database engine's implementation. It likely still wouldn't take a ton of time BUT would be more prone to error.

Re: Point System ideas

Posted: April 14th, 2012, 9:27 pm
by rocketsciguy
And you thought this discussion was dead? Tee hee... ;)

I had another idea the other day about ways to penalize frequently-found / power-trail caches compared with lonely caches. And fortunately, it can be expressed in a single sentence: "A cache increases in value only on days on which it is not found." Mathematically, this might be expressed:

Code: Select all

cache_current_value = (age_in_days - num_days_found) * point_per_day_factor / num_unique_finders
Only one additional computation is required per cache (num_days_found), which is pretty simple with a database. What might this do to cache point values? Let's take 3 hypothetical caches, each just celebrating their 2 year anniversary (with no leap years).
  • Cache A is a backcountry hide with 4 unique visitors on 3 different days. The DGP value of this cache is 50.00 CPs (if it's truly 100 CPs/yr); the unmodified LCP value as settled upon (with the point per day factor = 100/365.25) is 49.97 pts; and with my suggested modification 49.76 pts. Basically no change.
  • Cache B is a shopping mall LPC and had 100 unique visitors on 90 unique days. This is a 2 CP cache on DGP; 1.999 LCP points. With my modification, this cache now has its total points to give reduced from 200 to 175.2, so now each unique finder only receives 1.752. Not a huge change, but in the aggregate it reduces finders' scores which are heavy with these kinds of park-and-grab caches.
  • Cache C is a member of a popular power trail and had 1000 unique visitors on 500 days. This cache is worth 0.2 CPs on DGP and LCP (essentially). If there are 1000 caches on this power trail with the same stats, completing the trail would get you 200 points added to your score. With my modification, each cache like this would have its points-to-give reduced from 200 to 63 (because only 31.5% of days in its life were "lonely"). Each finder would receive just 0.063 points per cache, and completing the entire trail would get you 63 points.
This sharp reduction in value would only occur with power trail or shrine caches that are found on a nearly daily basis. In fact, if a cache is found daily (the antithesis of a "Lonely Cache"), it would be worth zero points. I understand that power trails are not zero-effort excursions, but using this method disincentivizes them (did I make up that word?) to the extent that if you care about the points, it becomes more worthwhile to find a backcountry moderately lonely cache worth 70 points instead of spending a weekend hoping in and out of a car along a highway.

Anyway, just an idea I thought I'd throw out there.

Re: Point System ideas

Posted: April 15th, 2012, 9:06 am
by afudc
I kind of like rocketscienceguy's idea. I see it as giving truly lonely caches a little more sway in the system. Not a big deal to me though.

Re: Point System ideas

Posted: April 15th, 2012, 9:39 am
by Blue Roads
I kinda like it too. Probably because I'm not a big fan of power trails anyway. There would be a slight drop in points for me on the caches that I do get because I just plain can't get to the really lonely ones. Just can't hike that far any more.

Re: Point System ideas

Posted: April 15th, 2012, 2:36 pm
by Redfist
I think that's an interesting idea to consider.

I also think that there should be bonus points for anyone with "fist" or "Clan" in their geocaching name! ;)

Re: Point System ideas

Posted: April 16th, 2012, 10:36 pm
by Redfist
More than a day has passed and no-one is slamming my "bonus points" idea? lol...

Re: Point System ideas

Posted: April 17th, 2012, 4:30 pm
by Blue Roads
You can kinda hide that in the code, and if you make it complicated enough, nobody will notice. :lol:

Re: Point System ideas

Posted: April 17th, 2012, 4:31 pm
by Corfman Clan
Redfist wrote:More than a day has passed and no-one is slamming my "bonus points" idea? lol...
What's there to slam :?:

Re: Point System ideas

Posted: April 17th, 2012, 4:39 pm
by Corfman Clan
Blue Roads wrote:You can kinda hide that in the code, and if you make it complicated enough, nobody will notice. :lol:
Redfist and I can hide anything in the code and well, um, yeah, there you have it :twisted:

Re: Point System ideas

Posted: April 17th, 2012, 4:55 pm
by Corfman Clan
rocketsciguy wrote:And you thought this discussion was dead? Tee hee... ;)

I had another idea the other day about ways to penalize frequently-found / power-trail caches compared with lonely caches. And fortunately, it can be expressed in a single sentence: "A cache increases in value only on days on which it is not found." Mathematically, this might be expressed:

Code: Select all

cache_current_value = (age_in_days - num_days_found) * point_per_day_factor / num_unique_finders
Only one additional computation is required per cache (num_days_found), which is pretty simple with a database.
...
Anyway, just an idea I thought I'd throw out there.
That is an interesting idea. It might be interesting to see what the overall effects would be to use one over the other though I'm not convinced there really would be much difference in the end except lowering everyone's score by some amount.

The biggest drawback that I see to this is that it removes the simplicity of the scoring system. Remember what I wrote above.

Re: Point System ideas

Posted: April 17th, 2012, 9:09 pm
by cosninocanines
KISS Keep it Simple!

I here you on all the ideas and what if's, but let's let the folks get it up and running. I really want to see my "new" "MOST WANTED".

Keep Up the good work, I'm sincerely sorry I don't have the knowledge or skills to help.

Re: Point System ideas

Posted: August 20th, 2012, 8:18 am
by UtahSteve
Just exploring the new site and it looks awesome. I was only on DGP for 1 month before it collapsed, but didn't realize how much I missed it until LonelyCache went online.

That having been said, one of my favorite features was the MOST WANTED list. When would you anticipate this one being on Lonely Cache?

Re: Point System ideas

Posted: August 20th, 2012, 9:56 am
by Corfman Clan
UtahSteve wrote:Just exploring the new site and it looks awesome. I was only on DGP for 1 month before it collapsed, but didn't realize how much I missed it until LonelyCache went online.

That having been said, one of my favorite features was the MOST WANTED list. When would you anticipate this one being on Lonely Cache?
The Most Wanted List seems to be a popular request. Last night I just happened to start designing the database query to do that. I wanted to see how long it takes to compute the distance. It isn't so bad, the query returns fairly quickly. Here's my top 20:

Code: Select all

GC Code    Cache Name                                     Miles             NextFindPts       PtsPerMile
---------- ---------------------------------------------- ----------------- ----------------- -----------------
GC3FDB7    Deem Hills { tea time 5 } hike                 1.77042634103925  39.9726214        22.577963552291
GC20A37    Ssptv 8pf 1 Lpa44 k 0536 y4 8219Pk             8.09077716084121  121.69746745      15.0415052881455
GC2D11V    Man Over Board!!!                              14.3953133628613  203.6960985       14.150167722331
GC296TB    Point Three Three Three                        6.00569481468983  74.5608031        12.4150169798215
GC2K253    Four Corners ?                                 5.42264686668998  56.9472963666667  10.5017526987568
GC2NZ8H    V Note ?                                       3.8376353476889   37.57700205       9.79170730033785
GC2FGEE    Smoking Banana Peels or The Original Smooth ?  6.7995855562828   62.9705681        9.26094209400973
GC2WBMC    Point Three Three Three (Easy Version)         4.79800546930245  41.3415468666667  8.61640261378798
GC2PBKN    Crazy Eights                                   6.13311822851252  49.0987907666667  8.00551839004328
GC2M6HR    May the Force be with You                      6.92346715152263  53.7531371        7.76390440274977
GC2MQMA    BxPxRx                                         6.77506129120629  52.3842117        7.73191701866848
GC2MBW4    Soup of the Day ?                              6.89688951748818  53.1143052666667  7.70119705875913
GC2D3VZ    A stitch in time saves Nine                    13.8260956284237  98.97330595       7.15844216689277
GC29F6W    Happy Aniversary My Dear!                      37.1355624894822  222.0396988       5.97916616620222
GC2J392    I Love Moms Homemade Pumpkin Pi                9.66136815770371  57.6773899        5.96989877194667
GC38EM3    Leftovers and Beer ?                           5.61589898685403  31.89596165       5.67958250756711
GC2TBW9    It's Seven A.M. in Phoenix ?                   5.94768323186123  33.6071184        5.65045532686905
GC2P7DZ    Scrambled Fish ?                               6.66325457068651  36.89253935       5.53671467278174
GC295N9    Archimedes                                     13.5304715709179  74.7433264666667  5.52407401877393
GC3BC7P    AZCampbell's Love Notes are Noncents!!!        4.69325732123883  25.73579735       5.48356835955604
Now moving from a DB query to a web page will take some work. If we add the "exclude caches" feature that DGP has, then we'll need to add another database table and access routines just for that.

At any rate, we've noticed this is a popular request and will prioritize it accordingly. :geek:

Re: Point System ideas

Posted: August 21st, 2012, 7:44 am
by UtahSteve
Very cool. Thanks for keeping us posted.

Re: Point System ideas

Posted: August 21st, 2012, 8:11 am
by rocketsciguy
This is more a Nuts-N-Bolts question, and this topic is off-topic of this thread, but anywho.... What equation(s) are you using to compute distance (great circle, etc.)? If you have a link, I'd like see the formulation. :geek:

Re: Point System ideas

Posted: August 21st, 2012, 8:16 am
by Redfist
We let the database engine compute it.

http://msdn.microsoft.com/en-us/library/bb933808.aspx

Re: Point System ideas

Posted: August 21st, 2012, 8:44 am
by rocketsciguy
Redfist wrote:We let the database engine compute it.

http://msdn.microsoft.com/en-us/library/bb933808.aspx
Cheaters! Er... I mean, well, that's a ... convenient ... piece of functionality to have available.

I would like to know how it works, but it appears to be a black box. Or at least Microsoft's documentation at that link is about as helpful as its "Help" documentation for its MS Office products. :evil: Can you provide a usage example? Do you select the physical model to use (WGS-84), provide it with constants (Earth radii, eccentricity), or is it using a geoid model with higher level harmonics, or is it a basic spherical great circle calculation where you provide the radius? Have you tried validating the STDistance calculation against other distance calculations? (FizzyCalc has your choice of three!) ;)

Sorry for the geek mode. This is in my line of work and can help if needed, but you might not need any.