bugGNU Octave - Bugs: bug #59418, Document work-arounds for...

 
 

bug #59418: Document work-arounds for single-precision OpenGL plots

Submitted by:  Markus Mützel <mmuetzel>
Submitted on:  Thu 05 Nov 2020 12:12:12 PM UTC  
 
Category:  Plotting with OpenGL Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Documentation
Status:  None Assigned to:  None
Originator Name:  Open/Closed:  Open
Release:  dev Operating System:  Any

Add a New Comment (Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

Mon 09 Nov 2020 03:16:55 AM UTC, comment #3: 

What do you think about this? Where should it be located in doc/interpreter/plot.txi ?

The limitation to single precision in particular applies to plots of timeseries against serial dates as used by the datenum(), datestr(), datestruct(), and datetick() functions.

Serial dates encode timestamps as days elapsed since the year zero with hours, minutes, seconds as the fractional part. On Dec. 31. 1999 the serial date representation was 730485. A double precision variable with this integer part allows for a resolution in its fractional part of 1.2e-10, representing about 5 microseconds. But with single precision this is reduced to about 0.06, representing 45 minutes. Any attempt to plot timestamped data with finer granularity will result in a distorted graph.

As a workaround one can subtract 2000 years, i.e. datenum(2000,0,0) or 730485 from the time values. Due to the fact that the calendar structure repeats every 2000 years, the relation between year, month, day of month and day of week will stay unchanged and the ticks and ticklabels produced by the datetick() function will still be correct. Only years will lack the millennium digit, thus "2020" will be printed as "20".

Just replace plot (t, x) with plot (t - 730485, x)

#timestamps of 24 hours in one minute steps
t = datenum(2020,1,1):(1/1440):datenum(2020,1,2);

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

subplot(1,2,1)
plot(t,x)
datetick x
xlabel "serial date"
title "problem"

subplot(1,2,2)
plot(t - 730485,x)
datetick x
xlabel "2000 years off"
title "workaround"


Lars Kindermann <larskindermann>
Sat 07 Nov 2020 09:04:20 PM UTC, comment #2: 

@Lars: Could you provide concrete examples with explanatory text that could be shown in the documentation? That would help getting this done.
The best would be a changeset that we could apply to the sources.

Markus Mützel <mmuetzel>
Project Member
Sat 07 Nov 2020 11:41:41 AM UTC, comment #1: 

Me and my students are really often hit by this bug when plotting time series with serial dates on the time-axis. It will inevitably occur when you plot recent timestamped data with better than minute resolution or so. I had provided a striking example in bug #32980.

So I suggest to include this specific issue in the documentation, together with the simple proposed workaround to subtract datenum(2000,0,0) from the date values, because luckily our calendar repeats every 2000 years. Month, days and even weekdays stay correct this way.

The only minor issue then is that dateticklabels may state the year as "0020". Perhaps the routines to automatically label the date axis could be temporally modified to leave out the century digits if they equal to "00"?

And of course you have to keep in mind the offset in callbacks...

Lars Kindermann <larskindermann>
Thu 05 Nov 2020 12:12:12 PM UTC, original submission:  

There are known issues because the OpenGL graphics backend uses single precision floating point numbers internally (see e.g. bug #32980).
There are also known work-arounds (mainly re-scaling) for this issue.

Rik wrote in bug #59370:

> Whether as part of this issue report, or a separate one, I think we should add a @subsection or @subsubsection with workarounds for the OpenGL toolkit.  The qt toolkit remains the preferred toolkit, and there are specific strategies for dealing with either large values which exceed the range of a single type or for data with very fine gradiations which exceeds the resolution of a single type.


This bug is here to track documentation changes to describe these strategies and work-arounds.

Markus Mützel <mmuetzel>
Project Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #50228:  ttest.png added by larskindermann (27KiB - image/png)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by larskindermann (Posted a comment)
  • -email is unavailable- added by mmuetzel (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.

     

     

     

    Follows 1 latest change.

    Date Changed by Updated Field Previous Value => Replaced by
    2020-11-09 larskindermann Attached File- => Added ttest.png, #50228

    Back to the top


    Powered by Savane 3.5