Beeminder Forum

Progress Report on Yellow Brick Half-Plane

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:

  1. 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?

  2. 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.

  3. 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.

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

  5. 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.

  6. 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.

  7. 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.

  8. 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.

  9. 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.)


what is asof?

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


me too!

Seems like the Uluc lobbying has won?
This is what I get ->


I don’t really have an eye for design, but: 1) I am anti-hard green boundary at 7, but 2) what does a gradient look like?


I googled this for you :smiley:


lol, I think he meant on the graph


That’s like “as of”, as in, the date the data is plotted as of. Or what counted as today, as of when the graph was generated. Very gory details in GitHub!

Yeah, I think having the good side green and the bad side red is going to look best. Much fainter green and red, but, yes. Remaining aesthetic things to work out are:

  1. indicating 7 days of buffer. yellow line? darker green?
  2. fixing the off-by-one error with the regions
  3. new way to indicate the oinkzone nee pinkzone (or maybe it should be called the anti-akrasia zone? nozone? it’s the region you can’t let the road intersect when editing the road)

Ooh, smart. Possibly easier said than done to make the gradient fade parallel to the road?

The one thing that makes me think I wouldn’t like the gradient is that I like being able to see distinct regions in the graph as reference points, like “where yellow turns to green is n days of buffer” or “where light green turns to dark green is n days of buffer.” So stair stepping appeals to me more than a gradient.

1 Like

well I think the gradient would just be for the very last region. so you’d still get the stairstepping for the other distinct regions, but the very last region (> 7 days or whatever) would fade out.

I agree that there should be stairstepping for the other distinct regions.

Zedmango’s got what I intended :slight_smile:

1 Like

Still see just green all the way through

Smaller sizes are losing the green

1 Like

It now seems we have two types of green !

1 Like

@dreev bug or new design ?
Screenshot 2020-02-08 at 09.31.27

By the way, it was more satisfying to see the area above the green line be , well, green, rather than the new yellow stripes

1 Like

Experimentation! Shading the whole regions makes a ton of sense semantically but looked a little garish. By the Pareto Dominance Principle we figure we want to launch YBHP with the graphs as similar as possible to the status quo. Then we can think about bringing back the colored regions. Thanks to @saranli it’s getting very easy to experiment now…

The following defines how all the regions and the boundaries between them are colored. A region is defined from d to D days to derailment (if d=D it’s a region boundary, i.e., an isoline of the the DTD function), using fill-color fcolor, stroke-color scolor, stroke-width w, and fill-opacity op. Finally, xrange, a list like [xmin, xmax], gives the x-axis range to apply it to. If xrange is null we use [-infinity, infinity].

xrfull = [goal.tini, goal.tfin]          // x-axis range tini-tfin
xrakr  = [goal.asof, goal.asof+7*bu.SID] // now to akrasia horiz.
lgreen = "#cceecc" // light green region
dgreen = "#b2e5b2" // dark green region
bgreen = "#00aa00" // bright green same as GRNDOT for green dots
lyello = "#ffff88" // light yellow same as LYEL for classic YBR
lblue  = "#e5e5ff" // light blue region
bblue  = "#3f3fff" // bright blue same as BLUDOT for blue dots
lorang = "#fff1d8" // light orange
borang = "#ffa500" // bright orange same as ORNDOT for orange dots
pink   = "#ffe5e5" // pink for nozone/oinkzone or bad side of YBR

//[ d,  D, fcolor, scolor,   w,  op, xrange] <-- region color definition
//[ 6, -1, dgreen,    "none",   0,   1, xrfull],  // dark green region
  [ 6,  6, "none",    bgreen, 1.5,   1, xrfull],  // 1-week guiding line
//[ 2,  6, lgreen,    "none",   0,   1, xrfull],  // green region
  [ 2,  2, "none",    bblue,  1.5,   1, xrfull],  // blue line
//[ 1,  2, lblue,     "none",   0,   1, xrfull],  // blue region
  [ 1,  1, "none",    borang, 1.5,   1, xrfull],  // orange line
//[ 0,  1, lorang,    "none",   0,   1, xrfull],  // orange region
  [ 0,  2, lyello,    "none",   0, 0.5, xrfull],  // YBR equivalent
//[ 0, -2, pink,      "none",   0,   1, null],    // entire wrong side

What would be the possible degradation by improving the colours used in the graphs? Are there any users that consider yellow to be a more positive colour than green? :slight_smile:


1 Like

My green is much less saturated (a rather weak #EDFFD8) and I like your green better. The halfplane is greener on the other side of the fence maybe. For what little it’s worth, my green also fills the whole half-plane.

More serious, but possibly very random point brought to mind by your isolines (which go away in flat periods, right?): have you ever considered losing the derail flat period and just having the line drop immediately to the point where you have 7 days buffer? I’m not sure how much if at all this is connected with your halfplane work because I’ve not had to implement this stuff without the halfplane and I have no do-less – but I think it has worked better for me that way because I can no longer ignore the goal in flat periods (not to mention simpler).

1 Like