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. 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. I wish Matlab would allow one to change the indexing. In Fortran for example, one can do that, 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?) 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. --Nasser
Use of MATLAB fftshift
Started by ●June 23, 2010
Reply by ●June 25, 20102010-06-25
Reply by ●June 26, 20102010-06-26
On Jun 26, 1:11�am, Greg Heath <he...@alumni.brown.edu> wrote:> Jun 25, 2010 11:27:45 AM, chris.b...@gmail.com wrote: > > On Jun 23, 11:30 pm, Greg Heath wrote: > > > > > On Jun 23, 5:04 am, Chris Bore wrote: > > > > I've seen discussion here of the correct use of MATLAB's fftshift() > > > function > > > Please do not send separate copies of the same post to different > > newsgroups. Just post one copy but include all group names, > > separated by commas, on the newsgroup line. > > > The MATLAB fft and ifft functions assume the nonnegative intervals > > t = dt*(0:N-1) and f = df*(0:N-1) corresponding to the Fourier pair > > x(t) and X(f). > > > If x and X are considered periodic, fftshift yields the translation > > to the "zero centered" bipolar intervals with indexing > > > tb = dt * [-ceil((N-1)/2) : floor((N-1)/2)] > > fb = df * [-ceil((N-1)/2) : floor((N-1)/2)] > > > corresponding to the Fourier pair xb(tb) and Xb(fb). > > > ifftshift is the inverse of fftshift. > > > When N is even, fftshift and ifftshift yield > > the same result. > > > However, when N is odd, > > > x �= ifftshift(xb) > > X �= fft(x) > > Xb = fftshift(X) > > > and to return > > > X �= ifftshift(Xb) > > x �= ifft(X) > > xb = fftshift(x) > > > The trick is to remember that fftshift will "center" > > the waveform about the coordinate zero. > > > If in doubt type fftshift([-2:2]) into the command > > line. > > > Hope this helps. > > > Greg > >Thanks to all contributors. > > >Can I state the issue another way, and try to suggest a more generic > >idiom? > >The issue, I think, is that the fft() and ifft() in MATLAB are defined > >on an interval n = [0 : N-1] where N is the number of samples, and n > >is the 'sample number' that has n ==0 at the 'center' (time or > >frequency). > > No. > > You have just defined n==0 to be at the beginning of the interval. > > >Whereas, I addressed the problem of a signal or spectrum > >that is defined on the interval n = [ -N/2 : (N/2 - 1) ]. > > Your index n is only derived correctly for N even. > > You are just further complicating the issue by introducing > the discrete index variable n. Now you have to get away from > the basic message by making a distinction between indexing based > on counting from 0 and indexing based on counting from 1. > > If you reread my reply, I never explicitly mention the indexing > variable. The important point is, for N even or odd, > > tb = dt*[-ceil(N-1)/2) : floor((N-1)/2) ] � % "b"ipolar > > and > > t �= dt*[ 0 : N-1 ] > > regardless of how you index. > > Similarly for fb and f with df = 1/(N*dt). > > >First, because the FFT assumes a periodic function, we can use a > >circular shift to translate from one interval to another. > >Second, the ifftshift() does such a circular shift for the interval I > >specified (with appropriate caveats as to correct use) > > Now you are trivializing a most important point: > The correct usage of fftshift and ifftshift is key. > > >Second, the issue is partly that it is easy to confuse the matrix > >index (call this 'i' where in matlab i = [1 : N ] ) > > Arghhh! > > 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). > > That confusion is exactly why I explained it without getting > into the distraction of the type of indexing variable that is > used. > > >So in matlab's native usage, n( 1 ) == 0 whereas in my interval n( N/2 > >+ 1 ) == 0. That is, to re-state the obvious , the 'centers' are at > >index i == 1 and i == (N/2+1) respectively. > > ...except when N is odd. > > In general (without specifying the indexing convention), > > tb(ceil(N+1)/2) = 0 �% exanple: tb = dt*[ -2 -1 0 1 2 ] > t(1) = 0 � � � � � � � � �% example � t = dt*[ 0 1 2 -2 -1 ] > > > > >But if I extend this to the case of a signal or spectrum that is > >defined on any interval of length N, and where the i corresponding to > >the 'zero' (time or frequency) is i0, then this interval is n = [ (1 - > >i0 ) : (N - i0 ) ] and what is needed to translate this to matlab's > >interval with n( 1 ) == 0 is a circular shift by n0. > >Thus we need to do: > >circshift( h, [ 0, ( 1 - i0 ) ] ); > >which is matlab-ese for a circular shift of h left by ( i0 - 1 ) - the > >-1 because matlab starts array indices at 1.. > >Thus, by explicitly stating the matlab array index of the sample that > >corresponds to 'zero' time or frequency, any interval of length N may > >be translated correctly. And the matlab array index of 'zero' time > >could alternatively be implicitly calculated from a vector of the > >sample numbers (n) or from a time- or frequency- base. > >This is one way I would expect to see this addressed in a slightly > >object-oriented DSP architecture, where a 'signal' would also contain > >metadata such as its 'zero' time or frequency position (offset if you > >like). > > In general, consider x(t) defined over the arbitrary interval > > t = t0 + dt*[0:(N-1)] > > If t0 ~= 0 or t0 ~= -dt*ceil((N-1)/2) > > just make a change of variable > > s = (t-t0) > > Then > > X(f) = exp(i*2*pi*f*t0)*fft(x(s)). > > This makes more sense than dealing with a more complicated > shift function. > > Hope this helps. > > GregSo why is this, which I agree makes complete sense, not done in matlab normally but instead the fftshift() and ifftshift() functions are used? That is the thing that initially puzzled me. Chris
Reply by ●June 26, 20102010-06-26
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
Reply by ●June 26, 20102010-06-26
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
Reply by ●June 26, 20102010-06-26
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
Reply by ●June 26, 20102010-06-26
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
Reply by ●June 26, 20102010-06-26
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
Reply by ●June 27, 20102010-06-27
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-jIMHO 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
Reply by ●June 27, 20102010-06-27
On 27 Jun, 07:56, eric.jacob...@ieee.org (Eric Jacobsen) wrote:> 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.The reason why it has never been addressed is that MATLAB is an acronym for MATrix LABoratory. In linear algebra the numerical arrays are - like it or not - indexed base 1. Changing this would undermine nearly 30 years worth of code base. So the main decision to be made at TMW is whether they want to sell a marginally predictable product on one side, or piss off RBJ on the other. The choise might be easier than I suspect RBJ appreciates. Rune
Reply by ●June 27, 20102010-06-27
On Jun 27, 8:09�am, Rune Allnor <all...@tele.ntnu.no> wrote:> On 27 Jun, 07:56, eric.jacob...@ieee.org (Eric Jacobsen) wrote: > > > 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. > > The reason why it has never been addressed is that MATLAB is > an acronym for MATrix LABoratory. In linear algebra the numerical > arrays are - like it or not - indexed base 1.whether it's 0 or 1 is not the issue. whether the user can define it for a particular array *is* the issue.> 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.> So the main decision to be made at TMW is whether they want to > sell a marginally predictable product on one side,it's still just as deterministic as before. no one would be randomizing the origins of arrays.> or piss off RBJ on the other.it's not just me, Rune. r b-j
