#581 wrong minor tics in logscale plots

None
closed-out-of-date
nobody
2D plot (258)
2016-06-13
2007-09-26
tobias
No

(version: 4.2.0, Linux debian etch)

mtics get confused on logscale plots, when giving a non-default interval for major tics. Try:

gnuplot> set logscale xy
gnuplot> set xtics 1,100
gnuplot> set mxtics 5
gnuplot> plot [1:1e7] x**2

I don't see any minor xtics at all. No number at "set mtics #" seems to have any effect.

A possibly related problem: Missing minor tics in an interval _before_ the first major tics:

gnuplot> set logscale xy
gnuplot> set xtics 1,100
gnuplot> plot [0.01:1e7] x**2

I would expect a minor xtic at x=0.1 - however, there is none.

I hope this is reproducible; yours

Tobias

Discussion

  • Hans-Bernhard Broeker

    Logged In: YES
    user_id=27517
    Originator: NO

    The problem is that pretty much any placement of minor tics other than what gnuplot already gives you as "default", would be wrong if, as in your example, the major tics are more than one decade apart. Just ask yourself: where would you put those 4 minor tics your command requested, and what good could they possibly do you in that position?

    As to the second problem: what do you base the expectation on that you should get minor tics outside the interval where you requrested major tics?

     
  • tobias

    tobias - 2007-09-27

    Logged In: YES
    user_id=1899315
    Originator: YES

    You are right, 5 is in this case a bad example - but it should be no problem to place any multiple of the distance of the Major ticks in units of decades. Thus in my example, the distance in decades is 2, hence the placing of 4, 6, 8, etc, minor ticks (i.e., in the plot, 3, 5, 7, ...) would be a desirable feature, in my opinion.

    Regarding the second point: I might have missed the real point. Please try this:
    gnuplot> set logscale xy
    gnuplot> set xtics 0.01,1.0
    gnuplot> plot [0.01:1e6] x**2

    Where are the x-tics? I don't see any. There is no problem when you give
    gnuplot> set xtics 1e-4,1e-2
    but the example from above seems to be special.

     
  • tobias

    tobias - 2007-09-27

    Logged In: YES
    user_id=1899315
    Originator: YES

    Reading the documentation again, I figured out that my second remark below actually is a feature, and not a bug ;) . Sorry! The second number in "set xtics #,#" is supposed to be a multiplicative factor, so obviously nothing happens when it is 1.

    However, since xtics still work when both numbers < 1, the program and the documentation seem not to be consistent. A more general approach would be to take the ratio of the first 2 numbers as the multiplying factor. Then the example will work, too; probably this is also the way how ## < 1 are treated.

     
  • Hans-Bernhard Broeker

    Logged In: YES
    user_id=27517
    Originator: NO

    The problem with non-default log minitics is worse than you're aware of. Let's consider the example

    set xtics 1,100
    set mxtics 10

    That requests one minor tic at 10.0. But where would the other 8 go? And how would they result manage to be both useful (i.e. no tics at positions like 10**(0.4), and still be regular subdivisions of the major tick interval. We really would have to change the entire way mxtics are determined, to be able to address this in a useful way.

    > However, since xtics still work when both numbers < 1, the program and the
    > documentation seem not to be consistent.

    They are as consistent as they can usefully be. "help xtics" explicitly allows a negative <incr> for linear scales, so it's only logical that a factor below 1 should be allowed, too.

    And no, we will *not* change the meaning of the arguments of "set xtics" at this time. It's well over 15 years too late for that.

     
  • tobias

    tobias - 2007-09-28

    Logged In: YES
    user_id=1899315
    Originator: YES

    > set xtics 1,100
    > set mxtics 10

    > That requests one minor tic at 10.0. But where would the other 8 go? And
    > how would they result manage to be both useful (i.e. no tics at positions
    > like 10**(0.4), and still be regular subdivisions of the major tick
    > interval. We really would have to change the entire way mxtics are
    > determined, to be able to address this in a useful way.

    Although not knowing the source code, I would be surprised by this, since gnuplot is able to handle less than nine mtics in one decade of a logarithmic plot.

    > They are as consistent as they can usefully be. "help xtics" explicitly
    > allows a negative <incr> for linear scales, so it's only logical that a
    > factor below 1 should be allowed, too.

    This was not my point. For me as a poor user, the way how gnuplot deals with "set xtics #,1" on a logarithmic scale is not useful.

    > And no, we will *not* change the meaning of the arguments of "set xtics"
    > at this time. It's well over 15 years too late for that.

    Once again, I wanted to point you on two aspects that are worth improving from my position as a daily user of gnuplot - a program which I do appreciate much. I'm very sorry if you feel insulted by this; I only wanted to give some useful feedback. But I will not try that again.

     
  • Ethan Merritt

    Ethan Merritt - 2009-06-01

    In preparation for eventual release of gnuplot version 4.4, existing bugs and patchsets are being re-prioritized.

    I have chosen to use the following categories

    9 - should be fixed for 4.4.rc1 if possible
    7 - should be fixed, but not high priority for 4.4.rc1
    5 - default priority for newly submitted tracker items
    2 - not important / not under active consideration

    These are my personal ratings. If you want to argue for a different priority on one or more bugs - go right ahead.

    Ethan Merritt (sfeam)

     
  • Ethan Merritt

    Ethan Merritt - 2009-06-01
    • priority: 5 --> 2
     
  • Ethan Merritt

    Ethan Merritt - 2016-06-13
    • status: open --> closed-out-of-date
    • Group: -->
    • Priority: 2 -->
     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks