Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

short Z-scale for splot

556 views
Skip to first unread message

Dushan Mitrovich

unread,
Feb 18, 2004, 5:07:05 PM2/18/04
to
I'm using ver. 3.7.1 compiled for OS/2. It's been working fine, but there
is one aspect I haven't figured out how to control.

Using splot to plot a 2-variable function, the visible Z-axis height is
invariably smaller than seems natural to me, and than I would like to see.
With 'set view ,,,3' I can expand that scale, but then the upper part of
the plot is clipped off. For example, if the actual vertical range of Z
is [9:15], I have to specify (having 'set ticslevel 0')

splot [..] [..] [9:22] function(x,y)

in order to see the top of the plot. Yet the Z-axis tics are correctly
labeled, going from 9 to 16. It looks like this 'set view' instruction
isn't behaving according to my expectations.

What is the proper way to control the vertical aspect ratio of a plot?

Thanks.

- Dushan Mitrovich

Hans-Bernhard Broeker

unread,
Feb 20, 2004, 11:44:27 AM2/20/04
to
Dushan Mitrovich <an...@spamming.org> wrote:

> Using splot to plot a 2-variable function, the visible Z-axis height is
> invariably smaller than seems natural to me,

It's quite impossible for others here to know what may "seem natural"
to you. Please keep in mind that gnuplot is a data plotting program,
not a CAD application. Among other things, that means we care more
about making good use of available space on the output page / window
than about making the scaling factors of all three axes the same.

It might be the command you're really looking for is

set ticslevel 0

> It looks like this 'set view' instruction isn't behaving according
> to my expectations.

And until you explain what those expectations are, nobody can
meaningfully help you.

