From: Alan W. I. <ir...@be...> - 2004-02-16 18:14:28
|
Maurice, could you take a look at this new API to make sure everything is okay, please? That review would be a big help before we go to the effort of propagating this to the various language interfaces. Alan On 2004-02-16 10:08-0000 Andrew Ross wrote: > On Wed, Feb 11, 2004 at 04:47:20PM -0800, Alan Irwin wrote: > > On 2004-02-11 11:47-0000 Andrew Ross wrote: > > > > > > > > Just to update you, I've commited another patch to add a fill option to > > > the new plsarrow function. x22c.c now demostrate this too. There is also > > > now an equivalent C++ example x22.cc. > > > > A minor issue is the colours. For example, I believe red labels and box and > > yellow vectors on a black background would look better than the current red > > on black. > > Fixed. > > > > > The other issue is the API. The last time this was discussed on list, the > > definitive comment was Maurice's, I believe. > > > > ************* > > It would be a whole > > different API. Right now we have: > > > > void > > plarrows(PLFLT *u, PLFLT *v, PLFLT *x, PLFLT *y, PLINT n, > > PLFLT scale, PLFLT dx, PLFLT dy) > > > > I'd change this to input 2 quantities (Ax_ij, Ay_ij) using the usual function > > evaluator approach. I think a single function pointer but different client > > data for each is sufficient. I'd drop the dx,dy stuff and instead have it > > do a pre-pass to determine what the maximum vector length should be so that > > vectors don't overlap, taking into account possible coordinate > > transformations. Then the internal entry point would look something like: > > > > plvecf_int(PLFLT (*plf2eval) (PLINT, PLINT, PLPointer), > > PLPointer plf2eval_data1, PLPointer plf2eval_data2, > > PLINT (*defined) (PLFLT, PLFLT, PLPointer), > > PLPointer defined_data, > > PLINT nx, PLINT ny, PLFLT scale, > > void (*pltr) (PLFLT, PLFLT, PLFLT *, PLFLT *, PLPointer), > > PLPointer pltr_data); > > > > where defined() here includes the new client data pointer syntax. > > > > It'd need a nice front-end to it with a suitably picked function evaluator > > similar to in pl*cont* and pl*shade*. > > > > Looks like some work. > > ************* > > > > To substantially simplify this, I would drop the defined part of it (which I > > brought up in the first place for the previous thread). Right now we don't > > have "defined" API for plcont, and I really don't think we need it for this > > API. But we do need the overall function evaluator stuff. Somebody will > > immediately want to be plotting vector fields for polar coordinates or > > irregularly shaped x,y regions, and plcont handles those cases with ease > > because of its function evaluator approach. > > Thanks for the suggestions. I have now implemented something along these > lines. Example 22 has been updated to reflect this and also to > demonstrate polar plots. > > We might want to rename the front end function from plarrows2 to > something more meaningful. To avoid problems with the existing if > underused and undocumented plarrows() interface we could rename the new > functions plvects() and plsvect() for plotting vectors if people prefer. > > A few points worth noting: > > The vectors have to be in cartesian coordinates even if the coordinates > are in e.g. polars (see example 22). This is mostly because of the way > our coordinate transforms work. I see this probably as more of a feature > rather than a limitation. If you think otherwise let me know. > > The auto-scaling is not particularly sophisticated and may well not work > for complicated coordinate systems. To keep the work to a minimum it > assumes that the adjacent points in the cgrid2 coordinate arrays are the > adjacent points in real space. Again this is probably not a major > limitation. If people have wierd and wonderful or even random arrays of > points to plot vectors at then they can always provide a scaling > themselves. A more robust algorithm would have to work out the distances > from every point to every other point which could be expensive for large > arrays. I may yet implement this. > > > Andrew, I have got to say that your example 22 already looks pretty good so > > I hope we can settle the API issue then extend that and example 22 (with > > colour changes and possibly adding a page with a vector field for polar > > coordinates) to all the language interfaces. I would be willing to do all > > of that latter project for python, java, fortran, and tcl, but I would leave > > to you doing the internal changes to implement the function evaluator > > approach along the lines of what Maurice suggested and also the required > > changes to the C++ interface and x22.cc. > > Alan, if we think the interface is ok then I would be grateful for help > adding the API to other languages and porting example 22. > > Cheers > > Andrew > __________________________ 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 __________________________ |