Thread Subject:

Matlab copy-on-write behaviour

>> format debug

If I create an array in the base workspace and then change just one
element of it, then the actual array thats pointed to by the mxArray
does not change, merely one of the values.

E.g
>> data = [1 2 3 4]

data =

Structure address = 4b504730
m = 1
n = 4
pr = 4b4362d0
pi = 0
     1 2 3 4

>> data(1) = 5

data =


Structure address = 4b504730
m = 1
n = 4
pr = 4b4362d0
pi = 0
     5 2 3 4


In both cases pr is the same - so far so good.

However, if I wrap the above two lines in a function like this:

function tArray
  data = [1 2 3 4]
  data(1) = 5

... and run it at the prompt:

>> tArray

data =

Structure address = 4b502030
m = 1
n = 4
pr = 4b36a488
pi = 0
     1 2 3 4

data =

Structure address = 4b502030
m = 1
n = 4
pr = 4b437eb0
pi = 0
     5 2 3 4

WHY now do the pr's differ?

Oddly enough the following code behaves differently:

function tArray
  data(1:4) = 0
  data(1) = 5

>> tArray

data =


Structure address = 4b502030
m = 1
n = 4
pr = 4b434af0
pi = 0
     0 0 0 0

data =

Structure address = 4b502030
m = 1
n = 4
pr = 4b434af0
pi = 0
     5 0 0 0


NOW, the pr's are the same. What gives?

-Farhan

In article <1183085140.654315.260500@d30g2000prg.googlegroups.com>,
farhan.rizwi@unswalumni.com says...
> >> format debug
>
> If I create an array in the base workspace and then change just one
> element of it, then the actual array thats pointed to by the mxArray
> does not change, merely one of the values.
>
> E.g
> >> data = [1 2 3 4]
>
> data =
>
> Structure address = 4b504730
> m = 1
> n = 4
> pr = 4b4362d0
> pi = 0
> 1 2 3 4
>
> >> data(1) = 5
>
> data =
>
>
> Structure address = 4b504730
> m = 1
> n = 4
> pr = 4b4362d0
> pi = 0
> 5 2 3 4
>
>
> In both cases pr is the same - so far so good.
>
> However, if I wrap the above two lines in a function like this:
>
> function tArray
> data = [1 2 3 4]
> data(1) = 5
>
> ... and run it at the prompt:
>
> >> tArray
>
> data =
>
> Structure address = 4b502030
> m = 1
> n = 4
> pr = 4b36a488
> pi = 0
> 1 2 3 4
>
> data =
>
> Structure address = 4b502030
> m = 1
> n = 4
> pr = 4b437eb0
> pi = 0
> 5 2 3 4
>
> WHY now do the pr's differ?
>
> Oddly enough the following code behaves differently:
>
> function tArray
> data(1:4) = 0
> data(1) = 5
>
> >> tArray
>
> data =
>
>
> Structure address = 4b502030
> m = 1
> n = 4
> pr = 4b434af0
> pi = 0
> 0 0 0 0
>
> data =
>
> Structure address = 4b502030
> m = 1
> n = 4
> pr = 4b434af0
> pi = 0
> 5 0 0 0
>
>
> NOW, the pr's are the same. What gives?
>
> -Farhan
>
>

When you call a function, it gets its own local workspace. Since you
are changing d inside the function, MATLAB severs the connection with
the local d vs. the caller's copy. When the function returns, d has
been replaced with the one computed in the function. This is in case
your function fails, then your original data is not corrupted.

-- Loren
http://blogs.mathworks.com/loren/

