Re: Matlab ginput

[Ted Harding]

( Re Message From: John W. Eaton )
> 
> On  2-Dec-1996, Mario Storti <address@hidden> wrote:
> 
> : BTW, is there a way to know the aspect ratio of the gnuplot window?
> 
> I don't know if gnuplot can return this information.  Even if it can,
> it is not currently possible to have it returned in a variable in Octave.
> 
> : I want  to have the same scale  factor in both  axis, since I'm plotting
> : finite element meshes, and similar things. In Matlab 3.5 for DOS there
> : was the axis('square') feature.
> 
> With some terminal drivers, the commands
>   set size square
> or
>   set size ratio 1
> will set the plot axes to be square, though the scales are not
> necessarily forced to be the same, so circles may still be displayed
> as ellipses.  For example,
>   gnuplot> set size ratio 1
>   gnuplot> set parametric
>         dummy variable is t for curves, u/v for surfaces
>   gnuplot> plot sin(t), cos(t)
> shows a circle on my X display, but
>   gnuplot> set xrange [-2:2]
>   gnuplot> replot
> turns it into an ellipse.
> 
> This works with gnuplot 3.6beta, anyway.  I didn't check earlier
> versions.
> 
> jwe

With regard to the above: I haven't used 3.6-beta, but am a long-time user
of gnuplot-3.5. In 3.5, the "set size <anything>" command sets the size of
the total /plotting/ area, including tic-labels, axis labels, plot title,
etc. The /graph/ itself (i.e. the axes and the plotted points) fits into
this according to the space taken up by the "furniture". Therefore it is
not possible to directly control the size of the /graph/, and you can only
get a 1:1 aspect ratio for the /axes/ by experiment. Also, a size setting
that gives 1:1 on a screen display may well give non-1:1 when printed on
paper. I know there were intentions to address these and other questions
during the development of 3.6, but can't answer for where they're at.

With regard to the other query from Jay St Pieere ("I wonder how hard it
would be to make a modification to the gnuplot source code to allow it to
support a ginput interface"), my guess is that this might be possible. It
would involve modifying, not gnuplot, but gnuplot-X11 (which is a
"backend" to gnuplot that gnuplot writes to, which in turn writes to the X
display). In fact, the best approach would be to produce a totally
different X "back-end" which could interpret gnuplot X-output (the
character stream), and have a mouse-event handler built-in. If this could
then write to file/named pipe/screen (and be based on Tcl/Tk perhaps) then
it might be possible.

But this would not be a trivial task, and I myself don't propose to try --
for the following reasons.

Based on my experience of 3.5 (and I may be doing 3.6-beta an injustice),
while gnuplot is a very useful rough-and-ready graphics display tool, and
can produce quite decent output on many occasions, it is not a top-class
package for "production" output. As well as the sort of minor roughness
such as the "size" question above, 3.5 at least was capable of making a
total mess of contouring and of surface plotting, and there are many other
technical shortcomings as well. Unless 3.6 (when finished) solves all
these problems, I would remain of the same view of gnuplot. Gnuplot's
basic problem is that it tries to be all things to all "terminals", and
builds the lot into the main code (with the partial exception of X11).
When 3.6 was first mooted, there was discussion of moving ALL the
terminal-dependent code out into backends like gnuplot-x11, with gnuplot
itself concerned only with generating "terminal-independent" code. If they
had gone down this road I would have joined in enthusiastically, but
apparently they decided not to, and I think this means that gnuplot is
going to continue to try to break out of its dead-end, but in fact only
tinker with the problem. My understanding is that, while this approach
would have been straightforward on UNIX systems, it would have been too
difficult, or impossible, on other OSs, and there was a policy decision to
keep gnuplot "universal". So be it. But then my wish is to see something
other than gnuplot.

Gnuplot has served octave well, but is not adequate to allow octave to
reach its full potential. Octave has reached a new stage of maturity, and
it is time to address the graphics question seriously. Along with this
goes the contouring/surface-plotting question. Again, up to a point
gnuplot has served octave reasonably well for these two purposes, but
(leaving aside the occasional complete collapse of contour/surface) there
are important possibilities which remain remote (though not absolutely
impossible) so long as these functions are delegated to gnuplot, rather
than being computed within octave.

1. You cannot directly obtain the coordinates of the countour lines
   (planar or surface) as you can in MatLab (where the function "contour"
   returns lists of numerical coordinates directly to MatLab); the best
   you can do in gnuplot is to "set terminal table" and "set output file",
   and then write an octave function to recover this information from the
   file.

2. Similar considerations apply to surfaces themselves.

3. (A different point). It is not possible to fill, shade or colour boxes,
   facets of surfaces, or bands between contours etc, in gnuplot. This is
   because all these things are simply collections of line segments to
   gnuplot, which has no concept of closed region.

So far, using octave, I have on accasion substituted other graphics
software (mainly PlotMTV and sometimes GLE) for gnuplot, especially when I
want a professional finish or special effects (not so special -- these are
not only normal expectation for good presentation, but often essential to
represent the information at all).

Therefore I warmly welcome John's announced intention to develop octave
graphics in a new direction, and will be happy to help as best I can.
The main thing needed by anyone who wants to think about "new graphics for
octave" is what the "graphics output stream" is expected to look like.
Given that, we can try the effects and capabilities of different tools.

Given these views, I think modifying gnuplot for "ginput" would be yet
another stop-gap in the long line of such attempts to rememdy gnuplot
deficiencies.

This is also the moment to, at least, put contouring where it belongs:
fair and square in octave!

Sorry to have launched a mini-treatise on the questions, but the above
(and a good deal else besides) has been building up steam for some time.

Meanwhile, my hearty thanks and deep appreciation to John Eaton for having
brought octave to where it is, and for his continuing efforts and
intentions to further enhance it.

Best wishes to all,
Ted.                                    (address@hidden)