I put a lot of energy into making the Gnuplot stuff work, because it produces beautiful publication-quality output in both 2-D and 3-D and is reasonably fast. I see the current round of grousing as a Good Thing, shaking out the module as people try it out. There are some architectural worries on Microsoft Windows since it is not POSIX, but I don't see them as show-stoppers - interprocess control is universal, and I am positive the low-level communication with gnuplot can be made more robust on that platform. I do not see gnuplot succumbing to bit rot in the near future - it has a vibrant development community and is being actively supported for multiple major platforms with far more users than PDL. The main issues with gnuplot are that is not optimized for interactive work, and that the API is a bit ... crufty. Those things are OK for most stuff, in part because plotting is very fast for most types of plot, but there are two large gaps I see, that are not likely to go away soon:
* The architecture slows down large image display. This makes it awkward to, e.g., perform interactive markup on large images. Up to about 800x800 is okay on my macbook pro, but 4000x4000 floating point images take around 10s to render, and the architecture forces a full re-render after each new point is rendered to the screen by, e.g., read_polygon(). The slowness arises partly because Gnuplot hands the image around a lot internally and partly because the image has to go through a pipe from PDL to Gnuplot each time. * It is likely to remain awkward to incorporate a gnuplot widget into other types of window - at least, without someone diving in and writing a new backend device driver for gnuplot itself. The API concerns stem partly from Gnuplot having a long legacy and partly from the fact that plotting itself is a complex endeavor - supporting all the wizzy things that gnuplot does requires a certain amount of cruftiness and wooliness to the control interface - every plotting package I have studied (IDL, Mongo, PGPLOT, Vplot, and some of Plplot) ends up pretty wooly in the course of becoming versatile. I see Prima as a very nice step in the direction of interactive work, potentially enabling a graphical PDL and certainly enabling closer interaction with graphical data. There is a lot of architectural beauty in it, although it does not yet fulfill my needs as an academic user - it is more of a toolkit than a high level plotting package. (To be fair, this seems to be the state of Plplot too... at least the last time I dug into it in anythibg resembling detail...). I see Gnuplot and Prima both as viable directions forward. I suggest moving toward Gnuplot as a primary plotting interface, and am willing to support frequent releases of it as folks begin reporting desires and/or warts that are invisible to me. I also suggest maintaining Prima as a major alternate package with prominent advertisement, in part because its tight integation with Perl and PDL give it a lot of promise for future interactive tools. I would like to see us keep legacy support for PGPLOT and Plplot, so that people like Karl (or even me) can continue runnng old code - but I do not think it is productive to feature those packages prominently in, e.g., the examples and tutorial literature. (mobile) On Jan 31, 2013, at 1:27 AM, Matthew Kenworthy <[email protected]> wrote: > > > i'm going to be an instigator again and point out that pgplot, plplot, and > gnuplot are all ~20 year old pieces of legacy software. at least gnuplot is > actively maintained and evolving, but pgplot has hardly been touched in ~10 > years. i've tried plplot a few times, but always ended up throwing up my > hands after a short while. maintaining dependencies with packages like these > will always be a headache and will hold back adoption and evolution of PDL. > note that i haven't looking into prima at all, however. > > > 20 years old doesn't mean they're crap - but your point about legacy software > is a good one. > > tying back into the previous discussion about notebook-type interfaces like > what ipython has i'd like to point out the existenceit of http://d3js.org/. > ipython notebooks are great, but using matplotlib graphics within a browser > is rather limiting. integrating something like D3 opens up a lot more > flexibility and capability. a browser-based PDL shell that used D3 for > plotting could be pretty kick butt.... > > > I use plotting packages for two things - making production quality figures > where I want fine grained control, and 'rough and ready' plots that allow me > to hack at data on the command line, like the python notebooks. > > d3js looks *beautiful* for interactive data, but probably a pain in the ass > for reproducible PDF output. What do you use for paper output? > > Matt > > > > -- > Matthew Kenworthy / Assistant Professor / Leiden Observatory > Niels Bohrweg 2 (#463) / P.O. Box 9513 / 2300 RA Leiden / NL > _______________________________________________ > 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