On Jun 29, 9:50 pm, Loren Shure <l...@mathworks.com> wrote:
> In article <1183085140.654315.260...@d30g2000prg.googlegroups.com>,
> farhan.ri...@unswalumni.com says...
>
>
>
> > >> format debug
>
> > If I create an array in the base workspace and then change just one
> > element of it, then the actual array thats pointed to by the mxArray
> > does not change, merely one of the values.
>
> > E.g
> > >> data = [1 2 3 4]
>
> > data =
>
> > Structure address = 4b504730
> > m = 1
> > n = 4
> > pr = 4b4362d0
> > pi = 0
> > 1 2 3 4
>
> > >> data(1) = 5
>
> > data =
>
> > Structure address = 4b504730
> > m = 1
> > n = 4
> > pr = 4b4362d0
> > pi = 0
> > 5 2 3 4
>
> > In both cases pr is the same - so far so good.
>
> > However, if I wrap the above two lines in a function like this:
>
> > function tArray
> > data = [1 2 3 4]
> > data(1) = 5
>
> > ... and run it at the prompt:
>
> > >> tArray
>
> > data =
>
> > Structure address = 4b502030
> > m = 1
> > n = 4
> > pr = 4b36a488
> > pi = 0
> > 1 2 3 4
>
> > data =
>
> > Structure address = 4b502030
> > m = 1
> > n = 4
> > pr = 4b437eb0
> > pi = 0
> > 5 2 3 4
>
> > WHY now do the pr's differ?
>
> > Oddly enough the following code behaves differently:
>
> > function tArray
> > data(1:4) = 0
> > data(1) = 5
>
> > >> tArray
>
> > data =
>
> > Structure address = 4b502030
> > m = 1
> > n = 4
> > pr = 4b434af0
> > pi = 0
> > 0 0 0 0
>
> > data =
>
> > Structure address = 4b502030
> > m = 1
> > n = 4
> > pr = 4b434af0
> > pi = 0
> > 5 0 0 0
>
> > NOW, the pr's are the same. What gives?
>
> > -Farhan
>
> When you call a function, it gets its own local workspace. Since you
> are changing d inside the function, MATLAB severs the connection with
> the local d vs. the caller's copy. When the function returns, d has
> been replaced with the one computed in the function. This is in case
> your function fails, then your original data is not corrupted.
>
> -- Lorenhttp://blogs.mathworks.com/loren/

Hi Loren,

Yes I understand your point but in my case there *is* no caller's
copy. The variable "data" is created inside the function and changed
within the same workspace. If you look at my second example where I
initialise data with "data(1:4) = [1 2 3 4]" instead of "data = [1 2 3
4]" then I get the results that I expect. My confusion is about the
difference in behaviour of the these two constructs. Further, "data =
zeros(4,1)" also seems to do the right thing.

Is it that sub-assignment forces a copy rather than a transfer of
ownership of the rhs temp array? In this case, it seems like the
reference to the temp array is not severed and hence when I change
data it causes a copy - but I may be way off here!

By the way, you may remember me from a couple of years ago. The last
three years that I was there I was mostly in the Simulink group and
wasn't quite a Matlab power user. However, presently I'm involved in
a project that analyses sound files, some of them could be quite large
and hence I'm having to be very careful how I write my code to
minimize memory allocation and improve speed. Your discussion on
nested functions here and on your blog was extremely useful to me. I
now have a dataBuffer object that I access through a nested function
handle which in turn is a field in my object. I really did not want
to go the mex-file route that some other people have suggested/
resorted to. While the mex-file solution does offer complete control
over memory elements, it essentially prevents leverage of newer
optimisations in Matlab. For example, its quite conceivable that some
of my M-code will automatically be more efficient in the future, just
like some of the in-place calculations are now.

Cheers,
Farhan

