Mother of Bugs: Two Consecutive Days In The Red

Bugabee
1

Currently, as I understand it, Beeminder has a patch to fix some problems, and this patch makes it so that the derail condition is something like:

IF you were in the red at your last deadline,
and IF you will be in the red at the next deadline if no additional data points are entered,
THEN derail.

This is, of course, a counterintuitive derail condition that will often cause derails when it shouldn’t.

Because of this problematic derail condition, numerous other patches were introduced to fix these problems, and these in turn cause other problems, and so forth.

So it seems likely that there is a whole cascade of bugs resulting from this one incorrect derail condition.

For instance

And there are probably others as well.

From the new user’s perspective these issues are very confusing and not explained clearly, and result in frustrating things like random unexplained derailments and inability to retrorachet with cryptic error messages.

I understand this is being worked on, so thank you! I’m putting this here because I think it’s likely that there are many issues resulting from this “mother of bugs.”

While there may be technical issues with this, from my perspective the most natural derail condition would be to check only at the time of deadline, and then patch up whatever issues result from this.

3 Likes
2

Thanks again for the bug report (cross reference: “Bug: cannot ratchet to 0 days”)! I’d say the real Mother of Bugs is the lack of Yellow Brick Half-Plane and we’re actually debating whether this 2-red-days-in-a-row bug is orthogonal to YBHP or not. If it is then I think we’ll have the fix quite soon. If it’s wrapped up with YBHP then, well, maybe “soon” with scarequotes but we’re making steady progress either way.

Normal users can stop reading at this point but in case you’re interested, here are excerpts from the discussion between me and @bee…

Gory Details

Status Quo

When you derail at the end of an eep day, the road jumps to where the datapoint is on the post-eep day. Beebrain’s test for derailment is “yesterday and today both in the red”. That way when the deadline hits and the goal is rebrained, Beebrain sees that what’s-now-yesterday is red and what’s-now-today is also red so that’s a derailment. When the goal is rerailed, today is no longer red so everything is fine.

Proposal

Rerail by jumping the road to the datapoint on the eep day and change Beebrain’s definition of derailment to “yesterday is red”.

What That Changes

  1. No more do-less loophole (Issue #250) because the derail is triggered as soon as you end the day in the red. It becomes a universal invariant that there are no red datapoints in the past. If you hit the deadline above your do-less road, that’s a derail, no eking back on by flatlining into the next day.

  2. Eep days after derailments are fine, ie, true zero-mercy.

  3. Derailments are no longer visually indicated by red datapoints. So probably a prereq for this is visually annotating derailments on the graph, which seems worthwhile anyway.

Bee’s Counterpoints

  1. it complicates genmercy – we need to deploy that in the old world order first
  2. road width makes this all horribly messy so post-YBHP may be much easier and cleaner
  3. need to rethink data structures for storing derailment dates

UPDATE: Countercounterpoints

  1. General Mercy now deployed!
  2. Tentatively not true – road width doesn’t impact this change
  3. Avoidable by having Beebrain just annotate derails based on the “RECOMMIT” datapoints

most recent dialog…

B: We need to figure out if this is orthogonal to YBHP or not. So… does roadwidth or lack thereof affect recommits (and how)? what would this “move road to yesterday’s point” look like in the YBHP world? are you increasing the number of rewrites of recommit behavior? what happens to the loophole or the “can’t ratchet to 0 right after a derail” problems in YBHP world if we don’t change anything now?

D: Good questions!

  1. From staring at the diagram I’m just now adding to the gissue description above, I believe the answer is that road width doesn’t affect this.
  2. As for what it looks like in the YBHP world (where critical edge and centerline are the same thing), everything is just beautifully straightforward.
  3. No, I believe there’s no extra work in doing this before YBHP. That’s the sense in which I believe it’s orthogonal. We can make this change before or after YBHP without affecting anything about how we proceed with YBHP.
  4. As also implied by the orthogonality, the do-less loophole and other 2-red-days-in-row bugs persist after YBHP.

In other words, we have to do this eventually anyway. Might as well do it now. If I’m wrong about the orthogonality then we can abort.

2 Likes
3

For future historians, my most recent attempt at documenting the status quo was Why don't I derail?

[Edit: Re-reading my own post made me realize a nitpick: The definition should be “You derail when any day in the past is red” (this accounts for retroactive data edits better than “Yesterday is in the red” does)]

1 Like
4

I disagree - you should not derail based on a retroactive data edit, only if you were in the red at the last deadline. If I change some data from a month ago, it seems wrong to derail me today.

(“Yesterday is in the red” is ambiguous - do you mean in the red at any time, or just at the deadline?)

And what if you change the deadline? Does that change the time for checking derailment?

1 Like
5

UPDATE: Fixed! http://beeminder.com/changelog#3083

2 Likes
6

Yay!

@dreev

What’s the current derail condition, and how are retroactive data edits handled?

7

If you cross the deadline and what’s-now-yesterday is still in the red, that’s a derail. That rule is applied universally / consistently / naively, so editing past data that causes yesterday to be red will also derail you.

1 Like