octave gset, graw

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

octave gset, graw

Volker Kuhlmann-5
I need to re-run some octave code which I developed 2 years ago, but get
informed that these functions are marked for removal:

  warning: gset is deprecated and will be removed from a future
  warning: version of Octave.
  warning: You should use the higher-level plot functions
  warning: ("plot", "mesh", "semilogx", etc.) instead
  warning: of the low-level plotting commands.
  warning: If you absolutely must use this function, use the
  warning: internal version __gnuplot_set__ instead.

Dito graw. Octave 2.1.71, SUSE 10.0.

One of the nice things of octave for me was that I can make it create
plots with the same visual appearance as I get from gnuplot directly,
thus allowing me to use a multitude of plot sources without getting an
optical potpourri throughout the document.

Yes I'd love to "use higher-level plot functions". How do I control
ticscales, location of the legend, and similar things with octave's
plot()? I created a general gnuplot initialisation file which I use with
gnuplot, and which I also read into octave and pass on with graw. Minor
adjustments then done with gset. Brilliant system. Ok gnuplot isn't what
one might call user friendly, but then neither is matlab's idiotic plot
tuning.

The info docs still say to use gset/gshow/etc, but help gset barfs
instead of telling me where to continue. It is not helpful to remove
documentation before the equivalent functionality is implemented in a
(presumably) better way. The manual and FAQ are dated 1998 - no help
there.

Please don't remove the mechanism to tune the plot output before
providing something better.

Thanks + greetings,

Volker  (please cc me any replies!)

--
Volker Kuhlmann
http://volker.dnsalias.net/

Reply | Threaded
Open this post in threaded view
|

Re: octave gset, graw

Søren Hauberg
I rarely need the high-level plotting routines that once was called
gset/graw/gshow, so I can't give you the best of answers. I'm under the
impression that the following renaming has takken place:

gset  -> __gnuplot_set
graw  -> __gnuplot_raw
gshow -> __gnuplt_show

This was done to reduce the dependency on gnuplot (I think).

/Søren

fre, 24 02 2006 kl. 04:09 -0600, skrev Volker Kuhlmann:

> I need to re-run some octave code which I developed 2 years ago, but get
> informed that these functions are marked for removal:
>
>   warning: gset is deprecated and will be removed from a future
>   warning: version of Octave.
>   warning: You should use the higher-level plot functions
>   warning: ("plot", "mesh", "semilogx", etc.) instead
>   warning: of the low-level plotting commands.
>   warning: If you absolutely must use this function, use the
>   warning: internal version __gnuplot_set__ instead.
>
> Dito graw. Octave 2.1.71, SUSE 10.0.
>
> One of the nice things of octave for me was that I can make it create
> plots with the same visual appearance as I get from gnuplot directly,
> thus allowing me to use a multitude of plot sources without getting an
> optical potpourri throughout the document.
>
> Yes I'd love to "use higher-level plot functions". How do I control
> ticscales, location of the legend, and similar things with octave's
> plot()? I created a general gnuplot initialisation file which I use with
> gnuplot, and which I also read into octave and pass on with graw. Minor
> adjustments then done with gset. Brilliant system. Ok gnuplot isn't what
> one might call user friendly, but then neither is matlab's idiotic plot
> tuning.
>
> The info docs still say to use gset/gshow/etc, but help gset barfs
> instead of telling me where to continue. It is not helpful to remove
> documentation before the equivalent functionality is implemented in a
> (presumably) better way. The manual and FAQ are dated 1998 - no help
> there.
>
> Please don't remove the mechanism to tune the plot output before
> providing something better.
>
> Thanks + greetings,
>
> Volker  (please cc me any replies!)
>

Reply | Threaded
Open this post in threaded view
|

Re: octave gset, graw

Bill Denney
In reply to this post by Volker Kuhlmann-5
On Fri, 24 Feb 2006, Volker Kuhlmann wrote:

> The manual and FAQ are dated 1998 - no help there.

