On 3/13/2011 1:18 AM, Ivan Shmakov wrote: >>>>>> Chris Marshall<[email protected]> writes: >>>>>> On 3/12/2011 4:25 PM, Ivan Shmakov wrote: > > […] > > >> Should a PDL instance's own storage layout fail to comply to the > >> one supported by GSL, like: > > >> m[0, 0] X X m[0, 1] X X m[0, 2] ... m[0, N - 1] X X ... X X > >> m[1, 0] X X m[1, 1] X X m[1, 2] ... m[1, N - 1] X X ... X X > >> ... > > >> a copy is unavoidable. > > > Yes, this would be a requirement of the GSL library. PDL is *much* > > more flexible in its ability to handle dimension order and other > > slicing operations. > > Thus, if a storage vector of a PDL instance is to be passed GSL, > it has to either comply to the (stricter) GSL model as it is, or > it has to be made compliant (by copying.) > > In order to limit such copying, it was my intent to allow GSL > function wrappers to produce copies as necessary, while allowing > these copies to be (somehow) passed back to the caller, so that > they could be reused in further GSL calls. > > […] > > >>> One thing I would like to see is a SWIG binding to support perl+PDL > >>> as a language option. That would probably be the cleanest approach > >>> from a multi-platform point of view. > > >> I'm not familiar with SWIG, and cannot readily see how such an > >> interoperability could be implemented. Any details, please? > > > SWIG could understand that a pdl is the natural mapping for an array > > of elements and issue code creating a piddle rather than a perl array > > in the binding. Plain perl is already a supported language of SWIG. > > It was my understanding that the GSL wrapping functions are to > work roughly as follows: > > • take PDL instances as arguments; > > • check them to comply to the GSL model; > > • allocate memory and copy storage vectors /iff necessary/; > > • construct gsl_matrix or gsl_vector wrapping; > > • call the function being wrapped; > > • some of the storage vectors may have been changed as a side > effect; propagate these changes back to the original PDL > instances if the storage vector was copied. > > Here, no PDL instance is ever created by the wrapping code.
Since the GSL library does not support pdls as inputs, any binding to that library must create any pdls needed. > Do I understand it correctly that what's you're proposing is > like: The comments re SWIG were for the option of implementing a perl+PDL language binding capability in SWIG itself (e.g., there is one for matlab). > • do as above to get the storage vectors in gsl_matrix or > gsl_vector wrapping; > > • allocate the memory for the results; > > • call the function being wrapped; > > • create new PDL instances for the results allocated. > > • return 'em to the caller. > > To my mind, this approach is less efficient, due to the > mandatory memory allocation being involved. I like the first approach, especially for GSL matrix and array routines as it should reduce memory pressure and improve latency. One of the biggest challenges in making a binding to the GSL library is the size and scope of the problem. Some issues of interest: (1) mapping of GSL data structures <-> perl or PDL ones (2) threading support of GSL routines (3) implementation and documentation A start would be creating a wiki page on our PDL wiki to flesh out these issues. There is more than can be done in an email thread. For example, this is the top level headings in the 'info gsl' on my PC: * Introduction:: * Using the library:: * Error Handling:: * Mathematical Functions:: * Complex Numbers:: * Polynomials:: * Special Functions:: * Vectors and Matrices:: * Permutations:: * Combinations:: * Multisets:: * Sorting:: * BLAS Support:: * Linear Algebra:: * Eigensystems:: * Fast Fourier Transforms:: * Numerical Integration:: * Random Number Generation:: * Quasi-Random Sequences:: * Random Number Distributions:: * Statistics:: * Histograms:: * N-tuples:: * Monte Carlo Integration:: * Simulated Annealing:: * Ordinary Differential Equations:: * Interpolation:: * Numerical Differentiation:: * Chebyshev Approximations:: * Series Acceleration:: * Wavelet Transforms:: * Discrete Hankel Transforms:: * One dimensional Root-Finding:: * One dimensional Minimization:: * Multidimensional Root-Finding:: * Multidimensional Minimization:: * Least-Squares Fitting:: * Nonlinear Least-Squares Fitting:: * Basis Splines:: * Physical Constants:: * IEEE floating-point arithmetic:: * Debugging Numerical Programs:: * Contributors to GSL:: * Autoconf Macros:: * GSL CBLAS Library:: * Free Software Needs Free Documentation:: * GNU General Public License:: * GNU Free Documentation License:: * Function Index:: * Variable Index:: * Type Index:: * Concept Index:: Cheers, Chris _______________________________________________ Perldl mailing list [email protected] http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
