[Octave-bug-tracker] [bug #32980] OpenGL plotting backend uses single precision, not double

[Lars Kindermann]

Follow-up Comment #25, bug #32980 (project octave):

I really want to bring this topic up again. At first glance it seems like a
rare corner case problem, occurring only when working with pretty ill scaled
data.

But have a look at this fairly simple example (plot example is attached):


#the last 24 hours in one minute steps
t = now-1:(1/1440):now;            

#some example timeseries
x = -cos(2*pi*t) + rand(size(t))/10; 

subplot(1,2,1)
plot(t,x)              
datetick x
title(datestr(t(end)))

#get rid of the calendar day
t = t - fix(now);  

subplot(1,2,2)
plot(t,x)             
datetick x
title(datestr(t(end)))
  

In fact, serial dates as used by all time related functions in Octave are
subject to this problem. Everybody plotting time stamped data with high
resolution will be hit. This is daily routine in geophysics, meteorology,
astronomy, stock charts, renewable energy, web traffic analysis, medicine,
etc. And worse, there is no indicator that the plots are incorrect in fact.  

At the moment there are only two options to get around this, use     gnuplot
(but then you are limited to just plain plots, no interactivity) or manually
tune your code to get rid of the integer date offset. But then you loose many
of the benefits of the datetick() function, like calendar dates on the time
axis and any interactive handling or zooming becomes much more complicated.

Having looked at the code, I fear that fixing this fundamentally will be
really a lot of work, requiring to offset and scale all plot data before
sending to the plot engine and keep track of this for transforming correctly
backwards when the plot returns interactive messages, or when adding or
modifying data. Probably an additional abstraction layer between the octave
plot logic and the graphics api needs to be inserted.

But in the meantime I strongly opt for at least throwing a warning when there
is some indication that the scaling problem actually hits, not leaving the
user unnoticed with an incorrect plot. This is also not trivial as it will be
more a guess than some well defined calculation and should not be triggered
too often by insignificant or false positives. 

I am willing to spend some time on it, as this is one of the most annoying
issues in Octave I am frequently confronted with. Does somebody have a
suggestion where in the code such a test should ideally be located? This might
be also a good start for inserting the rescaling code.    


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?32980>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/