Progress Report on Yellow Brick Half-Plane

[dreev]

Latest status: Bee is deep in refactoring of how the “no mercy” setting works so that we can generalize that so you can choose how much safety buffer you get when you derail which turns out to be an important feature for killing the last of the auto-widening yellow brick roads, which is just about the last in a long list of prerequisites for killing the concept of lanes. Phew! We’re getting there!

Here’s how @bee put it in a daily beemail:

Do you have value for being able to parameterize how much mercy you get when you derail a goal? I think mostly the feedback we’ve heard about the no-mercy option is that people want less mercy and are frustrated that our idea of “no mercy” still gives them 2 days off because they want for everything to always be an eep day no matter what. However, because of technical reasons, you can’t have an eep day immediately after a derail, so… well, what I’m talking about here does not fix that want. (Not that the technical reasons are insurmountable; just not on the table quite yet because, well, it’s technical.)

But does anyone ever wish they could have like 3 days off after a derail, or 2 weeks, or something?

Here’s the deal: currently with new-world-order weight roads (i.e. razor roads), if you have an up day and derail you’ll be recommitted right on the razor’s edge.

I love that because I hated how in the old version if I derailed my weight goal, my road moved to put my offending datapoint right in the middle of the road, with a big wide buffer above me. That meant that one bad day not only cost me money, it was then allowed to compound into many bad days in a row, which made it really easy to backslide. Now if I screw up, the road recommits with me right on the edge – I get a little buffer above where the road previously was (because my derail point is necessarily above the old road), but I still have to stay in the game and keep making progress.

A better implementation would let you adjust how much room you get on a recommit by having a parameterized “mercy” setting.

What I’m imagining is that this would be quite a bit like specifying your auto-ratchet amount. For do-more goals, you’d specify a number of days. For weight loss roads, and do-less roads too, you’d want to specify how much mercy you got on recommit in terms of units of buffer. If you liked the old style behavior with weight roads where you got a bunch of extra buffer from derailing, you could set your amount-of-mercy equal to your maximum daily fluctuation. If you wanted less buffer, you could decrease that amount, anywhere down to ‘0’, which would be like the current (new) behavior.

Anyhow, this is just kind of spitballing, except I’m probably going to do it.

[dreev]

We obviously got super distracted by a million things – many of which are very related to YBHP, like Javascript graphs! We actually planned for YBHP to be a prereq for Javascript graphs but then @saranli, in his amazingness, managed to port all the hideous lanes cruft, fully backward-compatibly, so now we have a single new codebase for all of that from which to proceed.

Oh and we did ship Generalized Mercy – Feature Announcement: General Mercy | Beeminder Blog – and forgot to update this thread [sheepish].

The remaining prereq is finishing death-to-autowidening-roads. All new roads have been sans autowidening for a quite a while and we’ve just been putting off some painful migrations for existing roads. (Upside is that the longer we wait the fewer there are to migrate and the less daunting that job is. ) Plus other loose ends we’re not happy with in the new “razor roads” for weight loss.

Anyway, it’s embarrassing to be “so close” on this this long but it remains true and remains important!

[zedmango]

@dreev

The remaining prereq is finishing death-to-autowidening-roads. All new roads have been sans autowidening for a quite a while and we’ve just been putting off some painful migrations for existing roads.

Thank you for this! Very exciting that we’re so close.

Would you please clarify how the width of the new, sans-autowidening roads is determined? Is it just 1 day’s worth?

And would you clarify the relationship between the width of the road, the color of the goal, and the number of days till derailment? Is it just that the lanes correspond to different colors and the colors represent different numbers of days till derailment?

[dreev]

@zedmango

how the width of the new, sans-autowidening roads is determined?

The idea is to use a zero-width road but shift it to give you enough safety buffer. This stuff really wants a blog post or other documentation but has to be gleaned in tweet-sized pieces for now:

Beeminder Changelog

@zedmango

relationship between the width of the road, the color of the goal, and the number of days till derailment

