From: <HIDDEN>
Newsgroups: comp.soft-sys.matlab
Subject: Re: Regarding Matrrix Indexing
Date: Tue, 29 Nov 2011 09:53:14 -0600
Organization: NNTP Server
Lines: 48
Message-ID: <jb2v59$9r5$>
References: <> <jb0hh0$88l$> <> <jb0o04$r2i$> <jb0qbs$b8o$> <jb12fv$nlj$> <jb2sp1$26i$>
NNTP-Posting-Host: q89k+tsFpa0C/
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20110616 Thunderbird/3.1.11
X-Notice: Filtered by postfilter v. 0.8.2
Xref: comp.soft-sys.matlab:750817

On 11/29/2011 9:12 AM, Steven_Lord wrote:

>> It seems like it _should_ work...but doesn't. Don't know precisely why
>> TMW chose the implementation as they did of A(I(:)) instead of the
>> literal meaning of the index array elements.
> I'm not certain either (you'd have to ask Cleve, probably) but I believe
> it's because linear indexing is useful, and we didn't want A(I) to
> perform linear indexing UNLESS the matrix I happened to have ndims(A)
> columns in which case it would switch to subscripted indexing.
> A = eye(4);
> A(1:10) = 2; % linear indexing
> A(1:3) = 3; % linear indexing
> A(1:2) = 4; % If this just changed A(1, 2), wouldn't that be confusing
> and break the nice "linear indexing" pattern?
> A(1) = 5; % linear indexing

I don't grok the

 > A(1:2) = 4; % If this just changed A(1, 2),

example comment, exactly.  The list as written is explicit and 1D so it 
would/could be interpreted as linear.  If one wanted only A(1,2) then 
one would write it that way.

I think users would have gotten to where it would have been expected 
behavior if the other parsing had been selected.  It would require 
possibly explicit ':' in places it doesn't as is, I'm not sure; I 
haven't tried to work on the actual parsing rules in detail.

I would guess the choice was strongly owing to the linear nature of 
matrix storage in memory that was so common to manipulate manually in 
the days when Cleve was starting to code Matlab.  Then we all used to 
handle "dynamic" memory by things such as large blank COMMON and pass a 
singly-dimensioned (static) array address around and then use it however 
the local routine needed before such wonders were handled for us.  When 
so used to the ind2sub<->sub2ind duality manually computed for such 
"tricks" it would be natural to simply keep that approach.

Things were _much_ different way back when... :)

(BTW, as shows I'm sure often, being within hailing distance of a just a 
handful of years of Cleve in longevity means saw/used/wrote a lot of 
that kind of stuff in days past.)