>>>>> Chris Marshall <[email protected]> writes: >>>>> On 3/12/2011 2:47 PM, Ivan Shmakov wrote:
[…]
>> There's, however, a catch: while GSL supports vectors with stride,
>> so that a PDL vector's storage could, I guess, be passed to GSL
>> directly (after all the necessary re-wrapping), the GSL matrices
>> could only have stride along the major dimension. Thus, should a
>> PDL matrix have a stride along the minor direction, the copy is
>> unavoidable.
> I'm not sure what you mean by major or minor dimension. PDL support
> N-dimensional object with the first dimension (think image rows)
> being most adjacent in memory order.
It was my understanding that changing the order of dimensions of
a PDL instance doesn't immediately cause the memory order of its
elements to change. Or does it?
[…]
>> The constructor for the class would accept an existing PDL, and,
>> should it be compliant to the GSL conventions, make it a “has-a” for
>> the newly created PDL::GSL instance, as required for the PDL
>> subclassing. (The necessary wrapping objects could be created
>> immediately.) Otherwise, a ->copy () is to be made, and the data
>> flow established (now, how the data flow is to be implemented in
>> this case, anyway?)
> A copy would not be needed unless to support a requirement of the
> underlying GSL library routine.
IIUC, it's a requirement of virtually every GSL routine that the
vectors are arranged in memory linearly, perhaps with a stride,
like (stride = 4):
v[0] X X X v[1] X X X v[2] ... v[N - 2] X X X v[N - 1] ;
and the matrices are arranged in memory like:
m[0, 0] m[0, 1] ... m[0, N - 1] X X ... X X
m[1, 0] m[1, 1] ... m[1, N - 1] X X ... X X
...
m[M - 1, 0] m[M - 1, 1] ... m[M - 1, N - 1]
This later model allows stride along the major (rows) dimension,
but not along the minor (columns) one.
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.
[…]
>> Now, there's still the problem that neither Math::GSL::Vector nor
>> Math::GSL::Matrix classes provide any constructors that will produce
>> an object from (mainly) a datatype and a data pointer. I haven't
>> looked at the code as of yet to determine whether such constructors
>> are feasible to make, though. (Perhaps I should contact the
>> Math::GSL developers for an advice on that matter.)
> It would be nice if the two could interoperate. 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?
--
FSF associate member #7257
pgpR6xzBrEqFx.pgp
Description: PGP signature
_______________________________________________ Perldl mailing list [email protected] http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
