albertvaka
Wrong average calculation after update to 4.10.0
Hi,
I just updated to 4.10.0 (from F-Droid), and now, the average calculation seems to have an issue. In the ChangeLog, you write "Calculate average until last entry". I'm not sure if I get the intention behind this right, but what I now see is:
I have 7 times on January 1st. What I would have expected today, on January 3rd, is an average of 2,33 (7/3).
If "average until last entry" means that the next average is not calculated before I increase, I would expect the average to be still 7, but not 6 … however I think this would not really be meaningful, or at least this should be configurable – at least I am actually interested in the average as of today, no matter when the last increase was done (actually, this is crucial for my use-case, as I'm interested when the average falls below a certain threshold, so that the counter can be increased again).
Anyway: Thanks a lot for this incredibly handy app and thanks in advance for fixing this :-)
Cheers, Tobias
The change was proposed and discussed in https://github.com/albertvaka/bettercounter/issues/84
Feel free to chime in with your use case, maybe we should make this configurable indeed...
Okay, I added an extensive description of the problem with the change here: https://github.com/albertvaka/bettercounter/issues/84#issuecomment-2570561518
Is there any chance this could be made configurable (if this change is actually desirable behavior for some people)? As of the last update, Better Counter is alas practically useless for me :-(
Yes, I'm considering this. Or maybe we can find a compromise, but I'm not sure it is possible. I will think about it, but in the meantime if you use F-Droid you can download an older version from there.
Thanks a lot for the follow-up! And also thanks for the hint with F-Droid, I didn't knew one could downgrade an app at all! Well, 4.9 does what I would expect. Nice that I can keep it for now.
I don't think there could be a "compromise" between the two approaches to calculate the average, so I think adding an option would be the only way if one wants to keep the current behavior.
What about the following approach (which would still make an option mandatory, but maybe solve this):
If I get it right, in https://github.com/albertvaka/bettercounter/issues/84, it's about knowing how long something lasted. E.g. you have a bottle of magic potion that is sufficient for 30 days. You open one and increase the counter. After 30 days, you open the next one. Conclusion: You need a bottle every 30 days. However, the average would be calculated to each 15 days. That's not what unoukujou wants.
However, if you're interested in how many bottles of magic potion you drank in the given time span, this calculation would be very right, because during 30 days, you drank two – and increased the counter two times. So: 30 days divided by two bottles = 1 bottle each 15 days. For the given time span. It will decrease with each day, but at day 30, there were 2 times in 30 days, and the average is at that day 15 – if you like it or not.
I think the solution would be quite easy: Add an option to either leave out the first increase, the latest increase or none. This way, you can use the app for multiple purposes:
- No increases left out: Simply the actual, dumb, basic average. It is what it is (and that would be what I would love to get again)
- First increase left out: No average until you have at least two increases. The first increase sets a starting point. You can't know how long your bottle of magic potion will last until you have to open a second one. Starting with the second one, you know it: E.g. Increase by one after 30 days → on average, you need one each 30 days. Another increase after 20? You needed two in 50 days, so on average one each 25 days.
- Last increase left out: The current behavior. Not very meaningful imho, but apparently, this is what unoukujou (and possibly others) also need.
What do you think?
If I get it right, the possibility of leaving out the first increase and only using it as a starting point would fully cover @unoukujou's use case – and it would be just one tick to set or not … but let's wait for a reaction.
However, thanks a lot for discussing this, replying, spend time with this etc. – I really appreciate this a lot! Esp. because I really have no idea to code for Android. If this was a Qt/C++ project, I would have filed a MR meanwhile ;-)
I would like to know @unoukujou's thoughts :)
Of course I figured that there will be people who are used to the old way and would prefer that. And of course, I don't mind to have an option that the user can decide how it's best for them. For me personally, the old way is not practical, and this new way is the most useful (for me), but at least if there's an option, everybody can be happy.
- No increases left out: ...
- First increase left out: ...
- Last increase left out: ...
In this example, It doesn't matter if you leave out the first increase or the last increase. You will still have the same average, the same numbers get calculated.
It's easier to think of it as instead of the first increase or the last increase, it's really just the 'total number of increases minus one". So either way, you have the same number. My point is that both options that you showed here are exactly the same. When you have only one increase, the first increase is also the last increase.
As you see how it is now:
I opened a 32 ounce coffee 10 days ago. I'm still using it. There's only one count but there's still no average yet until I'll mark the 2nd count.
All that's happening is the division by the "total number of counts minus one". When it's only one count, that's one minus one, which is zero, and anything divided by zero is zero. When I'll have two counts, it will divide by 1 (2 minus 1), With three counts it will divide by two (3 minus 1). So whether you like to think of it as the first increase left out or the last increase left out, it doesn't really matter. In the end, it's the same thing.
Now here with my coffee, let's say I'll be finished in 20 days, I'll put another count. And I'll forever know that the 32-ounce coffee lasts me 20 days. I'll also know that if I get 64 ounce coffee, it could last me 40 days. And if I get 16 ounce coffee, it can last me 10 days. That's a lot useful information for me. I can also continue counting with another 32 ounce coffee that i will open. Then I'll have three counts or four counts or five counts... and get even a more accurate average when I open more bags. Or I can just choose to stop right now and I'll still have a pretty good average to know that it lasts me about 20 days.
But again, for anybody else who likes the old way, if there's an option to change it to the way the user wants then everybody can be happy. Of course, that's always the best solution from the user's point of view. 👍
So, if you want the average the way it was calculated before, you just press the "+" button once and it gives the the old average. You can then hit the "-" button after, if you didn't want to make the counter go up. But it would be neat to have options, for sure. Both for convenience for some users, and also as an educational thing. Many don't know that there are different ways of getting averages.
But reverting back would be a step backwards, because of this easy workaround, don't you think?
Even better would be a way to set start and end times for the average. As in:
Beginning: 2025-01-01 6:00PM Ending: 2025-01-04 12:00AM
Average: 1.75/day
That would be a button you press for that counter. That might give all the averaging options anyone would ever want.
Thoughts?
Even better would be a way to set start and end times for the average. As in:
Beginning: 2025-01-01 6:00PM Ending: 2025-01-04 12:00AM
Yes. The good thing about having data that's recorded is that you can always generate different reports based on that data.
I know I usually drink more coffee in the winter than in the summer so if I can check the report during winter months and summer months, maybe I'll find that my 32oz coffee lasts 15 days in the winter. But in the summer months, maybe it's lasting 20 days. So yes, that's the good thing about having data is that you can always generate different type of reports if necessary. I can see the usefulness of this as my average in the summer and in the winter is definitely different.
All that's happening is the division by the "total number of counts minus one".
That's actually not all that happens. With the new behavior, also the time span the average is calculated for changes.
Sticking to my above example with 7 times, you get an average of 6 per day. That is what you said, "total number of counts minus one". But then, it would be only that average on January 1st. On January 2nd, I would then expect an average of 3 per day – but you still get 6. Also today, you would still get 6. Because the time span does not increase until you enter another increase. Which is then left out, but the time span increases, cf my example posted at https://github.com/albertvaka/bettercounter/issues/84: If you increase on January 4th one time, you get an average of 1.75, which is the total number of increases minus one, divided by 4 days.
So it's not as easy as adding a checkbox saying "Calculate the average with total number of counts minus one", because it's more than that …
All that's happening is the division by the "total number of counts minus one".
That's actually not all that happens. With the new behavior, also the time span the average is calculated for changes.
That is exactly what happens (division by the "total number of counts minus one). The timespan is the number that gets "divided", which of course changes with each count.
Sticking to my above example with 7 times, you get an average of 6 per day. That is what you said, "total number of counts minus one". But then, it would be only that average on January 1st. On January 2nd, I would then expect an average of 3 per day – but you still get 6. Also today, you would still get 6. Because the time span does not increase until you enter another increase. Which is then left out, but the time span increases, cf my example posted at #84: If you increase on January 4th one time, you get an average of 1.75, which is the total number of increases minus one, divided by 4 days.
What I was talking about by my comment is regarding to this example that you wrote:
No increases left out: ... First increase left out: ... Last increase left out: ...
No increases left out = old behavior
First/Last increase left out are both exactly the same calculation based on that example you wrote.
Maybe I don't understand what you're saying? Please show me an example of how leaving out the first increase or leaving out the last increase makes any difference?
I think there's only two options: the "old behavior" and the "new behavior" but in your example you have three different options which I don't understand because leaving out first increase or leaving out last increase are both the same so really there's only two options as far as I can understand? But maybe I just didn't understand your example, To me it seems the same, either when you leave out the first or the last.
That is exactly what happens (division by the "total number of counts minus one). The timespan is the number that gets "divided", which of course changes with each count.
And that's the point exactly: The time span changes with each count – but not without one! For my 7 times on January 1st with no increases added later, the "average" will stay forever at 6/day – unless you increase the counter again.
Until the update, the average would have been 7 per day on January 1st, 3.5 per day on January 2nd, 2.33 on January 3rd, 1.75 on January 4th and so on. After the update, it's 6 times per day on January 1st, 6 on January 2nd, 6 on January 3rd, 6 on January 4th and will be 6 times per day on December 31st – if no subsequent increase happens.
Do you see the problem you get if you're not interested in how long something would suffice, but in how often you did something? If I did something 7 times on January 1st, and on December 31st, the app still tells me the average of that happening was 6 times a day – something is wrong, no?!
Apart from that leaving out the first and the last increase may actually result in the same average. I was just brainstorming, I didn't calculate or think it through completely.
You are explaining the difference between the old behavior and the new behavior. Of course, it's two different things. And if there's an option to choose the way the user wants, it's no problem.
What I was talking about is not the difference between the old behavior and the new behavior. Of course, they are both different. I was only talking about how you mentioned there's three different ways to calculate. I was pointing out that there is not three different ways. There's two different ways. The old way and the new way. And of course the old way is different from the new way. And of course, if there's an option to go back to the old way, then you can use the app how you like.
Again, I was only pointing out that when you mentioned you can calculate with the first increase left out or the last increase left out as if they are different, but Either way it's the same. There was no "third" option. That's all I was saying. But of course the old way and the new way is two different things. And I am not against having an option to go back to the old way if you prefer that.
Okay, then I got you wrong. Sorry … but nice that we agree ;-) Hopefully, @albertvaka also does …
Any news about this? Meanwhile, v4.9 vanished from F-Droid … I blocked updates to keep the last working version, but sooner or later, this possibly won't work anymore …
The plan is still to add a toggle/setting for this in the next release. I've been busy with a combination of my other open source project (KDE Connect), my job and being sick, but this is still in my queue.
Those are very good news! Thanks a lot for working on this! And of course I wish you a speedy recovery – we have quite a epidemic at the moment …
The plan is still to add a toggle/setting for this in the next release. I've been busy with a combination of my other open source project (KDE Connect), my job and being sick, but this is still in my queue.
Oh speaking of settings, it'd be nice to have a setting to enable automatic daily backups. I will make a issue for this feature.
I just added it to https://github.com/albertvaka/bettercounter/issues/76
I just pushed a new release (v5.0, should get released in a few days) which lets you chose between the two modes from the (new) settings page. I hope this covers all use cases, but if not (or if I messed up in the calculations somehow), please let me know! Sorry it took a while! ❤
Yesterday, 5.0.1 hit F-Droid. Works perfectly, I think with the configuration option you added, everybody should be happy now. Thanks a lot again for working this out :-)