Beeminder Forum

Test the new autodialer

With help from @dreev and @mary, I’ve built a new autodialer site here:

Anyone game to give it a go and tell me if you run into any bugs or issues?

Thanks!

7 Likes

Autodialer now properly handles weekends off!

2 Likes

What is the effect, exactly? If you consistently do more than the minimum, your slope will increase up to a maximum. If you edge-skate, does the slope trend a minimum, over a 30-day period?

What kind of goals do people use this on?

I think I’ll give it a try on a reading goal, with a book that’s a bit of a slog to get through, at times.

2 Likes

Great! I’m super interested to hear your thoughts on the tool.

Unless you manually increase the rate, add breaks, or derail, your rate should continue to increase (or at minimum stay the same), since Beeminder will require you maintain the same average. If you do derail or add a break, and your data entry decreases in turn, then the autodialer will start reducing your rate.

3 Likes

To be clear, my explanation of how it works in relation to buffer is how I think it’s going to play out. The tool is so new that I don’t yet have enough experience with it to know if that’s actually 100% correct.

Will the autodialer respect breaks? My intuition was that it would just change the rate beyond the akrasia horizon to a single straight line, and that I would have to switch it off to get a break in.

The tool doesn’t seem to support negative rates? Or am I missing something?

No, it won’t overwrite breaks! It only changes the rate for the last segment of your road. If that segment also intersects the akrasia horizon, then it also breaks that segment to avoid modifying within the horizon. But it shouldn’t ever otherwise modify the rest of the road.

We built it intending it to work for both negative and positive rates. Is there something I’m missing in that code that makes you think it wouldn’t work for negative rates?

Thanks!

2 Likes

Because those regexes don’t match negative numbers?

Initially I tried to set a negative rate, with
#autodialMin=-14 and #autodialMax=-5. Then I thought the dialer might be smart enough to know the goal has a negative slope and you only had to enter absolute values. Then I didn’t know if I’d have to flip min and max in that case. Anyway, I didn’t get it to work.

What should I enter in the fine print for a range like [-14,-5]?

3 Likes

You’re absolutely right! This is a bug. I’ll need to fix the code to accept negative values for those options. (Or you can submit a PR!)

1 Like

Ah, that’s cool! I feel like this is going to be useful for goals where I know I want to keep doing something but I don’t really know what rate is sensible. I can just start going and see where the autodialer sends me, and stick a break in if I feel my initial enthusiasm has got a bit out of hand.

4 Likes

@ianminds Thanks for the PR, just merged it! Wonder if you’d be up to test it out when you get a chance to make sure we got it?

This doesn’t seem to work for me - when I click the “Enable Autodialer” button and give it access to my Beeminder it just goes to a white screen, and whenever I go back to the page that button plays a sort of loading animation for a few seconds before going back to a white screen. The “Force Run” button does nothing.

Any idea what could be going wrong?

1 Like

Oh, weird! When you get to the white screen do you think you could open up the console and send me any errors you find? For Chrome on a Mac, you do that by pressing Cmd+Opt+i

I’ve copied and pasted everything I found:

TypeError: t.rate is null
ee goalRow.tsx:30
React 7
unstable_runWithPriority scheduler.production.min.js:18
React 4
flush notifyManager.js:70
promise callbackk utils.js:322
flush notifyManager.js:69
batch notifyManager.js:26
dispatch query.js:390
setData query.js:83
onSuccess query.js:334
d retryer.js:58
promise callback
c retryer.js:116
l retryer.js:156
fetch query.js:330
executeFetch queryObserver.js:199
onSubscribe queryObserver.js:40
subscribe subscribable.js:16
f useBaseQuery.js:60
Fu React
unstable_runWithPriority scheduler.production.min.js:18
React 3
L scheduler.production.min.js:16
onmessage scheduler.production.min.js:12
EventHandlerNonNull* scheduler.production.min.js:12
a (index):1
index.js:4
a (index):1
React
a (index):1
React
a (index):1
141 main.ab11b7a1.chunk.js:1
a (index):1
r (index):1
t (index):1
main.ab11b7a1.chunk.js:1
react-dom.production.min.js:216:199

