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

 
 

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

Submitter:  Marco Caliari <caliari>
Submitted:  Thu 24 Sep 2015 11:52:16 AM UTC
   
 
Category:  Plotting Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Regression
Status:  Confirmed Assigned to:  None
Originator Name:  Open/Closed:  * Open
Release:  * 4.0.0 Operating System:  * GNU/Linux
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

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>
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>
Group 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>
Group Member
Tue 06 Oct 2015 07:51:27 PM UTC, comment #3: 

What about something like:



 if (is_logscale)
    {
      if (! (xisinf (hi) || xisinf (lo))) {
        tick_sep = 1;  // Tick is every order of magnitude (bug #39449)
        if (hi - lo > 10) {
           tick_sep = calc_tick_sep (lo, hi);
        }
      }
      else
        tick_sep = 0;
    }
  else
    tick_sep = calc_tick_sep (lo, hi);



Avinoam Kalma <avinoam>
Group 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


  if (is_logscale)
    {
      if (! (xisinf (hi) || xisinf (lo)))
        tick_sep = 1;  // Tick is every order of magnitude (bug #39449)
      else
        tick_sep = 0;
    }
  else
    tick_sep = calc_tick_sep (lo, hi);


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

Rik <rik5>
Group 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:


length (get (gca, "ytick"))
%% ->351


Now if you first do


set (gca, "ytick", 10.^(-50:50:300),'yticklabel',{'$10^{-50}$','$10^{0}$','$10^{50}$','$10^{100}$','$10^{150}$','$10^{200}$','$10^{250}$','$10^{300}$'})


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>
Group Member
Thu 24 Sep 2015 11:52:16 AM UTC, original submission:  

Dear all,

with the following code


x = (1:8);
y = 10.^(-50:50:300);
semilogy(x,y)


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


set(gca,'yticklabel',{'$10^{-50}$','$10^{0}$','$10^{50}$','$10^{100}$','$10^{150}$','$10^{200}$','$10^{250}$','$10^{300}$'})


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

 

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

Attach Files:
   
   
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
  • -email is unavailable- added by lachlan (Posted a comment)
  • -email is unavailable- added by godfrey (Posted a comment)
  • -email is unavailable- added by avinoam (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by pantxo (Posted a comment)
  • -email is unavailable- added by caliari (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 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2015-09-25 rik5 StatusNone Confirmed
        SummaryStrange labels in logarithmic plots Large number of axes ticks for big logarithmic plots
    2015-09-24 caliari Attached File- Added nongnuplot.pdf, #34972

    Back to the top

    Powered by Savane 3.13-4448.
    Corresponding source code