Discover MakerZone

MATLAB and Simulink resources for Arduino, LEGO, and Raspberry Pi

Learn more

Discover what MATLAB® can do for your career.

Opportunities for recent engineering grads.

Apply Today

Thread Subject:
Array indexing anomaly

Subject: Array indexing anomaly

From: David Young

Date: 7 Mar, 2010 22:24:20

Message: 1 of 11

If I write

    C = A(B)

where all arrays are type double, then the general rule is that C has the same size as B.

However, there seems to be an exception, which recently tripped me up: if A is 1xM and B is Nx1, then C has the same size as B'. In other words, C is a row when the general rule would make it a column.

Does anyone know why there is this strange exception to a sensible rule, and also where it is documented? I've looked in the obvious place, the Matrix Indexing article in the User Guide, but it is silent.

Subject: Array indexing anomaly

From: Sadik

Date: 8 Mar, 2010 01:44:08

Message: 2 of 11

Maybe you should add the following to that rule:

If A is a column [row] vector, C will also be a column [row] vector no matter whether or not B is a column or row vector.

Best.


"David Young" <d.s.young.notthisbit@sussex.ac.uk> wrote in message <hn192k$moc$1@fred.mathworks.com>...
> If I write
>
> C = A(B)
>
> where all arrays are type double, then the general rule is that C has the same size as B.
>
> However, there seems to be an exception, which recently tripped me up: if A is 1xM and B is Nx1, then C has the same size as B'. In other words, C is a row when the general rule would make it a column.
>
> Does anyone know why there is this strange exception to a sensible rule, and also where it is documented? I've looked in the obvious place, the Matrix Indexing article in the User Guide, but it is silent.

Subject: Array indexing anomaly

From: Matt J

Date: 8 Mar, 2010 02:21:08

Message: 3 of 11

"Sadik " <sadik.hava@gmail.com> wrote in message <hn1kp8$1fl$1@fred.mathworks.com>...
> Maybe you should add the following to that rule:
>
> If A is a column [row] vector, C will also be a column [row] vector no matter whether or not B is a column or row vector.
==============

You'll have to add to add to that a further qualification, that A be a non-scalar vector.

For scalars, the shape of the result is always the same shape as B

>> A=1;
>> A(ones(1,3))

ans =

     1 1 1

>> A(ones(3,1))

ans =

     1
     1
     1

Subject: Array indexing anomaly

From: Matt J

Date: 8 Mar, 2010 03:14:05

Message: 4 of 11

"David Young" <d.s.young.notthisbit@sussex.ac.uk> wrote in message <hn192k$moc$1@fred.mathworks.com>...

>
> Does anyone know why there is this strange exception to a sensible rule,
======================

It probably has to do with the fact that it is exceedingly common to represent data as row vectors. For one thing, row vectors are easier to display. Many more will fit on the screen, without scrolling, than column vectors.

Since working with row vectors is so common, it could become tiresome if we always had to index them as A(1,B) in order to preserve the row shape of the result.

Subject: Array indexing anomaly

From: David Young

Date: 8 Mar, 2010 15:33:21

Message: 5 of 11

Thanks Sadik and Matt J. You're quite right - the exception is broader than I had realised and applies to all cases where A is Mx1 or 1xM and M is greater than 1. I suppose this makes it a little more consistent - I'm sure you're right that this is because vectors get special treatment.

All the same, if feels much more awkward than if the general rule had been consistent. After all, my own code broke because I'd assumed that C would be a column vector if B was a column vector, and it took me a little while to figure it out.

I'd still like it if someone could say where the behaviour is properly documented, or where there's a previous discussion, and also whether it's a regretted design decision long in the past, or whether it's really worth having this complexity. After all, if you always work with, say, row vectors, then B would be a row vector too and the general rule (C same shape as B) would do what you want.

Subject: Array indexing anomaly

From: Matt J

Date: 8 Mar, 2010 16:36:20

Message: 6 of 11

"David Young" <d.s.young.notthisbit@sussex.ac.uk> wrote in message <hn35c1$fb9$1@fred.mathworks.com>...


> I'd still like it if someone could say where the behaviour is properly documented, or where there's a previous discussion, and also whether it's a regretted design decision long in the past, or whether it's really worth having this complexity. After all, if you always work with, say, row vectors, then B would be a row vector too and the general rule (C same shape as B) would do what you want.
=================

I can't find the documentation just now, but I'm starting to think the reasoning behind the design decision might be different from what I had said.

