bugGNU Octave - Bugs: bug #58305, Colorbar scale errors for very low...

 
 

bug #58305: Colorbar scale errors for very low numbers

Submitter:  None
Submitted:  Tue 05 May 2020 02:37:57 PM UTC
   
 
Category:  Plotting with OpenGL Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Incorrect Result
Status:  Duplicate Assigned to:  None
Originator Name:  Vincenzo Originator Email:  -email is unavailable-
Open/Closed:  * Closed Release:  * dev
Operating System:  * Any Fixed Release:  None
Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Sat 23 May 2020 04:21:17 PM UTC, comment #2: 

Yes, this is just another problem related to the use of single precision for the OpenGL backend.

The issue is relatively easy to workaround.  Scale the numbers by an arbitrary factor, say 1e6, so they are no longer below "eps ('single')".  Plot the data.  Add the colorbar, but get the handle to it.  Adjust the labels manually.

In pseudo-code


data = data * 1e6;
plot (data);
h = colorbar ();
set (h, 'yticklabels', { "0.0", "0.5", "1.0" })


Closing report as a duplicate.

Rik <rik5>
Group administrator
Wed 06 May 2020 08:28:22 PM UTC, comment #1: 

This is probably another manifestation of bug #32980.
The OpenGL backend uses single precision floating point numbers. eps('single') is approx. 1.1921e-07. So it is to be expected that there are deviations for such small numbers where neighbors are sparse. [1]

[1]: https://en.wikipedia.org/wiki/Denormal_number

Markus Mützel <mmuetzel>
Group administrator
Tue 05 May 2020 02:37:57 PM UTC, original submission:  

Hello everyone!
I noticed that when I try to plot a colorbar of a 3D plot with the 'slice' command (e.g. h=slice(xx,yy,zz,V,xslice,yslice,zslice);) with very low values (order of magnitude 1E-14), I get a wrong colorbar scaling (see the attached picture). I tried to fix it with various commands and tricks which I found in various forums discussions (including those of Matlab), but with no success. The problem disappears if I multiply the values for a 1E+14 factor (i.e. it seems it is just a problem of the order of magnitude of the values).

I got the problem with ver. 5.1.0 and both with the last one 5.2.0.

Did anybody noticed the same problem? If yes, is it normal or is it a bug? In this case, how can it be fixed?

Every suggestion will be more than welcome.

Thank you.

Enzo

Anonymous

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #49003:  BPA_H_capt.jpg added by None (69KiB - image/jpeg - Please note the colorbar scale)

 

Digest:
   bug dependencies.

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by mmuetzel (Posted a comment)
  • -email is unavailable- added by None (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 8 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2020-05-23 rik5 StatusNone Duplicate
        Open/ClosedOpen Closed
    2020-05-06 mmuetzel CategoryPlotting Plotting with OpenGL
        Item GroupInaccurate Result Incorrect Result
        Release5.1.0 dev
        Operating SystemMicrosoft Windows Any
        Dependencies- Depends on bugs #32980
    2020-05-05 None Attached File- Added BPA_H_capt.jpg, #49003

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code