Menu
▾
▴
Re: z_floor and z_ceiling (was Re: various observations)
|
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
|
