Calculation of FP % is incorrect

[+capoaira]

The calculation of the Fav-% is incorrect on the result page and cache listing:

This cache has about 1000 logs and therefore a PM-fav-% of about 30%

Please fix it, the Fav % are the only real tool for quality cache

Edited January 23 by Bl4ckH4wkGER

[+barefootjeff]

1 hour ago, BendSinister said:

suspect it has something to do with non-PMO status, as my PMO caches have the expected percentages.

(If this is some sort of *deliberate* exclusion of non-PMO caches it'd be wise to indicate that instead, as the current phrasing is basically tens of thousands of lies all over the site LOL.)

 

I only have one PMO cache and that's also showing 0% in spite of having 13 FPs from 87 finds:

 

 

The same thing is happening on the cache page:

 

[+simon_cornelus]

I Think it's a bug indeed.

I have one PMO cache that's archived with the same behavior and some other caches, all seem to have "0% Favorites/Premium logs" on the list and "<1% Favorites/Premium Logs" on the cache page.

Edited September 22, 2022 by simon_cornelus

[Frau Potter]

We are aware of this issue. The engineers are actively working to fix this bug. It will take several days before it is corrected. In the meantime, the values may be temporarily incorrect or missing. 

[+capoaira]

Looks like the bug is fixed. Thank you

[+yukionna]

I’m not sure the bug is fixed or perhaps there is another issue with the percent favorite calculation.   I saw a cache that has a total of 13 logs: 12 found it logs and 1 cache publish log.   The cache has 12 favorites all from from premium members.  I would have expected to see a favorite percentage of 100% but the percent is 92%.  That makes me draw the conclusion that the calculation includes the publish log because 12 favorites divided by 13 total logs = 92%.  

[+yukionna]

Never mind, all is well.  Unless someone just modified the code, it seems there is a few hours delay, after the FP is added, in the recalculation of the percentage.  It is curious though as when the FP was added earlier today, the 100% dropped immediately to 92%.  Now, five hours later, it just recalculated to 100%.  Perhaps the % is calculated twice: first when the FP is awarded using one set of code; second later on, using different code, to recalculate.  🤷‍♀️
 😊

Edited December 5, 2022 by yukionna

[+barefootjeff]

On 12/23/2022 at 11:57 AM, BendSinister said:

Something still seems to be amiss, in at least some cases. It's almost like the percentage updates with a subsequent log, such that the ratio is constantly out of date, using numbers that applied up until that latest log. Or something. The situation seems to persist until the next change in the numbers.

 

I think you've hit the nail on the head with this. I've been watching the FP percentage on a newly published multi and it always seems to be ignoring the most recent log.

[+MartyBartfast]

It's been discussed elsewhere that the way the website calculates the % score for favourites is wrong, but I just saw something that is so wrong it's frankly bizarre.

Consider this cache which I logged a find on 2 days ago: 11 finds, of which 10 are PM, and 3 favourites, so that should be  either 27% or 30% depending on which count you're using, but the website shows 40% (see  screenshot)!

Then when I went to add an FP to my log from 2 days ago  it records my FP, so now 4 out of 11 or 10 finds , which should be 36% or 40%  but it now calculates it to be 30% (see screenshot).

Whatever method is being used to work out the percentage how on earth can adding an FP (without adding a log entry) lower the % score

[+Bl4ckH4wkGER]

I merged a duplicate thread.

[+Viajero Perdido]

It's still wonky.  Perhaps this quasi-random number should be removed until it can be made correct.  Here, I kept clicking Remove/Add, same backwards result every time.

 

 

I've also found I can permanently increase a cache's mock-percentage by adding then removing a favorite point ... but only once per cache.  (If everybody does this, can we get over 100%?)

 

Edited March 6 by Viajero Perdido

[+barefootjeff]

2 hours ago, Viajero Perdido said:

I've also found I can permanently increase a cache's mock-percentage by adding then removing a favorite point ... but only once per cache.  (If everybody does this, can we get over 100%?)

 

That's just recently happened on one of my caches. Prior to the most recent find, it had 4 FPs from 5 PM finds and was incorrectly showing 75% FPs, now after the most recent finder logged it and gave it an FP (so it's now 5 from 6) it's showing this:

 

 

What's even more curious is she gave the FP with her log, as it shows in the log email, so I don't know how it got double-counted, unless perhaps she then went to the website, removed it and re-added it.

[+Viajero Perdido]

Darn ... I couldn't push you past 100% with a temporary found log and some favorite diddling.  Instead that just brought it down to 86% ... sorry!

 

