Hi, Alan, On Feb 10, 2010, at 23:01 , Alan W. Irwin wrote:
> On 2010-02-10 21:57-0800 David MacMahon wrote: > >> I wouldn't miss pltr0f if both its declaration and >> definition were in the FORTRAN bindings only, but I would very much >> miss pltr2f! > > Why? Do you have some non-Fortran use for it? > > I would prefer to keep definitions used in our Fortran bindings in > sccont.c. > But that assumes pltr0f and pltr2f will be used just for the Fortran > bindings which is why I am asking the above question. Yes, I have a non-Fortran (see the P.S.) use for pltr2f. I'll describe my specific non-Fortran need for this function (which might turn out not to be needed after all as you'll read below) and then explain why I think there is a general usefulness for it (regardless of whether my specific need still exists). Sorry for the length of this reply, but it covers more ground than just where these two functions should live. The Ruby PLplot bindings I'm working on utilize the Ruby NArray package for data storage. The NArray package (http:// narray.rubyforge.org/) provides a Ruby interface to multi-dimensional arrays of "native" data types along with some numeric processing capabilities, kind of like Numpy for Python. I had been thinking that it stores its data in column-major order, but while looking into it further to answer your question I have since discovered that it stores data in row-major order but reverses the ordering of the dimensions (and therefore indices). From http://narray.rubyforge.org/ SPEC.en: "The order of Matrix dimensions is opposite from the notation of mathematics: a_ij => a[j,i]". From a plotting perspective, column-major order is more or less equivalent to row major order with reversed dimensions, but when it comes to matrix multiplication it's entirely different. 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. I wonder if pltr2f could be re-written as a call to pltr2p with indices and dimensions reversed. Dave P.S. Here's an interesting little footnote about FORTRAN vs Fortran... http://en.wikipedia.org/wiki/Fortran#cite_note-0 ------------------------------------------------------------------------------ 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
