On 3/12/2011 2:47 PM, Ivan Shmakov wrote:
>>>>>> Chris Marshall<[email protected]> writes:
>>>>>> On 3/11/2011 2:22 PM, Ivan Shmakov wrote:
>
> >> Well, I had to use a few Math::GSL::Linalg functions, so I wrote a
> >> few simplistic Math::GSL::{Vector,Matrix} to PDL “and back again”
> >> conversion functions (MIME'd.)
>
> >> BTW, are there any plans to provide an interface to Math::GSL from
> >> within the PDL framework?
>
> > I would like to see PDL bindings to the GSL. Don't know of any plans
> > regarding Math::GSL. Depending on the implementation, that might
> > work (e.g., we wouldn't want GSL matrices to be turned into perl
> > arrays and then converted into piddles. It should be possible to go
> > directly from a GSL matrix or vector to a pdl.
>
> … Or vice versa, I suppose. (It's the GSL convention for the
> caller to provide the storage to put the results into.)
Yes.
> 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.
> (Do I understand it correctly that PDL supports stride along any
> set of dimensions, BTW?)
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...
> My idea was to add a new class (say, PDL::GSL), subclass to PDL,
> bearing a couple of extra properties: the corresponding
> Math::GSL::Vector (undef, unless PDL is 1D) and
> Math::GSL::Matrix (may default to a 1-column or 1-row matrix, if
> PDL is 1D) objects.
>
> 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.
> The data flow is quite nice to have, so that the wrapping
> functions become simpler to write (?), like:
>
> sub qr_decomp_packed {
> my ($in, $qr_1, $tau_1) = @_;
> my $qr
> = PDL::GSL->new ($qr_1);
> my $tau
> = PDL::GSL->new ($tau_1);
>
> $in->assgn ($qr)
> unless ($in == $qr);
> gsl_linalg_QR_decomp ($qr->gsl_matrix (), $tau->gsl_vector ());
> ## NB: the changes to $qr and $tau should propagate to $qr_1 and
> ## $tau_1, respectively, like, now
>
> ## .
> $qr;
> }
>
> There, the PDL::GSL constructor will accept both PDL and
> PDL::GSL instances as arguments, and will simply pass the latter
> through as is.
>
> 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.
--Chris
_______________________________________________
Perldl mailing list
[email protected]
http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
