Some functions require additional history during replays

[rixed]

For instance the attached screenshot shows an interesting case where all values cone from the same function, yet in between 2 replays all points are missing bu two.

There is actually not really a bug but a design flaw. The missing values are the first values of the new replay, because the function used (OK uses an hysteresis, perc_derivative uses previous.perc, as do cashflow_derivative. And so when the new replay starts with those data, it has no previous data and thus can not compute the value! As an illustration, here is a 10s gap for a LAG-10 function, that is NULL for 10s:

[rixed]

Plan:

• [ ] val O.use_past : O.t -> int * float: returns how many input tuples / event time seconds (at most) of past data are needed for that function to be able to output "realistically acceptable" output
• [ ] Store this info with the function compiled info
• [ ] When evaluating the cost of recomputing a function's output, it means we must consider the cost of outputing a larger time interval from all its parents (ie. requested interval grows as we recurse toward the root)
• [ ] Similarly when building the replay plan, time boundaries must be inflated as we recurse toward the root, both in terms of starting time and number of tuples before some date, which makes initial archive file choice hairy. (If it's OK to convert seqnums into time for replay cost estimation, it is not in general OK to do so when actually replaying past data)

Alternatives

• Get rid of non time based past usage but that seems too limiting a restriction.
• Instead of replaying more data, just draw a warning over the un-reproductible section of the chart (make this width part of the response somehow)

Issues still:

• Some functions require an infinite history (such as the smooth family)
• Some functions requirement might depend on the data (can't find a realistic use case though)
• Determining the amount of history required by some expression is not as easy as it looks; some seemingly harmless functions might require infinite history if they use the output tuple for instance (ex. avg of past 10 out.x).

All these issues are calling for an optional setting to indicate the historical requirement for each function: solves the issues of finding out history requirement in complex cases and of determining archive times when faced with seqnum requirements (no user indication => input is periodic enough to convert seqnums into times).