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

 
 

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

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

Add a New Comment Rich Markup
   

Jump to the original submission

Fri 02 Apr 2021 08:12:26 AM UTC, comment #7: 

The manual still seems to be built correctly after these changes. (At least, I'm not aware of any reports about the contrary.)

Closing report as fixed.

If someone is interested in making the changes that Lars suggested in comment #5, we should open a separate report.

Markus Mützel <mmuetzel>
Group administrator
Sun 21 Mar 2021 11:11:55 AM UTC, comment #6: 

I agree that a warning might be helpful for some users.
But I also agree that this would probably mean many functions would need to be changed. Additionally, functions that are currently agnostic of the graphics toolkit would need to use differing code depending on the toolkit.
I'm not sure if it is worth the effort of implementing and maintaining that additional complexity. (The time would probably better be spent on trying to fix bug #32980.)

If at all, that should probably be tracked in its own bug report.

Markus Mützel <mmuetzel>
Group administrator
Sat 20 Mar 2021 12:45:23 PM UTC, comment #5: 

Looks good for me, thanks for doing the formatting.

What do you think about datetick() throwing a warning in qt and fltk, pointing to this text, when the axes' limits look like being affected? Some simple heuristics, like checking if pixel resolution is way better than numerical resolution for the singles?

"Warning: For timestamps in the current range the plot resolution is worse than 45 minutes. The plot may look distorted. See (link here) for a possible workaround."

Or even make plot() and other functions check for some scaled difference between data(:) and single(data(:))? But that's a lot of work in many functions...


Lars Kindermann <larskindermann>
Sat 20 Mar 2021 10:42:01 AM UTC, comment #4: 

Thanks four your suggestion.
I pushed a patch based on it to stable here:
https://hg.savannah.gnu.org/hgweb/octave/rev/75ba68c686ab

Marking as ready for test.

Markus Mützel <mmuetzel>
Group administrator
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>
Group administrator
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>
Group administrator

 

(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

Digest:
   bug dependencies.

 

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

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2023-04-18 nrjank Dependencies- bugs #36094 is dependent
    2021-04-02 mmuetzel StatusReady For Test Fixed
        Open/ClosedOpen Closed
    2021-03-20 mmuetzel StatusNone Ready For Test
    2020-11-09 larskindermann Attached File- Added ttest.png, #50228

    Back to the top

    Powered by Savane 3.13-3230.
    Corresponding source code