I'm working to update the website.  Hopefully in the next week it will be
more help there.  If you feel this is a big hinderance, please feel free
to contribute to make the documentation easier to find and more
up-to-date.

> Please don't remove the mechanism to tune the plot output before
> providing something better.

This is being handled currently by the implementation of handle graphics.
The effort is trying to make the plot system modular (there will be one
set of octave functions to set the properties that can interact with any
number of back-ends to draw the plots).  You can see some results in this
with the Octaviz and Octplot graphics packages
(http://www.gnu.org/software/octave/related.html).

So, the code is not going away yet, and it won't go away until you are
able to better manage your plots.

Bill

--
A hundred thousand lemmings can't be wrong.  -- unknown

Reply | Threaded
Open this post in threaded view
|

Re: octave gset, graw

Daniel Sebald
Bill Denney wrote:

> On Fri, 24 Feb 2006, Volker Kuhlmann wrote:
>
>> The manual and FAQ are dated 1998 - no help there.
>
>
> I'm working to update the website.  Hopefully in the next week it will
> be more help there.  If you feel this is a big hinderance, please feel
> free to contribute to make the documentation easier to find and more
> up-to-date.
>
>> Please don't remove the mechanism to tune the plot output before
>> providing something better.

Will putting a script file "graw.m" in your personal script directory that does

function graw(varargin)

__graw(varargin)__

help any?

>
> This is being handled currently by the implementation of handle
> graphics. The effort is trying to make the plot system modular (there
> will be one set of octave functions to set the properties that can
> interact with any number of back-ends to draw the plots).  You can see
> some results in this with the Octaviz and Octplot graphics packages
> (http://www.gnu.org/software/octave/related.html).
>
> So, the code is not going away yet, and it won't go away until you are
> able to better manage your plots.

Could the group be more explicit about the roadmap for graphics?  I listen to John I hear one thing, other people say some other thing.

I understand some people want handle graphics, but I won't necessarily want to use that.  I've said before to the list that I find simply typing a command like "graw('set size square\n')".  Perhaps I'd migrate back to handle graphics but I always thought it cumbersome in the fact that one has to figure out first through parent/child/grandchild what it is they want to change.  HG commands were always something I'd save for the very end.

Also, retaining the "graw()" (which I understand now is meant to be graphics raw, not gnuplot raw) gives some fine control that might not be found in handle graphics.  For example, will there be ways in the print command to do something like

graw('set term gif animate 0.1\n')

?  Probably not.  Why?  Because the way Matlab works now, one is forced to first draw a plot and then change its properties as opposed to setting the properties and then doing the plot.  If I can set the properties first, with a command like above, I can string together a series of plots into an animation.

Handle graphics is a big project.  Will it require a lot of maintenance?  If there is an internal graphics engine for Octave, then HG would seem fairly easy conceptually.  But if the idea is to support multiple graphics engines will life be so simple?

I'm just wondering if the roadmap here is to make fine tuning plots slightly more difficult and inadvertently take away some flexibility.  I guess what I'm wondering is whether __graw__() is part of the roadmap for graphics.

Dan

Reply | Threaded
Open this post in threaded view
|

Re: octave gset, graw

Quentin Spencer
Daniel J Sebald wrote:

> Bill Denney wrote:
>
>> On Fri, 24 Feb 2006, Volker Kuhlmann wrote:
>>
>>> The manual and FAQ are dated 1998 - no help there.
>>
>>
>>
>> I'm working to update the website.  Hopefully in the next week it
>> will be more help there.  If you feel this is a big hinderance,
>> please feel free to contribute to make the documentation easier to
>> find and more up-to-date.
>>
>>> Please don't remove the mechanism to tune the plot output before
>>> providing something better.
>>
>
> Will putting a script file "graw.m" in your personal script directory
> that does
>
> function graw(varargin)
>
> __graw(varargin)__
>
> help any?
>
>>
>> This is being handled currently by the implementation of handle
>> graphics. The effort is trying to make the plot system modular (there
>> will be one set of octave functions to set the properties that can
>> interact with any number of back-ends to draw the plots).  You can
>> see some results in this with the Octaviz and Octplot graphics
>> packages (http://www.gnu.org/software/octave/related.html).
>>
>> So, the code is not going away yet, and it won't go away until you
>> are able to better manage your plots.
>
>
> Could the group be more explicit about the roadmap for graphics?  I
> listen to John I hear one thing, other people say some other thing.
>
> I understand some people want handle graphics, but I won't necessarily
> want to use that.  I've said before to the list that I find simply
> typing a command like "graw('set size square\n')".  Perhaps I'd
> migrate back to handle graphics but I always thought it cumbersome in
> the fact that one has to figure out first through
> parent/child/grandchild what it is they want to change.  HG commands
> were always something I'd save for the very end.

Cumbersome, maybe, but I always found it more intuitive when I want to
change a low-level setting than trying to search through gnuplot's
documentation. The other motivation for HG of course is "compatibility
with the other brand".

> Also, retaining the "graw()" (which I understand now is meant to be
> graphics raw, not gnuplot raw) gives some fine control that might not
> be found in handle graphics.  For example, will there be ways in the
> print command to do something like
>
> graw('set term gif animate 0.1\n')
>
> ?  Probably not.  Why?  Because the way Matlab works now, one is
> forced to first draw a plot and then change its properties as opposed
> to setting the properties and then doing the plot.  If I can set the
> properties first, with a command like above, I can string together a
> series of plots into an animation.
>
> Handle graphics is a big project.

Yes, it is. I think that's part of the reason for so many conflicting
proposals and no complete solution yet.

> Will it require a lot of maintenance?

I think it depends on how it's implemented.

>   If there is an internal graphics engine for Octave, then HG would
> seem fairly easy conceptually.  But if the idea is to support multiple
> graphics engines will life be so simple?

I think this is why John has advocated implementing an internal handle
graphics engine written as m files that interface with low-level
plotting functions unique to each graphics backend. It will of course
start with gnuplot as the default, but theoretically someone wanting a
different output generator could write the low-level interface functions
and use the same handle graphics fron end.

> I'm just wondering if the roadmap here is to make fine tuning plots
> slightly more difficult and inadvertently take away some flexibility.  
> I guess what I'm wondering is whether __graw__() is part of the
> roadmap for graphics.

I was under the impression that __gnuplot_raw__ isn't going away, but
that the change was done to discourage it's use in favor of the
high-level matlab functions, and eventually the HG implementation. I
think it was partly in response to the number of newbies on the mailing
lists trying to do things with the gset commands that could be done with
simpler commands using higher level matlab-compatible functions that
were already available.

-Quentin

Reply | Threaded
Open this post in threaded view
|

Re: octave gset, graw

Bill Denney
On Fri, 24 Feb 2006, Quentin Spencer wrote:

> Daniel J Sebald wrote:
>> Could the group be more explicit about the roadmap for graphics?  I
>> listen to John I hear one thing, other people say some other thing.

I'm not positive, but here is my guess:  handle graphics will be the
method used in 3.0.  When that happens, there will be a gnuplot back-end
that you can probably still tweak with __gnuplot_raw__ and other similar
commands.

>> I understand some people want handle graphics, but I won't necessarily
>> want to use that.  I've said before to the list that I find simply
>> typing a command like "graw('set size square\n')".  Perhaps I'd migrate
>> back to handle graphics but I always thought it cumbersome in the fact
>> that one has to figure out first through parent/child/grandchild what
>> it is they want to change.  HG commands were always something I'd save
>> for the very end.
>
> Cumbersome, maybe, but I always found it more intuitive when I want to
> change a low-level setting than trying to search through gnuplot's
> documentation. The other motivation for HG of course is "compatibility
> with the other brand".

I would say that searching octave documentation for how to plot something
in octave is far more intuitive and less cumbersome than searching gnuplot
documentation for how to plot something in octave.  Also, I have before
written scripts that output data that is then input by a gnuplot command
script.  Using octave commands to make octave plots seems the least
cumbersome.

>> Also, retaining the "graw()" (which I understand now is meant to be
>> graphics raw, not gnuplot raw) gives some fine control that might not be
>> found in handle graphics.  For example, will there be ways in the print
>> command to do something like
>>
>> graw('set term gif animate 0.1\n')
>>
>> ?  Probably not.  Why?  Because the way Matlab works now, one is forced to
>> first draw a plot and then change its properties as opposed to setting the
>> properties and then doing the plot.  If I can set the properties first,
>> with a command like above, I can string together a series of plots into an
>> animation.

There are other ways to string together plots into animations.  I
personally plan to make sure that there is an SVG output.  With SVG it is
trivial to convert it to a gif animation.  I may make that an option.  I
don't see how it makes it easier to make an animation by putting the
command before or after making the plots.

>> If there is an internal graphics engine for Octave, then HG would seem
>> fairly easy conceptually.  But if the idea is to support multiple
>> graphics engines will life be so simple?
>
> I think this is why John has advocated implementing an internal handle
> graphics engine written as m files that interface with low-level
> plotting functions unique to each graphics backend. It will of course
> start with gnuplot as the default, but theoretically someone wanting a
> different output generator could write the low-level interface functions
> and use the same handle graphics fron end.

I agree with this.  That is why I am trying to make sure that the
interface for the users and the backend developers is defined.  If I can
make a set of handles and then use it to make a plot on the screen, then
export it to an SVG, then make an animation out of it, ... then I'm going
to enjoy plotting significantly more (which is currently what I think is
the biggest weakness in Octave).

>> I'm just wondering if the roadmap here is to make fine tuning plots
>> slightly more difficult and inadvertently take away some flexibility.
>> I guess what I'm wondering is whether __graw__() is part of the roadmap
>> for graphics.
>
> I was under the impression that __gnuplot_raw__ isn't going away, but that
> the change was done to discourage it's use in favor of the high-level matlab
> functions, and eventually the HG implementation. I think it was partly in
> response to the number of newbies on the mailing lists trying to do things
> with the gset commands that could be done with simpler commands using higher
> level matlab-compatible functions that were already available.

Right, I think that __gnuplot_raw__ will continue to exist though it will
probably be moved another step away from the common users into part of the
gnuplot graphics backend.

Bill

--
"My mind is so numb and braindead; I feel I've just attended a three day
seminar on the future of plumbing."
   -- Rimmer, _Red Dwarf_ Series 8 Ep 1

Reply | Threaded
Open this post in threaded view
|

Re: octave gset, graw

Daniel Sebald
In reply to this post by Quentin Spencer
Quentin Spencer wrote:

> Daniel J Sebald wrote:
>> I understand some people want handle graphics, but I won't necessarily
>> want to use that.  I've said before to the list that I find simply
>> typing a command like "graw('set size square\n')".  Perhaps I'd
>> migrate back to handle graphics but I always thought it cumbersome in
>> the fact that one has to figure out first through
>> parent/child/grandchild what it is they want to change.  HG commands
>> were always something I'd save for the very end.
>
>
> Cumbersome, maybe, but I always found it more intuitive when I want to
> change a low-level setting than trying to search through gnuplot's
> documentation. The other motivation for HG of course is "compatibility
> with the other brand".

I won't argue against either of those points... although I think that in the gnuplot doc if one sees, for example

octave:5> graw('help set term gif\n')
octave:6>
 Syntax:
       set terminal gif
                        {tiny | small | medium | large | giant}
                        {{no}transparent} {{no}enhanced}
                        {font <face> {<pointsize>}}
                        {animate {delay <time>} {{no}optimize}}
                        {size <x>,<y>} {{no}crop}
                        {<color0> <color1> <color2> ...}

it isn't too difficult to figure out the capabilities at least.  Granted there is some reading involved, but hopefully when you've used the feature once, seeing this syntax summary jogs one's memory.


> I was under the impression that __gnuplot_raw__ isn't going away, but
> that the change was done to discourage it's use in favor of the
> high-level matlab functions, and eventually the HG implementation. I
> think it was partly in response to the number of newbies on the mailing
> lists trying to do things with the gset commands that could be done with
> simpler commands using higher level matlab-compatible functions that
> were already available.

That is pretty much how I understood things too.

Dan

Reply | Threaded
Open this post in threaded view
|

Re: octave gset, graw

Daniel Sebald
In reply to this post by Bill Denney
Bill Denney wrote:

> On Fri, 24 Feb 2006, Quentin Spencer wrote:
>
>> Daniel J Sebald wrote:
>>
>>> Could the group be more explicit about the roadmap for graphics?  I
>>> listen to John I hear one thing, other people say some other thing.
>
>
> I'm not positive, but here is my guess:  handle graphics will be the
> method used in 3.0.  When that happens, there will be a gnuplot back-end
> that you can probably still tweak with __gnuplot_raw__ and other similar
> commands.

OK.


> I would say that searching octave documentation for how to plot
> something in octave is far more intuitive and less cumbersome than
> searching gnuplot documentation for how to plot something in octave.

I'll concede that point.

> Also, I have before written scripts that output data that is then input
> by a gnuplot command script.  Using octave commands to make octave plots
> seems the least cumbersome.

Oh, certainly.  I mean 'plot(x)' and 'image(A)' win out any day on any computer.

>
>>> Also, retaining the "graw()" (which I understand now is meant to be
>>> graphics raw, not gnuplot raw) gives some fine control that might not
>>> be found in handle graphics.  For example, will there be ways in the
>>> print command to do something like
>>>
>>> graw('set term gif animate 0.1\n')
>>>
>>> ?  Probably not.  Why?  Because the way Matlab works now, one is
>>> forced to first draw a plot and then change its properties as opposed
>>> to setting the properties and then doing the plot.  If I can set the
>>> properties first, with a command like above, I can string together a
>>> series of plots into an animation.
>
>
> There are other ways to string together plots into animations.

In Octave?  Such as "movie(A)" or something?  Or maybe "print -dgifanim"?  Or do you mean make a series of graphs outside Octave and then string them together with some other utility.

>  I
> personally plan to make sure that there is an SVG output.  With SVG it
> is trivial to convert it to a gif animation.  I may make that an
> option.  I don't see how it makes it easier to make an animation by
> putting the command before or after making the plots.

Well, if the "print" command has a means of stringing together plots, I guess not.

>
>>> If there is an internal graphics engine for Octave, then HG would
>>> seem fairly easy conceptually.  But if the idea is to support
>>> multiple graphics engines will life be so simple?
>>
>>
>> I think this is why John has advocated implementing an internal handle
>> graphics engine written as m files that interface with low-level
>> plotting functions unique to each graphics backend. It will of course
>> start with gnuplot as the default, but theoretically someone wanting a
>> different output generator could write the low-level interface
>> functions and use the same handle graphics fron end.
>
>
> I agree with this.  That is why I am trying to make sure that the
> interface for the users and the backend developers is defined.  If I can
> make a set of handles and then use it to make a plot on the screen, then
> export it to an SVG, then make an animation out of it, ... then I'm
> going to enjoy plotting significantly more (which is currently what I
> think is the biggest weakness in Octave).

__graw__('set term gif animate\n');
__graw__('set output '''myfile.gif'''\n');
for i_image = 1:50
   x = <process some data>;
   plot(x);
end
__graw__('set output\n');

I realize it would be nice to have something more like

for i_image = 1:50
   x = <process some data>;
   plot(x);
   print -dgifa 'myfile.gif'
end

but it takes some non-trivial coding to enable this.

Dan

Reply | Threaded
Open this post in threaded view
|

Re: octave gset, graw

Bill Denney
On Fri, 24 Feb 2006, Daniel J Sebald wrote:

> Bill Denney wrote:
>
>> I agree with this.  That is why I am trying to make sure that the
>> interface for the users and the backend developers is defined.  If I
>> can make a set of handles and then use it to make a plot on the screen,
>> then export it to an SVG, then make an animation out of it, ... then
>> I'm going to enjoy plotting significantly more (which is currently what
>> I think is the biggest weakness in Octave).
>
> __graw__('set term gif animate\n');
> __graw__('set output '''myfile.gif'''\n');
> for i_image = 1:50
>  x = <process some data>;
>  plot(x);
> end
> __graw__('set output\n');
>
> I realize it would be nice to have something more like
>
> for i_image = 1:50
>  x = <process some data>;
>  plot(x);
>  print -dgifa 'myfile.gif'
> end
>
> but it takes some non-trivial coding to enable this.

I'm hoping to help do the non-trivial coding that will allow:

movie_handle = movie('file.mpg'); # or .avi or whatever
for i_frame = 1:50
   x = <some data>;
   plot_handle = plot(x);
   movie_handle = addframe(movie_handle, plot_handle);
endfor

My guess is that the movie_handle will have properties like:

frames (handles to figure, axis, or image objects that show the image)
resolution (height and width in pixels)
filetype ('mpg', 'avi', etc-- whatever we can handle)
some more that I can't think of at the moment.

Bill

--
"Patriotism is supporting your country all the time and the government
when it deserves it."
   -- Mark Twain

Reply | Threaded
Open this post in threaded view
|

Re: octave gset, graw

Daniel Sebald
Bill Denney wrote:

> I'm hoping to help do the non-trivial coding that will allow:
>
> movie_handle = movie('file.mpg'); # or .avi or whatever
> for i_frame = 1:50
>   x = <some data>;
>   plot_handle = plot(x);
>   movie_handle = addframe(movie_handle, plot_handle);
> endfor
>
> My guess is that the movie_handle will have properties like:
>
> frames (handles to figure, axis, or image objects that show the image)
> resolution (height and width in pixels)
> filetype ('mpg', 'avi', etc-- whatever we can handle)
> some more that I can't think of at the moment.

Looks good.

Dan

Reply | Threaded
Open this post in threaded view
|

Re: octave gset, graw

Stéfan van der Walt
On Fri, Feb 24, 2006 at 02:42:27PM -0600, Daniel J Sebald wrote:

> Bill Denney wrote:
> >I'm hoping to help do the non-trivial coding that will allow:
> >
> >movie_handle = movie('file.mpg'); # or .avi or whatever
> >for i_frame = 1:50
> >  x = <some data>;
> >  plot_handle = plot(x);
> >  movie_handle = addframe(movie_handle, plot_handle);
> >endfor
> >
> >My guess is that the movie_handle will have properties like:
> >
> >frames (handles to figure, axis, or image objects that show the image)
> >resolution (height and width in pixels)
> >filetype ('mpg', 'avi', etc-- whatever we can handle)
> >some more that I can't think of at the moment.

Advertising opportunity :)

I recently reworked octave-avifile.  It compiles with the latest
libraries in Debian, and I'd like to see people try it on different
platforms:

http://mentat.za.net

Stéfan

Reply | Threaded
Open this post in threaded view
|

Re: octave gset, graw

Volker Kuhlmann
In reply to this post by Bill Denney
Ok, I'm subscribed now.

[Mentioning that 1998 docs don't help with 2005 changes, to show that I
at least looked before asking]

>I'm working to update the website.  Hopefully in the next week it will
>be more help there.  If you feel this is a big hinderance, please feel
>free to contribute to make the documentation easier to find and more
>up-to-date.

I know nothing about this plotting change. The help for the respective
function, the docs coming with the software, and www.octave.org are all
silent. You can't be serious about me writing it up?

> This is being handled currently by the implementation of handle graphics.

Groan. Not like matlab, or?

Volker

--
Volker Kuhlmann is possibly list0570 with the domain in header
http://volker.dnsalias.net/                Please do not CC list postings to me.

Reply | Threaded
Open this post in threaded view
|

Re: octave gset, graw

John W. Eaton-6
On 25-Feb-2006, Volker Kuhlmann wrote:

| > This is being handled currently by the implementation of handle graphics.
|
| Groan. Not like matlab, or?

F'd if we do, f'd if we don't.

jwe

Reply | Threaded
Open this post in threaded view
|

Re: octave gset, graw

Volker Kuhlmann
In reply to this post by Daniel Sebald
> Will putting a script file "graw.m" in your personal script directory that
> does
>
> function graw(varargin)
>
> __graw(varargin)__
>
> help any?

(Assuming you meant __gnuplot_raw__(varargin))

No, gset/graw are internal functions with a special syntax that isn't
user-definable. Anyway, a gset.m in ./ isn't picked up.

This works:

    grawcmd='__gnuplot_raw__';
    if (~ exist(grawcmd)); grawcmd='graw'; end

        eval ([grawcmd '(str)']);

I could put that kind of thing in a wrapper function. What would be the
performance penalty?

Volker

--
Volker Kuhlmann is possibly list0570 with the domain in header
http://volker.dnsalias.net/                Please do not CC list postings to me.

Reply | Threaded
Open this post in threaded view
|

Re: octave gset, graw

Daniel Sebald
Volker Kuhlmann wrote:

>>Will putting a script file "graw.m" in your personal script directory that
>>does
>>
>>function graw(varargin)
>>
>>__graw(varargin)__
>>
>>help any?
>
>
> (Assuming you meant __gnuplot_raw__(varargin))
>
> No, gset/graw are internal functions with a special syntax that isn't
> user-definable. Anyway, a gset.m in ./ isn't picked up.

Oh yeah, that's right.

>
> This works:
>
>     grawcmd='__gnuplot_raw__';
>     if (~ exist(grawcmd)); grawcmd='graw'; end
>
> eval ([grawcmd '(str)']);
>
> I could put that kind of thing in a wrapper function. What would be the
> performance penalty?

Got me.  You're the expert, by default, on this one.  I see the conundrum now, however...

John, would it be possible to issue that warning just the first time that graw() is called?  I've done stuff like that before:

  static bool graw_first_call = true;
  if (graw_first_call)
    graw_first_call = false;
    issue_warning();
  else
    execute_graw_in_legacy_fashion();
  end

Dan

Reply | Threaded
Open this post in threaded view
|

Re: octave gset, graw

John W. Eaton-6
On 24-Feb-2006, Daniel J Sebald wrote:

| John, would it be possible to issue that warning just the first time
| that graw() is called?

That should be how it works now.

All future 2.1.x versions will continue to work they way they do now
(gset issues a warning, but still works).

For 2.9.5 and beyond, it will just be an error as the old names
have been removed.

jwe

Reply | Threaded
Open this post in threaded view
|

Re: octave gset, graw

Volker Kuhlmann
In reply to this post by Daniel Sebald
> >    grawcmd='__gnuplot_raw__';
> >    if (~ exist(grawcmd)); grawcmd='graw'; end
> >
> > eval ([grawcmd '(str)']);

This is silly. The only thing it achieves is backward compatibility with
older octaves, which can easier be done by creating a __gnuplot_graw__.m
containing a graw. So a string replace graw to __gnuplot_raw__ is the
best solution for cases where the use of graw is justified.

> John, would it be possible to issue that warning just the first time that
> graw() is called?

(And gset, gshow.)

Probably not worth spending a lot of time on, but it might prevent
having to change existing code before it has to be changed again for the
new plotting scheme, if one needs to see the important output in between
the 20th of the same warning.

Volker

--
Volker Kuhlmann is possibly list0570 with the domain in header
http://volker.dnsalias.net/                Please do not CC list postings to me.