From: Alan W. I. <ir...@be...> - 2004-05-09 15:44:19
|
On 2004-05-09 12:01+0200 Rafael Laboissiere wrote: > * Alan W. Irwin <ir...@be...> [2004-05-08 21:59]: > > The problem I am dealing with has completely sharp non-rectangular > > boundaries. An Equation of State is calculated on some supercomputer for a > > certain non-rectangular grid of indices, but the results are completely > > undefined beyond them. The EOS programme typically fails to converge beyond > > those boundaries because the fundamental assumptions and approximations in > > the code begin to break down (especially at relatively cool temperatures and > > high densities). The consensus in this research field (and also this is how > > it is handled in the gnuplot algorithm to do the same thing) is to leave > > those boundaries sharp rather than smoothing them. The idea is to present > > the results "warts and all" without smoothing so it is clear where the > > calculation failed at the boundaries. So the present result is perfect for > > EOS research needs and presumably many other research fields where the > > consensus opinion is to present unsmoothed research results. > > > > Of course, an option for smoothing the edges could be added later on if > > somebody had a need for it and wanted to do the substantial work involved, > > but we would also would want to retain the current unsmoothed behaviour as > > well. > > I think there is a confusion here. The algorithm involving the exclusion > region in the plshades function *_does_* use a sharp boundary. This > boundary is defined by the function "defined" which is passed as an argument > of plshades. There is no smoothing at all for producing the plot, it's > "warts and all". > > Are we talking the same language? :-) 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. > All that said, if your changes do not introduce any backwards > incompatibility, I would say let us introduce it. I will do it tomorrow (Monday) (with the non-default option in the example we discussed) unless I hear further objections. Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 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 front-end to PLplot (yplot.sf.net), the Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |