I think we're on the same page here, Chris. I hope I didn't come across too negatively about Gnuplot - I think it is a nice plotting package for specialist stuff (and you can see from the pdf I sent that it does indeed produce beautiful output when massaged). But it is not sufficiently fast, lightweight, or intuitive enough to be the default go-to package for PDL graphics. PGPLOT was nearly there, and the extensive PDL support code for it is terrific -- but the actual PGPLOT library is, of course, not in active development nor likely to be picked up again.
So I will motor on merging my stuff to Dima's desirements and release-worthy; but also heartily encourage Prima development (by somebody else). Cheers, Craig On Jul 13, 2012, at 1:36 PM, chm wrote: > Hi Craig- > > I still would like to see PGPLOT, PLplot and Gnuplot > graphics easily available and working for PDL. This > specific post was about something that could cover > basic interactive graphics for PDL users to use as > a standard default. > > Once the Alien::XXX stuff is working---and believe > me, I follow Joel's updates on his project with > keen interest---we can add more feature-full options > for publication graphics as well. > > It just seemed to me that the PDL+Prima was our > best chance of moving forward constructively in > the near term (e.g., I would like a September-ish > release). > > I have been following the Gnuplot support development > as well but, per my comment below, I'm pretty much > strapped with my current commitments for PDL > development and don't expect to add anything > significant for a while yet. (Along with PDL, > there is a long delayed update to POGL and thence > for PDL::Graphics::TriD). > > --Chris > > On 7/13/2012 3:17 PM, Craig DeForest wrote: >> I'm behind Chris's idea too, if it becomes a standard everyone can >> point to. >> >> I overhauled Dima's nice gnuplot module into something sufficiently >> top-heavy to hide most of the weirdness that is gnuplot itself. I >> owe Dima an apology for breaking some of the functionality that he >> put in there, but am working on unbreaking it now. I'll continue >> using gnuplot for publication quality stuff for some time, but I >> don't think that gnuplot itself is the ideal go-to-first solution for >> graphics, for a couple of reasons: >> >> (1) gnuplot is baroque and top-heavy. It makes simple things very >> simple, and moderately difficult things insanely difficult. > >> (2) gnuplot is slow compared to (say) vanilla pgplot, so that a lot >> of things like on-the-fly rendered animations are difficult or >> impossible. > >> (3) gnuplot is fragile - it is a complicated beast, and despite >> Dima's careful interface work it is possible to hose up the >> complicated state between PDL and Gnuplot itself. It is telling that >> every plot has a race condition, since it is possible to get into a >> state where gnuplot waits forever for input, and it's not in >> principle possible to know whether gnuplot is waiting or just working >> hard. > >> (4) gnuplot's syntax is insanely complex. I have attempted to hide >> most of that complexity from the user, with a modicum of success -- >> but there are many, many exceptions and special cases. One has to >> choose between very smart Perl code that attempts to regularize the >> syntax, vs. very smart users who refer to the manual constantly. The >> reality is that even very smart Perl code won't be able to track all >> the corner cases and irregularity and "this-is-how-you-do-its", so a >> *lot* of headspace is required to be able to produce good plots. > >> (5) gnuplot is not easily adaptible to an imperative model of drawing >> - the interface is keyed to an atomic "plot" operation. Typical >> operations for me to develop complicated plots (one such plot is >> attached) would involve multiple plotting commands in PGPLOT or >> Plplot; doing the same sort of thing in Gnuplot involves assembling a >> giant data structure of plot descriptors, all of which get shipped >> off on one giant parameter list (the attached plot includes over 50 >> overlain plot lines, all executed in a single call to Gnuplot's >> "plot" command). > >> (6) gnuplot interactivity is a bit baroque and hard to use reliably. >> I seem to have broken interactivity in recent versions of my git >> tree, but even with Dima's prettier original code it was very hard to >> get events in and out of the graphics. >> >> Those things said, Gnuplot *does* produce beautiful output when >> prodded appropriately, is in active development and well supported, >> and is reasonably device-independent for the major pixel- and vector- >> interface formats. >> >> In brief: I think gnuplot (and PDL::Graphics::Gnuplot) has good >> potential as a publication quality plot back-end, particularly for >> people who are used to gnuplot from elsewhere - but appears >> unsuitable as a main general purpose graphics backend. >> >> Cheers, Craig >> >>> >>> On Fri, Jul 13, 2012 at 11:37:55AM -0400, chm wrote: >>>> David and all- >>>> >>>> I think it is time to resolve the PDL graphics problem, "this >>>> missing link" by getting a basic, standard capability for PDL. >>>> >>>> I propose the standard display graphics for PDL be based on the >>>> Prima graphics toolkit by Karasik et. al. and the current code >>>> for PDL::Graphics::Prima by David Mertens. >>>> >>>> A start would be to review the common usage of PGPLOT, PLplot, >>>> and Gnuplot to come up with a Top 10 of use cases to implement. >>>> They should be *very* simple to use and have smart defaults so >>>> the common case versions of the Top 10 can be done in 1-line or >>>> less. :-) >>>> >>>> Motivation/justification: >>>> >>>> * More beginning PDL users thanks to the PDL Book and the >>>> increasing buildability and usability of PDL on all platforms. It >>>> makes it more glaring that we don't have a good, common, default >>>> graphics. >>>> >>>> * Alien::XXX development has not matured enough to allow easy use >>>> of PLplot and PGPLOT and it is arguable that we want the base >>>> display graphics to be readily available from perl/CPAN which >>>> Prima is. >>>> >>>> * The use of Prima will provide an easy to use, default GUI >>>> environment for more sophisticated and user friendly PDL >>>> applications. >>>> >>>> * If we could get that base graphics up and running for the next >>>> point release (which will include the new NiceSlice filter engine >>>> and 64bit indexing) we would have a compelling platform for >>>> future growth. >>>> >>>> One downside, I am not prepared to push this effort through as >>>> I'm pretty busy working to make time for the final 64bit index >>>> development and the new NiceSlice engine support (the missing >>>> piece is the ability to use NiceSlice in an eval such as the pdl2 >>>> or perldl shells. >>>> >>>> I'm hoping that David might be willing to spearhead this >>>> development and maybe hold off on the Core diving for a bit. >>>> >>>> At any rate, I think the time is right for this to happen and the >>>> sooner the better. >>>> >>>> Thoughts, comments, "volunteers"? >>>> >>>> --Chris >>> >>> -- Sincerely, >>> >>> Dmitry Karasik >>> >>> >>> >>> >>> _______________________________________________ Perldl mailing >>> list [email protected] >>> http://mailman.jach.hawaii.edu/mailman/listinfo/perldl >>> >> >> >> >> ----- No virus found in this message. Checked by AVG - www.avg.com >> Version: 10.0.1424 / Virus Database: 2437/5129 - Release Date: >> 07/13/12 >> >> >> > > _______________________________________________ Perldl mailing list [email protected] http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
