[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Using automatic form of...gset xrange [-10:10]
From: |
Joe Koski |
Subject: |
Re: Using automatic form of...gset xrange [-10:10] |
Date: |
Tue, 28 Dec 2004 10:32:54 -0700 |
User-agent: |
Microsoft-Entourage/11.0.0.040405 |
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
-------------------------------------------------------------