Quantcast

Compatibility considerations of "clear"

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Compatibility considerations of "clear"

Philipp Kutin
In Octave, issuing a plain "clear" clears both workspace and global
variables. This is a little surprising to someone working with MATLAB,
but from the command line it's only a minor issue. However, it may
have compatibility implications when used from a function.

There does exist M code in the wild that calls "clear"
programmatically. I guess that it's mostly people feeling clearing
data manually sometimes, but occasionally, it can be justified. For
example, when reading in some large data and reordering it to
normalize to one's convention -- it may be a sensible move to clear a
temp variable before the function returns if further memory-intensive
operations are subsequently carried out.

I propose making plain "clear" only clear the workspace-local
variables, and adding an option "-a"/"-all" for the current behavior.
What do you think?

--Philipp
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Compatibility considerations of "clear"

bpabbott
Administrator
On Aug 14, 2013, at 12:17 PM, Philipp Kutin wrote:

> In Octave, issuing a plain "clear" clears both workspace and global
> variables. This is a little surprising to someone working with MATLAB,
> but from the command line it's only a minor issue. However, it may
> have compatibility implications when used from a function.
>
> There does exist M code in the wild that calls "clear"
> programmatically. I guess that it's mostly people feeling clearing
> data manually sometimes, but occasionally, it can be justified. For
> example, when reading in some large data and reordering it to
> normalize to one's convention -- it may be a sensible move to clear a
> temp variable before the function returns if further memory-intensive
> operations are subsequently carried out.
>
> I propose making plain "clear" only clear the workspace-local
> variables, and adding an option "-a"/"-all" for the current behavior.
> What do you think?
>
> --Philipp

From Matlab ...

-----------
If X is global, clear X removes X from the current workspace, but
leaves it accessible to any functions declaring it global.
clear GLOBAL X completely removes the global variable X.
clear GLOBAL -REGEXP PAT removes global variables that match regular
expression patterns.
-----------

Octave is intended to be compatible with Matlab, so this is a bug.  Would you file a bug report?

        https://savannah.gnu.org/bugs/?group=octave

Ben

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Compatibility considerations of "clear"

Jordi Gutiérrez Hermoso-2
In reply to this post by Philipp Kutin
On 14 August 2013 12:17, Philipp Kutin <[hidden email]> wrote:
> In Octave, issuing a plain "clear" clears both workspace and global
> variables.

What's the difference between those two?

> I propose making plain "clear" only clear the workspace-local
> variables, and adding an option "-a"/"-all" for the current behavior.
> What do you think?

It appears that you have may have neglected reading "help clear"?

- Jordi G. H.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Compatibility considerations of "clear"

Philipp Kutin
In reply to this post by bpabbott
On Wed, Aug 14, 2013 at 6:24 PM, Ben Abbott <[hidden email]> wrote:
> -----------
> If X is global, clear X removes X from the current workspace, but
> leaves it accessible to any functions declaring it global.
> (...)
> -----------

Heh, that sentence is thoroughly confusing. The way I see it and from
experience, MATLAB behaves like this: to have a global, i.e.
process-wide variable, you first "declare" it using "global
<varname>". If it does not exist in the global workspace, it gets
initialized with the empty matrix. From this point on, <varname>
refers to that single instance of the variable *in this function*.

The second, orthogonal, issue is how you access this variable from
other functions (or at the prompt). Simply writing <varname> does
*not* refer to the global, but to a variable of the same name in that
workspace from whose context the reference happens (I'll refer to it
as the "current" workspace from here on). Thus, you must also declare
the global in the other function to access it.

So far, so good. How does "clear" behave? Without any additional
arguments, it clears all names from the current workspace. For
non-global variables, the memory pertaining to each name may also be
freed (more exactly, only if the then-decreased reference count
reaches zero, of course), because there is then no way of accessing it
any more. However, this is not the case with global variables: it it
unknown where they might be accessed from.

So summarizing, for globals:
- "clear <varname>" merely removes the way of accessing the global by
its name (i.e. makes the name refer to a function-local variable again
[*]).
- "clear global <varname>" also frees the memory associated with the
variable of that name.

[*] I don't know the specifics of what happens if a global variable is
declared that shadows an already existing local one, but I guess that
it's what you'd expect.

