From: Alan W. Irwin <irwin@be...>  20040509 19:31:00

On 20040509 18:40+0200 Rafael Laboissiere wrote: > * Alan W. Irwin <irwin@...> [20040509 08:38]: > > > No. :) I agree both have a sharp boundary, but the edge limits required in > > the EOS field (and others) are expressed as integer indexes which > > necessarily are quantized and therefore the edges look rough. While the > > defined function in plshade(s) is a PLINT (*defined) (PLFLT, PLFLT) with > > floating point arguments whose limits therefore look smooth. > > I can hardly believe that your quantized indices cannot be expressed as a > smooth, floating point boundary function. For instance, if you have the > following domain in your EOS problem: > > y=3 + + + + > y=2  + + + > y=1   + + > y=0    + > x=0 x=1 x=2 x=3 > > where "" means excluded and "+" means included, then the following > "defined" function would do the job: > > PLINT > defined (PLFLT x, PLFLT y) > { > return (y >= x + 3); > } > > Using this function with the hypothetical plsurf3dx function that I proposed > in my last post, would produce a nice 3d surface plot with a boundary around > the origin that would be an elegant straight line connecting the points > (x,y) = (0,3) anf (x,y) = (3,0). Instead of rectangular patches, we would > have triangular ones, like those produced by plshades. 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. > > I am quite positive that my proposal is suitable for your EOS problem, or > are we still talking different languages? :) 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. (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). Anyhow, I agree with you the "defined" approach should be possible. However,it is a lot of additional programming effort that I would not want to do myself. 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.) In sum, my judgment is using the "defined" approach for the plsurf... case is possible but it is nontrivial and therefore something we will want to deal with in the future. Meanwhile, the current plsurf3dl should satisfy a clear research need that we didn't satisfy before. Alan __________________________ Alan W. Irwin email: irwin@... phone: 2507272902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the PLplot scientific plotting software package (plplot.org), the Yorick frontend to PLplot (yplot.sf.net), the Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project (lbproject.sf.net). __________________________ Linuxpowered Science __________________________ 