#783624 octave: Bad plotted data against time with long arrays

Package:
octave
Source:
octave
Description:
GNU Octave language for numerical computations
Submitter:
Marco
Date:
2015-04-30 00:45:09 UTC
Severity:
normal
#783624#5
Date:
2015-04-28 13:41:25 UTC
From:
To:
Dear Maintainer,

The bug arises using Octave 3.8.2, when plotting an array of data with
dimension of 14327x1 against an array of times. Times is an array created with
datenum with a step of 10 minutes between data.
The trend of plotted data is made by segments and it is not continuous as it
should be.
Plotting data alone, not against time, or using Octave 3.6.2 gives a correct
curve. I send you 2 figures to explain better the bug.

Marco
#783624#10
Date:
2015-04-28 14:35:57 UTC
From:
To:
* Marco <marco.bajo@gmail.com> [2015-04-28 15:41]:

Thanks for your bug report.

Could you please send to us the actual code that you used to produce the
plots?

Best,

Rafael
#783624#17
Date:
2015-04-29 13:49:20 UTC
From:
To:
Dear Maintainer,

The bug arises using Octave 3.8.2, when plotting an array of data against
an array of times. Times is an array created with datenum with a step of 10
minutes between records. The trend of plotted data is made by segments and
it is not continuous as it should be. Plotting data alone, not against
time, or using Octave 3.6.2 gives a correct curve. I attach the m-file and
the dataset need to reproduce the bug.

Marco
#783624#22
Date:
2015-04-29 18:31:35 UTC
From:
To:
* Marco Bajo <marco.bajo@gmail.com> [2015-04-29 15:49]:

I can obtain non-jagged curves from your data using either this:

     close all
     graphics_toolkit ("gnuplot")
     plot (ttr, currr)

or this:

     close all
     graphics_toolkit ("fltk")
     plot (ttr - floor (ttr (1)), currr)

Notice that fltk is the default graphics toolkit.  This is the reason you
do not see what you expect when you run:

     plot (ttr, currr)

without changing the graphics toolkit from the default.

At any rate, this is an upstream issue and I am hereby tagging this bug
report accordingly.  It is related to the specific numerical condition of
your data.  This is the reason why the problem disappears when
floor(ttr(1)) is subtracted from ttr.

I will report this upstream, eventually.

Thanks,

Rafael
#783624#29
Date:
2015-04-30 00:12:42 UTC
From:
To:
Control: forwarded -1 https://savannah.gnu.org/bugs/?32980

Done!

This is a known upstream bug, the OpenGL plotting toolkits only support
single precision values. If your x or y data series exceed the bit depth
of single precision, some number of sequential values will end up being
the same, and it will plot as you've seen.

A workaround is to use gnuplot as Rafael has shown.

Another workaround would be to quantize or scale your x data series so
it doesn't overflow the depth of a single precision value. For example,
if you subtract datenum(2010,1,1) from your trr vector, the plot comes
out ok.
#783624#36
Date:
2015-04-30 00:15:59 UTC
From:
To:
* Rafael Laboissiere <rafael@laboissiere.net> [2015-04-29 20:31]:

Done.

Rafael
#783624#43
Date:
2015-04-30 00:23:32 UTC
From:
To:
Oh my, I have not seen Mike Miller's message before posting my message
below.  I am restoring here the forwarded URL (and also lowering its
severity level to normal).

Rafael

* Rafael Laboissiere <rafael@laboissiere.net> [2015-04-30 02:15]:
#783624#50
Date:
2015-04-30 00:42:19 UTC
From:
To:
Rafael

* Rafael Laboissiere <rafael@laboissiere.net> [2015-04-30 02:23]: