PDL 2.4.0: Scientific Computing for the Masses

Dr. Zowie writes "Perl Data Language 2.4.0 was just released; get it here. This release includes even more powerful array slicing, a complete GIS cartography package, API access to the Gnu Scientific Library, and a host of other goodies. Between PDL and its less-mature siblings Numeric Python and Octave, the established commercial languages' days appear numbered."

Comments

Where is the GIS?

[smishra]

I looked through the website but could not find and GIS related modules. I also did a Google search (gis site:pdl.perl.org)but that too came up blank.

Re:I'm seeing red

[kworthington]

This might help the Editors: I've noticed that these glitches happen when Michael is the editor who posts. I have screenshots if needed. (not trolling, it's an observation. I have nothing against Michael)

Re:Maple?

[pr0ntab]

Well, the author of the article is an idiot anyway, as PDL is basically a Perl interface to LAPACK.
PDL is not a CAL, DE-solver, or anything like that.

So Maple's days are not numbered. Go figure! :-)

Re:Octave v. Matlab

[t]

Well your loop seems to have some flaws. You allocate
nextRedds = zeros(1, x+2*runs);
But you only use a range of [1:x+1+runs]. Is the rest meant to be zero?

Regardless, copyRedds for example will at its largest be 2*numIters + x+2*sum([1:numIters]). redds will add to its initial size x*sum([1:numIters]) elements. And nextRedds will at most be x+2*numIters. You should allocate all of these at the max sizes required, and use the necessary indicies within the loop instead. e.g.,
redds = [redds; nextRedds(1, a:b)];
would be
redds(length(redds)+ [1:x] = nextRedds(1, runs+[1:x]);

I have no idea where you got your 1.49GB figure from as `x' is unknown to me. sum([1:N]) = (N+1)*(N/2) is about N^2. For N=10k then that's about 3/4 GB of RAM. So I guess your number is plausible. If you don't have that much RAM then now you know why it runs so slow, you can't escape that fact that that is indeed how much RAM will be trying to use at the end of the loop. I'm not sure about Windows, but I think it will continually allocate swap on the local harddrives which would allow you to run this monstrosity without running out of memory. I'd be willing to bet that the computer at the school has several GBs of RAM, that would explain the enourmous speed difference.

Re:scipy

[Dr. Zowie]

There are several device-independent graphics packages for PDL. The main one is PGPLOT, a venerable but powerful package written in FORTRAN in days of yore. PGPLOT has output modules for everything from a PASCAL turtle to (yes) eps. There are interactive devices (X windows and such) and hardcopy devices (PostScript, EPS, gif, jpeg, png, and such).

What impressed me most about PGPLOT when I started using it is the strong device-independence. For example, it's difficult to say "Give me a 600x400 pixel X window" since pixels aren't device independent. It's much easier to say "Give me a 6-inch by 4-inch X window". Takes some getting used to, but then when you go to stick your output into a publication you can generate the same plot and send it to (say) the eps device instead of the X-windows device.

The PDL front-end has a record-and-play feature, too, so you can define a PGPLOT X window, noodle around with it, and then say "Replay all that into this hard-copy device" and get exactly the same plot, rendered on the other device.