Menu
▾
▴
gnuplot-beta
|
From: Daniel J S. <dan...@ie...> - 2006-05-10 00:48:05
Attachments:
normal.png
|
OK, since SourceForge CVS seems to be working, somewhat, I'm trying the latest software and attempting some plot types I hadn't really used before. Some observations:
1) Is the CVS synched with what developers have checked in? If so, there is still a problem with arrow style parsing, i.e., arrowstyle.dem fails:
turn to continue
plot '1.dat' using 1:2:(+1):(+1) with vectors lt 4 filled title 'filled', '2.dat' using 1:2:(+1):(+1) with vectors lt 1 heads title 'double-headed', '2.dat' using ($1):(2-$2/3):(+1):(+.5) with vectors lt -1 lw 3 nohead title 'no head'
^
"arrowstyle.dem", line 91: ';' expected
2) 3D plot layout is definitely the thing most in need of work post 4.2. The default colorbox seems too big and out of place. The x-y plane position seems slightly limited. Let me give an example to illustrate a few things. The following is meant to show a zero mean, unit variance Gaussian r.v. density. The contour is supposed to represent the variance in some way, and there are supposed to be a set of Gaussian samples with zero mean, unit variance.
set hidden3d
set contour
set isosamples 60
set view 68, 28, 1, 1
unset key
unset title
set cntrparam levels discrete 0.1
set style line 1 linecolor rgb "black"
set term x11 2
set parametric
set xrange [-5:5]
set yrange [-5:5]
set urange [-5:5]
set vrange [-5:5]
set xyplane at -0.2
splot u,v,( 1/(2*pi) * exp(-0.5 * (u**2 + v**2)) ) with line ls 1, \
sqrt(-2*log(rand(0)))*cos(2*pi*rand(0)),sqrt(-2*log(rand(0)))*sin(2*pi*rand(0)),-0.2 with points pointtype 7 linecolor rgb "black"
My intent was to have the points on the x-y plane and drop the x-y plane to leave enough space that the surface plot doesn't obstruct the points. Using the "set xyplane #" just didn't seem to get me there. The axes would remain the same and the x-y plane would extend off the plot, which just seemed silly.
Then "set xyplane at -0.2" and setting the z-value of the points to -0.2 puts the points and x-y plane in the same plane, but notice that the line of the z-axis still extends down to where the xyplane used to be. (That's a bug, isn't it? Or am I missing something?) Consequently, the plot isn't using the space efficiently.
3) It sure is annoying going through the trouble of looking up in "test" (x11) the number of the symbol desired, and then the symbol comes out differently in the output file (png). Regardless of the different symbols from one output terminal to another, I find it so confusing, because looking at "test" as a PNG output the "7" is actually a solid symbol, but not in this example (see attached "normal.png"). Also, is it OK to use "linecolor rgb "black" to control symbol color as I did? Actually, I'd think that the "linecolor", "pointtype" is an extraneous syntax. Couldn't it just be "points type 7 color rgb "black""? Or in the case of lines, "lines type 1"?
4) In a related category would be contours. I wanted to force the contours to be all of the same color, in this case black. That doesn't seem possible.
5) In the example, I really only want about 25 samples. IS THERE SOME WAY TO CONTROL THIS? Setting the samples # doesn't seem to effect this. Ethan has an example where he assigns a dozen or two random numbers but that is based off the number of samples in a data file, i.e., "using 1:2:rand(0)".
6) Would anyone object to a patch for a math function "randn()" generating unit variance normal distribution random values using the Box-Mueller method? The last line of the above example constitutes the polar method; it would just save a lot of typing in generating normal r.v.s.
Dan
|
|
From: Ethan M. <merritt@u.washington.edu> - 2006-05-10 01:45:30
|
On Tuesday 09 May 2006 05:56 pm, Daniel J Sebald wrote: > > 1) Is the CVS synched with what developers have checked in? No. 6 weeks out of date and a lot of water under the bridge. > If so, there is still a problem with arrow style parsing No. Fixed (6-delta) weeks ago. > 2) 3D plot layout is definitely the thing most in need of work post 4.2. > The default colorbox seems too big and out of place. So change it. You don't have to use the default if you don't like it. > The x-y plane position seems slightly limited. Works fine for me. > The axes would remain the same and the x-y plane would extend off the plot, > which just seemed silly. ??? I don't understand. You set the intersection of the plane with the Z axis at -0.2, and that's where it is drawn. What did you expect? > Then "set xyplane at -0.2" and setting the z-value of the points to -0.2 > puts the points and x-y plane in the same plane, but notice that the > line of the z-axis still extends down to where the xyplane used to be. > (That's a bug, isn't it? Or am I missing something?) Um. I don't know. For me the z-axis extends to span the range currently set by "set zrange". That has nothing in particular to do with where the xyplane is currently set. > 3) It sure is annoying going through the trouble of looking up > in "test" (x11) the number of the symbol desired, > and then the symbol comes out differently in the output file (png). User error. If you want to know what the png symbols look like, test them with the png driver. > Regardless of the different symbols from one output terminal to another, > I find it so confusing, because looking at "test" as a PNG output the "7" > is actually a solid symbol, but not in this example (see attached "normal.png"). That's just because of the limited resolution. I don't think we can do anything about that. > Also, is it OK to use "linecolor rgb "black" to control symbol color as I did? Sure, if you want. Or "lt -1". > 4) In a related category would be contours. > I wanted to force the contours to be all of the same color, in this case black. > That doesn't seem possible. Yes it is. You just have to specify a specific color (lc rgb "blue") rather than a linetype. If you give a linetype, it autoincrements as it draws each contour. > 5) In the example, I really only want about 25 samples. > IS THERE SOME WAY TO CONTROL THIS? set isosamples 25, 25 > 6) Would anyone object to a patch for a math function "randn()" > generating unit variance normal distribution random values using > the Box-Mueller method? Other than generating demo plots, is there really a need? -- Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle WA |
|
From: Daniel J S. <dan...@ie...> - 2006-05-10 03:23:14
|
Ethan Merritt wrote:
>>The x-y plane position seems slightly limited.
>
>
> Works fine for me.
>
>
>>The axes would remain the same and the x-y plane would extend off the plot,
>>which just seemed silly.
Somehow I generated an x-y plane which landed outside the plot area. Can't seem to reproduce that now.
>
>
> ???
> I don't understand. You set the intersection of the plane with
> the Z axis at -0.2, and that's where it is drawn. What did you expect?
No, initially I tried something like "set xyplane 0.7" or something.
>
>
>>Then "set xyplane at -0.2" and setting the z-value of the points to -0.2
>>puts the points and x-y plane in the same plane, but notice that the
>>line of the z-axis still extends down to where the xyplane used to be.
>>(That's a bug, isn't it? Or am I missing something?)
>
>
> Um. I don't know. For me the z-axis extends to span the range
> currently set by "set zrange". That has nothing in particular
> to do with where the xyplane is currently set.
Well, that seems to work as expected, i.e., the range as described by the little tic marks. It's that "x-y plane drop down line", and oddly only for the one on the z-axis. The other three are the correct length.
>
>>3) It sure is annoying going through the trouble of looking up
>>in "test" (x11) the number of the symbol desired,
>>and then the symbol comes out differently in the output file (png).
>
>
> User error.
> If you want to know what the png symbols look like,
> test them with the png driver.
>
>
>>Regardless of the different symbols from one output terminal to another,
>>I find it so confusing, because looking at "test" as a PNG output the "7"
>>is actually a solid symbol, but not in this example (see attached "normal.png").
>
>
> That's just because of the limited resolution.
> I don't think we can do anything about that.
Oy, this is a PNG thing. Take a look at the difference between these plots.
set term png
set output 'plot.png'
plot x**2 with points pointtype 7 linecolor rgb "black"
set output 'plot2.png'
plot x**2 with points pointtype 7
set output
When PNG has a dot as the same color as a line or point it lands on, the dot is drawn hollow. Not sure how that helps the visual effect.
>>Also, is it OK to use "linecolor rgb "black" to control symbol color as I did?
>
> Sure, if you want. Or "lt -1".
Actually, lt -1 is a black line with a thickness greater than usual. The surface plots look bad with such a thick line.
>
>
>>4) In a related category would be contours.
>>I wanted to force the contours to be all of the same color, in this case black.
>>That doesn't seem possible.
>
>
> Yes it is. You just have to specify a specific color (lc rgb "blue")
> rather than a linetype. If you give a linetype, it autoincrements
> as it draws each contour.
I can't seem to do this. I see in "show cntrparam" that
contour line types are varied & labeled with format '%8.3g'
suggesting that line types can be controlled. But the documentation doesn't show how to set this. Hmm, this seems to fall under "clabel". Why would color be under that? Anyway, the documentation says
The first contour linetype, or only contour linetype when clabel is off, is
the surface linetype +1; contour points are the same style as surface points.
but again no indication of how to change that behavior. Would it be either of these:
set cntrparam linear lc rgb "black"
set clabel '' lc rgb "black"
This might be a good thing to add to "contours.dem".
>
>
>>5) In the example, I really only want about 25 samples.
>>IS THERE SOME WAY TO CONTROL THIS?
>
>
> set isosamples 25, 25
This causes a surface with isolines of 25 by 25. Well, I meant that I want to have the higher resolution isolines (60), but only 25 outcomes of a multivariate Gaussian. But I gather that this works by generating a random value for every point in the grid, i.e., 25 x 25 points. Now, that behavior is one I would say makes the rand function (at least on its own) really only good for demos... Oh, hold on here...
OK, it can be done. The "table" method will allow first creating the random data in a file than reading it back. This just about does it:
set hidden3d
set contour
set view 68, 28, 1, 1
unset key
unset title
set cntrparam levels discrete 0.1 lc rgb "black"
set style line 1 linecolor rgb "black"
set term x11 2
set parametric
set xrange [-4:4]
set yrange [-4:4]
set zrange [-0.2:0.2]
set urange [-4:4]
set vrange [-4:4]
set xyplane 0
set isosamples 5,5
set table "temp.dat"
splot sqrt(-2*log(rand(0)))*cos(2*pi*rand(0)),sqrt(-2*log(rand(0)))*sin(2*pi*rand(0)),-0.2
unset table
set isosamples 60
splot u,v,( 1/(2*pi) * exp(-0.5 * (u**2 + v**2)) ) with line ls 1, \
"temp.dat" with points pointtype 7 linecolor rgb "black"
>
>
>>6) Would anyone object to a patch for a math function "randn()"
>>generating unit variance normal distribution random values using
>>the Box-Mueller method?
>
>
> Other than generating demo plots, is there really a need?
Sure. I want to generate a plot illustrating a Gaussian mixture model, which means a lengthy polar transform equation for each of the components of the mixture. It's far fetched that someone would use gnuplot for simulations. But for quickly generating little illustrations in physics, communications, stats, etc. Gaussian distributions pop up fairly often.
Dan
|
|
From: Daniel J S. <dan...@ie...> - 2006-05-10 03:32:13
|
Daniel J Sebald wrote: > OK, it can be done. The "table" method will allow first creating the > random data in a file than reading it back. This just about does it: Oh, but "set isosamples <#>,1" will not work. I want a prime number of random points. ;-) Dan |
|
From: Daniel J S. <dan...@ie...> - 2006-05-14 00:43:26
|
>>Then "set xyplane at -0.2" and setting the z-value of the points to -0.2 >>puts the points and x-y plane in the same plane, but notice that the >>line of the z-axis still extends down to where the xyplane used to be. >>(That's a bug, isn't it? Or am I missing something?) I put a bug report and patch on S.F. for this. Try set xyplane at -20 splot x+y before and after patch. (I see HBB sort of nearby this stuff, with dates from way back.) Dan |
|
From:
<br...@ph...> - 2006-05-14 14:43:08
|
Daniel J Sebald wrote: > I put a bug report and patch on S.F. for this. Try > > set xyplane at -20 > splot x+y > > before and after patch. There's a bug there alright, but I don't think the patch is going in the right direction. The real problem is the mismatch between the user interface presented by set.c:set_ticslevel() and the actual internal data structure t_xyplane. > (I see HBB sort of nearby this stuff, with dates from way back.) Not really to be wondered about. I put such comments in the source wherever I see something dubious going on, or where the intent of a piece of code isn't immediately clear, and I initial them to make sure people know who to get back to about them. I don't see any of those particularly close to the xyplane stuff, though, and none of them relating to it. |
|
From: Daniel J S. <dan...@ie...> - 2006-05-14 18:17:27
|
Hans-Bernhard Br=F6ker wrote:
> Daniel J Sebald wrote:
>=20
>> I put a bug report and patch on S.F. for this. Try
>>
>> set xyplane at -20
>> splot x+y
>>
>> before and after patch.
>=20
>=20
> There's a bug there alright, but I don't think the patch is going in th=
e=20
> right direction. The real problem is the mismatch between the user=20
> interface presented by set.c:set_ticslevel() and the actual internal=20
> data structure t_xyplane.
The patch sort of makes sense. THere is a variable for controlling wheth=
er the xyplane is "absolute" or not. If absolute, then it is the min(pla=
neval,ZAXIS.min), if not it is related to the % value.
>=20
>> (I see HBB sort of nearby this stuff, with dates from way back.)
>=20
>=20
> Not really to be wondered about. I put such comments in the source=20
> wherever I see something dubious going on, or where the intent of a=20
> piece of code isn't immediately clear, and I initial them to make sure=20
> people know who to get back to about them. I don't see any of those=20
> particularly close to the xyplane stuff, though, and none of them=20
> relating to it.
Well, it's near the point where the lines are actually drawn, so one degr=
ee of indirection I guess.
Anyway, I sat thinking about the documentation for the ticslevel/xyplane =
stuff for the longest time. First, I somehow accomplished to get the xyp=
lane far off of the plot with the "ticslevel %" approach. I couldn't exa=
ctly understand the difference for values alpha > 1 and values 0 < alpha =
< 1. Then the "xyplane at #" approach resulted in this bug you see. Tha=
t is why I initially wrote to the list to inquire about whether this was =
a bug a bug or not. (Then there was the "drop down lines" sometimes draw=
ing, sometimes not problem. I see a new CHangeLog entry by Ethan for som=
ething related to that.)
Now that I reread the documentation, I guess I agree with you that the do=
cumentation is a not good.
First, I find the +/- convention to be a possible source of confusion. T=
hat is,
set xyplane +#
puts the xyplane in the negative z hemisphere
set xyplane -#
puts the xyplane in the positive z hemisphere. I would think that having=
it the other way around (with -0.5 as the default) would be a better mem=
ory aid.
Go back to the original unpatched version and try
set term x11 1
set xyplane +1
splot x+y
set term x11 2
set xyplane -1
splot x+y
I may not be thinking of this correctly, but I'd say that the above two e=
xamples are not consistent. Should the "set xyplane -1" also have a big =
blank area past the *positive* extreme of the z-axis now?
And this comment in the doc:
To place the xy-plane at a position 'pos' on the z-axis, `ticslevel` may
be set equal to (pos - zmin) / (zmin - zmax). However, this position w=
ill
change if the z range is changed.
Scratch that. It may be true, but there is an "at #" version of the comm=
and. Don't encourage people to use a linear translation. If someone wan=
ts to go through that extra work, let them devise the translation on thei=
r own.
Lastly, let's go to the wishlist realm. I see what the plot looks like w=
ith
set xyplane at -20
splot x+y
set xyplane at 20
splot x+y
and I then imagine what it would look like to have *both* of those planes=
present, i.e., all the axes/borders of a box.
Now, this may be possible to do with "set border". However, this documen=
tation doesn't give the right answer:
Draw a complete box around a `splot`:
set border 4095
That doesn't seem to work. And one last off-hand smarmy comment:
Draw a topless box around a `splot`, omitting the front vertical:
set border 127+256+512 # or set border 1023-128
Eeeww! Here is the syntax:
Bit plot splot
1 bottom bottom left front
2 left bottom left back
4 top bottom right front
8 right bottom right back
16 no effect left vertical
32 no effect back vertical
64 no effect right vertical
128 no effect front vertical
256 no effect top left back
512 no effect top right back
1024 no effect top left front
2048 no effect top right front
In hindsight, it would have been nice to have the following:
plot splot
syntax meaning meaning
------ ------- -------
blf bottom/left bottom left front
blk bottom/left bottom left back
brf bottom/right bottom right front
brk bottom/right bottom right back
tlf top/left top left front
tlk top/left top left back
trf top/right top right front
trk top/back top right back
lb bottom/left left bottom vertical
lt top/left left top vertical
rb bottom/right right bottom vertical
rt top/right right top vertical
fb bottom front bottom vertical
ft top front top vertical
kb bottom back bottom vertical
kt top back top vertical
bl bottom/left blf+blk
br bottom/right brf+brk
bf bottom blf+brf
bk bottom blk+brk
tl top/left tlf+tlk
tr top/right trf+trk
tf top tlf+trf
tk top tlk+trk
b bottom blf+blk+brf+brk
t top tlf+tlk+trf+trk
l left lb+lt (left vertical)
r right rb+rt (right vertical)
f * fb+ft (front vertical)
k * kb+kt (back vertical)
bottom b b
top t t
left l l
right r r
front f f
back b b
btlr b+t+l+r b+t+l+r (memory aid "butler")
all btlr btlr
The above still represents 16 line segments, so the above strings could b=
e stored as a table with an associated 16 bit number. (They probably wou=
ldn't be the same numbers as the current assignment, because I think ther=
e are some conflicts there. E.g.,
4 top bottom right front
means "top" in one context, "bottom" in another. But the two syntaxes co=
uld still exist if we simply write the 1, 2, 4, 8, 16, etc. as strings wi=
th an associated number as well.)
Dan
|
|
From: Daniel J S. <dan...@ie...> - 2006-05-14 18:59:48
|
Daniel J Sebald wrote: (They probably > wouldn't be the same numbers as the current assignment, because I think > there are some conflicts there. E.g., > > 4 top bottom right front > > means "top" in one context, "bottom" in another. But the two syntaxes > could still exist if we simply write the 1, 2, 4, 8, 16, etc. as strings > with an associated number as well.) On second thought, that wouldn't work because we need to allow for the number to be anything, e.g., 3... Oh, it could still be done fairly easily. Dan |
|
From:
<br...@ph...> - 2006-05-15 14:58:32
|
Daniel J Sebald wrote:
> Hans-Bernhard Bröker wrote:
>> Daniel J Sebald wrote:
[...]
> The patch sort of makes sense. THere is a variable for controlling
> whether the xyplane is "absolute" or not.
And there are *two* float variables, only one of which is controllable
by the user, at any given time, but both have effect on the result.
That's clearly wrong. The patch is wrong because it doctors symtoms of
this bug, instead of fighting the disease.
> xyplane far off of the plot with the "ticslevel %" approach. I couldn't
> exactly understand the difference for values alpha > 1 and values 0 <
> alpha < 1.
Actually, the three important classes for the ticslevel parameter are:
1) [0:*] --> baseplane below the graph quboid.
2) [-1:0] --> baseplane inside the quboid
2> [*:-1] --> baseplane on top of the quboid --- this may well fail
completely.
Yes, the coordinate direction for "ticslevel" is -z, not +z --- but that
shouldn't be too hard to grasp for anyone brave enough to touch the
insides of a program doing 3D computer graphics ;-)
> Now that I reread the documentation, I guess I agree with you that the
> documentation is a not good.
And the reason for that is that the behaviour of the code makes no
sense. Writing correct docs for crazy code would be pointless.
> puts the xyplane in the positive z hemisphere. I would think that
> having it the other way around (with -0.5 as the default) would be a
> better memory aid.
Maybe. But we're limited by backwards compatibility here. The
coordinate system for 'set xyplane <level>' is open for discussion, but
that for the original command 'set ticslevel' is not.
> I may not be thinking of this correctly, but I'd say that the above two
> examples are not consistent. Should the "set xyplane -1" also have a
> big blank area past the *positive* extreme of the z-axis now?
No, because 'ticslevel -1' is just the upper end of the actual z range,
i.e. it makes base_z = ceiling_z.
But 'set xyplane -2' should.
> set xyplane at -20
> splot x+y
>
> set xyplane at 20
> splot x+y
>
> and I then imagine what it would look like to have *both* of those
> planes present, i.e., all the axes/borders of a box.
Not quite. That's what the implementation of 'set {x|y}tics mirror'
and/or secondary x and y axes in an splot will be about --- if somebody
ever writes one.
|
|
From: Daniel J S. <dan...@ie...> - 2006-05-15 17:01:20
|
Hans-Bernhard Br=F6ker wrote:
> Daniel J Sebald wrote:
>=20
>> Hans-Bernhard Br=F6ker wrote:
>>
>>> Daniel J Sebald wrote:
>=20
>=20
> [...]
>=20
>> The patch sort of makes sense. THere is a variable for controlling=20
>> whether the xyplane is "absolute" or not. =20
>=20
>=20
> And there are *two* float variables, only one of which is controllable=20
> by the user, at any given time, but both have effect on the result.=20
> That's clearly wrong. The patch is wrong because it doctors symtoms of=
=20
> this bug, instead of fighting the disease.
Please explain more. Are you simply saying there is no need for two valu=
es in the xyplane array because the value is set, by requirement, for bot=
h "set xyplane #" and "set xyplane at #"? That's true.
> Yes, the coordinate direction for "ticslevel" is -z, not +z --- but tha=
t=20
> shouldn't be too hard to grasp for anyone brave enough to touch the=20
> insides of a program doing 3D computer graphics ;-)
"brave"? Are you using that in the euphemistic sense? (I'll take it.)
>> puts the xyplane in the positive z hemisphere. I would think that=20
>> having it the other way around (with -0.5 as the default) would be a=20
>> better memory aid.
>=20
>=20
> Maybe. But we're limited by backwards compatibility here. The=20
> coordinate system for 'set xyplane <level>' is open for discussion, but=
=20
> that for the original command 'set ticslevel' is not.
>=20
>> I may not be thinking of this correctly, but I'd say that the above=20
>> two examples are not consistent. Should the "set xyplane -1" also=20
>> have a big blank area past the *positive* extreme of the z-axis now?
>=20
>=20
> No, because 'ticslevel -1' is just the upper end of the actual z range,=
=20
> i.e. it makes base_z =3D ceiling_z.
Right, I see that now. I was not think of this correctly. My idea of th=
e "anchor" point was not zmin. Perhaps wording the doc and the following=
rewriting of the formula would help:
pos =3D zmin + <frac> (zmin - zmax)
Yes, I think I'd have prefered the polarity of the fraction be switched a=
round, i.e.,
pos =3D zmin + <frac> (zmax - zmin).
At this point though, changing the polarity might just confuse matters.
> But 'set xyplane -2' should.
Yup. Thanks.
>> and I then imagine what it would look like to have *both* of those=20
>> planes present, i.e., all the axes/borders of a box.
>=20
>=20
> Not quite. That's what the implementation of 'set {x|y}tics mirror'=20
> and/or secondary x and y axes in an splot will be about --- if somebody=
=20
> ever writes one.
OK, that would be another valid way to do that.
(In the remainder of that text I had written about a proposal for segment=
s of the border; you'll notice that the vertical lines were treated as tw=
o segments, one part above the plotted surface, one part below the plotte=
d surface, attempting to be similar to the way the ticslevel works.)
Dan
|
|
From:
<br...@ph...> - 2006-05-15 23:46:50
|
Daniel J Sebald wrote: > Hans-Bernhard Bröker wrote: >> And there are *two* float variables, only one of which is controllable >> by the user, at any given time, but both have effect on the result. >> That's clearly wrong. The patch is wrong because it doctors symtoms >> of this bug, instead of fighting the disease. > Please explain more. Are you simply saying there is no need for two > values in the xyplane array because the value is set, by requirement, > for both "set xyplane #" and "set xyplane at #"? That's true. Yes. And once that's cleaned up, the code using those variables, *and* the documentation, will quite likely end up being simpler than both the current code or your proposed patch. > Right, I see that now. I was not think of this correctly. My idea of > the "anchor" point was not zmin. Perhaps wording the doc and the > following rewriting of the formula would help: > > pos = zmin + <frac> (zmin - zmax) Actually, the simplest explanation is probably the best here: just state that ticlevels 0 and -1 correspond to the bottom and top of the z axis (_not_ the min and max, actually --- z axis can be reversed!), and that the coordinate moves linearly. > At this point though, changing the polarity might just confuse matters. This is not a question of what "might" happen. The polarity in the 'set ticslevel' parameter will not change, period. I won't have script compatibility compromised. What can be discussed is whether we should split up the old 'set ticslevel' and its alias, 'set xyplane <level>'. These two could have different scales. > (In the remainder of that text I had written about a proposal for > segments of the border; you'll notice that the vertical lines were > treated as two segments, one part above the plotted surface, one part > below the plotted surface, attempting to be similar to the way the > ticslevel works.) The interpretation of the vertical line aspect of 'set border' in 3D plots is admittedly quite crazy. You get some verticals you can control through 'set border', and others you can't (those from the base to the uppermost corner points, which only get drawn if a data point actually sits exactly in the corner). If control for these is provided as yet another new feature, it might be better suited as part of 'set xyplane', rather than 4 more bits to contrl by 'set border' --- that one's cramped enough as it is. > > Dan > |
|
From: Daniel J S. <dan...@ie...> - 2006-05-16 00:08:12
|
Hans-Bernhard Br=F6ker wrote: > Daniel J Sebald wrote: > >> Please explain more. Are you simply saying there is no need for two=20 >> values in the xyplane array because the value is set, by requirement,=20 >> for both "set xyplane #" and "set xyplane at #"? That's true. >=20 >=20 > Yes. And once that's cleaned up, the code using those variables, *and*= =20 > the documentation, will quite likely end up being simpler than both the= =20 > current code or your proposed patch. Oh, I see what you are saying. I can fix the patch up for that fairly ea= sily I think; tomorrow or the next day. >=20 >> Right, I see that now. I was not think of this correctly. My idea of= =20 >> the "anchor" point was not zmin. Perhaps wording the doc and the=20 >> following rewriting of the formula would help: >> >> pos =3D zmin + <frac> (zmin - zmax) >=20 >=20 > Actually, the simplest explanation is probably the best here: just=20 > state that ticlevels 0 and -1 correspond to the bottom and top of the z= =20 > axis (_not_ the min and max, actually --- z axis can be reversed!), Aye! Yes, well then: "The position on the z_axis is then pos =3D z_bottom + <frac> (z_bottom - z_top) where z_bottom may be a positive or negative value." I just did the math quickly here and I think that still works out. Notin= g the 0, -1 relationship would be nice to. Please make it 1 though! "0 = is the bottom, -1 is the top" just throws my world all topsy turvy. :-) = Seriously, what I meant by confusion is that ticslevel having the negati= ve value and xyplane the positive value would be the confusion... confusi= on I could live with. >> (In the remainder of that text I had written about a proposal for=20 >> segments of the border; you'll notice that the vertical lines were=20 >> treated as two segments, one part above the plotted surface, one part=20 >> below the plotted surface, attempting to be similar to the way the=20 >> ticslevel works.) >=20 >=20 > The interpretation of the vertical line aspect of 'set border' in 3D=20 > plots is admittedly quite crazy. You get some verticals you can contro= l=20 > through 'set border', and others you can't (those from the base to the=20 > uppermost corner points, which only get drawn if a data point actually=20 > sits exactly in the corner). If control for these is provided as yet=20 > another new feature, it might be better suited as part of 'set=20 > xyplane', rather than 4 more bits to contrl by 'set border' --- that=20 > one's cramped enough as it is. Well, the thing is it would be a more natural fit what I proposed: 16 seg= ments, 16 bits. But the big gain I think is the ability to use short abb= reviations like "blf" for "bottom/left/front" representing these bits. "= blf+tlf" has a better chance of being remembered than the numerical equiv= alents. Also the conflicting contex, e.g., 2 means top in 2D and bottom = in 3D, was a bad oversight. Dan |
|
From: Daniel J S. <dan...@ie...> - 2006-05-20 06:48:49
|
Hans-Bernhard Br=F6ker wrote:
> Actually, the simplest explanation is probably the best here: just=20
> state that ticlevels 0 and -1 correspond to the bottom and top of the z=
=20
> axis (_not_ the min and max, actually --- z axis can be reversed!), and=
=20
> that the coordinate moves linearly.
>=20
>> At this point though, changing the polarity might just confuse matters.
>=20
>=20
> This is not a question of what "might" happen. The polarity in the 'se=
t=20
> ticslevel' parameter will not change, period. I won't have script=20
> compatibility compromised. What can be discussed is whether we should=20
> split up the old 'set ticslevel' and its alias, 'set xyplane <level>'.=20
> These two could have different scales.
OK people, any preference as to xyplane (not 'ticslevel') having bottom o=
f zrange as 0 and top of zrange as 1?
Right now, as the code exists, 'xyplane' and 'ticslevel' are synonyms. T=
hat is "set ticslevel at -10" is valid even though the documentation indi=
cates that this is possible:
Syntax:
set ticslevel <frac>
set xyplane <frac>
set xyplane at <zvalue>
show xyplane
Should "set ticslevel at <zvalue>" be allowed? If not, then it is probab=
ly best to have enumerations of S_TICSLEVEL and S_XYPLANE, because there =
really isn't a nice way to determine what syntax cause the program to arr=
ive at the point in the case statement otherwise.
Dan
|
|
From: Daniel J S. <dan...@ie...> - 2006-05-20 06:53:08
|
Daniel J Sebald wrote: > OK people, any preference as to xyplane (not 'ticslevel') having bottom > of zrange as 0 and top of zrange as 1? That is should top of zrange be 1 or -1 for 'xplane'? > > Right now, as the code exists, 'xyplane' and 'ticslevel' are synonyms. > That is "set ticslevel at -10" is valid even though the documentation > indicates that this is possible: *does not indicate* that this is possible. > > Syntax: > set ticslevel <frac> > set xyplane <frac> > set xyplane at <zvalue> > show xyplane Dan |
|
From:
<br...@ph...> - 2006-05-20 10:05:22
|
Daniel J Sebald wrote: > OK people, any preference as to xyplane (not 'ticslevel') having bottom > of zrange as 0 and top of zrange as 1? I would prefer to keep things as they are. I think the possible benefit of flipping this sign around is too small to warrant the confusion this is likely to cause among users. If the current behaviour isn't easy to understand from existing documentation, I say fix the documentation, not the behaviour. > Should "set ticslevel at <zvalue>" be allowed? I don't really care. This command in a script would have caused a syntax error in all earlier versions of gnuplot, so it can be added without causing compatibility problems. OTOH, 'set ticslevel' is arguably the single worst option name gnuplot ever had, so it's probably not a good idea to add things to it. |
|
From: Daniel J S. <dan...@ie...> - 2006-05-20 15:18:32
|
Hans-Bernhard Br=F6ker wrote: > Daniel J Sebald wrote: >=20 >> OK people, any preference as to xyplane (not 'ticslevel') having=20 >> bottom of zrange as 0 and top of zrange as 1? >=20 >=20 > I would prefer to keep things as they are. I think the possible benefi= t=20 > of flipping this sign around is too small to warrant the confusion this= =20 > is likely to cause among users. OK, easy change if you want to try things the other way before the next r= elease. > If the current behaviour isn't easy to understand from existing=20 > documentation, I say fix the documentation, not the behaviour. >=20 >> Should "set ticslevel at <zvalue>" be allowed? =20 >=20 >=20 > I don't really care. This command in a script would have caused a=20 > syntax error in all earlier versions of gnuplot, so it can be added=20 > without causing compatibility problems. OTOH, 'set ticslevel' is=20 > arguably the single worst option name gnuplot ever had, so it's probabl= y=20 > not a good idea to add things to it. I can disallow that... Other things to note about "ticslevel": There ha= sn't been a bug report for the bad behavior of the z-axis line so that mi= ght mean it isn't used too often. "unset xyplane", wouldn't we expect th= at to remove the xyplane altogether? For example "unset xtics" removes t= he xtics. What may have been nice from the start would be to force set/show/reset t= o come as a structure with three functions. (Or maybe four, set/unset/sh= ow/reset.) The use of "reset xtics", "reset xyplane" wouldn't be ambiguo= us the way "unset xtics", "unset xyplane" might be. Dan |
|
From:
<br...@ph...> - 2006-05-21 11:55:12
|
Daniel J Sebald wrote: > I can disallow that... Other things to note about "ticslevel": There > hasn't been a bug report for the bad behavior of the z-axis line so that > might mean it isn't used too often. It might equally well mean that other users don't consider it all that buggy. Reading minds of people you don't even know exist is not really possibly. > "unset xyplane", wouldn't we expect that to remove the xyplane > altogether? No. I would expect that to be refused by the parser, given that it's not listed in 'help xyplane'. Whatever 'unset xyplane' does besides causing an error message, is an undocumented feature, i.e. a bug. > For example "unset xtics" removes the xtics. And is documented to do so. > What may have been nice from the start would be to force set/show/reset > to come as a structure with three functions. (Or maybe four, > set/unset/show/reset.) Absolutely, except that there should actually be five, but they should be 'reset/set/unset/show/save'). If I had the time to do it these days, I would have. If you want to try that, you have all my blessings. |
|
From: Daniel J S. <dan...@ie...> - 2006-05-22 02:01:33
|
Hans-Bernhard Br=F6ker wrote:
> Daniel J Sebald wrote:
>=20
>> I can disallow that... Other things to note about "ticslevel": There=
=20
>> hasn't been a bug report for the bad behavior of the z-axis line so=20
>> that might mean it isn't used too often. =20
>=20
>=20
> It might equally well mean that other users don't consider it all that=20
> buggy. Reading minds of people you don't even know exist is not really=
=20
> possibly.
>=20
>> "unset xyplane", wouldn't we expect that to remove the xyplane
>=20
> > altogether?
>=20
> No. I would expect that to be refused by the parser, given that it's=20
> not listed in 'help xyplane'. Whatever 'unset xyplane' does besides=20
> causing an error message, is an undocumented feature, i.e. a bug.
>=20
> > For example "unset xtics" removes the xtics.
>=20
> And is documented to do so.
I will disallow "unset xyplane" for now in the patch, unless you think "u=
nset xyplane" should be documentated instead.
>> What may have been nice from the start would be to force=20
>> set/show/reset to come as a structure with three functions. (Or maybe=
=20
>> four, set/unset/show/reset.) =20
>=20
>=20
> Absolutely, except that there should actually be five, but they should=20
> be 'reset/set/unset/show/save'). If I had the time to do it these days=
,=20
> I would have. If you want to try that, you have all my blessings.
Maybe post 4.2. That change will be fairly easy (because the compiler wi=
ll complain about any problem with structure entries), but it is sort of =
a destablizing change for a while. (Plus a patch like that could only go=
a couple days without hunks being rejected.)
So, that would get rid of all the S_TICLEVELS, S_XAXIS, etc. (which will =
be nice). The struct would be something like
{
"xyp$lane",
reset_xyplane,
set_xyplane,
unset_xyplane,
show_xyplane,
save_xyplane
};
And then maybe a short little routine to dump the string of set options, =
not exceeding 80 chars, to remove having to manually plut the option name=
in that text string.
Dan
|
|
From: Daniel J S. <dan...@ie...> - 2006-05-22 03:01:15
|
Also, an observation--which isn't specifically clarified in "set xrange" documentation--is that currently (tilde means congruence, for lack of better term): "set zrange [20:-20]" ~ "set zrange [-20:20] reverse" ~ "set zrange [20:-20] reverse" I assume that is the way it is supposed to be (i.e., double reverse means reverse... as in Spanish, double negative is still negative). An alternate would be "set zrange [-20:20]" ~ "set zrange [20:-20] reverse" Dan |
|
From:
<br...@ph...> - 2006-05-22 09:11:25
|
Daniel J Sebald wrote: > Hans-Bernhard Bröker wrote: > I will disallow "unset xyplane" for now in the patch, unless you think > "unset xyplane" should be documentated instead. I think I would slightly prefer it to be documented as a no-op. |
|
From: Ethan A M. <merritt@u.washington.edu> - 2006-05-10 06:08:19
|
On Tuesday 09 May 2006 10:38 pm, Ethan A Merritt wrote: > On Tuesday 09 May 2006 10:20 pm, Daniel Sebald wrote: > > my version of the PNG library creats hollow points even when > > they land inside the plot. (See plot.) > > Indeed. Mine too. > I have no idea why, but the bug must be in libgd. Heh. Actually, it's not a libgd bug. The circle is filled using a "fill to border" command, where the border color is the circle. But if the center of the current circle happens to already have that color, as for instance if there is another overlapping filled circle there already, then "fill to border" is a no-op. I can think of several workarounds for this, but I'm not sure what the cleanest is. Maybe draw the circle first in some junk color, fill to *that* border, and then re-trace in the real color? -- Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle 98195-7742 |
|
From: Ethan A M. <merritt@u.washington.edu> - 2006-05-10 06:20:43
|
On Tuesday 09 May 2006 11:08 pm, Ethan A Merritt wrote: > > I can think of several workarounds for this, but I'm not > sure what the cleanest is. Maybe draw the circle first > in some junk color, fill to *that* border, and then > re-trace in the real color? Not worth it. Recent versions of libgd have a gdImageFilledArc() function instead. I'll just use that and let older installations (gd version < 2) live with the bug. After all, it's been that way for 5 years already. -- Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle 98195-7742 |
|
From: Ethan A M. <merritt@u.washington.edu> - 2006-05-20 20:21:16
|
On Saturday 20 May 2006 12:01 am, Daniel J Sebald wrote: > > OK people, any preference as to xyplane (not 'ticslevel') having bottom > > of zrange as 0 and top of zrange as 1? > That is should top of zrange be 1 or -1 for 'xplane'? I was not following this thread, and now that I look back through it I don't understand what the issue really is. I never did understand 'set ticslevel', but whatever it did should stay that way for backwards compatibility. The idea behind 'set xyplane <foo>' is [supposed to be] obvious: Whatever zrange is, whatever way round the axes are pointing, yadda yadda, draw the place so that it intersects the z axis at <foo>. Have you found some case where this doesn't happen? -- Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle 98195-7742 |
|
From: Daniel J S. <dan...@ie...> - 2006-05-20 20:48:37
|
Ethan A Merritt wrote: > On Saturday 20 May 2006 12:01 am, Daniel J Sebald wrote: > >>>OK people, any preference as to xyplane (not 'ticslevel') having bottom >>>of zrange as 0 and top of zrange as 1? >> >>That is should top of zrange be 1 or -1 for 'xplane'? > > > I was not following this thread, and now that I look back through > it I don't understand what the issue really is. > > I never did understand 'set ticslevel', but whatever it did should > stay that way for backwards compatibility. > > The idea behind 'set xyplane <foo>' is [supposed to be] obvious: > Whatever zrange is, whatever way round the axes are pointing, > yadda yadda, draw the place so that it intersects the z axis > at <foo>. Have you found some case where this doesn't happen? But unless you've mis-typed, you have that wrong... and this is an example of the source of confusion. 'set xyplane *at* <foo>' does as you explain, and that works just as advertised. The problem is the "percentage of z-axis" form, i.e., the non "at" form, the form for which the actual values on the z-axis do not matter; rather the user wants the xyplane to be somewhere relative to the z-axis visually. Somehow we are trying to make a linear number range represent that concept. Some logical choices would be bottom top z-axis z-axis value value ------ ------ 0 -1 (current) 0 +1 (I think more intuitive) -1 0 (just as intuitive I guess) +1 0 (no) -1 +1 (maybe *this* is the most intuitive choice) +1 -1 (no way!) My point in all this is that I have no qualms about someone wanting axis values to be increasing in one direction or the other (I've seen things plotted many ways and for various reasons), but when we step one level back and speak of the axis relatively, the convention is increasing to the right, increasing up I would think. As it stands, 0/-1 is the way non-at 'xyplane' is going to be for consistency with 'ticslevel'. "ticslevel at <foo>" will not be allowed. Dan |
|
From: Ethan A M. <merritt@u.washington.edu> - 2006-05-20 22:27:55
|
On Saturday 20 May 2006 01:57 pm, Daniel J Sebald wrote: > Ethan A Merritt wrote: > > I never did understand 'set ticslevel', but whatever it did should > > stay that way for backwards compatibility. > > > > The idea behind 'set xyplane <foo>' is [supposed to be] obvious: > > Whatever zrange is, whatever way round the axes are pointing, > > yadda yadda, draw the plane so that it intersects the z axis > > at <foo>. > > 'set xyplane *at* <foo>' does as you explain, and that works just as advertised. > > The problem is the "percentage of z-axis" form, i.e., > the non "at" form, the form for which the actual values on the z-axis do not matter; > rather the user wants the xyplane to be somewhere relative to the z-axis visually. Then let's just get rid of the "no at" form for 'set xyplane'. I don't see a need for it. With Petr's patch to export GPVAL_Z_MIN and GPVAL_Z_MAX, you can accomplish the same thing by saying set xyplane at func(GPVAL_Z_MIN,GPVAL_Z_MAX) -- Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle 98195-7742 |