The user population is accustomed to containing data in vectors, but now that I think about it, users are equally likely to prefer row vectors (for reasons I've already given examples for) as column vectors. Column vectors are what you tend to work with if, for example, your data vector x is the solution to a matrix vector equation A*x=b.

The problem now is that a very common operation you want to perform is indexing
using colon expressions x(m:n:p).

However, since (m:n:p) is always a row vector, then if the index vector always determined the shape of the output and if x was a column vector and if you wanted the output to be a column vector as well, you would have to do things
like x((m:n:p)') in order to get the shape you wanted. This is obviously a fair addition in keystrokes and syntax complexity when you do a lot of colon-based indexing.

So the bottom line is, you pay in complexity no matter which design decision you make.

Subject: Array indexing anomaly

From: David Young

Date: 9 Mar, 2010 14:42:04

Message: 7 of 11

Thanks - yes, I see the point about the colon operator generating rows always.

I'd still have preferred the general rule to apply always, but I'm happier working with the exceptions if I can see a rationale.

Subject: Array indexing anomaly

From: Matt J

Date: 9 Mar, 2010 16:26:02

Message: 8 of 11

"David Young" <d.s.young.notthisbit@sussex.ac.uk> wrote in message <hn5mns$sd3$1@fred.mathworks.com>...
> Thanks - yes, I see the point about the colon operator generating rows always.
>
> I'd still have preferred the general rule to apply always, but I'm happier working with the exceptions if I can see a rationale.
===========

Just before we let this die completely, here's another, at least partial, rationale.

When indexing an N-dimensional array using an N-dimensional subscript (as opposed to linear indexing), it has always been a well-established MATLAB rule that the shape of the result is uninfluenced by the shape of the index array data. This is why, for example, the following two operations give the same results:

>> A=rand(5)

A =

    0.8147 0.0975 0.1576 0.1419 0.6557
    0.9058 0.2785 0.9706 0.4218 0.0357
    0.1270 0.5469 0.9572 0.9157 0.8491
    0.9134 0.9575 0.4854 0.7922 0.9340
    0.6324 0.9649 0.8003 0.9595 0.6787

>> A(1:4,1:2)

ans =

    0.8147 0.0975
    0.9058 0.2785
    0.1270 0.5469
    0.9134 0.9575


>>A([1,2;3,4].',[1;2])

ans =

    0.8147 0.0975
    0.9058 0.2785
    0.1270 0.5469
    0.9134 0.9575

The question is, how do we be consistent with this rule when N=1? Do we regard vectors as 1-dimensional arrays, or as 2-dimensional arrays? If 1-dimensional, it would makes perfect sense that, when A is a vector, the shape of A (column or row) and not the index array B would dictate the shape of the result. And this is indeed the case when B is also a vector, as we've seen.

The only fly in this ointment is that this rule is violated again when B is not a vector, e.g.,



>> a=1:5

a =

     1 2 3 4 5

>> a([1,2;3,4].')

ans =

     1 3
     2 4

Subject: Array indexing anomaly

From: Loren Shure

Date: 9 Mar, 2010 19:58:11

Message: 9 of 11

In article <hn5sqq$rg9$1@fred.mathworks.com>,
mattjacREMOVE@THISieee.spam says...
> "David Young" <d.s.young.notthisbit@sussex.ac.uk> wrote in message <hn5mns$sd3$1@fred.mathworks.com>...
> > Thanks - yes, I see the point about the colon operator generating rows always.
> >
> > I'd still have preferred the general rule to apply always, but I'm happier working with the exceptions if I can see a rationale.
> ===========

The general rules are:

1) retain the shape of the index UNLESS
2) you are indexing a vector with a vector, then retain orientation of
vector being indexed.

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

Subject: Array indexing anomaly

From: Matt J

Date: 9 Mar, 2010 20:15:20

Message: 10 of 11

Loren Shure <loren.shure@mathworks.com> wrote in message <MPG.2600725f676a1d4989ac1@news.mathworks.com>...

>
> The general rules are:
>
> 1) retain the shape of the index UNLESS
> 2) you are indexing a vector with a vector, then retain orientation of
> vector being indexed.
================

What we're curious about though, Loren, is what TMW's official rationale is for 2),
if different from what was discussed above. Why not retain the shape of the index universally?

Subject: Array indexing anomaly

From: Loren Shure

Date: 10 Mar, 2010 12:21:47

Message: 11 of 11

In article <hn6a8o$52s$1@fred.mathworks.com>,
mattjacREMOVE@THISieee.spam says...
> Loren Shure <loren.shure@mathworks.com> wrote in message <MPG.2600725f676a1d4989ac1@news.mathworks.com>...
>
> >
> > The general rules are:
> >
> > 1) retain the shape of the index UNLESS
> > 2) you are indexing a vector with a vector, then retain orientation of
> > vector being indexed.
> ================
>
> What we're curious about though, Loren, is what TMW's official rationale is for 2),
> if different from what was discussed above. Why not retain the shape of the index universally?
>

Too often the index is created via colon which produces a row vector.
Indexing into a column vector with a row vector and getting a row vector
surprised people too often. Hence the rule. I can't remember when that
change went in - perhaps some version 3 or 4???

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

Tags for this Thread

What are tags?

A tag is like a keyword or category label associated with each thread. Tags make it easier for you to find threads of interest.

Anyone can tag a thread. Tags are public and visible to everyone.

Contact us