have you noticed how MathWorks has responded to the horrible MATLAB indexing complaint?
robert bristow-johnson
looks like they sent out Nabeel with the anemic and hollow "We care"
response and, again, absolutely no response to the technical problem that
was put forth. and now, it appears that their hoping that it blows over
again.
no response to me. no response to Eric Jacobson (whose tone was much kinder
than mine, as if that would do any good) nor multiple other posters from
comp.dsp . they just want the issue to go away and for us DSPers to forget
about it.
'smatter MathWorks? finding out that your lame-ass excuses don't fly?
i know that there's Octave and Python (and MathCad and, hell, we can always
code it in C or C++) but, like Micro$hit, MATLAB has become the defacto
standard in modeling signal processing systems (as well as other systems).
the question is, does MathWorks plan to deal with their lead position in
this particular market the same way that Micro$oft does or do they respond
to their customer base and do their best, or at least what they can do to
make their product the best it can be or at least as good as its promise?
--
r b-j
Wave Mechanics, Inc.
45 Kilburn St.
Burlington VT 05401-4750
tel: 802/951-9700 ext. 207 http://www.wavemechanics.com/
fax: 802/951-9799 rob...@wavemechanics.com
--
Clay S. Turner
I do the consumer thing here and use other packages such as MathCad and
Mathematica.
Clay
p.s. A business man doesn't do something unless it either makes him
money or saves him money.
robert bristow-johnson
<phy...@bellsouth.net> wrote:
> Hello Robert,
> I do the consumer thing here and use other packages such as MathCad and
> Mathematica.
MATLAB still seems to be the standard in which to share or demonstrate DSP
concepts to remote parties.
> p.s. A business man doesn't do something unless it either makes him
> money or saves him money.
probably mostly true (we do things here at Wave Mechanics when customers
scream, because we wanna keep those customers) but not very enlightened.
Eric Jacobsen
<rob...@wavemechanics.com> wrote:
>looks like they sent out Nabeel with the anemic and hollow "We care"
>response and, again, absolutely no response to the technical problem that
>was put forth. and now, it appears that their hoping that it blows over
>again.
>
>no response to me. no response to Eric Jacobson (whose tone was much kinder
>than mine, as if that would do any good) nor multiple other posters from
>comp.dsp . they just want the issue to go away and for us DSPers to forget
>about it.
>
>'smatter MathWorks? finding out that your lame-ass excuses don't fly?
>
>i know that there's Octave and Python (and MathCad and, hell, we can always
>code it in C or C++) but, like Micro$hit, MATLAB has become the defacto
>standard in modeling signal processing systems (as well as other systems).
>the question is, does MathWorks plan to deal with their lead position in
>this particular market the same way that Micro$oft does or do they respond
>to their customer base and do their best, or at least what they can do to
>make their product the best it can be or at least as good as its promise?
A big difference in this case is that there are plenty of
alternatives, some of which you've listed already. If the Mathworks
continues to ignore these issues, they'll just lose more sales to the
competition in the DSP community. If the people I've worked with and
around over the last 15 years are any indication, they've already lost
a tremendous amount of business, and I think it'll only get worse as
the alternatives get better and more numerous. IMHO the Mathworks
ignores this at their own peril. Their business may still grow (which
would be my guess), but they'll be underserving a significant market,
and leaving a lot of business untapped. The business is theirs to
lose.
Eric Jacobsen
Minister of Algorithms, Intel Corp.
My opinions may not be Intel's opinions.
http://home.earthlink.net/~ejacobsensprint
Ben
>
(snip)
> i know that there's Octave and Python (and MathCad and, hell, we can always
> code it in C or C++) but, like Micro$hit, MATLAB has become the defacto
> standard in modeling signal processing systems (as well as other systems).
> the question is, does MathWorks plan to deal with their lead position in
> this particular market the same way that Micro$oft does or do they respond
> to their customer base and do their best, or at least what they can do to
> make their product the best it can be or at least as good as its promise?
>
Hi,
Don't tell me you're really surprised ! The Mathworks has had a contemptuous
attitude with their customers for years now. The answer to your question
is YES : The MathWork$ is just like Micro$oft. They have to deal with
DSPs because there is a market. As they already are a de facto standard for
numerical simulation, people buy their (expensive) products without any
doubt... and are disapointed most of the time, of course.
But who cares ? If customers are ready to pay a whole lot of money for
software tools that are not worth the third, why should Mathworks not
go on ?
As for me, when I had to do DSP stuff, I used other tools : other code
generators like Mustig or Hypersignal (both are better than Matlab's)
or manual C programming. Even for numerical simulation, we now have less
Matlab products than we had a couple of years ago...
Ben
--
---------------------------------------------------
Benoit LEPRETTRE Signal Processing Engineer
Schneider Electric SA, Grenoble, France
Note : The opinions here are mine, not my company's
---------------------------------------------------
Rick Armstrong
> (and MathCad and, hell, we can always
> code it in C or C++)
Speaking of alternatives, I get a lot of usefulness out of Scilab. Indexing
is one-based, but hey, it's free! (development is funded by the French
government...maybe the French are ok after all). It's not nearly as
full-featured as MATLAB but I just can't bring myself to spend that kind of
money (n * $1000) for my home projects. At work, I have need of such a tool
too infrequently to justify the expense. If they would make a relatively
cheap base product (< $500), then charge big bucks for the "toolboxes", I'd
be first in line. For now, I'll stick to Scilab and C++.
Rick Armstrong
Note: (the "attached" email address is bogus)
Ben
>
> Speaking of alternatives, I get a lot of usefulness out of Scilab. Indexing
> is one-based, but hey, it's free! (development is funded by the French
> government...maybe the French are ok after all).
What d'ya mean "after all" ?!? :o)))
>It's not nearly as
> full-featured as MATLAB but I just can't bring myself to spend that kind of
> money (n * $1000) for my home projects. At work, I have need of such a tool
> too infrequently to justify the expense. If they would make a relatively
> cheap base product (< $500), then charge big bucks for the "toolboxes", I'd
> be first in line. For now, I'll stick to Scilab and C++.
There are also a lot of toolboxes for Scilab, but surely not as many as for
Matlab. Enough for most users, though...
RM
Maple isn't cheap either, but at least I get not
milked again and again when I need some extra libraries
and toolboxes, and the newer releases are said to have
solved the old troubles with numeric speed.
"robert bristow-johnson" <rob...@wavemechanics.com> schrieb im Newsbeitrag
news:t3oR7.133$8m1...@nwrddc01.gnilink.net...
Bob Cain
of us in comp.dsp that don't go over there routinely?
Bob
--
"Things should be described as simply as possible, but no simpler."
A. Einstein
////////////////////////////////////////\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
To contribute your unused processor cycles to the fight against cancer:
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\///////////////////////////////////////
Ken Prager
wrote:
> Robert, would you mind summarizing the issue under discussion with those
> of us in comp.dsp that don't go over there routinely?
Here are three threads--from newest to oldest...
<http://groups.google.com/groups?hl=en&threadm=MXbQ7.14%24s71.17614%40nwr
ddc02.gnilink.net&rnum=3&prev=/groups%3Fq%3Drobert%2Bbristow-johnson%26hl
%3Den%26group%3Dcomp.soft-sys.matlab%26rnum%3D3%26selm%3DMXbQ7.14%2524s71
.17614%2540nwrddc02.gnilink.net>
<http://groups.google.com/groups?hl=en&threadm=3882B39D.734E%40viconet.co
m&rnum=5&prev=/groups%3Fq%3Drobert%2Bbristow-johnson%26hl%3Den%26group%3D
comp.soft-sys.matlab%26rnum%3D5%26selm%3D3882B39D.734E%2540viconet.com>
<http://groups.google.com/groups?hl=en&threadm=3896aaf2.1458218958%40news
.dtu.dk&rnum=1&prev=/groups%3Fq%3Drobert%2Bbristow-johnson%26hl%3Den%26gr
oup%3Dcomp.soft-sys.matlab%26rnum%3D1%26selm%3D3896aaf2.1458218958%2540ne
ws.dtu.dk>
Google is a wonderful thing,
KP
robert bristow-johnson
> Robert, would you mind summarizing the issue under discussion with those
> of us in comp.dsp that don't go over there routinely?
From my POV, the issue centers around a basic promise of MATLAB:
"MATLAB is a high-performance language for technical computing. It
integrates computation, visualization, and programming in an easy-to-use
environment where problems and solutions are expressed in familiar
mathematical notation." (Getting Started with MATLAB, v. 5)
Or from an older MATLAB reference guide (ca. 1992):
"MATLAB integrates numerical analysis, matrix computation, signal
processing, and graphics in an easy-to-use environment where problems and
solutions are expressed just as they are written mathematically - ... "
Note the phrases in claims: "familiar mathematical notation" and "just as
they are written mathematically". I submit that those claims are false in a
sense that is salient particularly for those of use who use MATLAB for
(digital) signal processing.
In Discrete-Time Signal Processing (otherwise known as "Oppenheim and
Schafer") p. 531, Eqs. (8.57) and (8.58), the Discrete Fourier Transform
(DFT) and inverse DFT are defined as:
N-1
X[k] = SUM{ x[n] * exp(-j*2*pi*n*k/N) }
n=0
N-1
x[n] = (1/N)*SUM{ X[k] * exp(+j*2*pi*n*k/N) }
k=0
Whereas MathWorks defines these for MATLAB to be:
N
X[k] = SUM{ x[n] * exp(-j*2*pi*(n-1)*(k-1)/N) }
n=1
N
x[n] = (1/N)*SUM{ X[k] * exp(+j*2*pi*(n-1)*(k-1)/N) }
k=1
Likewise on p. 21 Eq. (2.39) O&S define discrete convolution as:
+inf
y[n] = SUM{ x[k] * h[n-k] }
k=-inf
which is equivalent to:
+inf
y[n] = SUM{ x[n-k] * h[k] }
k=-inf
If the impulse response were causal and finite (i.e. a causal FIR where N =
# of taps), that equation would degenerate to:
N-1
y[n] = SUM{ x[n-k] * h[k] }
k=0
But MATLAB says it's this:
N
y[n] = SUM{ x[n-1-k] * h[k] }
k=1
or
N-1
y[n+1] = SUM{ x[n-k] * h[k+1] }
k=0
and, in fact, makes excuses for that in the Signal Processing Toolbox manual
(ca. 1993) p. 1-12:
"Note: The filter coefficients start with subscript 1 rather than 0. This
reflects MATLAB's standard indexing scheme for vectors."
and p. 2-56:
"The series is indexed from n+1 and k+1 instead of the usual n and k because
MATLAB vectors run from 1 to n instead of 0 to n-1."
The DFT and convolution summations are not the only examples (the way IIR
coefficients are ordered is another that occurs to me), but are *so*
fundamental that for a company whose product expresses mathematical
instructions "just as they are written mathematically", lot's of red flags
should have been flying up when they were essentially being forced to change
or contrive those well established expressions into their fixed 1-based
indexing scheme. The fact they didn't do this 10 years ago is no excuse for
not fixing the problem now ASAP, because their product has already become
the defacto standard used by the signal processing community to concisely
exchange ideas and algorithms (in addition to modeling and emulating these
algorithms for themselves).
So will MathWorks deal with this the same way Micro$oft does or will they do
the right thing? Will they use their market power to replace the
mathematically natural definitions of fundamental DSP concepts that exist in
*all* of the textbooks with the unnatural (offset by 1) definitions that
MATLAB currently has? Will Oppenheim and Schafer eventually have to change
their representation of convolution and the DFT (and the hundreds of
formulae based on those definitions) to the MATLAB version? Or will we
continue to have to juggle between the conflicting definitions in our work?
Is it consistent with the goal of MATLAB to provide an "easy-to-use
environment where problems and solutions are expressed just as they are
written mathematically" for us to juggle between these two non-equivalent
definitions of the same fundamental DSP formulae that nearly *every* DSP
concept is based on? I can't think of hardly anything in DSP that is not
fundamentally based on convolution or the DFT somewhere in the operation.
In a later post, I will present (again, since I did this a year ago) a
perfectly backward compatible solution that, for some odd reason, MathWorks
apparently refuses to consider or to debate.
Cleve Moler
>
>> Robert, would you mind summarizing the issue under discussion with those
>> of us in comp.dsp that don't go over there routinely?
In article <e5qS7.1887$Ga....@nwrddc01.gnilink.net>,
robert bristow-johnson <rob...@wavemechanics.com> replied (in part):
> ...
>
>Is it consistent with the goal of MATLAB to provide an "easy-to-use
>environment where problems and solutions are expressed just as they are
>written mathematically" for us to juggle between these two non-equivalent
>definitions of the same fundamental DSP formulae that nearly *every* DSP
>concept is based on? I can't think of hardly anything in DSP that is not
>fundamentally based on convolution or the DFT somewhere in the operation.
>
>In a later post, I will present (again, since I did this a year ago) a
>perfectly backward compatible solution that, for some odd reason, MathWorks
>apparently refuses to consider or to debate.
>
>r b-j
Hi --
Like many people at MathWorks, I have been reading all the posts in
this thread, but have hesitated to get involved because the level of
discussion has been so unpleasant and nontechnical. But here Robert
has made a compelling argument that deserves a civil reply.
I agree that indexing in DSP is zero-based and I agree that it would
be desirable to reflect that in MATLAB notation. But MATLAB is based
on linear algebra where indexing is conventionally one-based. As
a result, instead of defining the FFT by
> N
> X[k] = SUM{ x[n] * exp(-j*2*pi*(n-1)*(k-1)/N)
> n=1
I would use
N-1
X(k+1) = SUM x(n+1) * exp(-j*2*pi*n*k/N) , k = 0:N-1
n=0
Or, better yet, use matrix-vector multiplication:
% The Finite Fourier Transform
omega = exp(-2*pi*j/N)
k = 0:N-1
F = omega.^(k'*k)
X = F*x
But that's avoiding the issue of zero-based subscripts.
The real problem is backwards compatibility. The MATLAB community,
including MathWorks and customers around the world, has millions of
lines of code using one-based subscripts. What happens to all that
code if we extend MATLAB notation to also allow zero- or variable-based
subscripts? What does "find" return? How do I write a matrix library
if I don't know where the subscripts start? How do I refer to the leading
element of a string? In fact, is it the "first" element, or the
"zeroth" element?
We don't refuse to consider this issue. There are few issues that
we have considered more. And we don't refuse to debate. But if
you want our participation, please make it a debate, not a diatribe.
-- Cleve Moler
mo...@mathworks.com
robert bristow-johnson
(Cleve Moler) wrote:
...
>
> Like many people at MathWorks, I have been reading all the posts in
> this thread, but have hesitated to get involved because the level of
> discussion has been so unpleasant and nontechnical.
I might have been unpleasant, but have always been quite technical regarding
this issue.
> But here Robert
> has made a compelling argument that deserves a civil reply.
>
> I agree that indexing in DSP is zero-based and I agree that it would
> be desirable to reflect that in MATLAB notation. But MATLAB is based
> on linear algebra where indexing is conventionally one-based. As
> a result, instead of defining the FFT by
>
>> N
>> X[k] = SUM{ x[n] * exp(-j*2*pi*(n-1)*(k-1)/N)
>> n=1
>
> I would use
> N-1
> X(k+1) = SUM x(n+1) * exp(-j*2*pi*n*k/N) , k = 0:N-1
> n=0
But that is not what *any* DSP textbook uses for it's definition of the DSP,
is it Cleve? Slipping that "+1" into the subscript of the array looks
reasonably innocuous but what happens if you say:
[Xmax, Fmax] = max(abs(X));
to find the value of the peak frequency, Fmax? We must juggle your
definition with the natural and well-established definition in all of the
DSP textbooks and literature. We must remember to subtract 1 from Fmax,
otherwise it will be wrong. In a large and complicated MATLAB program (say,
a souped-up phase-vocoder), it is not unheard of (I can testify to this
directly) to lose hours of time searching for an obscure bug where one has
forgotten to subtract that 1 in computing frequency. But it's hard for me
to accept blame for that bug when the root of it is the non-standard
definition of the DFT that is forced upon us by the inflexible (and also
incorrect or at least unconventional) indexing scheme in MATLAB.
> Or, better yet, use matrix-vector multiplication:
>
> % The Finite Fourier Transform
> omega = exp(-2*pi*j/N)
> k = 0:N-1
> F = omega.^(k'*k)
> X = F*x
>
> But that's avoiding the issue of zero-based subscripts.
>
> The real problem is backwards compatibility.
I've disposed of that last year. I hope that you are willing to debate this
to its conclusion rather than just going silent when dispose of it this
time. That is why I got so frustrated and less civil. You state that
backwards compatibility is a problem and when I show exactly why it is not,
there was nothing but silence from you, Cleve, and everyone else at
MathWorks.
> The MATLAB community,
> including MathWorks and customers around the world, has millions of
> lines of code using one-based subscripts.
Of course. No product enhancement should hurt any of that code or the basic
function of it. I fully agree that it should be perfectly backward
compatible.
> What happens to all that
> code if we extend MATLAB notation to also allow zero- or variable-based
> subscripts?
NOTHING DOES. The reason why we know this is that 0 is the "identity vector
under the operation of addition". As I've suggested last year, the
perfectly backward compatible fix is to add to each MATLAB variable, right
beside the internal vector that defines the length of each dimension of the
MATLAB array, a vector of identical length (the length is equal to the
number of dimensions) that contains offsets to the indices of each
dimension. The implied "base" index is 1-offset for that dimension and THE
OFFSETS ALWAYS DEFAULT TO ZERO when a new array is created from scratch or
as the result of any operation on other 1-based (or 0-offset) arrays.
That's what makes it perfectly backward compatible. No legacy code will
break and I challenge anyone to come up with an example that does. I am
completely confident about this because I know that when you add or subtract
0 to any number, the result is unchanged.
> What does "find" return?
the indices returned by min(), max(), find(), sort(), ind2sub() (and any
other MATLAB function that returns indices) would have to adjust its
returned values by subtracting that very same offset for the corresponding
dimension.
> How do I write a matrix library
> if I don't know where the subscripts start?
But you *do*! Because of at least two new facilities that would have to be
created, one for changing the base (similar to reshape()), let's call it
"rebase()" and another for determining the base (similar to size()), let's
call that "base()". Rather than making you go back in Google Groups and
read what I posted a year ago, I will try to post in a few hours exactly
what the proposed fix is. Then nearly all of these questions will be
answered.
> How do I refer to the leading element of a string?
The same as you do now, except that MATLAB subtracts the offset parameter
that is defaulted or initialized to zero.
> In fact, is it the "first" element, or the "zeroth" element?
If it's a 1-based array, it's the "first" element (and that is always the
default and doesn't change unless the MATLAB user specifically changes the
base). If it's a 0-based array, it's the "zeroth" element. If it's a -128
based array, its index or subscript is -128.
> We don't refuse to consider this issue. There are few issues that
> we have considered more. And we don't refuse to debate. But if
> you want our participation, please make it a debate, not a diatribe.
I will try. I ask in return that silence or non-responsiveness is not used
as a debating technique when I *do* address your concerns of backward
compatibility. And I would also ask that the concept of "backward
compatibility" is not changed nor obfuscated from its simple and
straight-forward definition (that is, old code written before this
enhancement continues to work after the enhancement without changes).
Give me a couple of more hours and I'll post the main details of the
proposed fix (which i did last year) that I assert is perfectly backward
compatible.
Bob Cain
robert bristow-johnson wrote:
>
> In a later post, I will present (again, since I did this a year ago) a
> perfectly backward compatible solution that, for some odd reason, MathWorks
> apparently refuses to consider or to debate.
Ah, the old zero/one origin indexing argument. I look forward to your
proposal. The last time this discussion went around that I was in
attendance the compatibility question nailed the coffin shut on the
argument and there wasn't a whole lot of argument even presented for the
wisdom of the original decision.
As an APL user for more than 30 years I am very annoyed by the 1-origin
only architecture of Matlab but APL was designed from the ground up to
deal with dual origins so that function authors knew they had to be
aware that their functions could be called from either context and that
those considerations extended to the data itself. Being very familiar
with what that meant I can see why a change at this point could have
catastrophic impact on existing libraries but if you see a way to do it
without requiring _any_ change to the existing Matlab code base I am all
ears.
Edwin Robert Tisdale
> Like many people at MathWorks,
> I have been reading all the posts in this thread
> but have hesitated to get involved
> because the level of discussion
> has been so unpleasant and nontechnical.
> But Robert has made a compelling argument
> that deserves a civil reply.
>
> I agree that indexing in DSP is zero-based and I agree that
> it would be desirable to reflect that in MATLAB notation.
> But MATLAB is based on linear algebra
> where indexing is conventionally one-based.
> As a result, instead of defining the FFT by
>
> N
> X[k] = SUM{ x[n] * exp(-j*2*pi*(n-1)*(k-1)/N)
> n=1
>
> I would use
>
> N-1
> X(k+1) = SUM x(n+1) * exp(-j*2*pi*n*k/N) , k = 0:N-1
> n=0
Actually, the index base has nothing to do
with either linear algebra or digital signal processing.
Fortran programmers use 1 based indexing for both
and C and C++ programmers use 0 based indexing for both.
> Or, better yet, use matrix-vector multiplication:
>
> % The Finite Fourier Transform
> omega = exp(-2*pi*j/N)
> k = 0:N-1
> F = omega.^(k'*k)
> X = F*x
>
> But that's avoiding the issue of zero-based subscripts.
>
> The real problem is backwards compatibility.
> The MATLAB community
> including MathWorks and customers around the world
> has millions of lines of code using one-based subscripts.
> What happens to all that code if we extend MATLAB notation
> to also allow zero- or variable-based subscripts?
> What does "find" return? How do I write a matrix library
> if I don't know where the subscripts start?
> How do I refer to the leading element of a string?
> In fact, is it the "first" element, or the "zeroth" element?
You could introduce a new indexing operator .( )
which is zero based.
> We don't refuse to consider this issue.
> There are few issues that we have considered more.
> And we don't refuse to debate.
> But if you want our participation,
> please make it a debate and not a diatribe.
I strongly recommend that you filter out the diatribes
and respond only to compelling arguments
if you are going to respond at all.
The comp.dsp newsgroup has more than its share
of indigenous trolls and battle hardened flame warriors.
You will soon learn who they are
and that it is best to simply ignore them.
robert bristow-johnson
> robert bristow-johnson wrote:
>>
>> In a later post, I will present (again, since I did this a year ago) a
>> perfectly backward compatible solution that, for some odd reason, MathWorks
>> apparently refuses to consider or to debate.
>
> Ah, the old zero/one origin indexing argument.
It's not just 1 vs. 0 . An array index should be able to be bounded by
virtually any pair of finite integers. Arrays should be able to start with
1, 0, 10, -10 or -128 (the negative indices make it possible to cleanly
model acausal FIR filters, something that is useful for doing interpolation
or sample rate conversion or windowing).
> I look forward to your proposal.
It be below.
> The last time this discussion went around that I was in
> attendance the compatibility question nailed the coffin shut on the
> argument
I fail to see how. They (MathWorks) brought it up, I showed why there would
be no difference on legacy code (except for a very small increase in
execution time due to one additional small operation done to the indices),
MathWorks responded with utter silence on one occasion and on another
responded with straw men that were not truly problems of backward
compatibility.
> and there wasn't a whole lot of argument even presented for the
> wisdom of the original decision.
There was none except for saying MATLAB was originally envisioned as a
concise matrix processing language and all of the math textbooks give the
upper left corner of a matrix the indices (1,1). I agree with that, but it
does not preclude having the ability to create arrays with indices that do
not begin with 1.
> As an APL user for more than 30 years I am very annoyed by the 1-origin
> only architecture of Matlab but APL was designed from the ground up to
> deal with dual origins so that function authors knew they had to be
> aware that their functions could be called from either context and that
> those considerations extended to the data itself.
I've never used APL but I do program in C a lot and you can create a pointer
to an array that can mimic an array name and offset it in such a way that
the base of the array (the index of the "leading element") can be whatever
number you want. This is because C doesn't bound-check the array indices
during run-time as MATALB or Fortran (at least the Fortran of my day) does.
That bound checking is a necessary thing for MATLAB, in my opinion, because
if I'm modeling some process where I compute an index, I want to know if my
index went out of bounds before I code this into a DSP and an airplane falls
from the sky as the result of such an error.
> Being very familiar with what that meant I can see why a change at this point
> could have catastrophic impact on existing libraries
Not if you make the default array base the same as before (and do not write
code that uses any of the new re-basing feature in which legacy code cannot
do, of course, unless somebody has a time machine). Then there is no danger
of any "catastrophic impact on existing libraries".
> but if you see a way to do it without requiring _any_ change to the existing
> Matlab code base I am all ears.
Here it is:
Not being a MathWorks insider (I can't imagine why not) I have to guess a
little at the structure of a MATLAB variable:
enum MATLAB_class {text, real, complex};
// I don't wanna cloud the issue considering other classes.
typedef struct
{
void* data; // pointer to actual array data
char* name; // pointer to the variable's name
enum MATLAB_class type; // class of MATLAB variable (real, complex,...)
int num_dimensions; // number of array dimensions >= 2
long* size; // points to a vector with the number of rows, columns, etc.
} MATLAB_variable;
name[32]; // MATLAB names are unique to 31 chars
size[num_dimensions];
if (type == text)
{
char data[size[0]*size[1]*...*size[num_dimensions-1]];
}
else if (type == real)
{
double data[size[0]*size[1]*...*size[num_dimensions-1];
}
else if (type == complex)
{
double data[size[0]*size[1]*...*size[num_dimensions-1][2];
}
When an element, A(n,k), of a 2 dimensional MATLAB array A is accessed,
first n and k are confirmed to be integer value (not a problem in C), then
confirmed to be positive and less than or equal to size[0] and size[1],
respectively. It those constraints are satisfied, the value of that element
is accessed as:
data[(n-1)*size[1] + (k-1)];
For a 3 dimensional array, A(m,n,k), it would be the same but now:
data[((m-1)*size[2] + (n-1))*size[1] + (k-1)];
I realize that the pointer to "data" can be judiciously offset so that the
subtraction of 1 from the MATLAB indices to create the C indices would not
be necessary. I think any modern Fortran does this. Also I realize that
the MATLAB variable structure may have other internal fields that are not
described above and that I don't know about, but I don't see any reason what
that would affect the issues here.
What is proposed is to first add a new member to the MATLAB variable
structure called "offset" which is a vector of the very same length
(num_dimensions) as the "size" vector. The default value for all elements
of the offset[] vector would be 0 with only the exceptions outlined below.
This is what makes this backwards compatible, in the strictest sense of the
term.
typedef struct
{
void* data;
char* name;
enum MATLAB_class type;
int num_dimensions;
long* size;
long* offset; // points to a vector with index offset for each dimension
} MATLAB_variable;
name[32];
size[num_dimensions];
offset[num_dimensions];
Now immediately before each index is checked against the bounds for that
dimension ( > 0 and <= size[dim] where 0<=dim<num_dimensions), the offset
for that particular dimension (offset[dim]) is added to the index and then
the bounds comparison is made, and the element is accessed. Since the
default is 0, this will have no effect, save for the teeny amount of
processing time need to add the offset, on existing MATLAB legacy code.
The base index for an array dimension, dim, would be 1-offset[dim] and of
course the offset for that dimension would be 1-base[dim] .
Okay, how someone like myself would use this to do something different is
that there would be at least two new MATLAB facilities similar to size() and
reshape() that I might call "base()" and "rebase()", respectively. Just
like MATLAB size() function returns the contents of the size[] vector,
base() would return in MATLAB format, the contents of the offset[] vector
except it would be 1-offset. And just like reshape() changes (under proper
conditions) the contents of the size[] vector, rebase() would change the
contents of the offset[] vector except that the offset[dim] values would be
1-base[dim]. Since rebase() does not exist in legacy MATLAB code (oh, i
suppose someone could have created a function named that, but that's a
naming problem that need not be considered here), then there is no way for
existing MATLAB programs to change the offsets from their default values of
0 making this fix perfectly backward compatible.
Now just as there are dimension compatibility rules that exist now for
MATLAB operations, there would be a few natural rules that would be added so
that "rebased" MATLAB arrays could have operations applied to them in a
sensible way.
ARRAY ADDITION and SUBTRACTION and element-by-element ARRAY MULTIPLICATION,
DIVISION, POWER, and ELEMENTARY FUNCTIONS:
Currently MATLAB insists that the number of dimensions are equal and the
size of each dimension are equal (that is the same "shape") before adding or
subtracting matrices or arrays. The one exception to that is adding a
scaler to an array in which a hypothetical array of equal size and shape
with all elements equal to the scaler is added to the array. The resulting
array has the same size and shape as the input arrays.
The proposed system would, of course, continue this constraint and add a new
constraint in that index offsets for each dimension (the offset[] vector)
would have to be equal for two arrays to be added. The resulting array
would have the same shape and offset[] vector as the input arrays.
"MATRIX" MULTIPLICATION:
A = B*C;
Currently MATLAB appropriately insists that the number of columns of B are
equal to the number of rows of C (we shall call that number K). The
resulting array has the number of rows of B and the number of columns of C.
The value of a particular element of A would be:
K
A(m,n) = SUM{ B(m,k) * C(k,n) }
k=1
The proposed system would, of course, continue this constraint and add a new
constraint in that index offsets must be equal for each dimension where the
lengths must be equal. That is the number of columns of B are equal to the
number of rows of C and the base index of the columns of B are equal to the
base index of the rows of C. The resulting array has the number of rows of
B and the number of columns of C and the base index of the rows of B and
the base index of the columns of C. The value of a particular element of A
would be:
base+K
A(m,n) = SUM{ B(m,k) * C(k,n) }
k=base
where base = 1-offset[0] for the B array and 1-offset[1] for the C array
which must be the same number.
Both of these definitions are degenerations of the more general case where:
+inf
A(m,n) = SUM{ B(m,k) * C(k,n) }
k=-inf
where here you consider B and C to be zero-extended to infinity in all four
directions (up, down, left, and right). It's just that the zero element
pairs do not have to be multiplied and summed.
Probably matrix powers and exponentials (on square matrices) can be defined
to be consistent with this extension of the matrix multiply, but I can deal
with it at the moment.
CONCATINATION:
This would also be a simple and straight-forward extension of how MATLAB
presently concatinates arrays. When we say:
A = [B C];
The number of rows of B and C must be equal, but the number of columns of B
and C can be anything. The first columns of A are identical with the
columns of B and then also must the indices of those columns. And
independent of what the column indices of C are, they just pick up where the
column index of B left off. This rule extension defaults to what MATLAB
presently does if B and C are both 1-based arrays. A similar rule extension
can be made for A = [B ; C]; In all cases the upper left corner of A is
identical to the upper left corner of B, both in value but also in
subscripts (so A(1,1) becomes B(1,1) just like it does now in MATLAB).
MATRIX DIVISION ('/' and '\'):
I have to think about that a little, but I'm pretty sure a backward
compatible extension to the operations can be figgered out. If not, it
would be an illegal operation unless the bases were 1.
FUNCTIONS THAT RETURN INDICES (min(), max(), find(), sort(), ind2sub(), and
any others that I don't know about):
It must be internally consistent (and certainly can be made to be). The
indices returned would be exactly like the 1-based indices returned
presently in MATLAB except that the offset for the corresponding dimension
(that defaults to zero) would be subtracted from each index. That is, just
like now in MATLAB:
[max_value, max_index] = max(A);
This must mean that A(max_index) is equal to max_value.
I think that this is easy enough to define. The only hard part is to
identify all MATLAB functions that search through an array and modify them
to start and end at indices that might be different than 1 and size[dim] as
are the search bounds today. It would instead search from 1-offset[dim]
(the base) to size[dim]-offset[dim] which would default to the current
operation if the offset equals zero.
FOR ALL OTHER MATLAB OPERATIONS, until a reasonable extended definition for
non 1-based arrays is thunk up, MATLAB could either bomb out with an illegal
operation error if the base is not 1 or could, perhaps, ignore the base.
Either way it's still backwards compatible.
In a later post, I will suggest a few new DSP functions (they would actually
be new versions of existing DSP functions but with somewhat different names
so that there is backward compatibility) that would be made *far* more
elegant if these changes/extensions are implemented in MATLAB. I would
begin with convolution and the DFT.
Cleve, I hope that you and some of your "young Turks" at MathWorks will
seriously and thoughtfully look this over and respond. I might also suggest
that "straw men" counter examples to backwards compatibility requirement be
avoided in your response and that you folks stick closely to the strict
definition of "backwards compatibility". That strict definition means that
any code previously written in MATLAB will run with this extension exactly
as it had before the extension (except a minute amount slower due to the
offset addition).
robert bristow-johnson
yup! i'm convinced. it's the same E.Bob and heeeeeeee's back! it's like
the movie sequel, "Ghandi II - He's back, and he's mad." dauntless defender
of comp.dsp and all of USENET against us sexist trolls and flame warriors!
everyone must check his official comp.dsp Blacklist:
http://www.netwood.net/~edwin/comp/dsp/blacklist.html to see who them nasty
trolls and flamers are.
welcome back, E.Bob! as in the W (p)residency, we can derive a little humor
from your presence. or perhaps you'ld like to provide some substantive and
useful technical content to the forum. that would be welcome also.
r b-j
In article <3C1A6F48...@jpl.nasa.gov> , Edwin Robert Tisdale
<E.Robert...@jpl.nasa.gov> wrote:
> Cleve Moler wrote:
>
>> Like many people at MathWorks,
>> I have been reading all the posts in this thread
>> but have hesitated to get involved
>> because the level of discussion
>> has been so unpleasant and nontechnical.
>> But Robert has made a compelling argument
>> that deserves a civil reply.
>>
>> I agree that indexing in DSP is zero-based and I agree that
>> it would be desirable to reflect that in MATLAB notation.
>> But MATLAB is based on linear algebra
>> where indexing is conventionally one-based.
>> As a result, instead of defining the FFT by
>>
>> N
>> X[k] = SUM{ x[n] * exp(-j*2*pi*(n-1)*(k-1)/N)
>> n=1
>>
>> I would use
>>
>> N-1
>> X(k+1) = SUM x(n+1) * exp(-j*2*pi*n*k/N) , k = 0:N-1
>> n=0
>
> Actually, the index base has nothing to do
> with either linear algebra or digital signal processing.
except convenience and consistency to the literature.
> Fortran programmers use 1 based indexing for both
> and C and C++ programmers use 0 based indexing for both.
and C and C++ programmers (like me) have made arrays or "pseudo-arrays" in
which we define any base we want so that our code looks clean and we don't
have to offset any negative indices each and every time they may come up.
that, my Mr. Tisdale, is how to model acausal FIR filters.
ARGGHHHHHH!
YOU CAN'T IGNORE US!!!!
ARGGHHHHHH! (jumping up and down furiously waiting for little Billy-Goat
Gruff.)
WHO'S THAT WALKING OVER MY BRIDGE?!! ARGGHHHHHH!
Matthew Donadio
> I agree that indexing in DSP is zero-based and I agree that it would
> be desirable to reflect that in MATLAB notation. But MATLAB is based
> on linear algebra where indexing is conventionally one-based. As
> a result, instead of defining the FFT by
Cleve,
I think the reason why everyone is so upset is that MATLAB is heavily
advertised as being a DSP tool, but it doesn't let users use normal DSP
notation. This is really frustrating. For example, if you look in the
manual at the prony command, it refererences the Parks & Burrus book,
but the manual and the book use different notation.
Nearly all DSP related papers use zero-based arrays. It does not make
sense to publish a paper with a new algorith in it, and have the paper
and the example code (which is generally MATLAB) use different
conventions, but it happens all the time.
We're not asking to break backward compatibility, just an extension to
have the ability to specify the starting base of our arrays.
--
Matthew Donadio (m.p.d...@ieee.org)
Eric Jacobsen
wrote:
>Hi --
>
>Like many people at MathWorks, I have been reading all the posts in
>this thread, but have hesitated to get involved because the level of
>discussion has been so unpleasant and nontechnical.
Personally, I find this a little insulting, but perhaps we're talking
about different things.
>But here Robert
>has made a compelling argument that deserves a civil reply.
>
>I agree that indexing in DSP is zero-based and I agree that it would
>be desirable to reflect that in MATLAB notation. But MATLAB is based
>on linear algebra where indexing is conventionally one-based.
When this came up a few years ago I tried to make the point that most
users (of most technical systems) couldn't care less about how the
tool is implemented or what the legacy is, they care about how it will
help them get their work done. The fact that MATLAB is based on
linear algebra may be a reason for the origin of one-based indexing,
but it is a poor excuse or rationale for continual justification in
the context of attempting to be a generalized tool. As a DSP and
communications person, I -really-, _really_, *really* don't care why
MATLAB was implemented with one-based indexing. What I do care about
is the additional time it takes me to translate, code, and debug
MATLAB routines because of this forced disconnect between standard
mathematical notation, it's connection to physical meaning, and how I
have to adjust all of that to code it (and debug it) in MATLAB.
...
>The real problem is backwards compatibility. The MATLAB community,
>including MathWorks and customers around the world, has millions of
>lines of code using one-based subscripts. What happens to all that
>code if we extend MATLAB notation to also allow zero- or variable-based
>subscripts?
Nothing if you come up with a suitable fix that is backward
compatible. There were several suggestions a few years ago that
seemed to go a long ways toward addressing the problem and preserving
backward compatibility (since that isn't lost on the people who are
concerned about this, many of us have a lot of legacy code, too), and
that's just from knowledgable concerned users. I'd guess that your
engineers and coders are creative enough and talented enough to come
up with similar or better means to achieve those ends.
>What does "find" return? How do I write a matrix library
>if I don't know where the subscripts start? How do I refer to the leading
>element of a string? In fact, is it the "first" element, or the
>"zeroth" element?
As I mentioned, this was addressed with several possible solutions by
several different people a few years ago when this came up. Since
Google has all of that stuff easily available now, the details of the
suggestions could be easily looked up.
>We don't refuse to consider this issue. There are few issues that
>we have considered more. And we don't refuse to debate. But if
>you want our participation, please make it a debate, not a diatribe.
And try, please, to not insult us. The folks who rant likely do so
because they care. They have a problem with using your product that
they'd like to see addressed because it causes them difficulty. As
the vendor of that product if you disenfranchise them for being
frustrated with your product, the likely result may be that they go
use something else. We can vote with our wallets, and in my
experience I think you'd be surprised how many have voted against you
because of this single issue.
I know I'd feel a lot better if I heard something from you guys other
than "How should we fix this?" (like the above, which could be
interpreted to indicate you're not up to the task yourself), reasons
why it hasn't been, can't be, or shouldn't be fixed, or how it *may*
or will definitely be fixed in an upcoming release, which then doesn't
happen. I'd much prefer a vendor that listens to what roadblocks I'm
encountering in getting productivity out of their tool and then tries
to figure out how to remove those roadblocks, than one that tries to
explain away the roadblock or tell me they won't even participate in a
discussion of the roadblock if they don't like how I describe it.
One way is a path to more productivity for me and my company, which
we're willing to pay for, and one way is a path to continued
frustration for the users which leads us to look for alternatives (or,
in many cases, to continue using the alternatives and not purchase
MATLAB).
Clearly the call is yours in how to handle the situation, but don't
think people don't make purchasing decisions based on this. I know of
personal cases because I've hit this wall on this very issue with many
departments in several different companies, and in my experience it
has cost you a lot of business. If my experience is even remotely
exemplary then it would seem to me that the resources needed to fix
this issue would be easily paid for in increased sales. I'd use it
more, and I'd be able to recommend it more (or even start recommending
it in cases where I've recommended against it for this reason).
But perhaps my tone is not up to your liking and you didn't even read
this far.
Bob Cain
robert bristow-johnson wrote:
>
>
> It be below.
Thanks, Robert. I don't often print usenet postings but did this one
and will study it.
John D'Errico
be frustrating to use was finding bugs from its allowance
of non-fixed based indexing.
Some of us actually like 1 based indexing. A lot of us
even.
So TMW, if you do decide to fix their problems, please do
it so it does not blow the rest of us out of the water.
John D'Errico
--
Jordan Rosenthal
> The real problem is backwards compatibility. The MATLAB community,
> including MathWorks and customers around the world, has millions of
> lines of code using one-based subscripts. What happens to all that
> code if we extend MATLAB notation to also allow zero- or variable-based
> subscripts? What does "find" return? How do I write a matrix library
> if I don't know where the subscripts start? How do I refer to the leading
> element of a string? In fact, is it the "first" element, or the
> "zeroth" element?
I know it has been brought up before but how about creating a new discrete
signal object? I haven't seen a definitive argument yet for why this
wouldn't work. It wouldn't have to break any older code (see below); it
would only require overloading many of the builtin objects.
The disignal object could (at a minimum) have the following fields:
%---
dsignal.data: array to hold the actual data.
dsignal.origin: the index of the data array that holds the origin. this
should be allowed to point outside the available data as well. Default
would be 1 which implies that dsignal.data(1) represents the spatial origin.
dsignal.label: a name for labeling purposes
dsignal.dimension_labels: cell array of labels for each dimension. E.g.,
{'time','amplitude'}
dsignal.version: version number to allow for expansion in the future
(perhaps this is a hidden field)
%-----
Aside: The definition of dsignal.origin above is the simplest and was
presented just for the argument's sake. An alternative way to achieve the
same results would be to designate the shift required to bring matrix
element (1,1,....) to the spatial origin. That is, view the data stored in
dsignal.data as x[n-n0] and specify the n0. Thus, an n0 of zero would imply
that dsignal.data(1) is at the spatial origin, i.e., there is no shift. The
value of n0 would be a vector for multi-d data.
This one problem I have with the signal approach is how to easily allow a
dsignal object to pass its data to a function that hasn't been overloaded.
If such a method existed, then one could combine new code that handles the
dsignal object directly with old code that nobody really wants to take the
time to rewrite to handle the new object. Here are the sparks of a few
ideas:
1) One simple solution to this problem is to create a subscript reference
that returns the values in the dsignal.data field. For example, if one had
some old code that implemented a spectrum estimater, then one could call it
with something like (assume x is a dsignal object):
a) y = my_estimate(x.data);
b) y = my_esimate(getdata(x));
c) y = my_estimate(x(:))
d) y = my_estimate(x(:,:));
e) y = my_estimate(x~);
f) y = my_estimate(~x);
% These last two are not actually possible
% for the current implementation of subscript references,
% but I think it would solve many problems if something
% like this were possible.
2) Create another field of the object called dsignal.reference_mode. It can
take two values ('object' or 'array') defined as follows:
a) 'object': any reference to the dsignal object will return the object.
Thus, a call to my_estimate(d) passes the object d to the function
my_estimate and x = d assigns the object d to x. This is no different from
the way objects currently work.
b) 'array': any reference to the dsignal object will return a reference to
dsignal.data. Thus, a call to my_estimate(d) passes the value of
dsignal.data to the function my_estimate and the assignment x = d assigns x
to dsignal.data. The only exception to this rule is when referencing the
reference_mode field itself. Thus, d.reference_mode will operate on the
object d not the data d.data. This allows one to change the mode back to
'object' without causing errors.
With this new field, one can call older functions with:
d.reference_mode = 'array';
y = my_estimate(d);
d.reference_mode = 'object';
Now, to address the questions that you brought up:
> What does "find" return? How do I write a matrix library
> if I don't know where the subscripts start? How do I refer to the leading
> element of a string? In fact, is it the "first" element, or the
> "zeroth" element?
With a signal object, the questions concerning the matrix-library and
strings are irrevelant --- they don't apply. As for the "find" function:
it should be overloaded to return a value that matches whatever the
subscript assign does for the object. If the user really wants find to
return values based directly on the data, they can use one of the above
methods to make sure the right data gets passed to the find function.
I have many other ideas for what a signal object could do, but I'll stop
here to keep the discussion more focused.
Thanks for listening,
Jordan
Clay S. Turner
Bob Cain wrote:
>
> robert bristow-johnson wrote:
> >
> > In a later post, I will present (again, since I did this a year ago) a
> > perfectly backward compatible solution that, for some odd reason, MathWorks
> > apparently refuses to consider or to debate.
>
> Ah, the old zero/one origin indexing argument. I look forward to your
> proposal. The last time this discussion went around that I was in
> attendance the compatibility question nailed the coffin shut on the
> argument and there wasn't a whole lot of argument even presented for the
> wisdom of the original decision.
>
> As an APL user for more than 30 years I am very annoyed by the 1-origin
> only architecture of Matlab but APL was designed from the ground up to
> deal with dual origins so that function authors knew they had to be
> aware that their functions could be called from either context and that
> those considerations extended to the data itself.
Bob,
In APL, a new library function just calls quad IO to get the workspace
wide index origin and saves it. Then sets it to what it needs to run its
algo, and then resets it to the old value when done. I 1st used APL
back in 1972! - a really cool language and I learned to do this then.
Grant would like APL since it allows one to write very opaque code ;-)
But seriously, I think R-B-J has a viable soln to the indexing problem.
Clay
Jeffery J. Leader
On Sat, 15 Dec 2001 08:39:35 -0500, John D'Errico <der...@flare.net>
wrote:
>Its funny, but one of the reasons I remember APL could
>be frustrating to use was finding bugs from its allowance
>of non-fixed based indexing.
I liked the way APL handled it but then I liked APL all the way
around. One of the first things that attracted me to MATLAB was its
similarity to APL. I wish I had the time to invest in laerning J, the
'new' APL.
Having the ability to zero-index would be great. I get this question
all the time when I use MATLAB in a course and in my work I run into
this problem from time to time myself. I'd like to see the possibility
of zero-indexing.
How bad would it be to make it a new type for the nonce (shades of
APL's "NONCE ERROR")? There are so many different data types in MATLAB
nowadays --Viswanath hits on this in his recent review of Higham and
Higham--that a new type, the zero-indexed array, could be introduced
as a separate type with concersion facilities. Structures, function
handles, and zero-based arrays won't work in MATLAB 4.0 or earlier.
Merge the two types of arrays in the distant future when noone cares
about backward compatibility with MATLAB 2.0 any more. In any event,
many interesting ideas have been proposed--I hope the MathWorks can do
something about this.
(After we get back flops, at least in the Student Version.)
Sturla Molden
Jacobsen) wrote:
>the context of attempting to be a generalized tool. As a DSP and
>communications person, I -really-, _really_, *really* don't care why
>MATLAB was implemented with one-based indexing.
You should care. This is a long, posting, if you read it from the
start I will shortly explain how to use zero based indexing in Matlab
at the end.
The reason why DSP folks use 0-based indexing is that the C or assemby
language is used to program DSPs. Here 0-based indexing is natural
becauseit imples the following:
*(array + offset) == array[offset]
when array is a pointer to the first element, &array[0]. This is great
for programming hardware (which implies direct manipulation of
memory adresses) but no so great for numerical math. In linear
algebra, 1-based indexing is natural because it simplifies the
algorithms. Matlab uses 1-based indexing for two reasons. It is common
among mathematicans, and Fortran uses the same. Matlab was originally
written in Fortran to give a simple interface to the EISPACK and BLAS
routines.
What is the solution? In C++, the [] operator can be overloaded for
any class except the native datatypes such as double and int. If a C++
programmer needs an 1-based array, the solution is to wrap the array
in a class and overload the [] operator. An other solution, inspired
by the book "Numerical Receips in C", is to use
*(array + offset) = *( (array-base)+(offset+base))
= (array-base)[offset+base]
which actually invokes undefined behaviour and should not be used.
Now for the solution to the indexing problem in Matlab:
Base 1 indexing is already implented in Matlab. Yes it is, and here is
how you do it:
Like C++, Matlab implements classes and objects of classes.
But in stead of overloading the () operator for a class, you can
overload the behaviour of the indexing variable (actually the indexing
object). If a member function "subsindex" is defined for a class, this
function is called when an object of the class is used to subscript an
array. The return values from "subsindex" is used to subscript the
array as if it was zero-based, i.e
X(A) calles X( subsindex(A)+1 )
when A is an object of an user defined class. And that is all there
is to it! In other words, all you need to do is to use an user
defined class for your subscripting instead of using the elementary
types "double", "int32" or whatever. Although subsindex(A) default to
zero based indexing, it will of course allow you to select any base.
To make things simple, you can let the constructor of the indexing
object set the base.
So what are you actually complaining about?
The User Manual perhaps?
Sturla Molden
Eric Jacobsen
wrote:
>Its funny, but one of the reasons I remember APL could
Being one of the folks on the DSP side that sorely needs zero- or
variable based indexing, I wholeheartedly agree with you. Clearly the
tool serves a lot of people well with 1-based indexing, and even us
DSP folks have a ton of legacy code developed under the 1-based
indexing rules. It would be a very bad move to abandon what is
apparently the bulk of the customer base in order to accomodate the
needs of a portion of the market. I think any reasonable developer
would recognize that the best solution would broaden the customer
base, not shrink it.
robert bristow-johnson
>
> I know it has been brought up before but how about creating a new discrete
> signal object? I haven't seen a definitive argument yet for why this
> wouldn't work. It wouldn't have to break any older code (see below); it
> would only require overloading many of the builtin objects.
>
i am no MATLAB expert at all and have never tried to code with or use
MATLAB OOP. anyway, could this new object or class be defined so that
normal old vanilla MATLAB operators like + and - and * and .*, etc.
could be used?
this doesn't look like it:
> d.reference_mode = 'array';
> y = my_estimate(d);
> d.reference_mode = 'object';
if i can't do regular MATLAB programming (with just a couple of extra
calls to change the base or origin of an array from 1) with this
class, then MATLAB still fails to deliver on the promises: "familiar
mathematical notation" and "just as
they are written mathematically".
Lars Gregersen did make a stab at creating such a class and sent me
code, but (and i'm no expert) it appeared to both of us that the
syntax in using such a class would look more like LISP than MATLAB. i
want the syntax to be mostly unchanged, just extended so that i can
create/define arrays (or "matrices" if that's the word you want) that
can have non-positive indices.
> Thanks for listening,
yer welcome. and same for me.
i will apologize a bit for my previous tone, but, at the time i was
convinced that i (and "we" - i'm not alone) were not being listened to
by anyone that really mattered about this and i felt that i may as
well vent my spleen.
> Jordan
r b-j
robert bristow-johnson
> Its funny, but one of the reasons I remember APL could
> be frustrating to use was finding bugs from its allowance
> of non-fixed based indexing.
i wouldn't know (since i never used APL), but for me when i created C
arrays that were not 0-based (using an offset pointer as a sorta
pseudonym to the array), it was clear to any other functions using
such an array that they couldn't do anything with that array name
except access its elements, and the range of indices was explicitly
defined.
> Some of us actually like 1 based indexing. A lot of us even.
and in many cases, that is the most appropriate notation since math
(linear algebra) texts and lit define matrices to have (1,1) in the
upper left corner. when dealing with those kind of matrices/arrays,
*I* would want to have 1-based indexing. it still does not speak to
the need to extend MATLAB so that other bases can be covered to be
consistent with other mathematical/engineering fields that may have
arrays that are not 1-based.
> So TMW, if you do decide to fix their problems, please do
> it so it does not blow the rest of us out of the water.
i think, John, that you can be assured that Cleve & Company won't let
that happen (the fear i have is they will use that as a false pretext
to do nothing). also, i want to repeat, for the record, that *I*
don't want that to happen. as Eric Jacobsen said, we DSPers *also*
have legacy MATLAB code (where we likely spent hours fudging indices
by 1 to get the damn thing to work) that we don't want to break
either.
PLEASE LISTEN: (as Matthew Donadio said) *none* of us want to "break
backward compatibility", we just want "an extension to have the
ability to specify the starting base of our arrays." i'm gratified
that other frustrated comp.dspers are piping up about this. i still
find it amazing that when Tom Krauss brought this to TMW's attention
when the Signal Processing Toolbox was being developed, that they
lacked the insight or DSP experience to understand how important this
is in the context of MATLAB's promise to code formulae with "familiar
mathematical notation" and "just as they are written mathematically".
that fundamental MATLAB promise is not delivered in the context of
DSP, and what makes that so much worse, is that i believe the largest
application market of MATLAB *is* DSP. it's sadly ironic.
there is no reason in the world that this extension cannot be done,
and if an idiot like me can see exactly how it can be done, i cannot
see how the priests at TMW can't figger it out. especially when i
spell it out. i invite you or anyone else on c.s-s.m (or comp.dsp,
for that matter) to examine that and point out a flaw in the argument,
but i feel pretty safe for the same reason i feel pretty safe that
adding or subtracting 0 to an index will not change it.
> John D'Errico
>
> --
Eric Jacobsen
(Sturla Molden) wrote:
>On Sat, 15 Dec 2001 07:26:17 GMT, eric.j...@ieee.org (Eric
>Jacobsen) wrote:
>
>>the context of attempting to be a generalized tool. As a DSP and
>>communications person, I -really-, _really_, *really* don't care why
>>MATLAB was implemented with one-based indexing.
>
>You should care.
Why? Do you care whether your computer uses a Wallace-Tree multiplier
algorithm? Do you care whether your cell phone uses a synchronous
scrambler or not? Do you care whether your car uses a table based or
rule based ignition firing strategy? Do you care whether the
electricity provided at your wall socket was produced from a direct
drive or geared generator?
Most folks don't. Most folks just care that their computers produce
accurate results, their cell phone calls go through with decent
quality, and their car starts when they turn the key.
I care that MATLAB is able to make me productive in getting useful
simulation results. When I write a line of MATLAB code, I really
*really* don't care how they get the result, just that the result is
computed quickly and the results are correct for the documented
purpose of the operation.
>This is a long, posting, if you read it from the
>start I will shortly explain how to use zero based indexing in Matlab
>at the end.
>
>The reason why DSP folks use 0-based indexing is that the C or assemby
>language is used to program DSPs.
You have cause and effect backwards. The reasons we want zero- or
variable- based indexing is because algorithms written with standard
mathematical notation for DSP and communications seldom start indices
at 1, and this is largely because the indices will often have physical
meaning and significance. Some easy examples are the indices in the
Discrete Fourier Transform, which indicate the number of cycles per
aperture correlated to each output bin (so index zero is DC), and the
lag in a correlator, where index zero indicates zero delay. The
disconnect between the physical significance of the indices and how
MATLAB code has to be written causes an unbelievable amount of
frustration in both coding, debugging, and interpretation.
> Here 0-based indexing is natural
>becauseit imples the following:
>
> *(array + offset) == array[offset]
>
>when array is a pointer to the first element, &array[0]. This is great
>for programming hardware (which implies direct manipulation of
>memory adresses) but no so great for numerical math.
In some applications, but in DSP it is absolutely horrible for
discrete mathematics. See the above simple two examples. There are
thousands of others, and if you can understand that, then perhaps you
will understand the source of our complaint.
Since most folks use technical papers or notes written in standard
mathematical notation to capture analysis and often results of
algorithm developments, and many tools (e.g., MathCAD, SPW, C,
SystemView, etc., etc.) allow zero or variable based indexing, and, as
you point out, many software implementations (as well as hardware) are
developed consistent with the mathematical notation, simulations in
other tools, and the underlying physical meaning of the indices, in
that context MATLAB is the deviating exception. So when those of us
who work in the above context, which is essentially the DSP and
communications industries, et al, try to simulate systems in MATLAB we
are always confronted with this forced disconnect between the
analysis, work done in other tools consistent with the analysis, and
implementations done consistent with the analysis, other tools, and
the physical meanings of the underlying indices. Do you begin to see
the problem?
> In linear
>algebra, 1-based indexing is natural because it simplifies the
>algorithms.
Absolutely. Believe me, we get this. Many of us just don't see that
as an excuse to not be able to provide a more generalized tool. Other
folks do, and some of us who like a lot of the other features of
MATLAB are just trying to not be forced to go use those other tools,
although that seems to be what TMW may prefer.
> Matlab uses 1-based indexing for two reasons. It is common
>among mathematicans,
You may want to correct that to "a subset of mathematicians". You
shouldn't have to look very far at all to realize that folks dealing
with remote sensing, biological metrics, optics, communications, etc.,
etc., etc., deal with physical quantities that often wind up being
indices into arrays. Does it not make sense that a tool that forces a
disconnect between the analysis, the physical significance, and a
straightforward implementation is less useful than one that doesn't?
> and Fortran uses the same.
...which is a great comfort to both people still using FORTRAN.
> Matlab was originally
>written in Fortran to give a simple interface to the EISPACK and BLAS
>routines.
Again, most people care more about what the tool can do for them than
how it is implemented or why.
>What is the solution?
...discussion of a reasonable start for a solution that has been
discussed before...
I think many people, perhaps many within TMW, have the same lack of
understanding of the point of view of many within the DSP community
toward using their tool.
Cleve Moler
from robert bristow-johnson <rob...@wavemechanics.com>
Here are a few sentences from Robert's posting that relate to
our concern for backwards compatability.
>Now just as there are dimension compatibility rules that exist now for
>MATLAB operations, there would be a few natural rules that would be added so
>that "rebased" MATLAB arrays could have operations applied to them in a
>sensible way.
...
>The proposed system would, of course, continue this constraint and add a new
>constraint in that index offsets for each dimension (the offset[] vector)
>would have to be equal for two arrays to be added. The resulting array
>would have the same shape and offset[] vector as the input arrays.
...
>MATRIX DIVISION ('/' and '\'):
>
>I have to think about that a little, but I'm pretty sure a backward
>compatible extension to the operations can be figgered out. If not, it
>would be an illegal operation unless the bases were 1.
...
>I think that this is easy enough to define. The only hard part is to
>identify all MATLAB functions that search through an array and modify them
>to start and end at indices that might be different than 1 and size[dim] as
>are the search bounds today. It would instead search from 1-offset[dim]
>(the base) to size[dim]-offset[dim] which would default to the current
>operation if the offset equals zero.
...
>FOR ALL OTHER MATLAB OPERATIONS, until a reasonable extended definition for
>non 1-based arrays is thunk up, MATLAB could either bomb out with an illegal
>operation error if the base is not 1 or could, perhaps, ignore the base.
>Either way it's still backwards compatible.
...
> ... I might also suggest
>that "straw men" counter examples to backwards compatibility requirement be
>avoided in your response and that you folks stick closely to the strict
>definition of "backwards compatibility". That strict definition means that
>any code previously written in MATLAB will run with this extension exactly
>as it had before the extension (except a minute amount slower due to the
>offset addition).
I agree that it would be possible to add zero-based indexing to MATLAB,
using either new notation or an object that overloaded all of our
existing indexing notation. It could be backwards compatible in the
sense that old code that didn't know about or use the new stuff would still
work.
But here is the key point: none of our existing code would work with
the new object. You couldn't plot it; you couldn't print it; you
certainly couldn't do any matrix operations with it. Yes, over time,
everything could be rewritten to handle the extension, but that
is what we want to avoid. It would be like AM and FM radio -- two
systems living in the same box, but with separate and independent
underlying technology.
-- Cleve Moler
mo...@mathworks.com
Eric Jacobsen
wrote:
>I agree that it would be possible to add zero-based indexing to MATLAB,
>using either new notation or an object that overloaded all of our
>existing indexing notation. It could be backwards compatible in the
>sense that old code that didn't know about or use the new stuff would still
>work.
>
>But here is the key point: none of our existing code would work with
>the new object. You couldn't plot it; you couldn't print it; you
>certainly couldn't do any matrix operations with it. Yes, over time,
>everything could be rewritten to handle the extension, but that
>is what we want to avoid. It would be like AM and FM radio -- two
>systems living in the same box, but with separate and independent
>underlying technology.
>
> -- Cleve Moler
> mo...@mathworks.com
I think your last paragraph is a pretty good synopsis of what I have
suspected to be the case for some time. The bottom line is that you
don't want to do the change because it would entail a lot of effort.
This is understandable, but I wish representatives of your company
hadn't been telling me for years that a fix was imminent, because I
could have saved an awful lot of time dealing with this issue by just
moving on to other toolsets. Instead, I've put up with this highly
frustrating problem in the hope, based on what I was told, that I'd
soon be able to not only use the parts of MATLAB that I already like,
but that this problem would be fixed.
Now that you've indicated that a fix is probably never going to
happen, it will be much easier for me to plan migrations to other
tools, and avoid starting new projects in MATLAB. Thanks for this,
because ultimately it will save me and the people I work with a ton of
time.
Jerry Avins
>
...
>
> I agree that it would be possible to add zero-based indexing to MATLAB,
> using either new notation or an object that overloaded all of our
> existing indexing notation. It could be backwards compatible in the
> sense that old code that didn't know about or use the new stuff would still
> work.
>
> But here is the key point: none of our existing code would work with
> the new object. You couldn't plot it; you couldn't print it; you
> certainly couldn't do any matrix operations with it. Yes, over time,
> everything could be rewritten to handle the extension, but that
> is what we want to avoid. It would be like AM and FM radio -- two
> systems living in the same box, but with separate and independent
> underlying technology.
>
> -- Cleve Moler
> mo...@mathworks.com
I don't know your code. (If you told me, you'd have to kill me!) So I go
out on a limb when disputing your point, but nobody can fire me.
It doesn't matter if your existing code would work with the new objects
you have in mind. Backward compatibility requires only that the _new_
print and plot and (...) work with _both_ new and old objects. That
seems self evident to me; what's the hitch?
Jerry
--
"I view the progress of science as ... the slow erosion of the
tendency to dichotomize." Barbara Smuts, U. Mich.
---------------------------------------------------------------------
Muzaffer Kal
I whole-heartedly support this. Because of this problem, I've been
using Octave http://www.octave.org for quite a while. It is more or
less a matlab clone and it's getting better all the time. As to other
paid tools, I am looking for suggestions on what can replace Matlab. I
already have and use Mathcad and like it a lot too.
Muzaffer Kal
http://www.dspia.com
DSP algorithm implementations for FPGA systems
Jordan Rosenthal
> Yes, over time,
> everything could be rewritten to handle the extension, but that
> is what we want to avoid. It would be like AM and FM radio -- two
> systems living in the same box, but with separate and independent
> underlying technology.
Isn't that what we have now as function handles replace inline functions?
Jordan
Bob Cain
robert bristow-johnson wrote:
>
> It be below.
>
[definition snipped]
My first blush is that I don't like it because, following good OOP
philosophy, it attaches the symantics to each array individually rather
than to the global nature of index related operations. This will force
me to pay way more attention to the issue than I would like. Not
knowing how operands (indices) will apply to an operator by just knowing
the local execution environment to me is truly obscure even though it
has become the modern way of thinking. I don't want to have to seek out
an array's definition to figure that out or have conditional code to
cover the possibilities.
I'm unable with the time at hand to assess whether the conditions of
backward compatibility are truly met by the proposal. I don't like the
appearance that to use old code I must use backwards compatible
_variables_.
To me the simplest solution is to provide a system variable which
defines the index origin, make it local to functions and initialize it
to 1 at every function call. All Matlab operators that take or return
indices would depend on that system variable. Also define a system
variable that is initialized at the function call to the value of the
callers origin which could be used to condition results that are
returned. Existing defined functions that take or return indicies would
behave as before and those of us that work in 0-origin would just need
to remember that. I don't think any existing code would break and I
could set the index origin to be whatever I want at the start of a
function I write. There is probably something obviously wrong with such
a simple minded approach which I don't see and I invite criticism.
Bob Cain
"Clay S. Turner" wrote:
>
> In APL, a new library function just calls quad IO to get the workspace
> wide index origin and saves it. Then sets it to what it needs to run its
> algo, and then resets it to the old value when done.
It's been a long time but didn't they just make quad IO (the system
variable that determines the current index origin) implicitly local to a
function so that calling a function that changed it had no effect on the
calling function?
> I 1st used APL
> back in 1972! - a really cool language and I learned to do this then.
> Grant would like APL since it allows one to write very opaque code ;-)
I got it in 1967. Nothing I ever learned had such a profound effect on
my productivity. That was the thing I hated most to lose when I left
IBM in '77. As far as opaque code that was always very equivocal. My
experience was that the simplicity of the syntax and the power of the
operators made it far easier for me to scope out what an APL program did
than an equivalent program written in any other language which was
inevitably an order of magnitude more verbose. You were looking at the
cake rather than the recipe.
robert bristow-johnson
(Cleve Moler) wrote:
> This is a followup to article <_CxS7.2384$BK....@nwrddc02.gnilink.net>,
> from robert bristow-johnson <rob...@wavemechanics.com>
>
> Here are a few sentences from Robert's posting that relate to
> our concern for backwards compatability.
i think that we agree on the strict definition of "backwards compatibility".
however, whether we do or not might shake out below:
>>Now just as there are dimension compatibility rules that exist now for
>>MATLAB operations, there would be a few natural rules that would be added so
>>that "rebased" MATLAB arrays could have operations applied to them in a
>>sensible way.
>
does not affect backwards compatibility.
> ...
>
>>The proposed system would, of course, continue this constraint and add a new
>>constraint in that index offsets for each dimension (the offset[] vector)
>>would have to be equal for two arrays to be added. The resulting array
>>would have the same shape and offset[] vector as the input arrays.
>
does not affect backwards compatibility.
> ...
>
>>MATRIX DIVISION ('/' and '\'):
>>
>>I have to think about that a little, but I'm pretty sure a backward
>>compatible extension to the operations can be figgered out. If not, it
>>would be an illegal operation unless the bases were 1.
even though i think we both agree that this needs to be worked on in
advance, and a sensible extension to the current definition that degenerates
to the current definition when the base = 1 in all dimensions, i concede
that, but it still does not affect backwards compatibility. it can be
figgered out a little bit later (like next week).
> ...
>
>>I think that this is easy enough to define. The only hard part is to
>>identify all MATLAB functions that search through an array and modify them
>>to start and end at indices that might be different than 1 and size[dim] as
>>are the search bounds today. It would instead search from 1-offset[dim]
>>(the base) to size[dim]-offset[dim] which would default to the current
>>operation if the offset equals zero.
>
i only mean core MATLAB functions that return indices (that oughta be a
finite number and i have to believe that you guys *must* know which of your
"built-in" functions return indices). code that users run in .m files would
still work without any modification. even if they are using arrays based on
something other than 1, find() would still return the correct indices.
> ...
>
>>FOR ALL OTHER MATLAB OPERATIONS, until a reasonable extended definition for
>>non 1-based arrays is thunk up, MATLAB could either bomb out with an illegal
>>operation error if the base is not 1 or could, perhaps, ignore the base.
>>Either way it's still backwards compatible.
>
do you you dispute that this is backwards compatible? it just means that
there may be MATLAB operations that may not make sense for arrays unless
they are 1-based (ya know, the regular old MATLAB matrices for which these
operations *do* make sense). why is that such a conern? even if a sensible
extension to the operation to make it work with non-1-based arrays is thunk
up in the future, that extension could be implemented in the future and
nobody is hurt.
> ...
>
>> ... I might also suggest
>>that "straw men" counter examples to backwards compatibility requirement be
>>avoided in your response and that you folks stick closely to the strict
>>definition of "backwards compatibility". That strict definition means that
>>any code previously written in MATLAB will run with this extension exactly
>>as it had before the extension (except a minute amount slower due to the
>>offset addition).
>
> I agree that it would be possible to add zero-based indexing to MATLAB,
it should be more general than just adding 0-based indexing. even though i
used causal FIR convolution and DFT of examples of the egregious error in
notation we must accept with MATLAB presently, if this extension is done, it
should be more general. we should be able to model acausal filters in
MATLAB.
> using either new notation
it wouldn't be worth as much if it required any significant new notation
save for functions (like the DFT) that would take advantage of the extended
indexing base.
> or an object that overloaded all of our existing indexing notation.
it overloads a few specific places where subscripts or subscript ranges are
used before accessing MATLAB variable data. only places where your code
makes a reference to the matrix shape is where the offset would be have to
be added. only core functions that return indices would have to be modifed
to subtract the offset before the index is returned.
> It could be backwards compatible in the sense that old code that didn't know
> about or use the new stuff would still work.
yes. isn't that the definition? it would be backward compatible in that
sense, ergo it wouldn't be blowing John D'Errico and "the rest of us out of
the water."
> But here is the key point: none of our existing code would work with
> the new object.
that seems to be the conclusion Lars Gregersen and i came to. that's why
this problem appears that it cannot be decently fixed using the existing
MATLAB OOP facility (overloading subsasgn() and subsref() ). this is why i
am convinced that the solution to this problem lies ONLY with this *small*,
backward compatible, change to the core structure of the MATLAB variable.
we are not proposing a new notation (save for the new "base()", and
"rebase()" core functions that wouldn't be seen in legacy .m file code) nor
an object written within the current MATLAB OOP facility. (those are straw
men, i believe.) we are proposing a small and backwards compatible
extension to the internal parameters of the MATLAB variable so that each
index can be *potentially* adjusted before data is accessed so that the
MATLAB user can *choose* to change the default base index from its default
of 1 to some other finite integer.
> You couldn't plot it;
sure you can. why not? the worst that happens is the plot(X) facility
write 1 to size() at the bottom because it ignores the base. it, and a few
other MATLAB core functions should be modified to plot the correct indices
when there is only one argument. still sounds quite doable and finite to
me.
> you couldn't print it;
again, why not?
> you certainly couldn't do any matrix operations with it.
again, i have never proposed creating a new MATLAB object in the context of
the existing MATLAB language. i am proposing a *small*, backward
compatible, change to the core structure of the MATLAB variable and some of
the core functions that return (or use) indices.
> Yes, over time, everything could be rewritten to handle the extension, but
> that is what we want to avoid.
EVERYTHING? surely you do not mean the millions of lines of MATLAB code out
there. there would be a *finite* number of changes to the MATLAB
application code and those places can be readily found because the *only*
changes would be to the application code where references are made to the
array shape of the matlab variable or *core* functions that return indices.
THAT IS FINITE.
> It would be like AM and FM radio -- two systems living in the same box, but
> with separate and independent underlying technology.
it's an apt comparison Cleve (but not entirely accurate). even if it was
accurate, does that imply that you'ld rather have MATLAB to stay in the "AM"
era? why??? "FM" is better than "AM"!! we don't wanna be stuck with "AM"
when for a small increase in price (the finite development effort that gets
amortized over the entire remaining life of MATLAB), you can get the higher
quality of "FM" and get that inperpetuity? think of all the man-hours
you'ld be saving!
now the reason that it is not entirely an accurate comparison is that the
vast, vast majority of the MATLAB application code would be shared between
these "two" technologies. (it's really just one technology that got a
backward compatible extension.) the code that would be changed has only a
finite number of locations. the changes would happen only at those
locations where the matrix shape (the numbers returned by the size()
functions) are referenced and MATLAB core functions that return indices. if
that is done, it's backward compatible but not yet particularly useful. to
make it useful, the MATLAB variables that are created as a consequence of
some of the core functions described in my previous post would have to take
on the base (or offset[] vector) of the MATLAB variables that were arguments
of the function. i well defined that for '+', '-', '.*', './', '.^',
elemfun(), and even '*' (matrix multiply). i forgot to mean transpose ('),
but that one would be an easy extension also. '/' and '\' will come soon
enough.
Cleve, this is doable. *very* doable. and will be quite useful and
appreciated by potentially a large number of people in the future (which is
why fixing this sooner increases it's value). it really is doable and your
apparent skepticism and resistance is curious (i think there were a few
straw men in your argument). what do you expect the future life of MATLAB
to be? at least 10 years? if so, it's still not too late to fix this.
please, let's keep the conversation going on this.
r b-j
Edwin Robert Tisdale
> I agree that it would be possible to add zero-based indexing to MATLAB,
> using either new notation or an object
> that overloaded all of our existing indexing notation.
> It could be backwards compatible in the sense that
> old code that didn't know about or use the new stuff would still work.
>
> But here is the key point:
> none of our existing code would work with the new object.
> You couldn't plot it; you couldn't print it;
> you certainly couldn't do any matrix operations with it.
> Yes, over time, everything could be rewritten to handle the extension
> but that is what we want to avoid. It would be like AM and FM radio --
> two systems living in the same box
> but with separate and independent underlying technology.
Nonsense!
Balderdash!
Poppycock!
The index base is irrelevant to a MATLAB matrix object.
If you derive a new type from matrix that supports zero-based indexing,
you can pass it to your existing software as a matrix
and it will all work as expected.
You don't need to change anything.
I have written both C and Fortran 77 routines that I call from MATLAB.
I use 0-based indexing in the C routines and
I use 1-based indexing in the Fortran 77 routines.
But I don't think that adding 0-based indexing is necessary.
In fact, MATLAB might be better off with one less indexing operator.
The whole purpose of supporting vector and matrix arithmetic
in a language like MATLAB is to eliminate loops over an indexed array.
Loops are inherently serial and introduce too many opportunities
for the programmer to make mistakes
which are very difficult to detect and debug.
If you read a lot of MATLAB code which implements DSP algorithms
and find a lot of loops over indexed arrays,
you can be pretty sure that the programmer
doesn't know what he or she is doing.
There are a few exceptions such as recursive definition of array elements
x(i+1) = b(i)*x(i) + a(i)
for example.
robert bristow-johnson
>
>
> robert bristow-johnson wrote:
>>
>> It be below.
>>
>
> [definition snipped]
>
> My first blush is that I don't like it because, following good OOP
> philosophy, it attaches the symantics to each array individually rather
> than to the global nature of index related operations.
no, i think i'm proposing an extension to "the global nature of index
related operations". that extension allows arrays to begin with and end
with any index bounds you like (providing you have enough memory). so
rather than just have the end bounds attached to each array (and have the
start bounds hardwired to 1) as it is presently the case, both the start
bounds and end bounds (defined indirectly by the offset[] and size[] fields
of that hypothetical MATLAB variable structure) would have to be attached to
each array. that's the only way you can have some arrays that start with 1,
other arrays that start with 0, and still other arrays that start with some
other possibly non-positive integer.
> This will force me to pay way more attention to the issue than I would like.
no. you don't have to pay attention to it at all (because it will be
backwards compatible) *unless* you might want to take advantage of this new
base redefinition feature. if you don't like it, fine. don't use it. how
does that put you out?
> Not
> knowing how operands (indices) will apply to an operator by just knowing
> the local execution environment to me is truly obscure even though it
> has become the modern way of thinking.
sorry, Bob. i can't decode this. i have absolutely no idea what you mean.
can you elaborate?
> I don't want to have to seek out
> an array's definition to figure that out or have conditional code to
> cover the possibilities.
if you don't choose to use this, you do not have to seek out the array's
definition to figure that out or have conditional code to cover the
possibilities". is your worry that someone else will pass to one of your
routines a non-1-based array and your routine won't know it and won't check?
if that is your worry, just stick with 1-based arrays and only warrant your
routine for proper operation if people supply you with the default 1-based
arrays for function arguments.
> I'm unable with the time at hand to assess whether the conditions of
> backward compatibility are truly met by the proposal. I don't like the
> appearance that to use old code I must use backwards compatible
> _variables_.
but your old code would only generate 1-based variables. how are you
deprived of anything if your old code that was meant to work with 1-based
arrays still only works right with 1-based arrays? how does that make your
life harder?
> To me the simplest solution is to provide a system variable which
> defines the index origin, make it local to functions and initialize it
> to 1 at every function call.
making a global system index origin sounds like a bad idea to me. just
because i have some 0-based or -128 based arrays for my DSP operations, i
still want to be able to use all existing MATLAB features that i have paid
for, and if some MATLAB function only makes sense for a 1-based array, i
should be able to use it with old 1-based arrays. both 1-based arrays and
non-1-based arrays should be allowed to coexist in the same MATLAB program,
and the only way to do that is have the array origins or base attribute
attached to each one.
now, it can be defined that all core MATLAB functions simply ignore the base
(assuming them to be 1-based), do their operation oblivious to the base, and
then always return 1-based arrays for results. that would be backwards
compatible, but isn't the only way to make it backwards compatible. for
some MATLAB core functions, if non-1-based arrays are passed to them as
arguments, they might return arrays that are not 1-based but would return
arrays that take on the base origins based on their input arrays. however
the way these functions determine the base of returned arrays must
degenerate to returning 1-based arrays when 1-based arrays are passed to
them.
> All Matlab operators that take or return
> indices would depend on that system variable.
yeah, but you're not offering much advantage if you're insisting that all
MATLAB variables be arrays with the same indexing base that is defined by a
global system parameter.
> Also define a system
> variable that is initialized at the function call to the value of the
> callers origin which could be used to condition results that are
> returned.
no, what i proposed is far more flexible (and easier to insure backwards
compatibility, i think). as would be the case for matrix multiplication,
you could very well be making a function call with two arrays for arguments,
that *don't* have the same shape, nor (with this extension) have the same
indexing base. and the array returned by the function call might not be the
same shape or base as the arguments but would depend on the shapes and base
of them. you're idea precludes that and that seems to be a drawback to me.
> Existing defined functions that take or return indicies would
> behave as before and those of us that work in 0-origin would just need
> to remember that.
no. if i call [val, indx] = max(abs(X)) on a complex array X (looking for
peaks in a spectrum), i want the max index returned (indx) to be in terms of
its own base. that's the whole point in making this extension.
> I don't think any existing code would break and I
> could set the index origin to be whatever I want at the start of a
> function I write. There is probably something obviously wrong with such
> a simple minded approach which I don't see and I invite criticism.
don't mean to be critical, but i am not sure you understand the basics of my
proposal (i think that Eric Jacobson and Jerry Avins understand it
perfectly). i tried to spell out the basics (or foundations) of it in that
post, although i admitted that i didn't get all of the details.
essentially, i haven't identified all of the MATLAB core functions that
would have to be changed because i actually don't know them all that return
indices or some result based on the numerical values of the indices.
however, that set of functions is finite and it shouldn't take long to
identify them all (especially for a MathWorks insider).
r b-j
robert bristow-johnson
(Eric Jacobsen) wrote:
> On Sat, 15 Dec 2001 17:51:24 GMT, stu...@slettdette.molden.net.invalid
> (Sturla Molden) wrote:
>
>>
>>The reason why DSP folks use 0-based indexing is that the C or assemby
>>language is used to program DSPs.
>
> You have cause and effect backwards. ...
Sturla, i dunno yet whether i fully agree with Eric here or not (i think i
do, though) but i would point out that i never, ever appealed to C's
inherent 0-based indexing as the reason for making this extension. rather
than making my MATLAB code look more like it would if it were C code, what i
want is for my MATLAB code to look more like the equations in Oppenheim and
Schafer or any other DSP text or 99% of the other published literature (i
think i remember once seeing a paper that tried to be consistent to MATLAB's
conventions and it looked awful - almost as bad as my MATLAB code because
all of that fiddling with adding and subtracting 1 to indices).
screw C or C++. we want MATLAB to make good on its promise to express code
using "familiar mathematical notation" and "just as they are written
mathematically". for DSP, it clearly does not make good on that promise
presently. it forces us to change how well-established fundamental
expressions are written to another expression which is functionally
different because the indices (or subscripts) are off by 1. and, because it
cannot do negative indices, i cannot compactly model an acausal FIR filter.
r b-j
Abe Kohen
"robert bristow-johnson" <rob...@wavemechanics.com> wrote in message
news:g6US7.2422$Ga...@nwrddc01.gnilink.net...
As someone who programmed more in C/C++ than Fortran, I too would like to
see flexible indexing. At the same time, I must admit I discovered a bug in
one of my matlab programs when the index unintentionally took on the value
of zero, something I would have had probably overlooked (or spent enormous
time chasing) with zero based indexing.
With Matlab looking like a tool developed for Fortran programmers on VAX/VMS
none of this is surprising. Not even the lack of a consistent BNF grammar
(as VAX DCL did not appear to have one either.) The adoption of Java (with
all its memory leak and other problems) in R12 is all the more
mind-boggling.
It would be nice, though, if the developers of MatLab, would pay more
attention to end users requests and complaints. I will never forget
Professor Irving Shames at Buffalo who paid his students two-bits (25 cents)
for every error they found in his book. (I made a lot of quarters that way.)
Mathworks does not have to pay us, but it should have the courtesy to
acknowledge bugs and not hide them in a search-based bug database, and the
courtesy to offer realistic time estimates for reasonable enhancement
requests.
My two-bits,
Abe
Jordan Rosenthal
> If you read a lot of MATLAB code which implements DSP algorithms
> and find a lot of loops over indexed arrays,
> you can be pretty sure that the programmer
> doesn't know what he or she is doing.
Not true. It is very hard to code adaptive processing algorithms without
loops, unless one wants to use a tremendous amount of memory.
Jordan
Matthew C Roberts
>
>It doesn't matter if your existing code would work with the new objects
>you have in mind. Backward compatibility requires only that the _new_
>print and plot and (...) work with _both_ new and old objects. That
>seems self evident to me; what's the hitch?
>
I think Cleve's point was that, if implemented, they must then _write_
new plot, print, etc., routines, which would be very resource
intensive.
$0.02
matt.
Matthew C Roberts
Assistant Professor
Agricutural, Environmental, and Development Economics
The Ohio State University
email: ROBERTS dot 628 at OSU dot EDU
Bob Cain
robert bristow-johnson wrote:
> that's the only way you can have some arrays that start with 1,
> other arrays that start with 0, and still other arrays that start with some
> other possibly non-positive integer.
That is exactly what I would wish to avoid. I don't want the index
origin to be a property of the array much less each dimension of the
array. The program should work the same on any array that it is given.
I want to define how the program works rather than how the data works
and I want the ability to have the program see things in the origin that
is natural to the algorithm the program implements.
>
> > This will force me to pay way more attention to the issue than I would like.
>
> no. you don't have to pay attention to it at all (because it will be
> backwards compatible) *unless* you might want to take advantage of this new
> base redefinition feature. if you don't like it, fine. don't use it. how
> does that put you out?
I don't want my program to do the wrong thing or blow up if I don't
properly handle all the possible dimension origins an array that it is
given can have.
>
> > Not
> > knowing how operands (indices) will apply to an operator by just knowing
> > the local execution environment to me is truly obscure even though it
> > has become the modern way of thinking.
>
> sorry, Bob. i can't decode this. i have absolutely no idea what you mean.
> can you elaborate?
Does it make any more sense in the context of my above comments? I want
index origin to be a property that is attached to the current
"processor" state rather than to a datum.
> if that is your worry, just stick with 1-based arrays and only warrant your
> routine for proper operation if people supply you with the default 1-based
> arrays for function arguments.
I'd prefer not to.
>
> > To me the simplest solution is to provide a system variable which
> > defines the index origin, make it local to functions and initialize it
> > to 1 at every function call.
>
> making a global system index origin sounds like a bad idea to me.
For me it well accomplishes the limited goal of being able to write my
code using an origin appropriate to the algorithm. The origin that is
used should be a property of the algorithm rather than the data it
operates on.
>
> don't mean to be critical, but i am not sure you understand the basics of my
> proposal (i think that Eric Jacobson and Jerry Avins understand it
> perfectly).
I believe I do. I just don't care for it. I find it too elaborate and
susceptible to side effects. My proposal, unless there is a fatal hole
in it, is much simpler, less pervasive and still accomplishes the goal
of being able to use an index origin that is appropriate to the problem
at hand.
Lars Gregersen
wrote:
>This is a followup to article <_CxS7.2384$BK....@nwrddc02.gnilink.net>,
>from robert bristow-johnson <rob...@wavemechanics.com>
[snip]
>> ... I might also suggest
>>that "straw men" counter examples to backwards compatibility requirement be
>>avoided in your response and that you folks stick closely to the strict
>>definition of "backwards compatibility". That strict definition means that
>>any code previously written in MATLAB will run with this extension exactly
>>as it had before the extension (except a minute amount slower due to the
>>offset addition).
>
>I agree that it would be possible to add zero-based indexing to MATLAB,
>using either new notation or an object that overloaded all of our
>existing indexing notation. It could be backwards compatible in the
>sense that old code that didn't know about or use the new stuff would still
>work.
This is easily done (I suggested this in February, 2000). Simply add a
new syntax for indexes (I.e. this proposed change does not affect the
matrix at all)
E.g.
A = linspace(1,100);
% The first element (1-based):
A(1)
% The first element (0-based):
A[0]
% The last element (1-based):
A(end)
A(length(A))
% The last element (0-based)
A[length(A)-1]
Let's say we want to handle a case like
v = randn(10,1);
[y,i] = max(abs(v));
and that max was defined by:
---
function [y,idx]=max(v)
y = v(1);
idx = 1;
len = length(v);
for i=2:len
if v(i)>y
y=v(i);
idx = i;
end
end
---
This code would still work with the new syntax, but the index returned
from max would always be 1-based. Since there is no connection between
the counter variable i and the input vector v you can never convince
max into returning an index based on the type of v.
If furthermore abs was defined like this (for real vectors only)
---
function a=abs(v)
a = zeros(length(v),1);
for i=1:length(v)
if v(i)>=0
a(i) = v(i);
else
a(i) = -v(i);
end
end
---
there is no connection between the type of a and v. I.e. even if a
special object v is created that can have a different base than 1 you
will loose this capability for the returned vector a.
To summarise
[y,i] = max(abs(v))
can not return an index that is based on the type of v. No matter of
how many global and local variables you are allowed to set you will
not be able to make max return an index that is other than 1-based
(not without breaking the code above).
If anyone can prove me wrong I'll look carefully at the reply. Please
show a full example of your code.
>But here is the key point: none of our existing code would work with
>the new object. You couldn't plot it; you couldn't print it; you
>certainly couldn't do any matrix operations with it. Yes, over time,
>everything could be rewritten to handle the extension, but that
>is what we want to avoid. It would be like AM and FM radio -- two
>systems living in the same box, but with separate and independent
>underlying technology.
The solution as I see it is that TMW add indexing that is not 1-based
(e.g. using a special syntax like v[i]). It must then be up to the
programmers to handle that indexing scheme in their own code (like
they have to do in C).
Lars
M.Sc. Chem Engng. Lars Gregersen <l...@2-control.com>
2-control ApS
Windows Toolbox for Matlab version 1.0: www.2-control.com/wt/
Lars Gregersen
<rob...@wavemechanics.com> wrote:
>In article <3C1BCB54...@znet.com> , Bob Cain <arc...@znet.com> wrote:
>
>>
>>
>> robert bristow-johnson wrote:
[snip]
>
>> Existing defined functions that take or return indicies would
>> behave as before and those of us that work in 0-origin would just need
>> to remember that.
>
>no. if i call [val, indx] = max(abs(X)) on a complex array X (looking for
>peaks in a spectrum), i want the max index returned (indx) to be in terms of
>its own base. that's the whole point in making this extension.
See my other post about why this can never be.
You simply have to do that part of the job yourself.
Of course, TMW could help make that easier. Something like:
% max0 will return 0-based indexes.
[val,indx] = max0(abs(X));
% subtracting off-sets inline
[val,indx--] = max(abs(X));
>> I don't think any existing code would break and I
>> could set the index origin to be whatever I want at the start of a
>> function I write. There is probably something obviously wrong with such
>> a simple minded approach which I don't see and I invite criticism.
>
>don't mean to be critical, but i am not sure you understand the basics of my
>proposal (i think that Eric Jacobson and Jerry Avins understand it
>perfectly). i tried to spell out the basics (or foundations) of it in that
>post, although i admitted that i didn't get all of the details.
>essentially, i haven't identified all of the MATLAB core functions that
>would have to be changed because i actually don't know them all that return
>indices or some result based on the numerical values of the indices.
>however, that set of functions is finite and it shouldn't take long to
>identify them all (especially for a MathWorks insider).
Until all these functions have been found, I hope that TMW makes its
illegal (giving an error) to use any 0-based objects with old code
before it has been checked!
Jerry Avins
I suspect you are right, but I gave him the benefit of any doubt. If you
are indeed right, he's been saying "we can't" when he means "we don't
choose to". It's his company, and his decision to make. When he deigns
to tell the world the reason for that decision, he should be truthful.
I imagine this scenario: He first believed that he couldn't. Now that
he's been shown that he could, he thinks "That's hard. Maybe there's an
easier way. The time isn't ripe." So we hear yesterday's words attached
to today's reality, and it seems disingenuous. Given time, that may
shake out. In the meantime, we know (as Eric J. wrote) that it's really
"we don't choose to, at least for now".
robert bristow-johnson
>
> I think Cleve's point was that, if implemented, they must then _write_
> new plot, print, etc., routines, which would be very resource
> intensive.
that may very well be Cleve's point, but it is not entirely correct.
the use of the word "must" is an exageration. if the extension that i
am agitating for is implemented without revisiting the code that
implements plot() or print(), they would work fine with matrices that
are 1-based. there is no reason that they would break. if they are
core functions that are not written in MATLAB code (.m file), they
would even likely work with a non-1-based array, but they wouldn't
know that the base index differs from 1 and, say in plot(X), the
indices of X printed at the bottom would start with 1 instead of the
correct base index. important core functions like plot() *should* be
modified to be aware of other possible bases.
but it is not the case that *all* MATLAB functions would need to be
modified. to be strictly backwards compatible (old code continues to
run okay) almost no utilities would need to be rewritten. however it
would be less useful to those of us who would want to use non-1-based
arrays, so certainly core routine like plot() should be modified. but
that number of routines to adapt to this are finite, and the change
that would have to me made to them is small.
ya know, it ain't just the DSPers who make use of non-positive
subscripts in sequences of numbers or whatever. most power series
have a zero-power term that that should go with a(0). hell we may
even want a finite power series that has a mixture of negative and
non-negative powers. being able to represent that in MATLAB with an
array where the subscripts *are* the power would be a far more elegant
representation than what we are currently forced to use now in MATLAB.
> $0.02
here's mine: this fix will only make MATLAB better and (providing it
is perfectly backward compatible) will certainly be appreciated by
many MATLAB users in the future. the future is a long time and it
pays off to invest in it. it's an effort like learning C or C++ for
the first time when all one knows is Fortran and some assembly. i've
never regretted that effort and i haven't coded in Fortran since 1981.
r b-j
Grant Griffin
>
...
> i know that there's Octave and Python (and MathCad and, hell, we can always
> code it in C or C++)
Sell it, brother!!!
And don't forget to tell 'em about Scilab! (See
http://www-rocq.inria.fr/scilab/.) For folks who've bought into the
MATLAB method of DSP system design and simulation, I think Scilab--with
it's large library of DSP functions--might be the easiest thing to
switch over to. (But that said, I'll stick to Python, thank you.)
> but, like Micro$hit, MATLAB has become the defacto
> standard in modeling signal processing systems (as well as other systems).
Now don't say "de facto" too loud or TMW will get a swelled head. And
first thing you know, they'll start charging thousands for their
products--and for each and every new little toykit they come up with.
And pretty soon, they'll even start ignorin' the needs of their
custmomers <wink>.
But ya' know, r...as the Mac-usin', Motorola-DSP-programmin', Vermont
residin' guy that you are, I never much pictured you as the "de facto"
type. (In fact, I'm kindda disillusioned right now...help me out here
<sniffle>.)
As Thoreau said, "A man is rich in proportion to the number of things
which he can afford to let alone." So just think how rich you'd be if
you could afford to let MATLAB alone. (In fact, think how much _richer_
you'd be if you'd never shelled out for it in the first place. And
that's not even counting interest.)
Anyway, I wouldn't get too hung up on this whole nutty "de facto"
thing. I think that's really just imaginary anyway, because if there's
one thing we all can do our own favorite way using our own favorite
tools (unless some misguided employer _also_ buys into de-facto-ism...),
it's DSP system design and simulation. I've seen folks use lots of
different methods and tools--and they all work. For example, I have a
friend who does DSP system design using only MathCad. And I do mine
using a combination of things: Iowegian's tools, C, C++, Excel, and
Python. (I haven't used MATLAB and I haven't missed it. Then again, if
MATLAB were zero-based like C, C++ and Python...<wink>)
So I guess I wouldn't hesitate to try other methods and other tools. If
one-based indexing is the problem, I don't think trying to motivate The
MathWorks to change is the solution.
> the question is, does MathWorks plan to deal with their lead position in
> this particular market the same way that Micro$oft does or do they respond
> to their customer base and do their best, or at least what they can do to
> make their product the best it can be or at least as good as its promise?
Look, I don't want to bust anybody's bubble or anything, but let me just
observe here that the responsiveness of an outfit generally seems to be
inversely related to its size. So I guess the de-facto-ites of the
world are gonna have to get used to poor service <wink>. (I say this as
a Microsoft customer who is entirely comfortable with that.)
Of course, to turn that around, it follows that you're likely to get
better service from _small_ outfits. For example, since plumbing is
primarily a service business, my favorite plumber is self-employed: the
larger outfits can run magazine ads, send out direct mail, and even have
salesmen call me at work to ask me if I'd like to buy MATLAB (oops...I
mean "plumbing"), but my plumber has nothing to offer except great
service at a reasonable price ("reasonable", at least in the scale of
plumbing...)
Relative to software, I guess if you take this concept to its logical
conclusion, you would conclude that you might get the best service of
all on software that's free.
you-can-lead-a-horse-to-water-but-you-can't-teach-an-old-dog
-new-ways-to-skin-a-cat-<wink>-ly y'rs,
=g2
p.s. Sorry to get involved in this thread after I promised not to.
(But you all saw through that anyway <wink>.)
--
_________________________________________________________________________
Grant R. Griffin
g...@dspguru.com
Publisher of dspGuru
http://www.dspguru.com
Iowegian International Corporation
http://www.iowegian.com
robert bristow-johnson
> robert bristow-johnson wrote:
>
> > that's the only way you can have some arrays that start with 1,
> > other arrays that start with 0, and still other arrays that start with some
> > other possibly non-positive integer.
>
> That is exactly what I would wish to avoid. I don't want the index
> origin to be a property of the array much less each dimension of the
> array. The program should work the same on any array that it is given.
yes. it (if it's a MATLAB function) should make use of the base or
origin attributes of each array it is given and return results that
naturally make sense for that base attributes and that default to
exactly the present operation of that program when the base = 1.
> I want to define how the program works rather than how the data works
> and I want the ability to have the program see things in the origin that
> is natural to the algorithm the program implements.
does not make sense to me.
>
> >
> > > This will force me to pay way more attention to the issue than I would like.
> >
> > no. you don't have to pay attention to it at all (because it will be
> > backwards compatible) *unless* you might want to take advantage of this new
> > base redefinition feature. if you don't like it, fine. don't use it. how
> > does that put you out?
>
> I don't want my program to do the wrong thing or blow up if I don't
> properly handle all the possible dimension origins an array that it is
> given can have.
does not make sense. MATLAB programs that we write can presently
"blow up" if we try to access array elements with indices that are out
of bounds (presently bounds are [1 1] and whatever is returned by the
size() function. all of our functions have to run size() to know how
far to go if we are examining or number crunching each element in the
array. if you want your MATLAB function to work with the "new" data
(that is, you are not guaranteed that the input arrays are 1-based)
you have to run base() (or whatever it would be named) to know where
the indices start. if you don't do that, it's legacy code.
> >
> > > Not
> > > knowing how operands (indices) will apply to an operator by just knowing
> > > the local execution environment to me is truly obscure even though it
> > > has become the modern way of thinking.
> >
> > sorry, Bob. i can't decode this. i have absolutely no idea what you mean.
> > can you elaborate?
>
> Does it make any more sense in the context of my above comments? I want
> index origin to be a property that is attached to the current
> "processor" state rather than to a datum.
>
> > if that is your worry, just stick with 1-based arrays and only warrant your
> > routine for proper operation if people supply you with the default 1-based
> > arrays for function arguments.
>
> I'd prefer not to.
then this "improvement" would have almost no value. i cannot fathom
why you wanna hamstring an improvement to such an extent that it would
be virtually useless.
>
> >
> > > To me the simplest solution is to provide a system variable which
> > > defines the index origin, make it local to functions and initialize it
> > > to 1 at every function call.
> >
> > making a global system index origin sounds like a bad idea to me.
>
> For me it well accomplishes the limited goal of being able to write my
> code using an origin appropriate to the algorithm.
NO! just like MATLAB is now where, if the size of the array is not
appropriate to the algorithm (or there is some other inconsistancy,
like plot(X,Y) where X and Y don't have the same shape) MATLAB bombs
and returns unfriendly diagnostics and then you fix the program that
called the function. the same should be the case for indexing bases.
if they are not consistent with other arguments or not appropriate to
the algorithm, MATLAB should bomb and print unfriendly diagnostics and
then the user figgers out how to supply appropriately indexed
arguments to the function.
> The origin that is
> used should be a property of the algorithm rather than the data it
> operates on.
>
> >
> > don't mean to be critical, but i am not sure you understand the basics of my
> > proposal (i think that Eric Jacobson and Jerry Avins understand it
> > perfectly).
>
> I believe I do. I just don't care for it.
well, some people like to sleep with the window open and other people
like to sleep with it closed (and both groups cannot be simultaneously
satisfied if they cohabit). but in my opinion, your idea is hardly an
improvement.
we need to have 0-based arrays that are natural for the context they
are in (like the DFT) and negative based arrays for other contexts
(like noncausal FIR filtering). what you want is this sorta "lowest
common denominator" thing where if one array is based at -128, then
ALL arrays are based at -128 and that, frankly, would suck.
> I find it too elaborate and
> susceptible to side effects. My proposal, unless there is a fatal hole
> in it, is much simpler, less pervasive and still accomplishes the goal
> of being able to use an index origin that is appropriate to the problem
> at hand.
it would be nearly useless and horribly inelegant. unless i am just
not understanding your proposal, Bob.
sorry,
r b-j
robert bristow-johnson
> On Sun, 16 Dec 2001 02:38:45 GMT, "robert bristow-johnson"
> <rob...@wavemechanics.com> wrote:
>
> >In article <3C1BCB54...@znet.com> , Bob Cain <arc...@znet.com> wrote:
> >
> >>
> >>
> >> robert bristow-johnson wrote:
> [snip]
>
> >> Existing defined functions that take or return indicies would
> >> behave as before and those of us that work in 0-origin would just need
> >> to remember that.
> >
> >no. if i call [val, indx] = max(abs(X)) on a complex array X (looking for
> >peaks in a spectrum), i want the max index returned (indx) to be in terms of
> >its own base. that's the whole point in making this extension.
>
> See my other post about why this can never be.
i did and couldn't figger out how it spoke to this issue at all. the
only way that this extension can work as a natural extension to how
MATLAB currently does things is if functions returning indices return
the correct indices in the context of their origin. there is no
inherent reason that cannot be done.
about your other post:
> E.g.
> A = linspace(1,100);
> % The first element (1-based):
> A(1)
> % The first element (0-based):
> A[0]
>
that is not a good syntax at all. what i am suggesting is this:
A = linspace(1,100);
% The first element (1-based):
A(1)
A = rebase(A, 0, 0); % now A is 0-based
% The first element (0-based):
A(0)
it's that simple. and now if you did this:
[maxval maxind] = max(A);
then the value returned in maxind would be 99 instead of 100.
r b-j
David McClain
Specifically, I thought Matlab was vector/array based and that most
algorithms were coded using matrix representations instead of explicit
indexing loops. Is this not so? And if it is, why should anyone care what
indexing scheme is used internally to Matlab?
I have never seriously used Matlab for anything, I have my own FPL based
language for this kind of thing.
http://home.mindspring.com/~dmcclain1/nmlpromo.htm
And it so happens that I do use zero based array indexing, but that is an
accident of the implementation language. Like Matlab, I also use vectorized
arithmetic for nearly everything, and even though I can perform explicit
array indexing, there is little reason to ever do such a thing.
Also, there is a significant runtime cost for doing so over simply using
matrix expressions which call optimized matrix operators down in the kernel
of NML. I'm sure the same performance hit (probably much worse in fact)
exists in Matlab. I know it does in IDL and PVWave.
- DM
Sturla Molden
<rob...@wavemechanics.com> wrote:
>screw C or C++. we want MATLAB to make good on its promise to express code
>using "familiar mathematical notation" and "just as they are written
>mathematically". for DSP,
I guess youd din't read my posting clearly enough.
Matlab allows you to overload the behaviour of the indexing object.
It is _only_ when you use the simple classes such as double or
int32 for indexing that the subssripts have to be 1-based.
For derived classes, the behaviour of the indexing object is defined
by the indexing object's subsindex method. Thus, 0-based indexing is
already in Matlab if you want to use it.
Sturla Molden.
jj, DBT thug and skeptical philalethist
>Thanks, Robert. I don't often print usenet postings but did this one
>and will study it.
I will observe that a simple way to implement the whole thing would
be to allow a declaration of an array between bounds. If an array
is not declared, it's 1-based, just like all the zillions of arrays
out there in matlab now.
If, on the other hand, you declare the array specifically to be
x(-44:1024+44)=0;
you've set the limits.
I would not allow extending the limits ON THE FLY, just on general
principles :)
--
Copyright j...@research.att.com 2001, all rights reserved, except transmission
by USENET and like facilities granted. This notice must be included. Any
use by a provider charging in any way for the IP represented in and by this
article and any inclusion in print or other media are specifically prohibited.
robert bristow-johnson
stu...@slettdette.molden.net.invalid (Sturla Molden) wrote:
> On Sun, 16 Dec 2001 02:59:24 GMT, "robert bristow-johnson"
> <rob...@wavemechanics.com> wrote:
>
>>screw C or C++. we want MATLAB to make good on its promise to express code
>>using "familiar mathematical notation" and "just as they are written
>>mathematically". for DSP,
>
> I guess youd didn't read my posting clearly enough.
it's more that i disagreed with what i read, perhaps out of ignorance.
> Matlab allows you to overload the behaviour of the indexing object.
i understand that you can overload subsref(), subsasgn(), and perhaps
subsindex().
to accomplish what i think should be done to MATLAB, these integer offset[]
values (that default to 0, but could be changed with a called to the
hypothetical "rebase()" function) would be added to each index any time an
element of an array is accessed and would be subtracted from the MATLAB
index each time an index is returned.
to make this work right using the present MATLAB OOP, it seems to me that a
new object (and class) must be created that attaches to an ordinary MATLAB
array (or "matrix" as Cleve prefers to call them) a vector of length equal
to the number of dimensions of the array and contain the offsets for each
dimension.
now, in order to make this reasonably elegant (and it is the fundamental
inelegance of MATLAB when applied to 90% of the DSP formulae that i simulate
using MATLAB that i am complaining about), we should be able to use "+",
"-", ".*", "./", "*", "/", concatination, and any of the existing MATLAB
syntax that makes sense for arrays that might not be 1-based. can those be
overloaded, too? and if they are overloaded, can they be made to continue
to work on the regular old MATLAB matrices that exist now without first
casting them into the object mentioned above?
> It is _only_ when you use the simple classes such as double or
> int32 for indexing that the subssripts have to be 1-based.
i'm not sure what you mean here. what is this "simple class"? is a regular
MATLAB variable (and NxM matrix or even a 1x1 matrix or scaler) this simple
class? sorry for the basic question, but i'm a DSPer (not a computer
scientist) and i wish i could just use MATLAB to do the DSP i need to do
without having to dig into this.
> For derived classes, the behaviour of the indexing object is defined
> by the indexing object's subsindex method. Thus, 0-based indexing is
> already in Matlab if you want to use it.
cool. but just 0-based indexing is still not enough. can this be used to
create a derived class where arbitrary offsets (and therefore bases) are
attached to the MATLAB array? can those fundamental operators be overloaded
to work with this derived class and also work with ordinary old MATLAB
arrays?
how can this be done?
r b-j
robert bristow-johnson
<not....@seebelow.org> wrote:
> robert bristow-johnson wrote:
>>
> ...
>> i know that there's Octave and Python (and MathCad and, hell, we can always
>> code it in C or C++)
>
> Sell it, brother!!!
>
> And don't forget to tell 'em about Scilab! (See
> http://www-rocq.inria.fr/scilab/.) For folks who've bought into the
> MATLAB method of DSP system design and simulation, I think Scilab--with
> it's large library of DSP functions--might be the easiest thing to
> switch over to. (But that said, I'll stick to Python, thank you.)
>
>> but, like Micro$hit, MATLAB has become the defacto
>> standard in modeling signal processing systems (as well as other systems).
>
> Now don't say "de facto" too loud or TMW will get a swelled head. And
> first thing you know, they'll start charging thousands for their
> products--and for each and every new little toykit they come up with.
> And pretty soon, they'll even start ignorin' the needs of their
> custmomers <wink>.
>
...
> world are gonna have to get used to poor service <wink>.
...
> -new-ways-to-skin-a-cat-<wink>-ly y'rs,
...
> (But you all saw through that anyway <wink>.)
Grant, have you seen a physician about that twitch in your eye or eyelid
that you've been having? it seems that the problem is getting worse.
> But ya' know, r...as the Mac-usin', Motorola-DSP-programmin', Vermont
> residin' guy that you are, I never much pictured you as the "de facto"
> type. (In fact, I'm kindda disillusioned right now...help me out here
> <sniffle>.)
aw! suck it up, ya little wimp! (now i know i'm gonna get my face pasted
by some guy from the midwest with a twitch in his face. <nod, nod, wink,
wink> "Say no more!")
r b-j
Grant Griffin
OK, I'll work on that <wink>.
>> But ya' know, r...as the Mac-usin', Motorola-DSP-programmin', Vermont
>> residin' guy that you are, I never much pictured you as the "de facto"
>> type. (In fact, I'm kindda disillusioned right now...help me out here
>> <sniffle>.)
>
>aw! suck it up, ya little wimp! (now i know i'm gonna get my face pasted
>by some guy from the midwest with a twitch in his face. <nod, nod, wink,
>wink> "Say no more!")
Thanks. I needed that.
mennen-skin-bracer-ly y'rs,
=g2
Steven Lord
comp.dsp snipped from newsgroups list; now we're getting more into MATLAB
programming and less into DSP.
"robert bristow-johnson" <rob...@wavemechanics.com> wrote in message
news:wUrT7.5618$Ga....@nwrddc01.gnilink.net...
> In article <3c1e2aa...@newscache.ntnu.no> ,
> stu...@slettdette.molden.net.invalid (Sturla Molden) wrote:
>
> > On Sun, 16 Dec 2001 02:59:24 GMT, "robert bristow-johnson"
> > <rob...@wavemechanics.com> wrote:
> >
> >>screw C or C++. we want MATLAB to make good on its promise to express
code
> >>using "familiar mathematical notation" and "just as they are written
> >>mathematically". for DSP,
> >
> > I guess youd didn't read my posting clearly enough.
>
> it's more that i disagreed with what i read, perhaps out of ignorance.
>
> > Matlab allows you to overload the behaviour of the indexing object.
>
> i understand that you can overload subsref(), subsasgn(), and perhaps
> subsindex().
Hi Robert,
You can overload whatever function you want using MATLAB classes. Chapter
22 in the Using MATLAB manual describes how to set up a class and provides
some examples of how to do so.
> to accomplish what i think should be done to MATLAB, these integer
offset[]
> values (that default to 0, but could be changed with a called to the
> hypothetical "rebase()" function) would be added to each index any time an
> element of an array is accessed and would be subtracted from the MATLAB
> index each time an index is returned.
Do you know just how many array references there are in MATLAB's code???
> to make this work right using the present MATLAB OOP, it seems to me that
a
> new object (and class) must be created that attaches to an ordinary MATLAB
> array (or "matrix" as Cleve prefers to call them) a vector of length equal
> to the number of dimensions of the array and contain the offsets for each
> dimension.
>
> now, in order to make this reasonably elegant (and it is the fundamental
> inelegance of MATLAB when applied to 90% of the DSP formulae that i
simulate
> using MATLAB that i am complaining about), we should be able to use "+",
> "-", ".*", "./", "*", "/", concatination, and any of the existing MATLAB
> syntax that makes sense for arrays that might not be 1-based. can those
be
> overloaded, too?
Sure. Just overload the appropriate functions: PLUS, MINUS, TIMES, RDIVIDE,
MTIMES, MRDIVIDE, HORZCAT, and VERTCAT respectively.
> and if they are overloaded, can they be made to continue
> to work on the regular old MATLAB matrices that exist now without first
> casting them into the object mentioned above?
The overloaded functions are only used for objects of the class for which
they are methods. So if you created a DSPOBJ object (by creating a
directory @dspobj and a constructor function dspobj.m) and overloaded plus.m
and minus.m in the @dspobj directory, those overloaded functions would only
be used for DSPOBJ objects.
> > It is _only_ when you use the simple classes such as double or
> > int32 for indexing that the subssripts have to be 1-based.
>
> i'm not sure what you mean here. what is this "simple class"?
Built-in data types like double, char, struct, cell, etc.
> is a regular
> MATLAB variable (and NxM matrix or even a 1x1 matrix or scaler) this
simple
> class? sorry for the basic question, but i'm a DSPer (not a computer
> scientist) and i wish i could just use MATLAB to do the DSP i need to do
> without having to dig into this.
Maybe based on this discussion, someone will create a class like this and
put it on MATLAB Central:
http://www.mathworks.com/matlabcentral
> > For derived classes, the behaviour of the indexing object is defined
> > by the indexing object's subsindex method. Thus, 0-based indexing is
> > already in Matlab if you want to use it.
>
> cool. but just 0-based indexing is still not enough. can this be used to
> create a derived class where arbitrary offsets (and therefore bases) are
> attached to the MATLAB array?
Sure. Inside the constructor, specify the offset and store it inside the
object. Then, inside the overloaded SUBSREF function, use that offset.
> can those fundamental operators be overloaded
> to work with this derived class and also work with ordinary old MATLAB
> arrays?
>
> how can this be done?
Using MATLAB, chapter 22 is what you'll need.
http://www.mathworks.com/access/helpdesk/help/pdf_doc/matlab/using_ml.pdf
--
Steve Lord
sl...@mathworks.com
Andrew Reilly
> In article <3C1AFEFE...@znet.com>, Bob Cain <arc...@znet.com> wrote:
>>robert bristow-johnson wrote:
>>> It be below.
>
>>Thanks, Robert. I don't often print usenet postings but did this one
>>and will study it.
>
> I will observe that a simple way to implement the whole thing would
> be to allow a declaration of an array between bounds. If an array
> is not declared, it's 1-based, just like all the zillions of arrays
> out there in matlab now.
>
> If, on the other hand, you declare the array specifically to be
> x(-44:1024+44)=0;
>
> you've set the limits.
>
> I would not allow extending the limits ON THE FLY, just on general
> principles :)
RBJ is wrong on this issue. Not because the Matlab language couldn't be
tweaked to include zero (or anything else) based indexing. Not even
because it could be tweaked but Matlab Co don't want to, and are claiming
that it can't be.
Given the existence of any number of functionally similar alternatives
(or even outright clones), the _only_ reason to use Matlab at all is that
you value some fraction of the enormous base of existing software that
has been written in the language in the last 15+ years.
The basic object type in Matlab is the matrix. That's why it's called
"Mat"lab. When the language was designed, it used matrix nomenclature,
and that means that the elements are indexed from 1. To change that now
is to invent another language. The job of making a base-agnostic Matlab
now is no smaller than the job of porting the entire Matlab library,
toolbox set and third-party applications across to any of the other
existing vector/matrix scripting languages. And that's particularly hard
because you have to verify
and debug every function and module, to generalise any assumptions about
argument and result ranges that it might be making, based on the existing
language "limitations".
You can't argue the "old functions don't need to support the new types"
line. Of course they do. All of the plot functions are the old
functions, all of the existing toolboxes are the old functions. All of
the stuff that makes Matlab desirable at all. If you don't allow the old
functions to use the new matrices, then there's no point to using the new
matrices at all: you might as well write that style of code in a
different language that better suits your purposes. Even if that
language is rbjMatlab++ that has arbitrary indexing but no libraries.
This joust might be fun for rbj to start every six months or so, and it's
fun to watch for a while, but it gets boring very quickly, because the
outcome is always the same.
--
Andrew Reilly
Peter Boettcher
One thing that's always irked me about objects... many functions will
bomb if passed an object not specifically recognized. Some objects
(like the hypothetical DSPOBJ) convert non-ambiguously to vectors. I
have no ideas on implementation, but low-level MATLAB functions should
automatically try converting to double if the class is not recognized.
There's no reason plot should not call an overloaded DOUBLE on an
object like this. Perhaps I'm just making a stupid mistake.
--
Peter Boettcher
MIT Lincoln Laboratory
boet...@ll.mit.edu
(781) 981-5275
J. Shima
using MATLAB for DSP work. I think the solution of having an extra
index entry would be a nice thing to have, no doubt about it here.
Too bad TMW isnt ready to listen...
> there is no reason in the world that this extension cannot be done,
> and if an idiot like me can see exactly how it can be done, i cannot
> see how the priests at TMW can't figger it out. especially when i
> spell it out. i invite you or anyone else on c.s-s.m (or comp.dsp,
> for that matter) to examine that and point out a flaw in the argument,
> but i feel pretty safe for the same reason i feel pretty safe that
> adding or subtracting 0 to an index will not change it.
Eli Brandt
robert bristow-johnson <rob...@wavemechanics.com> wrote:
>> To me the simplest solution is to provide a system variable which
>> defines the index origin, make it local to functions and initialize it
>> to 1 at every function call.
>
>making a global system index origin sounds like a bad idea to me.
Last time this came up Eric Jacobsen proposed a global variable for
index origin (like in APL), but that's not what Bob's talking about.
His proposal is that index origin is local, not global. You can
change it for yourself, just not for anyone else. (I've snipped
your objections that I think go away in light of this.)
My proposal was one baby step more restrictive, as I recall: index
origin would be a special directive, not a variable, so it could only be
set at the head of the file, and never changed. Not that anybody
_would_ try to change it in the middle of a function, but you never
know.
>both 1-based arrays and non-1-based arrays should be allowed to
>coexist in the same MATLAB program, and the only way to do that is
>have the array origins or base attribute attached to each one.
You're each describing one of the two ways: attach the index origin to
the data, or attach it to the code.
>> Existing defined functions that take or return indicies would
>> behave as before and those of us that work in 0-origin would just need
>> to remember that.
>
>no. if i call [val, indx] = max(abs(X)) on a complex array X (looking for
>peaks in a spectrum), i want the max index returned (indx) to be in terms of
>its own base. that's the whole point in making this extension.
Seconded. I do want functions that deal in indices to be origin-aware.
Bob's point here, though, is that if you were willing to punt on that,
Matlab could support DSP-compliant indexing without any backward
compatability issues whatsoever -- not even this one of MathWorks
rewriting the system functions that deal with indices. This is a handy
pointed goad.
So there's Bob's minimalist proposal, which needs zero updating of
Matlab code. Then there's one step up, where find() and friends are
rewritten so they're origin-aware. I don't believe this is very many
functions.
Your (rbj's) proposal, though, doesn't it require updating a great deal
of old code? Everything that does "for i = 1 : length(x)", or anything
like that. It's doable in principle, but you know how it is in
practice. You can see at least why somebody would need convincing to
take on this job.
Is it worth it over Bob's or my proposal, the sizeable increase in work
in order to get array-local indexing? I dunno, convince me. Acausal
FIRs, okay. Maybe use it for a start time, "this fragment of signal
starts at sample 100000", so you could represent granular and note-based
things. You'd have to work through the design, like what happens now
when you fuse arrays together? I can see some uses, but it seems like
smaller potatoes than 0-based indexing.
If I were going to have array-local indexing information, I'd like a
sampling rate. And some kind of units might be interesting. This opens
a real can of worms, though.
Oh, how about this? Keep the x(i) indexing operator 1-based for
compatibility; introduce x[i] indexing that can do fancy new things --
either with a function-local index origin, or with an array-local one.
I think I will still argue for function-local for software engineering
reasons, but this indexing distinction would let you get your
array-local indexing without breaking any old code (though you'd still
have to make find() etc. be origin-aware).
--
Eli Brandt | el...@cs.cmu.edu | http://www.cs.cmu.edu/~eli/
robert bristow-johnson
<sl...@mathworks.com> wrote:
> comp.dsp snipped from newsgroups list; now we're getting more into MATLAB
> programming and less into DSP.
i'm putting it back since it appears that, at least at present, the primary
constituency having the most interest (and the most to gain) by this
extension are the DSPers.
> Hi Robert,
hi Steven,
> You can overload whatever function you want using MATLAB classes. Chapter
> 22 in the Using MATLAB manual describes how to set up a class and provides
> some examples of how to do so.
yeah, i have an older version (the most current Mac version) so it's chapter
14 for me. and believe me, i have been reading it.
>> to accomplish what i think should be done to MATLAB, these integer
> offset[]
>> values (that default to 0, but could be changed with a called to the
>> hypothetical "rebase()" function) would be added to each index any time an
>> element of an array is accessed and would be subtracted from the MATLAB
>> index each time an index is returned.
>
> Do you know just how many array references there are in MATLAB's code???
but i would think they would centralize it a bit so that identical code
would not need to be repeated a zillion times and to make it possible to
make modifications/improvements to the method that array references are
made.
>> to make this work right using the present MATLAB OOP, it seems to me that a
>> new object (and class) must be created that attaches to an ordinary MATLAB
>> array (or "matrix" as Cleve prefers to call them) a vector of length equal
>> to the number of dimensions of the array and contain the offsets for each
>> dimension.
>>
>> now, in order to make this reasonably elegant (and it is the fundamental
>> inelegance of MATLAB when applied to 90% of the DSP formulae that i simulate
>> using MATLAB that i am complaining about), we should be able to use "+",
>> "-", ".*", "./", "*", "/", concatination, and any of the existing MATLAB
>> syntax that makes sense for arrays that might not be 1-based. can those be
>> overloaded, too?
>
> Sure. Just overload the appropriate functions: PLUS, MINUS, TIMES, RDIVIDE,
> MTIMES, MRDIVIDE, HORZCAT, and VERTCAT respectively.
>
>> and if they are overloaded, can they be made to continue
>> to work on the regular old MATLAB matrices that exist now without first
>> casting them into the object mentioned above?
>
> The overloaded functions are only used for objects of the class for which
> they are methods. So if you created a DSPOBJ object (by creating a
> directory @dspobj and a constructor function dspobj.m) and overloaded plus.m
> and minus.m in the @dspobj directory, those overloaded functions would only
> be used for DSPOBJ objects.
so you're saying that the original methods would be called if the objects
were in the original built-in classes. i wouldn't have to do a call to
isa(arg, 'double') and, if true, call the original function that was being
overloaded?
now, how would it know to call our overloaded function if i happen to be
adding a new array that just happens to have a 1,1 base to an old array (of
the same size) that is inherently a 1,1 base? i want the syntax of this
system to treat those two identically. i know in C++ i would have to create
a method for every argument permutation. is that what i would have to do in
MATLAB?
>> > It is _only_ when you use the simple classes such as double or
>> > int32 for indexing that the subssripts have to be 1-based.
>>
>> i'm not sure what you mean here. what is this "simple class"?
>
> Built-in data types like double, char, struct, cell, etc.
>
>> is a regular
>> MATLAB variable (and NxM matrix or even a 1x1 matrix or scaler) this simple
>> class?
i take it that the answer to that is "yes" and it is of class "double".
correct?
>> sorry for the basic question, but i'm a DSPer (not a computer
>> scientist) and i wish i could just use MATLAB to do the DSP i need to do
>> without having to dig into this.
>
> Maybe based on this discussion, someone will create a class like this and
> put it on MATLAB Central:
>
> http://www.mathworks.com/matlabcentral
i would love that. and short of turning myself into a cutthroat OOPs
programmer, i'd be happy to put in a significant effort into this. i would
still bet that the BEST implementation of this is at the core-level MATLAB
code, but perhaps with a decently complete extension of the salient MATLAB
utilities using non-1-based arrays, this would be seen to be useful enough
to sufficient numbers of people that Cleve, et. al., would see the light.
>> > For derived classes, the behaviour of the indexing object is defined
>> > by the indexing object's subsindex method. Thus, 0-based indexing is
>> > already in Matlab if you want to use it.
>>
>> cool. but just 0-based indexing is still not enough. can this be used to
>> create a derived class where arbitrary offsets (and therefore bases) are
>> attached to the MATLAB array?
>
> Sure. Inside the constructor, specify the offset and store it inside the
> object. Then, inside the overloaded SUBSREF function, use that offset.
>
>> can those fundamental operators be overloaded
>> to work with this derived class and also work with ordinary old MATLAB
>> arrays?
>>
>> how can this be done?
>
> Using MATLAB, chapter 22 is what you'll need.
>
> http://www.mathworks.com/access/helpdesk/help/pdf_doc/matlab/using_ml.pdf
i got that (and my own ca. 1998, v 5.2, Using MATLAB book) but i'm still not
clear on the feasibility of appropriate mixes with the built-in double
class.
anyway, as a first pass, it would look like the fundamental "rebase()"
function might look like:
function X = rebase(varargin)
X.array = varargin{1};
X.offset = zeros(1, ndims(X));
if length(varargin) == 2
if length(varargin{2}) == length(X.offset)
X.offset = 1 - varargin{2};
end
elseif length(varargin) == length(X.offset)+1
for i = 1:length(offset)
if length(varargin{i+1}) == 1
X.offset(i) = 1 - varargin{i+1}; % base is 1-offset
end
end
end
X = class(X, 'array');
Is this a sensible looking constructor? i want the calling syntax to look
just like reshape() where i can send the function either a vector specifying
the base, or the base index for each dimension as multiple arguments.
now the "base()" function might look like:
function b = base(X)
if nargin == 1
if isa (X, 'array')
b = 1 - X.offset;
elseif isa (X, 'double')
b = 1 - zeros(1, ndims(X));
end
end
please tell me if i'm way off base with this.
--
r b-j
Wave Mechanics, Inc.
45 Kilburn St.
Burlington VT 05401-4750
tel: 802/951-9700 ext. 207 http://www.wavemechanics.com/
fax: 802/951-9799 rob...@wavemechanics.com
--
robert bristow-johnson
and skeptical philalethist) wrote:
> In article <3C1AFEFE...@znet.com>, Bob Cain <arc...@znet.com> wrote:
>>robert bristow-johnson wrote:
>>> It be below.
>
>>Thanks, Robert. I don't often print usenet postings but did this one
>>and will study it.
>
> I will observe that a simple way to implement the whole thing would
> be to allow a declaration of an array between bounds. If an array
> is not declared, it's 1-based, just like all the zillions of arrays
> out there in matlab now.
>
> If, on the other hand, you declare the array specifically to be
> x(-44:1024+44)=0;
the problem with that is if x is already defined and if the indices don't go
as low as -44 or as high as 1024+44, then what you should get is an "???
Indices exceed array limits" error message.
> you've set the limits.
those limits would be a function of the current size attributes (returned by
size() and modified by reshape()) and the base or origin attribute
(represented by the "offset" vector) that i would like to see added to a
MATLAB variable, at least those of class "double".
i think, outside of an assignment like Y = X; (where X already exists as a
non-1-based array), then the only way to set the limits is to change the
base of an already existing matrix or array with what i'm calling the
"rebase()" function patterned after MATLAB's "reshape()" function.
> I would not allow extending the limits ON THE FLY, just on general
> principles :)
we can reshape MATLAB arrays on the fly (using the reshape() function). why
not change the base on the fly? it would just like delaying or advancing
the discrete signal without any need for zero padding and concatinating. of
course there would be inappropriate times to do that just as there are other
operations that can be misused.
i guess i'm "generally unprincipled". :-\
r b-j
robert bristow-johnson
<and...@gurney.reilly.home> wrote:
yeah, yeah. we've heard this before.
> When the language was designed, it used matrix nomenclature,
> and that means that the elements are indexed from 1.
<yawn>
> To change that now is to invent another language.
no. it is to *extend* a current language is a way that makes syntactical
and mathematical sense. it's what should have been done to MATLAB when they
were first developing the Signal Processing Toolbox 10 or whatever years
ago. by not doing it, they saved themselves a few (less than 100) man-hours
and probably cost the MATLAB DSP community several thousand.
> The job of making a base-agnostic Matlab
> now is no smaller than the job of porting the entire Matlab library,
> toolbox set and third-party applications across to any of the other
> existing vector/matrix scripting languages.
no, you port or modify the *basic* operators in MATLAB and let the DSP
community start writing the improved DSP toolbox functions with different
names _as_we_need_them_! (the way we would write them would be to change
the base back to 1, call the current Toolbox function, and the fix the
results returned to be at the appropriate base and index range.) this would
become an evolutionary process that would always be backwards compatible
until, in maybe a decade, MathWorks discovers that nobody is using their
miserable 1-based arrays with the DFT or discrete convolution anymore.
> And that's particularly hard
> because you have to verify
> and debug every function and module, to generalise any assumptions about
> argument and result ranges that it might be making, based on the existing
> language "limitations".
>
> You can't argue the "old functions don't need to support the new types"
> line. Of course they do.
only some, initially. the salient functions like the basic operators and
elementary functions and some well used ones that return indices (like
min(), max(), maybe find()). keep things backwards compatible and let the
new paradigm evolve and the new needs for updated functions (and the concise
definitions on how the will work with the new arrays) will become known in
the future and can be dealt with. MATLAB has certainly been creating new
facilities over the years and we've never complained about that. from the
perspective of those new functions, in one sense (that Cleve brings up again
and again) they are not backwards compatible since they didn't exist in
times before those new functions were developed. BUT THAT DOESN'T STOP
PROGRESS: "If you build it, they will come."
> All of the plot functions are the old
> functions, all of the existing toolboxes are the old functions. All of
> the stuff that makes Matlab desirable at all. If you don't allow the old
> functions to use the new matrices, then there's no point to using the new
> matrices at all:
oh come on. there's a shitload of old functions that have nothing to do
with this new indexing scheme or the need for it. especially outside the
Sig Proc Toolbox. i open my old MATLAB randomly and it lands on "clock()".
why would that need to be modified? *ever* ?! or close()?
> you might as well write that style of code in a
> different language that better suits your purposes. Even if that
> language is rbjMatlab++ that has arbitrary indexing but no libraries.
>
> This joust might be fun for rbj to start every six months or so,
i left it alone since the summer of 2000 (before we moved from Jersey to
Vermont). i don't have infinite time, BUT THIS IS IMPORTANT! it's a
conjecture, but i'll bet MathWorks has wasted 1000's of people's man-hours
just to save themselves a few or a few dozen. and more man-hours are going
to be wasted in the future because they don't deliver on their fundamental
promise to provide an "easy-to-use environment where problems and solutions
are expressed just as they are written mathematically". the literature says
one thing and MATLAB says another. if you don't keep that straight, you
will either have a lot of insidious bugs to look for or you will be doing
the ugliest mathematics because you decide to do all of your DSP using the
MATLAB 1-based convention.
if you *do* keep it straight, you will always be thinking when you're coding
MATLAB "do i need to subtract 1 here or not, if i do subtract 1, then my
index means frequency, but if i use that index in the future to access the
array, i'll have to remember to add 1 again. so maybe i won't subtract 1
here. but then i'll probably catch a nasty bug because i'll forget that
this k is really k+1. oh me, oh my, oh me, oh my, what shall i do?" THAT'S
HOW STUPID AND WASTEFUL THIS PROBLEM IS. MathWorks' efforts at resisting
and dismissing this fix and justifying that resistance has certainly been a
larger effort than if they had just fixed it 10 years ago. and it would
have saved 1000's of man-hours for their client base and it would be
considered as much heresy today to do DSP with fixed 1-based arrays for
MATLAB coders as it would be to C programmers.
and if MATLAB wasn't the "defacto" standard for exchanging DSP algorithms
and ideas to each other, if it didn't have all of those neat tools that none
of us can afford to buy, then we could just say "screw MATLAB" because of
this awful indexing problem and buy something else or just do it in C.
however, i have never used Octave or Python or Mathcad and have never had
code exchanged with me in those formats. the *only* other languages have
been C and Mathematica that have been used by me or other people i know to
communicate a DSP idea. for good or for bad, MATLAB is the standard in this
area as much as Windoze is for computer applications. i just hope that
MathWorks is more enlightened than Micro$hit is. (i still am hoping for
that, Cleve. please don't foist a bad standard upon us.)
> and it's
> fun to watch for a while, but it gets boring very quickly, because the
> outcome is always the same.
and Cleve, if you're reading this, that's why there's the "diatribe".
r b-j
Cleve Moler
Andrew Reilly <are...@bigpond.net.au> wrote:
>
> ...
>
>You can't argue the "old functions don't need to support the new types"
>line. Of course they do. All of the plot functions are the old
>functions, all of the existing toolboxes are the old functions. All of
>the stuff that makes Matlab desirable at all. If you don't allow the old
>functions to use the new matrices, then there's no point to using the new
>matrices at all: you might as well write that style of code in a
>different language that better suits your purposes. Even if that
>language is rbjMatlab++ that has arbitrary indexing but no libraries.
Andrew has again stated what I regard as the key point.
"plot", and "surf", and "mesh", and ... would all have to be
overloaded for a new object, or at least modified for any
kind of built-in extension, because many of their variants
use the index as the independent variable. I would not find
it satisfactory to have location of the Nyquist point in a plot
be off by one. Another example: do you imagine anyone would
want to solve ordinary differential equations where the index
of the dependent variable does not start at one?
Yes, many of us at MathWorks continue to follow this thread.
-- Cleve
mo...@mathworks.com
Eric Jacobsen
wrote:
>I have to say I am a little shocked that this whole thread even exists...
>Specifically, I thought Matlab was vector/array based and that most
>algorithms were coded using matrix representations instead of explicit
>indexing loops. Is this not so? And if it is, why should anyone care what
>indexing scheme is used internally to Matlab?
Perhaps you should go back and read the thread. Several basic
examples have been given of why this is a problem, and there are many
many more.
Eric Jacobsen
Minister of Algorithms, Intel Corp.
My opinions may not be Intel's opinions.
http://home.earthlink.net/~ejacobsensprint
Eric Jacobsen
wrote:
>Andrew has again stated what I regard as the key point.
>"plot", and "surf", and "mesh", and ... would all have to be
>overloaded for a new object, or at least modified for any
>kind of built-in extension, because many of their variants
>use the index as the independent variable. I would not find
>it satisfactory to have location of the Nyquist point in a plot
>be off by one. Another example: do you imagine anyone would
>want to solve ordinary differential equations where the index
>of the dependent variable does not start at one?
Please, please, please make this point more strongly! This is the
absolute basis of our frustration. As clear as it is to you how
useful and easy and natural it is for the index to start at one, it is
for us to start at zero, or perhaps -N. The fact that the tool
doesn't do that and the developers can't seem to grasp how large of a
problem that is for an awful lot of people is the fundamental basis of
the argument.
Let me analyse your statements a little in the context of my point of
view:
>I would not find
>it satisfactory to have location of the Nyquist point in a plot
>be off by one.
I don't, either. But it is every time I compute a dft using Matlab.
Not with any other tool, though.
I also don't find it satisfactory that the index of the plot of a
correlator output be off by one, and this is a curse I have lived with
from Matlab for far far far too long, and it has caused me GREAT
difficulty. I have had to retract or redo reports and papers before,
sometimes at the last minute, because I discovered that a plot or
analytical detail was off by one, because MATLAB screwed me once
again. Do you have any idea how maddening that is? I suspect you
have some hint from your above statement. Now imagine that it
actually does happen to you quite often when you use a particular tool
(but not nearly so much with others). How would you feel about that
tool?
>Another example: do you imagine anyone would
>want to solve ordinary differential equations where the index
>of the dependent variable does not start at one?
Please please please try to get that no one here to my knowledge is
even remotely suggesting that Matlab be made to abandon one based
indexing completely. We only want the capability to shift things when
appropriate so that the indices make sense for a much broader class of
problems than can be handled now. It boggles my mind that a
developer apparently refuses to recognize that they have the potential
to increase the scope of their tool to an obviously large class of
potential customers.
>Yes, many of us at MathWorks continue to follow this thread.
Unfortunately, it seems that is all that is ever done.
Nabeel
In case anyone catches this post in this thread, you may want to take a
look at a separate thread I started titled "Variable Based Indexing code
on File Exchange - any takers?", Dec 18, 12:21 AM. It's food for
thought, and should showcase some limitations as well as advantages of
an M based OOP implementation of a variable based indexing object.
And it might not be a bad way to learn about OOP in M.
-- Nabeel
Bob Cain
David McClain wrote:
>
> I have to say I am a little shocked that this whole thread even exists...
> Specifically, I thought Matlab was vector/array based and that most
> algorithms were coded using matrix representations instead of explicit
> indexing loops. Is this not so? And if it is, why should anyone care what
> indexing scheme is used internally to Matlab?
In my case it is because I work with ranges within arrays, sections if
you will. I would like range specifications to be applied with zero
origin, not just the explicit loops which can usually be avoided.
>
> I have never seriously used Matlab for anything, I have my own FPL based
> language for this kind of thing.
>
> http://home.mindspring.com/~dmcclain1/nmlpromo.htm
You have an intriguing looking language. Is there a way to use it under
Windows and without having a compiler? All I could find is source and
makefiles.
Also, as I am sure you are aware the documentation is pretty sparse. Do
you have plans to produce anything more comprehensive and aimed at a
newcomer to the basic concepts?
Bob
--
"Things should be described as simply as possible, but no simpler."
A. Einstein
////////////////////////////////////////\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
To contribute your unused processor cycles to the fight against cancer:
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\///////////////////////////////////////
Bob Cain
Eli Brandt wrote:
>
> My proposal was one baby step more restrictive, as I recall: index
> origin would be a special directive, not a variable, so it could only be
> set at the head of the file, and never changed. Not that anybody
> _would_ try to change it in the middle of a function, but you never
> know.
I'm thinking I would rather have it be a new function which sets the
index origin to the argument and returns the index origin of the calling
environment. A nit, but more esthetically pleasing somehow.
I'd appreciate your comments on this general approach, Cleve? The
impact internally is probably higher than what it would naively appear
but is it a show stopper?
Peter Boettcher
> On 18 Dec 2001 04:18:00 GMT, mo...@acoma.mathworks.com (Cleve Moler)
> wrote:
>
> >I would not find
> >it satisfactory to have location of the Nyquist point in a plot
> >be off by one.
>
> I don't, either. But it is every time I compute a dft using Matlab.
> Not with any other tool, though.
Funny, when I plot a DFT I like to have real frequency on the X axis,
not something that depends on the size of the DFT I took. So I
generate an index vector that matches what I would like to see, and
plot using that... it's one short line of code, and I can make the
plot look however I want.
Scott Seidman
@news.earthlink.net:
> On 18 Dec 2001 04:18:00 GMT, mo...@acoma.mathworks.com (Cleve Moler)
> wrote:
>
>>Andrew has again stated what I regard as the key point.
>>"plot", and "surf", and "mesh", and ... would all have to be
>>overloaded for a new object, or at least modified for any
>>kind of built-in extension, because many of their variants
>>use the index as the independent variable. I would not find
>>it satisfactory to have location of the Nyquist point in a plot
>>be off by one. Another example: do you imagine anyone would
>>want to solve ordinary differential equations where the index of the
>>dependent variable does not start at one?
>
> Please, please, please make this point more strongly! This is the
> absolute basis of our frustration. As clear as it is to you how
> useful and easy and natural it is for the index to start at one, it is
> for us to start at zero, or perhaps -N. The fact that the tool
> doesn't do that and the developers can't seem to grasp how large of a
> problem that is for an awful lot of people is the fundamental basis of
> the argument.
As someone doing signal processing in Matlab for at least 12 years, I can say I really
don't understand the problem. Maybe this is because of my Fortran-based upbringing.
Frankly, I'm not that sure that the DSP community, aside from a vocal few, really care
about the issue. I've been in engineering departments in universities for some time,
and I've never heard one prof or student complaining of Matlab's 1-based indexing
scheme. Dozens of authors in DSP have opted to base their textbooks around Matlab,
inferior indexing scheme or not.
The whole concept of convolution and standard transforms centers around integrating
over a dummy variable. Having grasped this concept, I don't understand why reindexing
(which is really just one more dummy variable) is so complex or inconvenient.
>[ snip ]
> I have had to retract or redo reports and papers before,
> sometimes at the last minute, because I discovered that a plot or
> analytical detail was off by one, because MATLAB screwed me once
> again. Do you have any idea how maddening that is? I suspect you
> have some hint from your above statement. Now imagine that it
> actually does happen to you quite often when you use a particular tool
> (but not nearly so much with others). How would you feel about that
> tool?
I think you are being a little dramatic here. Besides, the old axiom holds... "fool me
once, shame on you. Fool me twice, shame on me." We all tend to make mistakes when we
code. Over time, we all learn what mistakes we (as individuals) tend to make, and
debugging such mistakes becomes second nature (personally, I never remember that the
transpose operater returns the complex conjugate of complex numbers). To continue your
insightful analogy of a tool, if I were a carpenter who kept hitting myself on the
thumb with my hammer, I would learn not to do that, or I would learn not to care when I
hit myself on the thumb, or I would buy a hammer I tend not to hit myself with, or I
would stop being a carpenter, or maybe I would subcontract someone else to hammer nails
for me. There are many options, but I would certainly not incessantly whine to other
carpenters about my lack of facility with the tools of my trade.
> Please please please try to get that no one here to my knowledge is
> even remotely suggesting that Matlab be made to abandon one based
> indexing completely. We only want the capability to shift things when
> appropriate so that the indices make sense for a much broader class of
> problems than can be handled now. It boggles my mind that a
> developer apparently refuses to recognize that they have the potential
> to increase the scope of their tool to an obviously large class of
> potential customers.
>
>>Yes, many of us at MathWorks continue to follow this thread.
>
> Unfortunately, it seems that is all that is ever done.
>
> Eric Jacobsen
> Minister of Algorithms, Intel Corp.
> My opinions may not be Intel's opinions.
> http://home.earthlink.net/~ejacobsensprint
>
It just seems to me that it would be a lot quicker and easier for people with this
problem to look at the two dozen or so Matlab functions they call, and write new
functions that deal with the problem of non-zero indexing. An array index, after all,
is how a programming language maps numbers to memory locations, and not a religion.
If this is as big a problem as you indicate, somebody would write a zero-indexing
toolbox for Matlab, and sell it for profit.
Scott Seidman
Sturla Molden
<rob...@wavemechanics.com> wrote:
>i'm not sure what you mean here. what is this "simple class"?
For example "double", which is Matlab's default.
>cool. but just 0-based indexing is still not enough. can this be used to
>create a derived class where arbitrary offsets (and therefore bases) are
>attached to the MATLAB array?
In its simplest form:
function y = subsindex(A)
y = double(A) - offset;
>can those fundamental operators be overloaded
>to work with this derived class and also work with ordinary old MATLAB
>arrays?
As long as you overload subsindex, it will work with any array.
Sturla Molden
Sturla Molden
wrote:
>One thing that's always irked me about objects... many functions will
>bomb if passed an object not specifically recognized. Some objects
>(like the hypothetical DSPOBJ) convert non-ambiguously to vectors. I
>have no ideas on implementation, but low-level MATLAB functions should
>automatically try converting to double if the class is not recognized.
>
>There's no reason plot should not call an overloaded DOUBLE on an
>object like this. Perhaps I'm just making a stupid mistake.
Every calss should have a double() method for typecasting to double.
Any function should try try to do a typecast if the object is not
recognized. An error should be thrown only when an appropriate
typecast cannot be done.
Sturla Molden
jj, DBT thug and skeptical philalethist
robert bristow-johnson <rob...@wavemechanics.com> wrote:
>the problem with that is if x is already defined and if the indices don't go
>as low as -44 or as high as 1024+44, then what you should get is an "???
>Indices exceed array limits" error message.
That depends. You should have the ability to reset the limits if
you want to, but ONLY if you want to. I certainly do agree that
error-checking is useful.
>> I would not allow extending the limits ON THE FLY, just on general
>> principles :)
>we can reshape MATLAB arrays on the fly (using the reshape() function).
Let me rephrase what I mean: I mean that I would not allow, if the
array was based from -55 to 1024+55, for instance, a new element due
to a variable index of -56. However, I would certainly allow
reshaping the array, EXplicitly, by variable x(i:j) or explicit
x(-12:1024+12) means.
jj, DBT thug and skeptical philalethist
Andrew Reilly <are...@bigpond.net.au> wrote:
>(or even outright clones), the _only_ reason to use Matlab at all is that
>you value some fraction of the enormous base of existing software that
>has been written in the language in the last 15+ years.
Now, Andrew, that's your personal position, but I don't agree with
it, and I'm sure I'm not the only one who doesn't.
>The basic object type in Matlab is the matrix. That's why it's called
>"Mat"lab.
So?
>When the language was designed, it used matrix nomenclature,
It used linear algebra nomenclature, you mean.
>and that means that the elements are indexed from 1.
A historical accident.
>To change that now
>is to invent another language.
That is simply not true. What we're suggesting is nothing but a
SUPERSET of the language. It most absolutely, incontrovertably
is not "another language".
Grant Griffin
>
...
>But here is the key point: none of our existing code would work with
>the new object. You couldn't plot it; you couldn't print it; you
>certainly couldn't do any matrix operations with it. Yes, over time,
>everything could be rewritten to handle the extension, but that
>is what we want to avoid. It would be like AM and FM radio -- two
>systems living in the same box, but with separate and independent
>underlying technology.
As it happens, I own several of those. In fact, most of 'em also come with a
clock. And I think I paid less than $20 each.
Python's-cheap-practicality-beats-Matlab's-expensive-purity-ly y'rs,
robert bristow-johnson
(Cleve Moler) wrote:
> In article <v3vT7.21037$_z.5...@news-server.bigpond.net.au>,
> Andrew Reilly <are...@bigpond.net.au> wrote:
>>
>> ...
>>
>>You can't argue the "old functions don't need to support the new types"
>>line. Of course they do. All of the plot functions are the old
>>functions, all of the existing toolboxes are the old functions. All of
>>the stuff that makes Matlab desirable at all. If you don't allow the old
>>functions to use the new matrices, then there's no point to using the new
>>matrices at all: you might as well write that style of code in a
>>different language that better suits your purposes. Even if that
>>language is rbjMatlab++ that has arbitrary indexing but no libraries.
>
> Andrew has again stated what I regard as the key point.
> "plot", and "surf", and "mesh", and ... would all have to be
> overloaded for a new object,
not so much for backwards compatibility, but more because, to make the new
object useful, most existing operations that make sense for the new object
(an array with a different base) should eventually be made to work with the
new object. that would be nice, but it won't kill anyone's legacy code if
it isn't done.
two points:
1. sure some of the most oft used functions (like plot, perhaps surf, mesh)
should be modified right away when this "new object" becomes available. but
that modification would not be very much for nearly all of these functions.
it would essentially be teaching them to use the new indexing range (it has
to figure out the range anyway, but now it doesn't assume it starts with 1)
and check for index base consistency just like plot(X,Y) checks for shape
consistency between X and Y.
2. certainly, many MATLAB functions won't make sense and shouldn't make
sense for some arguments supplied that are not 1-based arrays. then MATLAB
should return an error message just like it does now when the size or shape
of a supplied matrix argument is not what it is expecting. no big deal. if
i want to use such a function, i'll give it an appropriate 1-based array.
the DFT and convolution are not such functions.
> or at least modified for any
> kind of built-in extension, because many of their variants
> use the index as the independent variable.
but in many cases, they will simply operate on the data from beginning to
end oblivious of the index base.
> I would not find
> it satisfactory to have location of the Nyquist point in a plot
> be off by one.
as Eric pointed out, MATLAB *does* presently have the location of Nyquist
off by one. that's why we do not find it satisfactory, Cleve.
> Another example: do you imagine anyone would
> want to solve ordinary differential equations where the index
> of the dependent variable does not start at one?
not for other than normal people who want to do mathematics with a minimal
standard of elegance and are tired of a contrivance where they always have
to add or subtract one to keep everything straight.
(using C notation to indicate subscripts and () to indicate a continuous
function.)
y[n] should be the "nth derivative of the y(t)".
that is, (back to using MATLAB notation):
y(0) should be y (hmmmm, problem is i don't have a y(0) in MATLAB.)
y(1) should be y'
y(2) should be y''
y(3) should be y'''
...
Cleve, why do you think it's normal for y(n) (read "y sub n") to be the
(n-1)th derivative of the function y? is it for the same reason it seems
normal to you that Nyquist has a frequency of N/2 + 1 ? (do you like to
think of DC having a frequency of 1?) it seems pretty silly to me.
> Yes, many of us at MathWorks continue to follow this thread.
thank you Cleve. continue to toss up more counter-examples and we'll keep
trap-shooting them down.
i have to point out that things are starting to get hairy for me regarding
the holiday season. i am flying out Saturday morning and i got lot's of
shopping and packing and home preparation (clean-up) and i still gotta work
through Friday (and i don't yet get paid for lobbying TMW to fix MATLAB,
maybe someday). so i hope we can continue this after the new year. can we
Cleve and Nabeel? i'll be able to check in on the thread until Friday, but
i won't be able to spend much time on it.
someday, maybe i should drive down there (remember when i was in Jersey and
i offered to drive "up" there?) and we should thrash this out more directly.
unless you wanna come up to Stowe for a company ski-trip? (i only do Nordic
skiing, but i can try to learn anything.)
L8r,
Eric Jacobsen
wrote:
>eric.j...@ieee.org (Eric Jacobsen) writes:
>
>> On 18 Dec 2001 04:18:00 GMT, mo...@acoma.mathworks.com (Cleve Moler)
>> wrote:
>>
>> >I would not find
>> >it satisfactory to have location of the Nyquist point in a plot
>> >be off by one.
>>
>> I don't, either. But it is every time I compute a dft using Matlab.
>> Not with any other tool, though.
>
>Funny, when I plot a DFT I like to have real frequency on the X axis,
>not something that depends on the size of the DFT I took. So I
>generate an index vector that matches what I would like to see, and
>plot using that... it's one short line of code, and I can make the
>plot look however I want.
I do sometimes do that, too, to make a plot that goes from -pi/2 to
+pi.2, for example, and care must be taken to make sure DC lands where
it should. However, if you want to deal with the usual mathematical
DFT indexing, where the index number corresponds to the number of
cycles per aperture of the basis function (e.g., DC is 0), then Matlab
is off by one. If you're trying to be consistent from that sort of
analysis in standard notation, and a software or hardware
implementation where addresses are generated in place of the indices,
again, proportional to the analysis, then often you want the plot to
reflect what you'd see in both the analysis and in the implementation.
In MATLAB this requires shifting the indices by one, since it is
inconsistent with both the analysis and how most people seem to
construct implementations.
robert bristow-johnson
Seidman <ScottS...@mindspring.com> wrote:
perhaps that's it. i think that i'm older than you (my PhD would have been
1985 had i gotten it), and Fortran was my first programming. i haven't
allowed that first love to cloud my vision when i see something far better
(although i am still disappointed that C never really had "complex" as a
fundamental type).
> Frankly, I'm not that sure that the DSP community, aside from a vocal few,
really care
> about the issue. I've been in engineering departments in universities for
some time,
> and I've never heard one prof or student complaining of Matlab's 1-based
indexing
> scheme.
maybe lack of vision? how many students or profs that knew both Fortran and
C preferred Fortran's indexing (especially since a C array can be based at
any number, not just 0)?
> Dozens of authors in DSP have opted to base their textbooks around Matlab,
> inferior indexing scheme or not.
that's part of the problem, isn't it? take a perfectly good textbook like
Orfanidis "Intro to Signal Processing" and compare the math in the body of
the text to the MATLAB code in the appendix. since you're a prof (i used to
be one, too) ask yourself this pedagogical questions: "Why should we be
forcing the student, who is learning these concepts of convolution and
transforms for the first time, to deal with otherwise unnecessary mechanics
of adding or subtracting 1 when comparing the math theory in the body of the
text to the MATLAB code examples of the very same theory? Might we be
introducing unnecessary confusion when he/she sees 'n' in the math and 'n+1'
in the MATLAB for the very same subscript?"
> The whole concept of convolution and standard transforms centers around
integrating
> over a dummy variable.
no, some of these subscripts are not variables of integration (or
summation). in the DFT,
N-1
X[k] = SUM{ x[n] * exp(-j*2*pi*n*k/N) }
n=0
k is not a dummy variable. or in the iDFT,
N-1
x[n] = (1/N)*SUM{ X[k] * exp(+j*2*pi*n*k/N) }
k=0
n is not a dummy variable.
these equations, as depicted in any decent textbook as above and not as
N
X[k] = SUM{ x[n] * exp(-j*2*pi*(n-1)*(k-1)/N) }
n=1
N
x[n] = (1/N)*SUM{ X[k] * exp(+j*2*pi*(n-1)*(k-1)/N) }
k=1
because of the loss of elegance, conciseness, and even functionality (where
k *is* known to represent frequency, not just an index). same with
convolution:
N-1
y[n] = SUM{ x[n-k] * h[k] }
k=0
h[k] *is* the impulse response and h[0] (not h[1]) *is* the the output of
the LTI system at time = 0 (when the impulse is applied). to introduce
fudging terms of +1 and -1 confuses students, often confuses other people,
wastes man-hours, and is simply ugly. especially when it's fundamentally
unnecessary.
> Having grasped this concept,
i'm not convinced you *have* grasped it entirely.
> I don't understand why reindexing
> (which is really just one more dummy variable) is so complex or inconvenient.
the concept to grasp (especially if you're in the teaching profession) is
that of the need for mathematical elegance. it's not for the purpose of
making things pretty for the student. it's for conciseness, and if you can
prevent unnecessary and ancillary factiods (such as "in the text it's h[n]
but in MATLAB it's h(n+1)..."), that do not serve to teach the student what
the pedagogical concept is (like "what is convolution"), from creeping in
and competing for the attention of the student and possibly confusing the
student, why not prevent that?
>>[ snip ]
>> I have had to retract or redo reports and papers before,
>> sometimes at the last minute, because I discovered that a plot or
>> analytical detail was off by one, because MATLAB screwed me once
>> again. Do you have any idea how maddening that is? I suspect you
>> have some hint from your above statement. Now imagine that it
>> actually does happen to you quite often when you use a particular tool
>> (but not nearly so much with others). How would you feel about that
>> tool?
>
> I think you are being a little dramatic here.
dramatic, but not untrue. i have had very similar experiences.
> Besides, the old axiom holds... "fool me
> once, shame on you. Fool me twice, shame on me." We all tend to make
mistakes when we
> code. Over time, we all learn what mistakes we (as individuals) tend to make,
and
> debugging such mistakes becomes second nature (personally, I never remember
that the
> transpose operater returns the complex conjugate of complex numbers).
if it didn't, using the inner product to naturally define a norm (which is
always real and non-negative) wouldn't work very well, would it? the reason
that the transpose operator returns the complex conjugate of complex numbers
is that it is the only *natural* way to do it. alls we're trying to do is
get MATLAB to have a modicum of naturalness (that, BTW, also follows the
mathematical convention of the literature) so that people make fewer
mistakes and less time is wasted on debugging. a programming mistake due to
a flaw in the language, no matter how well documented that flaw is, is not
entirely the fault of the programmer. that is why programming languages
must evolve and be allowed to evolve. can you imagine what state computer
science would be if that were not the case?
> To continue your
> insightful analogy of a tool, if I were a carpenter who kept hitting myself on
the
> thumb with my hammer, I would learn not to do that, or I would learn not to
care when I
> hit myself on the thumb, or I would buy a hammer I tend not to hit myself
with, or I
> would stop being a carpenter, or maybe I would subcontract someone else to
hammer nails
> for me. There are many options, but I would certainly not incessantly whine
to other
> carpenters about my lack of facility with the tools of my trade.
very poor analogy (it's like the standard hammer is deliberately unbalanced
and the carpenters are expected to "just get used to it"). here's a better
carpenter analogy (that is not hypothetical): what are the cross-section
dimensions of a 2 by 4? 2 inches by 4 inches? almost never. but they
aren't always 1 5/8 by 3 5/8 either. in fact, they have been (on average)
getting a little small over time but that is not consistent between lumber
suppliers. so carpenters have to remember to keep that factiod in their
brains and never forget and periodically check it with a tape measure in
case it changes slightly. here's another one: who long is a standard 8
foot stud? no, it's about 7 ft 8 5/8 in, so that when you nail full 8 foot
planks to the bottom and top, you get the 8 feet you need to nail 8 foot
drywall to. that's another horrible factiod that carpenters and contractors
have to deal with, and believe me (as the son of a carpenter) they either
order the lumber directly themselves or, if they send a lackey out to get
some "8 foot studs" they need to remember to make awful damn sure which ones
he's bringing back. (they can always cut the 96 inch ones but not so the
other way around.)
why do you want MATLAB, an important and defacto standard analytical tool to
force us to adopt this kind of bullshit?
>
> It just seems to me that it would be a lot quicker and easier for people with
this
> problem to look at the two dozen or so Matlab functions they call, and write
new
> functions that deal with the problem of non-zero indexing.
that's what Nabeel (and later myself) is doing. my complaint is that as a
DSPer, i shouldn't have to teach myself OOP just to use a DSP tool to do DSP
concisely. this is just too fundamental for a product like MATLAB to get
wrong and then carve that error into stone, enshrining it for all time.
> An array index, after all,
> is how a programming language maps numbers to memory locations, and not a
religion.
well, it's not a religion but indices are more than "how programming
languages map numbers to memory locations". they are mathematical notation.
if your programming language purports to use "familiar mathematical
notation" and provide "an easy-to-use easy-to-use environment where problems
and solutions are expressed just as they are written mathematically", then
you MUST recognize that indices are also established mathematical
conventions. to take a conventional index "n", and just willy-nilly change
it to "n+1" or "n-1" (because it's easier for "us" not our customers) is an
abuse and certainly fails in that earlier quoted promise.
this is the last long "diatribe" (as Cleve would call it) that i can afford
to write before Xmas and the new year. i would love to shoot down future
rebuttals but i don't have the time. hey Eric! can you cover for me on
that? don't let them get away with any foolishness, okay?
Eric Jacobsen
<ScottS...@mindspring.com> wrote:
>eric.j...@ieee.org (Eric Jacobsen) wrote in news:3c1ec603.889449650
>@news.earthlink.net:
>> Please, please, please make this point more strongly! This is the
>> absolute basis of our frustration. As clear as it is to you how
>> useful and easy and natural it is for the index to start at one, it is
>> for us to start at zero, or perhaps -N. The fact that the tool
>> doesn't do that and the developers can't seem to grasp how large of a
>> problem that is for an awful lot of people is the fundamental basis of
>> the argument.
>As someone doing signal processing in Matlab for at least 12 years, I can say I really
>don't understand the problem. Maybe this is because of my Fortran-based upbringing.
>Frankly, I'm not that sure that the DSP community, aside from a vocal few, really care
>about the issue. I've been in engineering departments in universities for some time,
>and I've never heard one prof or student complaining of Matlab's 1-based indexing
>scheme. Dozens of authors in DSP have opted to base their textbooks around Matlab,
>inferior indexing scheme or not.
Clearly, and as rb-j often points out, this is a difficult argument
partly because of the fact that Matlab is widely used within the DSP
community. This is also a big part of why we do care to see this
change accomodated: a lot of people use it, and it even more would
use it with a lot less frustration and confusion.
>The whole concept of convolution and standard transforms centers around integrating
>over a dummy variable. Having grasped this concept, I don't understand why reindexing
>(which is really just one more dummy variable) is so complex or inconvenient.
It often isn't, but in many cases in DSP the indices represent
physical quantities with meaning that is significant and fundamental
to the problem at hand. I have offered DFT indices and correlator
lags as very simple and straighforward examples, but there are many
more. When you work in a design process that starts with an analysis
that may use standard discrete mathematical notation, and you're
trying to get to an implementation where the indices often wind up
being addresses into a memory somewhere that are generated with either
hardware or software based on some computation, the connection between
the analysis, the meaning of the indices, and the implementation is
often very consistent with the exception of the simulation tool *if*
you use Matlab. If you use some other tool, like MathCAD, SPW, etc.,
the tool does not cause such a disconnect, since other tools almost
universally support variable indexing, which can then be matched to
whatever the problem requires.
>> I have had to retract or redo reports and papers before,
>> sometimes at the last minute, because I discovered that a plot or
>> analytical detail was off by one, because MATLAB screwed me once
>> again. Do you have any idea how maddening that is? I suspect you
>> have some hint from your above statement. Now imagine that it
>> actually does happen to you quite often when you use a particular tool
>> (but not nearly so much with others). How would you feel about that
>> tool?
>
>I think you are being a little dramatic here. Besides, the old axiom holds... "fool me
>once, shame on you. Fool me twice, shame on me." We all tend to make mistakes when we
>code. Over time, we all learn what mistakes we (as individuals) tend to make, and
>debugging such mistakes becomes second nature (personally, I never remember that the
>transpose operater returns the complex conjugate of complex numbers). To continue your
>insightful analogy of a tool, if I were a carpenter who kept hitting myself on the
>thumb with my hammer, I would learn not to do that, or I would learn not to care when I
>hit myself on the thumb, or I would buy a hammer I tend not to hit myself with, or I
>would stop being a carpenter, or maybe I would subcontract someone else to hammer nails
>for me. There are many options, but I would certainly not incessantly whine to other
>carpenters about my lack of facility with the tools of my trade.
Ah, disparagement.
How about this twist on your analogy:
You're a carpenter and you have choice of hammers. One hammer has
some features that make it particularly nice, like, perhaps, a
magnetic 20oz head and a claw with just the right angle for the sort
of work you do. The hammer works great for many tasks, and you have
other hammers that work great, too, but they may not have the magnetic
head and nice claw. In your work you often have to frame headers, but
whenever you do the hammer *always* puts the nail 1/4" to the left of
where it should. No other hammer does this, and this one only does it
on headers. Since you do headers often, but that's the only place the
problem occurs, you either have to deal with the fact that very often
you just nail like you would with any other hammer, and any other
hammer places nails just fine all the time, but you have to
continually remind yourself that there is a special annoyance with
this one brand of hammer, and if you're not continually paying
attention, the next time you go to nail up a header you screw it up.
Only in this business, IMHO, it's much *more* annoying, because the
bugs that result can be very subtle, and they can be especially tough
to find because unless you continually remind yourself that when the
index has to deal with a physical quantity that doesn't conveniently
start with 1 (most don't, oddly enough), you must pay especially close
attention. I have often dealt with algorithms where the index is a
computed variable based on measured inputs, so that the index is
proportional to some measurable quantity, and the algorithm to compute
the index is part of the simulation. When you compute the index and
that computation gets the right answer, it may still be the wrong
index, because Matlab can't deal with the right answer, it has to be
shifted. The analysis can be consistent with the physics, and the
implementation can be consistent with the analysis (which you often
want it to be so that the computations are done efficiently), but the
simulation has to shift the indices due to a limitation IN THE TOOL.
This is the source of the complaint.
I'll give a few examples: I work in wireless communications, and
often one thing that needs to be computed is the frequency offset of
the signal. There are many ways to compute this, but a DFT of a CW
preamble is one that has been used often. In this case, if the
baseband signal has no offset the DFT of the CW will be DC, and should
be in bin zero to represent no offset. If a local coefficient based
interpolator (like Quinn's or mine) is used, the fine frequency offset
is computed based on the DFT coefficients local to the maximizer, and
added to the bin number, in all parts of the development *except the
Matlab simulation* where it is off by one. In *this* case, the index
is not representative of the offset, it has an artificial bias. If
you're trying to keep straight in your head how to deal with the
interpolating algorithm and trying to work out how best to compute a
correction vector, the tool gets in the way by adding an additional
constraint of "Oh, yeah, also shift by one in this case, since the
coefficients have meaning..."
Another case is the computation of indices into coefficients of a
polyphase FIR filter. In this case the indices have meaning in that
they're usually computed from the delay in an NCO after the phase
accumulator rolls over. If you're using the usual binary phase
accumulator, it rolls through zero according to normal arithmetic
rules, and the number in the accumulator can be pulled out during
certain trigger events, and used as the address to pull coefficients
out of a bank of coefficient memories. This is a nice algorithm that
connects well between the analysis of the problem, written in standard
discrete mathematical notation, and the implementation, where the
delays correspond exactly, based on the computations, to the addresses
(generated in hardware, typically) of the coefficient memories. If,
however, you try to simulate the damn thing in Matlab (like I had to),
you are continually confronted with the disparity between the nice
analysis, the implementation you're going to use, the delays that the
indices indicate, and the fact that you have to shift them all by one
*only in Matlab*. If you shift them by one in the analysis or the
implementation, you get a mess, because nobody makes memories that
start at one, and almost everybody writes delay time axes with the
first index as zero, since that's the no delay case (which, oddly
enough, also happens frequently in real life).
Shall I go on? I've got a hundred of these, and each time I spent a
lot of time using other tools with no such issues, so I didn't have to
think about it. I also did a lot of analysis, in standard discrete
mathematical notation, and didn't have to think about it. I also read
a lot of papers, which used standard mathematical analysis, and didn't
have to think about it. I collaborated with colleagues here, in other
companies, and at academic research labs, and since we all use
standard mathematical notation and understand the related metrics and
practical implementations, we communicated well without having to
think about it. But when we got to Matlab simulations, OOPS, THE
HAMMER HIT MY HAND. But, thanks to you, I now realize it must have
been my fault, and I should adjust all of the standard mathematical
notation, implementations, the physical quantities associated with the
algorithms, and all my colleagues, since, clearly, Matlab must be the
guiding standard.
Or not.
>It just seems to me that it would be a lot quicker and easier for people with this
>problem to look at the two dozen or so Matlab functions they call, and write new
>functions that deal with the problem of non-zero indexing. An array index, after all,
>is how a programming language maps numbers to memory locations, and not a religion.
If we had the time and resources to develop it all ourselves, there'd
be no reason to buy the tool. We buy the tool so that we don't have
to do this type of work ourselves, and Matlab has a business because
there is value in that for customers. Despite this one-based indexing
thing, we still buy the tool because it potentially saves us time with
the nice i/o routines, plotting functions, etc., and because I can do
things like write a FIR filter in one line of code.
There are other reasons why we'd prefer a universal solution, a big
one being that many of us share code across wide scopes. I share
code with academic labs, subcontractors, colleagues, students, etc.,
etc. If each time I do this I have to make sure that they also have a
specific set of bastard functions, it makes the sharing problem more
difficult. This is related to the first part of this post, which is
that a lot of people use Matlab, and that is one of it's big
utilities: people can share concepts, processes, and results in a
common language. What we're complaining about is a shortcoming that
causes a lot of difficulty in an otherwise very useful tool.
>If this is as big a problem as you indicate, somebody would write a zero-indexing
>toolbox for Matlab, and sell it for profit.
Which gets suggested every time this comes up, and often somebody goes
out to investigate this avenue. One roadblock is the one I just
described: if it's not part of the standard tool, its utility is
automatically reduced. Custom extensions to standard computational
languages always have a very difficult time existing.
Bob Cain
robert bristow-johnson wrote:
>
> > Having grasped this concept,
>
> i'm not convinced you *have* grasped it entirely.
Robert, I wish you would curb this habit of accusing people who disagree
with you of lacking understanding. That is clearly a two way street and
one on which traffic is sure to jam.
robert bristow-johnson
>
>
> robert bristow-johnson wrote:
>>
>> > Having grasped this concept,
>>
>> i'm not convinced you *have* grasped it entirely.
>
> Robert, I wish you would curb this habit of accusing people who disagree
> with you of lacking understanding. That is clearly a two way street and
> one on which traffic is sure to jam.
point taken.
apologies, Scott.
r b-j
(again, i'll keep my eye on the thread but i won't have time for any
treatises, so detractors will be able to get their licks in with impunity
now.)
Eric Jacobsen
<rob...@wavemechanics.com> wrote:
>this is the last long "diatribe" (as Cleve would call it) that i can afford
>to write before Xmas and the new year. i would love to shoot down future
>rebuttals but i don't have the time. hey Eric! can you cover for me on
>that? don't let them get away with any foolishness, okay?
>r b-j
Bob, you must know by now that there is no possible way that I can
ever hope to fill your shoes. ;)
In any case, have a safe and happy holiday trip.
Cheers,
Bob Cain
robert bristow-johnson wrote:
>
> it would be nearly useless and horribly inelegant. unless i am just
> not understanding your proposal, Bob.
You seem to understand it, you just don't care for it. That's cool;
there's no accounting for taste. :-)
Have a good holiday. I'm sure that when your head clears you'll see it
my way. Just kidding, just kidding!
robert bristow-johnson
>
>
> robert bristow-johnson wrote:
>>
>> it would be nearly useless and horribly inelegant. unless i am just
>> not understanding your proposal, Bob.
>
> You seem to understand it, you just don't care for it. That's cool;
> there's no accounting for taste. :-)
>
> Have a good holiday. I'm sure that when your head clears you'll see it
> my way. Just kidding, just kidding!
i apologize if i'm treating this like some kind of jihad (hmmm, maybe it
*is* a jihad???). i'll put the machetes away now. :-/
> "Things should be described as simply as possible, but no simpler."
>
> A. Einstein
BTW, i really agree with you and Albert about this one. and have heard or
read other variations of this quote.
r b-j