Test the new autodialer

Akrasia
101

Yes, I have tried those as well, but the problem is my average changes even when the amount per day I do doesn’t change.

If I do 60 units/day, on day 1, my average is about 60/30 = 0.5, then on day 2 my average is 120/30 = 4, on day day my average is 180/30 = 6. So If I use #autodialAdd = 60 for example, it would be 60.5 on day 1, 64 on day 2, 66 on day 3 etc, which is a a pretty sharp increase. Also, these numbers aren’t perfect because the autodialer is also only applying a fraction of the rate or something based on the goal age divided by 30 days.

And with autodialTimes, because of the goal age < 30 days, it’s even less clear what number it’ll spit out. Observe:

image

With an autodialTimes of 4, the goal rate will go from 60 to 65.73, I guess because 20.43 * 4 = 81, and that multiplied by whatever rule governs less than 30 day goals goes to 65.73

I just find the behavior for < 30 days pretty unintuitive, whereas for >= 30 days it acts how I would expect.

It seems in both cases, for goals less than 30 days my goal rate will jump pretty wildly. There’s no way, for example, for me to just increase 60 → 61 → 62 day by day, or go up by 1% per day, like 60 → 60.6 → 61.2, whereas for goals that are 30 days old or more, I could do either one of those by using autodialTimes or autodialAdd.

1 Like
102

Right. So basically, for goals younger than 30 days, the formula is roughly:

raw_new_rate = avg_rate * autodial_times + autodial_add
raw_delta = raw_new_rate - old_rate
adjusted_delta = raw_delta * (age_in_days / 30)
adjusted_new_rate = old_rate + adjusted_delta

And the min is taken of that and autodialMax.

How would you prefer this worked for goals younger than 30 days?

103

Oh that sounds promising. Can you set the month of slope prior to the start date of the goal? Where do you set the slope?

104

I agree with this take in general – 30 day ramp is slow if using autodialTimes. There are triagey ways around it (e.g. temporarily using autodialAdd or temporarily using a high multiplier) but then they need to be adjusted later, which slightly reduces the value of using an autodialer (at least for new goals) because it’s not fully automated.

And gradually ramping into new goals is one of the primary use cases for the feature.

Personally I usually do an autodialAdd for the first 2-4 weeks and then switch to times later, which doesn’t bother me but it does take some practice to choose the right values and is somewhat suboptimal.

I like that the default is slow, but could be nice to be able to configure the ramp time to like 7 days or 14 days or something but not sure how difficult that would be under the covers.

1 Like
105

Making the ramp period configurable sounds like a very elegant solution if that would solve the issue.

1 Like
106

It’s on the ‘stop/pause’ tab, disguised as ‘take a break’.

That setting lets you set any slope for a future period of time. Although it’s most often used to create a flat section, I often use it to set a slope before returning control to the autodialer.

This not about giving the autodialer prehistory, this sets the slope of a future segment of the bright red line. So you can preconfigure a reasonable ramp up for the first 38 days of a new goal, and rely on the autodialer kick in after it’s got 30 days of history.

Why 38? I think that’s right. You want 30 days of history for the autodialler, and it has to set a slope after the akrasia horizon, which it conservatively treats as 8 days, so 30 + 8.

Incidentally, you can upload historical datapoints to a goal, but be prepared for it to get confused and trigger a derailment.

1 Like