Bright Red Staircase and Continuous Beeminding

[dreeves]

Desiderata

Preview Give feedback

1. Draw the bright red line as a staircase, just visually
2. TBD

(by @saranli and @dreeves)

Currently, the red line is represented as a possibly discontinuous piecewise linear function. Beeminder's internal representation is in the form of a graph matrix aka road matrix, that is encoded as an n-by-3 matrix, rows of which correspond to changes in slope. Each row has the following format:

[ time[k], value[k], slope[k] ]

with the following constraints imposed:

• redline(time[k])=value[k]
• (( d/dtime (redline(time)))(t) = slope) for time[k-1] <= t < time[k]

In order to prevent conflicts between these two constraints for successive segments, only two of these row elements are recorded internally and the third one is computed accordingly. Discontinuities in the redline function are encoded as two or more successive rows with the same "time" but different values.

The current state of graph generation considers the above "redline" to depict the actual deadline for goals, giving the impression that if the extension of the latest datapoint with the "ppr" slope (0 for domore goals, slope dependent for doless goals) crosses the redline, "derailment" occurs and the user is charged. This does not, however, correspond to actual reality since derailment is only considered by the Beeminder backend (Beebody) when either a new datapoint is added, or when an official "deadline" time within that day (allowed to be past midnight) is crossed. Consequently, a more accurate visualization of the red line would be to have it take the form of a staircase, wherein the line stays flat throughout the day, and undergoes a discontinuous jump when the x-axis hits the "deadline" for that day. This would make the visual depiction much more accurate with respect to what happens in actuality.

As it stands, the Beeminder backend considers derailments every day for every goal of every user on their respective deadlines without exceptions. However, it seems that there might be utility in adding flexibility to that constraint, allowing users to pick exactly when these "derailment queries" are performed by the backend. The most general version of this includes two distinct cases:

1. Derailment can happen any time, any day (aka continuous beeminding). This corresponds to the piecewise linear redline representation being actually accurate with respect to derailments.

2. Derailments can happen at a discrete set of time instances, specified by the user through some sort of interface. This might be considered as a special case of Initial import from Glitch #1 above, if the redline representation is modified to incorporate discontinuities at these instances, preceded by flat regions extending back to the previous derailment consideration time.

The conceptually simplest way to implement all this is to keep relying on the piecewise linear redline representation, insert flat/vertical segment pairs into the graph matrix corresponding to time instances at which derailments will be considered, and modify the Beeminder backend to perform "rebraining" at the earliest intersection of the ppr-line extending from the latest datapoint with the hence modified redline. My concerns with this approach are the following:

• Following the insertion of flat/vertical segment pairs into the redline, the graph matrix (or its internal representation anyway) becomes quite large, adding computational complexity to graph generation and processing for basically all graphs regardless of whether the corresponding user cares about these issues at all or not.
• Visual representation of the previously nice and continuous redline becomes stairsteppy everywhere (except for continuously-beeminded time intervals), possibly impairing the visual clarity of the graph with possibly unnecessary cognitive overload.

Uluc: Both of these could significantly impair user experience, and I am not sure whether the pros outweigh the cons. My personal view is that the most common use case for this feature would be to regularly "skip" certain periods of time so that derailments happen only at specific days of the week, for example. I can't see continuous beeminding being commonly used, since the most common reason why this would be useful (being done with a task before a particular time of day) is already handled by the ability set the daily "deadline" for each goal. If we consider this to be true, then I would recommend the following extension to the current mechanisms for graph generation and beebraining:

• In addition to the current graph matrix, introduce a separate "deadline matrix" as a way to specify which specific days derailment is allowed to happen. This matrix would consist of rows with the following format:

  [ time, type, [indices]]

with the following semantics:

• time: Time at which the interval begins
• type: one of {week, month, year, custom[n]}, indicating the repetition pattern for the following set of day indices.
• [indices] : A "set" of indices (no duplicates), indicating a day pattern within the time interval selected by the "type".
  • For type = week, an index could be any of {Mon, Tue, Wed, Thu, Fri, Sat, Sun}
  • For type = month, an index could be any integer in [0, 30] or [-30,-1] corresponding to days of the month either starting from the first day for positive indices, or starting from the last day for negative indices
  • For type = year, an index could be any integer in [0, 365] or [-365,-1] corresponding to days of the year either starting from the first day for positive indices, or starting from the last day for negative indices. Alternatively, one could also use the (dd/mm) as an index to handle things like leap years.
  • For type = custom[n], an index could be any positive integer smaller than n, corresponding to specific days after the beginning of the interval, with the pattern repeated every n days.

This would allow the system to uniquely determine which specific time instants should be used for graph generation and hence derailment consideration. This information would be very simple to generate, and would be used by both the backend and the graph generation in computing what the redline and subsequent isolines should look like. The current status for graph generation corresponds to the following one-row deadline matrix:

[ tini, "week", [Mon, Tue, Wed, Thu, Fri, Sat, Sun] ]

which considers derailments every day of every week forever.

An alternative which, for example, places a deadline on Friday every week would be

[ tini, "week", [Fri] ]

Or, the last day of every month:

[ tini, "month", [-1] ]

Or, the Christmas eve:

[ tini, "month", [24/12] ]

This approach, in my opinion, may improve understandability and clarity for a larger number of users. On the other hand, both graph clarity and the complexity of graph generation (especially for dynagraphs where there is scrolling and hence regular regeneration of the graph) should be given careful consideration in figuring out whether this is worth the trouble.

Cognata

• https://blog.beeminder.com/staircase/
• Graph matrix (aka road) data structure documentation #117
• https://github.com/beeminder/beeminder/issues/750 (CHAINY vs CHUNKY structure)

Verbata: bright red staircase, continuous beeminding, stairsteppy bright red line,