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

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

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