farhan.rizwi wrote:
>
>
> On Jun 29, 9:50 pm, Loren Shure <l...@mathworks.com> wrote:
>> In article
> <1183085140.654315.260...@d30g2000prg.googlegroups.com>,
>> farhan.ri...@unswalumni.com says...
>>
>>
>>
>> > >> format debug
>>
>> > If I create an array in the base workspace and then change just
> one
>> > element of it, then the actual array thats pointed to by the
> mxArray
>> > does not change, merely one of the values.
>>
>> > E.g
>> > >> data = [1 2 3 4]
>>
>> > data =
>>
>> > Structure address = 4b504730
>> > m = 1
>> > n = 4
>> > pr = 4b4362d0
>> > pi = 0
>> > 1 2 3 4
>>
>> > >> data(1) = 5
>>
>> > data =
>>
>> > Structure address = 4b504730
>> > m = 1
>> > n = 4
>> > pr = 4b4362d0
>> > pi = 0
>> > 5 2 3 4
>>
>> > In both cases pr is the same - so far so good.
>>
>> > However, if I wrap the above two lines in a function like this:
>>
>> > function tArray
>> > data = [1 2 3 4]
>> > data(1) = 5
>>
>> > ... and run it at the prompt:
>>
>> > >> tArray
>>
>> > data =
>>
>> > Structure address = 4b502030
>> > m = 1
>> > n = 4
>> > pr = 4b36a488
>> > pi = 0
>> > 1 2 3 4
>>
>> > data =
>>
>> > Structure address = 4b502030
>> > m = 1
>> > n = 4
>> > pr = 4b437eb0
>> > pi = 0
>> > 5 2 3 4
>>
>> > WHY now do the pr's differ?
>>
>> > Oddly enough the following code behaves differently:
>>
>> > function tArray
>> > data(1:4) = 0
>> > data(1) = 5
>>
>> > >> tArray
>>
>> > data =
>>
>> > Structure address = 4b502030
>> > m = 1
>> > n = 4
>> > pr = 4b434af0
>> > pi = 0
>> > 0 0 0 0
>>
>> > data =
>>
>> > Structure address = 4b502030
>> > m = 1
>> > n = 4
>> > pr = 4b434af0
>> > pi = 0
>> > 5 0 0 0
>>
>> > NOW, the pr's are the same. What gives?
>>
>> > -Farhan
>>
>> When you call a function, it gets its own local workspace. Since
> you
>> are changing d inside the function, MATLAB severs the connection
> with
>> the local d vs. the caller's copy. When the function returns, d
> has
>> been replaced with the one computed in the function. This is in
> case
>> your function fails, then your original data is not corrupted.
>>
>> -- Lorenhttp://blogs.mathworks.com/loren/
>
> Hi Loren,
>
> Yes I understand your point but in my case there *is* no caller's
> copy. The variable "data" is created inside the function and
> changed
> within the same workspace. If you look at my second example where
> I
> initialise data with "data(1:4) = [1 2 3 4]" instead of "data = [1
> 2 3
> 4]" then I get the results that I expect. My confusion is about
> the
> difference in behaviour of the these two constructs. Further,
> "data =
> zeros(4,1)" also seems to do the right thing.
>
> Is it that sub-assignment forces a copy rather than a transfer of
> ownership of the rhs temp array? In this case, it seems like the
> reference to the temp array is not severed and hence when I change
> data it causes a copy - but I may be way off here!
>
> By the way, you may remember me from a couple of years ago. The
> last
> three years that I was there I was mostly in the Simulink group and
> wasn't quite a Matlab power user. However, presently I'm involved
> in
> a project that analyses sound files, some of them could be quite
> large
> and hence I'm having to be very careful how I write my code to
> minimize memory allocation and improve speed. Your discussion on
> nested functions here and on your blog was extremely useful to me.
> I
> now have a dataBuffer object that I access through a nested
> function
> handle which in turn is a field in my object. I really did not
> want
> to go the mex-file route that some other people have suggested/
> resorted to. While the mex-file solution does offer complete
> control
> over memory elements, it essentially prevents leverage of newer
> optimisations in Matlab. For example, its quite conceivable that
> some
> of my M-code will automatically be more efficient in the future,
> just
> like some of the in-place calculations are now.
>
> Cheers,
> Farhan
>

I know little about was going on under the hood of Matlab and I would rather not care. Maybe I should care more. I'm possitive that Matlab doesn't make a copy when processing data(1)=5. However, your post made me do the following test.

Matlab R2006b on WinXP. Taskmanager refresh rate is high.

I run
1. cssm(5e7)
2. profile on, cssm(5e7), profile viewer
3. tic, cssm(5e7), toc

Matlab doesn't make a copy and "data(1) = 5"; doesn't take any significant amount of time. BTW, is format debug a documented feature?

function cssm( N )
    clc
    format debug
    data = zeros( 1, N );
    pause(2)
    data(1) = 5;
    pause(2)
end

/ per

