Menu
▾
▴
gnuplot-beta
|
From: Hans-Bernhard B. <br...@ph...> - 2005-05-08 13:52:26
|
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.
|
|
From: Jim K. <je...@kl...> - 2005-05-09 19:02:19
|
Hans-Bernhard Broeker wrote: > 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." It would be great if all of my financial returns exceeded a decade or two! :) Unfortunately, the natural way to look at compounded returns is logarithmic and the noisy nature of the information can cause a dip below the starting value giving an extra decade at the bottom end and sometimes just above a decade at the top end. >> 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. It sounds like perhaps a function on the outside to detect this particular situation and set the manual range is the way to go. Many thanks for your insight. Jim |
|
From:
<br...@ph...> - 2005-05-10 07:34:25
|
Jim Kleckner wrote: > Hans-Bernhard Broeker wrote: > It sounds like perhaps a function on the outside to detect this > particular situation and set the manual range is the way to go. Or use set autoscale yfix and live with strange endpoints. That still won't get you useful tickmarks, though --- You'll eventually have to either choose a very small logarithm base, like set log y 1.1 (one labelled tick every 10%), or generate the tic positions outside gnuplot. |
|
From: James R. V. Z. <jr...@co...> - 2005-05-22 02:17:34
|
Hans-Bernhard Broeker <br...@ph...> wrote: >> 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. I worked out a pretty good algorithm for selecting major and minor tic locations for axes transformed by any continuous and either strictly increasing or strictly decreasing function, such that: - tic labels are "simple" - tic labels do not overlap - the distances between tics are roughly equal - the numeric value corresponding to any minitic is unambiguous - the distances between minitics are roughly equal, and small enough that the numeric value of any point can be estimated by eye. You can find standalone demo code and a couple of example plots at http://jrv.oddones.org. I need help integrating this into gnuplot - e.g. - choosing command syntax for declaring a transformed axis - command parsing - evaluating the transformation function for chosen points - displaying both major and minor tics at arbitrary locations (I found the user could choose locations for major tics but not minor tics) - maintaining the current log axis algorithm in parallel, and allowing the user to choose either for now. It's been two years since I worked on this. - Jim Van Zandt |
