Alan, That's an encouraging answer! The logarithmic grid looks uniform to me. Is there a way to get the major/minor look that I showed? Would one simply draw the minor grid and then a coarser major grid with larger spacing and heavier lines? Worst case, I can set styles and draw the lines, but the point of this is to explore smart ways to do it.
For now I have gnuplot doing something close enough to what I need to keep going for a while, but PLplot has been doing a good job where I really need a library, and I want to gradually migrate all of my graphing to it. It is worth mentioning that gnuplot's (advertised anyway) style options are not a panacea; Unicode will be nice approach. That said, the next thing on my agenda should probably be to use streams. At present, bad things happen if I am debugging an ongoing plot and fire off a new one =:( After that, a memory driver would be a good idea for me. Too many good ideas, too little time. Thanks for seeing this as the friendly challenge (emphasis on the friendly) it was intended to be. Bill ________________________________________ From: Alan W. Irwin [[email protected]] Sent: Thursday, November 11, 2010 6:51 PM To: Schwab,Wilhelm K Cc: [email protected] Subject: Re: [Plplot-general] Can PLplot do this? On 2010-11-11 14:12-0500 Schwab,Wilhelm K wrote: > Hello all, > > Suppose you were challenged with producing exactly the attached output. Do > you have any thoughts on clever ways to do it using PLplot? Are there things > you would advise NOT doing? :) To say I need exactly the displayed output > is too strong; it was produced using gnuplot and is itself a compromise. > However, it gets a few things right; in particular, distinguished major and > minor grid lines are a must. > > Not that it really matters, but the data are blood pressures (measured a > couple of different ways, hence the different symbols), and heart rate. The > minor grid lines are spaced at 15 minutes, but I could just as easily (and > did so here) express time in seconds. The vertical range of the numbers is > 0-250 with heavy grid lines every 50 units. The answer to your question is "yes". The grid part should be easy. See http://plplot.sourceforge.net/examples-data/demo04/x04.02.png for an example of a grid. In that case it is solid and logarithmic, but the solid part could be taken care of by setting the line style (I think), and a linear grid (what you have in the challenge plot) is default rather than logarithmic. See the "g" and "h" options for xopt and yopt in the plbox argument list at http://plplot.sourceforge.net/docbook-manual/plplot-html-5.9.7/plbox.html. The symbol part should (now) be easy as well. Just in the last few days by coincidence I implemented plstring which is a unicode-aware replacement for both plpoin and plsym where instead of an integer code for the glyph, you specify a normal PLplot user input string to represent the glyph that is plotted. Such strings can be UTF-8, or include the standard PLplot text escape sequences. So that gives you direct access to the millions of glyphs that are available using modern unicode-aware device drivers like qt, cairo, and svg. In particular most modern OS's like Linux, Windows, and Mac OS X are UTF-8 aware so that UTF-8 symbols can be simply cut and pasted from a glyph display app such as gucharmap to the plstring call, e.g., plstring(n, x, y, "△"); plstring(n, x, y, "▽"); plstring(n, x, y, "▲"); plstring(n, x, y, "▼"); (I hope you have set your mailer to UTF-8 so you can see the above UTF-8 symbols. Of course, millions more high-quality glyphs like those are readily accessible using cut and paste from gucharmap.) That only leaves just one real concern about your friendly challenge to PLplot, and that concern is the potential with time series of having an extreme aspect ratio for the plot. I think the aspect ratio of ~20 in the challenge plot would not be an issue, but if you tried to push too far toward large aspect ratios (say an aspect ratio exceeding 100 for a very long time series) with PLplot, then you would run up against some fundamental PLplot numerical precision limits. The sad truth is we currently store internal positions strictly as 16-bit integers as a legacy of our memory- and bandwidth-starved past. We need a core code rewrite to define at compile time the precision and kind of our critical variables using any numerical type the user likes (such as the current 16-bit integers or any of 32-bit integers, 64-bit integers, 32-bit floating point variables, and 64-bit floating point variables) to store plot data internally in PLplot. Note, I am not referring to the PLINT variables here. It is the explicit 16-bit ones (e.g., short) that are of concern. The following commands show the counts of files and lines where " short " occurs within PLplot softw...@raven> find -name '*.c' -o -name '*.cpp' -o \ -name '*.cc' -o -name '*.h' \ |xargs grep -l " short " |wc -l 82 softw...@raven> find -name '*.c' -o -name '*.cpp' -o \ -name '*.cc' -o -name '*.h' \ |xargs grep " short " |grep -v // |wc -l 430 Replacing all the short types in PLplot by some special PLplot type named PLCOORD that is #defined to be short, long, float, or double depending on CMake option would be an excellent start on getting on top of this precision problem. Such an initial patch would be most welcome. :-) Of course, at the start the short option for PLCOORD would be the only option that worked. Additional analysis of code where PLCOORD types were used would have to occur to figure out the additional critical changes that would be required so the other precisions (a) worked at all and (b) worked without short precision limitations (maximum values, etc.) that might be currently built into the code. But the initial step to get this project off the ground would be to replace all short variables in PLplot source code by PLCOORD. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ ------------------------------------------------------------------------------ Centralized Desktop Delivery: Dell and VMware Reference Architecture Simplifying enterprise desktop deployment and management using Dell EqualLogic storage and VMware View: A highly scalable, end-to-end client virtualization framework. Read more! http://p.sf.net/sfu/dell-eql-dev2dev _______________________________________________ Plplot-general mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/plplot-general
