I would tend to agree as well. I know that when I first started using PDL, I didn't use any of the plotting utils, first because I couldn't get the dependencies to install on winXP; second because I was quite happy with Gnuplot and had my templates for plotting completed.
I do think though that the graphics portion of PDL is nice. Once I was finally able to install it correctly using the perldl command line to prototype my scripts and explore my data it was a huge benefit. My work with PDL is mostly on the exploratory data side of things, so I most often am trying to find patterns between different sets of data, but the patterns aren't known in advance. In my case, it was the use of the basic PDL functionality that got me to use it, but the graphics integration should not be undersold. I don't know if a generic plotting interface can be created (b/c I am not a great programmer), i.e. any interfaces a Perl module supports available whether it is PLPlot, Gnuplot, PGPlot, xv..., would be great to have. I have tried PGPlot, PLPlot and Gnuplot. I still like Gnuplot formatting the best, plus the dynamic zoom is nice. I expect that I am just not experienced enough with the other plotting programs, which is why I still prefer Gnuplot. My 2cents. Cliff Sobchuk esn 361-8169, 403-262-4010 ext: 361-8169 Fax: 403-262-4010 ext: 361-8170 Nortel Core RF Field Support: All information is Nortel confidential. -----Original Message----- From: Craig DeForest [mailto:[email protected]] Sent: October 30, 2009 9:40 AM To: David Mertens Cc: [email protected]; perldl Subject: Re: [Perldl] PDL's got some 'competition' This looks like the best argument I've yet seen for breaking up the PDL distribution -- perhaps making the stuff in "Basic" the actual PDL module, and putting Graphics, IO, and Lib into their own module trees. On Oct 30, 2009, at 9:27 AM, David Mertens wrote: > Ilya Z, author of Numeric::LL_Array, is a long time Perl developer, a > rather brilliant one, and currently teaches/researches at the Cal > Math dept. I feel a bit vindicated in that I was not the only one > experiencing difficulty installing PDL. If Ilya felt it was difficult, > well, then, it must have been difficult. Either that, or he had some > other itch to scratch which caused him to develop his module instead > of sticking it out with PDL. > > See, this is what I find so surprising. I don't think it's really all > that difficult to get PDL to install. I've put instructions on > use.perl and, over the course of writing the instructions I realized > that it's really pretty simple if you know what you're doing or have > somebody to hold your hand. A Gentoo-quality wiki for installing PDL > seems like an appropriate stop-gap measure until we can get better > external dependency handling (in which case a cpan install would truly > be one-click). > > I don't think the installation was too dificult for him. Rather, I > think he has a philosophical gripe about it's apparent inability to > install correctly. Version 2.4.2 has an attrocious pass rate at CPAN > Testers. If PDL is supposed to be THE Perl numerical data module, it > should easily install on any Perl system and pass all its tests. I > believe that when he saw that, as well as all of the dependencies, he > decided to start fresh with his own solution. > > Ilya and I have discussed his failed attempts to get PDL installed, > and he made a very interesting observation. PDL 2.4.5 was released on > October 24 and Numeric::LL_Array v 0.12 was released on October 26. > Both distributions have passed on all the machines that have tested > them on CPAN Testers, but his distribution has run on 57 machines > while PDL has only been tested on four machines. We both thought > tthat these tests were automated, so why does Numeric::LL_Array have > over 14 times as many reported tests? My hunch is that the Perl > OpenGL module doesn't install on a lot of machines so PDL can't even > be attempted because its dependencies cannot be satisfied. I > conjecture that if PDL's dependencies can't be met that the > installation silently fails. But I'm not sure about how all that > stuff is reported. > > Ilya's take-away point is that authors of other modules cannot rely on > listing PDL as a dependency because the chances of a successful > automated install of PDL are low. Splitting up the current PDL into a > collection of modules, and especially having a lean core that focused > only on the data manipulatioin and left out the file handling and > visualization, would solve this problem. (As far as I know, > Numeric::LL_Array may simply be Ilya's vehicle for motivating us to > actually do that partitioning... and an opportunity for him to have > fun with XS code.) > > David > _______________________________________________ > Perldl mailing list > [email protected] > http://mailman.jach.hawaii.edu/mailman/listinfo/perldl _______________________________________________ Perldl mailing list [email protected] http://mailman.jach.hawaii.edu/mailman/listinfo/perldl _______________________________________________ Perldl mailing list [email protected] http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
