We currently have a huge, massive, voluminous problem with weight loss goals. If your road is shallow (which we recommend for weight loss, since weight is to some extent an Outcome rather than an Action goal) then you often find yourself with like a month of safety buffer. Which means you can get away with sticking your head in the sand and not weighing in. And people do, and it defeats the whole point of Beeminder. Did I mention what a literally massive problem this is?
There’s also a seemingly unrelated problem: confusion about the color vs time-to-derailment.
Rough notes: computing PPR from lane width:
Let y = yaw = {+1 if good side up, -1 if good side down}.
Let r = the current daily rate (at time tcur) = rcur / DIRU (days in rate unit).
Let delta = r - y*l
if delta == 0: return
if kyoom:
PPR = delta
else:
PPR = vcur + delta
The
yellow brick half-plane revamp changes all this.
Namely, we’ll want to reverse that formula.
Instead of deriving the PPR from the lane width, we’ll derive the lane width (just a colored zone in the half-plane world order) from the PPR.
PPR is zero for Do More, twice the daily rate for Do Less, and for noisy goals like weight loss, the user will answer a question like “What’s the most amount of weight you ever randomly gain or lose in a day?”
That number is the PPR.
The lane width (width of colored zones) is derived by solving for l in the above formula: l = yaw*(r - delta)
http://forum.beeminder.com/t/what-do-the-colors-actually-mean/2518/19?u=dreev
[uluc stop reading here probably]
Everything below is from before we decided that Yellow Brick Half-Plane is a prerequisite for any of this.
Generalize PPRs so you always move from green to blue to orange to red, one per day, for all goal types. For example, if you’re in the wrong lane of your weight loss goal and you don’t weigh in the next day then there will be a pessimistic presumptive report that puts you in the red.
Here’s the formula:
Let l = lnw = lane width.
Let y = yaw = {+1 if good side up, -1 if good side down}.
Let r = the current daily rate (at time tcur) = rcur / DIRU (days in rate unit).
delta = r - y*l
if delta == 0: return
if kyoom:
PPR = delta
else:
PPR = vcur + delta
Note that a PPR of twice the daily rate, as in Do Less goals, is a special case of that (y = -1, l = r, so delta = 2r).
So is flatlining on a Do More goal (y = 1, l = r, so delta = 0).
In general the pessimistic report is simply where you’d be if you followed the yellow brick road but then shifted by one lane width in the bad direction.
Technical prereqs:
lnw as 0 if the rate is 0.UPDATE: What about this: http://forum.beeminder.com/t/pessimistic-presumptive-and-non-standard-aggregation-play-badly-together/562 (further generalization of the “if kyoom” case?)
NOTE: At some point I had the idea that True Pauses, where we insert a gap in the yellow brick road when you schedule a break, would mean that we could do away with PPRs as magic datapoints. I don’t remember why I thought that but I’ll leave this note here for a while in case it jogs my memory.
In order for you use Beeminder for weightloss you have to:
Always moving from green -> blue -> orange -> red each day is great.
Adding fake data is bad. (I’ve heard this echoed in the chat a lot.) Even if Beeminder is adding the fake data for me, it’s still fake, and I will get angry at it.
Adding a PPR in the red seems like a technical solution to the problem given the existing system. Maybe the solution is as simple as silently and invisibly adding the fake data point just during computation of the derailment, but never actually displaying it. You would of course need to communicate and indicate that the goal is 1 day away from derailing if they do nothing.
I agree with the fake data haters. Danny wants to model it better by doing granular lane jumps. [Note that the existing do-less PPRs do do discrete lane jumps.] That’s a step in the right direction because it’s not just a blob of points in the wrong direction but instead specific consequences. But I still think it’s bad because: it’s using the goal data/progress/ybr to model if the user is being good about adding data.
I think it’s not clear what PPR is trying to achieve. What’s the problem it’s trying to solve? Generally try to get the user to consistently add all the correct data? This is an issue with all goals, right? So why is it special for Do Less? Maybe because with Do More goals, users are motivated to add data. With Do Less, nothing motivates them to. Maybe — but… in all of Beeminder Land, users have to invest in the concept of modeling akrasia and continually tricking themselves. In other words, for any goal type, a user can just quit the goal whenever they want. So, never adding data for a long time is the same thing.
[dreev was intrigued by JJB’s idea of solving this with meta graphs. Everyone automatically gets a meta graph that forces them to add data on their do-less graphs.]
[philip likes the meta-approach; it’s already possible given callbacks to create a one-to-one entry-enforcer meta-goal.]
Philip is not entirely sure how this fits in the PPR discussion. Goals like weight and email can bounce around. Many of the default Beeminder algorithms were developed to work well for monotonic do-more goals. Whatever solution is adopted, it’d be great if it made sense for other non-monotonic data. (Not just for PPR, but for Take-A-Break and for ‘flat spots’ and …)
Philip has argued before that the safe-days on a do-less goal are off-by-one. Because you can’t undrink that cup of coffee or uneat that doughnut. Being in the wrong lane makes today an emergency day; a day of heightened awereness and doing (or not doing) the committed activity. If the goal’s deadline is approaching on a do-more, and i’m on the wrong side of the road, I can do a little more. If it’s a do less goal, I can’t do a little less. Once I’m on the wrong side of the road, I’m screwed. Modulo loopholes. Conversely, although it’s a day of heightened awareness, it probably doesn’t warrant Zeno warnings. Also, some folks seem to have do-less goals that they can actively do less and get back on the road. Goodness knows how nicely that plays with the loophole. Could be related to insta-derail.
Slightly related: Continuous Beeminding