[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Plotting...
From: |
Ian Searle |
Subject: |
Plotting... |
Date: |
Wed, 22 Mar 1995 12:44:48 -0800 |
Hello all, I subscribe to the octave list primarily for the
education, I am not an Octave user :-) I have been following
some discussion about I/O and graphics. I think I could
contribute some information, since I have some experience.
Note that this is by _no_ means an attempt to convert Octave
users. Nor is this an attempt to start a flame-war or a
feature-debate. This is merely information. I hope you will get
something from it.
When I first started rlab, I decided to try and do away with
the classic file handles. You write to a file, by identifying
it with a string. Additionally, you can write/read to/from a
pipe by making `|' the first character of the string. Thus:
fprintf ("|gnuplot", "plot %s using 1:3\n", data_file);
works quite nicely. For quite a long time gnuplot was the only
plotting capability in rlab. All of the plotting capability
was implemented in script files. In fact, rlab is still
distributed with a set of files to allow plotting via
gnuplot. A nice thing about doing the plot interface this way
is that it is not too difficult to maintain/extend. In fact,
after I switched rlab to Plplot, a user who likes gnuplot
better, upgraded and extended the gnuplot interface completely
on his own.
There are some disadvantages to using gnuplot, which
ultimately caused me to switch to Plplot. (1) gnuplot plotting
must be done with temporary files, since gnuplot cannot read
data from stdin. (2) gnuplot lacks some important features,
primarily multiple plots per page, and (3) interactive
plotting with gnuplot requires the OS be multi-tasking (this
rules out DOS/Mac). Note that Plplot is not perfect either, I
will get around to criticizing it later :-) But, on the whole
Plplot is an excellent package. Furthermore, the
developers/maintainers are good people.
At present rlab uses Plplot for interactive graphics. The
Plplot library is linked into rlab during the build (unless
the user does --with-gnuplot, or the Plplot library is not
found). I am fairly happy with the implementation. Basically,
I mimicked the Plplot API with builtin rlab functions. These
functions are all nicely segregated into a single .c and .h
file. Some #ifdefs take care of the rest of the
segregation. The builtin low-level plotting functions are
"hidden"; in rlab variables that begin with the `_' character
are not "visible" (but they are usable). The high level
plotting functions, like plot(), and plmesh(), are written in
script.
There are several benefits to this method: (1) The high level
plot functions were much easier to write (as opposed to doing
them in C), and (2) the plotting functions are more
"adaptable". If Plplot were to undergo big changes, or someone
wanted to use another plot library, the effort is minimal (not
zero). Additionally, users can implement new high level
plotting functions on their own, without writing builtin
functions.
Plplot offers some advantages over gnuplot:
(1) It does not require a multi-tasking OS to
use. Thus the DOS and Mac ports of rlab have
interactive plotting quite similar to the Unix
version.
Plotting does not require temporary files with
Plplot.
(2) Plplot offers multiple plots per page.
(3) Plplot offers a nice, Tcl/TK graphics window for
Unix workstations. Printing, zooming, and
color-pallete modifying.
The only disadvantage (IMHO) to using Plplot is the lack of
Postscript fonts in the hardcopy.
I hope this information/experience is useful to someone...
-Ian Searle
- Plotting...,
Ian Searle <=