[MATRIX-SIG] [long] A NO-Proposal for a plot-package

[Janko Hauser]

Hello here are some of my thoughts regarding the plot-discussion,
which comes up once in a while.

First some of the things I think a ubiquitous plotpackage should cover:

There a some fields wich can be identified:

The ``normal'' function plotting (x-y-plots) with lines or markers or
error-bars. Often one wants to have more than one y- or x-axis here.

All the different types of 2 or 2 1/2 dimensional plots, like
contour-plots, filled contours, vector- and surface-plots. This are
normaly plots on grid. More and more the grids are not equidistant and
the hole field of triangular grids is coming. The view of this grid
changes more from plane views to perspectiv views of more than one of
these grids. (hor. and vert. slices through a data-cube) I think here
stops the field of plotting and the field of visualiztion begins. I
mean that the more dimensions are involved into the plot, the more
arise the need for interactiv movement of the view, or changing of the
color-palettes. So here you must work with the plot or better the view
onto the data. These plots are seldom simple to be printed on
paper. The next step into this direction is the display of isosurfaces
and volume-rendering.

Of course all of this plottypes should be able to be animated, because
of the volume of plots we want to see :-)

OK, than there are field of business graphics, like bar and pie-charts
also in more than one dimensions. Histograms are the same class. Here
it is very important to have rich set of text-functions in boxes, with
shapes or raised against the plot itself.

Than there is the hole field of statistical plots, which I don't know,
but I see often some strange things in such plots.

There is currently no free package wich does all these things. So we
can't wrap up something. (If I'm wrong here, please say it to me )
And there will be more things in the future like building of simple
point and click interfaces to look at some preprocessed data. So there
should be the possibility to connect to a GUI-interface, like Tk.

At the moment there are different ways to plot from python. (write a
Matlab-readable ASCII-file and plot this with Matlab :0)

Honestly, I know from ways to plot over gnuplot, mathematica, pgplot,
tk/blt, plplot, gist.

Especially plplot/pgplot and gist support a wide range of
plotprimitives. So these packages can be and are used to build a new
plot-system in python. But, (there must always be a but, eh?) they are
used in a mixed way. The high-level functions, which are present are
used and the missing parts are build from scratch. I think this way
has some limits, because there is always a mix from changes which can
be done in python and things which must be done on the
c-language-level. One example is the axis-system in 3d in the gist
package. Gist has nice autoscaling and rescaling with mouse-support in
2d. But the axis in 3d are plotted with different routines, the
labeling happens in a different way.

The worst case is, that I use different and overlapping packages to
fullfill my plot-requirements. I think this is bad, because the hole
system becomes more and more a hack, rather then developing to a
kitchen-sink-plot-system with wide application-range. (I don't want to
say, that the current implementations are hacks, but if I try to
change something, than it will become a hack, but I must say here,
that I'm very happy to have something with which I can generate plots
with Numpy here and now)


Here are some more specific requirements:

1) Use standard or at least very portable graphics-libraries: If the
effort is done to build a new plot-system it should be availabel with
some drivers on all platforms, where Numpy is availabel. I think the
two most wiedly available standards are postscript and opengl, which
can both be accsessed trough python (I have a nearly running
postscript-driver, which supports all of the further down mentioned
primitives)

If one use librarys like the above, very different fields can be
attacked, like molecular-modelling with opengl without learning a new
graphics-system or flow-diagramms with postscript.

2) Plots should be interactiv in a way that one can interact with the
plot directly, point to some locations and get the corresponding
values. This is possible with the opengl-driver.

3) At least the 2d plots should have or be able to have publication
quality. That's the major drawback of opengl. So here jumps the
postscript-driver in. For the real 3d-plots (like volume-rendering)
good tiff-files should be enough. But the access to the driver should
be seperated, so one can generate a hole bunch of plots on a Cray
without the need of opengl. (Although SGI owns them :-)) 

4) Following plot-primitives should be supported by any driver:

	markers at a point

	lines

	closed lines

	filled areas (filled with one color or pattern)

	bitmap areas (used for things like ligthing, shades)

	text which should be rotateable (ascii and some special
	fonts). The size of the text-surrounding box should be
	known.

Here is some room for higher primitives, like box and vector,
errorbars and so on. But this can also directly be handled by the
plot-routines.

5) These primitives should be there in every backend. 

6) The process queue can be:

data -> plot-primitive -> transformation -> scaling, normalization ->
put into viewport with aspect-ratio or big as possible

7) More than one window, more than one viewport in one window. The
viewport should be divided into a plot-area and the space for axis and
annotations. In this way the plots with multiple axis are not a
problem. Perhaps one needs axis in the plot-area, also this can be
done in that way. Each axis should be handled independant.

8) There should be a way for explicit axis-paths with
annotations. Standard creator and custom one. I think the
axis-handling is a crucial point in all existing packages. Normally the
hole axis-system is handled. One has now control over the strings, which
are plotted. So dates are really hard to plot. And what happens if one
wants to plot in polar-coordinates or with a cartographic projection? 
The axises of the plot should have similar handles like every other
plotobject and each axis should be seperated.

9) The hole package should mainly be written in python, only then
everybody can change it to her/his will. And additions are easier,
because there is then one concept of plotting. So perhaps other
packages can be incorporated under the same concept or in clear
derivation of this concept. If there are performance problems these
can be addressed specifically through an extra c-module.

10) In the end of the queue the plotobjects should be in clear
data-structure, which can be saved for example or given to different
drivers. This data-structure is a class with some special dictionaries
for different plot-types and actions. To have here one standard form
of structuring is maybe a hart thing to achieve. The advantage is,
that new plotroutines must only produce such a structure, so they
don't need to interact with the driver directly. This reduces the
hacking with driver-tricks. (But everybody can use the driver-routines
for such tricks, if she/he is in a real need for this  :-)

11) One additional drawback is the hole experience wich is incorporated in
other plotting-libraries. It's is not so easy to use one special
feature in one particular plotting-library, here is very much work in
redeveloping the circle. I don't know much about VTK for exapmle, but
I think all these great routines can't easyly be imported in this
framework, because VTK has it's one framework. But I think at the
moment an arriving VTK-module will not address the basic plotting
needs. And if we have general plot-objects, it should be possible
to write convertors to VTK-data-objects.

So, this is the end of the first part, which is mainly to bring some
things up for discussion. I will try to develop some ideas for the
system itself, but this will take some time, but the discussion can
start now. 


	
__Janko





_______________
MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________