have you noticed how MathWorks has responded to the horrible MATLAB indexing complaint?

1004 views
Skip to first unread message

robert bristow-johnson

unread,
Dec 11, 2001, 8:42:49 AM12/11/01
to

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

unread,
Dec 11, 2001, 10:57:30 AM12/11/01
to
Hello Robert,
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

unread,
Dec 11, 2001, 11:50:53 AM12/11/01
to
In article <3C162CEA...@bellsouth.net> , "Clay S. Turner"
<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

unread,
Dec 11, 2001, 11:05:11 PM12/11/01
to
On Tue, 11 Dec 2001 13:42:49 GMT, "robert bristow-johnson"
<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

unread,
Dec 12, 2001, 3:02:23 AM12/12/01
to
robert bristow-johnson a écrit :
>
(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

unread,
Dec 12, 2001, 2:52:55 PM12/12/01
to
> i know that there's Octave and Python
> (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

unread,
Dec 13, 2001, 2:52:19 AM12/13/01
to
Rick Armstrong a écrit :

>
> 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

unread,
Dec 13, 2001, 3:42:17 AM12/13/01
to
well, I don't use MatLab.. still sticking to maple.
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

unread,
Dec 13, 2001, 3:43:00 AM12/13/01
to
Robert, would you mind summarizing the issue under discussion with those
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:

http://www.intel.com/cure

\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\///////////////////////////////////////

Ken Prager

unread,
Dec 13, 2001, 7:33:36 AM12/13/01
to
In article <3C186A14...@znet.com>, Bob Cain <arc...@znet.com>
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

unread,
Dec 14, 2001, 11:50:18 AM12/14/01
to
In article <3C186A14...@znet.com> , Bob Cain <arc...@znet.com> wrote:

> 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

unread,
Dec 14, 2001, 1:19:24 PM12/14/01
to
>In article <3C186A14...@znet.com> , Bob Cain <arc...@znet.com> wrote:
>
>> 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

unread,
Dec 14, 2001, 3:18:42 PM12/14/01
to
In article <9vdfrc$52b$1...@news.mathworks.com> , mo...@acoma.mathworks.com
(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

unread,
Dec 14, 2001, 3:17:04 PM12/14/01
to

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

unread,
Dec 14, 2001, 4:29:44 PM12/14/01
to
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.
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

unread,
Dec 14, 2001, 8:24:10 PM12/14/01
to
In article <3C1A5E40...@znet.com> , Bob Cain <arc...@znet.com> 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.

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

unread,
Dec 14, 2001, 8:58:51 PM12/14/01
to

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

unread,
Dec 14, 2001, 9:35:26 PM12/14/01
to
Cleve Moler wrote:
> 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

unread,
Dec 15, 2001, 2:26:17 AM12/15/01
to
On 14 Dec 2001 18:19:24 GMT, mo...@acoma.mathworks.com (Cleve Moler)
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

unread,
Dec 15, 2001, 2:42:54 AM12/15/01
to

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

unread,
Dec 15, 2001, 8:39:35 AM12/15/01
to
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.

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

unread,
Dec 15, 2001, 9:47:05 AM12/15/01
to
Hi,

> 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

unread,
Dec 15, 2001, 12:00:03 AM12/15/01
to

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

unread,
Dec 15, 2001, 12:06:58 PM12/15/01
to
[ngs trimmed]
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

unread,
Dec 15, 2001, 12:51:24 PM12/15/01
to
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. 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

unread,
Dec 15, 2001, 1:26:46 PM12/15/01
to
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

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

unread,
Dec 15, 2001, 1:36:27 PM12/15/01
to
"Jordan Rosenthal" <jrs...@earthlink.net> wrote in message news:<JnJS7.4155$O7.4...@newsread2.prod.itd.earthlink.net>...

>
> 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

unread,
Dec 15, 2001, 1:58:59 PM12/15/01
to
John D'Errico <der...@flare.net> wrote in message news:<derrico-EAE573...@news.newsguy.com>...

> 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

unread,
Dec 15, 2001, 2:12:25 PM12/15/01
to
On Sat, 15 Dec 2001 17:51:24 GMT, stu...@slettdette.molden.net.invalid
(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

unread,
Dec 15, 2001, 2:13:43 PM12/15/01
to
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.

>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

unread,
Dec 15, 2001, 2:30:33 PM12/15/01
to
On 15 Dec 2001 19:13:43 GMT, mo...@acoma.mathworks.com (Cleve Moler)
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

unread,
Dec 15, 2001, 3:09:54 PM12/15/01
to
Cleve Moler 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 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

unread,
Dec 15, 2001, 4:14:50 PM12/15/01
to

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

unread,
Dec 15, 2001, 5:36:18 PM12/15/01
to
Hi,

> 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

unread,
Dec 15, 2001, 5:14:44 PM12/15/01
to

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

unread,
Dec 15, 2001, 5:16:07 PM12/15/01
to

"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

unread,
Dec 15, 2001, 8:39:45 PM12/15/01
to
In article <9vg7d7$g7n$1...@news.mathworks.com> , mo...@acoma.mathworks.com
(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

unread,
Dec 15, 2001, 8:04:14 PM12/15/01
to
Cleve Moler 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.

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

unread,
Dec 15, 2001, 9:38:45 PM12/15/01
to
In article <3C1BCB54...@znet.com> , Bob Cain <arc...@znet.com> wrote:

>
>
> 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

unread,
Dec 15, 2001, 9:59:24 PM12/15/01
to
In article <3c1b949f....@news.earthlink.net> , eric.j...@ieee.org
(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

unread,
Dec 16, 2001, 12:26:43 AM12/16/01
to

"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

unread,
Dec 16, 2001, 12:43:43 PM12/16/01
to
Hi,

> 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

unread,
Dec 16, 2001, 2:14:49 PM12/16/01
to
On Sat, 15 Dec 2001 15:09:54 -0500, Jerry Avins <j...@ieee.org> wrote:


>
>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

unread,
Dec 16, 2001, 2:58:15 PM12/16/01
to

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

unread,
Dec 16, 2001, 3:50:59 PM12/16/01
to
On 15 Dec 2001 19:13:43 GMT, mo...@acoma.mathworks.com (Cleve Moler)
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

unread,
Dec 16, 2001, 4:06:59 PM12/16/01
to
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.

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

unread,
Dec 16, 2001, 4:37:00 PM12/16/01
to

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

unread,
Dec 16, 2001, 10:45:07 PM12/16/01
to
NotMyEma...@Ameritech.net (Matthew C Roberts) wrote in message news:<3c1cf28d...@news.col.sbcglobal.net>...

>
> 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

unread,
Dec 17, 2001, 12:11:16 AM12/17/01
to
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>.

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

unread,
Dec 17, 2001, 1:01:17 AM12/17/01
to
Bob Cain <arc...@znet.com> wrote in message news:<3C1CFCD7...@znet.com>...

> 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

unread,
Dec 17, 2001, 1:16:02 AM12/17/01
to
l...@2-control.dk (Lars Gregersen) wrote in message news:<3c1d0bb5...@news.cybercity.dk>...

> 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

unread,
Dec 17, 2001, 12:12:36 PM12/17/01