bugGNU Octave - Bugs: bug #45356, Wrong tick labels when limits are...

 
 

bug #45356: Wrong tick labels when limits are set manually

Submitter:  Pantxo Diribarne <pantxo>
Submitted:  Fri 19 Jun 2015 12:40:55 PM UTC
   
 
Category:  Plotting Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Matlab Compatibility
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * dev Operating System:  * Any
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Wed 21 Oct 2015 10:58:10 AM UTC, comment #7: 

Sorry for being imprecise. Yes, im using the gnuplot backend with qt terminal. But according to your statement, I should rather move to qt backend and contribute to development by reporting bugs there.

W.F.

Anonymous
Tue 20 Oct 2015 10:16:19 PM UTC, comment #6: 

I don't see anything strange on Linux using 4.0.0 or the current development code.  Tick marks are in the same location as that returned by "get (gca, 'xtick')".  This is with one of the OpenGL backends such as qt or fltk.  If you are using gnuplot then all bets are off.  In that case I do see tick marks that don't correspond to the ones set in Octave.  You could file a separate bug report about that using the Category Plotting with gnuplot.

It might, or might not, get fixed.  Octave is moving away from gnuplot because it is slow and we don't have enough control over what is displayed.

Rik <rik5>
Group administrator
Tue 20 Oct 2015 09:52:01 PM UTC, comment #5: 

Can anyone confirm that the patch will also fix the following strange behavior:


plot ([0:2])
axis([1.01 3])
get(gca,"xtick")
ans =

   1.0000   1.5000   2.0000   2.5000   3.0000


The actual xticks displayed in the figure are [1.2 1.4 1.6 1.8 2 2.2 2.4 2.6 2.8 3].

This seems similar to the problem discussed below, but is not related to ticks going beyond the displayed axis limits. Rather, the "xticks" property misses entries within the xlim range.

W.F.

Anonymous
Sun 21 Jun 2015 03:00:05 PM UTC, comment #4: 

I committed the patch here (http://hg.savannah.gnu.org/hgweb/octave/rev/ce8fda51d236) with one added BIST test.  Closing report.

Rik <rik5>
Group administrator
Sat 20 Jun 2015 04:09:57 PM UTC, comment #3: 

Rik, I tested your patch in few situations (log, lin, limits smaller/larger than data) and didn't notice any failure. Maybe you can add the originally failing script as BIST.

Pantxo Diribarne <pantxo>
Group Member
Fri 19 Jun 2015 05:00:22 PM UTC, comment #2: 

This is a little strange.  It's not tragic, but could probably be improved.  The issue is that the routine that tries to find a reasonable spacing of ticklabels will often produce an extra ticklabel at the far left and far right of the range.  These values may be outside the current xlim, which isn't a problem for display because any labels outside the current limits are not displayed.  Here is an example that is pretty clear.


plot (1:10);
xlim ([4.75, 8.5]);
get (gca, "xtick")
ans =

   4   5   6   7   8   9


The routine for finding ticks likes to divide the range into 5 divisions, although it will compromise and use 4 or 6 as necessary.  In this case it produced five divisions: 4-5, 5-6, 6-7, 7-8, 8-9.  But the endpoints of the divisions 4 and 9 are not visible.  The code to change is calc_ticks_and_lims() in graphics.cc.  See the attached patch.  It appears to work, but I only used the example from this bug report for testing.  It would need a bit more verification before commititng.


(file #34266)

Rik <rik5>
Group administrator
Fri 19 Jun 2015 12:43:30 PM UTC, comment #1: 

No I am not living in the future, the test ML version is 2013a.

Pantxo Diribarne <pantxo>
Group Member
Fri 19 Jun 2015 12:40:55 PM UTC, original submission:  

Octave returns wrong tick labels when limits are set manually:


plot (1:10)
xlim ([.5 10.5])
get (gca, 'xtick')
get (gca, 'xticklabel')


The displayed xlabels are correct, i.e [2 4 6 8 10], while the returned values for "xtick" and "xticklabel" properties are consistently wrong: [0 2 4 6 8 10 12]. These are the labels we would have obtained if xdata had actually extended from 0.5 to 10.5 and the xlimmode had been "auto".

I could check in ML 3013a that displayed and returned values are consistent, i.e. [1 2 3 4 5 6 7 8 9 10].

I wouldn't expect that Octave follows ML exactly (i.e. increments of 1 instead of 2), but I do expect displayed and returned values to be consistent as in ML.

Pantxo Diribarne <pantxo>
Group Member

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #34266:  tick.cset added by rik5 (991B - application/octet-stream)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by rik5 (Updated the item)
  • -email is unavailable- added by pantxo (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 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2015-06-21 rik5 StatusPatch Submitted Fixed
        Open/ClosedOpen Closed
        Release4.0.0 dev
    2015-06-19 rik5 Attached File- Added tick.cset, #34266
        StatusNone Patch Submitted

    Back to the top

    Powered by Savane 3.13-02a9.
    Corresponding source code