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

[Joe Koski]

on 12/28/04 10:09 AM, John W. Eaton at address@hidden wrote:

> 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

Overall, that sounds like a big improvement, and the dropped features
wouldn't be too much of a bother.

To me the best new feature in gnuplot 4.0 is palette modulated 3D (pm3d).
Will that feature be exploited, for example, as a component of image()? That
would permit axis labels, titles, etc. to be passed to gnuplot for display
with images, and do away with the need for a separate image viewer in the
process.

Joe

> 
> 
> 
> -------------------------------------------------------------
> 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
> -------------------------------------------------------------
> 




-------------------------------------------------------------
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
-------------------------------------------------------------