Re: tic marks for transformed axes

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

On Mon, 22 Dec 2003, Jim Van Zandt wrote:
> Hans-Bernhard Broeker <br...@ph...> wrote:

> >"Reasonable" being as subjective and volatile a quality as it is, that's
> >indeed a noble quest you've set out on ;-)
> 
> By "reasonable" I mean "strictly monotonic".

I would hope to restrict that a little further, to continuous, or even
differentiable functions. We'll have to invert those functions,
eventually, and that's a bitch to do if there are jumps in the input or
intervals where the function isn't defined...

> >>  - Don't allow tic labels to overlap.
> >
> >This is already quite hard to do, in general...
> 
> At the moment, the function uses a simple estimate.  Once it's
> integrated into gnuplot, it can use v_char and h_char.  Where that's
> not enough, maybe we could implement a user-supplied scaling
> parameter for h_char (so it would apply to all strings).

Or put to use the "guess" parameter the current algorithm already has
(currently fixed at 20, for hysterical reasons). Tell it to use fewer tics
if the font is large or the labels take up too much space.

> >> 1. Provide for user mini-tics.  Currently the user can provide tic marks
> 
> so the documentation would be something like this:
> 
>    Syntax:
>          set xtics ... ({"<label>"} <pos> {level} {,{"<label>"}...) }
>    ...
>    The explicit ("<label>" <pos> <level>, ...) form allows arbitrary tic
>    positions or non-numeric tic labels.  In this form, the tics do not
>    need to be listed in numerical order.  Each tic has a 
>    position, optionally with a label.  Note that the label is
>    a string enclosed by quotes.  It may be a constant string, such as
>    "hello", may contain formatting information for converting the
>    position into its label, such as "%3f clients", or may be empty, "".
>    See `set format` for more information.  If no string is given, the
>    default label (numerical) is used.

I'm not sure that we actually can support %3f in the label string
of an explicit tic list, right now.  If you want the number formatted into 
the label, you currently have to leave out the label string and fall back
to 'set format', as far as I'm aware.

>    An explicit tic mark has a third parameter, the "level".  The default
>    is level 0, a major tic.  A level of 1 generates a minor tic.  If the
>    level is specified, then the label must also be supplied.

No.  Something like

	set xtics (1 1, 2 1, 3 2, 4 2)

should be allowed.  If only because it's awkward to express optional
entries being coupled to each other on two sides of a non-optional one,
in the syntax short-hand.

> The only awkward part is that minor tics are signaled twice - once by
> the empty label string and again by the nonzero level.  However, it
> maintains upward compatibility, and as you say it generalizes to more
> sizes of tics.

And to labelled minors right away.

> >and 'set log x'
> >would then internally be mapped to 'set transform x log10(x)'
> 
> Okay.  My first instinct is to hold off on this last step until the
> new transformed autotic function is thoroughly tested.  On the other
> hand, using it for log plots by default will certainly exercise it
> more!

Definitely.  Getting those log-ticks to behave sensibly in the face of
round-off errors was _very_ tricky business.  Just check out all that
business about having to look at the precision of the %l part to correctly
round the %L part in a

	set format x '%5.3l * b^%L'

situation...

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.