Dijkstra has died, and "Why Numbering Should Start At Zero"
robert bristow-johnson
Jerry Avins wrote:
>
> Randy Yates wrote:
> >
> > Robert,
> >
> > You may be able to use this for your argument against the
> > Mathworks:
> >
> > EWD831. Why numbering should start at zero, Edsger W. Dijkstra
> >
> > @unpublished{EWD:EWD831,
> > author = "Edsger W. Dijkstra",
> > title = "Why numbering should start at zero",
> > month = aug,
> > year = "1982",
> > note = "circulated privately",
> > url = "http://www.cs.utexas.edu/users/EWD/ewd08xx/EWD831.PDF",
> > fileSize = 93 KB
> > }
>
> Thank you. I don't own Matlab and barely understand it. I will let
> R.B-J. carry this ball. I'm sure he thanks you too.
i do (thank you Randy). but i, too, do not want MATLAB to become
backward incompatible. i just want a backward-compatible extension that
would allow users to change the indexing base from 1 to any other
reasonable integer.
certainly when MATLAB was first created, it would have been nice if
Cleve had thought more about the future and mathematical elegance that
Dennis Ritchie had when creating C. Ritchie understood that C was
counting differently than Fortran (which may have drawn some complaints
from the Fortran types when they were faced with porting old Fortran
code to C) but he knew it was better, not just because the CPUs counted
from zero, but *why* they did.
if MATLAB was to have a hard-wired indexing base, it certainly would
have been better if Cleve Moler would have departed from the existing
Applied Matrix Theory and Linear Algebra textbooks and used (0,0) for
the upper left corner. (who knows? perhaps in 10 or 20 years, virtually
all the texts would be written or revised to use 0,0 for the upper left
corner of a matrix!) but he didn't and that's really not so bad since
what the *true* lacking with MATLAB is that we cannot create our own
arrays and give them whatever integer indexing base we desire. if
MATLAB did that, the "1" guys can have their 1-based arrays and us "0"
guys can have our 0-based arrays. and the crazy dudes like me can have
our -1024 based arrays.
that's what i really want. i want to be able to represent a
discrete-time signal that has both positive and negative indices. i
want to be able to represent non-causal impulse responses. but, also,
what is most important, i want H[0] to have index 0 and h[0] to have
index zero and, long ago, when fft() and ifft() were first developed and
later, when the Signal Processing Toolbox (the very first MATLAB
toolbox, IIRC) was first developed, i just cannot understand why there
weren't deafeningly loud alarm bells going off in Cleve's head (about
why his MATLAB indices were all off by 1) or, if they were clanging
away, why he ignored them. that is truly unfathomable to me.
now we have to live with it, but that too is unnecessary. after
repeatedly telling these guys how they could define this extension, and
why it would be truly backward compatible, and finally, why it is
exactly the right thing to do technically, still nothing happens.
i'll add a new twist: i will bet Cleve (or some other single person)
$10,000 (i think i could save that up in 10 years) *if* Mathworks truly
makes this enhancement to MATLAB (i get input to its definition so i
know they do it right), that at the time of 10 years after this
enhancement is released (and all future versions must retain this
enhancement), that the 0-based (or user assigned base) versions of fft()
and ifft() and conv() (and perhaps polyval() and polyfit() etc) will
exceed the older 1-based versions in frequency of usage. if that's what
it would take to get them to take this seriously, i will start saving
$1000/year so i can make good on this wager (of which i am confident
that i would win).
if they made this enhancement, people (even the current detractors on
comp.soft-sys.matlab) would start using it in appropriate places in
their new code, and after 10 years MATLAB announced that they would yank
this enhancement out of MATLAB, there would be enough outcry that there
may be fires in Natick. there is no defensible technical reason not to
do it. it is only corporate inertia due to, frankly, a lack of vision
regarding this problem.
BTW, Jerry, Randy and other comp.dspers, when this MATLAB indexing
subject comes up on comp.dsp, please cross-post it right away on
comp.soft-sys.matlab . every time. i don't think the majority of those
guys over there have a clue about how ugly this problem is for us guys
over here. *if* every time this comes up as a serious topic (poking fun
or a comp.dsp inside joke is another matter) we cross-post it, there
will be less of a reason for the comp.soft-sys.matlab regulars and TMW
engineers/scientists and particularly Cleve Moler (whom i doubt visits
comp.dsp all that often) to blissfully conclude that this is just a
small and isolated complaint.
--
r b-j
r...@surfglobal.net a.k.a. rob...@wavemechanics.com
"Don't give in to the Dark Side. Boycott intel and microsoft."
Cris Luengo
> if MATLAB was to have a hard-wired indexing base, it certainly would
> have been better if Cleve Moler would have departed from the existing
> Applied Matrix Theory and Linear Algebra textbooks and used (0,0) for
> the upper left corner.
Why the upper left corner? I would like to index the LOWER left corner
by (0,0). That way, indices grow to the left and up, like coordinates
in a pair of axes do. It is a shame that in image processing it has
become custom to index the upper left corner by (0,0). It is really
confusing to have angles growing clock-wise!
Cris.
Julius Kusuma
> Why the upper left corner? I would like to index the LOWER left corner
> by (0,0). That way, indices grow to the left and up, like coordinates
> in a pair of axes do. It is a shame that in image processing it has
> become custom to index the upper left corner by (0,0). It is really
> confusing to have angles growing clock-wise!
>
> Cris.
>
maybe it has something to do with the fact that we write from left to
write, top to bottom. if you're writing entries like in a table, starting
from the bottom left instead of top left requires that you have some idea
on advance of how many rows you'll end up with.
just a guess ;-).
julius
--
The most rigorous proofs will be shown by vigorous handwaving.
http://www.mit.edu/~kusuma
opinion of author is not necessarily of the institute
robert bristow-johnson
i understand some of the sentiment, but matrices ain't coordinate plains.
for textbooks to gradually adopt (0,0) for the zeroth element because MATLAB
did it from the beginning and became wildly successful and authors wanted to
change the common convention to align themselves to MATLAB has some is a
fantasy that requires less suspension of disbelief than for those texts to
flip their matrices upside down following MATLAB's lead.
the shame is that of a DSP textbook changing its definition of discrete
convolution or the DFT so that they can be the same as MATLAB. that's just
dumb.
In article
Pine.GSO.4.30L.02081...@department-of-alchemy.mit.edu,
Julius Kusuma at kus...@mit.edu wrote on 08/12/2002 08:37:
>
> maybe it has something to do with the fact that we write from left to
> write, top to bottom. if you're writing entries like in a table, starting
> from the bottom left instead of top left requires that you have some idea
> on advance of how many rows you'll end up with.
>
> just a guess ;-).
>
a pretty good one.
r b-j
robert bristow-johnson
wrote on 08/12/2002 11:19:
> robert bristow-johnson wrote:
>>
>> amoli...@visi-dot-com.com wrote:
>>>
>>> With all due respect to Dijkstra, whose contributions are very
>>> real and worthy, this paper is classic Dijkstra flim-flam.
...
>>> I want indices to begin at 0 too, but I want them that way
>>> because C works that way, and I like C, and I don't like things
>>> that work differently.
>>
>> why does C start at 0? why do the machines (CPUs) start at zero? it's
>> easier, that's why. for some of the same reasons Dijkstra stated
>> (among others that i can think of).
>
> Machines also have jump (go to) instructions. Another Dijkstra aesthetic
> was against the use of the go-to statement.
Ritchie appears have had the same aesthetic. even though C provides a goto,
K&R say that it's almost always cleaner to write code without it (so program
flow is determined by group statements into compound statements and using
the if, else, while, for, and the kinda ugly switch). personally if i want
to break out of a nastily nested loop prematurely (or even one that is not
nested) i would prefer using the goto over the "break" keyword. but goto
should be rare in usage.
anyway, i see no reason for machines to do condition and unconditional
jumps/branches except by use of a simple jump or branch instruction, but
perhaps it would be nice if assemblers had an assembler directive that
allowed you to plop down an equivalent to {} or BEGIN .. END and have IF,
ELSE and WHILE constructs support that. but then it starts to look like C
and then you think why the hell not just do it in C.
long ago i first learned to code on the Mot 6800 but later learn how the
6502 (what was used in Apples and Commadores) worked. it's when i first
experienced the difference between big-endian and little-endian. the Mot
did big-endian which looked better when staring at hex machine code but the
little-endian actually worked better (saved a machine cycle). the 6502 also
had another difference from the 6800 that i later figgered out was better.
in the 6800 the Carry bit was set for carry _or_ borrow (for chained
subtraction). in the 6502 the Carry bit was the same as 6800 for addition
but opposite for subtraction. when there was no borrow in a 6502 subtract,
the Carry bit was set and it was cleared for borrow. that actually made for
a simpler machine. (and hell, saving those 10 square microns to save an
inverter gate or two was vitally important :-) however the 6502 was stupid
for not having a simple ADD and SUB instruction that ignored the carry bit
(which you always had to clear or set before their ADC and SBC).
nonetheless, it still doesn't excuse MATLAB for calling the DC output of the
DFT "H(0)". that is still inexcusable.
--
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
--
Jerry Avins
>
...
>
> anyway, i see no reason for machines to do condition and unconditional
> jumps/branches except by use of a simple jump or branch instruction, but
> perhaps it would be nice if assemblers had an assembler directive that
> allowed you to plop down an equivalent to {} or BEGIN .. END and have IF,
> ELSE and WHILE constructs support that. but then it starts to look like C
> and then you think why the hell not just do it in C.
>
packages for various assemblers that implement IF THEN ELSE, DO WHILE
UNTIL, and other structures. I have used them in 1802, Z-80, 68000, and
PDP-11, and they are standard in Forth assemblers.
...
Jerry
--
Engineering is the art of making what you want from things you can get.
ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ
robert bristow-johnson
08/12/2002 12:35:
> robert bristow-johnson wrote:
>>
> ...
>>
>> anyway, i see no reason for machines to do condition and unconditional
>> jumps/branches except by use of a simple jump or branch instruction, but
>> perhaps it would be nice if assemblers had an assembler directive that
>> allowed you to plop down an equivalent to {} or BEGIN .. END and have IF,
>> ELSE and WHILE constructs support that. but then it starts to look like C
>> and then you think why the hell not just do it in C.
>>
> I don't see why you think it starts to look like C. There are many macro
> packages for various assemblers that implement IF THEN ELSE,
i've seen this for *conditional* assembly (what was being tested by the IF
was a constant that was resolved before compilation or assembly).
> DO WHILE UNTIL, and other structures.
i haven't seen *that* in assembler and i've coded the Z80 a teeny-weeny bit
and the 68K a whole lot. maybe it was the development packages i was using:
C compiler with asm{} extension. (actually, now that i think of it, i was
hand-assembling Z80 code for a cute little kit called the "Microprofessor".
that was a pretty miserable experience.)
> I have used them in 1802, Z-80, 68000, and
> PDP-11, and they are standard in Forth assemblers.
i thought Forth was a high-level language. wouldn't you call it a "Forth
compiler"?
>
> ...
>
whatever. i dunno nuthin', Jerry.
r b-j
Jerry Avins
>
...
>
> i thought Forth was a high-level language. wouldn't you call it a "Forth
> compiler"?
>
sidetracked) to begin the definition of a word. Once defined, they are
indistinguishable in use.
A colon definition: : <name> <Forth words*> ;
A code definition: CODE <name> <assembler words* ENDCODE
* including structure generators
Code definitions can be faster, but you need to be on your toes to beat
an optimizing native-code compiler). Sometimes they are easier to write.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
robert bristow-johnson
at usene...@eeyore.demon.co.uk wrote on 08/12/2002 14:15:
> In article <3D56F882...@surfglobal.net>, r...@surfglobal.net says...
>>
>> amoli...@visi-dot-com.com wrote:
>>>
>>> In article <3D55B0F1...@ieee.org>, Randy Yates <ya...@ieee.org>
>>> wrote:
>>>> Robert,
>>>> @unpublished{EWD:EWD831,
>>>> author = "Edsger W. Dijkstra",
>>>> title = "Why numbering should start at zero",
>
>> why does C start at 0? why do the machines (CPUs) start at zero? it's
>> easier, that's why. for some of the same reasons Dijkstra stated
>> (amoung others that i can think of).
>
> C starts at zero because B started at zero. B started at zero because BCPL
> started as zero. BCPL started at zero because it was devised by assembler
> programmers.
as assembler programmers used if for what reason?
> None of this is numbering. It is addressing. Addressing should start at
> zero.
some addresses are purely symbolic. but when they are numerical, i would
say the conceptual line between "numbering" and "addressing" is faded.
> Counting (a word with a strong hint of cardinal numbers) naturally starts at
> one, but admits zero in case there's nothing to count.
>
> Numbering (a word with a strong hint of ordinal numbers) starts at one and
> doesn't admit zero. The concept of the zeroth person to run a mile in under
> four minutes doesn't make sense.
i know that. it's what we called "counting numbers" in grade school or jr.
high (what they now call "middle school").
IIRC: "counting numbers" = positive integers
"whole numbers" = non-negative integers = 0 + "counting numbers"
then they teach you about negatives integers and absolute value. then
fractions and rational numbers, and then multivariate calculus.
i agree, from a user interface POV, that counting numbers should usually
start at 1 and if those get mapped to a address (where is the date stored
for the nth person who ran a mile under 4 minutes?) then, IMHO (notice not
"IMNHO"), it's good form in C to take that positive integer that came from
the UI and subtract one to get the index (n-1) to look up data for it. this
is not uncommon, at least for code that i've seen. (another option is to
allocate N+1 elements, use n and leave the 0th one empty and never use it.
another is to allocated N elements, use n, and offset the pointer to the
array, and die a miserable death if anyone should access the 0th element.)
i dunno, it still doesn't excuse MATLAB for calling DC "H(1)" when everybody
knows it's "H(O)". and i still think the Dijkstra, while not worthy of
publication in a journal except as, say, one position in a big debate about
this issue, was still pretty well written and logically put forth.
--
r b-j
robert bristow-johnson
In article B97D80B4.68A7%rob...@wavemechanics.com, robert bristow-johnson at
rob...@wavemechanics.com wrote on 08/12/2002 15:11:
> In article 1029176149.27017....@news.demon.co.uk, Ian Kemmish
> at usene...@eeyore.demon.co.uk wrote on 08/12/2002 14:15:
>
>> In article <3D56F882...@surfglobal.net>, r...@surfglobal.net says...
>>>
>>> amoli...@visi-dot-com.com wrote:
>>>>
>>>> In article <3D55B0F1...@ieee.org>, Randy Yates <ya...@ieee.org>
>>>> wrote:
>>>>> Robert,
>>>>> @unpublished{EWD:EWD831,
>>>>> author = "Edsger W. Dijkstra",
>>>>> title = "Why numbering should start at zero",
>>
>>> why does C start at 0? why do the machines (CPUs) start at zero? it's
>>> easier, that's why. for some of the same reasons Dijkstra stated
>>> (amoung others that i can think of).
>>
>> C starts at zero because B started at zero. B started at zero because BCPL
>> started as zero. BCPL started at zero because it was devised by assembler
>> programmers.
>
> as assembler programmers used if for what reason?
i meant to type: "and assembler programmers used it for what reason?"
duh.
Andrew Reilly
> In article 3D57E3C7...@ieee.org, Jerry Avins at j...@ieee.org wrote
> on 08/12/2002 12:35:
>
>> robert bristow-johnson wrote:
>>>
>> ...
>>>
>>> anyway, i see no reason for machines to do condition and unconditional
>>> jumps/branches except by use of a simple jump or branch instruction,
>>> but perhaps it would be nice if assemblers had an assembler directive
>>> that allowed you to plop down an equivalent to {} or BEGIN .. END and
>>> have IF, ELSE and WHILE constructs support that. but then it starts
>>> to look like C and then you think why the hell not just do it in C.
>>>
>> I don't see why you think it starts to look like C. There are many
>> macro packages for various assemblers that implement IF THEN ELSE,
>
> i've seen this for *conditional* assembly (what was being tested by the
> IF was a constant that was resolved before compilation or assembly).
>
>> DO WHILE UNTIL, and other structures.
>
> i haven't seen *that* in assembler and i've coded the Z80 a teeny-weeny
> bit and the 68K a whole lot. maybe it was the development packages i
> was using: C compiler with asm{} extension. (actually, now that i think
> of it, i was hand-assembling Z80 code for a cute little kit called the
> "Microprofessor". that was a pretty miserable experience.)
I thought that you did Motorola 56k? The (exelent IMO) Moto
assembler has always had a lovely set of structure "macros" that
are implemented in the assembler, rather than as a macro
package. Just as in C, I hardly ever use a named branch target.
(The main use would be the bit-test-and-branch instructions,
which the macros won't generate.)
The big advantage of structured control macros/statements has
nothing to do with Dijkstra or aesthetics. It saves you from
having to (pointlessly) think of a name for the target location.
In my mind, naming things is difficult, and should be avoided.
My first assembler was MACRO-80, on a z-80 (in 1980!). It
didn't have structure macros built in, but it had a _good_
assembler-time macro processor, and you could build your own,
and I did. Using the macro facility itself meant that you had
to implement the stack of target addresses manually, and that
usually meant that you had to limit the depth, but nesting is
not usually terribly deep.
I really miss the kind of macro facility that assemblers usually
have, when I code in C. Standard cpp just doesn't cut it.
--
Andrew
Robert Malek
The matrix stuff is clear for me:
even many mathematicians started counting with their fingers.
Did anybody see/hear someone counting with his fingers
"zero, one, ...."? So most things that don't happen in
computers or have to be thought about twice start with one.
The matlab problem doesn't disturb me, I don't use it.
I really like the maple feature that allows arrays to have any
indexing, for example from 15 to 92 in steps of 7 ... or a
fibonacci sequence, or...
until one starts using library functions. The FFT unfortunately
requires one based single spaced arrays, other functions assume
zero based arrays.. positive expression would be "oh yes, a
grown language"
My expression is "no one took the responsibility for tidying
up the libraries and toolboxes".
I guess it is the same with MATLAB. There is no inherent
necessity to assume any special indexing for an FFT input at all.
The system could take care of that.
Robert
Jim Thomas
>
> The big advantage of structured control macros/statements has
> nothing to do with Dijkstra or aesthetics. It saves you from
> having to (pointlessly) think of a name for the target location.
> In my mind, naming things is difficult, and should be avoided.
In my mind, naming things is the most enjoyable part of design. A well
chosen name can illuminate, while a poorly chosen name can obfuscate.
In software we get to name all kinds of things - labels, functions,
variables, types, etc. I haven't done hardware in a while, but there
you get to name stuff too (more so now that VHDL is in common use).
I will concede that sometimes you *do* have to come up with pointless
names, and perhaps you are referring to those situations (e.g. the label
for a one-instruction "do loop" terminus).
--
Jim Thomas Principal Applications Engineer Bittware, Inc
jth...@bittware.com http://www.bittware.com (703) 779-7770
A pessimist is an optimist with experience
Jerry Avins
Please read my rant about "structured assembly programming" --
http://users.erols.com/jyavins/tantrum.htm -- and let me know if part of
it addresses your point.
Jerry
--
Engineering is the art of making what you want from things you can get.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
Cris Luengo
>>started as zero. BCPL started at zero because it was devised by assembler
>>programmers.
>
> as assembler programmers used if for what reason?
Because array[ii] is the same as *(array+ii) . (Similar notation in assembler.)
IMO, which indexing system should be used depends on the application. Sometimes
0 is better. Sometimes 1 is better. Sometimes -128 is better.
Cris.
Randy Yates
I think which index system is better depends on the PROBLEM and
the LANGUAGE should allow either.
--
Randy Yates
DSP Engineer, Sony Ericsson Mobile Communications
Research Triangle Park, NC, USA
randy...@sonyericsson.com, 919-472-1124
Steve Amphlett
chippers-in! Do you reckon they're developing their killer argument?
Or are they just sitting pretty, knowing that their obviously flawed
product has market share on its side?
- Steve
Scott Seidman
news:2ae8f62b.02081...@posting.google.com:
Maybe they just have more valuable things to do with their time.
--
Scott
Reverse first field of address to reply
Peter Boettcher
samp...@ricardo.com (Steve Amphlett) writes:
I suspect their argument has not changed since the last 10 discussions
on the topic. Search google if you want TMW chipping-in.
--
Peter Boettcher <boet...@ll.mit.edu>
MIT Lincoln Laboratory
MATLAB FAQ: http://www.mit.edu/~pwb/cssm/
AJ "no z" Johnson
news:2ae8f62b.02081...@posting.google.com...
...or maybe they are too busy adding an "Index Origin" property to array
constructs. One can only hope. I hope it's obvious which court I'm in.
This being the first indexing thread that *I've* read, I am curious what
other languages support definable indexing origins?
For sure:
- Maple (don't know much about it, though)
- Pascal, IIRC
- APL (choice of 0 or 1 only)
- C (array indexing is so loose that one can implement non-zero based
indexing, but it is geneally considered bad coding practice)
- Ada
- TCL, REXX (Being text-based, there is no true numeric indexing of arrays;
it's symbolic)
I guess everyone has their Matlab wish list... I know I do. And to be fair,
I think Mathworks has gone a long way to meeting customer demands, which is
why it's such a comprehensive product now. If only they'd add *my* stuff...
:-)
Aj
robert bristow-johnson
boet...@ll.mit.edu wrote on 08/14/2002 09:11:
>
> samp...@ricardo.com (Steve Amphlett) writes:
>
>> Oh well guys, the thread's now four days old and still no TMW
>> chippers-in! Do you reckon they're developing their killer argument?
>> Or are they just sitting pretty, knowing that their obviously flawed
>> product has market share on its side?
hey Cleve, i don't know Steve at all so it cannot be said i put him up to
say this.
> I suspect their argument has not changed since the last 10 discussions
> on the topic.
what argument was that???
> Search google if you want TMW chipping-in.
they did not answer either the complaints or the suggestions i put forth.
they (essentially Cleve) *did* respond, it was just a couple of times and he
did not answer the complaints nor refute the suggested fix that i proposed.
again, here is the basic complaint that TMW simply will not touch. they
will not fix it nor will they even acknowledge it:
From: robert bristow-johnson <rob...@wavemechanics.com>
Subject: Here is exactly why MATLAB's fixed 1-based indexing is wrong.
Newsgroups: comp.dsp, comp.soft-sys.matlab
Date: 2001-12-14 11:50:19 EST
...
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 us 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).
...
Peter J. Acklam
> This being the first indexing thread that *I've* read, I am curious what
> other languages support definable indexing origins?
> For sure:
> - Maple (don't know much about it, though)
> - Pascal, IIRC
> - APL (choice of 0 or 1 only)
> - C (array indexing is so loose that one can implement non-zero based
> indexing, but it is geneally considered bad coding practice)
> - Ada
> - TCL, REXX (Being text-based, there is no true numeric indexing of arrays;
> it's symbolic)
You can change the array base in Perl by setting the $[ variable.
> I guess everyone has their Matlab wish list... I know I do.
Variable index base is not on _my_ MATLAB wish list. :-)
Peter
--
~/.signature: No such file or directory.
Peter Boettcher
> In article tr3cth3...@coyote.llan.ll.mit.edu, Peter Boettcher at
> boet...@ll.mit.edu wrote on 08/14/2002 09:11:
>
>> I suspect their argument has not changed since the last 10 discussions
>> on the topic.
>
> what argument was that???
I'm not going to continue the discussion. I would just be repeating
lots of words from Dec 2001. I didn't say the arguments had all the
answers or defended against all your points or anything else. I DID
imply that the arguments probably have not changed since then. BTW,
"It would take us too long to implement correctly" is a valid argument
for a business. This is the feeling I get, even if I can't point to
the words that say exactly this.
Cleve Moler
> Oh well guys, the thread's now four days old and still no TMW
> chippers-in! Do you reckon they're developing their killer argument?
> Or are they just sitting pretty, knowing that their obviously flawed
> product has market share on its side?
robert bristow-johnson <rob...@wavemechanics.com> wrote:
> hey Cleve, i don't know Steve at all so it cannot be said i put him up to
> say this.
> they did not answer either the complaints or the suggestions i put forth.
> they (essentially Cleve) *did* respond, it was just a couple of times and he
> did not answer the complaints nor refute the suggested fix that i proposed.
> again, here is the basic complaint that TMW simply will not touch. they
> will not fix it nor will they even acknowledge it:
OK, at the risk of prolonging this discussion, here I am again.
But if the discourse continues in the above vein, we'll all tune out again.
Below is one example of an important function in our math library.
It's not a DSP function, but it is central to much of scientific and
engineering computation. I have one basic question:
How would you change this function to accomodate a scheme
where array subscripts do not start at 1?
If we get a reasonable answer to this question, then we'll consider
the task of applying that approach to the thousands of functions
that this one represents.
function [L,U,p] = lutx(A)
%LUTX Triangular factorization, textbook version
% [L,U,p] = lutx(A) produces a unit lower triangular matrix L,
% an upper triangular matrix U and a permutation vector p,
% so that L*U = A(p,:)
[n,n] = size(A);
p = (1:n)';
for k = 1:n-1
% Find index of largest element below diagonal in k-th column
[r,m] = max(abs(A(k:n,k)));
m = m+k-1;
% Skip elimination if column is zero
if (A(m,k) ~= 0)
% Swap pivot row
if (m ~= k)
A([k m],:) = A([m k],:);
p([k m]) = p([m k]);
end
% Compute multipliers
i = k+1:n;
A(i,k) = A(i,k)/A(k,k);
% Update the remainder of the matrix
j = k+1:n;
A(i,j) = A(i,j) - A(i,k)*A(k,j);
end
end
% Separate result
L = tril(A,-1) + eye(n,n);
U = triu(A);
-- Cleve
mo...@mathworks.com
robert bristow-johnson
mo...@mathworks.com wrote on 08/14/2002 17:20:
> samp...@ricardo.com (Steve Amphlett) writes:
>
>> Oh well guys, the thread's now four days old and still no TMW
>> chippers-in! Do you reckon they're developing their killer argument?
>> Or are they just sitting pretty, knowing that their obviously flawed
>> product has market share on its side?
>
> robert bristow-johnson <rob...@wavemechanics.com> wrote:
>> hey Cleve, i don't know Steve at all so it cannot be said i put him up to
>> say this.
>> they did not answer either the complaints or the suggestions i put forth.
>> they (essentially Cleve) *did* respond, it was just a couple of times and he
>> did not answer the complaints nor refute the suggested fix that i proposed.
>> again, here is the basic complaint that TMW simply will not touch. they
>> will not fix it nor will they even acknowledge it:
>
> OK, at the risk of prolonging this discussion, here I am again.
> But if the discourse continues in the above vein, we'll all tune out again.
>
> Below is one example of an important function in our math library.
> It's not a DSP function, but it is central to much of scientific and
> engineering computation. I have one basic question:
>
> How would you change this function to accomodate a scheme
> where array subscripts do not start at 1?
I will look at this to see if makes any sense for this to be extended for
arrays that do not have subscripts (1,1) in the upper left corner. Since
matrix triangular factorization is usually something I associate with
matrices (which i believe we agree are "special" arrays that have something
to do with systems of equations and the like), I am not sure that it *does*
make any sense for this function to accommodate an array that are not a
matrix.
> If we get a reasonable answer to this question, then we'll consider
> the task of applying that approach to the thousands of functions
> that this one represents.
even if there is no reasonable way to extend the the definition of LUTX to
arrays with some other indexing base, I believe this general answer is
perfectly reasonable:
"All matrix operations that can only be defined for 1-based matrices shall
cause a run-time error when passed an array with any dimension with base not
equal to 1."
kinda like saying:
翠 = [1 1; 1 0; 0 1]
A =
1 1
1 0
0 1
蜴nv(A)
??? Error using ==> inv
Matrix must be square.
Does it make sense, Cleve, that inv() be somehow extended to accommodate
non-square matrices? So, what would be unreasonable to expect anything
different from *matrix* functions, expecting 1-based matrices, to behave
differently when they are passed non-1-based arrays?
Now, even so:
> function [L,U,p] = lutx(A)
> %LUTX Triangular factorization, textbook version
since LUTX is not defined on our (old) version of MATLAB i am presuming it
is the same as LU:
[L,U] = lu(A)
In the last round of discussion, I proposed a perfectly reasonable way for
matrix multiplication to be extended for non-1-based arrays:
http://groups.google.com/groups?selm=_CxS7.2384%24BK.1426%40nwrddc02.gnilink
.net (unwrap line)
A = B*C
Currently the number of columns of B must equal the number of rows of C.
The user-definable base extension would additionally require that the base
index of the rows of B must equal the base index of the columns of C.
The result A would have the same number of rows as B and the same number of
columns as C. The user-definable base extension would also set the base
index of the columns of A to be the same as B and the base index of the rows
of A to be the same as C.
Perhaps a simple way of looking at it for some would be, the base-extended
matrix multiply operation would first check if the above requirements in the
number of rows and columns were satisfied and the same for the common index
base. If not, a run-time error is returned. If yes, then the index base
values are noted, the bases for B and C are changed to 1, the normal MATLAB
matrix multiply is performed (resulting in A having bases of 1) and the
bases of A are adjusted to fit the rule above. Pretty simple and a similar
rule can be done for matrix division.
Now back to LU decomposition:
[L,U] = lu(A)
As before, A would have to be a square matrix. Since A = L*U then, as
above, the base index of the columns of L must be the same as A and the base
index of the rows of U must be the same as A. To be compatible with
existing MATLAB, the base index of the rows of L and the base index of the
columns of U would both have to be 1.
So the extension to LU first notes the bases of A, then conceptually
converts the bases to 1, then does the currently existing LU (or LUTX)
operation, then adjusts the base index of the columns of L and the base
index of the rows of U to be what they were originally for A.
Is that not a reasonable answer, Cleve? It defines the extension in a
meaningful way that naturally defaults to the current way MATLAB does things
when all index bases are 1. It is *not* an implementation but, that can
come later, once the definition is settled.
I think it is a reasonable answer. Besides responding to that, what about
my $10,000 bet, Cleve? I have no doubt that you are good for it, and I can
be in 10 years when it will be known who wins.
Respectfully,
robert bristow-johnson
>
> "Steve Amphlett" <samp...@ricardo.com> wrote in message
> news:2ae8f62b.02081...@posting.google.com...
> > Oh well guys, the thread's now four days old and still no TMW
> > chippers-in! Do you reckon they're developing their killer argument?
> > Or are they just sitting pretty, knowing that their obviously flawed
> > product has market share on its side?
> >
> > - Steve
>
> ...or maybe they are too busy adding an "Index Origin" property to array
> constructs. One can only hope. I hope it's obvious which court I'm in.
it's nice to feel less alone. when i first brought this up, it seemed
like everyone, except a few comp.dsp regulars, thought i was goofy.
> This being the first indexing thread that *I've* read, I am curious what
> other languages support definable indexing origins?
> For sure:
> - Maple (don't know much about it, though)
> - Pascal, IIRC
> - APL (choice of 0 or 1 only)
> - C (array indexing is so loose that one can implement non-zero based
> indexing, but it is geneally considered bad coding practice)
i don't consider it bad coding practice, at all. i used to do this:
double _my_dummy_array1[1024];
double my_array[1];
double _my_dummy_array2[1024];
for (k=-1024; k<=1024; k++)
{
do_something_with( my_array[k] );
}
****but i was thoroughly chewed out for that since there was no way to
guarantee that the compiler would put the arrays together like that.
but if you do:
double *_my_dummy_array = (double *)malloc(2049*sizeof(double));
double *my_array = _my_dummy_array + 1024;
for (k=-1024; k<=1024; k++)
{
do_something_with( my_array[k] );
}
****that should be perfectly acceptable coding practice.
> I think Mathworks has gone a long way to meeting customer demands, which is
> why it's such a comprehensive product now. If only they'd add *my* stuff...
elegance, consiseness, and simplicity is more important to me than
everything with the kitchen sink. i use very few of the huge set of
MATLAB functions. i just want them to work correctly.
Jerry Avins
>
> This being the first indexing thread that *I've* read, I am curious what
> other languages support definable indexing origins?
> For sure:
> - Maple ...
> - Pascal, IIRC
> - APL (choice of 0 or 1 only)
> - C ...
> - Ada
> - TCL, REXX ...
>
...
Forth. Arrays are library functions. It's not hard to write one.
Peter J. Acklam
> AJ \"no z\" Johnson wrote:
>
> > - C (array indexing is so loose that one can implement
> > non-zero based indexing, but it is geneally considered bad
> > coding practice)
>
> i don't consider it bad coding practice, at all. i used to do
> this: [...]
Sure there are cases where a different array base is conveninent,
but that doesn't change the fact that it is _generally_ considered
bad coding practice to use an array base other than the default.
Cris Luengo
> Sure there are cases where a different array base is conveninent,
> but that doesn't change the fact that it is _generally_ considered
> bad coding practice to use an array base other than the default.
Generally by who?
(according to my dictionary:
"It is believed that" means "I think"
"It is generally believed that" means "A couple of other guys think so, too"
)
Anyway, "good coding practice" is heavily overrated. "don't use
globals", "use hungarian notation", "don't use hungarian notation",
"don't use variable names that are too short", "don't use variable
names that are too long", "comment all your code", "don't over-comment
your code", "don't use goto's". I'm sick of these rules. You never
know which ones to adhere to and why. Sometimes programs become too
complex or difficult to read because of these. A good program is one
that is simple and easy to read. If you need comments for that, ok.
If you need global variables for that, ok. A small independent
program can use globals; it makes it much simpler. If you need to
index an array starting at 2351354 because it makes all the code
look so much more like your original formulas, do it. But stop
telling other people how to write their programs, unless you you need
to read them but can't.
I'm belong to the group of people that would like MATLAB to have
user-definable array bounds. My life would be easier. But, as other
improvements I suggested, I don't think we'll ever have them. It
looks like they only change things they themselves are unconfortable
with, like the error messaging system (which was perfectly acceptable
IMO) or the logical flag.
Cris.
Allan Herriman
<aj.jo...@lmco.com> wrote:
>"Steve Amphlett" <samp...@ricardo.com> wrote in message
>news:2ae8f62b.02081...@posting.google.com...
>> Oh well guys, the thread's now four days old and still no TMW
>> chippers-in! Do you reckon they're developing their killer argument?
>> Or are they just sitting pretty, knowing that their obviously flawed
>> product has market share on its side?
>>
>> - Steve
>
>...or maybe they are too busy adding an "Index Origin" property to array
>constructs. One can only hope. I hope it's obvious which court I'm in.
>This being the first indexing thread that *I've* read, I am curious what
>other languages support definable indexing origins?
>For sure:
>- Maple (don't know much about it, though)
>- Pascal, IIRC
>- APL (choice of 0 or 1 only)
>- C (array indexing is so loose that one can implement non-zero based
>indexing, but it is geneally considered bad coding practice)
>- Ada
>- TCL, REXX (Being text-based, there is no true numeric indexing of arrays;
>it's symbolic)
VHDL (and ADA too, I guess). Arrays can be indexed by just about
anything that can be converted to an integer, e.g. enumerated types
But an array can also have an ascending or a descending range, and the
semantics are different! E.g.
whatever(0 to 7); -- ascending range
or
whatever(14 downto -3); -- descending range
or
whatever(yellow to blue); -- ascending range (enum. type as index)
There are attributes for returning the size:
'left, 'right, 'high, 'low
For an ascending array, 'left and 'low are the same, and for a
descending array, 'left and 'high are the same.
Array assignments, comparisons, etc. use the 'left to 'right ordering.
Allan.
Jordan Rosenthal
> "All matrix operations that can only be defined for 1-based matrices shall
> cause a run-time error when passed an array with any dimension with base not
> equal to 1."
> A = B*C
>
> Currently the number of columns of B must equal the number of rows of C.
> The user-definable base extension would additionally require that the base
> index of the rows of B must equal the base index of the columns of C.
Comment 1:
------------
Consider this case: Let x be a vector that represents a signal with some base
index. Now, I apply a transform:
X = F * x;
With your suggestion, this is okay as long as the base index of F matches the base
for x. Fine and dandy.
But what should happen when I want to do a block transform of a long signal y?
Y = F * reshape(y, nBlock, length(y) / nBlock);
If reshape adjusts all the indices to match the first block, this will work.
Comment 2:
------------
Assume functions like LU, SVD, and others are all "matrix" functions in the sense
you describe. That is, they are all oriented around a base one input matrix.
Further assume that I have some DSP or other application for which I want to use
data vectors/matrices with different bases.
What then happens when I want to use the matrix functions with my data vectors?
With your description, errors would occur. Unfortunatley, I can think of tons and
tons of DSP applications that use matrix factorizations. Is this really what you
want to do?
Jordan
Jordan Rosenthal
I forgot to make my point in "Comment 1". The point was that I'm not convinced
RESHAPE should have the reindexing behavior I described.
Jordan
AJ "no z" Johnson
news:3D5B5F0D...@ph.tn.tudelft.nl...
> Peter J. Acklam wrote:
> > Sure there are cases where a different array base is conveninent,
> > but that doesn't change the fact that it is _generally_ considered
> > bad coding practice to use an array base other than the default.
>
>
> (according to my dictionary:
> "It is believed that" means "I think"
> "It is generally believed that" means "A couple of other guys think
so, too"
> )
>
> Anyway, "good coding practice" is heavily overrated. "don't use
> globals", "use hungarian notation", "don't use hungarian notation",
> "don't use variable names that are too short", "don't use variable
> names that are too long", "comment all your code", "don't over-comment
> your code", "don't use goto's". I'm sick of these rules. You never
Good points on both sides. I've no wish to make this thread longer than it
needs to be (too late!) so I'll finish up with these thoughts.
1. From argument's sake, I'll say that any program can be written in any
language; however, languages are generally selected for their features, as
some languages are more suitable for some applications. So, with or without
"variable indexing," Matlab will continue to be a suitable language for many
applications. I've lived without it for 12 years now, and will continue to
do so (presumably).
2. Almost every feature has advantages and disadvantages. Often it's a trade
off among ease of programming, speed, readability, coding conventions,
backward compatibility, reliability, portability, etc. I'm not sure
"variable indexing" has a compelling argument given all factors.
3. As far as coding practices, it's a matter of personal preference, but
it's also a matter good sense. For example, I work with software that runs
on mission critical systems. Any coding technique that tends to be more
prone to semantic errors is heavily discouraged (e.g. use of pointers in C).
(The strongest driver here is reliability.) Jerry Avins' letter is a
testament to this, showing a better way to code when one's goal is
efficiency and readability rather than structural purity. In this light,
using an array base other than the default could validly be considered a bad
coding practice. But others would find it very useful.
done.
Aj
John D'Errico
<cr...@ph.tn.tudelft.nl> wrote:
> Peter J. Acklam wrote:
> > Sure there are cases where a different array base is conveninent,
> > but that doesn't change the fact that it is _generally_ considered
> > bad coding practice to use an array base other than the default.
>
> Generally by who?
>
> (according to my dictionary:
> "It is believed that" means "I think"
> "It is generally believed that" means "A couple of other guys think
> so, too"
> )
>
> Anyway, "good coding practice" is heavily overrated.
Only by those who think too much of themselves
to follow it. I have a great deal of respect for
Peter and I've found much to learn from him.
> "don't use
> globals", "use hungarian notation", "don't use hungarian notation",
> "don't use variable names that are too short", "don't use variable
> names that are too long", "comment all your code", "don't over-comment
> your code", "don't use goto's". I'm sick of these rules. You never
> know which ones to adhere to and why.
If you don't know enough about programming to know
what works and what does not work, then maybe it
might be a good idea to learn some rules. Rules help
you survive when experience is not available.
> Sometimes programs become too
> complex or difficult to read because of these. A good program is one
> that is simple and easy to read. If you need comments for that, ok.
> If you need global variables for that, ok. A small independent
> program can use globals; it makes it much simpler. If you need to
> index an array starting at 2351354 because it makes all the code
> look so much more like your original formulas, do it.
Rule #1:
Rules are made to be broken. It helps if you know
when to do so and when not to. Otherwise, stick to
rules #2 and above.
> But stop
> telling other people how to write their programs, unless you you need
> to read them but can't.
Don't listen. But don't come work for me or with
me either. I expect the programs I write to outlive
my presence. This means they need to be written
so that a person can read and modify them if need
be when I'm gone. Perhaps your code is more ephemeral.
> I'm belong to the group of people that would like MATLAB to have
> user-definable array bounds. My life would be easier.
Not as easy as you think. I'd bet that you would be
among the first people to complain about the bugs
this introduces into your code, and god forbid, bugs
that were missed in code from the Mathworks.
> But, as other
> improvements I suggested, I don't think we'll ever have them. It
> looks like they only change things they themselves are unconfortable
> with, like the error messaging system (which was perfectly acceptable
> IMO) or the logical flag.
Stop whining.
As I would expect, things that are easy to do get done
quickly. Things that are difficult to do, and entail
major risks of creating huge amounts of bugs in matlab,
get done almost never. Even if those things would
satisfy a few very vocal people.
The fact is, Cleve is a nice guy. I'll bet he would
gladly help you out if he could do so with no cost
to the rest of the Matlab community. But this would
be a significant change to matlab. It would force me
to test and possibly patch nearly every function I've
ever written to ensure there are no bugs created.
I'm not willing to take several months out of my
life to make your life a little easier. Sorry.
John D'Errico
--
Peter J. Acklam
Content-Type: text/plain; charset=us-ascii
Cris Luengo <cr...@ph.tn.tudelft.nl> wrote:
> Peter J. Acklam wrote:
>
> > Sure there are cases where a different array base is
> > conveninent, but that doesn't change the fact that it is
> > _generally_ considered bad coding practice to use an array
> > base other than the default.
>
> Generally by who?
By the programming community. Read about programming style -- and
I'm not talking about language syntax, but the bigger picture:
How to write good, self-documenting, easily maintainable programs.
> (according to my dictionary:
> "It is believed that" means "I think"
> "It is generally believed that" means "A couple of other guys think so, too"
> )
That's ok with me as long as you speak for yourself. Personally,
I use a different definition of "generally".
> Anyway, "good coding practice" is heavily overrated. "don't use
> globals", "use hungarian notation", "don't use hungarian
> notation", "don't use variable names that are too short", "don't
> use variable names that are too long", "comment all your code",
> "don't over-comment your code", "don't use goto's". I'm sick of
> these rules.
That is also fine with me, because luckily for both of us, we will
probably never do any serious coding together.
You don't seem to understand why people have come up with such
rules, and what these rules really are. They are not laws, they
are _guidelines_. And their purpose is to make people write
better programs.
> You never know which ones to adhere to and why.
That's exactly why you need to learn more about programming style.
First learn the rules, and when you know them really well, you
also know when to break them.
> Sometimes programs become too complex or difficult to read
> because of these. A good program is one that is simple and easy
> to read.
A good program is simple? I work as a developer at an air traffic
control center. The amount of code lines involved is well over
half a million. There is no way to make such a program simple.
No matter the programming language and style, such a program is
bound to be highly complex.
> If you need comments for that, ok. If you need global variables
> for that, ok. A small independent program can use globals; it
> makes it much simpler. If you need to index an array starting at
> 2351354 because it makes all the code look so much more like
> your original formulas, do it.
Yes, do it! I never said that it was always a bad idea to use
some weird array base. Quite the contrary. If an array base of
2351354 is a good thing in your case, then use it, but the fact
that it is a good thing in one case, doesn't make it a good idea
in general.
> But stop telling other people how to write their programs,
> unless you you need to read them but can't.
It seems you fail to grasp the very essence of this discussion.
It's not about giving orders on programming style, but rules of
thumb, guidelines on how to write good programs. They are general
rules, so follow them _in_general_, and break them when doing so
serves a good purpose.
> I'm belong to the group of people that would like MATLAB to have
> user-definable array bounds. My life would be easier. But, as
> other improvements I suggested, I don't think we'll ever have
> them. It looks like they only change things they themselves are
> unconfortable with, like the error messaging system (which was
> perfectly acceptable IMO) or the logical flag.
I am confident that the people at MathWorks are interested in the
index base issue and I am certain that they have discussed it
numerous times.
They haven't implemented it yet, but that's not because of
laziness or indifference. The index base issue is probably more
complicated than you are aware of.
Stan Pawlukiewicz
>
> AJ \"no z\" Johnson wrote:
> >
> > "Steve Amphlett" <samp...@ricardo.com> wrote in message
> > news:2ae8f62b.02081...@posting.google.com...
> > > Oh well guys, the thread's now four days old and still no TMW
> > > chippers-in! Do you reckon they're developing their killer argument?
> > > Or are they just sitting pretty, knowing that their obviously flawed
> > > product has market share on its side?
> > >
> > > - Steve
> >
> > ...or maybe they are too busy adding an "Index Origin" property to array
> > constructs. One can only hope. I hope it's obvious which court I'm in.
>
> it's nice to feel less alone. when i first brought this up, it seemed
> like everyone, except a few comp.dsp regulars, thought i was goofy.
Now, who... would think that. ;)
Responding to this and the another thread, here in one place.
Take a look at Python. I haven't played with 2.2, but in 1.5 and with
numpy, there is a distinction between an array(n) and a
array(n,1). You can also have an array with indicies
a('bob', 'ted', 'carol', 'alice')
if you want. The iterator in this case brings a few ideas to mind, but
I won't go there.
It seems like you would like something of the flavor of an associate
memory.
In terms of matricies, zero base indexing might be a bit cleaner in
terms of notation for cyclic objects i.e. a( mod(i,N))
Matt
> > This being the first indexing thread that *I've* read, I am curious what
> > other languages support definable indexing origins?
Fortran 90 and 95:
real(8) A(-1023:1024, 0:n-1)
> but if you do:
>
> double *_my_dummy_array = (double *)malloc(2049*sizeof(double));
> double *my_array = _my_dummy_array + 1024;
>
> for (k=-1024; k<=1024; k++)
> {
> do_something_with( my_array[k] );
> }
>
> ****that should be perfectly acceptable coding practice.
But it doesn't work for 2D and up arrays. Of course, C doesn't have 2D and up
arrays.
Well, C doesn't even have 1D arrays, it just has pointers. You can replace A[i]
with i[A]
with (A+i)* and you get the same thing. This is why C arrays are zero based,
they're
pointers.
Now, let's get the language wars going and discuss where {}'s should go ;)
Matt
Eric Jacobsen
<st...@mitre.org> wrote:
>Take a look at Python. I haven't played with 2.2, but in 1.5 and with
>numpy, there is a distinction between an array(n) and a
>array(n,1). You can also have an array with indicies
>
>a('bob', 'ted', 'carol', 'alice')
Clever. Stan reveals some things about himself here that the younger
folks may not get.
;)
Eric Jacobsen
Minister of Algorithms, Intel Corp.
My opinions may not be Intel's opinions.
http://www.ericjacobsen.org
robert bristow-johnson
eric.j...@ieee.org wrote on 08/15/2002 13:36:
> On Thu, 15 Aug 2002 11:10:48 -0400, Stan Pawlukiewicz
> <st...@mitre.org> wrote:
>
>> Take a look at Python. I haven't played with 2.2, but in 1.5 and with
>> numpy, there is a distinction between an array(n) and a
>> array(n,1). You can also have an array with indicies
>>
>> a('bob', 'ted', 'carol', 'alice')
>
> Clever. Stan reveals some things about himself here that the younger
> folks may not get.
>
> ;)
>
listen, *I'm* even a bit young (it was rated R and i was too young to see
the movie and i am now 46 and have for about a decade been coming to terms
with the fact that by body is turning into crap). however i think Stan
goofed up the order just a wee bit. 'carol' comes before 'ted' unless this
is the input to an N=4 DIT FFT.
Jordan, i'll respond to your post after i get some work done.
r b-j
Johan Kullstam
> samp...@ricardo.com (Steve Amphlett) writes:
>
> > Oh well guys, the thread's now four days old and still no TMW
> > chippers-in! Do you reckon they're developing their killer argument?
> > Or are they just sitting pretty, knowing that their obviously flawed
> > product has market share on its side?
>
> robert bristow-johnson <rob...@wavemechanics.com> wrote:
> > hey Cleve, i don't know Steve at all so it cannot be said i put him up to
> > say this.
> > they did not answer either the complaints or the suggestions i put forth.
> > they (essentially Cleve) *did* respond, it was just a couple of times and he
> > did not answer the complaints nor refute the suggested fix that i proposed.
> > again, here is the basic complaint that TMW simply will not touch. they
> > will not fix it nor will they even acknowledge it:
>
> OK, at the risk of prolonging this discussion, here I am again.
> But if the discourse continues in the above vein, we'll all tune out again.
>
> Below is one example of an important function in our math library.
> It's not a DSP function, but it is central to much of scientific and
> engineering computation. I have one basic question:
>
> How would you change this function to accomodate a scheme
> where array subscripts do not start at 1?
You could simple not change the function at all but add a declare
statement valid in a local context about how to treat the array
subscript.
Something like (but not as ugly)
declare_start_index some_vector(0)
declare_start_index some_array(-5,1)
So that indexing in the *local* context would stuff in the offset for you.
some_vector(0) would map to the first element,
some_vector(1) would map to the second element etc.
Once you pass the vector/array, the index offset would be lost.
This could be accomplished by some preprocessor or similar macrology
since it's just a syntactic sugar.
> If we get a reasonable answer to this question, then we'll consider
> the task of applying that approach to the thousands of functions
> that this one represents.
Since there are no local declarations about index starts point, your
example function would continue to work as normal.
[typical matlab function elided]
Well, my suggestion is rather ugly. Maybe it won't help much. The
only really annoying one for me is the FFT. But that is just one
case.
I also think there are bigger fish to fry -- i'd really like
first-class functions, including function constants (lambda) and
closures.
--
Johan KULLSTAM <kulls...@attbi.com> sysengr
Peter J. Kootsookos
> Anyway, "good coding practice" is heavily overrated. "don't use
> globals", "use hungarian notation", "don't use hungarian notation",
> "don't use variable names that are too short", "don't use variable
> names that are too long", "comment all your code", "don't over-comment
> your code", "don't use goto's". I'm sick of these rules. You never
> know which ones to adhere to and why.
Have you ever asked "why?" ? You might find the answers illuminating.
> Sometimes programs become too complex or difficult to read because
> of these. A good program is one that is simple ...
Bollocks! Some problems requiring software solutions are complex.
There is no way the software that solves these problems will not be
complex.
> and easy to read.
I agree that they should be easy to read.
> If you need comments for that, ok. If you need global variables for
> that, ok. A small independent program can use globals; it makes it
> much simpler. If you need to index an array starting at 2351354
> because it makes all the code look so much more like your original
> formulas, do it. But stop telling other people how to write their
> programs, unless you you need to read them but can't.
If you are writing code in a software team, you _always_ need to read
other people's code. That usually means that the software team needs
to find some middle ground about coding standards. These standards
will be different for each different group of programmers.
Ciao,
Peter K.
--
Peter J. Kootsookos
"Na, na na na na na na, na na na na"
- 'Hey Jude', Lennon/McCartney
Peter J. Kootsookos
> You don't seem to understand why people have come up with such
> rules, and what these rules really are. They are not laws, they
> are _guidelines_. And their purpose is to make people write
> better programs.
If sounds like Peter A. _has_ asked the "why?" question.
>
> > You never know which ones to adhere to and why.
>
> That's exactly why you need to learn more about programming style.
> First learn the rules, and when you know them really well, you
> also know when to break them.
Yup!
> A good program is simple? I work as a developer at an air traffic
> control center. The amount of code lines involved is well over
> half a million. There is no way to make such a program simple.
> No matter the programming language and style, such a program is
> bound to be highly complex.
:-) Great example.
Cris Luengo
> You don't seem to understand why people have come up with such
> rules, and what these rules really are. They are not laws, they
> are _guidelines_. And their purpose is to make people write
> better programs.
The reason I rant about these rules is that people seem unable to
break loose from them. I wholehartedly agree with you and the other
people that answered my message, in that these guidelines are a good
starting point. But I very often find myself breaking these rules
to obtain code that is clearer and conciser (I never go for speed,
I care about being able to read my code). However, when I do so,
there is always somebody hanging over my shoulders, screaming. That
makes me quite angry. It's never the people I work with. They seem
to have no problems with my style, and are always able to read/change
my code without my help (I do work on a large project with other
people).
>>Sometimes programs become too complex or difficult to read
>>because of these. A good program is one that is simple and easy
>>to read.
>
> A good program is simple? I work as a developer at an air traffic
> control center. The amount of code lines involved is well over
> half a million. There is no way to make such a program simple.
> No matter the programming language and style, such a program is
> bound to be highly complex.
A good program is as simple as the problem allows it to be. A good
program shouldn't be more complex than the problem itself. That's
what I meant. And even a project with half a million lines of code
should be easy to get into (after understanding the goal and the
general structure, that is). It shouldn't be necessary to read all
of the half-million lines to find and correct a bug, for example.
Peter J. Kootsookos wrote:
> If you are writing code in a software team, you _always_ need to read
> other people's code. That usually means that the software team needs
> to find some middle ground about coding standards. These standards
> will be different for each different group of programmers.
Of course. It certainly helps if all people working on a project use
the same conventions for naming, placing of braces, etc. I didn't mean
any of those things. But I don't think that the usage of certain
constructs (goto or switch, for example) should be dictated in those
conventions.
I din't mean to alienate anybody with my ranting. Sorry, guys!
I'm especially sorry I lost Peter Acklam as a potential co-worker. :(
Cris.
Cris Luengo
> I expect the programs I write to outlive
> my presence. This means they need to be written
> so that a person can read and modify them if need
> be when I'm gone. Perhaps your code is more ephemeral.
I hope not! (although it depends on the life-span of MATLAB,
who will die first?) I just think that some of my code is better
readable when indices start at 0. I've written a class to
encapsulate images under MATLAB, and because of that I was
able to overload the indexing to start at 0 (I've also
changed the order of the first two indices; some of my coleagues
also wanted to flip the y-axis, but we didn't do that). Large
portions of my code use both images and arrays, and this doesn't
make it confusing at all. It just feels natural to me (and
to other people using our toolbox as well).
> Stop whining.
Sorry! :)
> As I would expect, things that are easy to do get done
> quickly. Things that are difficult to do, and entail
> major risks of creating huge amounts of bugs in matlab,
> get done almost never. Even if those things would
> satisfy a few very vocal people.
>
> The fact is, Cleve is a nice guy. I'll bet he would
> gladly help you out if he could do so with no cost
> to the rest of the Matlab community. But this would
> be a significant change to matlab.
I think so too. It woun't be as easy to implement as many
people think. And it does pose quite a few problems with
inconsistencies, as was shown by other people in this thread.
> It would force me
> to test and possibly patch nearly every function I've
> ever written to ensure there are no bugs created.
I'll have to do the same thing because of the new logical
class (which is an improvement, but caught me off-guard).
I guess there is no way of keeping all your customers happy,
especially if you have such a large (and critical) customer
base as MATLAB has.
Cris.
Jerry Avins
>
> ... Some problems requiring software solutions are complex.
> There is no way the software that solves these problems will not be
> complex.
>
is far more complex than it needs to be. Some of that complexity comes
from hack programmers trying to follow rules whose purposes they don't
understand, or by applying to one domain "rules of good practice"
intended originally for another. Do you remember "structured assembly
language programming"? What a crock!
amoli...@visi-dot-com.com
>"Peter J. Kootsookos" wrote:
>>
>> ... Some problems requiring software solutions are complex.
>> There is no way the software that solves these problems will not be
>> complex.
>>
>I think everyone agrees with that. I hope you agree that some software
>is far more complex than it needs to be. Some of that complexity comes
>from hack programmers trying to follow rules whose purposes they don't
>understand, or by applying to one domain "rules of good practice"
>intended originally for another. Do you remember "structured assembly
>language programming"? What a crock!
See, I'm kind of stupid, so I can write clean code by simply insisting
that I can understand it myself. Works great. I dunno how alla the
smart guys manage it. Maybe they use coding style rules or something.
Sweavo
<amoli...@visi-dot-com.com> wrote in message
news:vn979.222$h7.4...@ruti.visi.com...
Pragmatic considerations can come in between the ideal factoring of code
and a suitable implementation. If your code is time-critical to be deployed
across various embedded platforms with varying space/timing constraints
then the code that is nearest the semantics you were intending to express
may not be workable in all situations.
Ken Davis
The problem with this position is that someday you'll leave the company and
you'll leave someone like me with 20,000 or 30,000 lines of Matlab, with few
comments (most of which are either cryptic or obsolete), where the same
quantities have different names in different places and are sometimes passed
through argument lists and sometimes passed through globals, that 10
different people have had their fingers in at one time or another and each
thought that "as long as I can understand it..." and when you go back to
them 2 years later, even they can't understand it anymore...
That's why I like to follow some basic coding standards (and refactor and
comment as I go) AND encourage others to do the same.
Regards,
Ken
<amoli...@visi-dot-com.com> wrote in message
news:vn979.222$h7.4...@ruti.visi.com...
Mike Rosing
>
>>>This being the first indexing thread that *I've* read, I am curious what
>>>other languages support definable indexing origins?
>>>
>
> Fortran 90 and 95:
> real(8) A(-1023:1024, 0:n-1)
I think that went over a few heads. It means a 2D array
with index range -1023 as the bottom value for the first
index and 0 for the second. RBJ you should like that!
> Well, C doesn't even have 1D arrays, it just has pointers. You can replace A[i]
> with i[A]
> with (A+i)* and you get the same thing. This is why C arrays are zero based,
> they're
> pointers.
You mean the compiler takes A[i] == i[A] and generates the right
assembler? I gotta try that to make my code obfuscated maximally :-)
> Now, let's get the language wars going and discuss where {}'s should go ;)
I'll stick with assembler thanks :-)
--
Mike Rosing
www.beastrider.com BeastRider, LLC
SHARC debug tools
Jerry Avins
A man of my own heart! From a letter I wrote years ago:
"The canons of structured programming in assembly language
seem to be:
(1) Don't branch out of a subroutine.
(2) Each subroutine may be entered at only one place.
(3) Each subroutine may have only one return statement.
(4) The return statement must be the last one.
These rules are supposed by some to make the program easier to
read and to understand, even if the processor has to work a
little harder to execute the code. In fact, to understand the
code, the programmer and the reader have to emulate the
processor: when it works harder, they do too. The intent is
good, but the rules are counterproductive.
"Often, those rules force superfluous branches, thereby
cluttering the symbol table and forcing the reader to scan for
the unnecessary label. ..."
Matthew C Roberts
<aj.jo...@lmco.com> wrote:
> I am curious what
>other languages support definable indexing origins?
>For sure:
>- Maple (don't know much about it, though)
>- Pascal, IIRC
>- APL (choice of 0 or 1 only)
>- C (array indexing is so loose that one can implement non-zero based
>indexing, but it is geneally considered bad coding practice)
>- Ada
>- TCL, REXX (Being text-based, there is no true numeric indexing of arrays;
>it's symbolic)
>
Fortran9x
navan
double f;
for (f=-4000; f<=4000; f+=3.9063)
{
do_something_with( my_array[f] );
}
because that is where the frequencies of the fft output are in my_array.
No programming language seems to support this. :(
This is highly readable.
(and highly inefficient)
Navan
> ...or maybe they are too busy adding an "Index Origin" property to array
> constructs. One can only hope. I hope it's obvious which court I'm in.
> This being the first indexing thread that *I've* read, I am curious what
> other languages support definable indexing origins?
> For sure:
> - Maple (don't know much about it, though)
> - Pascal, IIRC
> - APL (choice of 0 or 1 only)
> - C (array indexing is so loose that one can implement non-zero based
> indexing, but it is geneally considered bad coding practice)
> - Ada
> - TCL, REXX (Being text-based, there is no true numeric indexing of arrays;
> it's symbolic)
>
> I guess everyone has their Matlab wish list... I know I do. And to be fair,
> I think Mathworks has gone a long way to meeting customer demands, which is
> why it's such a comprehensive product now. If only they'd add *my* stuff...
> :-)
>
> Aj
robert bristow-johnson
epo...@yahoo.com wrote on 08/16/2002 17:11:
> I would love to write code with
>
> double f;
> for (f=-4000; f<=4000; f+=3.9063)
> {
> do_something_with( my_array[f] );
> }
>
> because that is where the frequencies of the fft output are in my_array.
>
> No programming language seems to support this. :(
you can do it in C++ but you have to make your own functions or
objects/methods to create these kind of arrays and do the interpolation with
non-integer subscript (which will have to make some assumption on how to do
the interpolation, probably some kind of windowed sinc() and/or Hermite
polynomial thingie). to create it is a little ugly, but not impossible.
> This is highly readable.
> (and highly inefficient)
especially if all you need are the integer indices.
r b-j
Randy Poe
>
> I would love to write code with
>
> double f;
> for (f=-4000; f<=4000; f+=3.9063)
> {
> do_something_with( my_array[f] );
> }
>
> because that is where the frequencies of the fft output are in my_array.
>
> No programming language seems to support this. :(
C++ would.
Of course you'd have to learn the intricacies of overloading
the indexing operator [], but what you want is certainly
possible.
- Randy
Raymond Toy
Matthew> On Wed, 14 Aug 2002 12:48:12 -0400, "AJ \"no z\" Johnson"
Matthew> <aj.jo...@lmco.com> wrote:
>> I am curious what
>> other languages support definable indexing origins?
>> For sure:
>> - Maple (don't know much about it, though)
>> - Pascal, IIRC
>> - APL (choice of 0 or 1 only)
>> - C (array indexing is so loose that one can implement non-zero based
>> indexing, but it is geneally considered bad coding practice)
>> - Ada
>> - TCL, REXX (Being text-based, there is no true numeric indexing of arrays;
>> it's symbolic)
>>
Matthew> Fortran9x
Fortran 77 allowed this.
Ray
bv
>
> if MATLAB was to have a hard-wired indexing base, it certainly would
> have been better if Cleve Moler would have departed from the existing
> Applied Matrix Theory and Linear Algebra textbooks and used (0,0) for
> the upper left corner. (who knows? perhaps in 10 or 20 years, virtually
> all the texts would be written or revised to use 0,0 for the upper left
> corner of a matrix!) but he didn't and that's really not so bad since
> what the *true* lacking with MATLAB is that we cannot create our own
> arrays and give them whatever integer indexing base we desire. if
> MATLAB did that, the "1" guys can have their 1-based arrays and us "0"
> guys can have our 0-based arrays. and the crazy dudes like me can have
> our -1024 based arrays.
That's an easy one, just switch to *Fortran* and it will give you all
the choices you'll ever want w/o attempting to turn the math upside down
by relabeling matrix entries etc. In the time you spent gripping what
Matlab doesn't have you could have whipped together a "dsp.dll" of your
own using the same sources scoured by the Molers et al except for their
handicapped indexing choices (due to C rather than design).
--
Dr.B.Voh
------------------------------------------------------
Applied Algorithms http://sdynamix.com
robert bristow-johnson
on 08/16/2002 21:00:
> robert bristow-johnson wrote:
>>
>> if MATLAB was to have a hard-wired indexing base, it certainly would
>> have been better if Cleve Moler would have departed from the existing
>> Applied Matrix Theory and Linear Algebra textbooks and used (0,0) for
>> the upper left corner. (who knows? perhaps in 10 or 20 years, virtually
>> all the texts would be written or revised to use 0,0 for the upper left
>> corner of a matrix!) but he didn't and that's really not so bad since
>> what the *true* lacking with MATLAB is that we cannot create our own
>> arrays and give them whatever integer indexing base we desire. if
>> MATLAB did that, the "1" guys can have their 1-based arrays and us "0"
>> guys can have our 0-based arrays. and the crazy dudes like me can have
>> our -1024 based arrays.
>
> That's an easy one, just switch to *Fortran* and it will give you all
> the choices you'll ever want w/o attempting to turn the math upside down
> by relabeling matrix entries etc.
perhaps you would have me vote for Eisenhower, too? perhaps i should move
up to *Color* TV.
i wasn't born yesterday (Fortran was the first language i learned and it was
required of engineering students in the 70s and perhaps 80s) but now it is
dead, dead, dead. it is the "late parrot" on the Monty Python sketch. and,
if you *can* get it for your platform (check the headers and see which
platform i'm using), it ain't gonna be cheap.
for most general purpose application programming, C and C++ is what people
are using and what they are (or at least should be) teaching in the schools.
i think, for what it is, C is a compact and concise language that has its
few blemishes. i don't sing the praises of C++ because i think that some
other object oriented language like smalltalk is more concise and elegant.
but i recognize C++ for what it is: ubiquitous (in the PC application area).
now for DSP algorithm design and modeling, probably Mathematica would be
more elegant than MATLAB, but, like C++, i recognize MATLAB is the defacto
standard for both the design and modeling of DSP algorithms but also for the
*exchange* of those algorithms. just like anyone who builds applications
should have Code Warrior (or -shudder- VC++), anyone who seriously does DSP,
publishes, and collaborates or communicates their ideas to others (via
email), should have MATLAB. in that sense, it is virtually ubiquitous.
you (according to your web page) seem to deal with mainframes and Watcom.
how likely is it that i will see either? and why should i? i have more
computing juice than i need on top of my desk.
> In the time you spent griping what
> Matlab doesn't have you could have whipped together a "dsp.dll" of your
> own
as if doing DSP algorithm R&D is the same as writing DLLs. (what is the
reason that we, or our bosses, buy a technical computing language like
MATLAB? so we can spend our time on DOSisms or on algorithms?)
> using the same sources scoured by the Molers et al except for their
> handicapped indexing choices (due to C rather than design).
from what i can tell, MATLAB is so well entrenched as the ubiquitous
standard for DSP algorithm modeling and design, that it should come as
little surprise that the next competition it gets (SysQuake) is not a new
language, nor does it emulate MathCad nor Mathematica. it emulates MATLAB
(at a user source code level) and that's how that guy expects to make some
money. kinda like the Beastrider tools for the SHArC, he intends to get in
on some of TMW's market by selling a source compatible tool (for much less
money) rather than selling a new language (even though it could easily be
conceived that a different language might be superior to MATLAB). that
should tell you where MATLAB is in the market share and where it (and
compatible competitors) shall be in the future.
so there are going to be lot's (many 1000s) of people using MATLAB for DSP
(more so than anyone else) in the future for a minimum of 10 years (probably
much longer) and for this inelegant *violation* of convention (regarding
indexing in the DFT/convolution) to get even more entrenched is ridiculous.
what to you (or TMW) expect? that the textbooks will toss out the concise
and elegant mathematical expressions and start using the MATLAB ones so that
their equations become compatible with MATLAB? that's ridiculous! no one,
not you, not Cleve, no one has ever touched the main point i made that for a
company whose product expresses mathematical instructions "just as they are
written mathematically", why weren't lot's of red flags flying up when they
were essentially being forced to change or contrive those well established
expressions (of which the DFT and FIR are only two) into their fixed 1-based
indexing scheme?
i don't think they *can* answer that one. they dropped the ball. now the
question is: how far are they going to let it roll before they pick it up?
those of us who do not use mainframes and Watcom *do* use PCs (or Macs or
UNIX workstations) and C/C++ and MATLAB. it is *this* language, precisely
because it is the de facto standard for DSP and will remain so (the SP
toolbox was the original MATLAB toolbook), that it needs to be fixed.
precisely because of the people who will be using it, in the near future and
in the distant future.
so Dr. B. Voh you may be a Ph.D. (which is fine and good) but don't let it
go to your head.
you do not understand.
r b-j
robert bristow-johnson
Jordan Rosenthal wrote:
>
> I forgot to make my point in "Comment 1". The point was that I'm not convinced
> RESHAPE should have the reindexing behavior I described.
i'm not sure what reindexing behavior you meant, but i don't think that
RESHAPE should change the indices of the upper left corner, whatever
they are.
> > > "All matrix operations that can only be defined for 1-based matrices shall
> > > cause a run-time error when passed an array with any dimension with base not
> > > equal to 1."
> >
> > > A = B*C
> > >
> > > Currently the number of columns of B must equal the number of rows of C.
> > > The user-definable base extension would additionally require that the base
> > > index of the rows of B must equal the base index of the columns of C.
> >
> > Comment 1:
> > ------------
> > Consider this case: Let x be a vector that represents a signal with some base
> > index. Now, I apply a transform:
> >
> > X = F * x;
> >
> > With your suggestion, this is okay as long as the base index of F matches the base
> > for x. Fine and dandy.
to be clear, the base index of the *rows* of F should be the same as the
base index of the *columns* of x. just like the length of the rows of F
should be the same as the length of the coloumns. the base index of the
the columns of F and rows of x can be anything (just as the lengths can
be anything) and that gets copied over to X.
> >
> > But what should happen when I want to do a block transform of a long signal y?
> >
> > Y = F * reshape(y, nBlock, length(y) / nBlock);
> >
> > If reshape adjusts all the indices to match the first block, this will work.
i do not now exactly what adjustment of indices you mean. reshape()
changes the length of the rows and the length of the columns in such a
way that the data of the array/matrix is unchanged (taken columnwize)
and the product of row length and column length remains unchanged.
what reshape() currently leaves unchanged is the indices (or
"subscripts" if that's what you like to call them) of the upper left
corner (which remain (1,1)). i think the most reasonable thing to do if
this were extended for user-definable base is to retain that rule, that
the base indices (the subscripts of the upper left corner) remain
unchanged by reshape().
the fundamental and new function that i am proposing should IMO be
called "rebase". just like reshape() changes the nature of the array
(the lengths of the rows and columns) without touching the data,
rebase() changes the nature of the array (the base index of the rows and
columns) without touching the data. and a counterpart to size() (that
returns the lengths of the rows and columns) would be "base()" (that
returns the base index of the rows and columns).
> > Comment 2:
> > ------------
> > Assume functions like LU, SVD, and others are all "matrix" functions in the sense
> > you describe. That is, they are all oriented around a base one input matrix.
> > Further assume that I have some DSP or other application for which I want to use
> > data vectors/matrices with different bases.
> >
> > What then happens when I want to use the matrix functions with my data vectors?
> > With your description, errors would occur. Unfortunatley, I can think of tons and
> > tons of DSP applications that use matrix factorizations. Is this really what you
> > want to do?
yup, i think i *did* successfully define an extension to lu() that makes
sense for user-definable based arrays, but the general rule for things
that just cannot make sense for arrays that do not have both (or all) of
the dimensions based to 1, could be that they don't work. if they can
be naturally extended for other bases, fine, then they should work. if
you're doing DSP using the user-extended based arrays and you come up
with an array that you want to treat as a matrix and do some kind of
operation on it that just cannot make sense unless it's a matrix that
has (1,1) as the subscripts for the upper left corner, if you wanna do
that, you may have to use "rebase()" to convert it to a conventional
MATLAB matrix. but perhaps a (1,1) array will naturally pop out of some
set of operations, then it would be "natural" to just apply the matrix
operation on the array without rebasing it.
hey Cleve! are you still in the discussion?
Cleve Moler
robert bristow-johnson <r...@surfglobal.net> wrote:
>hey Cleve! are you still in the discussion?
Yes, I glance over all the postings.
-- Cleve
robert bristow-johnson
did i answer your LU challenge sufficiently? (or did you want another
implementation of LUTX?)
r b-j
Alexander Zavorine
"robert bristow-johnson" <rob...@wavemechanics.com> wrote in message
news:B983F915.6ABE%rob...@wavemechanics.com...