Useful Table calculation bug?

I’m trying to understand why my goal’s “Useful Table” is showing no road increase between Friday and Saturday when there is no flat spot on the road (as you can see from the Upcoming Changes section which matches the visual road: https://www.dropbox.com/s/mpqzgmxaj9bhhtk/Screenshot%202015-06-16%2007.49.19.png?dl=0

The goal: https://www.beeminder.com/drtall/goals/drinks_triangle

Any thoughts?

3 Likes

I know exactly why and it’s not a bug but it’s a very compelling argument for something @insti has been advocating recently. The width of the yellow brick road is a function of its slope. So when a shallower spot is coming up it also means the road width will be shrinking. This is how we get the universal property that you transition from good side (green) to right lane (blue) to wrong lane (orange) to bad side (red, eep day) once per day. But when you hit a kink in the road and the road width shrinks, weirdness ensues. You can have situations like you observed, where the road shrinks so if you’re skating the edge you have more work to do on the first day of the shallow section. And then when the road becomes steep (and thus wider) again you may suddenly coast back onto the road, making your bare minimum amount negative. Anyway, so we monotonize that conservatively so you can just trust the table even though it’s the convolutedest thing ever.

This would all go away if the True Road, the thing you dialed with the road dial, was not the centerline but the critical edge. This is related to thinking of it not as a yellow brick road but a yellow brick halfplane, where the key thing you care about is the boundary between safe and not safe.

We will get there! Thanks so much for spotting these manifestations of our poor design decisions.

Short version: It happens because the critical edge is not monotone but we adjust the values in the table so they are monotone. So you can trust the table to give the true bare mins by each day.

2 Likes

I’m not sure I follow. I think I understand the difference between the critical edge and the centerline, but it looks to me like the road’s critical edge is monotonically increasing and does not contain any flat or negative spots: https://www.dropbox.com/s/23p4verivhwa7ww/Screenshot%202015-06-16%2015.13.10.png?dl=0 . So if the table is tracking the road (criticaledge or centerline) why does it include a flat section where the road clearly doesn’t?

2 Likes

It’s because we show whatever the current road width is everywhere. It will change when you actually get to the kinks in the road. Our excuse has been that the road looks better that way with consistent width, but it’s probably a terrible idea for this reason. Of course now we know the more fundamental fix (dial the critical edge, not the centerline – thanks again to @insti for convincing us!) so we may let this mess stand a bit longer.

Really sorry for the confusion it causes and thanks so much for pointing out things like this!

4 Likes

OMG. Now I get it!

I’ve actually been confused about this for a really really long time but didn’t realize it. Last year I spent a lot of time comparing #2 on the contract (https://www.beeminder.com/contract) with the visuals, trying to figure out how you could possibly be making this guarantee with a constant-width road. I ended up concluding that all goals worked like weight loss goals where the road width was dynamic but that they were split out in the contract text for ease of reading.

I’m not sure I see the road dial as the issue honestly. It seems to me that the graph of the yellow brick road ought to display the truth regardless of how you make edits to the road.

3 Likes

Looking back through my old support@ conversations, I think this also explains some of the headaches I’ve been having with Do Less goals. In order to safely abuse the “alternating days can be red” loophole, you need to compute where the critical edge of the road will be in the future, but if the road width can change at midnight then you can end up in the red when yesterday that data point looked like it would be orange.

I was never able to figure this out before, so I ended up having a few convoluted conversations with Alice. I get it now Hallelujah!

4 Likes

Doh…despite knowing all this I still managed to goof it up. I ended yesterday in the wrong lane with 0.71 to spare and today I’m going to derail because the road width shrank at midnight to put me into the red. You can see this on the email history for the goal (orange -> red at midnight).

Since I was in the orange yesterday I suppose Beeminder is technically within its rights to derail me today, but it’s still pretty frustrating. On the weight-loss goals, the penalty for being in the red is that adding a new datapoint can derail you. But it appears that on do-less goals the penalty is that you can derail without even entering any new data.

I plan to dispute the derail when it happens tomorrow on the basis that at the time I entered yesterday’s data point Beeminder told me that I had the leeway to do it. Maybe I should have known better from this discussion but I think the main UI (including email reminders and Android app) needs to not lie to people despite whatever the useful table (website only) says.

5 Likes

Definitely not a legit derail, any time there’s any confusion, even if it wasn’t our fault, which in this case it clearly is. More at blog.beeminder.com/legit on deciding when a derailment is legit.

3 Likes