1034 views

Skip to first unread message

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

--

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.

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.

Dec 11, 2001, 11:50:53 AM12/11/01

to

In article <3C162CEA...@bellsouth.net> , "Clay S. Turner"

<phy...@bellsouth.net> wrote:

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

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:

<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

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?

>

>

(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

---------------------------------------------------

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

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

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

>

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

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.

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

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?

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:

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

Dec 13, 2001, 7:33:36 AM12/13/01

to

In article <3C186A14...@znet.com>, Bob Cain <arc...@znet.com>

wrote:

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

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.

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?

>

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

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.

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

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.

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.

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

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!

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

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

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:

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.

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.

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.

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

--

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

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

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.

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

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:

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

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:

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.

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

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.

> 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

>

> --

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:

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

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>

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

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:

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.

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

---------------------------------------------------------------------

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

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

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.

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.

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:

(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

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.

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

Dec 15, 2001, 9:59:24 PM12/15/01

to

In article <3c1b949f....@news.earthlink.net> , eric.j...@ieee.org

(Eric Jacobsen) wrote:

(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

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

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

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

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.

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:

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/

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:

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

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

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.

>

> 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

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

>

...

> 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

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.

> 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

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.

> 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