Beeminder Forum

What are the technical reasons for the incompatibility between autoratcheting and weekends off?

#1

I realize the simple reason is that auto-ratcheting advances your road to the left, thereby moving the weekend breaks. (Does this also happen for manually-added breaks?)

But why couldn’t the road be moved up instead of to the left? If this currently affects user-scheduled breaks as well as automatic weekend breaks, would this ever be what the user wanted? When I schedule breaks, it’s because I want a break between those specific dates, and even if I retro-ratchet I really don’t want that to change.

What’s going on here?

3 Likes

#2

Yes. Retroratcheting (manual or automatic) does not respect breaks (manual or automatic).

I’m only speculating here, but my guess is that it is these features don’t work correctly together because they are each implemented in the easiest way possible, when considering each in isolation.

Beeminder has no persistent record of a “break”. There is only the road shape data, which is a list of tuples (called “bricks” sometimes). When you use the Take a Break UI, a brick gets inserted into the road. But there’s no metadata recording the fact that this brick corresponds to a break.

When you want to retroratchet, sliding the road to the left usually requires editing fewer bricks than sliding the road up. Although now that I think about it, I’m not sure I actually fully understand the behavior myself. I had typed out an example for you but it was invalid because I was assuming that when presented with a non-monotonic road, the behavior is to set you to the first occurrence of a safety buffer of the requested size. i.e. in this horrible drawing which red circle do you end up sitting at when you retroratchet to 0?

Anyway, I think for normal looking roads you always have to edit fewer bricks to shift left instead of up.

I realize in hindsight that maybe this post isn’t very useful. But I’ve never heard any argument articulated in favor of retroratchet’s current behavior so my assumption is that it is something to do with keeping the code simple.

3 Likes

#3

And for the record I do find it very disappointing that these two premium features, both very desirable and potentially capable of selling me on a premium plan, are completely broken when used together.

2 Likes

#4

Is it too naive to assume that recording breaks as breaks and reapplying them if applicable (e. g.: when start date is now or in the future) after ratcheting would solve the problem?

2 Likes

#5

Intuitively that seems reasonable to me, but I personally find it pretty challenging to reason about these types of things in detail. Beeminder supports a large number of different types of goals (whittle down, weight loss, do less, etc.) and they’re all implemented via very general settings. Aka you have to face the wrath of this table (from http://api.beeminder.com/#attributes-2):

and convince yourself that your proposal works for every possible combination of these settings. :cold_sweat:

To be clear, I have no evidence that you’re wrong. I’m just intimidated by attempting to prove you’re right.

3 Likes