bugGNU Octave - Bugs: bug #63820, ylim settings incorrect for small...


bug #63820: ylim settings incorrect for small limits < 1e-7

Submitter:  None
Submitted:  Mon 20 Feb 2023 02:31:55 PM UTC
Category:  Plotting with OpenGL Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Incorrect Result
Status:  Confirmed Assigned to:  None
Originator Name:  Florian Kerle Originator Email:  -email is unavailable-
Open/Closed:  * Open Release:  * 7.3.0
Operating System:  * Any Fixed Release:  None
Planned Release:  None
* Mandatory Fields

Add a New Comment (Rich Markup)

( Jump to the original submission )

Thu 23 Feb 2023 04:29:08 PM UTC, comment #8: 

With the original plot, I tried

ylim ([0, VAL])

for various values.  The plot is correct through 1e-7.  At 1e-8 the upper tick is no longer aligned with the top of the plot.

Rik <rik5>
Project Administrator
Thu 23 Feb 2023 04:25:02 PM UTC, comment #7: 

I can reproduce this on the development branch.  Octave shouldn't have this issue, and it is very likely related to the single precision used in OpenGL.  For the time being, scaling your data and then changing the labels  is the best workaround.  Here is an automated way to do that based on a callback function which "listens" for changes on the "ytick" property of the axes.

clear all;
x = 1:10;
y = 1e-11:1e-11:1e-10;
ynew = 1e10 * y;
plot (x, ynew);

function cb_ytick (h, ~)
  ytick = get (h, 'ytick');
  ytick ./= 1e10;
  ylabels = arrayfun (@(s) sprintf ("%.2g", s), ytick, 'uniformoutput', false);
  set (h, 'yticklabel', ylabels);

addlistener (gca, 'ytick', @cb_ytick);
cb_ytick (gca);  # Call once after initial plot to set limits

Once the plot is made and the listener is active you can execute normal commands such as

# manually set Y limits
ylim ([0, 1.5])
# Have Octave choose Y limits
ylim auto

Rik <rik5>
Project Administrator
Wed 22 Feb 2023 09:55:18 PM UTC, comment #6: 

Sorry, I didn't read the report carefully. You are right this issue is not a duplicate of bug #32980, even though the root cause is probably the same.

Reopening report and marking confirmed.

Pantxo Diribarne <pantxo>
Project Member
Tue 21 Feb 2023 08:07:39 AM UTC, comment #5: 


TL;DR: single precision float ~ -3 e-38 .. 3 e38 <- I'm talking about e-11.
please reopen!

I'm afraid it is NOT a duplicate!

octave IS plotting the graph CORRECTLY - only with automatic settings though. The MANUAL ylim is the problem!

The images in the "Precision Issues" doc page clearly show the missing resolution in the first plot, which are not present in the second one. This is NOT the issue.

Mon 20 Feb 2023 11:49:32 PM UTC, comment #4: 

This is a duplicate of bug #32980 where some (imperfect) workarounds are also provided.

Closing report.

Pantxo Diribarne <pantxo>
Project Member
Mon 20 Feb 2023 04:05:31 PM UTC, comment #3: 

Thanks for the fast replies!

Multiplying by a random factor would complicate yticklabel, measurements, etc.
Imho that should not be necessary. (Thanks for the the workaround anyhow)

If that is indeed the issue: How is it possible, that plotting AND printing without setting ylim manually, works?

Mon 20 Feb 2023 02:50:51 PM UTC, comment #2: 
Dmitri A. Sergatskov <dasergatskov>
Mon 20 Feb 2023 02:33:41 PM UTC, comment #1: 

Opengl only single precision. Take log or multiply by 1e10

Mon 20 Feb 2023 02:31:55 PM UTC, original submission:  

I'm at work, can test later on linux (debian) if required.

clear all;
print("correct.png", "-dpng")
ylim([0 1e-10])   % <-- NOTE: upper bound not correctly applied
print("wrong.png", "-dpng")  % <-- WRONG: upper y limit is reset -> image is not what was desplayed before (regardless of wrong y limit)

## Summary
I've encountered a problem with setting small (presumably) y limits. Reproducable on "qt" and "fltk". (gnuplot does work correctly, afaik)

1. When applying the y limit as in the above example, the correct limit is not set. Also manually setting the limit via `set(get(gcf).currentaxes, 'ylim', [0 1e-10])` does not set/display the correct upper y limit.

2. This presumably leads to some weiredness when printing (or saving via the graphical_toolkit "Save As" menu, fwiw):
The upper y limit is set the some incorrect value, distorting the plot completely.



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

Attach Files:

Attached Files
file #54383:  correct.png added by None (21KiB - image/png)
file #54384:  wrong.png added by None (21KiB - image/png)


   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 pantxo (Posted a comment)
  • -email is unavailable- added by dasergatskov (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 project members can vote.





    Follow 10 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2023-02-23 rik5 Summaryylim settings incorrect ylim settings incorrect for small limits < 1e-7
    2023-02-22 pantxo StatusDuplicate Confirmed
        Open/ClosedClosed Open
    2023-02-20 pantxo CategoryPlotting Plotting with OpenGL
        StatusNone Duplicate
        Open/ClosedOpen Closed
        Operating SystemMicrosoft Windows Any
        Dependencies- Depends on bugs #32980
    2023-02-20 None Attached File- Added correct.png, #54383
        Attached File- Added wrong.png, #54384

    Back to the top

    Powered by Savane 3.11