>>>>> 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.)
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.
(Do I understand it correctly that PDL supports stride along any
set of dimensions, BTW?)
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?)
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.)
--
FSF associate member #7257
pgpsXhz6imOwC.pgp
Description: PGP signature
_______________________________________________ Perldl mailing list [email protected] http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
