Point System ideas

[Corfman Clan]

Kripes, don't make it so complicated. It's not and there is no reason to make it so.

Don't worry, I know how to write understandable and testable specifications. I've done it for more projects than I care to think about

[jcanyoneer]

Unless we go for something overly complicated and/or stay with DGP's method, when the database does its calculation, it's going to subtract the publication date from the current date to find the number of days the cache has been active, then multiply it by a factor to get the total points available.

I know the point/day has ZERO support, but this statement shows that it is the simplest system programatically-no factor to multiply by. 1 day is 1 point, 1 week is 7 points, 2 months is about 60 points. If I'm going for a lonely cache and can see it's worth a 91 points, I know its either been out for 91 days if unfound or found once, 182 days if found twice, 273 days if found 3 times...no factor needed. A day still seems like the simplest, straight up unit that doesn't need a factor...just subtract the the 2 dates and be done with it.

[Corfman Clan]

Unless we go for something overly complicated and/or stay with DGP's method, when the database does its calculation, it's going to subtract the publication date from the current date to find the number of days the cache has been active, then multiply it by a factor to get the total points available.

I know the point/day has ZERO support, but this statement shows that it is the simplest system programatically-no factor to multiply by. 1 day is 1 point, 1 week is 7 points, 2 months is about 60 points. If I'm going for a lonely cache and can see it's worth a 91 points, I know its either been out for 91 days if unfound or found once, 182 days if found twice, 273 days if found 3 times...no factor needed. A day still seems like the simplest, straight up unit that doesn't need a factor...just subtract the the 2 dates and be done with it.

Guys, don't worry. However we do it, the math is really simple. For some number P (e.g. P=100) points per year:

Code: Select all

Total Points = P * (years + <day in year>/<days in this year>)

[rocketsciguy]

Kripes, don't make it so complicated. It's not and there is no reason to make it so.

Sorry Corfman Clan to make things seem more complicated. It's what I do!

I know the point/day has ZERO support, but this statement shows that it is the simplest system programatically-no factor to multiply by. 1 day is 1 point, 1 week is 7 points, 2 months is about 60 points. If I'm going for a lonely cache and can see it's worth a 91 points, I know its either been out for 91 days if unfound or found once, 182 days if found twice, 273 days if found 3 times...no factor needed. A day still seems like the simplest, straight up unit that doesn't need a factor...just subtract the the 2 dates and be done with it.

jcanyoneer, I see a few advantages with 1 point per day, especially with the "higher resolution" on cache and cacher scores. I liked watching my score move, as well as my hides and finds, and couldn't wait for the next update to see what the new scores were on my caches (hey, I'm a new hider). But personally, I like keeping it around 100/yr, 10/mon, 2/wk. We don't often think of cache age in days (or even weeks) unless we're chasing FTFs... well, maybe that would be a reason to change it.

Speaking of changing everything, let me throw this out there. I don't necessarily think this is the way to go, but this is something we have the ability to control if we want to change how the new system works vs DGP. A lot of people have been commenting that it would be good to hide, not count, or otherwise diminish the value of "power trails" and park and grabs. For example, compare finding one 100-CP backcountry hide with finding one hundred 1-CP power trail micros. Both tasks take a lot of work (I've never done either so I can't say), but the consensus in this group is that the backcountry option ought to be worth quite a bit more (or the power trail option worth quite a bit less, whatever your preference). But according to the DGP calculation, these two scenarios are worth the same (ignoring the effect of CPs changing after finding a cache). But we could "fix" this quite effectively with a small change to the point formula.

The DGP Challenge Point formula is (100 CP/year)*(age in years)/(number of finds), or generically C * A / x, where A is the age, x is the number of finds, and C is the constant we've been discussing. Just keeping with C = 100 points/year for comparison purposes, let's consider changing the formula to C * A / x^n where n is an exponent of our choosing designed to diminish low value hides. Here's what happens with a one-year-old cache (log-log plot for ease in differentiating the lines):

Table of possible point values for C * A / x ^ n for differing values of n and C*A = 100. Possible method to diminish value of power trail hides from Lonely Caches.

CP_100A_x^n.png (8.45 KiB) Viewed 13649 times

