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
