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

 
 

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

Submitted by:  Pantxo Diribarne <pantxo>
Submitted on:  Fri 19 Jun 2015 12:40:55 PM UTC  
 
Category: PlottingSeverity: 3 - Normal
Priority: 5 - NormalItem Group: Matlab Compatibility
Status: FixedAssigned to: None
Originator Name: Open/Closed: Closed
Release: devOperating System: Any

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

(Jump to the original submission 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>
Project 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:

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>
Project 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>
Project 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.

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>
Project 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>
Project Member
Fri 19 Jun 2015 12:40:55 PM UTC, original submission:

Octave returns wrong tick labels when limits are set manually:

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>
Project Member

 

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

Attach File(s):
   
   
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
  • -unavailable- added by rik5 (Updated the item)
  • -unavailable- added by pantxo (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 5 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Sun 21 Jun 2015 03:00:05 PM UTCrik5StatusPatch Submitted=>Fixed
      Open/ClosedOpen=>Closed
      Release4.0.0=>dev
    Fri 19 Jun 2015 05:00:22 PM UTCrik5Attached File-=>Added tick.cset, #34266
      StatusNone=>Patch Submitted

    Back to the top


    Powered by Savane 3.1-cleanup1