We do like the colors a lot and want those to stay, just no actual lanes. So the yellow brick road has no width but if you’re on the wrong side of it you’re in the red (will derail within 24 hours), if you have 24-48 hours (< 2 days) till you derail then you’re in the orange zone approaching the YBR, a little further away is the blue zone (2 days of buffer), and then the green zone (3 or more days of buffer).

So, yeah, with YBHP the colors encode nothing more nor less than amount of safety buffer.

[zedmango]

No, sorry, I wasn’t clear. I meant now, not after YBHP.

You said:

@dreev

All new roads have been sans autowidening for a quite a while and we’ve just been putting off some painful migrations for existing roads

I’m asking about the roads now, which are sans autowidening.

How is the width of roads now determined? Is it just one day’s worth?

And do the lanes now correspond to different colors and different numbers of days till derailment?

[zedmango]

@dreev

We do like the colors a lot and want those to stay, just no actual lanes. So the yellow brick road has no width but if you’re on the wrong side of it you’re in the red (will derail within 24 hours),

I’m confused. Shouldn’t derailment happen as soon as you cross the wrong side? Or if you’re on the wrong side at the next deadline? (I’m now asking about after YBHP.)

What’s the new derailment condition?

[howtodowtle]

@zedmango

@dreev

We do like the colors a lot and want those to stay, just no actual lanes. So the yellow brick road has no width but if you’re on the wrong side of it you’re in the red (will derail within 24 hours),

I’m confused. Shouldn’t derailment happen as soon as you cross the wrong side? Or if you’re on the wrong side at the next deadline? (I’m now asking about after YBHP.)

What’s the new derailment condition?

You can be in the red during the current day, before your deadline. In fact, on an emergency day, you start out in the red. If you haven’t moved back to safety (any other color) by your deadline (default: midnight), you derail.

I very, very strongly suppose this will not change.

[howtodowtle]

@zedmango

I’m asking about the roads now, which are sans autowidening.

How is the width of roads now determined? Is it just one day’s worth?

And do the lanes now correspond to different colors and different numbers of days till derailment?

And I think @dreev’s answer is also true now:

@"dreev"

if you’re on the wrong side of it you’re in the red (will derail within 24 hours), if you have 24-48 hours (< 2 days) till you derail then you’re in the orange zone approaching the YBR, a little further away is the blue zone (2 days of buffer), and then the green zone (3 or more days of buffer).

[zedmango]

@howtodowtle no - unfortunately it’s a lot more complicated than that currently. Right now, you derail if, at any time, you’re in the red and you were in the red yesterday.

I’m asking @dreev what the new derailment condition under YBHP will be.

[howtodowtle]

Isn’t that (the current situation) de facto what I wrote, just in other words?

If you start in the red today and were in the red yesterday, you derail. That’s the same as being in the red and failing to get back on the road by midnight.

[zedmango]

It’s a lot more complicated than that. Check out:

Mother of Bugs: Two Consecutive Days In The Red

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…

Why don't I derail?

I’m doing two “do less” goals (Internet browsing, as measured by Rescuetime, and iPhone usage which I can track on my phone and input manually). Between them, I have gone into the red three times. When I do, beeminder gives me all sorts of scary warnings and, shortly before midnight assures me I’m minutes from derailing. But when midnight rolls around I’m back in the orange again. Despite my $5 pledges I haven’t paid out any money. Perhaps the first derailment is free, but I just had my second d…

Mid-day derailing when yesterday was red

I think I may have found one explanation for the “multiple derailments on the same day” bug. I had assumed that you could only derail at the time of your deadline. But apparently if you were in the red yesterday, the system will derail you if you’re in the red at any time during the day. This causes a problem with any goal that always goes into the red mid-day. One of my goals is always in the red during the day but goes back by my deadline. So if I derailed the previous day I will always dera…

[zedmango]

@dreev sorry - I was confused.

Wait a second - autowidening was only for weight loss?

The Magical Widening Yellow Brick Road

@dreev

The idea is to use a zero-width road but shift it to give you enough safety buffer

So that’s just for weight loss goals, right?

