This problem shows up now and then and tends to generate
duplicate bug reports. Untl it is fixed (by descaling the data)
it might be useful to put in a range test on the data and
issue a warning, at least, which explains the use of
single in OpenGL.

Adding a dependency on bug #32980 which is the need for OpenGL to support doubles or for Octave to scale everything before presenting it to OpenGL.

Sorry for a bit of delayed response.

Rik, I tried your script, thanks. Seems to work OK as far as plotting itself goes.
As the x-axes series are shifted in time, additional stuff is needed for properly labeling the X-axis ticks (e.g., datetick). But OK that can probably be done, with a bit of trickery.

Perhaps this trickery can even be turned into a provisional "front end" to the plotting functions as long as FLTK itself hasn't been fixed for this.
But the real solution IMO is what Michael has sketched, i.e. after inference of needed tickmarks, legends, scaling, ..., transforming the data series just before sending them to the actual plot engine. That is, if plot() etc work along this way.
I peeked inside plot and its private functions but where to begin is unclear to me (and probably beyond me anyway).

This is a problem with data precision and the fact that the FLTK uses variable of class single (~8 digits of precision) versus the doubles that gnuplot uses.

There is already a bug report filed against that so I am marking this as a duplicate.

It is simple to work around this issue.  In general, you want to discard any common element in the data to enhance the precision.  For example, imagine making a time series plot where the x-axis went from 2000 to 2009.  If I use that range I take 4 digits of precision.  Alternatively, I could subtract by the common factor 2000, and then the range is 0-9 which takes only 1 digit of precision.  I'm attaching a script which demonstrates how to get a correct plot using your data.  In this case I used center() on your x-axis data which subtracts the mean from data.


(file #23680)