Re: z_floor and z_ceiling (was Re: various observations)

[Daniel J S. <dan...@ie...>]

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