@dreev

So the yellow brick road has no width but if you’re on the wrong side of it you’re in the red (will derail within 24 hours),

I still don’t understand this.

[drtall]

There’s at least three ways the road width can change:

1. You use the API to set lanewidth on the goal.
2. You change the slope of your road (via road dial or derail or any other means), which automatically changes lanewidth as if by #1.
3. The goal is a weight loss goal and you would be in the red today without being in the orange yesterday.

Type #3 is called “autowidening”. Type #2 (which applies to all goals) is automatic but it doesn’t have a name that I’m aware of.

[zedmango]

As I understand it, #3 is no longer true:

The Magical Widening Yellow Brick Road

Some experimenting with changing road width shows that the colors now are inconsistent but generally go with the lanes, not the number of days till derailment, sadly.

Relevant:

Green/blue inconsistencies

Interesting. This seems to be an artefact of setting a custom road width. By the custom road width of 1000, it’s clearly green because you’re above it. By the ‘natural’ road width of 2500 (related to your slope), it would be in the upper lane, so blue. I suspect that the graph colour is set by something related to beebrain that generates the graphs (and so knows/cares about road width), and that the headline blue colour is based on the time-to-derailment. Agreed that it would be good for the…

What do the colors actually mean?

Addendum: Beeminder is actually inconsistent with itself about colors! When you load the goal page for https://www.beeminder.com/kenoubi/bike (for example) the HTML returned says <span class="doom blue" data-doom="2147306399">, but then the Javascript doom counter immediately changes it to green. The behavior of the updateDoom function is responsible for this (IMO better) behavior. @dreev @bee Would you consider just changing the API for roadstatuscolor to match this code (from the Beeminder …

Dashboard colors don't match goal page colors on Do More goals

