Re: [Plplot-general] Can PLplot do this?

[Alan W. I. <ir...@be...>]

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

software@raven> find -name '*.c' -o -name '*.cpp' -o \
-name '*.cc' -o -name '*.h' \
|xargs grep -l " short " |wc -l
82
software@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
__________________________