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
