Weight loss: Width of the road? What about using moving average?

Thanks for the reply! Some follow up questions and thoughts–
Is the yellow brick road actually defined as the 90% quantile of the rate-adjusted daily absolute variations in your data? The FAQ item refers to “90% variance in the goal stats” which I don’t see anywhere, and also says that this stat is “how wide the Yellow Brick Road should be so that if your true values were all right on the centerline, 90% of your actual values (with random fluctuations) would be on the road.”

I ask because in the forum thread announcing the death of auto-widening, @dreeves wrote “The can’t-lose-tomorrow guarantee will still obtain, in a sense, but only applies for flatlining [1]. The width of each lane of the
road is always equal to the current daily rate of the road”

As an aside, I’ll also point out that the roadwidth blog post does not reflect this change (whatever it is specifically), unlike many other beeminder posts and pages which direct the reader to updated info when stuff changes.

I’m also going to make one more plea for using the moving average as a beemindable metric for weight loss, even with the caveat that it’s probably more helpful to beemind actions than outcomes. Here’s my thinking.

Beeminder is an awesome platform with cool graphs and QS functionality, but it’s kinda (completely) broken for tracking weight loss, which is a bummer since it’s the chief use case for so many people, including myself. I want to use beeminder’s awesome features, like the lanes and the safety buffer! But with the noise in daily weight datapoints, these features are useless (and misleading!) because I might derail by surprise on any given day unless I’m so far in the green that I’m not paying attention to the road at all. And even if I become a premium member and make weight a free-bee, any “surprise” derailments will mess-up my nice pretty road graph.

Using the moving average would make beeminder more usable and helpful for weight loss because it would make use of beeminder’s current and excellent features.

1- It would make the lanes meaningful. If my moving average goes into the wrong lane, I know I’ve got to step up my “inputs” before I derail. But I also know I have a few days to do it. That’s what the lanes are for, right?

2- It would make the safety buffer meaningful. Same reason as above, but I want to emphasize it’s utility and current brokenness. The biggest single image/number on my graph is the color-coded countdown that says I have 13 days until I derail! That’s not at all true! I have a very good chance of derailing tomorrow!

3- It makes recommitting more sensible. When I derailed recently my graph re-railed at a weight that gave me a week off and 44 day buffer! That doesn’t make any sense given that the derailment was the result of a couple days of weirdness. With a moving average, both the one-week flat spot and the auto-recommitment based on the offending datapoint would actually make sense. And yeah, if I’m in the red when I weigh in the morning there’s probably nothing I can do about it, but that’s actually good because

4- Using the moving average would discourage crazy one-day weight loss gambits. We can all agree that a day of intense pooping and sweating is not the path to a healthy lifestyle, right? It’s waaayy better to derail and then get back on track over a week than to try to claw your way back onto the road over a few hours…especially since you’d pretty much have to stay dehydrated until you lost enough real weight to put you in a safe zone.

The argument against using the moving average outlined on the blog is basically this:
a) There’s always a “magic number” that you have to be under for any given day. and
b) Akratics who use beeminder will always skate towards the edge, and once they get there they’ll have an impossible magic number to meet. So
c) Conclusion: using the moving average for weight tracking won’t work.

But this argument has two problems:
1- It totally ignores how the moving average would jive so nicely with the existing beeminder features like lanes and safety buffers and auto-recommitment with a 7 day flat spot. Not using the moving average just feels like fighting the whole platform. And

2- While there’s always a “magic number” for any given day, beeminder defines the akratic horizon as one week (arbitrary, of course, but probably good enough). So, yeah, I might not be able to nudge my moving average much in one day, but I probably can change it meaningfully over the course of a week. And while I tend towards hyperbolic discounting, I’m still perfectly capable of prioritizing and planning at least a few days at a time if it’s something I care about (or there’s real money on the line). I’m akratic, not a fruit fly. And if I set my rate too steep, and it’s obvious upon derailment that my moving average was headed off track since day 1, recommitment is a perfect time to make an adjustment.

Ok. End brain dump. Now for a real question-- has anyone hacked a workaround with spreadsheets or IFTTT or something? And if so, can you share?

4 Likes