Imagine there’s an akrasia-aware camel who wants to drink more water, enough to support his trek across the desert. He’s hip, so he signs up for Beeminder.
This camel is clever and wants to put a cap on the number of gallons of water Beeminder counts each day. “If I drink two gallons,” he thinks, “Beeminder should count 2 for that day. But I drink five gallons, Beeminder should still only count 2.”
How does this hypothetical, akrasia-aware, clever camel achieve this?
The “max” aggregation method could be the solution… until the camel reads the aggday docs. (And yes, this camel can read, too!)
“Binary” is close, but the camel isn’t measuring whether he drank water or not (possible values only 0 or 1). Rather, he’s Beeminding how much water he drank (0, 1, or 2).
“Sum” is the default method and works fine except it doesn’t limit the amount counted per day.
Maybe the camel has to choose “last” and do the math himself? In this case, if he drinks a gallon of water, he enters 1 in Beeminder. Later on, he drinks another three gallons, so he enters 2 (1+3 = 4, but cap it at 2). That seems to be fudging the numbers though.
What would you suggest to our camel friend?
P.S.: I don’t know whether the camel is of the one- or two-humped variety. But probably two because they’re cool.
is the point of the aggregation so that he has to drink 2 gallons every single day, even if he drank 20 yesterday?
if so, setting a max safe days on the goal (also known as ‘autoratcheting’) is the Typical Beeminder Tool to accomplish that! that will trim safety buffer every night if it’s above the max value you set, so you can put yourself on the edge every single day.
Yeah, you’re looking at it differently than I was. You’re pulling the road up to match the value, while I’m trying to limit the values to prevent them from getting too far from the road.
Your solution is the best so far and I like it! However, I think it has one flaw: autoratcheting only works if the camel drinks at least two gallons every day. If, one day, he only drinks a gallon, he either goes off the road immediately or can make it up the next day.
Goes off the road immediately. This happens if he’s right on the edge as ratcheting would do with a value of 0 (I think). It also means a Beemergency every day and this camel likes some buffer.
Can make it up the next day. If autoratcheting with a value of 1+ days, the camel gets that many days of buffer–which is good for those long trips between oases. But the next day, he drinks three gallons (one more than two, to make up for the previous day) and the original buffer is instantly restored.
Restoring the buffer is fine, but it should be tied to the akrasia horizon, i.e. adjust the road seven days from now. Put another way, the difference between the (hopefully) green value entries and the yellow brick road should only increase through a road dial change.
Maybe the camel just has to suck it up and accept an “eep!” day every day? Or maybe the autoratchet function already auto-adjusts for this, i.e. if the camel starts eating into his safety buffer, the autoratchet value decreases accordingly?
Would the absolute lane width setting work in some way?
I’ve got a handful of goals in which I’ve set both the slope and an autoratchet. The slope enforces the minimum that I have to do, and the autoratchet enforces the maximum benefit that I can get from ‘drinking too much water’, or whatever. That may or may not be a useful framing.
At risk of confusing any actual newbees, here are some thoughts:
One of the custom aggregation methods is @drmaciver’s triangular minding, which causes each datapoint to be worth more than the previous datapoint. That’s the opposite effect, but makes me wonder whether there’s a clever mathematical formula that reduces the value of each additional litre of water in a way that’s compatible with your desire.
Should also draw your attention to the IFTTT Macros and to Zapier, in case some chain of goals makes the desired effect possible.
Failing that, for complex translations, I use our webhook callbacks and my own server running a custom dancer script.
Changing the road width is liable to confuse things further.
Thanks for replying, @philip. Like @chelsea, you’ve got a slightly different way of looking at it then me… and that’s good! Without getting too geeky, this solution is probably as close as I’ll get.
But I am geeky! I’m going to explore the API some more to see if I can build something to check that final, elusive checkbox.
who wants to drink more water, enough to support his trek across the desert. 
He’s hip, so he signs up for Beeminder. 
I’m going to explore the API some more to see if I can build something to check that final, elusive checkbox.