Mother of Bugs: Two Consecutive Days In The Red

Bugabee
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