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:
MATLAB indexing issue (was Re: Use of MATLAB fftshift)

Subject: MATLAB indexing issue (was Re: Use of MATLAB fftshift)

From: robert bristow-johnson

Date: 27 Jun, 2010 01:40:49

Message: 1 of 6

On Jun 25, 8:43 pm, "Nasser M. Abbasi" <n...@12000.org> wrote:
> On 6/25/2010 5:11 PM, Greg Heath wrote:
>
>
>
> > Please not use i (or j) as an index. It will get confused with
> > sqrt(-1).
>
> >> and the 'sample number' n (which are not the same).
>
> On a side point, and I do not mean to interrupt the main discussion
> about fftshift, but wanted to mention the indexing issue.
>
> I think the fact that in Matlab one can't start indexing at 0 can cause
> one to easily make a programming error.

no shit.

> When one tries to code a mathematical equation from the textbook, which
> uses 0 as an index, into matlab, and have to adjust things, one can make
> the famous 1-off error.

my bottom lip is nearly bleeding, i am biting it so hard.

> I wish Matlab would allow one to change the indexing.

now it *is* bleeding.

> In Fortran for
> example, one can do that,

in the *new* Fortran. because they allowed it to evolve.

Cleve (Moler), did you know that languages can evolve? even MATLAB?

> and it can make implementing DSP algorithm
> easier I think. (Strange that even though Matlab was originally
> implemented in Fortran, if I remember correctly, that this was not put
> into Matlab arrays? May because at the time Fortran did not allow 0
> based arrays?)

i think so. but it's still amazing that the overlooked this problem
then and continue to do so now. it was more excusable then.

> As an exercise the other day, I wrote few lines of code to implement DFT
> in Fortran 90 and Ada. Both of these allowed one to define an array with
> an index that starts from 0, and I think the code was easier to
> implement, since I did not have to worry about the 1-off problem as I
> would have in Matlab or in any other language that does not have this
> flexibility.
>
> In DFT, the summation starts from n=0 to n=N-1, and the index n is also
> used, inside the loop, to index into the array of samples. So, one have
> to remember to add 1 to n before referencing the array. But in the
> textbook equation, there was no such addition of 1.
>
> Hence the Fortran and the Ada code matched the text book exactly, but
> the Matlab code would not. This is just an example.
>
> http://12000.org/my_notes/mma_matlab_control/KERNEL/node94.htm
>
> I know that this point have been talked about may times before, and it
> is too late now to change Matlab.