I have two goals with two safe days that are showing orange on the dashboard: [image] But on the goal pages they’re showing blue, eg: [image] I know some goals are tricky in terms of safe days vs colors, but these are straightforward Do More goals where the lane width is a day’s worth of effort. Probably worth fixing (if possible) to lower newbee confusion. (I note that these two goals appear to need exactly a day’s worth of effort to stay on track, which means they’re right on the boundary…

How is "days until wrong lane" being calculated?

Looking at my numbers here https://www.beeminder.com/apolyton/goals/weight The latest value is 86.8 The “hard cap by day” table shows that the 86.8 value is over the hard cap for the coming days including Thursday. But the “time left” is only 3 days (2 and today)? What am I missing? [image]

So basically beeminder will hit maturity when YBHP is here and all these weird bugs go away.

@dreev With YBHP will derailments occur only if you’re on the wrong side at your deadline? So that’s why it’s “within 24 hours”?

[dreev]

@zedmango

As I understand it, #3 is no longer true

Correct, except we’re not done migrating existing roads and have other loose ends before we’re happy with declaring auto-widening fully dead.

@zedmango

With YBHP will derailments occur only if you’re on the wrong side at your deadline? So that’s why it’s “within 24 hours”?

Right. Gory details: Mother of Bugs: Two Consecutive Days In The Red - #2 by dreev

[zedmango]

@dreev thanks!

Any chance we’ll get color coding based on the “lead days” setting, like I suggested here?

Feature Request: Color-ratchet

Well the easiest way to implement would be to make use of the “lead days” setting. That way there would not need to be any new settings - instead, you just base the colors on the lead days for the goal. So for instance: Default: Lead Days 4, Blue 2, Orange 1, Red 0 but if you change Lead Days to 6, everything else gets bumped up 2: Lead Days 6, Blue 4, Orange 3, Red 2 But eventually there could be a detailed color configurer where you could specify which colors the goal would become at …

So rather than “red” triggering the day before, it would trigger at a number of days based on the “lead days” setting.

[dreev]

Status report on the key visual aspect of the Yellow Brick Half-Plane project, thanks to Uluc (@saranli)! This is all deep in the guts of Beebrain and, as usual in this thread, users don’t need to care about this at all, other than how the graph ends up looking, which is very much in flux.

Our technical term for this is days-to-derail (dtd) isolines. Oh and the yellow brick road (ybr) itself is now assumed to be zero width. It’s the bright line that you derail if you cross. Well, if you end the day on the wrong side of. So the ybr is the 1-day isoline. (Technically 0-day in the implementation right now. We have a big off-by-one error in everything that follows. See item #0 below.) The 2-day isoline is the boundary between being in the orange and being in the blue. Beyond 3 days of safety buffer is green. Seems simple enough so far but this is much easier said than done and Uluc is a literal genius.

(My favorite quote from when we were hashing this out and he wrote a Matlab script to figure out how it should work: “I just lifted the PPR function to the continuous domain as a vector, taken the integral of its negation and plotted a curve through its isopoints.”)

Here are questions and comments for each other as we get ready to ship this for a few intrepid guinea pigs:

0. We’re currently drawing this with the first region closest to the road as red but you’re actually safe for more than 24 hours in that region so we need to shift all the colors. It’s the bad half-plane that’s red. The shading for the oinkzone (nee pinkzone) is kinda perfect but then we need another way to visually represent the oinkzone. Grayed out? Something like caution tape?

1. The ppr() function in broad.js enforced ppr=0 for t < asof. We put in an option to that function to force computation of past PPRs as well so we can show colored regions for t < asof. Otherwise the entire region before asof appeared green, which is technically correct but not very useful. We want to see what the dtd margins looked like in the past.

2. We haven’t yet implemented the yellow guiding lines for dtd > 7, but that will be really easy. We have the green region up until dtd - 7 for now, but any region between any two dtd values can be drawn. The algorithm Uluc devised can generically compute isolines for any dtd value, which are by definition guidelines anyway.

3. The current color selection is too saturated; region colors should probably be less pronounced.

4. If you open roadeditor_test.html in the browser, you should be able to edit the road and see the regions change in real-time.

5. Regions can be somewhat unintuitive for doless goals, but we’re fairly certain they’re correct. Inflection points in isolines either coincide with t=t_node for inflection points on the road, or when they cross boundaries across which the ppr function changes.

6. Palette optimization has not yet been done for png outputs, but we can do that once and for all once we decide on the colors.

7. Uluc is lobbying for not cutting of the green region at the 7-day boundary as Dreev suggested. It might be ugly or confusing. Maybe much lighter colors but having the green region cover the half-plane all the way out. We can still have the yellow guiding line to indicate the special 7-day boundary.

8. Still need to change the color and style of the centerline-cum-bright-derailment-line. Dreev was thinking it could be bright red or something. (The dotted line was a cute thing for emulating the painted line in the center of a physical road and doesn’t make sense in the new world order.)

Finally, there are some technically incorrect aspects of the isolines for do-more goals with downward sloping segments that we’re working on. Some parts of the isolines are closer to the actual derailment points on the road since they are offset from further parts of the road. A picture should make that make more sense:

Normally, that should just be a flatline up until the point where the isoline goes above the inflection point. (Uluc was hoping to avoid another pass over the isolines for monotonicity enforcement but probably not actually a big deal if that’s the best way to do it.)

Here is a do-less example:

For do-less goals with upward vertical slopes on the road, Uluc ensured consistency with very steep segments by shifting the dtd isoline by 2*delta where delta is the vertical displacement associated with that segment. That’s why you see weird looking blocky parts on the do-less graph above.

To get a better understanding, compare the following two graphs:

This way, regions don’t jump around when going from near-vertical to true vertical. We should probably do something similarly consistent for flat road segments, says Uluc. One possible interpretation for this vertical fix is that the PPR would be twice as much as the vertical displacement on the road. The ppr() function may also want to reflect that for consistency, but that’s probably an extreme edge case.

(PS: the centerline of the road appears wrong in those screenshots because it’s from the dynamic road editor which shows the centerline pre-edits.)

[zedmango]

what is asof?

[narthur]

I’ll put in my vote in agreement with Uluc on point 7.

[zedmango]

me too!