Re: tic marks for transformed axes

[Jim V. Z. <jr...@co...>]

Hans-Bernhard Broeker <br...@ph...> wrote:
>
>> 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 ;-)

By "reasonable" I mean "strictly monotonic".

>>  - 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).

>> 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...
>
>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.

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.
  
   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.
  
   Examples:
         set xtics ("low" 0, "medium" 50, "high" 100)
         set xtics (1,2,4,8,16,32,64,128,256,512,1024)
         set ytics ("bottom" 0, "" 10, "top" 20)
         set ytics ("bottom" 0, "" 10 1, "top" 20)
  
   In the second example, all tics are labelled.  In the third, only the end
   tics are labelled.  In the fourth, the unlabeled tic is a minor tic.

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.

>> 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.

However, it handles a lot of cases well :-)

>> 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>', 

agreed

>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!

I'll work on implementing user mini-tics with your syntax, unless
someone comes up with a better idea.

		- Jim Van Zandt