NO IT ISN'T!! and it wasn't 10 years ago, even though they tried to
imply to us that it was. they can *extend* the language by
incorporating into every MATLAB variable a vector which has length
equal to the number of dimensions that's just like the vector they
already have that defines the numbers of rows and columns and whatever
they call it for the 3rd or 4th dimension. except this vector would
define the index number of the "first" (and i don't mean the "one_th")
element in each dimension. if, when a MATLAB variable is first
created, if these origin values are assigned the default value of "1",
it would be perfectly backward compatible and no legacy code would
break. then there would be functions similar to size() and reshape()
that would instead be called base() and rebase() and would allow the
user to examine and change (respectively) these origin values. THAT
WOULD FIX THIS STUPID PROBLEM THAT CLEVE DENIES (or, at least
steadfastly denied it a decade ago) IS A PROBLEM.

r b-j

Subject: MATLAB indexing issue (was Re: Use of MATLAB fftshift)

From: eric.jacobsen@ieee.org (Eric Jacobsen)

Date: 27 Jun, 2010 05:56:48

Message: 2 of 6


On Sat, 26 Jun 2010 18:40:49 -0700 (PDT), robert bristow-johnson
<rbj@audioimagination.com> wrote:

>On Jun 25, 8:43=A0pm, "Nasser M. Abbasi" <n...@12000.org> wrote:
>> On 6/25/2010 5:11 PM, Greg Heath wrote:
>>
>>
>>
>> > Please not use i (or j) as an index. It will get confused with
>> > sqrt(-1).
>>
>> >> and the 'sample number' n (which are not the same).
>>
>> On a side point, and I do not mean to interrupt the main discussion
>> about fftshift, but wanted to mention the indexing issue.
>>
>> I think the fact that in Matlab one can't start indexing at 0 can cause
>> one to easily make a programming error.
>
>no shit.
>
>> When one tries to code a mathematical equation from the textbook, which
>> uses 0 as an index, into matlab, and have to adjust things, one can make
>> the famous 1-off error.
>
>my bottom lip is nearly bleeding, i am biting it so hard.
>
>> I wish Matlab would allow one to change the indexing.
>
>now it *is* bleeding.
>
>> In Fortran for
>> example, one can do that,
>
>in the *new* Fortran. because they allowed it to evolve.
>
>Cleve (Moler), did you know that languages can evolve? even MATLAB?
>
>> and it can make implementing DSP algorithm
>> easier I think. (Strange that even though Matlab was originally
>> implemented in Fortran, if I remember correctly, that this was not put
>> into Matlab arrays? May because at the time Fortran did not allow 0
>> based arrays?)
>
>i think so. but it's still amazing that the overlooked this problem
>then and continue to do so now. it was more excusable then.
>
>> As an exercise the other day, I wrote few lines of code to implement DFT
>> in Fortran 90 and Ada. Both of these allowed one to define an array with
>> an index that starts from 0, and I think the code was easier to
>> implement, since I did not have to worry about the 1-off problem as I
>> would have in Matlab or in any other language that does not have this
>> flexibility.
>>
>> In DFT, the summation starts from n=3D0 to n=3DN-1, and the index n is al=
>so
>> used, inside the loop, to index into the array of samples. So, one have
>> to remember to add 1 to n before referencing the array. But in the
>> textbook equation, there was no such addition of 1.
>>
>> Hence the Fortran and the Ada code matched the text book exactly, but
>> the Matlab code would not. This is just an example.
>>
>> http://12000.org/my_notes/mma_matlab_control/KERNEL/node94.htm
>>
>> I know that this point have been talked about may times before, and it
>> is too late now to change Matlab.
>
>NO IT ISN'T!! and it wasn't 10 years ago, even though they tried to
>imply to us that it was. they can *extend* the language by
>incorporating into every MATLAB variable a vector which has length
>equal to the number of dimensions that's just like the vector they
>already have that defines the numbers of rows and columns and whatever
>they call it for the 3rd or 4th dimension. except this vector would
>define the index number of the "first" (and i don't mean the "one_th")
>element in each dimension. if, when a MATLAB variable is first
>created, if these origin values are assigned the default value of "1",
>it would be perfectly backward compatible and no legacy code would
>break. then there would be functions similar to size() and reshape()
>that would instead be called base() and rebase() and would allow the
>user to examine and change (respectively) these origin values. THAT
>WOULD FIX THIS STUPID PROBLEM THAT CLEVE DENIES (or, at least
>steadfastly denied it a decade ago) IS A PROBLEM.
>
>r b-j

IMHO the most plausible explanation for why this has never been
addressed is that a conscious decision has been made within the
MathWorks that Matlab should not have flexible or zero-based indexing
capability.

Matlab has evolved a fair amount, as they've added structured features
and a few other things that probably appeal to a few people, so it's
not like they're just averse to changing anything.


Eric Jacobsen
Minister of Algorithms
Abineau Communications
http://www.abineau.com

Subject: Indexing base sanity check - (was ... which [was ... which implied

From: Richard Owlett

Date: 27 Jun, 2010 19:22:10

Message: 3 of 6

Apologies to those who might think I'm stealing their thread.

*CAVEAT LECTOR* Though I've *NEVER* supported myself by any trade
normally associated with DSP, my avocations regularly deal with
topics covered by this group.

I've dealt with problems best expressed with a 0 base index.
I've dealt with problems best expressed with a 1 base index.

For problems involving a FFT (or inverse) I use Scilab 4.x
Choice NOT based on indexing - couldn't afford MATLAB and at the
time Octave had installation problems on *my* Windows setup.

I think it is foolish for for any purported "GENERAL PURPOSE"
package to not address the index base issue.

A before I get really sarcastic comments - If I'm not old enough
to have changed their diapers/wipes, I'm more than old enough to
have been their "sitter" ;}

Subject: MATLAB indexing issue (was Re: Use of MATLAB fftshift)

From: Walter Roberson

Date: 4 Jul, 2010 16:42:08

Message: 4 of 6

robert bristow-johnson wrote:
> On Jun 27, 8:09 am, Rune Allnor <all...@tele.ntnu.no> wrote:

>> Changing this would undermine nearly 30 years worth of code base.

> no it wouldn't. it could be perfectly backward compatible, because
> newly-created arrays would have default origin of 1 for every
> dimension of the array. the user would have to call a not-yet-
> existing function to change the origin.

Robert, your enthusiasm for this idea has led you to neglect thinking
the problems through.

Suppose I have a mex file written to the current API. One or more of the
arguments to the function are array indices. Now introduce your proposed
new indexing scheme and have the user create such an array and pass it
in to the existing mex file.

Your claim that the proposed change "could be perfectly backwards
compatible" implies that the indices the user passes in must not rely on
the new indexing scheme, because "perfectly backwards compatible" means
that old code must work UNCHANGED. Now *without changing the API for
existing routines*, how is Matlab going to know if a (say) 5 being
passed in as a numeric value is already adjusted to be 1-relative or
needs to be silently re-biased by Matlab to the appropriate basis in
order to preserve backwards compatibility? What if the dimension to be
indexed is itself is a parameter so that the unbiasing that needs to
take place is not constant? What if the dimension number is not an
_obvious_ parameter, such as if you had some encoding such as the mesh
encoding that mixes control values and data values in the same array?
What if the indices that have to be rebiased have been packed, such as
two 8-bit indices numerically jammed into a 16 bit number -- how is
Matlab going to know the jamming algorithm to know how to rebias and
construct the appropriate new index?

As long as indices are computable data then in order to support
different index biases you MUST break backwards compatibility, in that
the existing code would have to be enhanced to know about and take into
account the new indexing scheme for any parameter that is not provably
an old-style matrix.

Subject: MATLAB indexing issue (was Re: Use of MATLAB fftshift)

From: Steven Lord

Date: 6 Jul, 2010 19:38:39

Message: 5 of 6


"robert bristow-johnson" <rbj@audioimagination.com> wrote in message
news:2f984955-7c2c-4414-8b5b-5843e314a8d7@b35g2000yqi.googlegroups.com...
> On Jul 4, 12:42 pm, Walter Roberson <rober...@hushmail.com> wrote:
> > robert bristow-johnson wrote:
> > > On Jun 27, 8:09 am, Rune Allnor <all...@tele.ntnu.no> wrote:
> > >> Changing this would undermine nearly 30 years worth of code base.
> > >
> > > no it wouldn't. it could be perfectly backward compatible, because
> > > newly-created arrays would have default origin of 1 for every
> > > dimension of the array. the user would have to call a not-yet-
> > > existing function to change the origin.
> >
> > Robert, your enthusiasm for this idea has led you to neglect thinking
> > the problems through.
>
> that might be a premature judgment. you don't know how much i have
> thought this through for more than a decade. if you can get Google
> Groups to search adequately, you might find the places where the
> objections (similar to yours) were brought up and i swatted them
> down. even Cleve eventually admitted that it was, from the strict
> definition of the term, backward compatible.
>
> > Suppose I have a mex file written to the current API.
>
> as long as no one applies your MEX function (written under the old
> assumptions) to any array with any origin not 1, there would be no
> problem. still backward compatible. no one's code breaks.

Except for the person who DOES apply an older MEX function to a non-1 based
array. People often need/want to reuse their old code, and I've found
people tend to get a wee bit upset if you tell them "Sorry, don't do that."
unless there's a major benefit they can immediately see (and sometimes even
then.) While some (including yourself) may see 0-based indexing as such a
major benefit, there are also many who would not.

> if this extension or enhancement to MATLAB were adopted and you wanted
> your .mex function to work with arrays of origin different than 1, you
> would have to modify the .mex function to look for the origins (using
> the new API). otherwise your function would work as if all of the
> origins were 1 when they may not be.

And that is an incompatibility. Let's take a look at a few others.

1)
Let's say that a user had a function that needs to loop over the columns of
their matrix. This is not a contrived example; I've seen plenty of code
that does something similar.

for whichcolumn = 1:size(A, 2)
    % process column A(:, whichcolumn)
end

If A is a 1-based array, then everything works as it did before. If A was a
0-based array, then this would error with an error message like "Index
exceeds matrix dimension" or something similar. Code that used to work no
longer works. That's an incompatibility.

Even worse, let's say the user's code, for whatever reason, only needed to
process all but the final column of A.

for whichcolumn = 1:size(A, 2)-1
    % process column A(:, whichcolumn)
end

Now this code can SILENTLY GIVE THE WRONG ANSWER if A is a 0-based array, as
it will process all but the _first_ column of A.

2)
What happens if I SAVE a 0-based array in a MAT-file and LOAD it in a
version prior to the introduction of this change? Would you expect that to
work?

