Hi all: As the author of PDL::Graphics::PLplot, I'm happy to have a
default interactive plotting solution for PDL that is easy to install.
I've always thought that the difficulty of installation was a major
downside for PGPLOT and PLplot graphics solutions. Both of these have a
bit of a hacked-together feel to them due to the fact that they are
interfaces to external libraries with their own complex set of rules and
procedures.
That said, I will continue to maintain and use PDL::Graphics::PLplot for
my own scripts and for the plots generated by my data center.
I would be interested in learning and using Prima for quick interactive
graphics, however.
Regards,
Doug
[email protected]
Software Engineer
UCAR - COSMIC, Tel. (303) 497-2611
On Fri, 13 Jul 2012, David Mertens wrote:
I have been in a car all day today and though I have been able to read this
email thread, I have not been able to respond.
Aaargh! But now I am in my hotel, so I can reply with my thoughts. :-)
On Fri, Jul 13, 2012 at 10:37 AM, chm <[email protected]> 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.
This endorsement means a lot. I have stated before that this has been a goal of
my work with PDL::Graphics::Prima, and it means
a lot that you think we should focus on this as a working default.
To clarify, I am working on making PDL::Graphics::Prima flexible and powerful.
I have even started working on a Cairo backend,
which would make it possible to create publication-quality figures. However,
gnuplot, PLplot, and PGPLOT are currently superior
for making professional plots. The proposal here is to have a working
mess-with-my-data plotting library. When it comes time to
produce something for publication, we can and should encourage variety.
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. :-)
"Or less." Ha!
I have thus far not focused on targeting the major use cases of these three
plotting libraries, simply as a matter of time.
However, if users of these can point me to things that these libraries do well
and which P::G::Prima can emulate, I will be
happy to do so. I will also be more than happy to say, "This feature is stolen
from Other::Lib, so if you like it you should
check out Other::Lib."
In particular, I have a function called "imag_plot". I would really like for
that to emulate PGPLOT's imag function, but I'm
not sure how it handles the contrast. Any pointers?
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.
Agreed.
* 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.
Agreed. This was one major reason for my choosing Prima.
* The use of Prima will provide an easy
to use, default GUI environment for more
sophisticated and user friendly PDL
applications.
In my opinion, this is a major win and a second major reason for my choosing
Prima. I foresee that interactive data analysis
will only become more common, so having a full GUI toolkit is far more useful
than simply having a plotting library. (Which
reminds me that I need to write a tutorial on this in the PDL::Graphics::Prima
docs...)
* 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.
Hmm, interesting story here. I just had my annual review and my boss has asked
me to cease doing my research in Perl and work
with Python, just as the rest of the lab uses Python. A year ago I didn't want
to switch because I worried I might actually
jump to Python, but I am no longer concerned about that. Actually, I am excited
to learn as much as I can, and to steal what I
like back for Perl and PDL.
All of that means that I will have a harder time justifying PDL-related
programming at work. I still intend to do a little bit
of Perl development at work, but it will have to be more constrained. Might I
be able to lead the next point release? Maybe,
but I can't commit to it quite yet. I think I know what needs to happen and how
to do it, it's just a matter of having enough
time.
At any rate, I think the time is right
for this to happen and the sooner the
better.
Thoughts, comments, "volunteers"?
--Chris
If we move forward with this, I foresee the following work ahead (in addition
to any other changes such as 64-bit support,
etc):
1) I will need to implement a number of planned features for
PDL::Graphics::Prima that I have been dragging out including
refined axis tweaks (including multiple axes), both text and drawn figure
annotations, and (based on the previous item) at
least basic support for legends. (An important feature that won't get attention
for this point release is the Cairo backend.
Sad.)
2) I will need to substantially improve the documentation for
PDL::Graphics::Prima, including one (or more) primers on Prima
itself.
3) We will need to comb through the PDL documentation and look for examples and
synopses that use PGPLOT (and possibly PLplot)
and replace them with P::G::Prima code.
4) We will need to go through the PDL::Book and replace basic examples to use
P::G::Prima. (Obviously, the chapters on PLplot
and PGPLOT will continue to use those libraries.)
5) We will need to write chapters for gnuplot and P::G::Prima.
6) The above documentation substitutions will necessitate a number of
additional P::G::Prima::Simple functions for those
one-liners Chris was talking about.
7) Does this mean that PDL::Drawing::Prima and PDL::Graphics::Prima should be
added to the PDL core? Or, should we simply
recommend the CPAN distributions that are already available? (I actually prefer
the latter, and would add PDL::Stats to the
recommendation list.)
Notice that there isn't a lot of PDL code that needs to change here, just some
of the docs.
I am on board with this proposal. I might be able to be orchestrate the
release, but I'd appreciate if somebody else could step
up here.
David
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." -- Brian Kernighan
_______________________________________________
Perldl mailing list
[email protected]
http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
