Re: [Plplot-devel] Added API for a plsurf3d variant (plsurf3dl) which implements non-rectangular index limits.

[Rafael L. <rla...@us...>]

* Alan W. Irwin <ir...@be...> [2004-05-09 12:23]:

> That tabale above clearly shows the problem. There are at least two options
> here for the limit.  In one, the limit is a discontinuous step function even
> for your simple example above. So between x = 0. and 1. you want the y limit
> to be 3., between x = 1. and 2. you want the limit to be 2. etc.  Another
> option is you would want a smooth limit like you have suggested above
> (perhaps adjusted upward by a half unit so it never wanders into the
> undefined region.) Eventually, if we do go with a defined function approach
> we would want it general enough so either type of limit could be used.

Well, remember that the "defined" function is, by its very nature,
completely arbitrary and the user can implement it in the way she wants.  In
particular, the "real ragged" boundary that you are proposing above (which I
find quite strange, by the way) can be trivially implemented in a specific
"defined" function.

> I think if somebody in the future wanted to make the effort it is possible
> they could change over to the "defined" type of approach that you are
> recommending, but it is not trivial.  One problem to be overcome is research
> examples are not as simple as your hypothetical case. The boundaries are
> complicated in general so they would have to be described by a whole series
> of y limits depending on the x value (both for the "discontinuous" and
> "smooth" limits described above). So in the general case you would have to
> look up the appropriate x range for your x value in a table, then find the y
> range for that x range, then fill to the limit.

In this case, just implement the defined function as a table lookup.  So
what?

> (You would also have to programme the case where the x limits were a
> function of y since the meaning of the fast and slow indices in plsurf3dl
> is swapped between x and y depending on azimuth).

I did not quite understand your statement.  With the use of the defined
function, there is no need to defined which coordinate x or y is a function
of which other.  Remember that both x and y are arguments of defined, and
the user can do whatever she wants with the values.

> the "defined" approach should be possible.  However,it is a lot of
> additional programming effort that I would not want to do myself.

The bits of code for doing it are already in plshade.c (I wrote them).  I
did not look at the code of plsurf3d, but it should be feasible. Of course,
I am not asking you to do it...  At any rate, the resulting plot would look
much nicer and I think it would be a great improvement to PLplot.  Take a
look at:

    http://people.debian.org/~rafael/plplot/x08-exclusion.ps

This is how the plot in x08 would look like with a defined function.  Would
that suit your EOS research paper?

> If somebody wanted to take this project on in the future, I should mention
> there is an additional complication that has to be dealt with. The table of
> x ranges and corresponding y ranges are "user" data that varies from one
> calculation to the next. Probably the most general way to communicate that
> data to defined is to add a PLPointer to the argument list of defined, and
> also add a corresponding PLPointer defined_data argument to your proposed
> argument list for the plsurf variation that will come after mine.
> 
> (It's a separate issue, but I should mention that Maurice has recommended
> this generalization of the defined API for the plshade and plshades case,
> and some day we should deal with that issue as well.)

Yes, I thought about this as well.  This idea is already implemented for the
transformation function argument (pltr) of the plshade* API routines and an
extension to the defined function is totally feasible.

-- 
Rafael