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

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

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.