Re: tic marks for transformed axes

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

On Sat, 20 Dec 2003, Jim Van Zandt wrote:

> 
> At present, gnuplot only knows about linear and log axes, and with a
> log axis only the powers of 10 are labeled.  

Powers of the logarithm base, to be precise.  Try 'set log x 2.0'
once in a while...  But in general, you're right.  See my long-open
bug report "short log axes get bad autotics" on SF.

> I'd like to generalize this, at least for the equivalent of "probability
> paper" and "weibull plots", and preferably for any reasonable
> user-supplied function. 

"Reasonable" being as subjective and volatile a quality as it is, that's
indeed a noble quest you've set out on ;-)

>  - Don't allow tic labels to overlap.

This is already quite hard to do, in general.  Note that for quite a
subset of drivers, including the entire PostScript and TeX family, gnuplot
has no real idea at all how large a given tic label is actually going to
be on output.

> 1. Provide for user mini-tics.  Currently the user can provide tic marks
> with a command like
>   set ytics ("bottom" 0, "" 10, "top" 20) 
> 
> However, only full size tic marks can be generated by this mechanism.
> I propose a patch below that will generate a minitic for a null label
> "".  The user can still get a full size tic with no label by putting
> one or more spaces in the label string.

While I do like the general idea of allowing user-placed minitics, I
strongly dislike that syntax.  Making a distinction between '' and ' '
is bound to counter-intuitive to almost every single non-guru user of
gnuplot out there.

Here's a possible alternative, which would also allow for a possible
extension to more than 2 kinds of tics in the future:

	set xtics ("bottom" 0 0, "" 10 0, "" 13 2, \
                   "here" 14 1, "top" 20)

which would express that there are labelled major (level-0) tics at
0 and 20, an unlabelled major at 10, an unlabelled sub-minor tic at 13,
and a labelled minor tic (level 1)  at 14.

> I propose that this part (only) be integrated into gnuplot version 4.0.

> The algorithm is more complicated than I like, but I could not get any
> of the simpler things I tried to work.  There are still some cases
> that don't come out right.

I supsected as much, having fought with the time/date variety of this
problem a while ago, and having tried to solve the "generalized axis
mapping" problem.

The best I could come up with was to have the user specify a
transformation function from plotted values to some artificial scale, then
use an improved version of the normal, linear auto-ticking algorithm on
that axis.  Whenever the auto-ticking algorithm working on the transformed
scale determines an interval smaller than, say, 1.0, or a user-choosable
threshold, tics would be placed equidistant in the real coordinates, 
per integer interval of the transformed scale.  That'd imitate what the
current logscaled autoticking in gnuplot docs, but extend sensibly to
short-range log axes and hopefully to transformed axes, too.

> I propose leaving "logscale" alone, but adding a "transform" option to
> xtics as follows:
> 
>        set xtics {axis | border} {{no}mirror} {{no}rotate {by <ang>}}
>                  {  autofreq
>                   | <incr>
>                   | <start>, <incr> {,<end>}
>                   | ({"<label>"} <pos> {,{"<label>"} <pos>}...)
>                   | transform <function> }
>                  { font "name{,<size>}" }
>                  { textcolor <colorspec> }

No. If we do add axis transformation, it really must be applied not only
to the tics, but to the plotted data, too, so this option has no business
hiding itself under the coat of 'set xtics'.  This really should become a
new command 'set transform {x|y|x2|y2|z|c} <function>', and 'set log x'
would then internally be mapped to 'set transform x log10(x)'