Re: Point System ideas
Posted: February 22nd, 2012, 2:17 pm
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.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.
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!
)
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.rocketsciguy wrote: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.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.
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.Corfman Clan wrote: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.rocketsciguy wrote: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.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.
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.
Code: Select all
cache_current_value = (age_in_days - num_days_found) * point_per_day_factor / num_unique_findersWhat's there to slamRedfist wrote:More than a day has passed and no-one is slamming my "bonus points" idea? lol...
Redfist and I can hide anything in the code and well, um, yeah, there you have itBlue Roads wrote:You can kinda hide that in the code, and if you make it complicated enough, nobody will notice.
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.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:Only one additional computation is required per cache (num_days_found), which is pretty simple with a database.Code: Select all
cache_current_value = (age_in_days - num_days_found) * point_per_day_factor / num_unique_finders
...
Anyway, just an idea I thought I'd throw out there.
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: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?
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.48356835955604Cheaters! Er... I mean, well, that's a ... convenient ... piece of functionality to have available.Redfist wrote:We let the database engine compute it.
http://msdn.microsoft.com/en-us/library/bb933808.aspx