Probably this is naive, but one idea for odometer goals: autodial in terms of “change since yesterday”.
1 Like
It’s not totally clear to me what “properly handles weekends off” (or breaks) means.
A priori, “properly handl[ing] weekends off” would mean that weekend days (and break days) would be excluded from the 30 day average - so that the goal would not get easier. @narthur said above that taking breaks does allow your goal to get easier. If I understand correctly, that means break days are not counted in the 30 day average. Are weekend days?
My vote is that neither should be counted - taking a break should not lead your goal to get easier. For me, weekend days and break days are an entirely separate regime from my typical workday, at least for the purpose of some goals (like my pomodoros-per-day goal). I wouldn’t want anything I do during my weekend or my break to affect what is expected of me during normal life.
2 Likes
Quick note: You are correct, weekends off are excluded from the average calculation, while manual breaks are not.
1 Like
Also, off the top of my head, this sounds like it relates to Beeminder’s current lack of true breaks, especially since true breaks could be handled by the autodialer the same for both do-more and do-less goals.
1 Like
I was relying on the theory described a few times here, that if I don’t derail, and do more than the minimum, then autodialer will slowly creep up over time.
But the slope of my exercise goal wasn’t really going up over time. I knew I’d derailed a few times, but was that all that was going on? Then I noticed a ton of oscillation in the rates (due to data entering and leaving the sliding 30-day window, I assumed) and decided it was time for further analysis…
So I wrote an autodialer simulator and confirmed that, without autodialTimes, rates creep up really slowly. This is what the rate looks like if I start with a 7min/day goal and run 30 minutes every time there’s a Beemergency, and never derail:
So… This is clearly not a great way to ramp up a goal—or at least, I’m pretty sure I can ramp up faster than that. 
It looks better if I enable strict mode:
But unfortunately, I do want the rate to go down if I derail. So this is what it looks like if, instead of making the autodialer strict, I set autodialTimes to 1.1:
Or 1.2:
(It reaches the max of 30min/day at the start of June, which is why it flatlines.)
Hope this helps!
5 Likes
Wow, fantastic analysis! Can you share more details about how you generated the data?
Also would be interested in what your simulator would say about my personal strategy of using auto ratcheting to lock in rate bumps.
I haven’t figured out how to publish an interactive version, and it doesn’t support auto-ratchet, but the notebook I used is here. Do you know how to work with that, or would I need to make the upgrades for you to have your answer?
3 Likes
huh thanks! I’ll have to take a look
Okay, I added auto-ratchet support to the simulator notebook.
Can you be a little more precise about your auto-ratchet strategy, though? I picked two scenarios that I thought might help…
Here’s what happens if you enable auto-ratchet with a 0/day goal and do 1/day every day:
Compare to what happens if you also set auto-ratchet to 3:
So no difference, as you might expect, since autodial always underestimates and you’re perfectly consistent.
Then there’s my exercise scenario where I run for 30 minutes every time there’s a beemergency, with the goal starting at 7min/day:
Setting auto-ratchet to 2 does make a difference:
And it’s a stronger effect with auto-ratchet set to 1:
Do these answer your question?
2 Likes
Very interesting!
For comparison, here are some of my graphs where I autodial and also autoratchet down to 7 days buffer:
Load of screenshots
2 Likes
