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

[<br...@ph...>]

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
>