Menu

#10 short log axes get bad autotics

None
closed-fixed
2D plot (258)
2016-07-20
2000-06-01
No

It seems to me that in logscale axis tics computed before non-automatic ranges defined. It may be a bug or a feature...

Discussion

  • Hans-Bernhard Broeker

    A little more details seem to be needed. Please show some more
    context (input, expected output, difference to actual output).

     
  • Vitaly Lugovsky

    Vitaly Lugovsky - 2000-06-02

    Okee. Here is a .gp file:
    -----------------
    set term gif transparent
    set logscale xy
    set output "Session-10095/plot0.gif"
    set grid
    set bar 0.0
    set xtics autofreq
    set ytics autofreq
    set border 127+256+512
    plot "rq1.dat" using 1:4:2:3:5:6 notitle with xyerrorbars
    -----------
    And here is a result: http://ontil.ihep.su/~vsl/plot0.gif

    Now we'll add a following lines after 'set term':
    ---------
    set xrange [0.215664:0.375827]
    set yrange [169.684:240.891]
    -----------

    And we'll see a horrible result (with the same datafile):
    http://ontil.ihep.su/~vsl/plot2.gif

    Where is the ticks?!? It looks like gnuplot calculates them before manual range definition.

     
  • Hans-Bernhard Broeker

    Ah, now I see. That's the known problem of logarithmic axes
    spanning less than one order of magnitude. gnuplot's automatic
    tic generation mechanism doesn't expect that case, and fails miserably.
    I'm putting this on the back-burner.

     
  • Hans-Bernhard Broeker

    • assigned_to: nobody --> broeker
    • status: open --> open-later
     
  • Hans-Bernhard Broeker

    • summary: set [x/y]range strange behavior --> short log axes get bad autotics
     
  • Christopher Stone

    Logged In: YES
    user_id=254140

    If you would ever like to have some data to test fixes for
    this bug, you may use my web site here:

    http://marketorders.dyndns.org/demo/graph.php

    If/when you have test code for this bug, I will update the
    version of gnuplot on this web page so you can test it out
    using my test data.

     
  • Ethan Merritt

    Ethan Merritt - 2006-06-27

    Logged In: YES
    user_id=235620

    As part of preparing for a 4.2 release, I want to make it clear
    what is and is not still on my (sfeam) MUST DO list. This patch
    is not on that list. If you think it should be, please speak up
    quickly.

    Many of these bugs are stale and can be closed out altogether.

     
  • Ethan Merritt

    Ethan Merritt - 2006-06-27
    • priority: 5 --> 2
     
  • Ethan Merritt

    Ethan Merritt - 2016-05-27

    The data and script originally attached to this bug have been lost to bitrot, but here is a short script that captures the essence that the tics generated for a logscale axis spanning a short range could be totally noninformative.

    set logscale x
    set grid
    set xtics autofreq
    set xtics scale 3.0, 1.5
    unset ytics
    set xrange [0.15:0.41]
    set xtics 0.1
    set mxtics 10
    plot x
    

    Now finally 16 years later we have a fix in the form of a reimplementation of "set log" that divorces the axis scaling per se from the generation of tics. By default the new implementation mimics the old one, but you now have the option of fixing this by explicitly giving a reasonable tic increment, in this case:

    set xtics 0.1
    

    Furthermore user-specified minor axis tics now work reliably for logscaled axes.
    Old and new plot output from the test script is attached

     

    Last edit: Ethan Merritt 2016-05-27
  • Ethan Merritt

    Ethan Merritt - 2016-05-27
    • status: open-later --> pending-fixed
    • Group: -->
    • Priority: 2 -->
     
  • Ethan Merritt

    Ethan Merritt - 2016-07-20
    • status: pending-fixed --> closed-fixed
     

Log in to post a comment.

Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.