The placement of minor tics is not working correctly in gnuplot 6.0.2 for logscales with small amount of major tics. The following script reproduces the error:
set terminal pngcairo
set grid xtics mxtics ytics mytics
set output 'error.png'
set xrange [1:14]
set logscale x
set xtics 10 logscale
set mxtics 10
set yrange [0.1:1.2]
set logscale y
set ytics 10 logscale
set mytics 10
plot 1-x**-3
set output
reset
gnuplot 6.0.1 works correctly.
I'm working on Windows 11 and using the 'gp602-win64-mingw.7z' or 'gp601-win64-mingw.7z' version, respectively.
Attached is an output of what I expect it to look like (created with gnuplot 6.0.1).
Last edit: Robin Putzar 2025-01-27
Hey!
I noticed the same problem (for the y axis). The commands
actually produces a tic at every +10 and not ×10, makes that helps to find the origin of this problem.
Thanks,
Alex
Thanks for the test case.
Fixed now in 6.1 and will be included for 6.0.3
As to the switch from x10 to +10, that is intentional. The idea is that since 6.0.2 the program checks to see how many logscale axis tics would be placed using the default algorithm. If this would be less than three ticmarks it reverts to placing a larger number of linear-spaced marks instead (+10). The bug was that it didn't properly correct the placement of minor tics to match this.
Thanks for the fix!
I observed the bug reported by the original poster may not be fully resolved yet. If the test script's
"set xtics ... logscale"is changed to"set xtics ... nologscale", a similarly broken plot is still produced. When the plot size is reduced, as in the following script, it becomes more apparent that grid lines are drawn outside the intended plot area. This behavior is also reproducible in the older version 5.2.8, so it appears to be a long-standing issue.Regarding the change in logscale handling in version 6.0.2
While I agree that switching to a non-log scale is reasonable when there is only one or no major tick mark, this might just be my perspective, forcing
nologscaleeven when there are two major tick marks might be somewhat excessive. The reason is that having at least two tick marks on a log scale is often sufficient to convey the overall structure of the axis. Moreover, since the values on the axis can differ by two to three orders of magnitude, using an additive scale may result in major tic marks becoming too dense at larger values or too sparse at smaller values.Additionally, in the case of
set xtics 10 logscale, I believe most users would interpret the increment ‘10’ to mean multiplicative steps of ×10. Automatically interpreting it as a linear increment of +10 after switching tonologscalecan be confusing. For example, the following script may not behave as the user intended:Of course, I can use “set xtics (10,100)”, but I cannot combine it with convenient minor tics placement. It would be preferable to retain the option for users who favor the traditional way of logarithmic scales.
For the "too many marks" case above, I think the recommendation would be to use
set xtics logscale 100; set mxtics
For the "no mark" case above, I think the recommendation would be
set xtics logscale 1.0; set mxtics
Hmm, that brings us back to the original discussion.
Just as an example, would it be possible to introduce a third option to the set xtics command, something like autologscale?
You are right that correct that in the case of logscale x and "set xtics nolog" the same adjustment to minor tic placement and range checks is needed as in the earlier fix. I have made that change.
As to the other examples you show, I agree that there are cases where the current behavior produces too many tick marks. But the "traditional way" produced even worse results in a bunch of other cases. See for example Bugs #2372 and #2717. That was the motivation for the original change. I feel like this is a game of whack-a-mole.
I attach a collection of problem cases from the earlier bug reports and from the current one. I think no gnuplot version to date handles all of them nicely. I'll see what I can come up with using this as a set of test cases.