The blue line is the DGP formula, with n=1. As you increase n, the cache loses points more quickly the more times its found. So picking a value for n could be as simple as answering the question, "How many power-trail micros worth 1 CP on DGP does is take to match a 100 CP backcountry cache?" If the answer is 100, just stick with the DGP formula. If it's 1000, then use n=1.5. I'm guessing it's somewhere in between. Comments?

Here's a table, if you prefer:

Family of curves for C * A / x ^ n for differing values of n and C*A = 100. Possible method to diminish value of power trail hides from Lonely Caches.

CP_100A_x^n_table.png (9.85 KiB) Viewed 13649 times

This could work with number of finds, or it could work with calendar days on which it is found, by changing the meaning of x. There is no comparable curve with DGP in this case unless you assume every find is on a different day. The consequence of changing x from "Number of Finds" to "Days on which it is Found" inflates power trails -- which is undesirable -- so having a value of n > 1 would counteract that switch.

Just an idea.

For reference, I just looked at [gc=GC32B8D]"1500-E.T."[/gc], the last cache on the new ET Highway power trail. As of writing, it's been up 154 days and received 478 Found It logs, giving a DGP score of 0.0883 CPs. If this is typical of the New ET Highway, then it takes 1133 ET caches to match one 100-CP backcountry hide, if individual points are not rounded. But this has been an especially popular destination lately with the resurrection of this trail, so this might be a bad example. I don't know where DGP rounded cache values -- obviously they were reported at whole numbers, but when tallying scores, maybe the fractional points were carried. If cache points are rounded before being summed, than every cache on ET is probably worth 0 CPs and doing the whole trail would net a cacher nothing. As I recall, DGP never said "0 CPs", it was always "<1 CP", which suggests to me that those fraction CPs add up in a finder's score. But we could use rounding to "fix" powertrails. For this example and at this time, rounding to the nearest tenth will overinflate ET caches (this one goes up to 0.1 CPs), so I suggest truncating (rounding down, "floor") to the next tenth or hundredth of a point before summing totals.

[rocketsciguy]

Obviously, a major downside to changing the formula like I've suggested is that the meaning of the point value is no longer easily understood. A 25-CP cache on DGP means it's found 4 times a year, or once every 3 months. A 25-point cache with this system above (and say n = 1.5 and A = 100/yr) could mean a 3-month-old cache that's been found once (or yet unfound), or it could be a 2-year old cache that's been found 4 times (find rate of twice per year), or it could also be a 6¾-year-old cache that's been found 9 times (find rate of once every 9 months).

On DGP, that last case would be a 75-CP cache. To me, it seems n = 1.5 is too large because that last one ought to be worth more than 25 points...

[jcanyoneer]

Guys, don't worry. However we do it, the math is really simple. For some number P (e.g. P=100) points per year:

Code: Select all
Total Points = P * (years + <day in year>/<days in this year>)

Is this right?
A cache that has been out for 5 months...
TP= 100 * (0+24/24) = 0
I assume years is the number of years the cache has been out?
The <day in year> is today?
The <days in this year> in the number of days so far this year?

this is not making sense, can you explain it a bit more?