But 5/6 is 0.83, rounded.

 

6/7 happens to be 0.86, rounded.

 

Math is hard.

[+barefootjeff]

12 minutes ago, Viajero Perdido said:

Darn ... I couldn't push you past 100% with a temporary found log and some favorite diddling.  Instead that just brought it down to 86% ... sorry!

 

Yep, so I now have:

• GC9M6X5 with 5 FPs from 6 PM finds showing 100% FPs
• GC9ZM7G with 6 FPs from 6 PM finds showing 86% FPs.

This has long since stopped being funny, HQ...

[+barefootjeff]

This one must take the cake with 1 FP from 1 find but <1% favourites/PM logs:

 

 

Maybe it's only counting FPs awarded from the app?

[+HouseOfDragons]

This is happening on one of my caches - 10 FP from 10 finders and a percentage of 90%.
 

i see they only ever said they were "working on it" last September and never confirmed it had been fixed though.

[+barefootjeff]

A bit more observation on my latest cache (GCA5HGT) which now has 4 FPs from 4 finds but is showing 75% FPs:

 

It appears the percentage FP calculation is only done when a log is posted and ignores any FPs that are added from the cache page afterwards, i.e.

 

 

The silence on this issue from HQ since it was first reported 6 months ago is disturbing. I guess since this only really affects caches with small find counts, it's been deemed inconsequential.

[+Viajero Perdido]

The types of people who are attracted to this game ... seem to be the types who are also into statistics ... and maybe it really annoys them if those stats aren't accurate.

 

Maybe this deserves more attention.

 

I don't personally care that much, but do have a(-n annoying?) compulsion to report bugs when I see them.  It comes from my background in software development.

[+barefootjeff]

2 hours ago, Viajero Perdido said:

The types of people who are attracted to this game ... seem to be the types who are also into statistics ... and maybe it really annoys them if those stats aren't accurate.

 

For unpopular caches like my more recent ones that are condemned to single-digit find counts, the percentage FPs is about the only statistic worth looking at. And as a retired engineer, it bothers some essential part of my core to see incorrect information displayed, more so when the response from those responsible is, well, crickets.

[+OGuyDave]

Same deal here for a cache that was just published on April 1:

 

Pretty sure that the last logger added his favorite point a day after submitting his log.

 

Would be nice to see HQ get their heads together and fix this problem. Or maybe it's HQ's attempt at humor based on the day the cache was published! Nah!

 

 

[+HouseOfDragons]

Is this ever going to be fixed (or even a comment that it's being looked at would be nice!) 

[+baer2006]

Before attempting to "fix" anything here, one must first establish a rigorous definition of the metric "percentage of FP". And I don't think that's super easy.

Basically, it should be "#FP / #(Logs from PMs)", because that's what it says on the listing page: xx% Favorites/Premium Logs

 

A) The simple approach would be #FP/(# of finders, who are currently PM). But this can easily lead to totally misleading percentages, because when a PM, who has given an FP, becomes BM (e.g. because the quit the game, and let the premium membership expire), the FP remains. Example: A cache with 10 finds, 6 FP, but only 2 finders are PM (because 4 of the those with an FP are now BM). So what's the percentage now? #FP/#PM-finders would give 300%, which doesn't make sense.

 

A better approach would be (#FP given by current PMs)/(# of finders, who are currently PM). With this definition, the above example would give 100% - the two remaining PM finders both gave an FP. How many ex-PMs gave an FP in the past would be irrelevant.

 

C) One could even define it like this: #FP/(#FP + # of finders who are currently PM and did not give an FP). Sounds complicated, but boils down to counting in the denominator all finders, where we know they could have given an FP: Those who actually gave one plus those who are currently PM and therefore could give one.

 

Both B and C should be easily query-able from the database, using only persistent information (i.e. who has found the cache, who is currently PM, and who has given an FP).

[Johannis10]

So far not all bugs have been fixed as you can easily see here right now without calculation:

https://coord.info/GC9F8ZF

5 findes and 5 FP is not 80%

Edited April 8 by Johannis10

[+barefootjeff]

2 hours ago, baer2006 said:

Before attempting to "fix" anything here, one must first establish a rigorous definition of the metric "percentage of FP". And I don't think that's super easy.

Basically, it should be "#FP / #(Logs from PMs)", because that's what it says on the listing page: xx% Favorites/Premium Logs

 

