@ncyrocks Oh, you’re right… Curious, how did you find the Netlify deploy failure? The cloud functions deployed fine.
@ianminds Just deployed a fix, such that end val + end rate is now supported, and the autodialer will just refuse to dial a goal defined with end date + end val.
Also, rows where you’ve hit your good limit (depending on yaw) are now highlighted in green.
1 Like
@narthur the behaviour of the autodialler on pjh/anki always feels weird, and today I had a thought — the Anki maintained progress add-on injects future datapoints based on its projection of what will happen in the absence of any studying. Are those projections (wrongly) included in the 30-day average?
2 Likes
@narthur By the way, I’ve been meaning to say that I think this is just a case of something being out by one. The autodialer always seems to set the rate based on (sum of datapoints - 1). I think it is just less obvious on goals with more data where the 30 day cut off isn’t as clear.
1 Like
@narthur I just noticed that the fix didn’t seem to be applying and checked the Netlify logs (which I found from a link on GitHub).
Also, I’ve opened a new pull request that allows you to add a constant amount to the 30-day average - don’t know if that’s actually something you wanted to implement, but it’s there if you do. (And I noticed that the green background wasn’t working properly for goals with negative yaw, so I included a fix for that.)
1 Like
Thank you for this!!
I don’t understand the yaw fix. Shouldn’t edge === -1, or rate === min, be the definition for success for a goal with yaw = -1?
I’ll dig into this more tomorrow…
1 Like
@k1rsty Are you sure it’s not just excluding datapoints added on the current day? I know it takes about a full day before any of my data shows up (probably due to timezone shenanigans), which seems like it’d produce a similar issue to the one you’re having.
rate === min should definitely be the definition for success, but that results in edge === 1 since the result is multiplied by yaw before being returned.
1 Like
Oh, duh!! So I tried to account for yaw twice which resulted in both being negated. That makes sense.
1 Like
Looks like you’ve got a build error. I’ll merge once you get it fixed.
https://app.netlify.com/sites/autodial/deploys/6226b2c011e2f20007e52210
1 Like
Stupid trailing whitespace… sorry about that, again. Should be fixed now.
Hmm. I’ve just setup a test goal with the exact same datapoints over the last >30 days as the goal I’m seeing the issue with. And the test goal autodialer says the rate is 1.17/w (7*5/30) but on my real goal it shows as 0.93/w (7*4/30). The differences are that the test goal was set up a few minutes ago (though the autodialer says 4 hours, which probably isn’t important), and has the data added in before the start of it, whereas the real goal started a couple of years back and already had 98 datapoints before this. It’s very odd!
Here are the datapoints from the test goal:
TIMESTAMP,DAYSTAMP,VALUE,COMMENT,ORIGIN,CREATEDAT,DEADLINE 2022-02-11T21:59:59Z,2022-02-11,1.0,"",Beeminder Web,2022-03-08T09:17:37Z,-7200 2022-02-19T21:59:59Z,2022-02-19,1.0,"",web,2022-03-08T09:18:21Z,-7200 2022-02-24T21:59:59Z,2022-02-24,1.0,"",web,2022-03-08T09:18:33Z,-7200 2022-02-25T21:59:59Z,2022-02-25,1.0,"",web,2022-03-08T09:18:42Z,-7200 2022-03-06T21:59:59Z,2022-03-06,1.0,"",web,2022-03-08T09:19:02Z,-7200 2021-12-25T21:59:59Z,2021-12-25,1.0,"",web,2022-03-08T09:27:04Z,-7200
I haven’t duplicated the exact timestamps from the original goal though, these are the last six lines of the CSV datapoints of the original goal, with just the comments redacted.I can’t see any reason it would find only four datapoints here?
2021-12-25T15:03:35Z,2021-12-25,1.0,"",ifttt,2021-12-25T15:03:35Z,-7200 2022-02-11T19:43:26Z,2022-02-11,1.0,"",ifttt,2022-02-11T19:43:26Z,-7200 2022-02-19T11:44:10Z,2022-02-19,1.0,"",ifttt,2022-02-19T11:44:10Z,-7200 2022-02-24T17:38:33Z,2022-02-24,1.0,"",ifttt,2022-02-24T17:38:33Z,-7200 2022-02-25T18:23:51Z,2022-02-25,1.0,"",ifttt,2022-02-25T18:23:51Z,-7200 2022-03-06T14:28:48Z,2022-03-06,1.0,"",ifttt,2022-03-06T14:28:48Z,-7200
Separate issue: I’ve just noticed that an odometer based goal, with odometer resets allowed, has just flipped into a negative slope after I’ve reset the odometer. I guess the autodialer just can’t deal with that, but it’s not listed in the limitations.
2 Likes
I’ve used the autodialer for the past month and I think it works really great for my goals.
I have one feature request: I would like to set a percentage that would be used to calculate the new commitment instead of it always being 100% of the past 30 day average.
Example:
For my steps goal it would be useful to not have to live up to the full average of the last 30 days, but maybe only 90%. 100% means that it will forever move up since I will likely not hit the average exactly every single day and if I go under I will fail the goal.
It will also allow me to autodial the value lower over time.
2 Likes
Although that matches my intuition too, certainly on my steps goal it’s been ok. Possibly because I’ve got a hefty amount of safety buffer.
It seems worth noting that the autodialler only changes the final graph segment, so you can use the take-a-break feature to inject a week at 50% every now and again.
The other features that might be helpful is to set #autodialMax or use #autodialAdd to subtract (ironic!) about 10% of your daily average steps
1 Like
Oof, I thought this was what autodialer was for! No wonder those goals hadn’t been getting incrementally harder. I guess I had just assumed it was auto-dialing…up?
1 Like
You’ve got several options ensure you get the trend you want:
- Use auto ratcheting to automatically trim your safety buffer (this is what I do).
- Set #autodialStrict to prevent the dialer from ever making your goal easier.
- Use #autodialAdd to force the dialer to add a fixed amount to your average when calculating your new rate.
3 Likes
So long as you don’t derail or take breaks or use up your safety buffer, they actually will get incrementally harder, just very very slowly if you’re doing the minimum.
In other news: I just added a forever-flat goal to the autodialer, with max and min both set to zero. Why? Because it’s nice to see the 30 day average, which doesn’t feature in the official statistics tab. Easy UVI @dreev?
Update: apparently I’ve been beeminding my weight for ten years (which is also more clearly called out on the autodialer than in the stats) and in that time I’ve gained 1.6kg (3.5lb, 1.5%) which on the one hand is pretty good going and on the other hand masks the wild fluctuations over a 15kg (33lb, 14%) range.
3 Likes
So long as you don’t derail or take breaks or use up your safety buffer, they actually will get incrementally harder, just very very slowly if you’re doing the minimum.
Yeah, I do all three of these things on almost every goal! That’s the problem. However, I price that in and still want the baseline expectation to be slowly increasing for, say, my mindful minutes goal.
2 Likes
The autodialer now explicitly rejects dialing odometer goals, and this is listed as a limitation.
Also, if anyone wants to think through how the autodialer could work with odometer goals, I’d be interested to hear your ideas!
3 Likes