As example session could look like this (from memory, can't verify right now):
$ global a
$ a
  ans = []
$ a = 5;
$ clear a  % "a" does not refer to the global from here on
$ a
  ??? error: no variable 'a'
$ global a  % let's see it again
$ a
  ans = 5
$ clear global a
$ a  % nope, now it's gone forever
  ??? error: no variable 'a'
$ global a  % initialize it anew
$ a
  ans = []

> Would you file a bug report?

I'll see if I can procude some code if there's general consensus that
this needs fixing. My suggestion is only about changing some already
existing high-level behavior, so I hope I'll manage to see through it.

So, reading the quote from the docs again,
> If X is global, clear X removes X from the current workspace, but
> leaves it accessible to any functions declaring it global.

Here, the five mentions of "X" (the 4th and 5th being "it") refer to
different concepts. De-mystifying,

 "If [the name] X [refers to a variable that] is global, clear [the
string "X" due to command syntax] X removes [the binding of the name]
X [to the global variable named by it] from the current workspace, but
leaves it [the variable data] accessible to any functions declaring it
global."

The last part doesn't make too much sense. We cannot know which
functions are "declaring it global", as they may not have been loaded
yet (or because the global declarations may probably be even from
eval'd code). So the last part should be reading "but leaves the
associated variable in memory" or similar.


On Wed, Aug 14, 2013 at 6:26 PM, Jordi Gutiérrez Hermoso
<[hidden email]> wrote:
>> (...) workspace and global variables.
> What's the difference between those two?

By "workspace" I meant the unit of variable scope. Since the MATLAB
language does not have lexically scoped variables, the scope of an
automatic variable is usually a single function. Then there are two
other workspaces: the "interactive" workspace where all your session
vars are stored, and the global workspace, containing all global
variables. That's only describing the conceptual view, not a
particular implementation. As for "persistent", it's more a property
of a variable with function scope than an own scope in its own right
IMO.

> It appears that you have may have neglected reading "help clear"?

Oops, right. Then the only thing I suggest is that globals are not
cleared for the plain "clear" invocation.


--Philipp
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Compatibility considerations of "clear"

John W. Eaton
Administrator
On 08/14/2013 02:16 PM, Philipp Kutin wrote:

[...]

We aren't stupid, you don't have to spell out every little detail.  We
know what a workspace is, y'know?

I think the attached patch will fix the behavior for clear without any
arguments.

Is the current Octave behavior for functions also wrong?  Given the function

   function foo ()
     persistent x
     if (isempty (x))
       disp ('x is not initialized');
       x = 1;
     end
   end

what do the following commands do?

   foo
   foo
   foo = 1
   foo
   clear foo
   foo
   clear foo
   foo

In any case, it looks like the documentation for clear in Octave no
longer matches its behavior with regard to clearing functions.

jwe

diffs.txt (892 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Compatibility considerations of "clear"

bpabbott
Administrator
In reply to this post by Philipp Kutin
On Aug 14, 2013, at 2:16 PM, Philipp Kutin wrote:

> On Wed, Aug 14, 2013 at 6:24 PM, Ben Abbott <[hidden email]> wrote:
>> -----------
>> If X is global, clear X removes X from the current workspace, but
>> leaves it accessible to any functions declaring it global.
>> (...)
>> -----------
>
> Heh, that sentence is thoroughly confusing.

Ok. Since that is a cut-n-paste from Matlab, please direct your complaints to Mathworks.

Ben

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Compatibility considerations of "clear"

Philipp Kutin
In reply to this post by John W. Eaton
On Wed, Aug 14, 2013 at 9:25 PM, John W. Eaton <[hidden email]> wrote:
>
> We aren't stupid, you don't have to spell out every little detail.  We know
> what a workspace is, y'know?

Um, I didn't describe it in such detail because I assumed all of you
"stupid", but to agree on a common mental model for how the language
maps names to values... the exact semantics of scope, and so on. After
all, you did get that one detail wrong, and even if you "know what a
workspace is", tiny differences like these may have a significant
impact in how the software is perceived when you're supposedly giving
much weight to compatibility.

--Philipp
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Compatibility considerations of "clear"

Philipp Kutin
In reply to this post by bpabbott
On Wed, Aug 14, 2013 at 9:47 PM, Ben Abbott <[hidden email]> wrote:

> On Aug 14, 2013, at 2:16 PM, Philipp Kutin wrote:
>
>> On Wed, Aug 14, 2013 at 6:24 PM, Ben Abbott <[hidden email]> wrote:
>>> -----------
>>> If X is global, clear X removes X from the current workspace, but
>>> leaves it accessible to any functions declaring it global.
>>> (...)
>>> -----------
>>
>> Heh, that sentence is thoroughly confusing.
>
> Ok. Since that is a cut-n-paste from Matlab, please direct your complaints to Mathworks.

Yes, of course, it's MATLAB being sloppy at writing documentation
here. This is my point -- there's much value in certain concepts to be
exponded in extreme detail, to the point of being painful to read.
Because well... this is the only way robustness can be achieved. I
mean, nobody would want to go back to the stone age of when, say, C
had not yet been standardized, right?

--Philipp
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Compatibility considerations of "clear"

Julien Bect
In reply to this post by bpabbott
On 14/08/2013 18:24, Ben Abbott wrote:

> On Aug 14, 2013, at 12:17 PM, Philipp Kutin wrote:
>
>> In Octave, issuing a plain "clear" clears both workspace and global
>> variables. This is a little surprising to someone working with MATLAB,
>> but from the command line it's only a minor issue. However, it may
>> have compatibility implications when used from a function.
>>
>> There does exist M code in the wild that calls "clear"
>> programmatically. I guess that it's mostly people feeling clearing
>> data manually sometimes, but occasionally, it can be justified. For
>> example, when reading in some large data and reordering it to
>> normalize to one's convention -- it may be a sensible move to clear a
>> temp variable before the function returns if further memory-intensive
>> operations are subsequently carried out.
>>
>> I propose making plain "clear" only clear the workspace-local
>> variables, and adding an option "-a"/"-all" for the current behavior.
>> What do you think?
>>
>> --Philipp
>  From Matlab ...
>
> -----------
> If X is global, clear X removes X from the current workspace, but
> leaves it accessible to any functions declaring it global.
> clear GLOBAL X completely removes the global variable X.
> clear GLOBAL -REGEXP PAT removes global variables that match regular
> expression patterns.
> -----------
>
> Octave is intended to be compatible with Matlab, so this is a bug.  Would you file a bug report?
>
> https://savannah.gnu.org/bugs/?group=octave
>
> Ben

I did  : https://savannah.gnu.org/bugs/index.php?39790

Julien.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Compatibility considerations of "clear"

Julien Bect
In reply to this post by Philipp Kutin
On 14/08/2013 21:54, Philipp Kutin wrote:
> On Wed, Aug 14, 2013 at 9:25 PM, John W. Eaton <[hidden email]> wrote:
>> We know what a workspace is, y'know?
> to agree on a common mental model for how the language
> maps names to values... the exact semantics of scope, and so on.

Hi all,

Talking about workspaces, scope and semantics...

->" help who", "help whos" refer to "local scope", "global scope" (but
not to "workspace" or "symbol table")

-> "help clear" refers to "symbol table" (but not to "workspace", "local
scope", "global scope")

-> "help evalin", "help assignin" refer to "context" (but to none of the
other concepts)

Perhaps some clarification of the documentation regarding the relation
between theses concepts would be helpful ?

@++
Julien

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Compatibility considerations of "clear"

Philipp Kutin
In reply to this post by John W. Eaton
On Wed, Aug 14, 2013 at 9:25 PM, John W. Eaton <[hidden email]> wrote:
> I think the attached patch will fix the behavior for clear without any
> arguments.

No, it doesn't. The values of global variables are still cleared when
only the names should.

> Is the current Octave behavior for functions also wrong?  Given the function
> (...)
> what do the following commands do?
> (...)

Here's the result of a slightly modified foo.m (attached) on R2013a.
Indented lines are echoed commands, the others are input/output.

>> dofoo
    foo  % Call the function
X IS NOT INITIALIZED
    foo  % Call the function
CALLED FOO
    foo = 1;  % Assign to a variable
    foo  % Refer to the variable
foo = 1
    clear foo  % Clear the variable
    foo  % Call the function
CALLED FOO
    clear foo  % Clear the function
    foo  % Call the function
X IS NOT INITIALIZED

By the way, what I said may not have been consistent. I'll try to
clarify another time.

--Philipp

foo.m (228 bytes) Download Attachment
Loading...