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.
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. 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. 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. 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.' Thoughts? 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 was jealous. So I don't think it's necessarily bad that Perl has a second numerical data processing project springing into existence.
_______________________________________________ Perldl mailing list [email protected] http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
