Beeminder RetroRatchet via API calls

1

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.

-Jolly

Daniel Reeves dreeves@beeminder.com 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
settings.

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
below that.)

Thanks so much for getting the ball rolling on this, Paul!

On Fri, Dec 7, 2012 at 8:02 PM, Paul Fenwick paul.j.fenwick@gmail.com wrote:

G’day everyone,

Now that we have a Beeminder API, I’m looking at writing my own
RetroRatchet functionality (
RetroRatchet! – Customer Feedback for Beeminder
). 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:

  1. 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.
  2. 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
built in.

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

Paul

–
http://dreev.es – search://“Daniel Reeves”
Follow the Yellow Brick Road – http://beeminder.com

2

G’day everyone,

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:

  1. 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.
  2. 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
built in.

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

Paul

3

I’d love to just have a “Delete safety buffer” or “set safety buffer to x” button in the UI…
I face this issue a lot, esp with my fitbit goals - if I ramp the goal up too fast, I know I’m going to forget to dial it back down…

-Jolly

-----Original Message-----
From: akratics@googlegroups.com [mailto:akratics@googlegroups.com] On
Behalf Of Paul Fenwick
Sent: Friday, December 07, 2012 11:03 PM
To: akratics@googlegroups.com
Subject: Beeminder RetroRatchet via API calls

G’day everyone,

Now that we have a Beeminder API, I’m looking at writing my own
RetroRatchet functionality (
General: Top (348 ideas) – Customer Feedback for Beeminder
general/suggestions/2289727-retroratchet-
). 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:

  1. 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.
  2. 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 built in.

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

Paul

4

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

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
below that.)

Thanks so much for getting the ball rolling on this, Paul!

On Fri, Dec 7, 2012 at 8:02 PM, Paul Fenwick paul.j.fenwick@gmail.com wrote:

G’day everyone,

Now that we have a Beeminder API, I’m looking at writing my own
RetroRatchet functionality (
RetroRatchet! – Customer Feedback for Beeminder
). 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:

  1. 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.
  2. 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
built in.

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

Paul

–
http://dreev.es – search://“Daniel Reeves”
Follow the Yellow Brick Road – http://beeminder.com

5

Aw, shucks! Thanks Jolly! Solution to that “problem” from
Perverse Incentives and the Paradox of Beeminder's Sting | Beeminder Blog :

…Beeminder’s sting is so valuable as to be self-defeating. In other
words, it’s hard to be motivated by the threat of having to pay
Beeminder if you feel that Beeminder has already earned that money!
Please don’t laugh but we’d like to propose that the solution is to
just hurry and get to an obscene pledge amount. After the $5 and $10
pledges it gets obscene quite quickly: $30, $90, $270…

Also check out our latest blog post: Pledge Short-Circuiting | Beeminder Blog
(per usual, that was first fleshed out here on the akratics list –
thanks everyone!).

On Mon, Dec 10, 2012 at 3:00 PM, Apneet Jolly jolly@ajollylife.com wrote:

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.

-Jolly

Daniel Reeves dreeves@beeminder.com 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
settings.

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:
Allow scheduling of "days off" in advance – Customer Feedback for Beeminder
and some nitty-gritty here:
Trello

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
below that.)

Thanks so much for getting the ball rolling on this, Paul!

On Fri, Dec 7, 2012 at 8:02 PM, Paul Fenwick paul.j.fenwick@gmail.com
wrote:

G’day everyone,

Now that we have a Beeminder API, I’m looking at writing my own
RetroRatchet functionality (

RetroRatchet! – Customer Feedback for Beeminder
). 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:

  1. 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.
  2. 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
built in.

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

Paul

–
http://dreev.es – search://“Daniel Reeves”
Follow the Yellow Brick Road – http://beeminder.com

–
http://dreev.es – search://“Daniel Reeves”
Follow the Yellow Brick Road – http://beeminder.com