On Wed, Oct 28, 2009 at 11:09 PM, David Mertens <[email protected]> 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. > > 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?
Since you asked -- I approached PDL a few months ago with an incredible amount of enthusiasm. To me, it seemed like it would answer all my questions. It would replace IDL, it would provide a familiar and completely free platform to do all my scientific analysis. And, from there, it went bad. I just never could install the darn thing easily on my Mac. Many of you very kindly gave me your time and advice. I am very appreciative of all that, but the reality is, the first step itself was just way too difficult. I wasted so much of my energy and effort getting the thing to install on my laptop, I never really got the courage to pursue PDL for other analysis work. I tried to do some 3D surface plotting, but gave up quicker than I thought of it. Went to R, and with a few keystrokes, I had a working model 2 different ways. Even IDL was a single click install. I have kept my subscribed to the list, because I love reading about the developments, and reading the code that others write, hoping to learn from it. But, mostly, I am simultaneously appreciative of the hard work of the developers, and full of trepidation at the torture that PDL installation continues to seem to be. I don't really care about the footprint or the dependencies. Disk space is cheap, memory is cheap. What is not cheap is my (or anyone else's) time. I want a robust, preferably single-click (single CPAN command) install that I know will work reliably on my Mac, and on any other Mac that I transfer to (one nice thing about Macs and Windows is that once you get something working on one machine, you are pretty much guaranteed to have it work on other machines, provided the CPU and OS version doesn't change). Once again, I have a tremendous appreciation for the developers, and a lot of, but guarded, amazement at what PDL purports to do. For now, I don't have the first hand experience doing anything with PDL other than installing it rather painfully. Yes, I do hear a lot about Numpy and Scipy (a bunch of hackers here at Wisc are heavily into Python). Frankly, Python bores me to tears, so I will probably stick to IDL until PDL comes home. :-) Here's hoping. > 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 > > -- Puneet Kishor http://www.punkish.org Carbon Model http://carbonmodel.org Charter Member, Open Source Geospatial Foundation http://www.osgeo.org Science Commons Fellow, http://sciencecommons.org/about/whoweare/kishor Nelson Institute, UW-Madison http://www.nelson.wisc.edu ----------------------------------------------------------------------- Assertions are politics; backing up assertions with evidence is science ======================================================================= Sent from Madison, WI, United States _______________________________________________ Perldl mailing list [email protected] http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
