On 3/12/2011 4:25 PM, Ivan Shmakov wrote: >>>>>> 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? > > […]
PDL looping supports strides across dimensions in any order. Effectively, a copy is not needed although there may be a performance impact if you are doing a lot of ops on non-continuous elements which would break the cache... Data reordering if not needed for many types of slicing operations. > >> 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. 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. > […] > > >> 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? 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. --Chris _______________________________________________ Perldl mailing list [email protected] http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
