Menu

#2765 misplaced mxtics/mytics on short logscale

None
closed-fixed
nobody
None
2025-06-04
2025-01-27
No

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.

1 Attachments

Discussion

  • Robin Putzar

    Robin Putzar - 2025-01-27

    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
  • Alexander Stangl

    Hey!

    I noticed the same problem (for the y axis). The commands

    set logscale y
    set ytics 10 logscale
    

    actually produces a tic at every +10 and not ×10, makes that helps to find the origin of this problem.

    Thanks,
    Alex

     
  • Ethan Merritt

    Ethan Merritt - 2025-04-30

    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.

     
    • Robin Putzar

      Robin Putzar - 2025-05-05

      Thanks for the fix!

       
  • Ethan Merritt

    Ethan Merritt - 2025-04-30
    • status: open --> pending-fixed
    • Group: -->
    • Priority: -->
     
  • Hiroki Motoyoshi

    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.

    set size 0.5,0.5
    set origin 0.2,0.1
    
    set logscale xy
    set xtics 10 nologscale
    set ytics 10 nologscale
    set mxtics 10
    set mytics 10
    
    set grid mxtics mytics lt 3
    
    set xrange [1:14]
    set yrange [0.1:1.2]
    
    plot 1-x**-3
    pause -1
    

    Regarding the change in logscale handling in version 6.0.2

    If this would be less than three ticmarks it reverts to placing a larger number of linear-spaced marks instead (+10).

    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 nologscale even 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 to nologscale can be confusing. For example, the following script may not behave as the user intended:

    set logscale xy
    set ytics 10 logscale
    set xtics 10 logscale 
    
    set grid
    
    set xrange [5:500] 
    set yrange [5:500]
    plot x              ### too many marks
    pause -1
    
    set xrange [0.05:5] 
    set yrange [0.05:5]
    plot x              ### no mark
    pause -1
    

    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.

     
    • Ethan Merritt

      Ethan Merritt - 2025-05-02

      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

       
      • Hiroki Motoyoshi

        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?

        • autologscale: Switches between logscale and noloscale based on the number of major tics (default)
        • logscale: Forces logarithmic tics
        • nologscale: Forces additive (linear) tics
         
  • Ethan Merritt

    Ethan Merritt - 2025-05-02

    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.

     
  • Ethan Merritt

    Ethan Merritt - 2025-06-04
    • Status: pending-fixed --> closed-fixed
     

Log in to post a comment.