From help-octave-request at bevo dot che dot wisc dot edu Sat Nov 22 23:51:03 2003 Subject: Re: Puzzled about scope/existence of globals From: Tomer Altman To: Glenn Golden , Date: Sat, 22 Nov 2003 21:50:24 -0800 (PST) Ah, okay. Now its clearer. Here's where my confusion lies: There's no analog of 'clear' that operates on globals. It just clears local/current scope references to global variables. I expect, when I do the following: global x; x = 5; clear x; For x the be completely obliterated. I simply don't see the point otherwise. I mean, unless you want to write messy code like this in a function: function y = foo() global x; y = x; clear x; x = bar(); y = y + x; endfunction This would be considered very bad style in any structured programming language; using one variable identifyer to represent two different values of different scope within the same context. But that is the only thing that I can think of where "clearing a global" makes any sense. Would it be possible to have the following? global x; x = 5; clear("x","global"); --- Cheers, ~Tomer On Nov 22, 2003 at 10:17pm, John W. Eaton wrote: jwe >Date: Sat, 22 Nov 2003 22:17:14 -0600 jwe >From: John W. Eaton jwe >To: TAltman at lbl dot gov jwe >Cc: Glenn Golden , help-octave@bevo.che.wisc.edu jwe >Subject: Re: Puzzled about scope/existence of globals jwe > jwe >On 22-Nov-2003, Tomer Altman wrote: jwe > jwe >| You know what? I was starting to notice some of the same strangeness, jwe >| but I became distracted & never fully investigated it. Poking around, jwe >| I've noticed some oddities: jwe > jwe >I think you also said you were working with 2.1.40, which is old, but jwe >you would only see one difference with 2.1.51 which is that global jwe >values are always intialized to [] unless you specifically initialize jwe >them yourself. This changes the behavior of your second function. jwe > jwe >| function scope_fun jwe >| jwe >| if ( ! exist("x","var") ) jwe >| global x = "foo" jwe >| x jwe >| else jwe >| global x = "bar" jwe >| x jwe >| endif jwe >| jwe >| endfunction jwe >| jwe >| octave> scope_fun jwe >| x = foo jwe >| octave> x jwe >| error: `x' undefined near line 5 column 1 jwe >| octave> global x jwe >| octave> x jwe >| x = foo jwe >| octave> x = 5 jwe >| x = 5 jwe >| octave> scope_fun jwe >| x = 5 jwe >| octave> clear x jwe >| octave> x jwe >| error: `x' undefined near line 10 column 1 jwe >| octave> scope_fun jwe >| x = 5 jwe >| octave> x jwe >| error: `x' undefined near line 12 column 1 jwe >| octave> jwe >| jwe >| --- jwe >| jwe >| My off-the-cuff analysis is that there is, in fact, somehow, *TWO* jwe >| global scope name-spaces: one for the interpreter environment, and one jwe >| for the "compiled" M-file environment. What I think is happening, is jwe >| that as soon as one is updated, it will try to "sync" with the other jwe >| environment. Of one of those global scopes' variables is 'cleared', jwe >| then the other one persists. Also, it seems that the interpreter jwe >| environment is "dominant", when they "sync"... jwe > jwe >I'm not sure why you are guessing about the behavior. jwe > jwe >| Here's the same test, but from the opposite perspective: jwe >| jwe >| --- jwe >| jwe >| function scope_fun2 jwe >| jwe >| global x; jwe >| jwe >| x jwe >| jwe >| clear x; jwe >| jwe >| x jwe >| jwe >| endfunction jwe >| jwe >| octave> scope_fun2 jwe >| error: `x' undefined near line 5 column 3 jwe >| error: called from `scope_fun2' in file jwe >| `/home/taltman/taltman-judean/code/octave/M-files/scope_fun2.m' jwe > jwe >With 2.1.51, you would see jwe > jwe > ans = [](0x0) jwe > jwe >for line 5, then the undefined variable error on line 9 after the jwe >clear statement. jwe > jwe >| octave> global x jwe >| octave> x = 5 jwe >| x = 5 jwe >| octave> scope_fun2 jwe >| x = 5 jwe >| error: `x' undefined near line 9 column 3 jwe >| error: called from `scope_fun2' in file jwe >| `/home/taltman/taltman-judean/code/octave/M-files/scope_fun2.m' jwe >| octave> x jwe >| x = 5 jwe >| octave> jwe >| jwe >| --- jwe >| jwe >| So I guess this bizarreness is due to how 'clear' operates, as well. jwe > jwe >I don't think it is bizarre, so perhaps you can point out specifically jwe >where you think it is bizarre, and the behavior you expect, and why. jwe > jwe >Think of each global variable behaving as though it exists in its own jwe >named Fortran COMMON block. Clearing a global is like deleting that jwe >COMMON block from the scope in which the clear statement appears. The jwe >globals associated with a function are created the first time a global jwe >statement inside a function is evaluated, but do not disappear when jwe >the function exits (that way, they are persistent across a function jwe >call, even if they are only mentioned inside one function). jwe > jwe >AFAIK, this is all Matlab-compatible behavior (with the exception of jwe >allowing initialization in the global statement as an extension -- to jwe >get that in Matlab, you have to do some extra work). If you find some jwe >way that global variables in Octave's do not work the same as they do jwe >in Matlab, then please describe precisely how Octave's current (i.e., jwe >2.1.51 or later) behavior is different. If you simply don't like the jwe >way that globals work in Matlab, then I think you should be asking jwe >questions about that over in comp.soft-sys.matlab. jwe > jwe >jwe jwe > ------------------------------------------------------------- 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 -------------------------------------------------------------