The “problem” with you guys being so responsive/awesome is in previous times I’ve derailed my mental thought process has included “Beeminder is awesome, they deserve the money…”
And I also dislike the dummy data points, and a cap on safety buffer seems like a reasonable solution.
Daniel Reeves firstname.lastname@example.org wrote:
Love this! Except for the idea of implementing it via dummy datapoints
– that gives me the heebie-jeebies. We’ll work very hard to make that
not be a tempting option, we promise!
It’s definitely a high priority for us to implement something that
addresses this, maybe starting with a cap on safety buffer in advanced
Clarification: you can’t steepen for just an hour. A day is the
minimum. The advantage of that is that any road dialing you do is
fully undoable as long as you undo it before midnight. (That’s also
why “dial it harder starting right now” is easier said than done –
you have to define a window for undoability or something.)
Btw, your last point is covered in another suggestion from uservoice:
and some nitty-gritty here:
Finally, I highly encourage implementing this via the API with the
auto-steepening trick you propose. You could even maybe do it totally
statelessly: Every morning you check if your safety buffer exceeds
your threshold. If so, double the steepness. If not, halve it. (Maybe
that would make it end up too shallow if you’re an edge-skater though.
And this is akratics anonymous, so of course we’re all edge-skaters.
So maybe it remembers the last human-entered steepness and doesn’t go
Thanks so much for getting the ball rolling on this, Paul!
On Fri, Dec 7, 2012 at 8:02 PM, Paul Fenwick email@example.com wrote:
Now that we have a Beeminder API, I’m looking at writing my own
RetroRatchet functionality (
). In a nutshell, the algorithm looks like this:
Assign a maximum safety buffer for a goal.
Assign a ‘standard’ slope for a goal (by default, the current slope).
foreach interval (eg, daily):
- if the safety buffer is less than our maximum safety buffer
- Set our slope to ‘standard’.
- else if our safety buffer is greater than our maximum safety buffer
- Increase the slope to some amount higher than the standard
The gotchas here are:
- This doesn’t do anything if our ideal safety buffer is less than
seven days, since we can only makes changes one week in advance.
- I’m not exactly sure if I can just set the slope of a graph
insanely high for an hour, and then change it back again. In theory
that’s an effective way of ablating safety buffers, but In the case of
malfunction, one ends up with an unachievable goal.
A much more reliable and safer way of implementing userland
RetroRatchet would be to simply submit data points which immediately
suck up the safety buffer, without changing the yellow-brick-road as
well. However then we have essentially fake date in the Beeminder
graphs. Sure, we could tag such fake data that one could do a data
export via the API and filter out all the fake points, and then use a
client-side graphing engine to redraw the ‘true’ graph, but that seems
like a lot of effort, especially when Beeminder has a graphing engine
Daniel/Bethany: I’m assuming a retroratchet functionality via the web
interface is at least moderately difficult, but would it be possible
to expose an API call which implements this? At the most basic level,
adding an optional ‘effective_by’ parameter to ‘dial_road’ would allow
us to ramp our roads early. Of course, one could only use
effective_by for dates sooner than one week if it was making the road
harder. At a more advanced level, being able to set a maximum
safety buffer directly into a goal would be fabulous.
I don’t know how things work under the hood, but an effective_by date
would also allow changes that weren’t exactly a week in advance, which
would allow me to submit data to automatically flatten my road for
various things when I go on business trips, or head off to Burning