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.

 

[+Deepdiggingmole]

Today I noted on one of my caches that the %age figure as given in the FP box did not tally with the number of FPs points given over the number of finds 
As per the image both are 5 (newish cache) however the %age figure says 80%
One of these finds was today though when you look in the 'View who favourited' link it does show all 5 who have found it are on that list including today's finder - so would have thought that would be 100% 

So is there a delay in that %age figure updating or is there an issue with this 
 

(Note I had started a post on this topic as I hadn't found this thread - have added it here to show this issue is still unresolved)

[+barefootjeff]

39 minutes ago, Deepdiggingmole said:

So is there a delay in that %age figure updating or is there an issue with this 

 

No delay, it's just broken. This cache of mine, with one find and one FP, was found nearly four weeks ago but it's still showing <1% FPs.

 

 

I have a picture with two candles on a cake ready to post next September.

[+Deepdiggingmole]

...and yet it does show it correctly too - this one, (see attached) 15 finds 15 FP and shows as 100% and the latest find was earlier this year (relevant to when this thread was orignally posted)

My 2 examples are the easier to show whether the %age figure is correct, becasue all finders gave a FP - I am aware with PM and non-PM logs and also PMO caches these figures can be a little skewy - however both my examples though being non PMO caches - with all finds, all have given FPs 

I will monitor my earlier example and see if it does eventually change as that does suggest either there is a time lag issue or it gets repaired and it keeps breaking

 

Edited November 8 by Deepdiggingmole

[+Deepdiggingmole]

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

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.

Just reading through the past posts on this as I have only just joined in) the above suggestion though using my example where there have been 15 finds and 15 FPs given out - if for example 5 of these let their PM lapse so now only 10 are PM then the %age figure would still be 100 as you indicate however that isnt telling me 100% of ALL finders gave that cache an FP (which is what I would expect out of that stat ), it is essentially saying 67% of all finders have given an FP as we are  going to ignore some of them 

 

Edited November 8 by Deepdiggingmole

[+baer2006]

13 minutes ago, Deepdiggingmole said:

Just reading through the past posts on this as I have only just joined in) the above suggestion wouldnt work using my example where there have been 15 finds and 15 FPs given out - however if 5 of these let their PM lapse so now only 10 are PM then the %age figure would be 100 as you indicate however that isnt telling me 100% of ALL finders gave that cache an FP (which is what I would expect out of that stat ), it is essentially saying 67% of all finders have given an FP but we are not going to count them all 

Sorry, but I don't see your problem. Of course, the FP % stat doesn't "count them all", because non-PM simply cannot give an FP. So if a cache has 15 finds, and 10 of these are currently(!) PM, and all those 10 current PMs have given an FP, then it should say "100%". Such a calculation scheme ignores FPs by former PMs, true. But in my view, only taking the current FP per PM percentage into account would be the most "stable" and reproducible method.

[+Deepdiggingmole]

5 minutes ago, baer2006 said:

Sorry, but I don't see your problem. Of course, the FP % stat doesn't "count them all", because non-PM simply cannot give an FP. So if a cache has 15 finds, and 10 of these are currently(!) PM, and all those 10 current PMs have given an FP, then it should say "100%". Such a calculation scheme ignores FPs by former PMs, true. But in my view, only taking the current FP per PM percentage into account would be the most "stable" and reproducible method.

No - but I am well aware that if you factor in non PM then it wouldn't and I am aware of that when I look at that %age figure it only counts PM finds (not discussing PMO as has already been stated that only PMO caches would give a more accurate figure). So I look at a non PMO cache and I know that that %age figure will reflect the stats based on PM finders only - and that doesnt bother me because I know only PM can give an FP - so I look at it and if it says 26% , I know that means 26% of PM finders have awarded an FP - I dont then go and look at the number of total finds and say it is wrong 
In my example and with the suggestion that you gave where a few had PM lapsed - yes, it would produce a figure that may be "stable" and reproducible - but, inaccurate because it is discounting FPs that have been given - why would you want to discount FPs in a figure that has the sole function of measuring FPs

[+Deepdiggingmole]

3 hours ago, baer2006 said:

Sorry, but I don't see your problem. Of course, the FP % stat doesn't "count them all", because non-PM simply cannot give an FP. So if a cache has 15 finds, and 10 of these are currently(!) PM, and all those 10 current PMs have given an FP, then it should say "100%". Such a calculation scheme ignores FPs by former PMs, true. But in my view, only taking the current FP per PM percentage into account would be the most "stable" and reproducible method.

and to answer the statement 

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

 

I have just checked another of my caches to see how the PM non PM issues stands up and it would seem the %age figure only counts the PM 

26 finds of which 25 PM, 1 non PM and 16 FP - if ALL finds were counted then the %age would be 61 - if only PM finds were counted then the %age would be 64 
The stat shows 64% - which does indicate it is ignoring non PM - so in essence it is correctly counting all the relevant find logs for that stat - those by PM 
That is a fairly new cache (1 year old) so I doubt lapsed PM accounts are an issue - so yes, it is "#FP / #(Logs from PMs)"
and yes, I agree that lapsed PM accounts would skew these stats - I have just checked one of my older caches -  1159 finds, 917 by premium members, 246 by non-PM, 359 FPs this should work out as 31% if all find logs are counted or 39% if only PM counted - the FP box shows 38% so suggests again this does only take into consideration PM finds (39% is my calculation and it is very likely that 1% is the difference of lapsed PM which is between 10-20 cachers - though to identify those accounts that had been premium and are now non PM is doable but would take ages ) but again I would say it is "#FP / #(Logs from PMs)"

 

However what the glitch is - who knows 

Edited November 8 by Deepdiggingmole

[+Deepdiggingmole]

31 minutes ago, Deepdiggingmole said:

31% if all find logs are counted or 39% if only PM counted - the FP box shows 38% so suggests again this does only take into consideration PM finds (39% is my calculation and it is very likely that 1% is the difference of lapsed PM

Having looked at this closer - I have now established there were 34 PMs who gave FPs who are now shown as basic (Non PM accounts) (its pouring with rain so I'm enjoying sitting at the PC today  )
So where the logs show 917 by premium members, 246 by non-PM this would be amended to 951 PM, 212 non PM with the account change taken into consideration 

this means the %figure would be 37.7% - I then wondered about those PM accounts that similarly lapsed and are now basic but didn't give FPs as that would also affect this number - but I dont have the time to disseminate those stats (even though it is raining !!!! )

So does this mean their calculations do take all this into consideration  - despite there being a glitch 

 

 

I hope this rain stops soon - I can't sit here all day researching this dribble