David Mertens wrote:
>
> I don't know if anybody has pointed this out before, but on Monday night
> I stumbled across Numeric::LL_Array. It seems to be a very new project,
> but in principle is very similar to PDL.
Interesting.
> I contacted the author and asked him how his package compared with PDL;
> he said he didn't know because he could never get PDL to install. I got
> the impression that he was turned off from PDL by the dependency
> requirement and the footprint, and after the initial installation
> attempt failed he started on his own project. He seems to be very
> enthusiastic about it.
I'd be interested if he still has problems with PDL. If you explicitly
turn off all the PDL external dependencies then you should get something
that builds quite well I would expect. That PDL would have significantly
more functionality than Numeric::LL_Array athough it would be bigger and
most likely the much greater flexibility, generality, and power will
cost some performance, especially for small arrays.
> The goals of Numeric::LL_Array seem to be a bit different from PDL's
> aims, though it's not clear because the author does not explicitly state
> them. The module seems to focus on compact storage, small installation
> footprint, no external dependencies, and quick binary operations.
> Initially PDL focused on compact storage and quick operations, but it
> has expanded and I would say that it now aims to be a complete
> scientific numerical and analysis suite, complete with visualization and
> PDL::PP for hand-optimized routines and links to external libraries. We
> are not so concerned about the size of our footprint or the external
> dependencies.
A quick look at the Numeric::LL_Array reminded me of a sort of array
assembly language for perl. Very good for smaller or more focused
problems, maybe much more difficult as the degree of generality
increases.
> Anyway, it's definitely a project worth following. If nothing else, our
> docs should point to it as an alternative to PDL in case any of our
> readers are looking for a smaller, simpler solution.
I would like to see if the project evolves along the same lines
as the early PDL development. It feels more like a computer
scientist module than a scientist computer module to me.
> However, I think there's a lesson we could learn form this: We might
> consider breaking PDL into small individual modules, and then create
> a meta-distribution on CPAN called PDL-Full that requires all the
> small packages. This way, PDL could compete head-to-head with
> Numeric:LL_Array if somebody simply wanted to install the PDL-Core,
> but would aim to match the full > capabilities of IDL or Matlab,
> which most of us see as our real 'competition.'
PDL already is a bunch of individual modules (just look at what
use PDL means). :-) However, the current monolithic build and
distribution has consequences for maintainance and portability.
There has actually been some discussion on perldl (or pdl-porters)
along these lines. Personally, I would like to see PDL move to
more of an a la carte distribution: a lean, mean core, then additional
modules giving the full-featured package we now know as PDL.
The benefits could include:
* shorter, more responsive development cycle (smaller modules are
easier to work with, test, and release)
* PDL would be more portable (the core modules would provide the
data structure, the computational engine, and probably support
for test, development, documentation,...
* Functionality with outside dependencies would be separate so
if you did not have GSL installed, the core PDL would work,
the GSL module would not. (i.e. the Numeric::LL_Array author
might have come away with the thought that PDL did exactly
what he wanted rather than that PDL couldn't be installed)
> Thoughts?
We've been discussing refactoring PP for a while now. I think
a clean up of the existing code/approach might make possible
GPGPU acceleration (PyCUDA at http://mathema.tician.de/software/pycuda)
or even multicore CPU support.
A refactored core data structure could be generically useful to
anyone wishing to connect operations with C/binary blobs and perl.
For example, a cleaner PDL code data array could effectively replace
Numeric::LL_Array or OpenGL::Array implementations of binary array
objects. I know TMTOWTDI is the Perl way but it would be nice not
to reinvent basic, core functions for each module with a C array
object type of some sort.
> David
>
> P.S. I saw a paper comparing Numpy, PDL, hand-rolled C code, and plain
> Perl and Python code for computing a numerical integral. Plain old
> Python and Perl were terribly slow, but Python had two distinct
> numerical libraries, Numpy and something else.
I think they had Numpy, Numeric, and now a new NumPy. So if each
array language counts as a new version, 1, 2, 3, then we need to
get cracking on PDL-3.0! :-)
> I was jealous. So I
> don't think it's necessarily bad that Perl has a second numerical data
> processing project springing into existence.
Agreed.
--Chris
_______________________________________________
Perldl mailing list
[email protected]
http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
