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
I was looking for the latest Autodialer thread, and I think maybe this is it (at least according to the search?)…
Anyway, I really like the Autodialler! One of the things it does is create an awful lot of rows in your goal matrix, though - one for each day it dials. This can take a loooong time to load for old goals (I’m not sure if it’s the matrix or the graph with lots of vertices in the goal line that causes this, tbh).
Anyway, I wondered in @narthur might add another parameter, something like “#mindelta”, such that if the dialer calculated a new value that wasn’t at least #mindelta away from the current value, it didn’t make any change?
As an example, in a step-count goal, #mindelta=100 would just mean that it didn’t bother updating the slope unless the new slope that it calculated was at least 100 steps per day different from the existing one.
(Of course it’s updating against the 30-day average, so the calculation for that will need to account for the number of days that the rate was left at a previous value because delta<mindelta, but it very likely is doing that anyway, rather than just averaging the last 30 rows in the goal matrix)
3 Likes
I feel conflicted with this one. Under the hood I believe the autodialer already does something like this, though with a very small delta. I hesitate to expose this as a setting because it feels like putting a bandaid on an issue that needs to be fixed on Beeminder’s end if tools like the autodialer are to be reliable tools over long periods of time.
3 Likes
Does the autodial make sense for new goals? I created a goal to log 60 units per day, and I wanted to gradually increase it, but since the goal is only 5 days old, the average rate it tries to set my goal to is around 15 units/day. Using autodialAdd or autodialTimes doesn’t make too much sense, because the average is going to climb rapidly if I do 60 units/day of work, so I would have to adjust those numbers almost daily to make sure it doesn’t set the rate to something really high
For goals that are 30+ days old, I can do an autodialTimes=1.005 or something like that and gradually creep the goal up, but for goals less than 30 days, not sure if autodialer can help
1 Like
Yes! The autodialer gradually scales up the adjustments it makes over the first 30 days of a new goal’s life. So you should be set.
Ah, but for the first 30 days, it seems that all of the adjustments will make the goal easier. Since there are so many zeros, if I let autodialer run, it’ll adjust my goal to 15 units/day. If I wait the full 30 days, then finally the average will be at least 60, so at least the goal will start to get harder, wondering if there’s any kind of automation so that I can start making the goal harder even before the 30 days have passed.
1 Like
There is! Set #autodialStrict and it will prevent the autodialer from ever making your goal easier.
Right, that’s what I’ve been doing, but there’s no way to make the goal incrementally harder for the first 30 days. I can make the floor of the goal at 60 units, but it’ll remain at 60 units/day for basically the entire first month, because I can’t push the average above 60 since there are so many zeros. Basically what I’m asking is if there’s a way to make the goal incrementally harder in some kind of automated fashion even before the 30 days are up, because the average is essentially artificially low because there are so many zeros
1 Like
For sure. You can use #autodialAdd or #autodialTimes to modify the average that the autodialer sees. The autodialer will still remain cautious during those first 30 days, but you could compensate that way. You could combine that with #autodialMax to ensure it doesn’t make your goal too hard.
Not automated, but worth knowing that the Autodialer only changes the slope after any upcoming break, so you can manually set the first month of slope(s) so that it’s got 30 days of data to work with when it kicks in.
1 Like