Math::GSL::Core

[Jonathan Leto]

Howdy,

I was thinking of making something like

use Math::GSL::Core;

which would include the most commonly used Math::GSL modules,
something like Complex, Matrix, Vector, Eigen, Linalg, Errno, BLAS,
Const, and possibly a few others. This would only give you access to
the OO interface, if you wanted all of the low-level access to the
c-style functions (gsl_*) then you would do:

use Math::GSL::Core qw/:all/;

which would basically pass the :all to the corresponding modules.

My philosophy is thus: Optimize the OO interface for ease of use, but
expose the c-style interface for those wanting nothing but speed. The
trade off is that the OO interface is roughly 10 times slower but it
condenses 10-20 lines of code into one chainable method call. When you
find yourself chaining 3 or 4 methods like this:

# this code only works in the latest git bleed branch
use Math::GSL::Matrix;
printf "%.4f %.4f\n%.4f %.4f\n",
Math::GSL::Matrix->new(2,2)->identity->inverse->as_list;

OUTPUT:

1.0000 0.0000
0.0000 1.0000

the power of chainable method calls shines through.

This shows that the inverse of the identity matrix is
.....(drumroll).... the identity matrix. Good to be sure, don't trust
a numerical algorithm farther than you can throw it! The equivalent
code in low-level routines is probably about 20 lines with proper
error checking.

What do y'all think about this and do you have any other hints for
making Math::GSL more user-friendly?

Cheers and Happy Holidays,

Math::GSL blog: http://leto.net/code/Math-GSL

--
[---------------------]
Jonathan Leto
jal...@gmail.com

[Bruno]

I think it's a very good idea. I am all forward the 'simple things
made simple and difficult things made possible' motto.
I also like when modules provide sane, tacit defaults so that a
beginner user does not have to deal with decisions that he's not yet
ready to make. In your PDX.pm talk, you provided an example of how
numerical integration:

my ($status, $result, $abserr) = gsl_integration_qags (
sub { my $x=shift; $x ** 2 * log (1/$x) },
0, 1, 0, 1e-7, 1000, $gsl_integration_workspace
);

I would love it if you could do away with the last four parameters;
you'd only provide the function and the integration limits, and have
the module figure out sane defaults for the rest:

my ($status, $result, $abserr) = gsl_integration_qags (
sub { my $x=shift; $x ** 2 * log (1/$x) }, 0, 1
);

Another improvement that I can think of, is to access the arguments
using a hash, so that you don't have to look for the documentation to
remember the order in which the arguments go. Something like:

my ($status, $result, $abserr) = gsl_integration_qags (
function => sub { my $x=shift; $x ** 2 * log (1/$x) },
from => 0,
to => 1,
);

Another idea that I think would be nice, is to have a subset of the
gsl library (much like the one you describe here) available for
independent installation from the rest of the module. This way, you
can increase the probability of building the core modules successfully
in as many platforms as possible, thus lowering the entry barrier to
the most frequently used functionality.
In my experience, one of the biggest downsides of PDL is its lack of
ease of installation, and I blame it on the graphic and plotting
libraries. I've spent hours playing with libgd dependency issues just
to be able to install the PDL::Core module, needed for some N-
dimensional vector algebra. I didn't need any plotting, but there was
not an option to independently build the PDL::Core module from the
PDL::Graphics::GD one.