bugGNU Octave - Bugs: bug #46047, Large number of axes ticks for big...

 
 

bug #46047: Large number of axes ticks for big logarithmic plots

Submitted by:  Marco Caliari <caliari>
Submitted on:  Thu 24 Sep 2015 11:52:16 AM UTC  
 
Category: PlottingSeverity: 3 - Normal
Priority: 5 - NormalItem Group: Regression
Status: ConfirmedAssigned to: None
Originator Name: Open/Closed: Open
Release: 4.0.0Operating System: GNU/Linux

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)

Sun 31 Jan 2016 08:13:53 AM UTC, comment #6:

Michael, I agree that documenting the limitation is useful as a backup.

Panxto, I agree that we need to choose a rule for both major and minor tics in a consistent way.

One problem with basing the spacing on the number of pixels is that things like PDF don't really have pixels. It may be useful to use the width and height of a character of the label font as a unit.

I would use a rule of thumb that the space between consecutive labels should be no less than approximately the width of a label (which depends on the number of digits in the label as well as the font size).

Given the major tics, we could have as close as possible to 4 minor tics per major tic, while staying with one of the sets:
10^0, 10^n, 10^2n, ...
1,3,10,30....
1,2,5,10,20,50...
1,2,3,5,7,10,20...
1,2,3,4,5,6,7,8,9,10,20,...
(or something finer if the major tics are very close)

Some packages refuse to have major tics closer together than a power of 10, but that often leads to plots that quite hard to read.

Again, $0.02

Lachlan Andrew <lachlan>
Project Member
Wed 07 Oct 2015 11:43:26 AM UTC, comment #5:

It is pretty widely accepted that a completely
general solution for automatic tick marks does not
exist. But, trying to avoid the recent problems is,
of course, worth doing. Imagining that these fixes
will "always" work is not appropriate.

It may be helpful to put something in the Manual to
point out that manual control of tick marks may be
needed, or at least useful to improve the result,
in special cases.

Michael Godfrey <godfrey>
Project Member
Wed 07 Oct 2015 11:27:22 AM UTC, comment #4:

@Avinoam: then you end up with bug #39449, which is minor ticks are no more computed correctly.

I think fixing bug #39449 involves being able to compute minor ticks when major ones are not distant of one order of magnitude. For this we should first decide what to do when minor ticks come to be be ridiculously close to each other:

  • use a fixed tule: show 2:9 if tick_sep < 6, then 2:2:9 for ticksep <10, then 2:3:9 ...
  • use a rule based on the minor tick separation: e.g. minimum 2 pixels between two minor ticks.

There may be other rules we can imagine but it is only once one of those rules has been chosen that we can fix both this bug and bug #39449. This is my 2cts.

Pantxo Diribarne <pantxo>
Project Member
Tue 06 Oct 2015 07:51:27 PM UTC, comment #3:

What about something like:

Avinoam Kalma <avinoam>
Project Member
Fri 25 Sep 2015 08:42:14 PM UTC, comment #2:

It is a regression. I just checked with 3.8.2 and Octave sensibly comes up with just 8 ticks/labels from 10^-50 to 10^300. The problem seems to be the solution for bug #39449 which always sets the tick separation on log plots to one order of magnitude.

The issue is in graphics.cc with function axes::properties::calc_ticks_and_lims. The problem bit is

I don't know right now how to fix this.

Rik <rik5>
Project Administrator
Thu 24 Sep 2015 12:31:19 PM UTC, comment #1:

Hi,

The problem seams to be that gnuplot rearranges ytick to not display 351 tick labels by default. That is why it originally looks fine even though if you retrieve the actual ticks stored in the graphics object you'll see that there are 350 of those:

Now if you first do

Then it works in both opengl and gnuplot toolkits.

So I'd say the only issue I can see is octave not limiting the number of yticks.

Pantxo Diribarne <pantxo>
Project Member
Thu 24 Sep 2015 11:52:16 AM UTC, original submission:

Dear all,

with the following code

I see nongnuplot.pdf with the two non-gnuplot graphics toolkits and a correct plot with gnuplot toolkit. But if I add

I get a lot of warnings such as

line 0: warning: integer overflow; changing to floating point

and a final plot which resembles nongnuplot.pdf. I'm pretty sure that it worked with 3.8.1 (but cannot check now).

Marco

Marco Caliari <caliari>
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 #34972:  nongnuplot.pdf added by caliari (40KiB - application/pdf)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by lachlan (Posted a comment)
  • -unavailable- added by godfrey (Posted a comment)
  • -unavailable- added by avinoam (Posted a comment)
  • -unavailable- added by rik5 (Posted a comment)
  • -unavailable- added by pantxo (Posted a comment)
  • -unavailable- added by caliari (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 3 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Fri 25 Sep 2015 08:42:14 PM UTCrik5StatusNone=>Confirmed
      SummaryStrange labels in logarithmic plots=>Large number of axes ticks for big logarithmic plots
    Thu 24 Sep 2015 11:52:16 AM UTCcaliariAttached File-=>Added nongnuplot.pdf, #34972

    Back to the top


    Powered by Savane 3.1-cleanup1