--
Hans-Bernhard Broeker (bro...@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

Dushan Mitrovich

unread,
Feb 20, 2004, 2:56:25 PM2/20/04
to
Hans-Bernhard Broeker <bro...@physik.rwth-aachen.de> wrote:

`Dushan Mitrovich <an...@spamming.org> wrote:
`
`> Using splot to plot a 2-variable function, the visible Z-axis height is
`> invariably smaller than seems natural to me,
`
` It's quite impossible for others here to know what may "seem natural"
` to you. Please keep in mind that gnuplot is a data plotting program,
` not a CAD application. Among other things, that means we care more
` about making good use of available space on the output page / window
` than about making the scaling factors of all three axes the same.
`
` It might be the command you're really looking for is
`
` set ticslevel 0
`
`> It looks like this 'set view' instruction isn't behaving according
`> to my expectations.
`
` And until you explain what those expectations are, nobody can
` meaningfully help you.

Okay, fair enough, here's more detail.

First, I'm already using 'set ticslevel 0' exactly as shown to set the
ticslevel plane height, and that part is working fine - this was already
mentioned in my original post.

Second, even after the ticslevel is set as above, and the 'set view' is
left at default, the 'splot' plot has an overall height that is only about
40% of the overall width ('overall' means including the axes tic labels),
and a 'graph' Z-height that is only ~25% of the XY-plane spread (whose
diagonal is essentially horizontal). For the same X- and Z-ranges, the
length of a unit along Z is about half the length along X (the Y-range is
1/3rd of the X- and Z-ranges, so the comparison is only slightly distorted
by perspective).

My expectations are that the default overall vertical spread of a plot
should be comparable with, or a bit less - say 3/4 - of its horizontal
spread, rather than the 2/5 that I'm seeing. In fact, this 2/5 aspect
ratio doesn't change as I vary the screen window proportions; the plot
size simply increases or decreases to accomodate the limiting horizontal
or vertical window dimension.

In my original efforts I used the following command

set ticslevel 0
splot [-6:0] [-1:1] [9:15] LOGsig(x,y)

and noticed not only that if Z-range [9:15] is left unchanged, using 'set
view ,,,F' between these instructions (where 'F' is a scale factor) clips
the upper part of the graph, but also that the scaling is far from propor-
tional to the factor 'F'.

Recently I had better success with a different tack. Instead of incorpo-
rating the Z-range within the splot command, I placed it separately as
follows

set ticslevel 0
set zrange [9:15]
splot [-6:0] [-1:1] LOGsig(x,y)

This did not much alter the initial aspect ratio of the plot, but inser-
ting the statement 'set view ,,,F' now really did scale the Z-axis propor-
tionally to 'F'. The choice F=1.5 worked well, but F=2 again clipped the
upper end of the plot. The Z-tics were expanded correctly, tho the actual
vertical line representing the axis was no longer drawn (a minor problem).

Is this sufficient detail to focus on the problem?

- Dushan Mitrovich

Hans-Bernhard Broeker

unread,
Feb 20, 2004, 6:09:34 PM2/20/04
to
Dushan Mitrovich <an...@spamming.org> wrote:

> Second, even after the ticslevel is set as above, and the 'set view' is
> left at default, the 'splot' plot has an overall height that is only about
> 40% of the overall width ('overall' means including the axes tic labels),
> and a 'graph' Z-height that is only ~25% of the XY-plane spread (whose
> diagonal is essentially horizontal).

The default 'set view' is rotated around two axes, by different
angles. Are you sure that reading off lengths from this non-isometric
projection can make any sense whatsoever?

> My expectations are that the default overall vertical spread of a plot
> should be comparable with, or a bit less - say 3/4 - of its horizontal
> spread, rather than the 2/5 that I'm seeing.

The page space usage of 3D plots is optimized for something you
apparently haven't considered doing so far: rotating the plot. Try
the 'animate.dem' demo script some time to see the effect. We're
keeping enough space to not have to modify the scaling of the 3D graph
box as it's rotated.

You're also using version 3.7.1, which has been replaced by 3.7.3 a
bit more than a year ago. There were bugs with the clipping of plots
that had unusually large z_scale factors (the last argument of "set
view"), IIRC, so you may see improvement by updating.

Dushan Mitrovich

unread,
Feb 21, 2004, 2:39:03 AM2/21/04
to
Hans-Bernhard Broeker <bro...@physik.rwth-aachen.de> wrote:

`Dushan Mitrovich <an...@spamming.org> wrote:
`
`> Second, even after the ticslevel is set as above, and the 'set view' is
`> left at default, the 'splot' plot has an overall height that is only about
`> 40% of the overall width ('overall' means including the axes tic labels),
`> and a 'graph' Z-height that is only ~25% of the XY-plane spread (whose
`> diagonal is essentially horizontal).
`
` The default 'set view' is rotated around two axes, by different angles.
` Are you sure that reading off lengths from this non-isometric projection
` can make any sense whatsoever?

Yes, I am. Recall that I noted that the amount of distortion introduced
was slight.

`> My expectations are that the default overall vertical spread of a plot


`> should be comparable with, or a bit less - say 3/4 - of its horizontal
`> spread, rather than the 2/5 that I'm seeing.
`
` The page space usage of 3D plots is optimized for something you
` apparently haven't considered doing so far: rotating the plot. Try
` the 'animate.dem' demo script some time to see the effect. We're
` keeping enough space to not have to modify the scaling of the 3D graph
` box as it's rotated.

Does it rotate around the vertical axis? Anyway, I'll try it to see what
happens.

` You're also using version 3.7.1, which has been replaced by 3.7.3 a


` bit more than a year ago. There were bugs with the clipping of plots
` that had unusually large z_scale factors (the last argument of "set
` view"), IIRC, so you may see improvement by updating.

Okay, that's a good point. Actually, with your recent announcement of
version 4.0 soon to come out, maybe I should wait for that. OTOH, I'd
need a binary compiled for OS/2, and that may take a bit longer to appear.

In any case, thanks for the suggestions.

- Dushan Mitrovich

0 new messages