Menu
▾
▴
gnuplot-beta
|
From: Hans-Bernhard B. <br...@ph...> - 2003-12-22 01:49:21
|
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)'
|
|
From: Jim V. Z. <jr...@co...> - 2003-12-23 03:04:33
|
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
|
|
From: Jim V. Z. <jr...@co...> - 2003-12-26 23:26:40
|
Hans-Bernhard Broeker <br...@ph...> wrote:
>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.
I've checked code into CVS that implements levels 0 and 1.
I've also updated my demo program at http://jrv.oddones.org/ to use
the new syntax. I'd appreciate if you would run the demo
(i.e. download http://jrv.oddones.org/transform-0.6.tar.gz, unpack,
and type "make plots").
I'll be working on the tic routines over the next few days, but will
be traveling so probably won't see any discussion until I return.
- Jim Van Zandt
|
|
From: Ethan A M. <merritt@u.washington.edu> - 2003-12-28 19:45:24
|
On Friday 26 December 2003 03:26 pm, Jim Van Zandt wrote: > > I've checked code into CVS that implements levels 0 and 1. > I'd appreciate if you would run the demo Jim: I ran into a minor issue when updating my patch for handling string data so that it would apply on top of your new code. My patch revises add_tic_user() so that it maintains the tic entries as sorted lists, allowing only one tic entry for any given axis coordinate. Your demo scripts revealed a difference between my patched version and the current behaviour, but in thinking about it I decided both were incorrect. The issue is what to do when a minor tic entry and a major tic entry both have the same coordinate. My code was keeping whichever was specified last. The current code keeps both. Either way potentially causes a problem, either by over-printing two labels at the same place or by losing a desired tic label. I modified my patch so that only the tic with the lowest "level" code is kept; i.e. major tics trump minor tics. This makes your demo scripts behave the same as on the unpatched cvs version. I *think* this is the right thing to do, but maybe someone can offer arguments for a different approach. Would there ever be explicit minor tic labels that should over-ride the [possible null] major tic labels? I don't see an easy way to even detect this condition in the current code, though. So if both major tic labels and minor tic labels are present they will print on top of each other at major tic locations. Maybe we can live with this though the next release. Or else I could break out just the sorted-tic-lists part of the datastrings patch and apply that to the cvs version sooner rather than later. What do you all think? -- Ethan A Merritt Department of Biochemistry & Biomolecular Structure Center University of Washington, Seattle |
|
From: Hans-Bernhard B. <br...@ph...> - 2003-12-29 01:01:16
|
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.
|
Thanks for helping keep SourceForge clean.
X