In article <1183168102.356935.11240@i13g2000prf.googlegroups.com>,
farhan.rizwi@unswalumni.com says...
> On Jun 29, 9:50 pm, Loren Shure <l...@mathworks.com> wrote:
> > In article <1183085140.654315.260...@d30g2000prg.googlegroups.com>,
> > farhan.ri...@unswalumni.com says...
> >
> >
> >
> > > >> format debug
> >
> > > If I create an array in the base workspace and then change just one
> > > element of it, then the actual array thats pointed to by the mxArray
> > > does not change, merely one of the values.
> >
> > > E.g
> > > >> data = [1 2 3 4]
> >
> > > data =
> >
> > > Structure address = 4b504730
> > > m = 1
> > > n = 4
> > > pr = 4b4362d0
> > > pi = 0
> > > 1 2 3 4
> >
> > > >> data(1) = 5
> >
> > > data =
> >
> > > Structure address = 4b504730
> > > m = 1
> > > n = 4
> > > pr = 4b4362d0
> > > pi = 0
> > > 5 2 3 4
> >
> > > In both cases pr is the same - so far so good.
> >
> > > However, if I wrap the above two lines in a function like this:
> >
> > > function tArray
> > > data = [1 2 3 4]
> > > data(1) = 5
> >
> > > ... and run it at the prompt:
> >
> > > >> tArray
> >
> > > data =
> >
> > > Structure address = 4b502030
> > > m = 1
> > > n = 4
> > > pr = 4b36a488
> > > pi = 0
> > > 1 2 3 4
> >
> > > data =
> >
> > > Structure address = 4b502030
> > > m = 1
> > > n = 4
> > > pr = 4b437eb0
> > > pi = 0
> > > 5 2 3 4
> >
> > > WHY now do the pr's differ?
> >
> > > Oddly enough the following code behaves differently:
> >
> > > function tArray
> > > data(1:4) = 0
> > > data(1) = 5
> >
> > > >> tArray
> >
> > > data =
> >
> > > Structure address = 4b502030
> > > m = 1
> > > n = 4
> > > pr = 4b434af0
> > > pi = 0
> > > 0 0 0 0
> >
> > > data =
> >
> > > Structure address = 4b502030
> > > m = 1
> > > n = 4
> > > pr = 4b434af0
> > > pi = 0
> > > 5 0 0 0
> >
> > > NOW, the pr's are the same. What gives?
> >
> > > -Farhan
> >
> > When you call a function, it gets its own local workspace. Since you
> > are changing d inside the function, MATLAB severs the connection with
> > the local d vs. the caller's copy. When the function returns, d has
> > been replaced with the one computed in the function. This is in case
> > your function fails, then your original data is not corrupted.
> >
> > -- Lorenhttp://blogs.mathworks.com/loren/
>
> Hi Loren,
>
> Yes I understand your point but in my case there *is* no caller's
> copy. The variable "data" is created inside the function and changed
> within the same workspace. If you look at my second example where I
> initialise data with "data(1:4) = [1 2 3 4]" instead of "data = [1 2 3
> 4]" then I get the results that I expect. My confusion is about the
> difference in behaviour of the these two constructs. Further, "data =
> zeros(4,1)" also seems to do the right thing.
>
> Is it that sub-assignment forces a copy rather than a transfer of
> ownership of the rhs temp array? In this case, it seems like the
> reference to the temp array is not severed and hence when I change
> data it causes a copy - but I may be way off here!
>
> By the way, you may remember me from a couple of years ago. The last
> three years that I was there I was mostly in the Simulink group and
> wasn't quite a Matlab power user. However, presently I'm involved in
> a project that analyses sound files, some of them could be quite large
> and hence I'm having to be very careful how I write my code to
> minimize memory allocation and improve speed. Your discussion on
> nested functions here and on your blog was extremely useful to me. I
> now have a dataBuffer object that I access through a nested function
> handle which in turn is a field in my object. I really did not want
> to go the mex-file route that some other people have suggested/
> resorted to. While the mex-file solution does offer complete control
> over memory elements, it essentially prevents leverage of newer
> optimisations in Matlab. For example, its quite conceivable that some
> of my M-code will automatically be more efficient in the future, just
> like some of the in-place calculations are now.
>
> Cheers,
> Farhan
>
>

I do remember you! Nice to hear from you again.

I see the behavior you're seeing and don't understand it either. I have
entered it as a bug in our database.

-- Loren
http://blogs.mathworks.com/loren/

