Re: Using automatic form of...gset xrange [-10:10]

[John W. Eaton]

On 28-Dec-2004, Robert A. .Macy <address@hidden> wrote:

| Dimitri,
| 
| Thank you for the reply.
| 
| ...uh, any idea of the logic behind all these extra steps?

The interface to gnuplot is simple.  To support something like

  a = 1;
  b = 10;
  gset yrange [a:b]

and have values for a and b inserted automatically before sending the
command to gnuplot would require a lot of extra effort and probably be
out of sync with gnuplot before too long anyway.  The current
implementation of gset just passes the line off to gnuplot without
additional processing, so we don't have to track changes to the
gnuplot set command in Octave's parser.

BTW, in the next "unstable" snapshot of Octave, all the
gnuplot-specific code in Octave's main lexer/parser has been moved to
a separate parser.  Now anything that looks like

  gplot ... <end of line>
  gsplot ... <end of line>

etc. is passed to a separate parser to be interpreted.

Advantages to doing things this way:

  * Things like linewidth will work without having to modify Octave's
    parser.

  * Octave's main parser now has 11 shift/reduce conflicts again,
    instead of 87.

  * The gnuplot stuff is now a dynamically linked .oct file, so it
    should be easier to replace/omit in the future.

Disadvantages:

  * The gplot/gsplot/etc commands must appear on lines by themselves,
    so you can't write

      gplot foo; [x, y, z] = some_other_thing (a, b, c);

    all on the same line.  I don't think this will be a big problem.

  * Things like

      gplot ([x, sin(x)])

    no longer work, but

      data = [x, sin(x)];
      gplot data

    still does.  This feature could be revived with some additional
    work, but I'm not convinced it is worth it.

  * Currently, Octave sends a cd command to gnuplot when Octave's
    working directory changes.  This feature has been dropped.  It
    could also be restored with some additional work, but again, I'm
    not sure that it is worth the effort.

In any case, we should be discouraging direct use of the
gplot/gsplot/etc commands and encouraging the use of the functional
plot commands that could be implemented using any graphics backend.
If those are not sufficient, then we should improve them so that they
will do the job rather than using the gnuplot-style commands
directly.  That way, you will not be stuck with gnuplot when something
better comes along.  So the recommended solution to your problem would
be to use "axis" rather than eval+gset.

Comments?

jwe



-------------------------------------------------------------
Octave is freely available under the terms of the GNU GPL.

Octave's home on the web:  http://www.octave.org
How to fund new projects:  http://www.octave.org/funding.html
Subscription information:  http://www.octave.org/archive.html
-------------------------------------------------------------