Re: [Gnuplot-info] logscale and autoscale improvement (was logscale and manual range setting?)

[Hans-Bernhard B. <br...@ph...>]

Jim Kleckner wrote:
> It would be nice to have the autoscale logic be able to
> handle the scaling to waste less space, I think.  

The case you stumbled on is quite particular.  The data yrange is
[1-epsilon:4.0]  This drives autoscaling for log axis exactly into its 
worst-case scenario.

1) the input range is scarcely one decade long
2) it's positioned uncomfortably, with one end point scarcely below a
    natural tic position.
3) it's a logarithmic axis.

Item 2) means that the autoscaled range will be extended beyond that
power-of-ten.  Throwing data points off the plot (like 'set yrange 
[1:10]' does it in this case), is strictly a non-option for the 
automatic behaviour of gnuplot.  You can turn off this extension, at the 
risk of getting rather ugly ranges.  See "help autoscale"; the 'fix' 
options.

Item 3) means that the extension cannot currently be shorter than one
full unit in logarithm (i.e. a factor of 10) --- that's why the 
autoscaled range ends up being [0.1:10].  The core limitation here is 
that gnuplot still has no way ofcontinuously changing from the only 
sensible ticking pattern for long log axes (labelled, graphically 
equidistant major tics, unlabelled, arithmetically equidistant tics in 
between) to the only sensible one for very short axes (labelled, 
arithmetically equidistant tics).

The fact that the additional is perceived to be creating such a huge
"waste" of plot space is because of item 1).  In the essence, you're in 
violation of an old lemma of scientific plotting: "He who uses a 
logarithmic axis spanning less than two decades is rather probably 
trying to brush some embarrasing detail under the carpet."

> How hard do you think it would be to start/end the axis
> on a minitic rather than a major tic if too large a
> fraction of the range is wasted?

Starting the axis on a minitic is IMHO not the right solution.  Lifting 
the limitation that in log axes only at integer powers of the base can 
currently be major tics is what really needs tackling.  While at it, 
other axis re-mappings than pow()/log() should be made possible.

Unfortunately, that'd end up in having to essentially re-write the 
entire autoticking stuff from scratch.  James Van Zandt made a proposal 
for that a long time ago, but it never made it into serious discussion, 
let alone the CVS code.