TypeError: t.rate is null
ee goalRow.tsx:30
React 7
unstable_runWithPriority scheduler.production.min.js:18
React 4
flush notifyManager.js:70
promise callbackk utils.js:322
flush notifyManager.js:69
batch notifyManager.js:26
dispatch query.js:390
setData query.js:83
onSuccess query.js:334
d retryer.js:58
promise callback
c retryer.js:116
l retryer.js:156
fetch query.js:330
executeFetch queryObserver.js:199
onSubscribe queryObserver.js:40
subscribe subscribable.js:16
f useBaseQuery.js:60
Fu React
unstable_runWithPriority scheduler.production.min.js:18
React 3
L scheduler.production.min.js:16
onmessage scheduler.production.min.js:12
EventHandlerNonNull* scheduler.production.min.js:12
a (index):1
index.js:4
a (index):1
React
a (index):1
React
a (index):1
141 main.ab11b7a1.chunk.js:1
a (index):1
r (index):1
t (index):1
main.ab11b7a1.chunk.js:1
react-dom.production.min.js:216:199

Uncaught TypeError: t.rate is null
ee goalRow.tsx:30
React 7
unstable_runWithPriority scheduler.production.min.js:18
React 4
flush notifyManager.js:70
promise callbackk utils.js:322
flush notifyManager.js:69
batch notifyManager.js:26
dispatch query.js:390
setData query.js:83
onSuccess query.js:334
d retryer.js:58
promise callback
c retryer.js:116
l retryer.js:156
fetch query.js:330
executeFetch queryObserver.js:199
onSubscribe queryObserver.js:40
subscribe subscribable.js:16
f useBaseQuery.js:60
Fu React
unstable_runWithPriority scheduler.production.min.js:18
React 3
L scheduler.production.min.js:16
onmessage scheduler.production.min.js:12
EventHandlerNonNull* scheduler.production.min.js:12
a (index):1
index.js:4
a (index):1
React
a (index):1
React
a (index):1
141 main.ab11b7a1.chunk.js:1
a (index):1
r (index):1
t (index):1
main.ab11b7a1.chunk.js:1

Error: Promised response from onMessage listener went out of scope

Basically there were 3 errors that all seemed to stem from a goal’s rate being null, somehow? Then what looks like a timeout from the previous stuff failing.

Is that enough to nail it down?

1 Like

Thank you, that definitely gave me something to go on! I found a couple bugs that should now be fixed, though I’m not 100% that I’ve actually addressed the particular bug you’re running into. Can you give it another go and see if things are resolved?

(If you’re curious, here’s the PR with the changes I made this morning:)

2 Likes

Seemed to work perfectly! Thanks :smiley:

1 Like

On second glance, it seems like one of my goals wasn’t actually dialled - after running the dialler a couple of times, the current rate of 1.07 hasn’t increased to the 30-day average of 1.67. Possibly something to do with the fact that this is a goal where the rate is defined by a day and end count.

2 Likes

Loving the autodialler @narthur – thanks very much.

Just under half of my many many goals are now configured to autodial, and I think I keep seeing improvements being deployed, based on what gets dialled, by how much, to what rate, etc.

1 Like

I’ve been thinking about this behaviour, and I think it might be exactly as it should be? With my other goals, which are either defined by a rate and a date or a rate and end quantity, it’s obvious how to adjust to account for the new rate. Should autodialling a date+quantity goal change the date or quantity, when those define the red line? I think it differs for each goal, and so they should be left alone until the user makes one of them non-constant. That’s what I ended up doing for the undialled goal, and it was helpful to consider how I wanted to define its end point.
(There’s another case where both the goal and end-quantity are far-enough away as to act as a de facto infinite goal, where it doesn’t really matter which is changed, although I guess keeping the date constant would be better so as not to shift it closer and closer as your rate improves. Until Beeminder has proper infinite goals it’s probably best to still ask the user to make one non-constant.)

2 Likes