Use of MATLAB fftshift

On 27 Jun, 20:06, robert bristow-johnson <r...@audioimagination.com>
wrote:
> On Jun 27, 8:09&#4294967295;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. &#4294967295;whether the user can define it
> for a particular array *is* the issue.

In that case, why can't you just use the OO capabilities of
matlab and declare your own array class, say, RBJarray, and
overload the () operator?

Ought to be a piece of cake, provided matlab's OO is half decent.

Rune

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" ;}

On Jun 27, 2:16&#4294967295;pm, Rune Allnor <all...@tele.ntnu.no> wrote:
> On 27 Jun, 20:06, robert bristow-johnson <r...@audioimagination.com>
> wrote:
>
> > On Jun 27, 8:09&#4294967295;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. &#4294967295;whether the user can define it
> > for a particular array *is* the issue.
>
> In that case, why can't you just use the OO capabilities of
> matlab and declare your own array class, say, RBJarray, and
> overload the () operator?

i think this is described in subsref() and subsasgn() and in this page
 http://www.mathworks.com/access/helpdesk/help/techdoc/matlab_oop/br09eqz.html

i had thought about it before.  i think i would call the class
"rebase" or "reorigin", because a call to something that looks like a
function called that would be what creates an object in that class
(with a regular MATLAB array as an argument as well as the new origin
values).  this psuedo-function would look like a counterpart to
"reshape".  then there would be another basic function called "base"
or "origin" that would return a vector with the origins (just like
"size" returns the values set with "reshape").

the issue is "just".  never marketed myself as an OOPs person.  i have
asked people at comp.soft-sys.matlab about this, oh, maybe 5 or 8
years ago.  can't remember what came of it.

speed is an issue.  and cleanliness (much cleaner done at the root
level since MATLAB has to subtract 1 from indices (at least for arrays
having more than one dimension) for individual  to assemble a net
pointer into the array.

> Ought to be a piece of cake, provided matlab's OO is half decent.

if you see it as a piece of cake, i would invite you to collaborate
since i am shit-for-brains regarding the nasty details of setting this
up.

a decade ago, i posted to comp.soft-sys.matlab a description on how
array arithmetic would also have to be modified (by overloading "+",
"-", "*", ".*", "\", "/", "./", "^", ".^" and all of the simple math
functions that work on a straight-forward element-by-element basis).
the array created would have the origins defined in the correct manner
(not always at 1).  Google Groups doesn't work as good as it used to
but i could try to dig up those posts.

that would be a beginning.  a different fft (i would call them "dft"
and "idft") that would look at the origins and apply the proper phase
modification (or rearrange what goes in, similarly to fftshift).
different functions for ployval() (and related functions like
polyfit()) that get the order of coefficients wrong (should be the 0th-
order or constant coef first, at the 0th index).

it would be a task, but doable to start.  still should instead be done
at the fundamental level, just like "complex" should be a basic type
in C.  it might be a piece of cake for a seasoned MATLAB programmer
who's used their OO (and maybe subsref and subsasgn) before, but i
just want to be able to do DSP and translate the common equations
directly from the lit to MATLAB without having to fiddle with the
addition or subtraction of 1 for the fft or some other constant if i
want to model a non-causal impulse response.  i should be able to just
do that directly.

if this is a piece of cake, i'd be interested in collaboration.  (but
it would still be better if it were done at the fundamental level,
without having to create a class.)

r b-j

On 27 Jun, 22:03, robert bristow-johnson <r...@audioimagination.com>
wrote:
>
> > Ought to be a piece of cake, provided matlab's OO is half decent.
>
> if you see it as a piece of cake, i would invite you to collaborate
> since i am shit-for-brains regarding the nasty details of setting this
> up.

Sorry, can't help with that. I've never really progressed
from how I started using matlab some 20 years ago, as an
algorithm testbed and general prototyping tool. Once things
turn 'real' I tend to switch to C++ rather quickly. But in
C++ what you want is trivial. For instance, switching from
a base 0 vector indexing to base 1 would be something like
(allowing for the element dereference operator being [] rather
than () in C++)

template<class T>
class base1vector : public std::vector<T>{
public:
   T& operator[](size_t i){return this->operator[](i-1);};
};

You would probably need a few variations over this theme,
and some constructors, but the gist is a simple as this.

Rune

On Jun 27, 3:22&#4294967295;pm, Richard Owlett <rowl...@pcnetinc.com> wrote:
> 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" ;}

with me, Richard, you're preaching to the choir.  i find this deficit
in MATLAB to be astonishing.  particularly so long after multiple
people have pointed it out (including an early developer for the Sig
Proc toolbox).

r b-j

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.

On Jul 4, 12:42&#4294967295;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. &#4294967295;it could be perfectly backward compatible, because
> > newly-created arrays would have default origin of 1 for every
> > dimension of the array. &#4294967295;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.

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.

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.

r b-j