bugGNU Octave - Bugs: bug #61087, PLOT function produces incorrect...

 
 

bug #61087: PLOT function produces incorrect graph.

Submitter:  Trevor <ipa>
Submitted:  Sat 28 Aug 2021 05:40:43 PM UTC
   
 
Category:  Plotting Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Incorrect Result
Status:  Duplicate Assigned to:  None
Originator Name:  Trevor Open/Closed:  * Closed
Release:  * 6.3.0 Operating System:  * GNU/Linux
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Mon 30 Aug 2021 08:02:08 AM UTC, comment #5: 

I'm afraid I wouldn't know where to begin.  I know nothing about the Octave internals, let alone OpenGL, and would need a lot of guidance to even scratch the surface.

It's a shame as I see this problem is 10+ years old.

Trevor <ipa>
Sun 29 Aug 2021 05:47:21 PM UTC, comment #4: 

This is a duplicate of bug #32980.
This is a long standing bug.
If you have interest in providing a fix, please post a patch there.

Markus Mützel <mmuetzel>
Group administrator
Sun 29 Aug 2021 01:12:11 PM UTC, comment #3: 

@Trevor: Yes, that's the ultimate solution, but someone has to do the actual work.  It sounds like it should be easy, right?  But is it?  Can you help to create a solution for Octave to fix this problem?

John W. Eaton <jwe>
Group administrator
Sun 29 Aug 2021 12:40:21 PM UTC, comment #2: 

Oh that's very disappointing, but thanks for clarifying Dimitri.

Is there a plan to fix the problem ?


I do wonder though if a trick is being missed here.  I agree that a single precision library will manifest the problem, but it's not really the CAUSE of the problem in my view.

When it comes down to it a good high res display hardware has perhaps 7680x4320 pixels, and that defines the plot resolution, not single or double precision.  The job of the plotting subsystem is to map the graphical data to that limited display range by normalising it (subtract the mean offset and scaling).  Given the limited hardware resolution, single precision arithmetic has sufficient resolution to correctly do that.

However the PLOT function takes in double precision data and passes it to OpenGL, which apparently uses single precision.  If the data is not appropriately normalised (subtract the mean offset and scale) at the double to single conversion then detail will be lost at that stage, and that I suspect is where the problem lays. 

I'd suggest that the PLOT function is not appropriately normalising the data before it is converted to single precision.  The normalisation should only need to ensure the detail fits into a single precision number, the normalisation to the display hardware resolution should be handled in the graphics library itself.  The actual value can still be shown by axis labels.

The issue is really that the PLOT function accepts double precision data, but does not correctly map double precision data to the display, which should be possible.

Trevor <ipa>
Sat 28 Aug 2021 05:55:25 PM UTC, comment #1: 
Dmitri A. Sergatskov <dasergatskov>
Sat 28 Aug 2021 05:40:43 PM UTC, original submission:  

I've encountered a bug in the Octave PLOT function, when plotting some scientific data.  I've created below a stripped down demo code to demonstrate the problem with synthetic data.

The demo code produces two figures with comparable data, one showing the problem, one not.  The data produces a straight line graph in fig1, but in fig2 produces an error and displays a staircase waveform instead.  Also the xgrid is non-uniform & poorly labelled, and the y-axis labelling is poorly positioned.

The problem appears to be triggered when the data on one axis has a moderately large mean value, but small dynamic range.  And it occurs whether it is x data or y data.

I've checked this on the following platforms, all with the same result:

Linux Oct 6.3 (Flatpack)
Linux Oct 5.2 (Native)
Win10 Oct 6.1

I've plotted the same data with Python (code attached) and it plots correctly with no error.  Unfortunately I no longer have access to Matlab, but I would expect it to plot correctly also.

I suspect the problem may be that the plot function is not properly considering the graph limits, to plot the data with the correct resolution.

Please could a fix be made.

Regards, Trevor



OCTAVE DEMO CODE

function retval = plterr()

  close all;

  x=[0:0.001:1];
  y=[0:0.001:1];
  k=700000;

  h1=figure;      % This plots OK
  plot(x, y);
  grid on;

  x=x+k;          % Add offset to data

  h2=figure;      % This plots INCORRECTLY
  plot(x, y);
  grid on;

end


PYTHON DEMO CODE

#!/usr/bin/env python3
# -*- coding: utf-8 -*-
"""
Created on Sat Aug 28 13:22:20 2021

@author: trevor
"""

import numpy as np
import matplotlib.pyplot as plt

x = np.linspace(0,1,num=1000)+700000
y = np.linspace(0,1,num=1000)

plt.figure(num=0,dpi=120)
plt.plot(x, y)


Trevor <ipa>

 

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

Attach Files:
   
   
Comment:
   

No files currently attached

 

Digest:
   bug dependencies.

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by mmuetzel (Posted a comment)
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by dasergatskov (Posted a comment)
  • -email is unavailable- added by ipa (Submitted the item)
  • -email is unavailable- added by ipa (Plot issue)
  •  

    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 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2021-08-29 mmuetzel StatusNone Duplicate
        Open/ClosedOpen Closed
        Dependencies- Depends on bugs #32980
    2021-08-28 ipa Carbon-Copy- Added ipa

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code