bugGNU Octave - Bugs: bug #52980, clear in the caller workspace...

 
 

bug #52980: clear in the caller workspace doesn't clear all references to a variable.

Submitter:  None
Submitted:  Fri 26 Jan 2018 07:00:11 PM UTC
   
 
Category:  Performance Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Performance
Status:  Need Info Assigned to:  None
Originator Name:  Rahnema Originator Email:  -email is unavailable-
Open/Closed:  * Open Release:  * 4.2.1
Operating System:  * GNU/Linux Fixed Release:  None
Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Sat 27 Jan 2018 04:56:36 PM UTC, comment #3: 

I see the issue, and I suspect that the problem is the way Octave implements parameter passing by storing the parameter values in an array that is live for the duration of the function call, then also assigning them to elements of the function's symbol table.

It would be good to fix this problem but if I'm right about the reason, then I'm not sure there is any simple way to do it.

John W. Eaton <jwe>
Group administrator
Sat 27 Jan 2018 04:22:12 PM UTC, comment #2: 

Analyzing the code line by line:


function f(A)


A reference to the array `V` is created and it is assigned to `A`. Now we have one array object and two references `A` and `V`.


evalin('caller', 'clear V')


One of the references say `V` is deleted. Now we have one array object and one reference to it say `A`.


A(1) = 5;


Here `A` is modified in-place so no copy should be made. Also the function returns nothing so we don't have `ans`. Finally we should have one array object that `A` refers to it.

I think there may be a reference to the array object in the caller workspace that has not been cleared, so when `A` is modified a copy of the object is created.

Thanks.

Anonymous
Sat 27 Jan 2018 01:15:03 PM UTC, comment #1: 

Are you sure this is a bug?
My interpretation is that you misunderstand how Octave works.

First you make an array V.
Then you call a function f() to operate on that array.
Now you apparently think that f(V) directly operates on V in the calling scope. But that's not the way things work in Octave:

1. When you call a function along the lines of f(V), f() operates on its local copy of V, not on V itself. In other words, Octave calls functions with arguments by value, not by reference. If inside f() you change V, it'll create a deep copy, so memory consumption doubles. That deep copy is returned as the output of f(V), see below.

2. Any function always returns a value. That can be a scalar, an array, struct, anything.
If you don't supply a return argument, Octave will put the outcome in the default return argument, a variable called "ans".

So after calling f(V) you'll end up with two arrays:

  • The original, untouched V
  • ans, a copy of V with ans(1) having a value of 5


When you then clear V, obviously "ans" still exists.
That also happens if you call octave with "eval" as the same scopes (calling and called) will be created.

Or, did I misunderstand you?

I'm tempted to close this bug report right now with "Invalid" but I'll await your response.

Philip Nienhuis <philipnienhuis>
Group Member
Fri 26 Jan 2018 07:00:11 PM UTC, original submission:  

Hi all!
Comparing the following example:

B = rand(5000);
B(1) = 7;

with this one:

function f(A)
    evalin('caller', 'clear V')
    A(1) = 5;
end
V = rand(5000);
f(V);

I can use time to get the maximum memory consumption of a process:

/usr/bin/time -f "%M" octave -q --eval "V=rand(5000);function f(A);evalin('caller', 'clear V');A(1)=5;end;f(V);"

Interestingly the second example consumes two times more than the first example.
When 'V' is cleared from the caller workspace we should have only one instance of the 5000*5000 array in the function scope but when the local 'A' is modified a copy is created! It seems that 'clear' can't clear all references to the array object in the caller workspace.

Best regards,
Rahnema.

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by jwe (Posted a comment)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follows 1 latest change.

    Date Changed by Updated Field Previous Value => Replaced by
    2018-01-27 philipnienhuis StatusNone Need Info

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code