On 2010-02-11 12:53-0800 David MacMahon wrote: > As readers of this list know, I have been working on supporting "arbitrary > storage of 2D data". My primary motivation for doing this was to access the > NArray 2D data via a pointer to data in column-major order. Since the data > really are in row-major order with the dimensions reversed, this approach > allows one to index the data more "naturally" (i.e. a[i,j] rather than the > prescribed-though-backwards-seeming a[j,i]) at the expense of mistreating the > data as being unintentionally transposed. I now think I should revert back > to using the prescribed-though-backwards-seeming dimensioning/indexing of > NArray, thereby eliminating my need for pltr2f. > > Even though my specific use of pltr2f is no longer needed, I still think it > is useful to support 2D data that are in column-major order even in > non-Fortran languages. Plotting libraries exist to plot data. Data come > from various sources in various formats. IMHO, a plotting library that can > work with multiple (even arbitrary) data formats is more user friendly than > one which requires users to copy their non-conformant data into (one of) the > conformant format(s). So I still think that supporting arbitrary storage of > 2D data is "a good thing". Moving pltr2f into libplplot seems like a step in > that direction and my forthcoming patch will finish providing PLplot with > that ability.
Thanks very much for this further explanation. If we do decide to adopt this change then some additional changes have to be done. For example, your original patch may need modification if we decide not to include pltr0f. Also, your original patch removes pltr2f from both bindings/f77/sccont.c AND bindings/f95/sccont.c. That is a backwards-incompatable API change for both libplplotf77cd and libplplotf95cd, and Hazen will need to do the appropriate (so)version bump for those libraries during the next release to be consistent with that API breakage. Of course, all of this is just a formal API breakage because in practice both libplplotf77cd and libplplotf95cd depend on libplplotd so there should not be an API breakage for the combination, but I think we should observe these API formalities for the (so)versions of libplplotf77cd and libplplotf95cd. I don't feel qualified to decide about this small patch so I am willing to go along with whatever the rest of the core developers here decide (especially Maurice who is qualified and who was encouraging about your original ideas on arbitrary 2D storage), but it appears to me this small patch is philosophically tied up with the ideas behind your big patch (or probably patch series) implementing arbitrary 2D storage. So perhaps it would be best to make this small patch part of that patch series so that your implementation of arbitary 2D storage could be evaluated when that implementation is completely done. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ ------------------------------------------------------------------------------ SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