A) The simple approach would be #FP/(# of finders, who are currently PM). But this can easily lead to totally misleading percentages, because when a PM, who has given an FP, becomes BM (e.g. because the quit the game, and let the premium membership expire), the FP remains. Example: A cache with 10 finds, 6 FP, but only 2 finders are PM (because 4 of the those with an FP are now BM). So what's the percentage now? #FP/#PM-finders would give 300%, which doesn't make sense.

 

A better approach would be (#FP given by current PMs)/(# of finders, who are currently PM). With this definition, the above example would give 100% - the two remaining PM finders both gave an FP. How many ex-PMs gave an FP in the past would be irrelevant.

 

C) One could even define it like this: #FP/(#FP + # of finders who are currently PM and did not give an FP). Sounds complicated, but boils down to counting in the denominator all finders, where we know they could have given an FP: Those who actually gave one plus those who are currently PM and therefore could give one.

 

Both B and C should be easily query-able from the database, using only persistent information (i.e. who has found the cache, who is currently PM, and who has given an FP).

 

Just displaying what it used to display back before they changed things last September would be a good start. Right now it's just wrong whichever way you define it.

[+Viajero Perdido]

Has anybody figured out how to game this to simultaneously +1 the favorite count, and increase the fave percentage?  (...as would happen in reality.)

 

I'm trying to figure out how to deliver a proper compliment, not a half-cheeked one.  [:D]  I say nice things with words, of course, but nobody reads those.

[+HouseOfDragons]

On 4/8/2023 at 7:32 PM, baer2006 said:

Before attempting to "fix" anything here, one must first establish a rigorous definition of the metric "percentage of FP". And I don't think that's super easy.

Basically, it should be "#FP / #(Logs from PMs)", because that's what it says on the listing page: xx% Favorites/Premium Logs

 

A) The simple approach would be #FP/(# of finders, who are currently PM). But this can easily lead to totally misleading percentages, because when a PM, who has given an FP, becomes BM (e.g. because the quit the game, and let the premium membership expire), the FP remains. Example: A cache with 10 finds, 6 FP, but only 2 finders are PM (because 4 of the those with an FP are now BM). So what's the percentage now? #FP/#PM-finders would give 300%, which doesn't make sense.

 

A better approach would be (#FP given by current PMs)/(# of finders, who are currently PM). With this definition, the above example would give 100% - the two remaining PM finders both gave an FP. How many ex-PMs gave an FP in the past would be irrelevant.

 

C) One could even define it like this: #FP/(#FP + # of finders who are currently PM and did not give an FP). Sounds complicated, but boils down to counting in the denominator all finders, where we know they could have given an FP: Those who actually gave one plus those who are currently PM and therefore could give one.

 

Both B and C should be easily query-able from the database, using only persistent information (i.e. who has found the cache, who is currently PM, and who has given an FP).

Why would you want it to be anything other than "what  percentage of people eligible to give a FP gave this cache  a FP"?

 

I'd settle for correct. 10 out of 10 isn't 90%

[+Etherlord Clan]

Hi Team,
I'll throw my hat into the ring as well

I have a new gadget cache that has 11 Found It logs and collected 11 FPs, yet is only at 91% thanks to the "Published" log making a total of 12 logged visits and throwing off the % calculation.

 

Thanks,
Thomas

 

Edited April 13 by Etherlord Clan

[+2Abendsegler]

Before our log the cache had 26 favorite points and 68%. With the log via the new log form we have set a favorite point. The listing also included the 27 favorite points. Unfortunately, the percentage was reduced to 67%. We then removed the favorite point via the listing and added it again in the hope that it would then be displayed correctly. When it was removed, the old values of 26 points and 68% were restored. On adding it got even worse with 27 points and 65%. We can remove and add again and again with the same result. I might as well shoot a little clip of it.

Really very unfortunate that you haven't been able to correct the obvious bug for months. It's particularly unfortunate because it used to work. It also seems questionable whether all past data can be reproduced again.

[+barefootjeff]

The silence on this issue is becoming deafening, with it now eight months since the OP in this thread. The latest example is GCA703Y which has had two finds, one by a basic member, and received an FP from the other:

 

 

If it's no longer possible to correctly show the percentage FPs, why show it at all?

[worrellsquirrel]

This issue is still being investigated by our engineering team. We apologize for any inconvenience but thank you for your patience in the meantime.

[+Viajero Perdido]

On 5/18/2023 at 12:22 PM, worrellsquirrel said:

This issue is still being investigated by our engineering team.

 

What was the result?

[+barefootjeff]

Happy birthday to this bug.