Beeminder and floating point numbers

Tech
1

I have long assumed that beeminder is internally using 64-bit floating point numbers for fractional data, and that this is not something that would cause me any problems (though I hadn’t thought about it very hard).

However, I was doing some road calculations recently and realized that there’s probably a subtle correction that happens somewhere, and now I’m curious what it is so that my road calculations can match whatever beeminder is doing.

So in particular I have a goal that is calibrated so I do 5 items per week, i.e 5/7 items per day.

The roadall value is as follows:

      [[1747670400,
        0,
        0],
       [1747670400,
        0,
        0],
       [1747670400,
        1,
        0],
       [1748793600,
        10.285714285714286,
        0.7142857142857143],
       [1748793600,
        11,
        0],
       [1753545600,
        50.28571428571429,
        0.7142857142857143],
       [1754150400,
        50.28571428571429,
        0],
       [4102419600,
        19463.857142857145,
        0.7142857142857143]]

The interesting bit is the last two entries, where we have a flat section with a value of 50.28571428571429, and then we continue with the normal slope of 0.7142857142857143. If we add these values together (to get the cumulative amount due on the first day after the break) with standard floating-point arithmetic, we get 51.00000000000001.

I realize now that I’m actually not 100% sure that beeminder won’t require an extra item on that day, but I wasn’t expecting that to happen. Assuming that’s not what happens, what logic is beeminder using internally to avoid that outcome?

4 Likes
2

Yeah, see this older thread:

Beeminder sometimes does indeed end up requiring an extra item because of floating point issues. That’s not great, but at worst you can contact support to fix up your goal for you. In cases where it truly is the fault of a bug in Beeminder, this or any other, they absolutely will fix it manually for you.

(Also, if you’re willing to get more technical: as a cludgy workaround for this sort of floating point issue, the API, when checking that you’re not making your road easier, does so only to within a tolerance of 10^{-9}. You can take advantage of this hidden undocumented workaround to update your goal’s graph via the API to jump downwards on that day (from 51.00000000000001 to 51, which is a floating-point difference of approximately ~7.1 \cdot 10^{-15}, well below 10^{-9}), and thus fix it yourself. I think that would work also via the visual graph editor.

For many or most users just contacting support to manually fix it is probably easier, but given that this long-standing issue is unlikely to be truly fixed any time soon, it may be worth knowing that you can work around it with the small amount of leniency the API gives you.)

4 Likes
3

I decided to wait around until the flat portion ended, and got a surprising result – I can’t actually tell whether beeminder will require an extra item because I get contradictory indications:

1000012122
10000121221080×908 123 KB

(I realize this might be judged low-priority, which is fine, just figured it was worth highlighting)

1 Like