On Jul 1, 1:31 am, "per isakson" <p...@kth2.se> wrote:
> farhan.rizwi wrote:
>
> > On Jun 29, 9:50 pm, Loren Shure <l...@mathworks.com> wrote:
> >> In article
> > <1183085140.654315.260...@d30g2000prg.googlegroups.com>,
> >> farhan.ri...@unswalumni.com says...
>
> >> > >> format debug
>
> >> > If I create an array in the base workspace and then change just
> > one
> >> > element of it, then the actual array thats pointed to by the
> > mxArray
> >> > does not change, merely one of the values.
>
> >> > E.g
> >> > >> data = [1 2 3 4]
>
> >> > data =
>
> >> > Structure address = 4b504730
> >> > m = 1
> >> > n = 4
> >> > pr = 4b4362d0
> >> > pi = 0
> >> > 1 2 3 4
>
> >> > >> data(1) = 5
>
> >> > data =
>
> >> > Structure address = 4b504730
> >> > m = 1
> >> > n = 4
> >> > pr = 4b4362d0
> >> > pi = 0
> >> > 5 2 3 4
>
> >> > In both cases pr is the same - so far so good.
>
> >> > However, if I wrap the above two lines in a function like this:
>
> >> > function tArray
> >> > data = [1 2 3 4]
> >> > data(1) = 5
>
> >> > ... and run it at the prompt:
>
> >> > >> tArray
>
> >> > data =
>
> >> > Structure address = 4b502030
> >> > m = 1
> >> > n = 4
> >> > pr = 4b36a488
> >> > pi = 0
> >> > 1 2 3 4
>
> >> > data =
>
> >> > Structure address = 4b502030
> >> > m = 1
> >> > n = 4
> >> > pr = 4b437eb0
> >> > pi = 0
> >> > 5 2 3 4
>
> >> > WHY now do the pr's differ?
>
> >> > Oddly enough the following code behaves differently:
>
> >> > function tArray
> >> > data(1:4) = 0
> >> > data(1) = 5
>
> >> > >> tArray
>
> >> > data =
>
> >> > Structure address = 4b502030
> >> > m = 1
> >> > n = 4
> >> > pr = 4b434af0
> >> > pi = 0
> >> > 0 0 0 0
>
> >> > data =
>
> >> > Structure address = 4b502030
> >> > m = 1
> >> > n = 4
> >> > pr = 4b434af0
> >> > pi = 0
> >> > 5 0 0 0
>
> >> > NOW, the pr's are the same. What gives?
>
> >> > -Farhan
>
> >> When you call a function, it gets its own local workspace. Since
> > you
> >> are changing d inside the function, MATLAB severs the connection
> > with
> >> the local d vs. the caller's copy. When the function returns, d
> > has
> >> been replaced with the one computed in the function. This is in
> > case
> >> your function fails, then your original data is not corrupted.
>
> >> -- Lorenhttp://blogs.mathworks.com/loren/
>
> > Hi Loren,
>
> > Yes I understand your point but in my case there *is* no caller's
> > copy. The variable "data" is created inside the function and
> > changed
> > within the same workspace. If you look at my second example where
> > I
> > initialise data with "data(1:4) = [1 2 3 4]" instead of "data = [1
> > 2 3
> > 4]" then I get the results that I expect. My confusion is about
> > the
> > difference in behaviour of the these two constructs. Further,
> > "data =
> > zeros(4,1)" also seems to do the right thing.
>
> > Is it that sub-assignment forces a copy rather than a transfer of
> > ownership of the rhs temp array? In this case, it seems like the
> > reference to the temp array is not severed and hence when I change
> > data it causes a copy - but I may be way off here!
>
> > By the way, you may remember me from a couple of years ago. The
> > last
> > three years that I was there I was mostly in the Simulink group and
> > wasn't quite a Matlab power user. However, presently I'm involved
> > in
> > a project that analyses sound files, some of them could be quite
> > large
> > and hence I'm having to be very careful how I write my code to
> > minimize memory allocation and improve speed. Your discussion on
> > nested functions here and on your blog was extremely useful to me.
> > I
> > now have a dataBuffer object that I access through a nested
> > function
> > handle which in turn is a field in my object. I really did not
> > want
> > to go the mex-file route that some other people have suggested/
> > resorted to. While the mex-file solution does offer complete
> > control
> > over memory elements, it essentially prevents leverage of newer
> > optimisations in Matlab. For example, its quite conceivable that
> > some
> > of my M-code will automatically be more efficient in the future,
> > just
> > like some of the in-place calculations are now.
>
> > Cheers,
> > Farhan
>
> I know little about was going on under the hood of Matlab and I would rather not care. Maybe I should care more. I'm possitive that Matlab doesn't make a copy when processing data(1)=5. However, your post made me do the following test.
>
> Matlab R2006b on WinXP. Taskmanager refresh rate is high.
>
> I run
> 1. cssm(5e7)
> 2. profile on, cssm(5e7), profile viewer
> 3. tic, cssm(5e7), toc
>
> Matlab doesn't make a copy and "data(1) = 5"; doesn't take any significant amount of time. BTW, is format debug a documented feature?
>
> function cssm( N )
> clc
> format debug
> data = zeros( 1, N );
> pause(2)
> data(1) = 5;
> pause(2)
> end
>
> / per

No format debug is not documented but evidently very useful. Its
mentioned quite a few times on this group.

-Farhan