Beeminder Forum

Progress Report on Yellow Brick Half-Plane


So it kind of sounds like we can just wait 2 more weeks and then rip WLL out of Beebrain and we’re done with #6?

Although: however long we wait, it’s possible for someone to have been inactive from their first datapoint until a couple days ago. Like it’s been a month since they started their goal but they only actually have a few datapoints, all but the first recent. So I think we need to just manually intercede to make those dfluxes reasonable. The longer we wait the fewer of them there will be but the number may already be plenty small and we could do this now.

(But now I’m confused about the mechanics of this. @bee, when Beebrain decides to up and change vini, as in WLL, how does that make its way back to the database?)

At the moment it doesn’t, really. The goal thinks its vini is A and keeps sending that to beebrain, and beebrain keeps ignoring it and deciding to use B instead. Beebrain does return that to the goal in its output, so the actually used vini is stored in the bb field. I did one update query already that set vini = bb.vini for noisy goals where they differed. I’ll do that again just before you deploy a new non-WLL beebrain.

1 Like

I’m adding the dflux field to the db, and storing what the user enters when they set up the goal there. Possibly it shouldn’t be called dflux, though, because it is not the nicely computed thing that bbrain does.

1 Like

Proposal: What Beebrain computes is stdflux because it’s like standard deviation, computed from data so far. What the user specifies is maxflux – max daily fluctuation.

DONE: Refactor dflux in beebrain to stdflux
DONE: Beeminder’s attr is called maxflux.

Meta: We’ll edit to-do items like above to say “DONE” when they’re done, so we can grep this thread for to-dos in the usual way.

Plan for finishing up #7 (die noisy param and auto-widening):

  1. Big picture is we need to obliterate the “noisy” field
  2. Probably make all noisy graphs razor roads
  3. For most cases we can just set razor road = existing critical edge
  4. But there are a couple cases where we’ll eyeball the graphs PLN
  5. The number of graphs goes down the longer we wait but maybe it’s already a perfectly manageable number
  6. Email everyone whose graph we’re changing. Those emails (even when slightly smarmbotty, though we’ll make sure not to cross that line) really impress people and lead to good feedback and insight for us. (This is us psyching ourselves up for this because emailing people has a massive ugh field around it for us. Speaking of which, it may be time to try which supposedly makes it much easier to email arbitrary sets of users.)
  7. [DONE] Pretty urgent bugfix: restarting frozen/archived noisy goals need to not restart you on the razor’s edge
  8. Open question how exactly recommits should work. Arguably razor’s edge but with flat spot is ok. For weight loss you presumably derailed due to an up-fluctuation so maybe you don’t need additional margin, just the flat post? This might vary a lot across users though so this is pretty tricky. Let’s say we start with making sure we’re pareto-dominating the status quo. Maybe that means recommits happen at bb:stdflux above the current datapoint?

PLN: better plan

Do we really want to make all existing noisy graphs razor roads? An alternate, lazier solution would be to do an update that sets the abslnw = current lnw and then be done with it.

There’d be no more growing or shrinking, but it wouldn’t look like a massive change – save that for later when we’ve got true YBHP. Then we don’t have to do transforms on road matrices. (Well, not yet. We’ll have to transform road matrices to change to YBHP anyway, so might as well delay for now and change status quo as little as possible for existing noisy folks. For now.)

1 Like

Yeah, I agree. In any case that’s a good first step. We can take the next step later, but you’re right, that’s more part of death-to-lanes than death-to-noisy/auto-widening.

Thanks for the update! I am still very excited about this! And this update is well timed since I am just on the verge of re-ramping up my Beeminder usage after taking a year off (which has included a lot of re-remembering Beeminder’s quirks including this one).

1 Like

Ok, so tentative plan going forward:

Weightloss Leniency

  • [DONE] Danny kills it in Beebrain
  • [DONE] lets Bee know just prior to deploying updated beebrain
  • [DONE] Bee does a final DB update to set goal.vini = bb[:vini]

Existing Noisy Roads

  • write a blog post justifying / explaining our reasoning for making the change, and laying out clear expectations about what will change for ppl with currently noisy goals.
  • auto-email all those ppl to let them know that we’re making a change [solicit feedback?]
  • shortly thereafter run a DB update that sets goal.abslnw = bb[:lnw] (~ or possibly bb[:dflux] if that happens to be more generous?)
  • Danny rips noisy out of beebrain
  • Do I need to stop sending noisy to beebrain as well?

Am I missing things?


You’re satisfied on the question of how db.vini could ever not equal bb.vini?

Also we’re killing “dflux” and replacing with “stdflux” in Beebrain and “maxflux” in Rails. [DONE]

Do we maybe need a way to recognize weightloss goals even if the goal type is changed to custom? Right now “noisy” basically tells us this, but without noisy then inbox goals and weight loss goals are differentiable I guess only by the lane width being set (either to 0 or to dflux based on if it is an existing goal vs new/restarted goal). Is that weird? a problem? Well, by those things, and by the goal type, but users w/access to custom goals can change the goal type.


I’d say yes. In general I think there’s huge value in having much more structured data about people’s goals. Similarly I think it’s worth gathering more information on users too, for Science. For goals, it matters both for Science and for Engineering. Like right now we don’t have a good way to know how many pushups goals are out there and we’d really like to know that when building a goal creation wizard more like StickK’s.

In conclusion, as we’re hacking away on transitioning these goals, don’t lose the information that they used to have noisy set to true.

1 Like

This thread is the coolest.


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.


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 – – 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. :slight_smile:) 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!

1 Like

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?

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:

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.


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

You said:

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?

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.