>>>>> 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.
Do I understand it correctly that what's you're proposing is
like:
• 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.
--
FSF associate member #7257
pgpaw8SWa3n7J.pgp
Description: PGP signature
_______________________________________________ Perldl mailing list [email protected] http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
