plotting same date with 2 different scales
Bruce Dennison
scale in degrees F. I am having difficults get the two scales to match
up. I asume you have to do something like this:
set ytic nomirror
set y2tic
plot 'data' u 1:2, 'data' u 1:($2*1.8+32) axis x1y2
I can't get the scales to match. Any ideas?
Dave Denholm
> I need to plot the same data with 1 scale in degree C and the other
> scale in degrees F. I am having difficults get the two scales to match
> up. I asume you have to do something like this:
>
> set ytic nomirror
> set y2tic
> plot 'data' u 1:2, 'data' u 1:($2*1.8+32) axis x1y2
Looks reasonable.
>
> I can't get the scales to match. Any ideas?
>
The problem is that the y ranges adjust themselves after a plot
to be a whole number of ticks. The readjustment will be done
differently, independtly, for the two axes.
Setting the ranges explicitly would probably do it.
Unfortunately, that's currently hard to automate.
[there is a writeback option on the yrange, which sets the
calculated range back into the yrange setting. But I don't
think you can then read that from a gnuplot script to set the
y2 range
]
Hans-Bernhard Broeker
> I need to plot the same data with 1 scale in degree C and the other
> scale in degrees F. I am having difficults get the two scales to match
> up.
This is a bit difficult, currently, because gnuplot doesn't expect you to
chain two axes together, in this way. It treats all axes as independent,
instead.
> I asume you have to do something like this:
> set ytic nomirror
> set y2tic
> plot 'data' u 1:2, 'data' u 1:($2*1.8+32) axis x1y2
No. This will autoscale both axes independently, which you don't want.
In all but the very latest development versions, you'll have to do this, instead:
CtoF(degrees) = degrees*1.8 + 32
set yrange [x1 : x2]
set y2range [CtoF(x1) : CtoF(x2)]
set ytics nomirror
set y2tics
p 'data' u 1:2
You have to use fixed ranges, because otherwise, you'll end up with
problems caused by the extension of autoscaled axes to the next
multiple of the tic step size. In a later version of gnuplot you'll
be able to turn this auto-extension off, to make this easier. We may
even add a 'coupled axes' feature, if I find the time to code it.
--
Hans-Bernhard Broeker (bro...@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.
Ethan Merritt
Hans-Bernhard Broeker <bro...@physik.rwth-aachen.de> wrote:
>
>In all but the very latest development versions, you'll have to do this:
>
> CtoF(degrees) = degrees*1.8 + 32
> set yrange [x1 : x2]
> set y2range [CtoF(x1) : CtoF(x2)]
> set ytics nomirror
> set y2tics
> p 'data' u 1:2
>
>You have to use fixed ranges, because otherwise, you'll end up with
>problems caused by the extension of autoscaled axes to the next
>multiple of the tic step size.
I have a related problem.
I want to label my x axis in both eV and in Angstroms.
The procedure you suggest above does not work for me in either 3.7.1 or
in Version 3.8c patchlevel pm3d 6 with updates from CVS.
Here's the problem:
gnuplot> A(x) = 12398. / x
gnuplot> set xrange[ 8000. : 15000. ]
gnuplot> set x2range[ A(8000.) : A(15000.) ]
gnuplot> show xrange
set xrange [8000.00 : 15000.0] noreverse nowriteback
gnuplot> show x2range
set x2range [1.54975 : 0.826533] noreverse nowriteback
So the reported xranges match up correctly. But when I actually plot
something, it becomes obvious that the x2 axis is being treated as an
evenly spaced linear function, whereas it should be linear with respect
to 1/x1 as defined in the function A(x). So although the two ends of the
axis are labeled correctly, all intermediate tics are incorrect.
Is there a clean way to fix this? I know how to set tic labels
manually, but these plots are auto-generated dynamically and it would
be so much nicer not to have to run auxilliary calculations just to
create a file of appropriate x2 tic labels.
If there's no way in the current gnuplot model, would there be enough
interest for it to be worth adding an option something like
'set funcscale x2 = A(x)' analogous to the existing 'set logscale x'?
--
Ethan A Merritt
Hans-Bernhard Broeker
> The procedure you suggest above does not work for me in either 3.7.1 or
> in Version 3.8c patchlevel pm3d 6 with updates from CVS.
> Here's the problem:
> gnuplot> A(x) = 12398. / x
This is the problem. The procedure I describe only works for *linear*
mappings between the two axes. For nonlinear coupling, the extension
you propose would be necessary. I've come up with the same proposal,
recently.
> If there's no way in the current gnuplot model, would there be enough
> interest for it to be worth adding an option something like
> 'set funcscale x2 = A(x)' analogous to the existing 'set logscale x'?
Interest, yes. But apparently no spare time or will on anyone's hands
to actually do it, at the moment.
Dave Denholm
> Ethan Merritt <mer...@u.washington.edu> wrote:
>
> > The procedure you suggest above does not work for me in either 3.7.1 or
> > in Version 3.8c patchlevel pm3d 6 with updates from CVS.
> > Here's the problem:
> > gnuplot> A(x) = 12398. / x
>
> This is the problem. The procedure I describe only works for *linear*
> mappings between the two axes. For nonlinear coupling, the extension
> you propose would be necessary. I've come up with the same proposal,
> recently.
>
> > If there's no way in the current gnuplot model, would there be enough
> > interest for it to be worth adding an option something like
> > 'set funcscale x2 = A(x)' analogous to the existing 'set logscale x'?
>
> Interest, yes. But apparently no spare time or will on anyone's hands
> to actually do it, at the moment.
There may be a complication if there is no inverse function available.
ISTR that with logscales, gnuplot keeps converting things back and
forth between the logs (internal rep.) and the original values.
If there is no inverse function available, some of the logic may have
to change (to remember the user space values as well as the internal
values)
[But it is a while since I've looked at any gnuplot sources...]
Maybe it's good enough to require the user to specify mappings in
both directions. And if it is done in a general way, the mappings
could be specifed separately for
{func|file}->internal form, and then internal form -> first or second axes.
[ not sure if rest of gnuplot requires that internal form is linear... ]
Maybe it is good enough to just specify how internal form is mapped to
the axes, since the transformation of plot func or data to internal form can
already be specified.
Hans-Bernhard Broeker
> There may be a complication if there is no inverse function available.
> ISTR that with logscales, gnuplot keeps converting things back and
> forth between the logs (internal rep.) and the original values.
Either that, or we have to simulate the inverse mapping by numerical
methods. The mapping is usable only if it's monotonous, anyway, so
most zero-finding methods should work well, in this context.
> Maybe it's good enough to require the user to specify mappings in
> both directions.
Requiring it may be a bit too much of a limitation --- I think we'ld
be best off allowing both the function and its inverse to be given by
the user, but if the inverse isn't given, we use numerical methods,
instead.
> Maybe it is good enough to just specify how internal form is mapped to
> the axes, since the transformation of plot func or data to internal form can
> already be specified.
Something like that would be useful, indeed. It might allow to decide
somewhat implicitly when to switch over from numerically equidistant
tic steps to graphically equidistant ones, too. I.e. it could help
solve the problem we still have with auto-ticking of short-ranged
logscaled axes.
Ethan Merritt
Hans-Bernhard Broeker <bro...@physik.rwth-aachen.de> wrote:
>Dave Denholm <dave.d...@insignia.com> wrote:
>
>> There may be a complication if there is no inverse function available.
>> ISTR that with logscales, gnuplot keeps converting things back and
>> forth between the logs (internal rep.) and the original values.
>
>Either that, or we have to simulate the inverse mapping by numerical
>methods. The mapping is usable only if it's monotonous, anyway, so
>most zero-finding methods should work well, in this context.
OK, I've got a much simpler proposal that would at least take care
of part of the problem. My primary need is simply to label the axis correctly,
so I'd be satisfied by a command that mapped the tic labels through
an arbitrary function. How about something like
set x2tics func A(x)
that has the effect "whenever you were going to write a label on x2,
write A(x) instead".
Ethan
--
Ethan A Merritt
Hans-Bernhard Broeker
> an arbitrary function. How about something like
> set x2tics func A(x)
> that has the effect "whenever you were going to write a label on x2,
> write A(x) instead".
This would be simpler, indeed, but at the expense of a large drawback.
The positions of these tics would most likely be awkward, yielding all
but completely unreadable tic labels, usually. I.e. for
A(x)=12345.6/x, you most likely wouldn't find the tics at x=1, 2, 3,
4, ..., 10 very meaningful, let alone readable.
For the sake of visual clarity, it's important that ticmarks are
non-equidistantly spaced, graphically, to communicate the fact that
this is not a "standard" scale. It doesn't pay to have this expressed
by many-digit fractional numbers without any obvious rule they follow.
Internally, gnuplot needs the inverse mapping to decide about
automatic tic placement, i.e. in exactly those cases where a
hand-crafted long "set xtics" list with faked labels isn't really an
option, and thus such a coordinate transformation would be handy.
George Jefferson
:> set x2tics func A(x)
:> that has the effect "whenever you were going to write a label on x2,
:> write A(x) instead".
:
:This would be simpler, indeed, but at the expense of a large drawback.
:The positions of these tics would most likely be awkward, yielding all
It would be useful even to have just linear scale transformations.
I'm looking now at a series of plots each with a dozen curves,
(mixed funcions and external data) and I want to multiply the whole works
by 2. It would be nice if instead of modifying every line there was a
funcion to just fix the labels.
Hans-Bernhard Broeker
> It would be useful even to have just linear scale transformations.
> I'm looking now at a series of plots each with a dozen curves,
> (mixed funcions and external data) and I want to multiply the whole works
> by 2. It would be nice if instead of modifying every line there was a
> funcion to just fix the labels.
<gasp> You mean --- as in *cheating*? Bad boy! </gasp> :-)
Now, seriously: this can be done by the current versions, already, iff
you know the ranges beforehand. For autoscaling plots, you'ld need the
most recent CVS version, and even then, it'd still require changes to
the plot command to get it right, so you'ld win nothing.
George Jefferson
:<gasp> You mean --- as in *cheating*? Bad boy! </gasp> :-)
as another example, this must come up fairly often, you have a plot
which autoranges to 0,1E-10,2E-10..1E-9. I'd like the plot
labeled 1:10 and (manually) indicate the magnitude in the axis label.
It seems there should be an elegant way to do that instead of
having to modify all the data.
Hans-Bernhard Broeker
You don't have to modify the actual data --- you can filter them on-the-fly
via the "using" option:
plot datafile 1:($2/1e-10)
Another option for this particular case is to (ab)use the 'set format
y' statement:
set format y '%t'
writes only the mantissa part of the number. This could lead to
problems at one of the endpoints, though.