[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Contour Plots, Delaunay triangulation, and Plotmtv

From: Ted Harding
Subject: RE: Contour Plots, Delaunay triangulation, and Plotmtv
Date: Mon, 14 Jun 1999 10:46:47 +0100 (BST)

On 13-Jun-99 John Smith wrote:
> A summary of my progress:
> Given some data not sampled from a rectangular grid (mine came on a
> polar grid), plotmtv can triangulate the data and draw contours on the
> triangular mesh. My experience was that the meshing algorithm was poor.
> The code's documentation admits that meshing is not perfected yet.
> I replaced it with Steve Fortune's 2D Delaunay meshing algorithm
> (indirectly available from, and generated a much
> better mesh. The substitution was a simple hack. An example of one of
> these contour plots is at

Does this mean you hacked the Delaunay code into PlotMTV? If so, this
looks very interesting indeed!

> Ted Harding provided a simple framework of Octave code to drive plotmtv
> (see previous emails), which is dispite its simplicity, must be worthy
> of wider distribution.

I've been using PlotMTV since about 1995 (those were the days when
gnuplot was going through a very bad patch [no pun intended, though
having written it I now see that it's an accurate summary .. ] and
contouring, especially, was a disaster). After trying PlotMTV I liked it
so much that it became my preferred vehicle for quality graphics output
from octave, and it still is.

I still use gnuplot (now much better than it was) for looking at graphics
on-the-fly and for some production output.

I created a suite of octave/PlotMTV interface files, some emulating the
octave "plot" command syntax (and based on hacking the chain of files
that lead from "plot(...)" to the final output). However, these fail to
exploit PlotMTV's resources properly, and they're internally messy.

They also ran out of road when octave definitively changed from allowing
'fprintf("filename",...)' to requiring 'fprintf(fileid,...)'; I think
I have mended most if not all of these routines, but I haven't tested
them all. (Some of my code repositories are a bit like a drawer-full
of socks ... ). However, I'd be happy to wrap them up and put them
somewhere, if someone would tell me where.

However, I can't claim that they are anything like the best way to do
these things, and the options opened up by the "tela hack" (see below)
as well as John's Delaunay enhancement suggest that the whole thing
could probably be done in a differen and much better way.

> I am happy to say that with Octave+Fortune+Plotmtv I now generate
> better plots than with Matlab! A reversal of the position 4 days ago.
> Thanks to everyone,

I'm happy that John has made such good progress, which looks as though it
could turn out to be helpful to us all.

Although PlotMTV has several advantages over gnuplot, it also has some
comparative disadvantages. Perhaps the most important one, in its
standard form, is that when evoked it does one thing only: It reads the
data file and draws the plot. After that, it is totally enclosed within
the X event loop (i.e. responds only to mouse clicks and key presses),
and is beyond the control of the calling program. Any intrinsic changes to
the plot require evoking a new instance of the program. This is why the
"tela hack" plotmtv1.4.3t is interesting: the calling program remains
connected via a socket, and in addition can send an artificial X event
causing PlotMTV to re-start. I have been experimenting with the "tela"
program and its usage with PlotMTV, and find this version of plotmtv
extremely flexible when used in this way.

Another thing which PlotMTV lacks compared with gnuplot -- especially
where contouring is concerned -- is that with gnuplot you can set the
"term" to "table" and obtain the coordinates of the points and lines
that get plotted. This partially compensates for the lack of the MatLab
facility whereby [...] = contour(...) generates numerical data defining
the plot.

There is at present no way to extract the plotting data from PlotMTV
(and, given that you can rotate and zoom, etc, in PlotMTV, it would have
to be of a different form anyway, namely the numerical description of the
object being plotted, of which the visible plot is just one possible
aspect). Maybe this might be the next useful hack of PlotMTV...

This also leads back to the lack of a built-in "contour" function in
octave, whose job would be to generate these numerical data.

These are just off-the-cuff thoughts. I hope others also will push this
discussion ahead.

Best wishes to all,

E-Mail: (Ted Harding) <address@hidden>
Date: 14-Jun-99                                       Time: 10:46:47
------------------------------ XFMail ------------------------------

Octave is freely available under the terms of the GNU GPL.  To ensure
that development continues, see
Instructions for unsubscribing:

reply via email to

[Prev in Thread] Current Thread [Next in Thread]