Data with resets (legal nonmonotonic timestamps) incorrect rendering

[breznak]

Problem: For example OPF files have a reset field which annotates a new sequence starts. It is perfectly legal for the new sequence to have a different/older timestamp than the previous sequence. This is detected as non-monotonicity in time and causes the graph to be incorrectly rendered.

Solution:

• if detected combination hasResets, the timestamp is ignored and we use iterations.
  • [ ] it would be nice to show the "original time" field, currently it gets suppressed.

Note:

• I'm thinking if we should avoid the hassle with timestamp parsing at all, and just stick with iteration for xdata and show timestamp as a normal field; as suggested above.

[breznak]

Thoughts @jefffohl @rhyolight ?

[rhyolight]

@breznak said:

It is perfectly legal for the new sequence to have a different/older timestamp than the previous sequence.

@scottpurdy Is this true?

[scottpurdy]

What code are we talking about here? In the OPF, it is perfectly valid to have resets and older timestamps afterward. But what graph are we talking about?

[breznak]

@scottpurdy just visualization specific problem here. For DyGraphs we need functions (one fn value at given time), OPF with resets does not ensure that, so we should represent the data differently, not plotted as function of time, but as fn of iteration number(step).

[scottpurdy]

Ahh got it. Yes that sounds right. We should use the record number for the x-axis and timestamps just as labels.

[rhyolight]

Thanks @scottpurdy

[breznak]

Reopening for discussion if we should :

• ditch the timestamp and use iterations for x-data
• keep using time where possible (current)