From help-request at octave dot org Tue Dec 28 11:30:33 2004 Subject: Re: Using automatic form of...gset xrange [-10:10] From: Joe Koski To: "John W. Eaton" , "Robert A. .Macy" CC: "Dmitri A. Sergatskov" , Octave Help Date: Tue, 28 Dec 2004 10:32:54 -0700 on 12/28/04 10:09 AM, John W. Eaton at jwe at bevo dot che dot wisc dot edu wrote: > On 28-Dec-2004, Robert A. .Macy 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 ... > gsplot ... > > 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 -------------------------------------------------------------