Hey there,
I have a whittledown goal that minds my anki cards left using the anki beeminder addon.
Problem is, if I never open anki that day, the number stays at 0! Is there any way to do some sort of pessimistic presumptive report that assumes I have new anki cards unless I specifically submit 0?
On the assumption that we don’t support PPR on whittle-down goals, because odometers are tricky, here’s an idea…
Schedule IFTTT to add a datapoint every morning, so that you start the day in the red. When you sync with Anki, the lowest of your day’s datapoints will be the one that counts.
I’ve thought about this very problem. My own anki goals are manual since the addon doesn’t support my usage and I haven’t gotten around to automating it myself. But what would be ideal is if we could submit datapoints for the future that do not derail the goal until that day is reached - since anki knows how many reviews are due in the future. An addon could submit projected due numbers for some number of days, and then some extreme clearly-derail number after that.
I recently added some fine print that says (in part) that if I forget to submit an amount, I need to retroactively submit the number from before reviews when I do remember.
ETA: my anki goals are odometer type, so this isn’t a whittle-down specific thing. They’re just special odometers that can go backwards when I don’t do my reviews…
Bumping an old topic (I was originally going to add this to a post here: An experiment to beemind “keeping on top of grading” but didn’t want to derail the thread, and it’s more appropriate here anyway.)
@dreev The interface says that pessimistic presumptives don’t make sense for whittle down goals, but maybe having it so that it’s just creating a point that is above the limit every day would keep us from sticking our heads in the sand? It doesn’t make sense for it to be turned on by default, but do you think it makes sense for it to be available to turn on? There are at least a couple of us using IFTTT or Zapier like the above example(s) to achieve the same thing (and that’s pretty easy to set up, but they don’t self-destruct, which could be neat).
They’d need to be entered at the turnover time for the next day, though. (I.e., instead of adding a PP datapoint for the day that’s just passed, adding it for the day that’s just started, so that there’s plenty of time to notice it and enter a real datapoint, and so that the goal with the unentered datapoint appears higher in our list of goals). I actually like that idea for all PPs, but I suspect there are reasons why thats not how it already is.
The code is actually only looking at the datapoint comment to determine if it’s a PPR that should self-destruct. So if you’re using IFTTT/Zapier-generated PPRs and use that same comment (“PESSIMISTIC PRESUMPTION (autodestructs with new data)”) then they should self-destruct the same way the built-in ones do!
Definitely let me know if that seems to be false!
That’s amazing! I have a different weird integration where I use min to override a manual PPR. Can’t wait to fix it.
I just tried this for something where I’m posting predicted future values to the API for coming week, and when I post a second time the first batch still exists - what exactly is supposed to make these disappear?
For my actual purpose, I should probably be using requestid instead, but if this had worked it would’ve let me avoid thinking through the details of two different things that have their own configurable day turnover times.
This doesn’t work for whittle down (and other non-do-less) goals, or for do-less goals that don’t already have the Pessimistic Presumption option turned on. (All of which is the intended behaviour, I expect!)
It is working on a do less goal of mine that does not get PPRs–but it is an API data source so maybe that’s different?