Feature Announcement: Tare Tags

As promised, tare tags are live! And the old “odometer reset feature” is dead, thoroughly subsumed by the new tare tags.

Background

Besides knowing that taring (aka zeroing) is what you do to a scale when you want to weigh stuff not already on the scale, you need to know that Beeminder really likes cumulative graphs. See the classic post from Grayson Bray Morris explaining why, for Beeminder goals, cumulative graphs are Good and Correct. (Very briefly: it’s how we allow you to accumulate safety buffer, getting ahead of the bare minimum you committed to maintain as an overall average.) But the important thing for now is that Beeminder graphs are cumulative whether or not you enter cumulative data. Let us explain.

Most Beeminder graphs, like standard do-more or do-less graphs, don’t expect cumulative data. These graphs are auto-summing. That means you enter the additional amount (“the delta”) that you did each day and the cumulative total is plotted on the y-axis for you. [1] Odometer-style graphs do not auto-sum. Whatever value you enter is directly plotted on the y-axis.

(Ignore weight-loss and weight-gain goals for now. They’re neither auto-summing nor cumulative, exactly, but also they’re not relevant to taring. Not yet anyway. We’re intrigued by a use case where you tare your weight after getting dressed so you can log your true weight throughout the day without actually getting naked for each weigh-in. But it’s weird and messy — with the numbers and the taring algorithm, not the nakedness — so we’re not officially supporting that yet. If you really want to experiment, you’ll need to change your weight-loss goal to use aggday “last” instead of aggday “min”. Beeminder experts only!)

So usually you want auto-summing. Like if you ate 3 vegetables today, you enter a +3 on your veggies goal. Easy peas-y. But sometimes the convenient number to report is the new total. Maybe you’ve read 7 pages today but to figure that out you’d need to subtract the page number you started at from the current page number. Easier to just tell Beeminder your current page number! Especially since — if you started on page 1 (more on this shortly) — the current page number is your total number of pages read, exactly what’s plotted on the y-axis.

Quick version if you don’t want to learn any (more) new things

It used to be that a zero datapoint on an odometer goal would be treated as a reset of the odometer. Maybe you were beeminding numbers from a literal odometer and it literally got reset. Like you tracked your miles driven and your car died at 123,456 miles. If you want to keep tracking your cumulative miles (let’s pretend you got a brand new car with 0 miles on the odometer) then it would be pretty annoying to have to add 123,456 to the reading on the new car every time you reported the number to Beeminder.

Instead, Beeminder would presume that any zero datapoint was an accidental odometer reset and magically add the previous total to all new datapoints from then on. It was very handy for a lot of things, like beeminding total pages read by reporting the page number. Starting a new book is like getting a new car with zero on the odometer.

But it was also a gross violation of the Anti-Magic Principle, as we talk about in the second half of our recent post about magic strings. I may have mentioned punching my past self in the face.

So now everything is exactly the same except that if you want that to happen, you have to explicitly tag the datapoint with “#TARE” in the comment. See our previous blog post about magic strings in datapoint comments for background on how that works in general.

Ok, this concludes the quick version. You used to implicitly get an odometer reset with a zero datapoint. Now you explicitly get it by tagging the zero datapoint with “#TARE”.