3)
Suppose A is a 0-based array and B is a 1-based array. What happens if I
ask for A+B? A.*B? [Assume all the sizes match; just consider the
based-ness for this scenario.]

I'm guessing you're going to say that A+B and A.*B both error; operating
under that assumption, let's take a look at one more example. What should
the command pi+A do? Does the pi built-in function return a 0-based array
or a 1-based array? Seems to me that users would expect pi+A to add pi to
each element of A -- but for backwards compatibility, and to agree with your
own proposal from earlier in this thread, PI would _have_ to return a
1-based array and so pi+A would ERROR. If you say that PI should be "smart
enough" to know with what it's going to be combined and return the
appropriate-indexed scalar:

x = pi;
y = A+x;
z = B+x;

_One_ of the latter two operations must error unless scalars are treated as
a special case. If they are treated specially, x = 1:10; will encounter the
same problem assuming A and B are both 10-element vectors, since x must have
a specified base when it is created.

> it's no different than with any other extension or enhancement to a
> language. the issue you brought up is not a violation of backward
> compatibility. old code (with old .mex files) would still work the
> same way they did before.

Robert, when you've brought this type of system up in the past I've
seriously thought about how it could work, but based on the potential
problems I called out above, speaking personally I do not think it would be
a good idea to modify MATLAB indexing to use your proposed system.

