I agree with most of what is said in the comments/answers. Yet, if you really needed to avoid copies for good reasons in a context far more complex and/or specific than the example that you give, you could create a handle class and always work on a single copy of whatever you pass to functions/methods. Again, there is no point in doing this for simple data structures unless you have proven that you cannot afford the copy-on-write, so don't jump on this solution if you don't fully understand what you are doing.
Yet, skimming the history of your questions, I think that you know what you are doing and that people reacted to your comment about "not using functions and getting messy code for avoiding copy-on-write" a bit too quickly .. but you have to admit that in most cases this is almost a heretical statement/approach ;-)
Anyhow, assuming that you need this for valid reasons, here is an example:
classdef VeryVeryLargeArray < handle
properties
array
end
methods
function obj = VeryVeryLargeArray( builder, varargin )
obj.array = builder( varargin{:} ) ;
end
end
end
Using it for building e.g. a 5GB random array (so you can see something in the task manager):
>> n = floor( sqrt( 5e9/8 )) ;
>> vvla = VeryVeryLargeArray( @rand, n ) ;
you see a 5GB jump in the memory usage. Now if you call a function e.g. setRow :
function setRow( vvla, rowId, value )
vvla.array(rowId,:) = value ;
end
after having set a break point on the 3rd line with end:
you won't see a second jump due to a copy-on-write and your array will have been updated (even in the base workspace, because handles work "a bit like pointers").
EDIT 10/4 @ 12:41UTC: I am just giving you a quick example of overload of SUBSREF in case you wanted to transfer block indexing of the object(s) to the internal array(s):
function out = subsref( obj, S )
if S(1).type(1) ~= '.'
out = subsref( obj.array, S ) ;
else
out = builtin( 'subsref', obj, S ) ;
end
end
This method could be added after my comment in the methods block of the class definition. The same would have to be done for SUBSASGN and possibly SIZE. The advantage is that most functions could operate on the object the way they operate on any numeric array:
>> vvla(2:4, 10:13)
ans =
0.5108 0.1707 0.3188 0.3955
0.8176 0.2277 0.4242 0.3674
0.7948 0.4357 0.5079 0.9880
This accesses vvla.array(2:4,10:13) and has the advantage to make the internal structure transparent to the user (at least for what is managed by SUBSREF).
Note that testing S(1).type(1)~='.' (and not just S(1).type(1)=='(') allows to transfer any () or {} indexing to the array property, so you can use builders of cell arrays:
vvlca = VeryVeryLargeArray( @cell, 4, 5 ) ;
BUT you cannot easily (or at all) manage properly CSL outputs (especially when you want to nest these objects), so there is a limit to what you can achieve with overloading indexing methods. [If you try, you will likely spend hours wondering why nargout is defined through a call to your overloaded NUMEL and not to the builtin, and trying to find workarounds.]
EDIT 10/5 @ 12:32UTC: As mentioned, you can overload specific operations or functions that are relevant to the use that you make of these arrays. If you want to be able to use DIFF transparently for example:
function df = diff( obj, varargin )
df = diff( obj.array, varargin{:} ) ;
end