Still seems simpler to have:
TP = ( ([Today] - [PublishDate]) / [# of Finds])
or
150=((Jan 24,2012)-(Aug 24,2011)/1 Find

I like Rocketsciguy's graphs and tables, but this does seem to degrade points for true Lonely caches also...I think that is undesirable. If anything, I would think people would prefer to have the lonelier caches have Bonus points or a scaler or something to make them worth more, not less. I like the different thinking though, any more ideas? Your example also shows that the TP = points/finds formula seems to take care of power trails already. I figure, if someone wants to get a 100 points by finding 1500 caches, let 'em! It's not my thing, but maybe that's all they are capable of finding (no offroad vehicle, uses a cane, no rappelling gear, no access to a boat...etc )

[rocketsciguy]

I like Rocketsciguy's graphs and tables, but this does seem to degrade points for true Lonely caches also...I think that is undesirable. If anything, I would think people would prefer to have the lonelier caches have Bonus points or a scaler or something to make them worth more, not less. I like the different thinking though, any more ideas?

Thanks. It may be possible to fit a curve to whatever we'd like it to be. The danger though is that the more complicated it is, the less likely it will be widely accepted and applicable, and the more room for politicking and contention.

Something else we could do is to stick with the DGP formula, but add a knee to the curve, so that after a certain number of finds (or better, after exceeding a certain find rate, say >2 finds per month), the curve bends sharply downward. In the electronics world, this would be called a low pass filter where "high frequency signals" are attenuated effectively to the point of being removed altogether. Sorry -- getting my geek on again.

Here are some other ideas I've had:

• Giving bonus points to caches based solely on its age.

The idea here is that if a cache has been around 7, 8, 9, 10+ years without being archived, it's probably a very worthwhile cache to visit and ought to be promoted as such. Sticking with my nomenclature, the formula could be C*A/x + D*A, where D is a bonus factor giving the cache extra points just based on its age. A problem with this is that after many years the LonelyCacheProject effectively becomes the ElderlyCacheProject unless the factor D is adjusted or the formula changed.

• Including a term that represents the local cache density (or maybe human population density)

This would be a complex calculation where the database would have to count the number of caches within a (e.g.) 10-mile radius, for each and every cache. Or do it in one pass by defining a grid and counting the number of caches in each grid cell, and each cache in that cell gets the same "bonus" which is (e.g.) inversely proportional to the cache density. I like this method better than calculated the distance to the nearest cache and using that as a factor, because it would be easy (relatively) to "kill" a very remote cache's score by planting another cache 600 ft away from it. The formula for this term might be C*A/x + E/d, where d is the density calculation and E is the multiplier to this bonus score.

• Including a term for DNF/Attempt ratio, as somebody suggested earlier

This would probably be a negative point value, something like ... - F * DNF/x, where x could be Finds or Attempts in this case. This one could be abused a bit by hammering a cache with DNFs, but would discourage backcountry "needles in a haystack."

Your example also shows that the TP = points/finds formula seems to take care of power trails already.

And I'm not sure I picked the best example case for a power trail, because the ET Highway has just had its grand reopening. I picked out a 5-year-old LPC micro at a mall nearby and it has a DGP score of 2 CPs or 2.23 if you include the fraction. Big caveat is obviously that DGP is out of date. Using DGP's nearest caches tool, I find there are 43 caches within "<1 mile" (meaning within the same DD° MM' grid by DGP rules) with a total score of 241. If I exclude the puzzles, there are 36 caches with a total of 101 CPs. Not all of these are PnG LPCs of course, a couple are very well concealed, at least one requires climbing a tree, at least one has been archived (4 CPs) and another ought to be (12 CPs). But otherwise, it's very likely that you could collect 75ish CPs by driving around the shopping district and adjoining neighborhoods for a couple hours. Maybe this is a better example of the kinds of caches that can be diminished on LCP.

I figure, if someone wants to get a 100 points by finding 1500 caches, let 'em! It's not my thing, but maybe that's all they are capable of finding (no offroad vehicle, uses a cane, no rappelling gear, no access to a boat...etc )

Jealousy arises within me. No cane here, just a handful of rugrats clinging to my legs, and a commitment not to buy any power toys or outdoor gear until my student loans are paid off. So it will be bumming ATV/UTV rides in the mountains with my inlaws, and rockclimbing/repelling with my coworker friends in the meantime. And I don't think I'll ever ask my dad to borrow his boat! I wore out my hiking shoes this year, but at least I can still go do that now and then!

[Corfman Clan]

Guys, don't worry. However we do it, the math is really simple. For some number P (e.g. P=100) points per year:

Code: Select all
Total Points = P * (years + <day in year>/<days in this year>)

Is this right?
A cache that has been out for 5 months...
TP= 100 * (0+24/24) = 0
I assume years is the number of years the cache has been out?
The <day in year> is today?
The <days in this year> in the number of days so far this year?

Yes, it's correct, you just applied the formula wrong

From your example:

Code: Select all

TP = 100(0 + 150 / 365) = 41.096

For <day in year>, using 5 months, I took 5*30=150, or the 150th day in year.
For <days in this year>, I took 365. For time periods that cross Feb. 29 of a leap year, 366 would be used.

[Corfman Clan]

I like Rocketsciguy's graphs and tables, but this does seem to degrade points for true Lonely caches also...I think that is undesirable. If anything, I would think people would prefer to have the lonelier caches have Bonus points or a scaler or something to make them worth more, not less. I like the different thinking though, any more ideas?

Thanks. It may be possible to fit a curve to whatever we'd like it to be. The danger though is that the more complicated it is, the less likely it will be widely accepted and applicable, and the more room for politicking and contention. ...

To me, that's really the heart of the issue. The scoring system needs to be simple and understandable. It may be fun to come up with interesting ways to weight how a cache is scored, but in the end, if the method appears to be magic to most people, its value is greatly diminished.

[firennice]

100/year simple, easy to describe, people understand, and there is no real big reason to change it.

[jcanyoneer]

From your example:

Code: Select all
TP = 100(0 + 150 / 365) = 41.096

I see. So, in the (0 + 150 / 365) 0 + 150 is actually a formula too?
like

0 + (Date Archived - Date Published), or

0 + (Today - Date Published)?

sounds like my formula would just be one of these above. - with no factor to multiply by or division problem 1 every 4 years.
I still think this as better, but majority rules (and I think I might be even less than a minority here )

[firennice]

currently an archived cache does not count at all...

[Corfman Clan]

I see. So, in the (0 + 150 / 365) 0 + 150 is actually a formula too?

I can't tell if you're just trying to bug me or what

Multiplication is done before addition, but to remove ambiguity, I'll add some parenthesis.

Code: Select all

TP = 100(0 + (150 / 365)) = 41.096

or

Code: Select all

TP = 100(years + <fraction of year>)

[Corfman Clan]

currently an archived cache does not count at all...

Yes, and that will continue to be the case.

Even if we wanted to include archived caches, it is not practical to since there is no reasonable way for us to identify them.

[jcanyoneer]

Sorry-not trying to bug ya-I was mainly questioning where the 150 came from. I know that it is the number of days that a cache has been out. I was meerly saying that once you know the number of days a cache has been out, you are done using a 1 point/day system. No factors to multiple or divide by. The cache is just worth the number of days it's been out.

sorry again...I am not a good communicator!

[Corfman Clan]

Sorry-not trying to bug ya-I was mainly questioning where the 150 came from. I know that it is the number of days that a cache has been out. I was meerly saying that once you know the number of days a cache has been out, you are done using a 1 point/day system. No factors to multiple or divide by. The cache is just worth the number of days it's been out.

sorry again...I am not a good communicator!

No problem. Just to be clear, I'll plug in another example.

Say a cache was published Dec 12, 2004. So today, Jan 24, it is 7 years and 44 days old. Plugging that into the formula, I have:

Code: Select all

TP = 100(7 + 44/366) = 712.022

Note that I used 366 for the days in the year, not 365. That is because the eighth year of this cache's life will include Feb. 29.

One more example.
Say a cache was published Feb 1, 2009. So today it is 2 years and 358 days old. Plugging that into the formula, I have:

Code: Select all

TP = 100(2 + 358/365) = 298.082

Note that even though this is a leap year, I still used 365. That is because the third year of this cache's life will not include Feb. 29.

(I should also point out that I'm counting a cache as one day old the day it is published, not the day after. This means, for example, that a cache published on Jan 1, 2011, is a year old Dec 31, 2011, not Jan 1, 2012. I did this so a cache would never be 0 days old.)

[rocketsciguy]

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! )

[MooseMob]

Last time I worked with dates, it was stored as a real number. Anything left of the decimal was the date, right of the decimal was the time. Luckily, we aren't trying using the time portion. That said, it would be technically/mathematically easier and (due to leap year) more accurate to use 1/day instead of 100/year.

[Corfman Clan]

I can do this. I'm not worried about doing it. If I don't do it, I have complete confidence in Redfist being able to. Right now, we're working on getting the data into the system. That entails things like connecting to Groundspeak's servers to retrieve pocket queries and cache logs. Parsing through the pocket queries, updating the database with the pocket query and log data. Properly handling exceptions that may/will occur. Managing the tasks that do all that. Scheduling activities to keep the data up to date, and so on. There's a lot to do and we'll generate thousands of lines of code to get it done. Compared to everything else, calculating a cache's score is simply peanuts. If you must opine about something, please pick something more interesting than this.

...A little earlier my wife said I needed to get out.

[rocketsciguy]

Sorry, Corfman Clan. I realize that the backend of this project, particularly data retrieval, is where the real hard work lies not in the points and scores. I think we're just nitpicking on it because it's the most visible aspect of the site. May I say thank you again for picking up the DGP ball and running with it?