Different off-by-one error with akrasia horizon

[dreeves]

Desiderata

Beta Give feedback

1. Does this want merged with Can't extend flat spot past the akrasia horizon #232?
2. Replicata that actually replicate the bug
3. Decide if Mary's report is the same issue
4. Fix the bug
5. Tweet the UVI

LANTHALA (2021-11-12): Is this a bug? https://www.beeminder.com/lanthala/dailytask -- I created a new goal with 7 days' buffer, then realized I wanted to change the future slope, but when I updated it, it updated starting one day after the initial flat spot (the day after the akrasia horizon line). So now I have one day of the original slope followed by the new slope. I expected it to update right at the 7-day point, what with there being a giant dashed line there.

(Non-)Replicata

1. Create a new do-more goal
2. Give it a rate of 1 whatever per day (this doesn't actually matter)
3. Give it 7 days' initial buffer
4. See the graph created like so:

5. Dial it to 0.5 whatevers per day

Expectata

That the slope of the red line changes right at the akrasia horizon.

Resultata

Um, that's exactly what I get when I do the above steps so unclear what Lanthala was smoking there. Obvious answer would be that in between steps 4 and 5 the deadline passed. But maybe there's a bug where Beeminder gets confused about calendar days vs Beeminder days somehow and this off-by-one problem can happen even if you dial the slope immediately?

MARY (2022-01-06): I think the akrasia horizon is in the wrong place, either by restricting too much of what we're allowed to change or by being drawn in the wrong place on the graph. One or the other cuz they don't match.

This graph shows the big jump in the red line coming after the akrasia horizon, but the graph matrix row that makes that jump start is not editable and pops up the error that it can't be made easier inside the akrasia horizon:

Cognata

• https://github.com/beeminder/beeminder/issues/2747 (dup from beebody, moved here)
• https://github.com/beeminder/beeminder/issues/1838
• 65c8bd4
• https://changelog.beeminder.com/#3785 (UVI from above gissue and commit)
• Can't extend flat spot past the akrasia horizon #232

Verbata: akrasia horizon, off-by-one, graph aesthetics, user confusion,

[dreeves]

New report:
https://forum.beeminder.com/t/argument-the-akrasia-horizon-line-should-be-7-days-out-instead-of-6-days-out-on-the-graph/11506

[emerald-pham]

Replicata

This seems fine.

Expectata

I think this is where the issue stems from.

Let me go back to basics to see if there’s some assumptions users and devs are not on the same page on creating confusion here that might pin down a better Replicata Expectata and Resultata trio.

Assumption A - When a graph is created with the above replicata, the space between two vertical tick markers on the y-axis is about twenty four hours. All following assumptions will be based upon using the above replicata with default settings.

Assumption B - The horizontal position of each vertical markers on the x-axis represents the (Unix time second?) between one (approximately) 24 hour period of time and another (about) 24 hour period of time.

Assumption C - With above replicata, the timestamp represented by the vertical tick markers delineates, in this circumstance, sometime around midnight at one of the points of time, perhaps seconds, between one day’s period and another day’s period in timekeeping for this goal which would spawn with a default deadline of midnight.

Assumption C.1 - The graph origin point (not the initial datapoint) has a x-axis position representing its time at the midnight before the goal was created, and a y-axis position of 0.

Assumption D - The Akrasia horizon represents the point in time, in this circumstance, where the slope of the red line changes when inputting changes in slope to the red line.

Assumption E - The Akrasia horizon is + 7 days from the graph origin point, represented by the 7th vertical tick marker on the x-axis representing time.

Assumption F - Changes in the rate of change of the slope of the graph occur on the 7th vertical tick marker on the x-axis representing time.

Most importantly,

Assumption G - The dotted line representing the Akrasia horizon represents a boundary of time where, before, you cannot make any changes to the rate of change of the graph, and after, you are able to make changes to the rate of change of the graph.

Assumption H - Before the point in time plotted on the graph representing the Akrasia Horizon, we are unable to make changes to the rate of change of the graph, and after the point in time on the graph plotted representing the Akrasia horizon, we should BEGIN to see changes we make to the rate of change of the graph begin to occur.

Therefore, the vertical blue dotted Akrasia line should be plotted on the seventh vertical x-axis tick marker.

Resultata

The point of inflection for the rate of change on the graph correctly plots at the 7th x-axis vertical tick marker representing 7 days from the origin point, but the Akrasia horizon plots at the 6th vertical x-axis tick marker. This is wrong because the period of time between the 6th and the 7th vertical x-axis tick marker is a period of time that we CANNOT adjust the rate of change of the red line, and therefore should not fall AFTER where the Akrasia horizon is plotted.

[dreeves]

Replication from Tiffanie:

I first observed this issue when I set my rate to 0 then entered a week's worth of data at once, the flat spot wouldn't "kick in" unless I entered 8 days of data. I had some once-a-week goals, wanted a break, set my rate to 0 from the goal's page on the day it was due, entered my day's data of +1, and was still "on the hook" for the following week's entry, but if I changed my data entry to 1.15, the 0 would "kick in." The behavior was the same regardless of the goal's color.
Goal page > commitment page > rate to 0 > commit > data entry of 7 days of data > observe top thingy saying "+1 due in 7 days xx hours" > add 0.15 to make data entry equal to 8 days of data > observe top thingy saying "+1 due in xx years."

I also ran into this issue on Monday in the graph editor when I tried to make my slope easier starting next Monday and it wouldn't let me, saying you can't make it easier within the akrasia horizon. This week is not the first time I've run into this, and behavior is also the same regardless of the goal's color.
graph.beeminder.com > select goal > graph editor tab > red line tab > add a line scheduled for 8th day out (e.g., today is the 24th, so scheduling it for the 1st) > change slope after the newly entered line to a lower rate > (possible related bug: at this point, if I'm not allowed to make the change, I expect the graph to yell at me, but for this 8th day bug, it only does small error text AFTER I click submit) > click submit > observe unchanged graph and red text next to submit button saying you cannot make it easier within the akrasia horizon.