[Vitaly Lugovsky]

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

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

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.

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.

• assigned_to: nobody --> broeker
• status: open --> open-later

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

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.

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.

• priority: 5 --> 2

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