Also we took the liberty of converting all your existing data. Zeros on odometer graphs now have the tare tag appended. (We used the @TARE version instead of the #TARE version, for reasons explained in the previous blog post.) Expect an email about this shortly if it applied to you. [Now sent.]

The wonderful generality (and explicitness)

What’s really new is that you can tare any datapoint. Maybe the shiny new car you bought was test-driven by some grubby grubkins and you only start driving it when the odometer already says “7”. Gasp. Here’s how you’d enter the datapoints (the carets are Beeminder’s shorthand for “today”):

• ^ 123456 “RIP my old car” [123456]
• ^ 7 “New car acquired with 7 on the odometer #TARE” [123456]
• ^ 107 “Inaugural 100-mile road trip” [123556]
• ^ 999 “About to hit 4 digits on the odometer but 8 more miles till I’ve driven this car 1000 miles” [124448]

In brackets we’ve put the actual values plotted on the y-axis of the graph. Notice how the 7 miles that were already on the new car are never added to the running total — which is just miles you’ve driven — thanks to taring the graph. But all that you, as the user, ever have to worry about is reporting the actual odometer reading.

As a simpler example, maybe you want to beemind your way through a book but skip the boring introduction. Say chapter 1 starts on page 30. When you enter a “30”, that should mean you’ve actually read just the first page of the meat of the book. You can now enter data like this:

• ^ 29 “Skipping the first 29 pages before chapter 1. #TARE” [0]
• ^ 30 “Finished page 30, ie, the first page of chapter 1” [1]

Here’s a more convoluted example if you want to really make sure you’ve got your head around it:

“We’re relieved that you now have to be less of a supergenius to make Beeminder behave as you want it to”

The general algorithm (feel free to skip this if you’ve got the idea already): Until there’s a taring, the y-values plotted on the graph match the entered datapoints. Now say a datapoint with value v is marked as a tare and let u be the previous y-value (or 0 if this is the first datapoint) before v was entered. Then the actual value of v is disregarded (but remembered). The plotted value corresponding to v is still u and subsequent datapoints are measured as the delta from v and added to u. When that happens more than once, those deltas just accumulate.

(Fun fact: All of this was technically possible with the old odometer reset feature but it involved outrageously clever / excruciating abuse of the feature. Credit to Scarabaea for the ingenuity there. We’re relieved that you now have to be less of a supergenius to make Beeminder behave as you want it to.)

Whittle-Down use case

We don’t know if this one’s a good idea yet, but… As an alternative to the schemes we’ve blogged about for backlog-minding, you could beemind something like your inbox with a whittle-down goal, but every so often, maybe even at the end of every weekend, you just tare the graph at whatever value it ballooned up to.

In this scenario you are still beeminding the size of your inbox, entering the current size and always trying to make that number go down. But you’re kind of giving yourself a free reprieve periodically. Your inbox size can jump up but the plotted y-values will keep going down. Possibly into negative numbers.

Like we said, it could be a bad idea. It seems to violate the Quantified Self First principle. And unless you have a principled rule for when it’s ok tare your inbox at a higher value, that could be too much of a loophole. (Or maybe it’s an ice cream truck loophole and it’s fine?)

Probably you should mostly think of tare tags as applying to graphs that go up. Book reading, bike riding, word writing, Anki reviewing. Those sorts of things. We assume someone will do something wildly creative with this though.

Oh my goodness the sheer number of things this fixes

Here’s a dumb one: Sometimes users would create an odometer goal, which would naturally have an initial datapoint of zero. That would technically yield an odometer reset — what we now call a taring — but when you do that to the first datapoint, it’s a no-op. Fine. Then maybe the user would add a datapoint of 10 for today, in addition to the initial zero. Still fine. But then maybe they’d backfill a datapoint for yesterday of 5. Do you see the problem? The person doing this probably didn’t. The 5 yesterday, followed by a tared zero today, would mean that today’s 10 is now added to yesterday’s 5. So the graph would plot 15 today instead of the expected 10.

That one at least is fairly corner-casey.

How about this disaster that happened to my own URLminder goal, for automatically fetching wordcounts of documents and beeminding my total words written:

What is going on there? Well, the documents I’m pointing to sometimes fail to load when Beeminder requests them, which means Beeminder sometimes fetches a zero datapoint. Now you see the problem. All those zeros got processed as odometer resets, so each subsequent non-zero fetch got added cumulatively to the previous total. (Btw, tarings are indicated visually on the graph with faint vertical dotted lines, same as odometer resets were.) This is especially tragic because it just silently inflated my total wordcount higher and higher until I had infinite safety buffer and the graph was buried at the bottom of my dashboard, out of sight, out of mind.

All these problems are now mercifully a thing of the past.

You could say we’re zeroing them out and making a fresh start. #TARE

 

Footnotes

[1] We sometimes, like in the API, call auto-summing graphs kyoom graphs, or kyoom=true. It’s phonetic for “cumulative”.