Re: Hold on and hold off in octave-2.9.8

[Joe Koski]

on 9/10/06 2:35 PM, Joe Koski at address@hidden wrote:

> on 9/9/06 2:30 PM, Joe Koski at address@hidden wrote:
> 
>> on 9/9/06 2:09 PM, John W. Eaton at address@hidden wrote:
>> 
>>> On  9-Sep-2006, Joe Koski wrote:
>>> 
>>> | Hi all,
>>> | 
>>> | I have a loop in one of my scripts:
>>> | 
>>> | for i = 1:num_c2f
>>> |   ifig = ifig + 1;
>>> |   figure(ifig);
>>> |   clg;
>>> |   legend('off');
>>> |   axis('auto');
>>> |   title(['Coarse to Fine ',int2str(i),' vs. Signal']);
>>> |   xlabel ("Time, s")
>>> |   ylabel ("Amplitude")
>>> |   hold on;
>>> |   plot(t,x,'r');
>>> |   plot(t,c2f(i,:),'b');
>>> |   hold off;
>>> | end
>>> | 
>>> | With octave-2.1.73, the "hold on" and "hold off" serve to superimpose the
>>> | two plot commands onto one plot frame. With octave-2.9.8, only the second
>>> | plot appears in the axes, and the first plot disappears. This is all on my
>>> | Mac with octave builds from scratch on OS X 10.4.7, Xcode-2.4, etc.
>>> | 
>>> | Has the use of "hold on" changed?
>>> 
>>> It should not have changed.
>>> 
>>> I can't run your code above since I don't have all the data required,
>>> but the following works for me:
>>> 
>>>   x = linspace (-10, 10, 200)';
>>>   hold on
>>>   plot (x, sin (x));
>>>   plot (x, cos (x));
>>>   hold off
>>> 
>>> Does this work for you?
>>> 
>>> jwe
>> 
>> John,
>> 
>> Yes, the simple test works correctly on my machine, both when I paste
>> line-by-line, and when I place the commands in a simple test_hold_on.m file.
>> 
>> I'll be in and out today, but I can try things like constructing a test loop
>> and placing other items like legend() inside the loop. It takes my code
>> about 5 minutes to get to that sequence of plots, so I need to come up with
>> a faster case for debugging that still replicates the problem.
>> 
>> This is the second time that this has happened, but the loops are very
>> similar.
>> 
>> When I combined the plot commands into a single plot command, I did get what
>> I wanted.
>> 
>> Joe
>> 
> John,
> 
> After much tinkering, I couldn't exactly duplicate the problem in a short
> script, although the problem in the long script is very reproducible and can
> be controlled by using a single plot command (without hold on and hold off).
> 
> The problem seems to be associated somehow with figure.m or what is called
> there. When I was using octave-2.9.7, figure.m wasn't finished, so I used my
> old figure.m that allows me to set fontsize and fontname via global
> variables and a __gnuplot_set__ command. It almost works. Now 2.9.8 has
> figure.m updated, but, at least on my Mac, all figures appear with the plot
> window labeled "Figure 0", not with the number assigned by n in figure(n).
> When I attempted to fix that, I got into some logic problems in
> __plot_globals__.m, so I punted (it's football season).
> 
> I guess I'll concede until I understand how to set the figure window number
> correctly.
> 
> Is it an octave bug that every plot window is Figure 0, or is it just my Mac
> version?
> 
> Joe
> 
To answer my own question, I tried some plots in X11, and the correct plot
numbers appear with each plot window. Apparently the figure number problem
is related to the use of the Mac AquaTerm interface.

In the old 2.1.73 figure.m, there is a line

   eval (sprintf ("__gnuplot_set__ term %s %d\n", gnuterm, f));

where gnuterm is the terminal type (aqua for AquaTerm) and f is the number
in figure(f). Where is the equivalent line in the new octave? My initial
search could not find it.

Joe