bugGNU Octave - Bugs: bug #45541, Automatically scale values before...

 
 

bug #45541: Automatically scale values before plotting

Submitter:  None
Submitted:  Mon 13 Jul 2015 11:56:08 AM UTC
 
Category:  Plotting with OpenGL Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Incorrect Result
Status:  Duplicate Assigned to:  None
Originator Name:  Originator Email:  -email is unavailable-
Open/Closed:  * Closed Release:  * 3.8.1
Operating System:  * Any
* Mandatory Fields

Add a New Comment (Rich Markup)
   

Comment Type & Canned Response:
       

 

Thu 16 Jul 2015 10:50:37 AM UTC, comment #5: 

Well toolkit often stands for graphics_toolkit in Octave, not the GUI library we use to implement it.
Both Qt and FLTK graphics_toolkit use a common OpenGl rendering class (see [1]) to draw graphics objects on their respective canvas. The preliminary scaling from graphics object data to OpenGl friendly coordinates should be done there.

I'll close this report as duplicate of bug #32980. The "solution" isn't different from what has already been proposed and, up to now, doesn't include the programmer to implement it.

[1] http://octave.org/doxygen/3.8/d8/d00/classopengl__renderer.html

Pantxo Diribarne <pantxo>
Project Member
Wed 15 Jul 2015 05:05:06 PM UTC, comment #4: 

With toolkit, I do not mean the interface between Octave and FLTK, I mean FLTK itself. If I created a GUI toolkit (I have considered to do so since I am not happy with any existing one), I would use Window coordinates between -1 and 1. So the line drawing API, for the "Canvas" widget would simply look like

    void lineDraw(Canvas* c,const float* x,const float* y,size_t n_points);

Or

    void lineDraw(Canvas* c,const Point* x,size_t n_points);

As a user of that function, I do not need to ask for the width, since I know that the scaling is invariant. All I need to do before calling the function is to make sure all values are in the correct range, and that is trivial. The only problem is aspect ratio, but that can be solved by choose a fixed y range [-1 1] and add

    float widthGet(Canvas* c);

It is now left to Octave to call these functions with appropriate values. Compatible with Matlab? Yes.

I am not an expert in Octave, but I know that the `plot` command is a high-level routine, so the `plot` command should not do the work, it is more low-level than that.

Anonymous
Wed 15 Jul 2015 02:37:07 PM UTC, comment #3: 

Would everyone be happy if the OpenGL
plotting functions only accepted type single
or, as you propose, rejects all data input
outside [-1,1]?

Aside from this causing a lot of trouble, it
is not compatible with Matlab, R, or others.

Michael Godfrey <godfrey>
Project Member
Wed 15 Jul 2015 09:55:38 AM UTC, comment #2: 

I disagree with that the toolkit should do rescaling. It makes completely sense to only accept normalized values since it follows the UNIX principle. It makes also a simpler contract to assume that the viewport size always stays within [-1 1]. Some extra work on the client maybe, but much cleaner. You do not expect an audio daemon (jackd) to scale sample values for you, do you? If you give jackd values outside [-1 1] it will clip the signal.

Anonymous
Mon 13 Jul 2015 01:30:31 PM UTC, comment #1: 

It is known that the appropriate solution is to
rescale, but this should be done within the graphics
toolkit.

In the meantime, the user can do the rescaling
even though this is a bit tedious.

Also, the Manual should be corrected.

Michael Godfrey <godfrey>
Project Member
Mon 13 Jul 2015 11:56:08 AM UTC, original submission:  

This is a known problem but it has a solution:

From the manual
    Caution: The FLTK toolkit uses single precision variables internally which limits the maximum value that can be displayed to approximately 10^{38}. If your data contains larger values you must use the gnuplot toolkit which supports values up to 10^{308}.

The solution is to not pass values directly to FLTK. First scale them to fit within [-1,1] and draw the axis with labels formatted from the original values. The choice of feeding directly have other bad effects which occurs for time series with a fairly large offset (see figure). It is strange that line drawing is affected but not points.

Anonymous

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #34430:  skärmdump1.png added by None (17KiB - image/png - Figure illustrating the bug)

 

Digest:
   bug dependencies.

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by pantxo (Posted a comment)
  • -email is unavailable- added by godfrey (Posted a comment)
  •  

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

    Date Changed by Updated Field Previous Value => Replaced by
    2015-07-16 pantxo StatusNone Duplicate
        Open/ClosedOpen Closed
        Dependencies- Depends on bugs #32980
    2015-07-13 None Attached File- Added skärmdump1.png, #34430

    Back to the top


    Powered by Savane 3.9