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
