waistline
waistline copied to clipboard
feature/improvement request: add/replace goal averages with a 'budget' style system
The averages system for goals does have a few disadvantages which make it difficult to reach the goals on average.
Example: lets assume my goal is 2000 kcal every day with a 3 day average and for some reason on day 1 and 2 I only consume 1500 kcal. On the third day I should be consuming 3000 kcal to keep the average of 2000 kcal a day. So far the existing system works well. On day 4 to reach the goal for 3 days I am allowed to eat only 1500 kcal even though I did not violate my goal of 2000 kcal on average the last 3 days.
I would like to request the following feature: replace the averages system with a budget style system that only continuously tracks the difference between goal and consumed kcal. Example: Goal 2000 kcal / day
day | consumed | goal | target for this day | change for next day | budget |
---|---|---|---|---|---|
1 | 1500 | 2000 | 2000 | +500 | 0 |
2 | 1500 | 2000 | 2500 | +500 | 500 |
3 | 2250 | 2000 | 3000 | -250 | 1000 |
4 | 2000 | 2000 | 2750 | 0 | 750 |
5 | 2250 | 2000 | 2750 | -250 | 750 |
6 | 1500 | 2000 | 2500 | +500 | 500 |
7 | 3000 | 2000 | 3000 | -1000 | 1000 |
8 | 2000 | 2000 | 2000 | 0 | 0 |
So only one number needs to be tracked to make this system work. It is changed after each day by adding the result of "goal kcal - consumed kcal" to this number. This would improve the overall possibility to reach the set goals.
I like the idea of maintaining a budget for the goal calculation. It sounds very simple and would probably help to address the performance issues mentioned in #694.
However, this only works as long as the user doesn't change any diary entries in the past, and doesn't care about what their goal was on a particular day in the past. As soon as the user goes back to a past diary entry, the whole system collapses. Any changes made to a past entry would change the remaining budget for the following day, but the app cannot compute that because it only knows the budget for the current day. This problem gets worse as the number of days between the changed entry and the current day increases.
After all, there is a reason why the app currently computes the goals dynamicly. We want it to be flexible and be able to respond to changes. Yes, this has some disadvantages and performance problems, but I have yet to come up with a better solution.
So, I'm sorry, but I don't think this idea can be implemented 😞
I like the idea of maintaining a budget for the goal calculation. It sounds very simple and would probably help to address the performance issues mentioned in #694.
Thank you. I still am not entirely sure how to handle multiple goals. One option would be to do the same thing as for one goal just x amount of times.
However, this only works as long as the user doesn't change any diary entries in the past, and doesn't care about what their goal was on a particular day in the past. As soon as the user goes back to a past diary entry, the whole system collapses. Any changes made to a past entry would change the remaining budget for the following day, but the app cannot compute that because it only knows the budget for the current day. This problem gets worse as the number of days between the changed entry and the current day increases.
I have thought about the possibility of a user 'changing history' as well. One very easily implemented way around that entire problem would be to save the budget calculated up to a specific date for that date as well (this needs to be done any way as you would need it to display the kcal target for that same day or any day which would be calculated by: Target = Goal + Budget). When a user then changes a diary entry for that day you just need to recalculate all budgets and targets for any day up to and including the current day. This should be possible within O(1) or worst case Ω(n) even with multiple goals. This would be even simpler with the consumed kcal calculated for every day already calculated and saved for that day. It would just be the case of implementing the following (Budget = Target - Goal):
for all days up to and including current day do
BudgetThisDay = BudgetLastDay + GoalLastDay - ConsumedLastDay;
Save(BudgetThisDay);
After all, there is a reason why the app currently computes the goals dynamicly. We want it to be flexible and be able to respond to changes. Yes, this has some disadvantages and performance problems, but I have yet to come up with a better solution.
My above solution would be very dynamic. And very easy to implement.Plus I don't think a lot of people change diary entries hundreds of days ago. I would assume most changes made would be close to the current date.
My above solution would be very dynamic. And very easy to implement
I think you haven't quite grasped the magnitude of your proposed change. It would be a complete change in paradigm! The diary in Waistline is currently 100% based on references. The user builds up a list of foods and recipes, and the diary entries are actually just references to these items. So every time the user changes a food or recipe (e.g. to correct a mistake, or to add a missing ingredient to a recipe), all existing entries in the diary that reference this item get this change automatically, no further action required. The total nutrition intake for any particular day isn't actually stored in the app. It can be computed on the fly based on the referenced items whenever we need it.
However, if we would implement your idea, then whenever the user changes a food item or recipe, the app would first need to find the oldest diary entry that references this item, and then recompute the total intakes and the budgets for all days from then until the current date.
I'm not saying this would be completely infeasible. But it would be a complete paradigm shift, and certainly not "easy to implement" 😜