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

Wed 03 May 2023 07:09:45 AM UTC, comment #9: 

Thanks for the workaround!
Adding a listener this way is tremendously useful for other use cases as well.

Hope the single precision / related stuff will finally get adressed in the future.

BR
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;
> figure()
> 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);
> endfunction
>
> 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


>

 Anonymous
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>
Group 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;
figure()
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);
endfunction

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>
Group 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>
Group Member
Tue 21 Feb 2023 08:07:39 AM UTC, comment #5: 

@Pantxo

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.


Anonymous
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>
Group 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)

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

 Anonymous
Mon 20 Feb 2023 02:50:51 PM UTC, comment #2: 

It is a know problem:

https://docs.octave.org/interpreter/Precision-issues.html

Dmitri.
--

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
.

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

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

TL;DR:
clear all;
figure()
plot(1e-11:1e-11:1e-10)
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.

 Anonymous

 

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

Attach Files:
   
   
Comment:
   

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

 

Depends on the following items
bugsOpenGL plotting backend uses single precision, not double (bug #32980, Confirmed)

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 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 group 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

    Copyright © 2024 Free Software Foundation, Inc.
    Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.
    The Levitating, Meditating, Flute-playing Gnu logo is a GNU GPL'ed image provided by the Nevrax Design Team.
    Page source code

    Powered by Savane 3.14-f13d.
    Corresponding source code