I think your best option would be to create your own 0-based (or
variable-based) object and overload those functions with which you want to
work as well as subscripted indexing and assignment -- that way you can
control the behavior of indexing for your object. You can even make use of
the built-in functions (rather than having to reimplement them) by using the
BUILTIN function to call them on the 1-based data that's stored inside the
array as a private data member, and adjust the indices afterward (if
necessary.) Indeed, Nabeel posted an object to do just this to the File
Exchange several years ago:

http://www.mathworks.com/matlabcentral/fileexchange/1168-varbase

If you wanted to write a classdef-based version of this object then the
Object-Oriented Programming section of the documentation will contain the
information you'll need to become familiar with this style of object. In
particular, since indexing will be a major component of this object, the
following page will be of special interest:

http://www.mathworks.com/access/helpdesk/help/techdoc/matlab_oop/br09eqz.html

--
Steve Lord
slord@mathworks.com
comp.soft-sys.matlab (CSSM) FAQ: http://matlabwiki.mathworks.com/MATLAB_FAQ
To contact Technical Support use the Contact Us link on
http://www.mathworks.com

Subject: MATLAB indexing issue (was Re: Use of MATLAB fftshift)

From: robert bristow-johnson

Date: 7 Jul, 2010 03:11:12

Message: 6 of 6

On Jul 6, 10:42 pm, spop...@speedymail.org (Steve Pope) wrote:
> Greg Berchin  <gberc...@comicast.net.invalid> wrote:
>
> >Every time I see this argument raise its ugly head in comp.dsp, I find myself
> >shaking my head and thinking:  "Because that's the way we've always done it" is
> >rarely a legitimate reason for continuing to do things wrong.
>
> I wonder which mathematician decided that matrices are indexed from one
> instead of zero?
>
> There is so much matrix theory published that is dependent upon
> this decision that it's impossible to un-do it in the world of
> math literature.

i do not think, nor have ever believed, that this is an "either or"
thing. it's not a dichotomy. it not a forced choice. no one needs
to choose between one convention (the long established matrix index
convention) and another (the "Dykstra" convention
http://www.cs.utexas.edu/users/EWD/ewd08xx/EWD831.PDF ). in fact,
it's just a generalization. neither convention need be adopted and,
as we do with non-causal impulse responses, we can start counting from
some negative index.

it's a generalization to or an extension to the present way of doing
things in MATLAB. and even though it doesn't favor any particular
origin in use, it *does* favor the present 1-based origin in MATLAB
because every new array created *defaults* to having 1 as the origin
for every dimension. the only way to change it would be to call this
"reorigin()" function (similarly to reshape()) or to create a non-1
based array from other non-1 based arrays. this makes it backward
compatible. old code would not break with this extension to the
language implemented.

r b-j

Tags for this Thread

No tags are associated with 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