High-resolution plotting

[alexforencich]

I need to plot some data with a very high-resolution time axis. Think, unix timestamps, but with sub-picosecond resolution. 64-bit floating point does not have sufficient resolution to represent this, as I need more than 72 bits of resolution to get both at least 32 bits for seconds and at least 40 bits for fractional seconds to get down to picoseconds. Currently I am using D128 from fastnum to store the data. It's one thing to plot an overall view of the trace where truncation doesn't really matter, but the problem is what happens when you zoom in to look at a handful of points and they don't get plotted in the right spots due to truncation.

I'm not sure what the "right" way to solve this would be. One option is to support plotting via a high-resolution decimal type (fastnum, rust_decimal, etc.) directly and avoid converting to floating point. This is probably the best option, but I'm not sure about performance and such. Another potential option is to support offsetting the X and/or Y axes, possibly on a per-trace basis, to remove most of the time portion to reclaim some resolution for the fractional part. But this doesn't really solve the problem completely as there would only be ~12 bits of the f64 mantissa left for the time portion. Maybe dynamically changing the offset based on the current zoom level and plot extents would work? Still possibly not a very clean solution.

I'm also not sure the best way to handle the axis markings, seems like what's really needed is some kind of relative labeling where some reference is marked with the full resolution and then the other divisions are marked relative to the reference. Maybe even something more like an oscilloscope display makes sense, where the individual grid lines are not marked at all, but instead you have "reference" and "per division" values displayed somewhere, and the reference lines explicitly marked in a distinctive way.

Does anyone have any thoughts on this? Does it make sense to try to support plotting high-resolution decimal values directly? Does it make sense to have some alternate axis labeling modes that might be better suited for this kind of data? Or is this too specialized?

[oscargus]

f128 is in nightly so will hopefully be stable soon. https://doc.rust-lang.org/std/f128/index.html

It may not be the ideal solution, but may very well be the simplest to implement if nothing else...

[CramBL]

It would be awesome if we could avoid having to convert unix timestamps to f64. It has bit me a few times too.

One workaround is to normalize the timestamps to whatever the start of your data series is. So if you only have data from 2020 and on, you make the unix timestamp for 2020 be your 0 value, then you won't lose as much precision as you would when 0 is 1970.

That's what you're hinting at with your "relative" X-axis as well (If I understand correctly).

But for sub-picosecond precision that will obviously not be ideal.