My responses are below to the various points.  For clarity,
I've edited out the text not being addressed in my response.

--Chris

On 7/13/2012 11:56 PM, David Mertens wrote:

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.

Thanks for developing it.

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.

Yes, this is a "Keep it Simple" graphics that can grow
in the future but the goal is to have the 90% solution
as soon as possible.

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."

The first thing is just a table of the basic functionality
and general equivalences and what the differences are.
The idea is that someone used to line $x,$y in PGPLOT
might have a similar routine that could do the same
general thing.

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?

Take a look at the source code?  Per my comment above,
I think something like a linear stretch with 1%
saturation at the tails would be a good first
cut.  Improvements can be made down the line.

* 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...)

Docs would be good.  :-)

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.

I was hoping you could take care of the PDL::Graphics::Prima
part, not dumping the whole release on you...

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):

I've rearrange the points in my suggested order
of priority.  Again, I think the existing PDL::Graphics::Prima
covers most of the bases.  What would be most valuable here is
docs/tutorial and a chapter on that in the PDL Book.

2) I will need to substantially improve the documentation for
PDL::Graphics::Prima, including one (or more) primers on Prima itself.

6) The above documentation substitutions will necessitate a number of
additional P::G::Prima::Simple functions for those one-liners Chris was
talking about.

5) We will need to write chapters for gnuplot and P::G::Prima.

I would like to see a chapter on Gnuplot but that is not
this project.  I'm hoping that it will come when the
win32 issues with the PDL::Graphics::Gnuplot are fixed
and the release is ready for prime time.

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.)

The first iteration is the chapter on PDL::Graphics::Prima
for the book.  After the module is in general use, we can
address the issue of retroactive changes to doc refs.

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.)

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.

The goal of the Top 10 use cases was to allow you to
limit any new development to the least amount with
the most impact.  This is more important if you will
be working on PDL issues outside of work time.

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.)

Leaving it on CPAN is good for me.  We just need to
ensure that the various cpan, cpanm,... tools all
a 1-click capable so the new user doesn't have
problems getting the modules.

Per discussions from a while ago, I think a lean,
mean, core PDL with a clean way for non-core
modules to tie in to the documentation and an
existing PDL core install seamlessly would be
better than making the core PDL even bigger.

Notice that there isn't a lot of PDL code that needs to change here, just
some of the docs.

Yes, exactly.

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.

I was hoping you would do the PDL::Graphics::Prima
stuff as I don't have time to learn Prima and
P::G::P just to be able to document it.  I have
a link to a very good presentation on using
P::G::P that might give you some ideas.  Now,
if I could only remember the speaker's name...  :-)






_______________________________________________
Perldl mailing list
[email protected]
http://mailman.jach.hawaii.edu/mailman/listinfo/perldl

Reply via email to