Recent changes to 2864: logscale issue in tics

#2864 logscale issue in tics

2026-03-25T17:18:21.813000Z

Yes, the behavior has changed since version 5. User feedback (a.k.a. "bug reports") suggested revisions to the empirical rules for log tic placement. See in particular the discussion attached to Bug #2717
https://sourceforge.net/p/gnuplot/bugs/2717/

Some users feel strongly that there must be at least three major (i.e. labeled) tic marks in order to make it immediately apparent that the axis is log-scaled. The output from 5.4 on plot #2 has only two labeled tic marks. In this particular case close inspection of the unlabeled minor tic marks does help with visual recognition of log scaling. In other cases the minor tics were less helpful or even incorrect.

Other possibly relevant bug reports that resulted in code revisions
https://sourceforge.net/p/gnuplot/bugs/2372
https://sourceforge.net/p/gnuplot/bugs/2856/

There is always room for improvement, and retaining or at least allowing backwards compatibility with earlier gnuplot versions is a priority, So perhaps we could add or tweak something to allow the user to force the old version 5 logscale tic placement. I'll think about it. For example set ytics nolog forces linear placement (increment is additive rather than multiplicative) but set ytics log is not forcing; it is interpreted as meaning "use the default log tic placement" and allows the program to in fact revert to linear placement in accordance with the default empirical rules. Probably these command would better have been set ytics {no}linear but it's too late for that.

#2864 logscale issue in tics

2026-03-25T15:21:21.973000Z

Group: -->
Priority: -->

#2864 logscale issue in tics

2026-03-25T14:44:20.044000Z

This behavior is different from that in the previous version (at least v5.4 as I used before, see the right panel of the figure attached).

"ytics" ignored the "logscale" parameter - the tic interval was supposed to be interpreted as a multiplicative factor rather than a constant.

Would like to clarify if this is a new feature or a bug? Thanks!

gnuplot> set log y
gnuplot> set yrange [5:1e2]
gnuplot> set ytics 10,10,1e3 logscale
gnuplot> set mytics 10
gnuplot> p x

#2864 logscale issue in tics

2026-03-25T00:16:38.210000Z

Both plots show log scaling on y. The difference you notice is probably the choice of where to place major tics (labeled) vs minor tics (unlabeled).

The program tries to choose a reasonable set of major and minor axis tics based on the total range. When placing log scaled major tics it currently uses heuristics like "there must be at least 3 but preferably not more than 10 major tics; do not place more than 10 minor tics between major tics; if the range would hold only 1 major tic promote the minor tics to major (labeled) status". Your pair of ranges demonstrates hitting one or another of these limiting cases.

People have different, conflicting, opinions on the best choice of tic placement and labels. The program tries to pick something reasonable but it can't match everyone's preference. By the same token, I am not sure what you were expecting for the second plot. If you add a command
set ytics 10,10,100
it would force the same choice of major tics as used in the first plot, but for this total range they would all be crammed into the upper half of the figure. Maybe you prefer that. In extreme cases you can specify a full set of labeled tics explicitly
set ytics (1,2,5,10,20,50,100)
or whatever your preference is.

logscale issue in tics

2026-03-24T22:05:01.041000Z

Using version 6.0.2, logscale is not recognized for tics when the axis range limits are not exact powers of 10.

gnuplot> set log y
gnuplot> set yrange [5:100]
gnuplot> p x
gnuplot> set yrange [1:100]
gnuplot> p x

logscale issue in tics

2026-03-24T22:05:01.041000Z

Ticket 2864 has been modified: logscale issue in tics
Edited By: zcy (zcycat)