horrible MATLAB indexing (was Re: MATLAB PSD() Magnitude normalization question (FFT related))
robert bristow-johnson
this debate or ignore it (as they have done every time in the past).
this is why i'm cross-posting to comp.soft-sys.matlab (it would seem
logical that they would monitor that newsgroup).
In article <3881FDA0...@ieee.org>, jya...@erols.com wrote:
> Jordan,
>
> The problem of backward compatibility is easily solved by allowing the
> programmer to choose the origin of arrays. BASIC's "OPTION BASE" comes
> to mind, but that has global effect. an optional declaration for each
> index would be my choice.
>
> The arrogance resides in the decision that users ought not be allowed to
> choose.
Jerry, you understand exactly what it's about but i feel the need to be
explicit.
> Jordan Rosenthal wrote:
> >
> > Robert,
> >
> > About your statement,
> >
> > > it's arrogant (as in microsoft quality of arrogance) for MathWorks to
> > > blow off their main constituency (the signal processing community) by
> > > insisting that the frequency of DC is 1. it's inexcusable.
> >
> > I think it would actually be much more "arrogant" for Mathworks to change
> > the current indexing system. Why? Because if they did, almost all the
> > Matlab code ever written would no longer run and everyone would have to
> > rewrite all of their code.
no, Jordan,
i've had this coversation a dozen times before including with the 2
original Sig Proc Toolbox authors (Tom Krauss, who agreed with me as i
remember it, and Loren Shure, who didn't) and with the Mathworks VP of
Technology (i can't remember his name, he didn't agree with me even
though he was unable to refute a single argument - he just said they
wouldn't do it). i spelled out exactly how it could be done in such a
way to be perfectly backward compatible at a source code level (.m files
- the .mex files created by users may have to be recompiled, of course
Mathworks would have to supply new .mex files with any upgrade with this
change).
for every MATLAB variable there are some embedded attributes besides the
actual numerical data of the variable or array. when you type in 'whos'
you see what some of those attributes are: number of rows and columns,
type (real vs. complex vs. text), memory used (bytes), etc. MATLAB has
some structure format where it can get a hold of these attributes and
allocates the memory for them along with the memory needed for the data
itself. so MATLAB ain't really memory efficient for simple scaler
variables, but it wasn't meant to be. in addition, like Fortran, MATLAB
checks these attributes when operations are done to make sure the
operation makes sense (types are compatible) and how to do it in the
case of mismatched types (like adding a real to a complex).
one test is to check the array bounds to make sure you don't go outside
of them. so MATLAB isn't very (execution) time efficient, but it's not
meant to be. it was meant to save _US_ time in prototyping/modeling
(testing "proof of concept") without making us worry about arcane
details of implementation that we have to do when we construct a real,
sellable product. it is in this goal/function of MATLAB that it fails
so miserably vis a vis DSP and the fixed indexing scheme that _must_
always start with one.
so my proposal is simply to add a new array of attribute (number of
elements equal to the number of dimensions of the array) the would
define the "upper-left" corner coordinates and that attribute would
default to (1, 1). or, another way to do it, would be to define an
index offset that would always be added to an array coordinate (default
is 0,0). so far, perfect backward compatibility. it would work just
like it did before albeit _slightly_ less fast and _slightly_ more
memory used.
then for DSPers who want their indexing for the FFT to start at 0 or
even perhaps at -N/2 (-nyquist) or who want our impulse responses to
start at 0 (or even some negative index for non-causal systems), we
would call some utility, similar to the RESHAPE function, that would
adjust this new attribute without messing with the data.
1. it is easily done.
2. it would save DSPers thousands of hours and headaches.
3. it can be made to be perfectly backward compatible.
4. there is no good reason that it can't be done.
> "robert bristow-johnson" <pbj...@viconet.com> wrote in message
> news:387EBB...@viconet.com...
> > > "strings" <str...@bellatlantic.net> wrote:
> > >
> > > > I have been using the MATLAB PSD() function do FFT magnitude analysis.
> > > > The problem is that the values don't seem normalized to what I see in audio
> > > > analysis tools.
> > > >
> > > > What I want: If a waveform in MATLAB is +/- 1.0 peak, I'd like to see the
> > > > Magnitude be "0 dB" from the PSD.
> > > > Likewise, if I had a waveform that had it's peak value as 0.5, I'd like to
> > > > get the PSD to give me "-3 dB".
> >
> > one thing: reducing the signal magnitude from 1 to 0.5 should bump you
> > down by 6 dB, not 3.
> >
> >
> > Mr. Sig Proc Toolbox and soon to be Dr. Tom Krauss, wrote:
> > >
> > > We used to (and they probably still do) get this question ALL THE
> > > TIME at MathWorks.
> >
> > which is understandable but this time Mathworks is right. the issue is
> > how does the FFT (or DFT) relate scalingwise to the continuous Fourier
> > Transform.
> >
> > i just wish we could get MathWorks to listen regarding enhancing the
> > horrible indexing system for MATLAB arrays by allow users to define the
> > index range to be an contiguous set of integers instead of insisting
> > that the first array element always be numbered "1". just this week i
> > was bitten for the umpteenth time by forgetting to subtract one from the
> > index value to read frequency. i had a sampling rate or 44100 and a
> > 4096 point FFT and i spent days (not solid days) wondering why my
> > computed frequencies were 10 Hz higher than their expected values.
> >
> > it's arrogant (as in microsoft quality of arrogance) for MathWorks to
> > blow off their main constituency (the signal processing community) by
> > insisting that the frequency of DC is 1. it's inexcusable.
> >
--
r b-j
pbj...@viconet.com a.k.a. rob...@audioheads.com
a.k.a. rob...@wavemechanics.com
"Don't give in to the Dark Side. Boycott intel and microsoft."
Michael C Schweisguth
indexing is easy to follow and implement. if array offsets
are introduced, then the underlying mex files would be
more complex. they already have to deal with Nan, Inf, empty's,
multiple data types?, etc...
the "off by one" bug is a classic one which has plaqued
programmers since the beginning of the art-- regardless
of the language-- and it takes away our time. ;-(
as a mex programmer, i appreciate the 'simple' interface
with MATLAB. maybe it could be 'enhanced', but at least
it is simple enough to understand its limitations.
you could write a function:
indx = dspindx(-N/2,N/2);
which would map your indicies to MATLAB indicies.
and then you could do:
for ii=indx(:)
end;
which has no explicit reference to what ii(1), ii(2), etc...
is.
when programmers make a mistake, i think that they try to
come up with a system so that they no longer make that
mistake--> just like people put their pills in containers
labeled: "M","TU","W","TH","F","SA","SU" so that they
wont forget to take them! ;-) certainly, the manufactures
could label the pills, but then most people probably couldnt
or wouldnt read the annotations anyway! if MEX or M programmers
ignored the matrix attribute, then bad programs would be produced.
i.e. if incompatible index vectors were generated, or
index vectors werent interpretted correctly. because index
vectors and matricies are loosely coupled, i think that
the current convention makes a lot of sense -- especially
since index vectors are of type double and can be operated
on very efficiently.
maybe you write your own index class:
indx = myindxclass(-N/2,N/2);
for ii = matlab_indx(indx)
end;
where 'matlab_indx' would convert your numbering to MATLAB numbering.
In comp.soft-sys.matlab robert bristow-johnson <pbj...@viconet.com> wrote:
> the real test of arrogance will be whether or not MathWorks will take on
> this debate or ignore it (as they have done every time in the past).
> this is why i'm cross-posting to comp.soft-sys.matlab (it would seem
> logical that they would monitor that newsgroup).
> In article <3881FDA0...@ieee.org>, jya...@erols.com wrote:
> > The arrogance resides in the decision that users ought not be allowed to
> > choose.
> so my proposal is simply to add a new array of attribute (number of
Cleve Moler
robert bristow-johnson <pbj...@viconet.com> wrote:
> the real test of arrogance will be whether or not MathWorks will take on
> this debate or ignore it (as they have done every time in the past).
> this is why i'm cross-posting to comp.soft-sys.matlab (it would seem
> logical that they would monitor that newsgroup).
Hi.
Yes, a number of us at MathWorks follow either one or both of these
news groups. (Personally, I read c.s-s.m almost daily, but don't
read comp.dsp very often.)
We've had extensive discussions, both internally and externally, about
introducing 0-based subscripting. When he was here, Tom Krauss was
one of the strong advocates of such a change.
MATLAB's subscripting is based on the fact that the fundamental
data structure is a matrix, not an array. Standard matrix notation
always starts the subscripts at 1. Over fifteen years, the MATLAB
community has developed a huge collection of code that relies on
this fact.
I have a suggestion. Maybe you'll think it's arrogant, but, in my
opinion, it's the only reasonable approach at this point. It's
a piece of notation for distinguishing 0-based subscripts from
1-based subscripts. It allows the use of 0-based subscripts without
requiring any changes to MATLAB's internal functions or math libraries.
Any 0-based subscript can be changed to a 1-based subscript by appending
the characters "+1".
At least you know we're listening.
-- Cleve Moler
mo...@mathworks.com
Jeffery J. Leader
On 17 Jan 2000 20:39:17 -0500, mo...@mathworks.com (Cleve Moler)
wrote:
>MATLAB's subscripting is based on the fact that the fundamental
>data structure is a matrix, not an array.
This makes sense to me, though I must admit that the option to change
the base would be handy.
>Any 0-based subscript can be changed to a 1-based subscript by appending
>the characters "+1".
First, let me disassociate myself from the tone of the comments in the
article to which you were replying. Second: What you say is correct
of course, but I think there's more. I teach numerical analysis in a
room with 1 workstation for every other student. Today mid-lecture I
asked them to take to the computers to play with some numerical
differentiation and Richardson extrapolation stuff in order to have
them "see" the O(h^n) error behaviour in vivo. The school is
Maple-heavy and many students are learning MATLAB bit-by-bit (well,
maybe byte-by-byte) as we go along in class--I am not teaching it
separately. As usual it works great because MATLAB is intuitive,
user-friendly, and has exemplary on-line help. (I can't say enough
about the on-line help.) On the other hand it would have been easier
for me if I could have said "Type >>help base to see how to change the
base to zero-indexing" so as to match the development and notation in
the text and on the board, rather than have students who are learning
MATLAB and also of course learning numerical analysis have that extra
conversion issue to deal with. What's simple in the context of a
larger program is not as simple in immediate mode for new users--and
yet I want them to do it themselves as much as possible in order to
learn and become comfortable with the language. For students trying
to do centered differencing the indexing issues can indeed get in the
way of the bigger picture.
This may not be an important application in the big scheme of
things--I used MATLAB for much more sophisticated work when working
with the DoD on my own, and then changing indices was a small price to
pay--and is a transient issue for any given student, and of course I
do not know what would be involved in adding this feature to MATLAB
and maintaing backward compatibility. But, especially with the
immediate mode and the ability to "play" without having to program,
this would be very handy--and for me at least would extend the natural
"feel" of MATLAB even further. Numerical integration is next and in
the book and at the board the nodes will be x0,x1,...,xn.
Michael C Schweisguth
not see it as a problem.
Jeffery J. Leader <JeffL...@MindSpring.com> wrote:
> Today mid-lecture I asked them to take to the computers to play with
> some numerical differentiation and Richardson extrapolation stuff in
> order to have them "see" the O(h^n) error behaviour in vivo.
> On the other hand it would have been easier for me if I could have
> said "Type >>help base to see how to change the base to zero-indexing"
> so as to match the development and notation in the text and on the board,
> rather than have students who are learning MATLAB and also of course
> learning numerical analysis have that extra conversion issue to deal with.
Michael C Schweisguth
it looks like he paid a big price for his stand. ;-)
Steve Eddins
Even though you included a smiley face, I had to jump in here to make
sure no one misunderstands. Tom departed New England to pursue a
doctorate. We were very sorry to see him go. You may have noticed
that he is a regular contributor to this newsgroup, most recently (I
think) on the FFTFILT thread.
Tom and I happened to be on opposite sides of this argument, even
though we both share an E.E. background specializing in DSP algorithms
and theory. Passionate disagreements about the design of MATLAB and
our other products are commonplace here and are part of the, umm, joy
of the job. :-) I like to think that the main reason discussions
sometimes get heated, both in this newsgroup and at The MathWorks, is
because we care very much about MATLAB and want it to be as good as it
possibly can be.
We appreciate very much the lively user community evident in
comp.soft-sys.matlab. Some of the very best MATLAB programmers in the
world are newsgroup regulars. Most developers and many others
throughout the company read the newsgroup regularly, and many animated
lunchroom discussions start with "what did you think about that cssm
post today from so-and-so?" If sometimes we do not respond to a
thread, it may simply be that we have nothing particularly useful or
new to add, or perhaps because we are all in a panic over the latest
release deadlines. :-)
Cheers,
Steve
--
Steve Eddins
The MathWorks, Inc.
edd...@mathworks.com
http://www.mathworks.com
Michael C Schweisguth
to market email shreading devices! ;-)
Michael C Schweisguth
sarcastic; therefore, i wanted to make it clear that "i was joking
around."
i remember using Cleve's ctrl-c package, before he went off to
do MATLAB.
robert bristow-johnson
not many posters (as in none except for Jerry Avins) are supporting me on
this. well, if scientific fact was determined by majority rule, then 600
years ago,sun revolved around the world that was really flat. fortunately,
i am not depending on popular support from comp.soft-sys.matlab as
justification of my complaint.
In article <3go78s048c575q8pe...@4ax.com>,
Jeffery J. Leader <JeffL...@MindSpring.com> wrote:
...
> First, let me disassociate myself from the tone of the comments in the
> article to which you were replying.
i will take this as a hint to tone it down a bit.
A reader (that i am not naming) emailed me and wrote:
>...
> My guess, however, is that the only way it could
> be done so that users would not have to rewrite their code, would be for
> Mathworks to have to rewrite most of their code!
not at all! MathWorks engineers know where, in their source, they can
find the code that explicitly checks for indices being out of bounds
for a particular matrix (or 'array') when an element is being
addressed directly and in a matrix on matrix operation, where the
matrix dimensions are checked for compatibility. it is only here
that MATLAB would have to be modified to include offsetting the matrix
indices or checking index bases for compatibility. this is in the
low-level part of the MATLAB kernal code but i cannot understand where
else MATLAB would have to be changed.
MathWorks would never divulge their source code to me, but if they
did, i bet i could find all of the necessary spots to possibly modify
in a day. no sweat.
In article <85vuet$vqb$1...@news.ccit.arizona.edu>,
Michael C Schweisguth <msch...@u.arizona.edu> wrote:
>
> the "off by one" bug is a classic one which has plaqued
> programmers since the beginning of the art-- regardless
> of the language-- and it takes away our time. ;-(
not in C. i can define any finite integer base i want for a C array.
// begin C code
float _my_array[512], *my_array;
int i;
my_array = &(_my_array[256]);
for (i=-256; i<256; i++)
{
my_array[i] = (float)i;
}
// end C code
no sweatsky! except i cannot do this in MATLAB.
...
> maybe you write your own index class:
>
> indx = myindxclass(-N/2,N/2);
>
> for ii = matlab_indx(indx)
> end;
>
> where 'matlab_indx' would convert your numbering to MATLAB numbering.
that does not help. see the code below. if i am examining the array
for some feature (like a local maximum), i must _alway_ remember to
subtract 1 from the index MATLAB gives me. if i don't i will get a
numerical error and there is no automatic mechanism that i can create
in MATLAB that will take care of this. if there were, i wouldn't be
complaining.
FINALLY:
In article <860g85$n...@acoma.mathworks.com>,
mo...@mathworks.com (Cleve Moler) wrote:
> In article <3882B3...@viconet.com>,
> robert bristow-johnson <pbj...@viconet.com> wrote:
> > the real test of arrogance will be whether or not MathWorks will take on
> > this debate or ignore it (as they have done every time in the past).
i need to backpedal a little bit. Cleve _did_ respond to me (by
telephone) within 30 minutes after i emailed him and the MathWorks CEO
about this maybe 2 years ago (and i am impressed and grateful about
this). he is the VP whom i didn't remember his name. but i
complained about this many times on comp.dsp and at least a couple of
times cross-posted to c.s-s.m and i don't believe got a response from
the company.
> > this is why i'm cross-posting to comp.soft-sys.matlab (it would seem
> > logical that they would monitor that newsgroup).
>
> Hi.
hi Cleve, how're ya been since we last talked.
> Yes, a number of us at MathWorks follow either one or both of these
> news groups. (Personally, I read c.s-s.m almost daily, but don't
> read comp.dsp very often.)
is it accurate to say that the most common use of Matlab is Signal
Processing and that is the most sold Toolbox? (as if the VP will
release internal sales info. ;-)
> We've had extensive discussions, both internally and externally, about
> introducing 0-based subscripting. When he was here, Tom Krauss was
> one of the strong advocates of such a change.
i am advocating a backward-compatible _extension_, not a "change".
certainly Matlab programs that worked before should work the same with
the extension since they won't be using the extension.
also, remember Cleve, we are not just talking about "1-based
subscripting" vs. "0-based subscripting". why are you limiting the
issue to that? we should be able to define our base for any chosen
array to be _any_ finite integer. if i want to do convolution with a
non-causal impulse response, there is no good reason why a
non-realtime analysis/prototyping tool like MATLAB won't let me do
that. yet MATLAB does not let me do that. when i'm researching my
own interpolation algorithm, i want to be able to "look" into the
future. that is essentially a non-causal h[m] (nonzero for some
negative m). this extension will make that possible in addition.
> MATLAB's subscripting is based on the fact that the fundamental
> data structure is a matrix, not an array.
now it seems to me that this is a semantic difference. a 2 dim
rectangular array is a matrix. just as complex numbers are an ordered
pair of real numbers. without the additional concepts of operators,
there is not much difference between rectangular arrays and matrices
or of ordered pairs and complex numbers.
> Standard matrix notation always starts the subscripts at 1.
and i sure wouldn't wanna change that. not when i'm dealing with
standard textbook matrices.
but, here's the rub, Cleve: i also don't wanna change the standard
textbook definition and notation for the DFT:
N-1
X[k] = SUM{ x[n]*exp(j*2*pi*n*k/N) } for 0 <= k < N
n=0
or for discrete convolution:
M-1
y[n] = SUM{ h[m]*x[n-m] }
m=0
and MATLAB forces me to do that. it changes the definitions to
N
X[k] = SUM{ x[n]*exp(j*2*pi*(n-1)*(k-1)/N) } for 1 <= k <= N
n=1
M
y[n] = SUM{ h[m]*x[n-m+1] }
m=1
the meaning of X[k] and x[n] in the DFT, and h[m] in the convolution
SUM have been _quantitatively_ changed from the meaning that you will
get in _every_ signal processing and linear system textbook. this
cannot be denied.
now, as i see it, the reason why we buy MATLAB and the Sig Proc
Toolbox (and upgrades) is to save us human development time. if our
proof of concept works in a clunky slow MATLAB program that should be
relatively easy to toss together, then we know we can invest some time
sweating the details of implementation on some particular DSP chip or
CPU.
so, when we DSPers (i'm being presumptuous) use MATLAB, we want be
able to apply the equations as we see them in the textbook and are
used to using them and not have to worry about changing them to
MATLAB's definition. when we don't worry about that difference in
definition in the current MATLAB, mistakes happen. below is a simple
MATLAB program (analyzeSweep.m) extracted out of a much bigger one
where i was looking for a peak in the spectrum and then calculate the
frequency associated with that peak (which is used in other code not
listed). for the longest time, i couldn't figure out why my
calculated frequency was off by 10 Hz. when i discovered that it was
the same old MATLAB indexing bug for the umpteenth time, i got real
mad. not at myself but at MATLAB on insisting that i use different
mathematics than that in the textbooks or the literature or in my
design notebook.
for DSP (as well as many other apps that aren't a 'simple' matrix
app), this definition is not just inconvenient. it is wrong (as in
incorrect). it is mathematically incorrect (essentially saying that
the frequency of DC is 1).
> Over fifteen years, the MATLAB
> community has developed a huge collection of code that relies on
> this fact.
and _allowing_ for a different indexing base (with the default base
being identical to what it is now) would not shake that reliance at
all. what is the harm in _allowing_ for that indexing base to be user
adjusted (just as the number of rows and columns are readjustable by
using the RESHAPE function)?
> I have a suggestion. Maybe you'll think it's arrogant, but, in my
> opinion, it's the only reasonable approach at this point. It's
> a piece of notation for distinguishing 0-based subscripts from
> 1-based subscripts. It allows the use of 0-based subscripts without
> requiring any changes to MATLAB's internal functions or math libraries.
> Any 0-based subscript can be changed to a 1-based subscript by appending
> the characters "+1".
that doesn't help at all. _i_ have to remember to do this for each
new array i create. as soon as i forget (and use the correct standard
textbook definitions for DFT, etc.), i get numerical errors and no
hint of a programming error. if MATLAB is supposed to be so useful
and painless to develop signal processing prototypes, why must we have
to maintain, multiple indexing definitions, one that is the correct
accepted definition and one that is MATLAB's definition. that is
silly and unnecessary.
> At least you know we're listening.
but it's not doing any good!
FILE: analyzeSweep.m
if ~exist('inFile')
inFile = 'test.wav';
end
if ~exist('startSample')
startSample = 0; % first sample to process (MATLAB calls this 'startSample+1')
end
if ~exist('numSamples')
numSamples = 88200; % max number of samples to process
end
if ~exist('frameSize')
frameSize = 4096; % size of FFT frame
end
%[inSamples inChannels] = wavread(InFile, 'size'); % i dunno why this doesn't work
siz = wavread(inFile, 'size');
inSamples = siz(1);
inChannels = siz(2);
numInSamples = min([numSamples, inSamples-startSample]);
clear siz;
[inBuf, Fs] = wavread(inFile, [startSample+1 startSample+numInSamples]);
x = inBuf(:,1); % use left channel only
clear inBuf;
halfFrameSize = frameSize/2;
twopi = 2*pi;
halfpi = pi/2;
alpha = 1/(2*pi/3 - 4/pi) * 1/(halfFrameSize^2);
binFreq = Fs/frameSize;
hopSize = frameSize/4; % compute hop size and number of frames
numFrames = floor((numInSamples-frameSize)/hopSize);
hannWindow = hanning(frameSize); % create the input window
freq = linspace(0.0, (halfFrameSize-1)/frameSize, halfFrameSize)';
xWindowed = zeros(frameSize,1); % initialize the FFT analysis buffer
X = fft(fftshift(xWindowed));
% analyze the input signal
n = 0; % initialize input pointer
for frameIndex = 1:numFrames
xWindowed = x(n+1:(n+frameSize)) .* hannWindow; % get and window the input audio frame
X = fft(fftshift(xWindowed)); % do the FFT
% mag = log( abs(X(2:halfFrameSize+1)) .* abs(X(1:halfFrameSize)) )/2;
mag = log( abs(X(1:halfFrameSize)) );
delta = log( X(2:halfFrameSize+1) ./ X(1:halfFrameSize) );
realDelta = real(delta);
imagDelta = unwrap(imag(delta));
[maxmag, maxindex] = max(mag);
%
% f1 is the frequency estimate using the standard quadratic fit formula.
% it's for comparison to f0.
%
f1 = maxindex + 0.5*(mag(maxindex+1) - mag(maxindex-1))/(2*mag(maxindex) - mag(maxindex-1) - mag(maxindex+1)) - 1;
%
% must subtract an extra 1 because of stupid Matlab
%
imagDelta = imagDelta - twopi*round((imagDelta(maxindex)+imagDelta(maxindex-1))/(2*twopi));
ReA = realDelta(maxindex) - realDelta(maxindex-1);
ImA = imagDelta(maxindex) - imagDelta(maxindex-1);
ReB = realDelta(maxindex-1);
ImB = imagDelta(maxindex-1);
r_magA = 1/(ReA^2 + ImA^2);
beta = ImA/ReA * alpha;
f0 = (maxindex-1) - r_magA*(ReA*ReB + ImA*ImB) + 0.5 - 1; % must subtract an extra 1 because of stupid Matlab
lambda = r_magA*(ReA*ImB - ImA*ReB);
disp([beta*binFreq^2 f0*binFreq f1*binFreq]);
hold off;
subplot(3,1,1);
plot(freq(3:50), mag(3:50), 'bo');
grid on;
subplot(3,1,2);
plot(freq(3:50), realDelta(3:50), 'go');
grid on;
subplot(3,1,3);
plot(freq(3:50), imagDelta(3:50), 'ro');
grid on;
sound(xWindowed, Fs);
pause;
n = n + hopSize;
end
Peter J. Acklam
>
> we are not just talking about "1-based subscripting" vs. "0-based
> subscripting". why are you limiting the issue to that? we should
> be able to define our base for any chosen array to be _any_ finite
> integer.
In the language Perl, changing the base is trivial, you would simply
set the variable $[ to the index of the first element in an array.
The default is 0, but if you want 1-based indexing you would simply
put
$[ = 1;
at the top of your code. And, voilà, you have 1-based array indexing.
Matlab doesn't have special variables like this. And introducing
something like
set(0, 'ArrayBase', 1)
would have a global effect and mess things up completely.
At this point I don't see how anything similar could be introduced
into Matlab, but with Perl, changing the array base is trivial.
Peter
--
function f,f=(fopen(which(mfilename)));l=fgetl(f);l=fgetl(f);
J.u.s.t_.a.n.o.t.h.e.r_.M.a.t.l.a.b_.h.a.c.k.e.r=f;fclose(f);
disp(strrep(strrep(l(1:find((l)==('='))-1),'.',''),'_',' '));
Stan Pawlukiewicz
>
> i would agree with the Mathworks on this. their convention of
> indexing is easy to follow and implement. if array offsets
> are introduced, then the underlying mex files would be
> more complex. they already have to deal with Nan, Inf, empty's,
> multiple data types?, etc...
>
> programmers since the beginning of the art-- regardless
> of the language-- and it takes away our time. ;-(
>
> with MATLAB. maybe it could be 'enhanced', but at least
> it is simple enough to understand its limitations.
From my own personal preferences and inclinations the difficulty with 1
vs 0 based adressing comes into play when I go back and forth between C
and Matlab. If you look at each (C or Matlab) the relative merits of
each convention are really not that important to me. When working in
both domains, it annoys me because I make more mistakes.
I would like the option of a choice. As for the argument about backward
compatility, all I can say to the Mathworks - What about lala?
>
> you could write a function:
>
> indx = dspindx(-N/2,N/2);
>
> which would map your indicies to MATLAB indicies.
>
> and then you could do:
>
> for ii=indx(:)
> end;
>
> which has no explicit reference to what ii(1), ii(2), etc...
> is.
>
> when programmers make a mistake, i think that they try to
> come up with a system so that they no longer make that
> mistake--> just like people put their pills in containers
> labeled: "M","TU","W","TH","F","SA","SU" so that they
> wont forget to take them! ;-) certainly, the manufactures
> could label the pills, but then most people probably couldnt
> or wouldnt read the annotations anyway! if MEX or M programmers
> ignored the matrix attribute, then bad programs would be produced.
> i.e. if incompatible index vectors were generated, or
> index vectors werent interpretted correctly. because index
> vectors and matricies are loosely coupled, i think that
> the current convention makes a lot of sense -- especially
> since index vectors are of type double and can be operated
> on very efficiently.
>
> maybe you write your own index class:
>
> indx = myindxclass(-N/2,N/2);
>
> for ii = matlab_indx(indx)
> end;
>
> where 'matlab_indx' would convert your numbering to MATLAB numbering.
>
> In comp.soft-sys.matlab robert bristow-johnson <pbj...@viconet.com> wrote:
> > the real test of arrogance will be whether or not MathWorks will take on
> > this debate or ignore it (as they have done every time in the past).
> > this is why i'm cross-posting to comp.soft-sys.matlab (it would seem
> > logical that they would monitor that newsgroup).
>
> > In article <3881FDA0...@ieee.org>, jya...@erols.com wrote:
> > > The arrogance resides in the decision that users ought not be allowed to
> > > choose.
>
Steve Eddins
> but, here's the rub, Cleve: i also don't wanna change the standard
> textbook definition and notation for the DFT:
>
> N-1
> X[k] = SUM{ x[n]*exp(j*2*pi*n*k/N) } for 0 <= k < N
> n=0
Hi Robert,
This example came up in a meeting here a few years ago. I went to the
board and wrote this MATLAB code:
N = length(x);
n = 0:N-1;
k = 5; % for example
X_k = sum(x .* exp(j*2*pi*n*k/N));
This is typical of vectorized MATLAB code. Whether MATLAB's matrix
indexing is 1-based, 0-based, or 17-based doesn't appear explicitly in
the code.
I'm not claiming this is always possible. There are, of course,
situations where you can't fully vectorize the code, and so loops and
explicit indices are necessary.
Regards,
Steve
Jerry Avins
Jordon Rosenthal wrote to me the other day, my response to him is below.
I hope he didn't take it to signify agreement. I was merely expressing
my unwillingness to continue the argument. Moler's statement, "Standard
matrix notation always starts the subscripts at 1", seals it for me. It
tells me that there is a religious aspect, and that logical argument is
useless. I will therefor not try to use it: you're on your own!
Jordan Rosenthal wrote:
>
> Jerry,
>
> Cleve Moler, one of the founders of Mathworks, replied to this thread on the
> Matlab newsgroup today. ...
Jordan,
I read that response; it was well presented. It, and your thoughtful
response to me, (which I snipped), make it clear what the issues are and
dispel the impression of arrogance that I perceived. Perhaps "aloofness"
might have been a less charged way to put it.)
The fact of disagreement doesn't distress me. It is disagreement without
dialog, coupled with the appearance of arbitrariness that becomes
particularly irksome. Peace!
Jerry
--
Engineering is the art of making what you want from things you can get.
-----------------------------------------------------------------------
Jordan Rosenthal
My name keeps popping up in this thread despite the fact I only wrote one
public message! Since most of my messages regarding this issue were written
as private email, I would like to state for the record that I personally do
not care how the indexing in Matlab works.
I just do not see it as a big problem (though I understand the feelings and
concerns of those who do take issue with it). I rarely wind up using an
actual index value since I can almost always vectorize my code making the
index values irrelevant. If I ever need to use a particular index value in
my code, it is typically part of some FOR loop which I cannot vectorize. In
that case, the point is moot since I wind up writing mex files in C (with
zero indices) because of performance issues.
My original reply to Robert (in the comp.dsp newsgroup) was not written
because I had any emotional stand on the indexing issue, but because I
didn't think it was fair that he called Mathworks "arrogant".
Whether Matlab would be a better system if its indexing scheme were
extended, I do not know and have no strong opinions. Both Robert and Cleve
make valid points concerning this issue. I do strongly feel, however, that
Mathworks should not be painted as arrogant. Quite the opposite, I have
always found the staff at Mathworks to be very concerned about their users.
Just my two cents.
Jordan
Grant Griffin
>
> robert bristow-johnson <pbj...@viconet.com> writes:
> >
> > we are not just talking about "1-based subscripting" vs. "0-based
> > subscripting". why are you limiting the issue to that? we should
> > be able to define our base for any chosen array to be _any_ finite
> > integer.
>
> set the variable $[ to the index of the first element in an array.
> The default is 0, but if you want 1-based indexing you would simply
> put
>
> $[ = 1;
>
$_ = "Well, obviously. ;-)\n";
print "$_";
> at the top of your code. And, voilà, you have 1-based array indexing.
>
> Matlab doesn't have special variables like this. And introducing
> something like
>
> set(0, 'ArrayBase', 1)
>
> would have a global effect and mess things up completely.
>
> At this point I don't see how anything similar could be introduced
> into Matlab, but with Perl, changing the array base is trivial.
>
> Peter
When a vendor claims it ain't broke, he usually don't fix it...
But why try to make him, when something is available that _really_ ain't
broke? I refer, of course, to Python. Python uses zero-based arrays,
and with its support for complex numbers and matrices as built-in date
types (via Numeric Python), the essential raw ingredients for a
successor to Matlab for DSP work are there. (Although Perl has its
merits, it lacks these essential ingredients. Oh, also it reads a whole
lot like "Perl", e.g. "$[" (GMWAS! ;-)
Best of all, if there ever _is_ something about Python that rb-j finds
objectionable, he's free to change that, via the miracle of open source
software and Python's "wide open" license. (Imagine if all that energy
spent vainly trying to motivate porculent software vendors could instead
be directed toward creating a comprehensive DSP library for Python...)
>
> --
> function f,f=(fopen(which(mfilename)));l=fgetl(f);l=fgetl(f);
> J.u.s.t_.a.n.o.t.h.e.r_.M.a.t.l.a.b_.h.a.c.k.e.r=f;fclose(f);
> disp(strrep(strrep(l(1:find((l)==('='))-1),'.',''),'_',' '));
=g2
print "Just another programmer who thinks Python is more readable than
Perl and cheaper than Matlab."
--
_____________________________________________________________________
Grant R. Griffin g...@dspguru.com
Publisher of dspGuru http://www.dspguru.com
Iowegian International Corporation http://www.iowegian.com
Michael C Schweisguth
In comp.soft-sys.matlab robert bristow-johnson <pbj...@viconet.com> wrote:
> [stuff deleted] fortunately, i am not depending on popular support
> from comp.soft-sys.matlab as justification of my complaint.
i think that issues such as "speed," "real functionality", and "costs"
would have priority over what some may think of as "eye candy."
having "try" and "catch" as well as structures and classes
allowed many people (i would think) to create full scaled
applications for the first time.
i would highly doubt that an index base feature would have
such an impact on the bottom line.
> not at all! MathWorks engineers know where, in their source, they can
> find the code that explicitly checks for indices being out of bounds
> for a particular matrix (or 'array') when an element is being
> addressed directly and in a matrix on matrix operation, where the
> matrix dimensions are checked for compatibility. it is only here
> that MATLAB would have to be modified [...]
what are the "new semantics" of the find command:
indx = find(A>0);
vs:
indx = find(0<A);
does indx use the bounds associated with A or the scaler 0? this
issue, it seems, must be addressed when temporarys are created.
if vector A has a base of "-N/2", what base does B have here:
B = A(-1);
perhaps -1?
sure, BASIC allows you to set the lower bounds of a matrix,
but BASIC doesnt ( i think ) allow complex expressions like
MATLAB does.
supporting "union" and "intersection" and "subset" operations
on "lower bounds" attribute calculations doesnt seem simple.
> MathWorks would never divulge their source code to me, but if they
> did, i bet i could find all of the necessary spots to possibly modify
> in a day. no sweat.
wow!
> not in C. i can define any finite integer base i want for a C array.
> my_array = &(_my_array[256]);
> for (i=-256; i<256; i++) {
> }
> no sweatsky! except i cannot do this in MATLAB.
sure you can!
myvector = PlusMinusVector(-256,256);
for ii = -256:256
myvector(ii) = ??
end;
here, PlusMinusVector is a class, and subsasgn handles the
assignment--> maps ii to a "matlab/matrix index."
this would be slow, but it wouldnt force a speed penality on those
who are willing to put up with matrix indexing. and, an mcc
compiled mex file wouldnt have to have a speed penalty either.
>> maybe you write your own index class:
> that does not help.
have you tried using a "class wrapper" and tried to overload
"subsasgn"?
robert bristow-johnson
> > textbook definition and notation for the DFT:
> >
> > N-1
> > X[k] = SUM{ x[n]*exp(j*2*pi*n*k/N) } for 0 <= k < N
> > n=0
>
>
> This example came up in a meeting here a few years ago. I went to the
> board and wrote this MATLAB code:
>
> N = length(x);
> n = 0:N-1;
> k = 5; % for example
> X_k = sum(x .* exp(j*2*pi*n*k/N));
>
> This is typical of vectorized MATLAB code. Whether MATLAB's matrix
> indexing is 1-based, 0-based, or 17-based doesn't appear explicitly in
> the code.
i have absolutely no idea how this is helpful for anything. X_k is a
number. big deal! why don't you examine the little program i posted
and tell me how to avoid the inelegant index correction that must be
done to get the right answer on frequency (look at 'f0' and 'f1')?
there is no way with MATLAB, as it exists presently (and likely to exist
in the future until the base can be user adjusted), that i can examine
an array from the DFT [or fft(fftshift()) as it is done in MATLAB] so
that when i find any feature in the resulting DFT that i can, using the
equations they give us in any textbook, compute the frequency associated
with that feature unless i subtract 1 from the array index. this need
to change the math to subtract 1 is not from the basic math as depicted
in the texts or literature. it is a consequence _only_ of a rigid
MATLAB definition that is unlike the convention in the literature.
so when we read papers or write papers, if we want to stick with the
convention of the DSP lit (and we _want_ to stick with the convention
because it is certainly simpler and more elegant than the MATLAB
definition besides the fact that journal reviewers would puke at the
math if expressed with the MATLAB definition), we have to write our
equations one way. when we implement the algorithm in C or C++ or even
assembly, within the contexts of those languages, those equations are
implemented as they are written. but when we want to implement the
_same_ algorithm in MATLAB, we _must_ (we have no choice in the matter)
modify those equations to satisfy a rigid requirement of MATLAB that no
array (or 'matrix' to satisfy Cleve's semantic) in MATLAB shall have no
non-positive index.
there are times when, to hold to accepted convention, the first element
of an array has the subscript of 1. i fully recognize that. but it's
not when you are doing the Discrete Fourier Transform or Discrete
Convolution (there are other cases in addition). for MathWorks to
insist on that defies the convention of DSP, communications, and linear
system texts and the published literature on the subjects. it forces
us, against our better judgement, to follow suit if we want to prototype
our algorithms on MATLAB (which, for many reasons, is a useful tool for
that purpose, despite this unnecessary and ugly wart). it forces us to
gunk up our code, making it vulnerable to difficult to find and
unnecessary errors.
as Jerry pointed out, MathWorks cannot win this argument with logic.
they cannot because, implementing the _option_ to change the base with
the default base remaining as it is destroys any valid argument about
backward compatibility or any "...the MATLAB community has developed a
huge collection of code that relies on this..." rigid, unadjustable
base. it's bullshit and Cleve or anyone else at Mathworks is unable to
point to existing code that would stop working if this option were put
in MATLAB. i challenge anyone at MathWorks or anyone else on c.s-s.m to
come up with an example of code that would stop working (the very small
hit on speed and memory usage not being used as criteria).
so why _don't_ you just be honest and say "MathWorks will not bother to
do the small amount of work necessary to bring their primary product up
slightly to a level of flexiblity so that it can be used by the signal
processing community without having to obfuscate the expression of
commonly accepted conventional formulae." what does it take to be
important to you guys? don't you want the product to be elegant? if
you say it's elegant the way it is, you should read the help file on the
conv() function.
listen for $1000, i'll drive up there, sign an NDA, spend an hour
getting briefed on the internal structure of the MATLAB variable (i'm
thinking C here), do a little bit of greping (or whatever search utility
you have), show you where the code needs to be changed, and go home. it
will be backward compatible and will satisfy the needs i have been
talking about. a very small price to pay, don't you think, Cleve?
MathWorks would be getting a steal, and i _know_ that future DSPers will
thank me for it.
once this gets fixed in the MATLAB kernal, a function similar to
reshape() would need to be written to change to base of a MATLAB
variable from 1 to whatever. then the _user_ (like me) can make simple
rewrites of our _own_ conv() or fft() or whatever that adjusts the base
(back to 1) and calls the old MATLAB equivalent function.
this is simple.
it's foolproof.
it fixes a serious shortcoming of MATLAB.
there is no good reason for not fixing it.
if MathWorks is confident there are good reasons for not fixing this,
i'm sure there is someone there smart enough to construct a persuasive
argument. that persuasive argument would have to contain a defensible
example of existing code that would break if this fix was made or
('snicker') a convincing argument that the existing rigid '1-based
indexing' is more elegant or adheres more to accepted convention in DSP
literature.
so are you guys up to it? or will you just kick back and say "it isn't
the MATLAB way, we don't need to fix it nor do we need to defend it
logically."
(oh, and BTW, can you guys fix the stupidities in the Mac-based MATLAB
text editor that i emailed you about months ago? it's really stupid and
it's amazing this got past alpha testers, let alone any beta testing.)
Robert Bielik
pbj...@viconet.com wrote:
> okay, this is going to be a long one and one that i approach with
trepidation (sp?)
> not many posters (as in none except for Jerry Avins) are supporting me
on
> this.
I have too many times cursed Matlab for the stupid indexing. Possibly
not Quasar-stupid, but pretty much up to singularity stupid... ;-)
/Rob
Sent via Deja.com http://www.deja.com/
Before you buy.
John W. Eaton
> listen for $1000, i'll drive up there, sign an NDA, spend an hour
> getting briefed on the internal structure of the MATLAB variable (i'm
> thinking C here), do a little bit of greping (or whatever search utility
> you have), show you where the code needs to be changed, and go home. it
> will be backward compatible and will satisfy the needs i have been
> talking about.
I know absolutely nothing about Matlab internals, but my guess is it
would take more than an afternoon to identify everything that needs
changing without breaking anything...
If you want the freedom to change fundamental features of the software
you are using, then you are using the wrong kind of software if you
use Matlab.
Grant Griffin already pointed out that you could modify Python to suit
your needs, because it is free software. However, Python may not be
close enough to Matlab for you. If you want something more compatible
with Matlab and that is also free software (so you have the freedom to
modify it to suit your needs), then maybe what you are looking for is
GNU Octave (http://www.che.wisc.edu/octave).
Here are some possible ways to get non-zero-based arrays in Octave.
First, come up with a spec for introducing non-zero-based arrays in
Octave in such a way that it doesn't cause trouble for existing
code, then
* Implement the changes yourself and contribute them to the Octave
project for everyone to use.
* Provide funding for someone else to do the work for you.
* Wait around for someone else to do the work for you.
If non-zero-based arrays catch on in Octave, then maybe The MathWorks
will `see the light', copy the idea, and put it in some future version
of Matlab (with some annoying little incompatibilities, of course). :-)
jwe
--
In the beginning, Ken Thompson | Octave: http://www.che.wisc.edu/octave
wrote the searching tool grep. | Me: http://www.che.wisc.edu/~jwe
-- A. Hume, SP&E (1988) |
John W. Eaton
> Here are some possible ways to get non-zero-based arrays in Octave.
Uh, of course, I meant arrays with index bases not equal to ONE, not
zero (if they were already zero-based, I guess the other half of you
would be happy, and the other half would still want to be able to set
the base to be something other than zero or one :-).
Marius Vollmer
> Here are some possible ways to get non-zero-based arrays in Octave.
> First, come up with a spec for introducing non-zero-based arrays in
> Octave in such a way that it doesn't cause trouble for existing
> code, [...]
I'd like to see smething like that, too. My idea is to have some kind
of `displaced', `aliased' or `indirect' arrays. Such a indirect array
would not have storage space itself, it would just refer to another
array, with a linear index transformation inbetween and maybe some
rules for out of range indices.
With such a facility, it should be possible to have a convenient
notation for block-matrices, vectors that are infinite but non-zero
only in a finite range, and of course arbitrary-based arrays.
I have no idea how feasible this is in the current Octave
implementation, i.e. if there is any memory management strangeness to
overcome. I also don't have specific ideas for a nice notation, maybe
something like this:
A = randn(4,4);
zA = displace (A, { i: i+1 }, { j: j+1 } );
bA = displace (A, { i: [2*i:2*i+1] }, { j: [2*j:2*j+1] } );
so that
zA(i,j) = A(i+1,j+1)
that is, zA is a zero based version of A and, for example,
bA(0,0) = zA(0:1, 0:1)
that is, bA is a block view of zA.
The strange { args: result } construct is my shorthand for an
anonymous function.
Just an idea. What ideas has APL to offer?
- Marius
Jordan Rosenthal
Again, I am bowing out of a public debate because I don't really care. I
can see valid points on both sides of this issue. I am firm in my
ambivalence! :)
I think, however, I can solve one of your problems:
> and tell me how to avoid the inelegant index correction that must be
> done to get the right answer on frequency (look at 'f0' and 'f1')?
This shows how to get the f1 in Hz without the index getting explicitly
involved:
% f = Frequency vector in Hz corresponding to half the fft
% kk = Indices of the three points used in the quadratic fit
% f1_InHz = Should be equivalent to what you calculated with f1*binFreq
f = 0 : binFreq : fs/2 - binFreq;
kk = maxindex - 1 : maxindex + 1;
f1_InHz = interp1(kk, f(kk) , maxindex + <expr> , '*linear');
where <expr> is the quadratic fit (without the minus 1) stuff. The amount
of extra processing here is minimal; it should be very fast. From your
code, I wasn't sure what the signal processing involved in finding f0 was
doing, but I imagine the same or similar technique would work.
Anyway, I hope this technique will help to alleviate some of your headaches
in the future.
Jordan
Jerry Avins
>
[snip]
>
> so why _don't_ you just be honest and say "MathWorks will not bother to
> do the small amount of work necessary to bring their primary product up
> slightly to a level of flexiblity so that it can be used by the signal
> processing community without having to obfuscate the expression of
> commonly accepted conventional formulae." what does it take to be
> important to you guys? don't you want the product to be elegant? if
> you say it's elegant the way it is, you should read the help file on the
Robert,
That's not the point. They _are_ being honest. It's not the work that
they object to. They are saying, "Matlab is beautiful the way it is; you
want us to scar it." This is a quasi religious stand, and you are asking
them to alter or abandon their religion. Weep for them, but give it up.
You cannot save their corporate soul.
Denis Gilbert
<3886B0...@viconet.com>...
> that persuasive argument would have to contain a defensible
> example of existing code that would break if this fix was made or
> ('snicker') a convincing argument that the existing rigid '1-based
> indexing' is more elegant or adheres more to accepted convention in DSP
> literature.
Hi Robert,
I have been reading this thread with interest because you are touching a
very fundamental language issue. When I was first introduced to Matlab in
1988, I really enjoyed its general intuitive feel and it quickly displaced
FORTRAN as my favorite programming language. The only non-intuitive
feature of Matlab that caused me some difficulty back then was the absence
of 0-based indexing for digital signal processing applications. So I do
feel sympathy for the points you raised in this thread. What I lack is a
full appreciation of the complexity involved in making the adjustments you
request while maintaining backward compatibility and not putting too much
overhead on memory usage and execution speed. A persuasive argument along
the lines of what you are describing above would indeed help in my opinion.
Just my 2 cents. Denis Gilbert
robert bristow-johnson
In article <8661ss$o60$1...@news.ccit.arizona.edu>, Michael C Schweisguth
>
> In comp.soft-sys.matlab robert bristow-johnson <pbj...@viconet.com> wrote:
>> from comp.soft-sys.matlab as justification of my complaint.
>
>
> what are the "new semantics" of the find command:
>
> indx = find(A>0);
>
> vs:
>
> indx = find(0<A);
>
> does indx use the bounds associated with A or the scaler 0?
i haven't thought about find() (i never use it) but i guess it would work
the same as before except, if the index base had been adjusted from the
MATLAB default, the indices returned in A would be the offset by the same
amount.
> if vector A has a base of "-N/2", what base does B have here:
>
> B = A(-1);
>
> perhaps -1?
isn't A(-1) a scaler? wouldn't B be just be a scaler (or a 1x1 matrix)?
to be backward compatible, any newly created variable would have a base of 1
until someone calls a routine that changes the base. so that 1x1 matrix, B,
would have a base of 1 unless it existed previously as a 1x1 and the base
was adjusted (in that case only the data would change).
>> MathWorks would never divulge their source code to me, but if they
>> did, i bet i could find all of the necessary spots to possibly modify
>> in a day. no sweat.
>
> wow!
listen, deep in their kernal there can be only a couple places (probably
one) where indices are checked to be within bounds and an integer (when a
user does a direct reference to an element as in A(5)). before that test is
made is when the offset is added to the index (and since the offset is
defaulted to 0, this insures backward compatibility). likewise, deep in
their kernal there can be only a couple places (probably one) where the
number of rows and columns of two different matrices are being checked to
insure compatibility (given whatever the operator is). this is where you
would check, for all operations where an adjusted base doesn't make sense,
that the base is 1 and print unfriendly diagnostics if the base is not.
that's it. what else must be modified? okay creating a new variable and
the structure typedef (i think in terms of C) would need to be changed a
little also to add the field where this base (or index offset) goes and init
it to 1 (or 0, if it's an offset). that's it.
>> not in C. i can define any finite integer base i want for a C array.
>
>> my_array = &(_my_array[256]);
>> for (i=-256; i<256; i++) {
>> }
>
>> no sweatsky! except i cannot do this in MATLAB.
>
> sure you can!
>
> myvector = PlusMinusVector(-256,256);
>
> for ii = -256:256
> myvector(ii) = ??
> end;
>
> here, PlusMinusVector is a class, and subsasgn handles the
> assignment--> maps ii to a "matlab/matrix index."
now this is new and substantive (to the present debate).
i am not a C++ programmer even though i have to dabble in our Wave Mechanics
code (for our plug-ins for Digi Pro Tools which is C++). i do understand
the concepts of encapsulation, inheritance, and operator overloading. i
have _big_ trouble with the nitty gritty of C++ syntax (i do fine with C, in
fact many C++ books say it's harder to teach a C programmer C++ than a total
newbie) and have never written a _real_ C++ program from scratch.
i knew that there is OOP in MATLAB but it didn't dawn on me that one can
define a class that looks just like an old MATLAB array but does index
adjusting before looking up (or writing) the value in the array. you would
have to overload an awful lot of operators but this looks like it could be
the ticket (since, as Jerry points out, MathWorks won't fix this). gee,
maybe it could be extended to that, if the index is non-integer,
interpolation would be done, or if the index is beyond the bounds, (virtual)
zero-padding or modulo wrap around (this would be handy for DFT sequences
since, fundamentally, the DFT maps one periodic sequence to another periodic
sequence) would be done. "interrresting..."
gee, i wonder if somebody did this already and is willing to share it? it
will take me weeks (i will have to start with reading Chapters 14 and 13 in
the "Using MATLAB" book), but if i do it, i will happily share it with the
DSP community.
--
r b-j (at work)
Wave Mechanics, Inc. http://www.wavemechanics.com/
tel: 973/746-9417 rob...@wavemechanics.com
fax: 973/746-0762 rob...@audioheads.com
Grant Griffin
>
> robert bristow-johnson <pbj...@viconet.com> writes:
>
> > listen for $1000, i'll drive up there, sign an NDA, spend an hour
> > getting briefed on the internal structure of the MATLAB variable (i'm
> > thinking C here), do a little bit of greping (or whatever search utility
> > you have), show you where the code needs to be changed, and go home. it
> > will be backward compatible and will satisfy the needs i have been
> > talking about.
>
> would take more than an afternoon to identify everything that needs
> changing without breaking anything...
>
> If you want the freedom to change fundamental features of the software
> you are using, then you are using the wrong kind of software if you
> use Matlab.
>
> Grant Griffin already pointed out that you could modify Python to suit
> your needs, because it is free software.
I guess I was hoping he would supplement it more than modify it; I think
it's fine, as is: it just needs more DSP stuff.
> However, Python may not be
> close enough to Matlab for you. If you want something more compatible
> with Matlab and that is also free software (so you have the freedom to
> modify it to suit your needs), then maybe what you are looking for is
> GNU Octave (http://www.che.wisc.edu/octave).
While Octave's high degree of compatability with Matlab is one its many
merits, I believe--paradoxically--that Python's high degree of
_incompatability_ with Matlab is one of _Python's_ merits. Python has a
very clean and simple syntax, and a deliberately sparse but unified and
very powerful set of features. The "clean and simple" thing (a theme in
Python) continues in its approach to classes (objects), which were
designed into the language from the start, not bolted onto the side
later. Therefore, instead of being designed as a "matrix laboratory",
Python was designed as a "programming language"--which long ago was
extended to support complex variables and matrices as data types, thus
extending it into a "matrix laboratory". ("Is it a desert toping/No
it's a floor wax/No it's both!")
For DSP work, Python currently lags Matlab "as a system" because only a
few DSP functions are now available. However, if DSPers want to spend
effort developing a free/open interpreted programming system for DSP
work, I believe Python is the best starting point. With all respect to
John W. Eaton and his efforts on Octave, the problem with any system
which is highly compatible with Matlab is that its major strength will
always be that it is free and open. Therefore, those who are willing to
pay (which seem to be large numbers of people...) and who don't care
about software being "closed" (which seem to be large numbers of
people...most people want to use a system, not modify or fix it) will
buy the commercial product. The commercial product is likely to be
ahead in technical terms, because it gets more development resources.
(For example, a job ad from TMW which was recently posted in comp.dsp
revealed that they have about 200 employees. Yet John W.
Eaton--amazingly--has written most of Octave himself. Then again, maybe
TMW has one guy writing code and 199 people sending out direct mail. ;-)
OTOH, if a different (that is, incompatible) programming language offers
some real advantages as the basis for a new DSP system analysis and
simulation tool--in this case its clean, simple, extensible, portable,
modern design--then it actually has the potential to one day achieve
"world domination". Yup, even if it's free. And since Python is first
a "programming language", it already has a strong community of its own
whose efforts leverage into DSP work. (For example, a *very nice* free
Python IDE is currently available for Windows, as well as many other
goodies.)
That's why--while recognizing the considerable value of Octave within
the framework of what it's trying to be--I feel that comp.dsp, as a
community, should focus development efforts like this (if any) on
creating a Python system for DSP. If wildly successful, such efforts
would attract users not just because the software is free, but because
we have created a better system. ("Now how much would you pay?/But
wait, there's more.")
(BTW, rb-j, if anybody has the *skills* to write a "DSP toolbox" for
Python, it's you. Heck, I bet you could lick it in an hour or two. ;-)
>
> Here are some possible ways to get non-zero-based arrays in Octave.
> First, come up with a spec for introducing non-zero-based arrays in
> Octave in such a way that it doesn't cause trouble for existing
> code, then
...
Did I mention that Python arrays are already zero-based? ;-)
=g2
Michael C Schweisguth
In comp.soft-sys.matlab robert bristow-johnson <rob...@audioheads.com> wrote:
> In article <8661ss$o60$1...@news.ccit.arizona.edu>, Michael C Schweisguth
> <msch...@u.arizona.edu> wrote:
> i haven't thought about find() (i never use it) but i guess it would work
> the same as before except,...
it is the "semantics" which need to be preserved "everywhere," not
just in a few key locations.
> > if vector A has a base of "-N/2", what base does B have here:
> >
> > B = A(-1);
> >
> > perhaps -1?
> isn't A(-1) a scaler? wouldn't B be just be a scaler (or a 1x1 matrix)?
since B isa *matrix* of size 1x1, B is both a scalar and a matrix.
if matrix A has a base index that is not 1, then what is the base
index of matrix B.
>> here, PlusMinusVector is a class, and subsasgn handles the
>> assignment--> maps ii to a "matlab/matrix index."
> now this is new and substantive (to the present debate).
well, i think that I added two things to this debate:
1) what are the "semantics" of the "union" and "intersection" of
matrices having different or same base indexes. the Mathworks
compiler team would need to know how to "propagate" the
"base index" attribute in the calculation. i.e. they
need a "base index" algebra. BASIC is far less sophisticated
than MATLAB and doesnt need it (i think). example:
B has base 1;
C has base 0;
A = [B;C]; % was is the base of A.
the semantics of [] seem to be difficult enough!
2) suggesting a class.
> you would have to overload an awful lot of operators but this looks
> like it could be the ticket
only "subsref" and "subsasgn" would have any meat to them. the rest
would simply be wrappers.
for example, when you call:
strcmp({'a','b','c'},'a')
the Mathworks has a function:
@cell/strcmp
which calls the 4.2c version of strcmp.
thus, users of strcmp('a','b') arent penalized by the overhead
of the @cell version.
for example, you would have to do:
@myclass/fft
function result fft(obj)
result = myclass(fft(obj.data));
or you could do:
fft(double(myclass_instance))
since you want clean code, the @myclass/fft seems to by your ticket.
>(since, as Jerry points out, MathWorks won't fix this).
technically, nothing is broken with regards to "base index."
making a quick change could really break things. for example,
if A is a class, then:
A(-N/2,N/2)
would invoke subsref() and it is not clear to me wether MATLAB
should change -N/2 to 1 and N/2 to (N + 1) before subsref is
called.
luckily, the Mathworks left well enough alone so that this
kind of thing isnt an issue.
robert bristow-johnson
>
>
> Whether Matlab would be a better system if its indexing scheme were
> extended, I do not know and have no strong opinions.
how would it hurt? it's backward compatible.
> Both Robert and Cleve
> make valid points concerning this issue.
what valid points did we make? i think the only point that i understand
that Cleve made was demonstrated to be not valid (and he has not
responded to that). nothing bad would happen to MATLAB legacy code
except that perhaps .mex files may need to be recompiled.
> I do strongly feel, however, that
> Mathworks should not be painted as arrogant.
probably, too strong of a word.
> Quite the opposite, I have
> always found the staff at Mathworks to be very concerned about their users.
i haven't found it quite the opposite. not one single bug or complaint
that i have sent to MathWorks has been resolved satisfactorily (or
resolved at all). other than a response that acknowledged receipt of
the bug report (or that phone call from Cleve in which he said basically
the same as we have read here, that this fix is undoable, without any
justification that holds water), i got nothing from MathWorks support.
here is the latest example: (i am shaming them because i am confident
that they will never bother to fix this bug, if it were otherwize, i
would bite my tongue waiting with bated breath for the fix.)
anyway, we have the final Mac version of MATLAB (plus the Sig Proc
Toolbox) at work since our current product platform is 98% Mac
(Digidesign Pro Tools). it is the "final" version because MathWorks has
stated, a couple of years ago, that no more version upgrades to the Mac
are planned. this was before the iMac and the other cool Macs came out
so i might be hopeful that they would resume this support for the Mac
given Apple's new lease on life. the MATLAB text editor is okay, i
guess, but they adopted text editing conventions that flagrantly
contradict every other Mac text editor that i know of. so it's like
going from Mac to PC but instead of remembering to switch from Cmd-C
('Alt' is the same position as the Apple Cmd key) to Cntl-C, i have to
remember to that Cmd-E does not [enter selected text into Find command
window] but _executes_ the frontmost MATLAB program. that was a rude
awakening! so i have to remember whether i'm using Code Warrior (or
THINK or MPW) or using MATLAB when i'm doing simple text editing
operations.
here is the worst bug that i told them about months ago and all i got
was an acknowledgement of receipt of email: for some really stupid-ass
reason, the underscore '_' character is not considered an identifier
token (like alphanumeric chars) by the MATLAB editor even though the
char is a legit identifier token for the MATLAB syntax. it treats '_'
as a delimiter. e.g. "my_variable" is a legit MATLAB variable. works
just fine. until you double-click it to select that word. then,
depending on where exactly your mouse is, "my" or "_" or "variable" is
selected. so you hafta drag the mouse through the whole word to select
it. no other text editor or word processor does that.
on the other hand, the minus '-' character is treated by the MATLAB
editor as part of the word if not delimited by a space. e.g. if you
double-click anywhere on "numSamples-startSample", the whole thing is
selected. THIS IS ASININE. no other programmer's text editor does
that. it is inexcusable. do they do beta testing or even alpha testing
on that component of their product? i can hardly believe that anyone
who uses the editor even 5 minutes wouldn't have come across this bug.
why don't they fix it? because it's perfect the way it is?
robert bristow-johnson
>
> Robert,
>
> Again, I am bowing out of a public debate because I don't really care. I
> can see valid points on both sides of this issue. I am firm in my
> ambivalence! :)
>
> I think, however, I can solve one of your problems:
>
> > done to get the right answer on frequency (look at 'f0' and 'f1')?
>
> involved:
>
> % f = Frequency vector in Hz corresponding to half the fft
> % kk = Indices of the three points used in the quadratic fit
> % f1_InHz = Should be equivalent to what you calculated with f1*binFreq
>
> f = 0 : binFreq : fs/2 - binFreq;
> kk = maxindex - 1 : maxindex + 1;
> f1_InHz = interp1(kk, f(kk) , maxindex + <expr> , '*linear');
>
> where <expr> is the quadratic fit (without the minus 1) stuff. The amount
> of extra processing here is minimal; it should be very fast. From your
> code, I wasn't sure what the signal processing involved in finding f0 was
> doing, but I imagine the same or similar technique would work.
i probably should've left it out but i think it will be harmless.
> Anyway, I hope this technique will help to alleviate some of your headaches
> in the future.
on the surface, it looks even worse than having to remember to subtract
1 from the MATLAB DFT index. the problem is systemic, Jordan. there
are many other examples that the rigid indexing of MATLAB causes a
problem (but i am not going to extract). maybe the suggestion of
Michael Schweisguth to create a class for this will be the best solution
short of MathWorks fixing the bug.
Jordan Rosenthal
> > Whether Matlab would be a better system if its indexing scheme were
> > extended, I do not know and have no strong opinions.
>
> how would it hurt? it's backward compatible.
Point taken, but only as long as it is backwards compatible AND does not
open other cans of worms. For example, another person mentioned a problem
when doing things like:
A = setindex(A,-2); % Pseudo-code to set index for A to -2
B = setindex(B,-3);
A = 3; % So A(-2) = 3
B = [ 5 4 3 4 5 4 ] % So B(-3) = 5;
C = 1:6;
A = [ B C ]; % (*)
A = [ reshape(A,2,6) [C ; C] ]; % (**)
A.Data = 'Hi mom.'; % (***)
What should Matlab do in the last three lines above?
1) Viewpoint #1: A variable should always use the index as given if we set
it with setindex. In this case, the first element of A in the line marked
(*) would be -2 and the top corner of the matrix marked (**) would be
(-2,-2).
In the line marked (***), A is now a structure with size 1x1. To be
consistent, Matlab should then only allow you to use A(-2).Data.
2) Viewpoint #2: Whenever you use a variable on the left of the equals sign
you are in a sense creating a new variable. Then, the index in (*) should
start at 1 and the index in (**) should start at (1,1). The index for (***)
is also 1.
One of the problems with viewpoint #1 is that a programmer has to in some
sense worry about declarations. Forgetting that a variable was declared
with a certain index could cause problems. (Maybe as bad as forgetting to
subtract 1 from an index. Sorry. That was snotty, but I couldn't resist.
:) ). One of the nice things about Matlab is that you can redefine a
variable without having to declare it.
Another problem would be that it would add more work for the compiler since
it now would have to figure out if it needs to continue to associate an
index with a particular variable. Will this affect performance, I don't
know...I am not an expert.
In addition, it is not clear to me that when changing from a matrix to a
structure (i.e., going from line (**) to line (***)) that the setting for
the indices for the matrix should migrate to the structure. Since the data
contained (***) is of a different nature than (**) it feels like a new
variable. This makes me feel that it should default to a starting index of
one. If we were to be consistent with viewpoint #1, however, it should
start at negative two.
As another person wrote, you would also have problems when using the find
command. What would statements like
x = -5:5;
y = setindex(y,-10);
y = m*x + b;
lessThanZero = find(x<0);
y(lessThanZero) = 0;
do? In this case, the variable lessThanZero = [1 2 3 4 5] because the index
of x starts at one. The last line would normally set the value of y to
zero whenever x is less than zero. If the index of y were changed, this
would have no meaning.
Aside: I was amazed to hear that you never use the find command. I would
suggest learning about it. I "find" it one of the most helpful commands in
Matlab. :)
Anyway, my point with all this is that changing the indexing system may
create some sticky problems. Your quick "one-day" fix is just not
realistic. This is not to say that it cannot be done; if you can work out a
solution, great. But before you continue to write more inflammatory
messages about this issue, be sure to take the time to consider all aspects
of it.
> what valid points did we make? i think the only point that i understand
> that Cleve made was demonstrated to be not valid (and he has not
> responded to that). nothing bad would happen to MATLAB legacy code
> except that perhaps .mex files may need to be recompiled.
I apologize ahead of time if I make a mistake putting words in both your
mouths, but this is my perception of your arguments:
Your point: If the change can be backwards compatible, will not affect
performance, and will increase Matlab's usefulness, why not do it.
Cleve's point: Matlab is built around the idea of a matrix and is the
mindset that is encouraged when programming in Matlab. Therefore, the
standard that indices for matrices start at one should be used.
The key to winnning anyone over to your argument is supporting the IF
clause. The key to winning anyone over to Cleve's argument is proving that
the adherence to this mindset is worth it in the face of any benifits from
making the change.
And yes, I feel that both points are valid to varying degrees.
> i haven't found it quite the opposite. not one single bug or complaint
> that i have sent to MathWorks has been resolved satisfactorily (or
> resolved at all). other than a response that acknowledged receipt of
I am sorry to here that; the bugs I have reported have been fixed. The
support staff has also seemed to go out of their way to help me when I have
had problems. I just recently had someone from Mathworks send me an updated
file after reading a newsgroup article I wrote....without me soliciting it.
All the Mathworks staff I have communicated with have been cordial,
knowledgable, and helpful. Maybe I just keep getting lucky, but I doubt it.
> here is the worst bug that i told them about months ago and all i got
> was an acknowledgement of receipt of email: for some really stupid-ass
> reason, the underscore '_' character is not considered an identifier
> token (like alphanumeric chars) by the MATLAB editor even though the
> char is a legit identifier token for the MATLAB syntax. it treats '_'
> as a delimiter. e.g. "my_variable" is a legit MATLAB variable. works
> just fine. until you double-click it to select that word. then,
> depending on where exactly your mouse is, "my" or "_" or "variable" is
> selected. so you hafta drag the mouse through the whole word to select
> it. no other text editor or word processor does that.
I can see how you might think this is irksome, but I would not characterize
it as a bug. I actually like the fact that it works that way! To me, each
section of a variable like my_variable is a different word and the ability
to highlight each word is, in fact, desirable.
Two other common text editors/word processors do the same thing on my
machine: Microsoft Word and EMACS (running on Windows). I know these
programs have no reason to treat my_variable as a single entity, but it does
seem to be a standard way of working.
I am confused. You said none of the bug fixes you reported were fixed and
you also said you work on Macs. Did I get that right? How would you expect
to get a bug fixed that you reported only months ago if there are no future
versions of the software on that platform? I assume you meant that you
reported the bug before the latest Mac version was released?
> on the other hand, the minus '-' character is treated by the MATLAB
> editor as part of the word if not delimited by a space. e.g. if you
> double-click anywhere on "numSamples-startSample", the whole thing is
> selected. THIS IS ASININE. no other programmer's text editor does
This does NOT happen in my any of the Windows versions I have (Matlab
5.1--Matlab 5.3).
Jordan
Doug Schwarz
> [...] MathWorks has
>stated, a couple of years ago, that no more version upgrades to the Mac
>are planned. this was before the iMac and the other cool Macs came out
>so i might be hopeful that they would resume this support for the Mac
>given Apple's new lease on life.
I agree with this, obviously.
>the MATLAB text editor is okay, i
>guess, but they adopted text editing conventions that flagrantly
>contradict every other Mac text editor that i know of.
[snip]
>i have to
>remember to that Cmd-E does not [enter selected text into Find command
>window] but _executes_ the frontmost MATLAB program. that was a rude
>awakening!
You can easily change this with ResEdit. Email me for details if you
are interested.
>here is the worst bug that i told them about months ago and all i got
>was an acknowledgement of receipt of email: for some really stupid-ass
>reason, the underscore '_' character is not considered an identifier
>token (like alphanumeric chars) by the MATLAB editor even though the
>char is a legit identifier token for the MATLAB syntax. it treats '_'
>as a delimiter. e.g. "my_variable" is a legit MATLAB variable. works
>just fine. until you double-click it to select that word. then,
>depending on where exactly your mouse is, "my" or "_" or "variable" is
>selected. so you hafta drag the mouse through the whole word to select
>it. no other text editor or word processor does that.
I agree that this is not ideal, but you are wrong to say that no other
editor does it. BBEdit works the way you want, but Alpha (a very nice
shareware editor) works the same way as the MATLAB editor.
>on the other hand, the minus '-' character is treated by the MATLAB
>editor as part of the word if not delimited by a space. e.g. if you
>double-click anywhere on "numSamples-startSample", the whole thing is
>selected. THIS IS ASININE. no other programmer's text editor does
>that. it is inexcusable. do they do beta testing or even alpha testing
>on that component of their product? i can hardly believe that anyone
>who uses the editor even 5 minutes wouldn't have come across this bug.
>why don't they fix it? because it's perfect the way it is?
Again, I agree that this is not ideal, but there is a simple solution:
use spaces on both sides of '-'. You should do this for readability
anyway (in my opinion).
In fact, I have been using Mac-MATLAB for about 12 years and I have
never noticed it simply because I do always use spaces. I also did
alpha and beta testing of MATLAB 5. So please believe that I have used
the editor for a bit more than 5 minutes. It simply does not matter to
me at all. Very little software works *exactly* the way I want so I
just deal with it.
Robert, you should learn to be a little more tolorant; you'll live
longer. If you can't do that then I recommend that you use only
software that you have written yourself (or can modify to meet your
stringent requirements).
Also, I agree with Jordan's latest post on this subject. For the way
you work you don't see what problems having different base indices could
cause, but there are people using MATLAB in very different ways from
you. Please don't think you know everything; you don't. It is
certainly ok to voice your opinion on this matter, but I find your
know-it-all tone to be rather condescending and unappealing. You can't
berate people in public (or private) and then expect them to modify
their world view to suit you.
--
Doug Schwarz
Eastman Kodak Company
douglas...@kodak.com
robert bristow-johnson
>
> In comp.soft-sys.matlab robert bristow-johnson <rob...@audioheads.com> wrote:
> >(since, as Jerry points out, MathWorks won't fix this).
>
> technically, nothing is broken with regards to "base index."
well, you can say this because it's unlikely you've been bitten by this
problem.
> making a quick change could really break things. for example,
> if A is a class, then:
>
> A(-N/2,N/2)
>
> would invoke subsref() and it is not clear to me whether MATLAB
> should change -N/2 to 1 and N/2 to (N + 1) before subsref is
> called.
so what are you saying here? mixing _both_ this class thing _and_ the
index base extension i have been advocating? when i say "backward
compatible" i mean that _existing_ MATLAB code would work under the new
extended system. of course, just like with the existing MATLAB, you can
write code that breaks, generates diagnostics and/or produce unexpected
results.
> luckily, the Mathworks left well enough alone so that this
> kind of thing isnt an issue.
again, that's convenient for you to say since it's unlikely that you
have had to pay for the consequences of the rigid 1-based indexing
"feature" in MATLAB. i have and it's cost me days. it's also very
incongruent that an "intuitive, high level language" like MATLAB forces
me to rewrite or reinterpret the math equations from DSP texts for such
a silly and unnecessary reason. neither you nor anyone at MathWorks has
responded to that. maybe it's not a problem for you but it _is_ a
problem for myself and other DSPers (they are now starting to speak
up). since this fix wouldn't cost you an iota, i don't understand your
resistance. since the Signal Processing Toolbox was, i believe, the
first MATLAB toolbox, i suspect the the signal processing constiuency is
a significant one for MathWorks. yet they blow us off. that's what i
meant by "arrogant".
again, the reasons you infer that MATLAB should not fix this problem
fall short of persuasive.
Denis Gilbert wrote:
>
> robert bristow-johnson <pbj...@viconet.com> wrote in article
> <3886B0...@viconet.com>...
> > that persuasive argument would have to contain a defensible
> > example of existing code that would break if this fix was made or
> > ('snicker') a convincing argument that the existing rigid '1-based
> > indexing' is more elegant or adheres more to accepted convention in DSP
> > literature.
>
> I have been reading this thread with interest because you are touching a
> very fundamental language issue. When I was first introduced to Matlab in
> 1988, I really enjoyed its general intuitive feel and it quickly displaced
> FORTRAN as my favorite programming language.
ooooh, FORTRAN was never my favorite language since 1982 (when i learned
C).
> The only non-intuitive
> feature of Matlab that caused me some difficulty back then was the absence
> of 0-based indexing for digital signal processing applications. So I do
> feel sympathy for the points you raised in this thread. What I lack is a
> full appreciation of the complexity involved in making the adjustments you
> request while maintaining backward compatibility and not putting too much
> overhead on memory usage and execution speed. A persuasive argument along
> the lines of what you are describing above would indeed help in my opinion.
i tried to spell this out before. i will try again. it is a bit
difficult since i am not privy to MATLAB's own code. so this is a sorta
guess at what MATLAB does when it creates an array variable and when an
individual array element is accessed. i'll use C syntax since that is
what i know.
when you create a MATLAB variable, besides the data, there are a few
attributes that go with the variable that MATLAB has to allocate memory
for. again, this is a guess (and i'm assuming 2 dim arrays only):
typedef struct {
char* name;
union {
double* real_data;
char* text_data;
} data;
MATLAB_type type; // real vs. complex. vs. text ...
long numRows;
long numColumns;
} MATLAB_variable;
i'm sure there is other stuff they have. my proposal is that (assuming
the 2 dim array), that two more fields are added:
...
long numRows;
long numColumns;
long offsetRow;
long offsetColumn;
} MATLAB_variable;
when a new MATLAB variable is created offsetRow and offsetColumn are
initialized to zero (this is what makes it backward compatitible). a
new function, similar to RESHAPE, would be called by people like me that
would change these 2 offsets. the value of the offset would the base -
1.
now, when you access an individual element of a MATLAB array (or
'matrix') such as saying my_variable(n, m), MATLAB takes the indices, n
& m, and checks that they are integer values and that n >=1, m >= 1 and
n <= numRows, m <= numColumns (FORTRAN does this but C doesn't). after
checking for integer values and casting to long is where offsetRow gets
added to n and offsetColumn gets added to m just before they are checked
against the bounds. THAT'S IT! 2 extra long words are added to the
MATLAB variable structure, and 2 additions (along with all of the other
rigamarole MATLAB already does to check indices against bounds). this
will do the job and be backward compatible.
in addition, in the code that compares the number of rows and columns of
two matrices and makes sure that they are compatible (as in matrix
multiplication), i would also check the offsets to make sure they are
zero (or the base is 1). for array addition and array multiplication
(.* and ./), i would allow bases other than 1, but they have to be
equal, just as the number of rows and columns are equal.
Michael C Schweisguth
> >
> > In comp.soft-sys.matlab robert bristow-johnson <rob...@audioheads.com> wrote:
> ...
> > >(since, as Jerry points out, MathWorks won't fix this).
> >
> > technically, nothing is broken with regards to "base index."
> well, you can say this because it's unlikely you've been bitten by this
> problem.
> > making a quick change could really break things. for example,
im getting the feeling that you are playing games here; MATLAB has,
for the most part, *always* done what I told it to do. take
responsibility for *your* bugs, and move on!
Travis Oliphant
> overcome. I also don't have specific ideas for a nice notation, maybe
> something like this:
>
> A = randn(4,4);
> zA = displace (A, { i: i+1 }, { j: j+1 } );
> bA = displace (A, { i: [2*i:2*i+1] }, { j: [2*j:2*j+1] } );
>
> so that
>
> zA(i,j) = A(i+1,j+1)
>
> that is, zA is a zero based version of A and, for example,
>
> bA(0,0) = zA(0:1, 0:1)
>
> that is, bA is a block view of zA.
>
This can be implemented in Python+Numerics quite easily using a
variety of notations because of the elegant class structure and concept of
slicing. An outline of implementation is (not working code):
class displace:
# an initialization
def __init__(self, basearray, indexing_function):
self.base = basearray
self.index_to_base = indexing_function
def __getitem__(self, key):
# This will be called to evaluate self[key] where key can
# be any other object. For example If you entered self[i,j]
# key will be a tuple containing i,j: key = (i,j)
return self.base[self.indexing_function(key)]
This is simplified example, but gets at the point. For example, this
would not check for errors in the indexing_function that might happen when
used in __getitem__:
You would use the class in much the same way as you describe (changing
your {} function definition to either a lambda function or a genuine
function object -- defined with a def myfunction(): statement.
Python allows you to be quite expressive.
Travis
robert bristow-johnson
Michael C Schweisguth <msch...@u.arizona.edu> wrote:
> In comp.soft-sys.matlab robert bristow-johnson <pbj...@viconet.com> wrote:
> > Michael C Schweisguth wrote:
> > >
> > > In comp.soft-sys.matlab robert bristow-johnson <rob...@audioheads.com> wrote:
> > ...
> > > >(since, as Jerry points out, MathWorks won't fix this).
> > >
> > > technically, nothing is broken with regards to "base index."
>
> > well, you can say this because it's unlikely you've been bitten by this
> > problem.
>
yeah, i guess it's the "blame game". you blame me for the "bug", i
blame MATLAB (for the unnatural and unconventional and unchangable
syntax), and MathWorks conveniently (some might say "arrogantly") sits
on the sidelines letting you do battle for them. notice, the word i
used (here, at least) is "problem" not "bug".
> MATLAB has,
> for the most part, *always* done what I told it to do. take
> responsibility for *your* bugs, and move on!
the root of the bug is an unconventional syntax regarding the DFT and
discrete convolution (as well as other sequences that, conventionally,
have non-positive indices).
here is an obvious hypothetical example: suppose MATLAB assigned to the
addition operators '+' and '-' higher or equal binding precedence as for
the multiplicative ops '*' and '/' (or '.*' and './'). even though this
was (hypothetically) the way the product was from the very beginning and
the MATLAB docs clearly said that + and - bind as tightly as *, zillions
of unnecessary bugs (that are the 'responsibility' of the user) would
result and either MathWorks would fix the stupid thing or they would
have to change their product line from mathematical tools to comedy
novelties.
it's just a convention. MathWorks can define any convention they want
and we can choose to take it or leave it. but that is still no defense
for the technical correctness of their choice, and to force us to accept
it because they seem to be the only game in town (yeah, yeah,
Mathmatica, MathCad, Python, whatever...) is Microsoft quality of
arrogance. this problem of incorrect indexing (and the inability to
change it without using a whole different 'paradigm' - i hate that word)
is nearly as bad as the silly hypothetical i illustrated above. it's
stupid. it's unnecessary. it can lead to unnecessary bugs (by those
who just apply the commonly accepted equations of DSP). it's very hard
for us to fix (i used to think impossible before your suggestion) but it
would be simple for MathWorks to fix. the fact that they have been
silent on the issue, since their first lame excuses, is evidence of the
weakness of their case. and, because they evidently don't feel obliged
to defend it (or even just explain it), it's evidence of arrogance of
their position.
Grant Griffin
>
...
> it's just a convention. MathWorks can define any convention they want
> and we can choose to take it or leave it. but that is still no defense
> for the technical correctness of their choice, and to force us to accept
> it because they seem to be the only game in town (yeah, yeah,
> Mathmatica, MathCad, Python, whatever...) is Microsoft quality of
> arrogance.
Hi robert,
I would like to modestly suggest Matlab is the only game in town only in
towns which allow only Matlab a gaming permit.
To me, Matlab has always been a very interesting business case. One is
hard pressed to think of another example of such an expensive software
package which has such a large number of both "clone" and "does about
the same thing" competitors--both commercial and free/open.
The fact that Matlab seems to prosper in this competitive environment is
somewhat puzzling. Sure, they've somehow managed to get people to write
textbooks around their system: that's a pretty neat gimmick. (Heck, you
could probably even sell _hamburgers_ that way!) But given the amount
of direct mail I get from them and the number of magazine ads I see from
them, I have long assumed they were prospering largly as a result of
effective--and, judging by the product's sticker price, quite
*expensive*--marketing.
But the marketing stuff is directed mostly at people who might _move to_
Matlab City. So is there any explaining why some folks who live there
think they just couldn't live anywhere else?--even the folks who grumble
a bit about the potholes?!
Since there are many games and many towns, I just can't figure it out.
Peter J. Acklam
> (...) i blame MATLAB (for the unnatural and unconventional and
> unchangable syntax)
You mean 1-based indexing is unconventional syntax? That makes me
wonder just how much mathematical software you have been using.
Peter
--
function Y=rot90(X,N),s=size(X);d=ndims(X);i={':'};i=i(ones(d,1),1);
%ROT90 Rotate an array X, N*90 degrees counterclockwise along all dimensions.
N=N-4*floor(N/4);if N==1|N==2,i{2}=s(2):-1:1;end;if N==2|N==3,i{1}=s(1):-1:1;
end;Y=X(i{:});if N==1|N==3,Y=permute(Y,[2,1,3:d]);end
Jerry Avins
whippersnappers get all het up the first time you can't come twice.
You'll get an entirely different perspective the second time you can't
come once.
Jerry
--
Engineering is the art of making what you want from things you can get.
-----------------------------------------------------------------------
robert bristow-johnson wrote:
>
> In article <86aolh$orl$1...@news.ccit.arizona.edu>,
> Michael C Schweisguth <msch...@u.arizona.edu> wrote:
> > In comp.soft-sys.matlab robert bristow-johnson <pbj...@viconet.com> wrote:
> > > Michael C Schweisguth wrote:
> > > >
> > > > In comp.soft-sys.matlab robert bristow-johnson <rob...@audioheads.com> wrote:
> > > ...
> > > > >(since, as Jerry points out, MathWorks won't fix this).
> > > >
> > > > technically, nothing is broken with regards to "base index."
> >
> > > well, you can say this because it's unlikely you've been bitten by this
> > > problem.
> >
> > i'm getting the feeling that you are playing games here;
>
> yeah, i guess it's the "blame game". you blame me for the "bug", i
> blame MATLAB (for the unnatural and unconventional and unchangable
> syntax), and MathWorks conveniently (some might say "arrogantly") sits
> on the sidelines letting you do battle for them. notice, the word i
> used (here, at least) is "problem" not "bug".
>
> > MATLAB has,
> > for the most part, *always* done what I told it to do. take
> > responsibility for *your* bugs, and move on!
>
> the root of the bug is an unconventional syntax regarding the DFT and
> discrete convolution (as well as other sequences that, conventionally,
> have non-positive indices).
>
> here is an obvious hypothetical example: suppose MATLAB assigned to the
> addition operators '+' and '-' higher or equal binding precedence as for
> the multiplicative ops '*' and '/' (or '.*' and './'). even though this
> was (hypothetically) the way the product was from the very beginning and
> the MATLAB docs clearly said that + and - bind as tightly as *, zillions
> of unnecessary bugs (that are the 'responsibility' of the user) would
> result and either MathWorks would fix the stupid thing or they would
> have to change their product line from mathematical tools to comedy
> novelties.
>
> it's just a convention. MathWorks can define any convention they want
> and we can choose to take it or leave it. but that is still no defense
> for the technical correctness of their choice, and to force us to accept
> it because they seem to be the only game in town (yeah, yeah,
> Mathmatica, MathCad, Python, whatever...) is Microsoft quality of
> arrogance. this problem of incorrect indexing (and the inability to
> change it without using a whole different 'paradigm' - i hate that word)
> is nearly as bad as the silly hypothetical i illustrated above. it's
> stupid. it's unnecessary. it can lead to unnecessary bugs (by those
> who just apply the commonly accepted equations of DSP). it's very hard
> for us to fix (i used to think impossible before your suggestion) but it
> would be simple for MathWorks to fix. the fact that they have been
> silent on the issue, since their first lame excuses, is evidence of the
> weakness of their case. and, because they evidently don't feel obliged
> to defend it (or even just explain it), it's evidence of arrogance of
> their position.
>
Michael C Schweisguth
> yeah, i guess it's the "blame game". you blame me for the "bug", i
> blame MATLAB (for the unnatural and unconventional and unchangable
> syntax), and MathWorks conveniently (some might say "arrogantly") sits
> on the sidelines letting you do battle for them. notice, the word i
> used (here, at least) is "problem" not "bug".
well, they are probably happy because we are discussing a non-issue--
unlike [1/j] calculating the wrong answer. this whole issue doesnt
touch on wether or not MATLAB is a stable numerical calculation
engine or not.
if i was going to buy MATLAB and i saw that this is what MATLAB
users gripe about, then I would buy the product.
you know the work-a-round--> use a mathematical tranformation of
variables. people do this prodcedure often. after you do the
transformation, then you will have a "one based" solution.
Jeff Stuart
will dissuade Robert from complaining about the unreasonable
unwillingness of the folks at the Mathworks. Until such time
as the Mathworks changes its entire approach to index
formulation, or until Robert finds some other package that
does not have this flaw (but which will no doubt have some
other egregious flaw), Robert will vociferously express his
dissatisfaction. If you have lots of spare time and you want
to argue with him, then that's your choice, but if you expect
to change his point of view, save your electrons for some
more feasible task. In the mathematics community, this
petulant behavior is often associated with folks who want
positive angles measured clockwise, ,,,
J. Stuart
Michael C Schweisguth
skills are excellent. I think people really trust him in a very unartificial
way.
In comp.soft-sys.matlab Grant Griffin <grant....@iowegian.com> wrote:
> robert bristow-johnson wrote:
> >
> ...
> > it's just a convention. MathWorks can define any convention they want
> > and we can choose to take it or leave it. but that is still no defense
> > for the technical correctness of their choice, and to force us to accept
> > it because they seem to be the only game in town (yeah, yeah,
> > Mathmatica, MathCad, Python, whatever...) is Microsoft quality of
> > arrogance.
> Hi robert,
robert bristow-johnson
> > unchangable syntax)
>
> You mean 1-based indexing is unconventional syntax?
it most certainly is when the topic is the Discrete Fourier Transform
(sometimes called an FFT), discrete convolution, and other mathematical
formulae (such as power series).
> That makes me
> wonder just how much mathematical software you have been using.
none other than MATLAB. that's not the point. the point is that MATLAB
is, and forces me (and other DSP users) to be out of convention for some
_very_ important, basic, and commonly used formulae. that is where it
is unconventional.
i still believe that a fundamental purpose of MATLAB (other than to
financially enrich the principals, stockholders, and perhaps the
employees of MathWorks) is to allow users to simply, without a whole
shitload of translation, apply mathematical formulae to tasks of
analysis, simulation, and prototyping. with this rigid 1-based
indexing, i cannot do that in the case of non-positive subscripts.
MATLAB insists that all subscripts are positive, oblivious to the
literature and common practice.
robert bristow-johnson
Michael C Schweisguth <msch...@u.arizona.edu> wrote:
> In comp.soft-sys.matlab robert bristow-johnson <pbj...@viconet.com> wrote:
>
> > blame MATLAB (for the unnatural and unconventional and unchangable
> > on the sidelines letting you do battle for them. notice, the word i
> > used (here, at least) is "problem" not "bug".
>
> well, they are probably happy because we are discussing a non-issue--
it's a non-issue to you (and evidently to MathWorks) but it is not a
non-issue to DSP algorithm designers (who you MATLAB for prototyping)
and programmers. there have been a few posts by other comp.dsp folk
indicating the same. by insisting that it is not a problem or a
non-issue
> unlike [1/j] calculating the wrong answer.
that's funny. when i type in 1/j <return>, i get 0 - 1.00000000000i .
just to make sure it isn't off by a little, 1/j + j gives me 0.
was this a real problem or a hypothetical (the latter just dawned on
me)?
> this whole issue doesnt
> touch on wether or not MATLAB is a stable numerical calculation
> engine or not.
i never said it was unstable. you're changing the subject. i said that
rigid 1-based indexing is inappropriate to the DFT, discrete
convolution, and common convention in the literature of many other
mathematical formulae that has non-positive indices. i.e. it sucks.
software that costs 4 digits shouldn't suck about something so basic.
the issue isn't that of a MATLAB bug so that when i use it as
instructed, it gives me the wrong answers, it's that Cleve and those
guys seemed not to care a tittle about the indexing convention they were
imposing on their future DSP users was contrary to the convention in
_every_ DSP text (that wasn't written around MATLAB) and all of the
profession literature at the time. that is the issue and every time you
try to change the subject or imply it's something else, i will correct
it.
> if i was going to buy MATLAB and i saw that this is what MATLAB
> users gripe about, then I would buy the product.
that's because it's unlikely that you do Discrete Fourier Transforms
(examining the results bin-by-bin and calculate the frequency associated
with the bin) or discrete convolution (and needed to implement a
non-causal impulse response). i would buy the product also, but most of
the time it's still a problematic indexing convention for DSP. and that
fact is incongruent to the fraction of users of MATLAB who do these
operations.
> you know the work-a-round--> use a mathematical tranformation of
> variables. people do this prodcedure often. after you do the
> transformation, then you will have a "one based" solution.
yup. and to implement it, i need to write a MATLAB class as you have
described, along with all necessary operator/function overload or i need
to remember to change each and every equation that appears in the
literature that has non-positive subscripts. in the case of DFT, i need
to add 1 to each subscript before going to MATLAB and subtract 1 from
each MATLAB subscript in examining results. if i forget to do that
anywhere, i get numerical errors but no hint of error otherwise. and
you call that a non-issue.
Marius Vollmer
> This can be implemented in Python+Numerics quite easily [...]
> [...]
> Python allows you to be quite expressive.
Yes, I guess so. In the end, you always need a full blown programming
language, no matter how specific your domain is. The MathWorks is
plugging the holes one by one, but that just leads to patchwork.
Grant Griffin
>
> Cleve is a respected leader. Ive heard a few testimonies. His engineering
> skills are excellent. I think people really trust him in a very unartificial
> way.
>
I don't know much about him, but the tremendous success of Matlab seems
to suggest effective leadership of some kind from some where; I don't
doubt that it's him.
Now, if only he could lead Matlab to a reasonable price. Sure, the
student version has long been affordable (about the price of an
expensive textbook), and recently we find that the student version is no
longer crippled, thus giving it about the same capabilities (as I
understand it) as the professional version. But for some reason
"professionals" aren't supposed to use the student version; instead they
should pay thousands of dollars (or whatever...last I checked, a couple
of years ago, the cost of the professional version wasn't publicized on
The Mathworks' web site, in magazine ads, or in direct mail; I think
they were ashamed of it--I had to call a professional salesman at TMW to
find out.)
So, given the fact that the professional version does about the same
thing as the student version, and given that the professional version
costs 50 times as much (or whatever...I haven't called a professional
salesman lately), is Cleve leading people into dishonesty? (Let's see a
show of hands: how many of you so-called "students" out there are also
"professionals". _Naughty, naughty_!)
God bless John W. Eaton and the good folks at INRIA (and others) for
leading Cleve to lower the price--if only via this schizophrenic pricing
policy which gives professionals a choice between dishonesty and
schlemielhood.
Michael C Schweisguth
In comp.soft-sys.matlab robert bristow-johnson <pbj...@viconet.com> wrote:
> was this a real problem or a hypothetical (the latter just dawned on
> me)?
no, it was a bug. it was fixed quickly since it works in
release 11.1.
and some of us would classify this as a real problem versus
what the base index is.
robert bristow-johnson
In article <86jcrl$mdr$1...@news.ccit.arizona.edu>, Michael C Schweisguth
<msch...@u.arizona.edu> wrote:
> Cleve is a respected leader. Ive heard a few testimonies. His engineering
> skills are excellent. I think people really trust him in a very unartificial
> way.
i actually do not doubt this at all. but it would be a logical fallacy to
use the above fact as support for his position regarding the "horrible
MATALB indexing (from the POV of DSP)" debate that he seems to be avoiding.
his position is technically wrong despite his reputed excellent leadership
and engineering skills.
--
r b-j
robert bristow-johnson
"Jeff Stuart" <1123...@email.msn.com> wrote:
> It should be obvious at this point that no reasoned argument
> will dissuade Robert from complaining about the unreasonable
> unwillingness of the folks at the Mathworks.
sorry Jeff, but even that is not true. early on i stated two arguments that
would do exactly that dissuasion.
1. that the way MATLAB is, vis-a-vis sequences that have natural subscripts
that are not always positive such as the DFT and discrete convolution
(something very close to the heart of us DSPers, even if it's not to the
'MATLABers'), is more elegant and less error prone than the fix i've been
harping about (for years - it's only recently that i've raised the volume
because it's apparent that MathWorks is deaf despite their assurances).
2. that this fix would break MATLAB in such a way that code that had
already existed and does not, in any way, use the 'non-positive subscripting
feature', that this code would break if the fix, as i have outlined it, were
made.
if MathWorks or the MathWorks apologists on comp.soft-sys.matlab can present
_and_ _defend_ either of these cases, i'll shut up and accept that MATLAB
simply cannot be fixed. no one yet has been able to do that and MathWorks
has simply blown me (and other dissatisfied DSPers) off hoping that the
ruckus will die down soon. why else have they been so quiet on the issue
once i had shown their lame excuses to be just that?
so Jeff, even in this sorta non-objective (i guess the word for that would
be 'subjective') statement you made, you missed the mark of accuracy. and
that's hard to do.
> Until such time
> as the Mathworks changes its entire approach to index
> formulation,
or, simply extend it so that an offset (initialized to zero) is added to the
index before the index is checked against bounds. that is not a change of
its entire approach to index formulation. it _is_ a change of entire
approach to the attitude: "we already talked about this and we decided we
ain't gonna never do it and since we are MathWorks, we must be right about
this issue beyond question. so it's settled."
> or until Robert finds some other package that
> does not have this flaw (but which will no doubt have some
> other egregious flaw), Robert will vociferously express his
> dissatisfaction.
and i'm also explaining and defending the reasons of that dissatisfaction
down to minute detail when challenged. call it whatever you want, but the
confidence i have about my position is its rightness (so it's not all that
hard to defend, although time-consuming). the confidence that MathWorks has
about their position is "that MATLAB is fine and this can not nor should not
be fixed" is only that of the power to do nothing about the problem and keep
on sellin' those MATLABs. why should they bother? (and _that_ is
fundamentally Microsoft quality of arrogance.) their defense of their
position has little to do with its merit.
> If you have lots of spare time and you want
> to argue with him, then that's your choice, but if you expect
> to change his point of view, save your electrons for some
> more feasible task. In the mathematics community, this
> petulant behavior is often associated with folks who want
> positive angles measured clockwise, ,,,
well, that's not me. in fact, i want _more_ conformance to accepted
mathematical convention. not less.
Eli Brandt
robert bristow-johnson <pbj...@viconet.com> wrote:
>In article <86iban$4aq$1...@news.ccit.arizona.edu>,
>it's a non-issue to you (and evidently to MathWorks) but it is not a
>non-issue to DSP algorithm designers (who you MATLAB for prototyping)
>and programmers. there have been a few posts by other comp.dsp folk
>indicating the same.
Yo. I'm more pessimistic than you are about the difficulty MathWorks
would have in fixing this, so I'm mostly considering this discussion
moot. But I would just like to say hell yeah it's an issue.
Some domains (anywhere data is sampled from a continuous axis) are
naturally zero-based. Then 1-based arrays are as much a language
misfeature as 17-based would be -- if not more; off-by-17 bugs are
harder to make and easier to catch.
But look, there are plenty of design flaws in Matlab as a programming
language that can't possibly be fixed at this point. Would anyone
like to talk instead about how Python does at expressing APL-style
vector operations? I'm curious.
--
Eli Brandt | el...@cs.cmu.edu | http://www.cs.cmu.edu/~eli/
Peter Boettcher
> 1. that the way MATLAB is, vis-a-vis sequences that have natural subscripts
> that are not always positive such as the DFT and discrete convolution
> (something very close to the heart of us DSPers, even if it's not to the
> 'MATLABers'), is more elegant and less error prone than the fix i've been
> harping about (for years - it's only recently that i've raised the volume
> because it's apparent that MathWorks is deaf despite their assurances).
>
> 2. that this fix would break MATLAB in such a way that code that had
> already existed and does not, in any way, use the 'non-positive subscripting
> feature', that this code would break if the fix, as i have outlined it, were
> made.
How about
3. that this fix would create such a mess of the MATLAB programming
language that any non-trivial routines using it would be MORE difficult to
get right. Or that modifying someone else's code would be a disaster?
I'd like to direct your attention to Jordan Rosenthal's post on January
21, which presents real, concrete examples of ambiguities and difficulties
in your proposed fix. The way to convert me (and others) over to your
view is to come up with reasonable solutions to those, and think of the
others, rather than making a ridiculous claim that this is a one-day
modification. Or that it has no negative consequences.
--
Pete Boettcher
boet...@cmu.edu
Michael C Schweisguth
that he makes "technical tradeoffs." obviously, he does this well since
MATLAB has been a viable product for a long time. not everyone who
uses MATLAB is a DSP person and not every DSP person is bothered by 1
based indexing. therefore, using the Matrix indexing model makes a lot
of sense to me. of course, as a C programmer, 0 based indexing makes a
lot of sense to me also.
why not set up a web site and take a poll?
In comp.soft-sys.matlab robert bristow-johnson <rob...@audioheads.com> wrote:
Grant Griffin
>
> ... it _is_ a change of entire
> approach to the attitude: "we already talked about this and we decided we
> ain't gonna never do it and since we are MathWorks, we must be right about
> this issue beyond question. so it's settled."
>
I've noticed that "Dark Side" thinking seems to be endemic among
monopolists. Maybe we shouldn't appoint any more.
;-)
Grant Griffin
>
> one of the hats that Cleve wears is his engineering hat-- which means
> that he makes "technical tradeoffs." obviously, he does this well since
> MATLAB has been a viable product for a long time.
Let us not discount his considerable abilities as a marketeer. Whereas
Bill Gates convinced a of people to pay a little money for software,
Cleve has somehow convinced a few people to pay a lot. Neither trick is
easy.
But like Bill, maybe he'll one day become a philanthropist. Just
imagine, Kids, how many vaccinations you can fund with the purchase of
just a single copy of Matlab.
Michael C Schweisguth
discussion.
instead, I must ask myself: "what am i going to do today?"
p.s. if you think that Bill Gates is charging you too much, then
he is really just giving away your money to charity in his
name-- which isnt philanthropy nor altruism. (i.e. he's
stealing from the poor and then giving it back to the poorer)
while im liberal, i loved what "the prince" had to say about
philanthropy.
In comp.soft-sys.matlab Grant Griffin <grant....@iowegian.com> wrote:
Grant Griffin
>
> now that you are trying to malign Cleve, I must get out of this
> discussion.
>
I dare you to find one bad word about him in what I said below. As far
as I can tell, it was complimentary.
> instead, I must ask myself: "what am i going to do today?"
>
> p.s. if you think that Bill Gates is charging you too much, then
> he is really just giving away your money to charity in his
> name-- which isnt philanthropy nor altruism. (i.e. he's
> stealing from the poor and then giving it back to the poorer)
>
On the contrary, I think Bill's price is quite reasonable. (In fact if
the dollars-per-line-of-code ratio of Matlab were similar, I would think
Matlab's price was reasonable, too: the professional version would sell
for about $5. OK, let's throw in the cost of the disk, the book, and
the box and make it $25.)
I respect Bill's right to make money (so long as he does so within the
letter and spirit of the law...), and I respect his right to do what he
pleases with it. I also admire his vaccination program, which seems
like a worthy philanthropy--one that might be equally worthy of Cleve's
Matlab millions. (BTW, what _does_ he do with all that money he takes
from you people?)
> while im liberal, i loved what "the prince" had to say about
> philanthropy.
>
I love what Edward Francis Albee said about suckers and even breaks. To
that I might add, "And then tease them."
> In comp.soft-sys.matlab Grant Griffin <grant....@iowegian.com> wrote:
> > Michael C Schweisguth wrote:
> > >
> > > one of the hats that Cleve wears is his engineering hat-- which means
> > > that he makes "technical tradeoffs." obviously, he does this well since
> > > MATLAB has been a viable product for a long time.
>
> > Let us not discount his considerable abilities as a marketeer. Whereas
> > Bill Gates convinced a of people to pay a little money for software,
> > Cleve has somehow convinced a few people to pay a lot. Neither trick is
> > easy.
>
> > But like Bill, maybe he'll one day become a philanthropist. Just
> > imagine, Kids, how many vaccinations you can fund with the purchase of
> > just a single copy of Matlab.
=g2
Michael C Schweisguth
> Michael C Schweisguth wrote:
> > now that you are trying to malign Cleve, I must get out of this
> > discussion.
> I dare you to find one bad word about him in what I said below. As far
> as I can tell, it was complimentary.
this:
>>> But like Bill, maybe he'll one day become a philanthropist. Just
>>> imagine, Kids, how many vaccinations you can fund with the purchase of
>>> just a single copy of Matlab.
since it is hearsay.
i would compare the TI calculator at $200 to MATLAB. according to the
TI website, the TI calculator beat out Mathematica. this $200 figure
includes all the hardware and software.
Grant Griffin
>
> In comp.soft-sys.matlab Grant Griffin <grant....@iowegian.com> wrote:
> > Michael C Schweisguth wrote:
> > > now that you are trying to malign Cleve, I must get out of this
> > > discussion.
> > I dare you to find one bad word about him in what I said below. As far
> > as I can tell, it was complimentary.
>
> this:
>
> >>> But like Bill, maybe he'll one day become a philanthropist. Just
> >>> imagine, Kids, how many vaccinations you can fund with the purchase of
> >>> just a single copy of Matlab.
>
> since it is hearsay.
>
Sorry, but I can't read anything like "bad" or "hearsay" into that.
Help me out here...
> i would compare the TI calculator at $200 to MATLAB. according to the
> TI website, the TI calculator beat out Mathematica. this $200 figure
> includes all the hardware and software.
(what was the question? ;-)
Michael C Schweisguth
> Help me out here...
ok, i believe ya! ;-)
> > i would compare the TI calculator at $200 to MATLAB. according to the
> > TI website, the TI calculator beat out Mathematica. this $200 figure
> > includes all the hardware and software.
> (what was the question? ;-)
well, IMO, comparing the cost of the TI-92 to MATLAB seems to be better
than comparing windows to MATLAB since the TI-92 functions more like MATLAB.
i listed the TI-92 since Texas Instruments beat out Mathematica and
several other desktop strength packages with their calculator
in a competition they entered!
the TI-92 has symbolic as well as matrix capibility, but a slow
processor and obviously less RAM than a desktop.
i dont know what MATLAB pricing is, but perhaps MATLAB + symbolic
capibilty is 5-10 times the cost of the TI-92.
since Dell charges $99 for windows NT, and nothing for win 95, it
looks like win NT costs about as much as the TI-92 calculator.
Grant Griffin
>
> > Sorry, but I can't read anything like "bad" or "hearsay" into that.
> > Help me out here...
>
> ok, i believe ya! ;-)
>
> > > i would compare the TI calculator at $200 to MATLAB. according to the
> > > TI website, the TI calculator beat out Mathematica. this $200 figure
> > > includes all the hardware and software.
>
> > (what was the question? ;-)
>
> well, IMO, comparing the cost of the TI-92 to MATLAB seems to be better
> than comparing windows to MATLAB since the TI-92 functions more like MATLAB.
>
No. You should never compare the cost of hardware to bits. Bits don't
cost anything to make on a per-unit basis, except for the disk, book,
and, box, of course--oh, and the customer support. The disk, book, and
box may cost a few tens of dollars. However, the support may cost
thousands (if the product is extremely hard to use. ;-)
> i listed the TI-92 since Texas Instruments beat out Mathematica and
> several other desktop strength packages with their calculator
> in a competition they entered!
>
> the TI-92 has symbolic as well as matrix capibility, but a slow
> processor and obviously less RAM than a desktop.
>
> i dont know what MATLAB pricing is, but perhaps MATLAB + symbolic
> capibilty is 5-10 times the cost of the TI-92.
You know...it's funny. I didn't really know what it was either. The
student version, as I understand it, cost about $100. But here's The
$64,000 Question: what does the _professional_ version cost?
Well, it turns out this isn't easy to find out. Most vendors are quite
clear about prices. They think that helps sell stuff. For example, the
Sunday paper is filled with "advertising circulars" which are
overflowing with prices. And most people who sell something online put
prices where you can find them by navigating through, at most, three or
four pages.
But TMW has a different idea. I went to their web site, and tried to
access the pricing page. First, it wanted to me to answer three
questions (not unlike the bridge in Monty Python's "Holy Grail" movie.
;-) I thought that was kindda obnoxious, but they were pretty simple
questions, and they didn't result in any real loss of privacy, so I
answered them. Then I hit the "Continue" button. It came back with a
"Document contains no data" message. But maybe that was Netscape's
fault, so I decided to try Internet Explorer. I got a similar result.
Next, I decided to call them. After all, if they have 500 employees
(the web site actually did tell me _that_ much), surely there's somebody
to answer the phone. As usual, there were multiple voice-mail menus to
navigate through, but it looked I was hot on the trail of my personal
holy grail: the hidden cost of Matlab. Then, the voice-mail computer
put me on hold with some rather obnoxious music. Well, after listening
to that stuff for awhile, I lost interest, so I hung up. (BTW, if
anybody at TMW is listening here's a little tip: Mozart, Benjamin:
Mozart.)
Next, I went to e-mail. Besides the web and the telephone, e-mail is
the next best thing to being there. I sent out a kind note asking about
the price of the professional version.
I promptly got a nice note from the e-mail computer saying it was
listening. That made me feel good for a moment, but I didn't think the
e-mail computer could really help. (_Especially if it is in collusion
with that darn *web* computer_...)
However, a couple of hours later, I got the following form letter from a
real live human being:
- Hello Grant,
-
- Thank you for your inquiry concerning MATLAB and our family of
products.
-
- In order to process your request and direct you to the appropriate
account
- representative, please provide us with the following information:
-
- * Full name
- * University/Company Name
- * Mailing address
- * City, State, Zip Code
- * Telephone number
- * Fax Number
- * Email address
- * Platform of interest
-
- Please email the information above with your original message to
- pri...@mathworks.com
-
- Thank you for your cooperation. We look forward to hearing from you
- soon!
-
- Best regards,
-
- (name deleted)
- Customer Service Representative
I then sent back the following:
- Hi ____,
-
- I would like to protect my privacy by providing as little information
- as possible. While I understand that The Mathworks may have various
- pricing structures, can you simply provide me with the list price?
- I'm just trying to get a ballpark figure. I seem to recall that the
- last quote I receive a couple of years ago was about $5000 plus about
- $2000 for some of the toolboxes. Is it still in about that range,
- or have the prices changed?
At this point, as a Pavlovian response, I was expecting more rigamarole
(one becomes conditioned to it after awhile...), but instead I received
a nice e-mail wich included a price list in .pdf format. The list was
clear and simple. (In fact, it wouldn't take TMW more than an hour to
turn that into a web page...) According to the list, the cost of the
professional version of Matlab is $1900, and the cost of the DSP toolkit
is $600. That makes a total package price of $2500 for us DSPers.
Now that isn't too bad, really. It's a darn sight better than what they
told me a couple of years ago. In fact, it only costs about twice what
you might now pay for the computer you run it on (unless you use a
laptop. ;-)
But I digress. Having gone through all this, I now have to ask myself:
what was all *that* about? Why is the cost hidden? I'm tempted to say
that they're "ashamed" of it--after all that seems like a whole lot of
money just to pay for "bits". (How much does a darn bit cost, anyway?)
However, as a businessman, I must admit that I think it's more likely
that they simply play games with pricing in order to acquire information
about their potential customers (see above). That is, of course, the
genesis of part of their profuse output of direct mail.
Although I am an advocate of free/open software, I am not dogmatic about
it: I sell closed/commercial software myself. We already knew that the
advantages of free/open software are that it's 1) free of cost, and 2)
open to modification, but I never knew until now that its major
advantage is: YOU KNOW WHAT IT COSTS. (The latter, of course, isn't an
advantage vis-a-vis software vendors who don't subject their customers
to pricing games.)
Although as a potential customer, I personally find TMW's tactics here
quite disgusting, as a businessman, I can see the value. I don't know
whether Cleve invented this idea or maybe it was some other genius at
TMW, but, as a businessman, please let me take this opportunity to
express my admiration for this scheme--and also for somehow making
(most) customers expend the effort it takes to have their privacy
invaded.
Michael C Schweisguth
> > than comparing windows to MATLAB since the TI-92 functions more like MATLAB.
> No. You should never compare the cost of hardware to bits. Bits don't
> cost anything to make on a per-unit basis, except for the disk, book,
> and, box, of course--oh, and the customer support. The disk, book, and
> box may cost a few tens of dollars. However, the support may cost
> thousands (if the product is extremely hard to use. ;-)
the software comes with the hardware.
> Although as a potential customer, I personally find TMW's tactics here
> quite disgusting, as a businessman, I can see the value. I don't know
> whether Cleve invented this idea or maybe it was some other genius at
> TMW, but, as a businessman, please let me take this opportunity to
> express my admiration for this scheme--and also for somehow making
> (most) customers expend the effort it takes to have their privacy
> invaded.
well, from what people tell me, Cleve is a people person-- he even
posts to this group. he believes in his product and i think that he
still wants to know his customers.
and, i really think that MATLAB costs what it does because the US
miltary likes buying $200.00 hammers and $600.00 toilet seats! hence,
MATLAB may in fact be underpriced! ;-) while student pricing may
make the Mathworks look altruistic, it allows them to keep the
retail price high.
Microsoft can crank out a 50 cent CD and give it to a charity and
then deduct it from their taxes as a deduction.
Olivier Lapierre
it's less time to write the functions to do it than the time you spent
writing e-mails on the subject. I think like you that indexing of fft result
is not user friendly, but it's years ago I spent some minutes (not more) to
make my own functions do what I like with fft results. I made that with
Matlab 3.x running under MSDOS (am I so old ?), and I'm still happy with
it.
Your problem seems to be a no-problem question : just make the effort to
develop your own toolbox (look at objects programming, I did it twice, and
it's not so complex), Matlab is an opened software which lets the developer
make it look like he wants, and for this reason it can't take into account
all your desiderata.
And stop this useless discussion. As I said Matlab is an opened software,
that means that if you need something special, you have to program it
yourself (needs time, of course), but it's always possible to do it .
Peter Boettcher a écrit dans le message ...
robert bristow-johnson
well, setting aside the MathWorks business plan (and trying to get back to
the technical issue), is Cleve's silence (or the collective silence from
everyone at MathWorks) an indication of the technical strength of their
position (that MATLAB is fine the way it is and should not be extended to
accommodate the needs of a large constituency) or of the acuteness of their
hearing (about customer concerns)?
MathWorks might have a great business plan (develop MATLAB at the expense of
the Pentagon and then rake in big profits selling it to the rest of us).
fine, i really have no problem with that as long as their stated goal, to
make MATLAB the best that it can be, was truly pursued. but on this issue
(of rigid 1-based indexing) they have offered only lame excuses. their own
confidence in the technical merits of their position must be low since they
have made no attempt to defend their lame excuses once it became clear that
some of us (namely me and other from comp.dsp) were not easily hoodwinked.
Michael (or other MathWorks apologists on comp.soft-sys.matlab), would you
care to speculate on the reasons behind deafening silence from MathWorks?
Cleve (or anyone else at MathWorks), i challenge you to defend, technically,
your rational for not fixing this thing (by implementing a backward
compatible extension to the existing indexing scheme). just saying that
there is a 15 year user base and implying that their code will break if this
fix is made is not good enough without justifying that statement. saying
that the convention that MATLAB forces on us DSPers is more elegant than the
convention of DSP textbooks and literature is so ludicrous that i would find
it hard to believe you truly think that, but if you do, please, by all means
offer that argument AND DEFEND IT!
are you man enough for it, Cleve? ;-)
it's good for any of us to have our perception of reality tested by others.
it would be great for MATLAB.
it is only reasonable to assume that silence from MathWorks is exactly the
Microsoft kind of self-satisfaction i was alluding to before. what other
reason could it be? if MathWorks truly wants MATLAB to be the best that it
can be and if MathWorks is truly responsive to their customer base, there
can be little else to explain this silence.
Phil Martel
Grant Griffin <grant....@iowegian.com> wrote in message
news:389002...@iowegian.com...
<snip>
> But I digress. Having gone through all this, I now have to ask myself:
> what was all *that* about? Why is the cost hidden? I'm tempted to say
> that they're "ashamed" of it--after all that seems like a whole lot of
> money just to pay for "bits". (How much does a darn bit cost, anyway?)
Grant, I'm surprised at you. A bit is $0.125 ;)
Best wishes,
--Phil Martel
Lars Gregersen
<rob...@audioheads.com> wrote:
Dear Robert
>fix is made is not good enough without justifying that statement. saying
>that the convention that MATLAB forces on us DSPers is more elegant than the
>convention of DSP textbooks and literature is so ludicrous that i would find
No-one forces you to use the indexing scheme that Matlab has. In fact
no-one forces you to use Maltab at all.
Matlab has an indexing scheme that makes sense to most people that
uses Matlab. When I have to implement numerical algorithms it is
extremely easy to do so since the indexing scheme used in the
literature is the same as the one used in Matlab. There are no
problems with the Matlab indexing scheme since it is extremely
consistent - even for high dimensional matrices.
For some uses I also have to use non-standard indexing. Something
like: "pick every other element of a vector", "subdivide a matrix into
three-by-three blocks and select the upper-left element of each
blocks, then select the next element in each block" etc. I guess that
I could gain some speed and especially make my programmes easier to
read, but I also aknowledge that Matlab is a general tool and it
simply can't have everything built in.
I fear that if Matlab changes its indexing scheme so that any matrix
can have any indexing scheme a lot of programmes would break because
of this. If a change of indexing scheme was provided by overloading of
the ()-operator only for objects (so the user could make their own
changes) I would vote for.
In any event, it is hardly a surprise that a change of indexing scheme
is a very complicated thing to design and implement. Think of the
implecations if you wanted to change the indexing scheme of C or
FORTRAN. This is not very likely to happen, is it? Nor is it something
that should happen in Matlab overnight. The implecations it would have
on m-code, p-code and MEX files has to be thoroughly evaluated. A
change of indexing scheme can't simply go too slow.
Lars
------------------------------
Lars Gregersen (l...@kt.dtu.dk)
http://www.gbar.dtu.dk/~matlg
Check out my matlab toolboxes at:
http://members.xoom.com/gregersenweb/matlab/
Wlodek Tych
I have just noticed this thread, and as a Matlab user (since 1988) I would
like to put my 2p worth, hoping I won't offend anyone, but perhaps lessen
the tensions.
First of all, indexing, like all other features of a language, is a
convention, and some will like it, while others won't. This is unavoidable.
As long as it is consistent it is fine, we can nearly always write a little
fix for ourselves. Only changes from version to version are a bit annoying,
and that happened between version 4 and 5 of Matlab. I got over that easily
though, only minor fixes were needed in my extensive code library.
All the best and happy Millenium to everyone,
Wlodek
Grant Griffin
>
> Grant Griffin <grant....@iowegian.com> wrote in message
> news:389002...@iowegian.com...
> <snip>
> > what was all *that* about? Why is the cost hidden? I'm tempted to say
> > that they're "ashamed" of it--after all that seems like a whole lot of
> > money just to pay for "bits". (How much does a darn bit cost, anyway?)
>
>
OK, you got me. :-)
Assuming it comes with hundreds of thousands or maybe millions of bits,
$2500 is a bargain.
And Linux is a steal!
Grant Griffin
>
> > > well, IMO, comparing the cost of the TI-92 to MATLAB seems to be better
> > > than comparing windows to MATLAB since the TI-92 functions more like MATLAB.
> > No. You should never compare the cost of hardware to bits. Bits don't
> > cost anything to make on a per-unit basis, except for the disk, book,
> > and, box, of course--oh, and the customer support. The disk, book, and
> > box may cost a few tens of dollars. However, the support may cost
> > thousands (if the product is extremely hard to use. ;-)
>
>
Unless you buy Matlab. Then you get to pay extra for the hardware.
Imagine if two slices of bread cost twice as much as a toaster. Or what
if a a tank of jet fuel cost twice as much as Cleve's Learjet. It
doesn't make any darn sense.
> > Although as a potential customer, I personally find TMW's tactics here
> > quite disgusting, as a businessman, I can see the value. I don't know
> > whether Cleve invented this idea or maybe it was some other genius at
> > TMW, but, as a businessman, please let me take this opportunity to
> > express my admiration for this scheme--and also for somehow making
> > (most) customers expend the effort it takes to have their privacy
> > invaded.
>
> well, from what people tell me, Cleve is a people person-- he even
> posts to this group.
That must be why those nice folks at the TRW credit bureau keep track of
your and my bill-paying habbits: They're just people persons.
I don't doubt any of the nice things you say about him. To those, let's
add "filthy rich". (BTW, that's a compliment. ;-)
> he believes in his product and i think that he
> still wants to know his customers.
>
I believe he believes in his customers, too. Especially the
professional ones: he believes in their ability and willingness to shell
out twice what their computer costs for his software.
> and, i really think that MATLAB costs what it does because the US
> miltary likes buying $200.00 hammers and $600.00 toilet seats! hence,
> MATLAB may in fact be underpriced! ;-) while student pricing may
> make the Mathworks look altruistic, it allows them to keep the
> retail price high.
>
You know...that must be why IBM used to give away mainframes to
Universities (heck, maybe they still do!) I don't think that had
anything to do with teaching large number of students to use their
systems. I don't think it had anything to do with the fact that
students quickly graduate into professionals. And I certainly don't
think it had anything to do with indoctrinating otherwise-astute
soon-to-be-professionals into the idea that they were "the only game in
town" (when, in fact, the alternatives are manifest and legion.) Nope,
they're just nice folks.
But you know...IBM may be even _nicer_ folks than the nice folks at The
Mathworks. Heck, whenever they gave away a mainframe, that's hardware.
It costs a lot of money to make that stuff, on a per-unit basis. They
had to buy parts from somebody, and they had to pay people to put it
together and get it running. They had to pay somebody to ship it, and
they had to pay somebody to install it. Sure, maybe they got a little
tax writeoff. And maybe they charged the University for a little
service contract or something. But mostly, they just lost money on the
deal. Those nice folks!
OTOH, if The Mathworks sells you a disk, a book and a box for, say $100,
there's a very good chance they make net a profit on each and every
unit. (For evidence, one need look no further than the local computer
store where nearly every disk/book/box package on the shelf costs much
less than that.) In fact, I bet The Mathworks derives a substantial
part of their revenue from the student version. (Let this be a lesson,
Kids: Altruism pays.) Sure, the per-unit profit is low (maybe only $50
or so after you take out the cost of the disk/book/box and the cut of
the University bookstore), but the quantity is high: lots and lots of
students end up buying Matlab because their University makes them do
their homework on it. (In fact, if you think about it, the University,
in effect, gets a "kickback" for every copy of Matlab they sell in their
bookstore. Not a bad scam!--and it's legal, too!) In business terms,
The Mathworks has established themselves a *very* lucrative franchise.
Maybe I should give up on being a "customer" and turn myself into a
"stockholder". (Then again, something this lucrative is probably
privately held.)
THEN those students turn into professionals. So they're supposed to
shell out for the professional version (even though TMW resists telling
them what it costs...) because the student version isn't licensed for
professional use. Of course, the quantity drops dramatically here
because most professionals are a little smarter than that: they know
that just doesn't make any sense, so they just keep on using the student
version. (Those naughty boys!) But for those few who _do_ pay, The
Mathworks makes even _more_ money. (Lemme see...$2500 - $50 for the
disk/book/box...carry the six...that's a net of about $2450. That'll
fund a whole lot of direct mail--to maybe go round up some old-time
professionals who weren't indoctrinated into Matlab in college. If only
The Mathworks could get to know them...)
So who says, "Nice guys finish last"? Although it might be interesting
to consider whether IBM or The Mathworks is nicer, let us not quibble
over that. Heck, I think they're _both_ pretty nice. Just look at all
the nice things they do for students.
;-)
Janez Makovsek
Sorry to intrude, but I dont now wheter I should lough or cry. Why in
God's name is Matlab so important? Every single thing, except the real time
interpreter, can be done better and faster in C++. And while real time
interpreter has it's advantages, it's a nightmare in compare to C++ when it
comes to some serious debugging.
On the other hand it's true that I have found only one (!) truly object
oriented C++ library for Matrix Vector operations properly implemented. And
guess who made it? MathWorks did C++ interface to their runtime engine! Ha!
It seems that there is absolutely no living soul out there, that would
understand the problems of numerical computing, be good in C++ and have a
vision on how to design an object oriented matrix vector library.
And the reason why MathWorks did it, is because they simply did not brake
any rules from Matlab. But obviously there is no one who would know what
rules are to be kept and what discarged bottom up. People just get too
creative and carried away.
I just dont get it...
And the reason for the silence of Mathworks is the same as for the silence
of Microsoft: MONOPOLY. Once you rule, you decide on the wishes of the
customers. You dont need any arguments. Why do you even bother...
Janez.
robert bristow-johnson <rob...@audioheads.com> wrote in message
news:38911...@news.viconet.com...
> fix is made is not good enough without justifying that statement. saying
> that the convention that MATLAB forces on us DSPers is more elegant than
the
> convention of DSP textbooks and literature is so ludicrous that i would
find
Peter J. Kootsookos
news:86sagd$ddd$1...@strelovod.uni-mb.si...
> Sorry to intrude, but I dont now wheter I should lough or cry. Why in
> God's name is Matlab so important?
I have found that Matlab (or one of the MEU's [Matlab Equivalent Units] like
Scilab) is the fastest way to develop and test new algorithms.
> Every single thing, except the real time
> interpreter, can be done better and faster in C++.
Definitely true! The execution speed of Matlab is not the fastest, but the
other thing that an Matlab has in its favour is that you can write the whole
thing in m-files and make sure the entire system works. Then, as you code
the C++ versions, you can easily substitute the calls to m-files to calls to
matlab-dll's that you've coded yourself.
Ciao,
Peter K.
--
Peter J. Kootsookos
http://www.clubi.ie/PeterK
Michael C Schweisguth
> Or what if a a tank of jet fuel cost twice as much as Cleve's Learjet.
wow! is this true? he is right up there with Steve Jobs.
> That must be why those nice folks at the TRW credit bureau keep track of
> your and my bill-paying habbits: They're just people persons.
well, i feel more sorry for the people who track my habits because they
have nothing better to do with their lives. since i recently secured
employment, i may even disappear from this "historically" long thread!
> I believe he believes in his customers, too. Especially the
> professional ones: he believes in their ability and willingness to
> shell out twice what their computer costs for his software.
what would the people do who make a living by claiming that Cancer costs
trillions of dollars to cure? come on, weve got to keep the economy
going! ;-(
> They had to buy parts from somebody, and they had to pay people to put it
> together and get it running. They had to pay somebody to ship it, and
> they had to pay somebody to install it. Sure, maybe they got a little
> tax writeoff. And maybe they charged the University for a little
> service contract or something. But mostly, they just lost money on the
> deal. Those nice folks!
you see, when you buy a professional copy of MATLAB, you are helping out
those at the Univerisity, you are giving back! (hee hee, hoo hoo!)
> OTOH, if The Mathworks sells you a disk, a book and a box for, say $100,
> there's a very good chance they make net a profit on each and every
> unit. (For evidence, one need look no further than the local computer
> store where nearly every disk/book/box package on the shelf costs much
> less than that.)
most students would probably be happy with an AOL style MATLAB-- no box,
or book--> just a CD.
> In fact, if you think about it, the University, in effect, gets a
> "kickback" for every copy of Matlab they sell in their
> bookstore. Not a bad scam!--and it's legal, too!)
bookstores have always been scams-- support student goverments and other
endeavors. it is sad that students actually have to fund these scams
with loans.
> Maybe I should give up on being a "customer" and turn myself into a
> "stockholder". (Then again, something this lucrative is probably
> privately held.)
well, i bought Microsoft stock rather than a computer, i would be a
millionaire today!
> THEN those students turn into professionals. So they're supposed to
> shell out for the professional version (even though TMW resists telling
> them what it costs...)
there helping subsidize the student version since when they were students,
professionals supsized the cost of MATLAB for them!
> Of course, the quantity drops dramatically here because most
> professionals are a little smarter than that: they know
> that just doesn't make any sense, so they just keep on using the student
> version.
but then they dont have bug fixes!, since Mathworks, like other companies,
dont fix old versions of their software. granted, their are patches,
but some fixes are only put in "newer versions" so that the fix becomes
a sought after feature.
> So who says, "Nice guys finish last"? Although it might be interesting
> to consider whether IBM or The Mathworks is nicer, let us not quibble
> over that. Heck, I think they're _both_ pretty nice. Just look at all
> the nice things they do for students.
discrimination pays!
Michael C Schweisguth
> but on this issue> (of rigid 1-based indexing) they have offered only
> lame excuses.
> Michael (or other MathWorks apologists on comp.soft-sys.matlab), would you
> care to speculate on the reasons behind deafening silence from MathWorks?
> Cleve (or anyone else at MathWorks), i challenge you to defend, technically,
> your rational for not fixing this thing (by implementing a backward
> compatible extension to the existing indexing scheme).
i do agree with on this; it would be nice to know wether it is really a
convention thing, or as i suspect, a very difficult software engineering
challenge.
it would be nice to get a statement, from Mathworks, indicating what
they think the challenges of this change are.
-take care,
Michael Robbins
1) Debugging is a joy. Between the interpreter and the fantastic
visualization functions, algorithms are VERY easy to test.
2) Matlab does not require many of the more tedious features of other
languages. No type definitions, etc.
3) Many prewritten, highly compatible routines make fast work of common
tasks.
4) The high precision, complex/real/matrix/vector/scalar variants and
operators make the language very powerful, somewhat akin to apl.
Make no mistake, dispite the complaints you may see on this forum by
myself, and others, Matlab is an indispensable tool for my group and
many, many more. It is the high cost of the professional version
(although the student version is quite powerful and VERY INEXPENSIVE)
that causes it's users to have very high standards.
I recommend you try it for FREE! <www.mathworks.com>
--
Michael Robbins, CFA
Director, Proprietary Trading
Debt Capital Markets
Canadian Imperial Bank of Commerce
Sent via Deja.com http://www.deja.com/
Before you buy.
Michael Robbins
list is now available in PDF format on <www.mathworks.com>. I was happy
they made the student version more capable for about the same price, but
a little distraught that I paid about 50x for nearly the same
functionality! Imagine how many would be shocked (and not pleasantly)
to find that if they waited a little longer to purchase, they could have
saved 98% !
MATLAB Toolbox Version 5.3.1 (R11.1)
Database Toolbox Version 2.0.1 (R11.1)
MATLAB Compiler (and Compiler 1.2.1) Version 2.0.2 (R11.1)
Symbolic Math Toolbox Version 2.1.1 (R11.1)
Partial Differential Equation Toolbox Version 1.0.3 (R11)
Financial Toolbox Version 2.1 (R11.1)
Statistics Toolbox Version 2.2 (R11)
Spline Toolbox Version 2.0.1 (R11)
Optimization Toolbox Version 2.0 (R11)
Michael Robbins
> So is there any explaining why some folks who live there
> think they just couldn't live anywhere else?--even the folks who
> grumble a bit about the potholes?!
>
> Since there are many games and many towns, I just can't figure it out.
I purchased Matlab for the luxury of quick and painless development. To
go to one of the clones would promise fewer features, more awkward use
and poorer support. If I wanted that, I'd have stuck with C++.
Olivier Lapierre
software ? And bore the pants of mathematica's users ? I'm sure that
it would help us to concentrate on usefull subjects, and may be make
you happier.
olivier....@ind.alstom.com
www.alstom.com
Cleve Moler
I have been following this thread since it started. I think I've
read every word of every post. I haven't said much until now because,
in my opinion, the discussion has had very little interesting
technical content. I know that many other people at MathWorks
have also been reading the thread, and have had the same reaction.
For many of us, our concern with 0-based indexing is the following.
We have written thousands of M-files, many of which are distributed
with MATLAB. We expect to write thousands more. Many of them look
something like this:
function ... = ...(X,...)
n = length(X);
for k = 1:n
... X(k) ...
end
Our question is: if we introduce other bases for indexing, what
do we do with functions like this? What happens to that "1" in
the middle of the third line?
I'm not worried about efficiency. I'm not worried about somehow
changing our internal subscripting code. I'm not worried about
the syntax for specifying some other base. I AM worried about
where to start the loops in library routines intended for general
purpose use on arrays whose pedigree we can't anticipate.
But, for the sake of discussion, let's assume we could finesse
this issue. How would 0-based indexing actually be used?
Here is my challenge to anybody who is still reading this thread:
please show us some hypothetical MATLAB code that profits
from 0-based indexing. I don't care what the syntax is. You
can just assume that x(0) is legal. If it were, what would some
serious code look like?
And, by the way, I don't have, or want, a Lear jet.
-- Cleve Moler
mo...@mathworks.com
Grant Griffin
>
> Hi.
>
> I have been following this thread since it started. I think I've
> read every word of every post. I haven't said much until now because,
> in my opinion, the discussion has had very little interesting
> technical content.
Tut, tut. All work and no play...
> I know that many other people at MathWorks
> have also been reading the thread, and have had the same reaction.
>
So lemme ask a dumb question: What kept everybody reading it?
<relevant but dull technical stuff snipped>
> And, by the way, I don't have, or want, a Lear jet.
I agree. Who can afford the fuel?
;-)
Grant Griffin
>
> Last year I bought the following, and I paid around $10,000 !
That's funny...I paid about the same amount for my last car. (Best
part: it came with hardware. ;-)
> The price
> list is now available in PDF format on <www.mathworks.com>.
Waitaminute--complaining actually works?!
> I was happy
> they made the student version more capable for about the same price, but
> a little distraught that I paid about 50x for nearly the same
> functionality!
That must be why their license terms say you shouldn't use the student
version. That way, you don't have to feel bad about paying 50x as much
for about the same thing.
> Imagine how many would be shocked (and not pleasantly)
> to find that if they waited a little longer to purchase, they could have
> saved 98% !
Well, I guess professionals can now _buy_ the student version, just so
long as they don't actually use it.
Grant Griffin
I read something relevant on the comp.lang.python the other day by Tim
Peters (who is a friend of Python's creator, Guido van Rossum <wink>).
As background: A controversial features of Python is its use of
whitespace to delimit blocks. Since few languages do that, the concept
is foreign to most people. Once they get used to it, many people
(including me) absolutely love it, but as you might imagine, this is an
recurring fight in the newsgroup: people who are new to Python bash this
feature, and people who like Python defend it.
(However, absolutely *nobody* bashes Python's price. ;-)
Somebody said:
> > They [the Python people] do not realize that this feature
> > is an important obstacle for many people
Tim replied:
> Neither is Guido an idiot <0.9 wink>. Of *course* he knows it's
> a show-stopper for some people. But so are many other things. Every
> language designer knows this, and the successful ones figure out early
> there's no future in trying to make everyone happy. There is a future
> in keeping a language's philosophy consistent for as long as possible,
> and the use of indentation to denote block structure wasn't an arbitrary
> choice in Guido's view of the world. He realizes it's an important
> obstacle; do "they" realize it's an important manifestation of Python's
> philosophy?
I would think this sort of thing applies to Matlab (except that the
issue at hand is indexing rather than whitespace delimiters). Cleve has
made the point that 1-based indexing is conventional with matrices. If
the Matlab's philosophy is to be a matrix programming language (rather
than a programming language which happens to do matrices), adhering
rigidly to matrix conventions seems at least to be a consistent
philosophy--even if it makes many user applications awkward.
the-ivory-tower-isn't-always-wrong-ly yr's,
Michael C Schweisguth
> Hi.
> something like this:
> function ... = ...(X,...)
> n = length(X);
> for k = 1:n
> ... X(k) ...
> end
> Our question is: if we introduce other bases for indexing, what
> do we do with functions like this? What happens to that "1" in
> the middle of the third line?
Ive pushed this problematic point myself many times in this thread,...
including what happens if you do:
indx = find(X>threshold)
since X and threshold may or may not have the same index and
indx may be a subvector.
> I AM worried about where to start the loops in library routines
> intended for general purpose use on arrays whose pedigree we
> can't anticipate.
well, your example is easily modified to get code that doesnt care
about what the index is! (as long as xk is a RHS value)
for xk = X(:)
// use xk
end
since MATLAB would iterate through the elements without an explicit
index.
this is a nice feature of MATLAB.
i guess that the main pusher of the 0 based index was happy to use a
"C" trick:
int x_values[257];
int *x = x_values + 128;
for(ii=-128;ii<=128;ii++) {
x[ii] = ??
}
in C++, the trick would be to return a "reference" from the overloaded
"()" operator.
BASIC has the construct (i think) :
for each xk in X
xk = xk + 5; // xk is like a returned C++ reference
end
so, the question is, does it make sense or is it possible for MATLAB
to work like BASIC does-- at least in my wishful thinking sense.
the Matlab code might look like:
foreach xk(k,0,n) in X using k = [0:N-1] withbase 0
xk = xk + 1
end
the foreach loop would be transformed to the MATLAB code:
ktemp = (0:N-1);
Xtemp = X(sub2ind(ktemp+1,0+1,n+1));
Xtemp = Xtemp(:);
Itemp = 1;
Ntemp = length(Xtemp);
while(Itemp>=Ntemp)
k = ktemp(Itemp);
xk = Xtemp(Itemp);
%the users "foreach loop body" goes here.
%xk(1) would be the identity xk.
%xk(0) is invalid.
%xk(2) is invalid.
Itemp = Itemp+1;
end;
by the pcode compiler.
i know, i know, this looks complicated!, but we're brain storming
here.
what is less complex is that you dont have to create a MATAB class
to muck with all this.
> But, for the sake of discussion, let's assume we could finesse
> this issue. How would 0-based indexing actually be used?
if the "foreach" could extend the indexing scheme, then maybe that
would be an accpetable answer for the distressed DSPer. the Mathworks
would just have to spit out pcode that implemented the "foreach" loop.
hence, the pcode could be backward compatible since no new pcode
ops would have to be designed.
> Here is my challenge to anybody who is still reading this thread:
well, lots of folks at the Mathworks, you, myself and about 5 others
are! ;-)
my challege to you: find another thread that went on for this long,
and had at least 5 participants!
granted, the "particpation histogram" would be lop sided.
> please show us some hypothetical MATLAB code that profits
> from 0-based indexing. I don't care what the syntax is. You
> can just assume that x(0) is legal. If it were, what would some
> serious code look like?
instead of x(0), i am thinking about "foreach" because no matter
what the index base is, im sure that people will have runtime
errors due to "invalid index" problems.
i also believe that using an x(0) scheme would impact many,
many functions like sub2ind() and ind2sub().
if the BASIC "foreach" system was used, and combined with
C++ references, then the other hot topic of having references
would be addressed.
namely, i would suggest a copy in, copy out RPC convention:
function docalculation(xk)
xk = xk + 1;
%this function would be invoked as:
reference xk;
xk(1:3) = [1 2 3];
foreach xk(k) in X
docalculation(xk)
end;
xk
%this function would say:
%
% xk =
% [2 3 4]
basically, the calling module would copy the value into the calling
workspace just before the symbol table of the invoked function was
destroyed.
of course, maybe this is all just too complex too.
BTW: a cannondale bicycle is much classier than a Lear! ;-)
especially out here in Tucson, since there is no
snow!
@canondale/canondale.m
issuperior('canondale','learjet');
John D'Errico
Moler) wrote:
> For many of us, our concern with 0-based indexing is the following.
> We have written thousands of M-files, many of which are distributed
> with MATLAB. We expect to write thousands more. Many of them look
>
> function ... = ...(X,...)
> n = length(X);
> for k = 1:n
> ... X(k) ...
> end
>
> Our question is: if we introduce other bases for indexing, what
> do we do with functions like this? What happens to that "1" in
> the middle of the third line?
Good question Cleve. Thank you for remembering that
existing base of code. I'd like my code to continue to
work, for at least a while.
> But, for the sake of discussion, let's assume we could finesse
> this issue. How would 0-based indexing actually be used?
It would be used to make my life considerably harder.
Every once in a while a few individuals might benefit from
a zero based index because it make a simple formula easier
to code. Gosh. I wish I had a penny for every time I've stared
at an expression for a few seconds, thinking of how best to
write it. This even for unitary based expressions. Maybe,
just maybe, those few seconds were time well spent anyway.
Maybe my code is the better for having spent them.
(If I did have those pennies though, I might be able to buy
one of those Lear jets for myself. Nah, my garage is too
small.)
This said, the rest of us will be fuming every time we trip
over those bugs we create when our own code fails, because
somebody introduced zero based indexing.
Suddenly, every piece of code I write would now have to
check for non-unitary indexing.
Why do some people assume that because they personally like
ketchup on their eggs, that the rest of the world must
think the same way?
> And, by the way, I don't have, or want, a Lear jet.
8-))
Keep up the good work,
John D'Errico
Valter Hilden
> ...
> Our question is: if we introduce other bases for indexing, what
> do we do with functions like this? What happens to that "1" in
> the middle of the third line?
This need for converting every existing function must be the biggest
objection to any change in indexing methods. I have faced it when
converting programs from FORTRAN to C, and there is no easy answer, you
*must* understand the code you are converting and go carefully checking
every line of source code.
I have also done that conversion in a few C routines I used from the
"Numerical Recipes in C" book, where they were too lazy to convert the
indexing scheme when translating from FORTRAN.
Given the implicit problems, why would anyone want to change an existing
indexing method? I do it always when I reuse a function or subroutine
that uses a method I consider "not natural" compared to the usual
mathematical notation for that particular case. I've found that the time
lost in debugging confusing notation is, in the long run, far worse than
the time lost in going through every line of code and changing the
indexes. This means I *do* use one-based arrays in C, whenever this
feels more natural to my mathematical understanding. It's simply a
matter of declaring, for instance:
double _zero_based_array[size];
double *one_based_array = _zero_based_array - 1;
If Matlab had some equivalent scheme, I would even consider using
Matlab. Without this, no way. I have lost too much time in my
professional life looking for stupid little bugs, where an array started
at the wrong place.
Michael C Schweisguth
> Michael Robbins wrote:
> >
> > Last year I bought the following, and I paid around $10,000 !
> That's funny...I paid about the same amount for my last car. (Best
> part: it came with hardware. ;-)
> > The price
ahh, but does the car have resale value! once version 6.0 comes out,
then how much would a 5.x release be worth?
> Well, I guess professionals can now _buy_ the student version, just so
> long as they don't actually use it.
lifelong learning! that is todays mantra. the worlds the *real*
classroom, so in todays word, professionals *can* use the
professional version.
Eric Jacobsen
wrote:
>I have been following this thread since it started. I think I've
>read every word of every post. I haven't said much until now because,
>in my opinion, the discussion has had very little interesting
>technical content. I know that many other people at MathWorks
>have also been reading the thread, and have had the same reaction.
That's good to know, but realize that a subsequent continued apathy or
lack of improvement is only going to disappoint a lot of us a lot more
now that we *know* you know.
And, BTW, thanks for responding to this issue. It is an important
issue to a lot of users (myself included), and this recent thread is
not the first time this has come up on comp.dsp over the years.
Making yourself available for this public discussion is a very good
thing. Thank you.
>For many of us, our concern with 0-based indexing is the following.
>We have written thousands of M-files, many of which are distributed
>with MATLAB. We expect to write thousands more. Many of them look
>something like this:
>
> function ... = ...(X,...)
> n = length(X);
> for k = 1:n
> ... X(k) ...
> end
>
>Our question is: if we introduce other bases for indexing, what
>do we do with functions like this? What happens to that "1" in
>the middle of the third line?
Legacy of a bad idea, in my opinion, is a poor excuse for continuing
along ad nauseum with the bad idea. At some point it is a benefit to
correct the bad idea, and the longer one waits to do it the more
painful it is. Most of us have probably dealt with this in our
engineering careers in some way or other, and it is rather irritating
to see an otherwise premier outfit and product like Matlab and the
Mathworks refuse to address it.
>I'm not worried about efficiency. I'm not worried about somehow
>changing our internal subscripting code. I'm not worried about
>the syntax for specifying some other base. I AM worried about
>where to start the loops in library routines intended for general
>purpose use on arrays whose pedigree we can't anticipate.
Are your people really not that creative? This is not a new problem,
as anybody who's ever had to translate useful stuff from FORTRAN to C
(for example) has dealt with this, often quite successfully, and often
in a library environment similar to the situation with Matlab. Are
the Mathwork's coders less competent?
In addition to the other good ideas already stated, I'll offer the
following (which may have been already stated as well):
function ... = ...(X,...)
n = length(X);
for k = SINDEX:n-(1-SINDEX)
... X(k) ...
end
where SINDEX is a constant, global variable, whatever, that indicates
where the array index starts. In this case it can be 0,1, whatever,
and the legacy user code is still compatible with the library if the
system initialization sets SINDEX to 1. Somebody like rb-j, myself,
or the numerous colleagues here and in my career experience that would
*really* like to can change SINDEX to 0 and make life much, much
easier and our productivity with Matlab higher. This would increase
the value of Matlab to our employers and make an easier case for
justifying the expense, probably resulting in more sales to the
Mathworks.
Yes, it does require a lot of maintenance on the part of the
Mathworks, but it would improve the product in the eyes of, in my
experience, a large number of users. I'm guessing that the truth is
that the coders at the Mathworks actually *are* competent and creative
enough to come up with very good solutions to the problem that
maintain compatibility with legacy user code.
>But, for the sake of discussion, let's assume we could finesse
>this issue. How would 0-based indexing actually be used?
I thought you said you'd read this thread?
>Here is my challenge to anybody who is still reading this thread:
>please show us some hypothetical MATLAB code that profits
>from 0-based indexing. I don't care what the syntax is. You
>can just assume that x(0) is legal. If it were, what would some
>serious code look like?
It would look like a Matlab implementation of the billions of lines of
C code that have been written because it is such a pain in the ass to
get Matlab to do this. Believe me, I've been a Matlab evangelist and
user for a long time, and I've heard this a lot: One reason a lot of
people prefer simulating in C is due to this indexing problem in
Matlab. I've often opted to use C for this reason, and I *like*
Matlab. You've lost a lot of sales to this exact issue if the
conversations I've had with folks over the years is any indication.
Matlab, IMHO and especially for people in this forum, is a tool for
visualizing and exercising the effects of various algorithms and
processes. Very often these algorithms and processes start out life
as a mathematical analysis done in common mathematical notation,
which, oddly enough, uses indices that very often start at zero. I'm
sure I don't need to explain to you that zero has some very special
mathematical properties, so in many cases the value and meaning of the
index is very important to the algorithm or process.
DSP has the particular example of indices with specific physical
meanings, like the index in a DFT. For real-valued signals life
begins in the frequency domain at DC, or zero-Hz. Not one, zero. So
a rigorously analyzed mathematical treatment of transforms for
real-valued signals will have indices that start at zero, and the
indices have special physical meaning relating to the signal. The
Mathworks wants us to disconnect a Matlab implementation not only from
the source mathematical notation, but from the physical significance
of the index values. I can't tell you how much frustration and time
loss this has caused me by not only confusing the code implementation
in having to code something different than the analysis, but in
interpretation of simulation results; "You mean bin 10 isn't ten
cycles per aperture? Why the hell not?" "Because I'm using
Matlab..." "Oh, shit..."
The same is true for many other instances, like delay in a correlator,
where zero delay is actually index 1, and a delay of ten samples is
actually index 11 in Matlab. Do you really think that this isn't
irritating? Do you really think that this isn't irritating enough
that a lot of people forego buying Matlab and just use C since these
exact problems are then easily avoided, and a lot of folks have C
compilers lying around anyway? It is very true that Matlab offers a
lot of power and productivity that you lose with a C simulation, but
many people opt for C because of the indexing issue and the time and
aggravation it saves in coding and interpretation. Matlab code can be
much less readable than C when there are loads of INDEX-1 calculations
to fix this freaking problem for subsequent computations using index
values that have real physical meaning.
The gory truth that, IMHO, the Mathworks needs to come to grips with,
is that the world uses mathematical notation for engineering that
start vectors with zero indices. Having tools available that don't
aggravate a disconnect from common notational language to simulation
language is a genuinely important issue. It makes not one bit of
difference to me and a host of others (some of whom post here,
obviously) that it is, in fact, possible to make Matlab work for all
of these problems. The point is that it takes a lot of extra effort in
coding and interpretation to do it. This diminishes the value of
Matlab as a tool for these purposes, and in my engineering career
experience there isn't much else that Matlab is good for. I do still
use Matlab a lot, because of the benefits that it offers, but I'd use
it more often, and a lot more productively, if this indexing issue
were fixed. As I've mentioned, if my experience is any indication,
there are a lot of people out there who are potential Matlab customers
but aren't because of this issue. It seems to me that the Mathworks
has consistently severed its own toes for the sake of one-based
indexing.
Eric Jacobsen
Minister of Algorithms, Intel Corp.
http://www.primenet.com/~ericj
Jerry Avins
>
...
>
> > Here is my challenge to anybody who is still reading this thread:
>
> are! ;-)
>
...
Jerry
--
Engineering is the art of making what you want from things you can get.
-----------------------------------------------------------------------
Grant Griffin
>
> In comp.soft-sys.matlab Grant Griffin <grant....@iowegian.com> wrote:
...
> > Well, I guess professionals can now _buy_ the student version, just so
> > long as they don't actually use it.
>
> lifelong learning! that is todays mantra. the worlds the *real*
> classroom, so in todays word, professionals *can* use the
> professional version.
Actually, I have considered buying the student version of Matlab.
However, I am not currently officially a "student", and probably won't
be anytime soon. (As a professional, I learn mostly on the job. ;-)
Therefore, since I refuse to pay thousands for the professional version,
I have no choice but to consider one of the many alternatives: Octave,
Scilab, Python, etc. Because I have recently switched from Perl to
Python as my scripting language of choice for general-purpose
programming chores, I will probably focus any of my future Matlab-ish
endeavors on Python.
Although I understand the attraction to most folks of simply buying the
current best-of-class tool (at any cost), I would submit that doing so
is a bit shortsighted in light of the other possibilities. I continue
to believe that if several of us DSPers would each contribute a little
effort to create a new "best-of-class" tool designed specifically for
DSP system analysis and simulation, we would be better off in the long
run than we are by separately paying high prices for Matlab. The "free
of cost" aspect of it would be very attractive, of course, but even
better, such a tool would be designed not around the paradigm of
"matrices" but around the paradigm of "DSP". (And if that happened to
involve matrices having a flexible base index, so much the better.)
Grant Griffin
>
> Cleve Moler wrote:
> > ...
> > Our question is: if we introduce other bases for indexing, what
> > do we do with functions like this? What happens to that "1" in
> > the middle of the third line?
>
> This need for converting every existing function must be the biggest
> objection to any change in indexing methods. I have faced it when
> converting programs from FORTRAN to C, and there is no easy answer, you
> *must* understand the code you are converting and go carefully checking
> every line of source code.
>
> I have also done that conversion in a few C routines I used from the
> "Numerical Recipes in C" book, where they were too lazy to convert the
> indexing scheme when translating from FORTRAN.
>
which is quite unforgivable. It would have been much cheaper in the
aggregate for them to do it than for each of us to do it. (This is
pretty-much the definition of poor quality: saving your own cost at the
expense of cost-to-society.)
Although one might make a case that one-based addressing makes sense in
Matlab (and in its cousin, FORTRAN ;-), one can make no such case in C.
When in Rome, use zero-based addressing.
> Given the implicit problems, why would anyone want to change an existing
> indexing method? I do it always when I reuse a function or subroutine
> that uses a method I consider "not natural" compared to the usual
> mathematical notation for that particular case. I've found that the time
> lost in debugging confusing notation is, in the long run, far worse than
> the time lost in going through every line of code and changing the
> indexes. This means I *do* use one-based arrays in C, whenever this
> feels more natural to my mathematical understanding. It's simply a
> matter of declaring, for instance:
>
> double _zero_based_array[size];
> double *one_based_array = _zero_based_array - 1;
I use an even more radical approach to this in ScopeFIR's
Parks-McClellan routine. The PM routine is a thin translation from
FORTRAN into C. I created a C++ class to implement one-based arrays.
The basic trick (which is an alternative to what you're doing) is to
allocate the array one bigger than requested so that one-based
operations don't fall off the end. Then, as the last step, a copy
operation copies the PM result back to the land of the zero-based
(which, being in C++, is how the rest of the program is written.)
An advantage of this scheme (which is a side-effect, really) is that the
C++ class does array bounds checking in debug mode via an ASSERT. (This
is kind of like Ada, except not slow.)
>
> If Matlab had some equivalent scheme, I would even consider using
> Matlab. Without this, no way. I have lost too much time in my
> professional life looking for stupid little bugs, where an array started
> at the wrong place.
(not to mention that Matlab costs too much. ;-)
Jeff Stuart
Isn't it a little dishonest to spend all of your time slamming Matlab's
pricing structure without clearly stating that you are selling a competitive,
even if very limited, DSP package? And if Cleve is a slimey capitalist
because he charges more than you think he should for MATLAB,
what should we make of the fact that you want $100 for your shareware
DSP package that we can download off of the net? Does it really
cost you $100 to post your packages to an ftp site, or <GASP> are
you making a profit at the expense of users? And if so, why is it
okay for you to make a profit, but wrong for Cleve to make one? And,
I am sure that your $100 has to help cover the costs of a far smaller
pool of full time employees (one? two? three?) at Iowegian International
than the large staff of full-time programmers, full time support personnel
and full time business personnel at the Mathworks that has to be supported
by the per-copy price of Matlab.
Finally, if you do not know Cleve, and if you have never met him, how is
it that you know so much about his income and spending habits? Or
are all of the snide remarks about Cleve's learjet and his ill-gotten wealth
supposed to win points where your logic fails?
Jeff Stuart
long term matlab user
Grant Griffin
>
<good feedback snipped>
> As I've mentioned, if my experience is any indication,
> there are a lot of people out there who are potential Matlab customers
> but aren't because of this issue. It seems to me that the Mathworks
> has consistently severed its own toes for the sake of one-based
> indexing.
Hi Eric,
One of the things I was surprised about when I started selling software
is that I get virtually zero user feedback (either positive or
negative). However, my company is a small outfit (as you might have
guessed.) I'm always amazed, therefore, when I see big outfits like
Microsoft and The Mathworks ignore good user feedback like this,
because, from my shoes, solid feedback like this is quite a rare and
valuable commodity. In particular, the hints you offer about how to
sell more units would seem to be something that an outfit with 500
mouths to feed would be interested in.
I once read a book about programming which talked about "candy machine
interfaces". These are simply user-interfaces which tend to create user
confusion rather than preventing it. When people find a gizmo hard to
use, the first reaction of the gizmo's maker is usually to blame the
users. However, it seems intuitively obvious to me that it is, ipso
facto, the gizmo's fault. So if people faithfully press the buttons on
the candy machine and then wind up with the wrong candy, it's time to
re-design the machine.
The candy-machine folks may not realize this (and they certainly would
never *admit* it), but users who complain about the machine actually are
being quite charitable: if the candy machine folks get lead kicking and
screaming into redesigning the machine in such a way that makes their
business thrive and prosper, users will have actually rewarded their
arrogance with a favor. (And if you think about it, that's even kinder
than "turning the other cheek". <slap!>)
when-folks-get-the-candy-they-want-you-won't-hear-from-'em-ly y'rs,
Michael C Schweisguth
> where SINDEX is a constant, global variable, whatever, that indicates
> where the array index starts.
the nasty thing is that someone could set this to NaN or [], and
therefore, it would have to be a function that would barf if some
silly index was given--> because it is better for a program to be
robust then not.
> In this case it can be 0,1, whatever, and the legacy user code is
> still compatible with the library if the system initialization sets
> SINDEX to 1.
i guess the y2k programmers would start modifying MATLAB code.
> This would increase the value of Matlab to our employers and make
> an easier case for justifying the expense, probably resulting in more
> sales to the Mathworks.
??, would it be worth more than $2500 for a base installation.
> >But, for the sake of discussion, let's assume we could finesse
> >this issue. How would 0-based indexing actually be used?
> I thought you said you'd read this thread?
;->
> Believe me, I've been a Matlab evangelist and user for a long time,
> and I've heard this a lot: One reason a lot of people prefer simulating
> in C is due to this indexing problem in Matlab.
ill bet that Mathworks could show you that more than 10% of their users
have never fired up a C compiler. of the people in the Optics Lab
where I work, 8 out 10 of them can use MATLAB but not C. the could
care less about header files, strict data typeing, etc... they have
journals to read, phD dissertations to write, and experiments to
perform
> You've lost a lot of sales to this exact issue if the
> conversations I've had with folks over the years is any indication.
on this point, what kind of study can we set up to prove this.
currently, 20,000+ people go to the Mathworks store each day.
does this represent discontent? with the radical 5.0 upgrade as well
as the growth in toolboxes, i think that peoples curiosity is brewing!
> I'm sure I don't need to explain to you that zero has some very special
> mathematical properties, so in many cases the value and meaning of the
> index is very important to the algorithm or process.
but then, remember that "eps" is often used since digital processors
dont have infinite precision.
> I can't tell you how much frustration and time loss this has caused
> me by not only confusing the code implementation
but you did have time to write this really long note?
> The point is that it takes a lot of extra effort in coding and
> interpretation to do it.
but if you have the brain to do DSP, then...
> This diminishes the value of Matlab as a tool for these purposes,
> and in my engineering career experience there isn't much else
> that Matlab is good for.
well, i worked on an application which has: over 1000 m-files,
lots of GUI screens, etc...
i dont believe that we could have ever wrote the app in C because
80% of our talent doesnt program in C.
it was sad that it was nearly impossible to distribute our code
since the runtime environment makes the application expensive.
and, mcc just couldnt compile this many m-files to a reasonable
application size--> maybe it could do it if we spent more time
laying out the program's architecture.
MATLAB is used by the financial industry, electrical engineers,
dspERROR's, etc...
does Michael Robbins demand that MATLAB print dollar signs in front
of all the numbers that it prints?
Jerry Avins
>
> In comp.soft-sys.matlab Eric Jacobsen <er...@primenet.com.nospam> wrote:
>
> > where the array index starts.
>
> therefore, it would have to be a function that would barf if some
> silly index was given--> because it is better for a program to be
> robust then not.
It's always possible to write a bug. The question is whether permitting
zero-based indexing would create or avoid more. The facility could never
create bugs for those who choose not to use it.
>
> > In this case it can be 0,1, whatever, and the legacy user code is
> > still compatible with the library if the system initialization sets
> > SINDEX to 1.
>
> i guess the y2k programmers would start modifying MATLAB code.
Huh?
>
> > This would increase the value of Matlab to our employers and make
> > an easier case for justifying the expense, probably resulting in more
> > sales to the Mathworks.
>
> ??, would it be worth more than $2500 for a base installation.
Probably not, but (also probably) a few more people would buy it at that
price.
>
> > >But, for the sake of discussion, let's assume we could finesse
> > >this issue. How would 0-based indexing actually be used?
>
> > I thought you said you'd read this thread?
>
> ;->
>
> > Believe me, I've been a Matlab evangelist and user for a long time,
> > and I've heard this a lot: One reason a lot of people prefer simulating
> > in C is due to this indexing problem in Matlab.
>
> ill bet that Mathworks could show you that more than 10% of their users
> have never fired up a C compiler. of the people in the Optics Lab
> where I work, 8 out 10 of them can use MATLAB but not C. the could
> care less about header files, strict data typeing, etc... they have
> journals to read, phD dissertations to write, and experiments to
> perform
So? What about the rest?
>
> > You've lost a lot of sales to this exact issue if the
> > conversations I've had with folks over the years is any indication.
>
> on this point, what kind of study can we set up to prove this.
> currently, 20,000+ people go to the Mathworks store each day.
Wouldn't it be nice if there were 50 more?
>
> does this represent discontent? with the radical 5.0 upgrade as well
> as the growth in toolboxes, i think that peoples curiosity is brewing!
>
> > I'm sure I don't need to explain to you that zero has some very special
> > mathematical properties, so in many cases the value and meaning of the
> > index is very important to the algorithm or process.
>
> but then, remember that "eps" is often used since digital processors
> dont have infinite precision.
This is germane?
>
> > I can't tell you how much frustration and time loss this has caused
> > me by not only confusing the code implementation
>
> but you did have time to write this really long note?
That's being ridiculous! (I hope you figured that out by now.)
>
> > The point is that it takes a lot of extra effort in coding and
> > interpretation to do it.
>
> but if you have the brain to do DSP, then...
I give up! The discussion had been rational, if often heated up to now.
You've pushed it over the edge for me.
>
> > This diminishes the value of Matlab as a tool for these purposes,
> > and in my engineering career experience there isn't much else
> > that Matlab is good for.
>
> well, i worked on an application which has: over 1000 m-files,
> lots of GUI screens, etc...
>
> i dont believe that we could have ever wrote the app in C because
> 80% of our talent doesnt program in C.
>
> it was sad that it was nearly impossible to distribute our code
> since the runtime environment makes the application expensive.
> and, mcc just couldnt compile this many m-files to a reasonable
> application size--> maybe it could do it if we spent more time
> laying out the program's architecture.
>
> MATLAB is used by the financial industry, electrical engineers,
> dspERROR's, etc...
>
> does Michael Robbins demand that MATLAB print dollar signs in front
> of all the numbers that it prints?
Jerry
Jordan Rosenthal
This is a rather long post. I could not sleep and since it is so quiet in
the middle of the night, I decided to think a bit about our little indexing
problem. In this post I try to establish the source of the problem and have
fleshed out the beginnings of a possible solution (hopefully). It is not
perfect, but it is a start.
To start, I had been thinking about the question "Why is the 1-based index
such a sore point for DSP people" and the related question "Why is the
1-based index _not_ a problem in other fields". The simple answer is that
the conventions in the textbooks are just different for different fields. I
think, however, that the answer goes deeper than this.
Consider the following continuous-time problem:
%============================
% Problem 1:
% Find the time at which the value the function
% x(t) = (t-1)^2 reaches its minimum. The error in
% the measurement should be less than 0.01 seconds.
%============================
t = 0: 0.01 : 2;
x = (t-1).^2;
k = find(x==min(x));
theTime = t(k);
Ignore the fact that this problem has an obvious solution. This is a valid,
if not particularly insightful, way to solve the problem and I'm just using
it to illustrate an idea. Now consider the similar discrete-time problem
%============================
% Problem 2:
% Find the index at which the function
% x[n] = (n-1)^2 reaches its minimum.
%============================
n = 0:5;
x = (n-1).^2;
k = find(x==min(x));
theIndex = n(k); % theIndex ~= k
Obviously, these two problems are analogous. In the continuous-time
problem, it is obvious that the index from FIND does not equal the minimum
time because the physical units in the continuous world are much different
than the array index. In the discrete-time problem, however, the "physical"
units are so similar to the array index that most people do not even
consider the difference. People do not treat problem 2 the same way they
treat problem 1, even though they are fundamentally the same. The n in x[n]
can too easily be interpreted as the index of the storage array.
Okay, I know this is somewhat obvious. The reason I wanted to belabor this
point is because it illustrates that the argument concerning the indexing
does not arise because of a difference in the textbook conventions, but
arises because people in the DSP field do not separate the "physical" units
of x[n] from the indices to its storage array.
If Matlab programmers from the DSP field could change their mindset then
there would not be any problems. This is, of course, NOT going to happen.
It is not natural to separate the x[n] into its "physical" units (0:N-1) and
the indices to its storage array (1:N in Matlab).
If Mathworks is to facilitate the use of Matlab in the DSP community, it
either needs to:
1) Teach the DSP community the correct mindset.
2) Add features to Matlab that make the difference between "physical" units
and indices more transparent.
Concerning 1 (teaching the correct mindset):
-------------------------------------------
I think most will agree that this would be near impossible to do. A first
step, however, would be to improve the Signal Processing Toolbox manual
since it is the only place where Mathworks has the chance to impress upon
its users the correct techniques.
Suggestion to Mathworks: A quick look through the current Signal Processing
Toolbox manual shows little discussion of the indexing issue (there are a
few places, but no examples of possible problems that may occur). Most of
the plots are continuous-time plots, and there are few discrete-time
examples. It is no wonder that the bridge from the DSP mindset to the
Matlab mindset is not made; the user never sees code that illustrates the
difference.
One of the first sections entitled "Representing Signals" does not even give
a plot of the signal being represented. The next section does, but it
illustrates a continuous-time example. I think there should be something
added to the manual to illustrate discrete-time problems.
I also think that there should be some discussion about how to translate a
formula given either in discrete-time or continuous-time to its Matlab
representation since this is apparently one of the things with which people
have problems (maybe attach the discussion to one of the current examples).
I taught a DSP theory course (using Matlab) for a while. One of the first
things I asked students to do was plot the signal x[n] = cos(2*pi/10*n).
Most students created code like:
x = cos(2*pi/10*(0:100));
stem(x);
This plot is, of course, wrong since the plot starts at one instead of zero.
I always had to explicitly tell them that they should get in the habit of
carrying the "time" index in a separate vector such as
n = 0:100;
x = cos(2*pi/10*n);
stem(n,x);
This usually got the idea across to them that there is a difference between
the indices for the signal's storage and the discrete-time index. I think
that the Signal Processing Toolbox manual should make this clear. At least
point out the issue more carefully.
Finally, there are NO examples I could find to explain how (or more
importantly when) to use FFTSHIFT or any examples of how to deal with the
frequency response of signals which do not begin at zero. These operations
are essential and really should be addressed in the manual.
Concerning 2 (adding features):
------------------------------
There is only so much Mathworks can do to encourage the correct mindset.
Even with the best writers in the world, an improved manual will only help a
certain subset of people understand the Matlab perspective of programming.
Many do not even read the manual.
As I tried to explain earlier, I think the indexing issue is _endemic_ to
the DSP field and does not present problems in other fields only because it
more clear in other fields what the "physical" units are. If Mathworks is
interested in facilitating the use of Matlab in the subset of the DSP
community who cannot or will not get used to the 1-based indexing, they will
need to make it easier to write code for tasks such as problem 2 above.
This will amount to making some way to distinguish between "physical" units
and storage indices.
So far the best suggestion I have heard yet is to use a class (or even a new
datatype ?). I have fleshed this idea out a little more. Here is a
possible function prototype for a generic indexed object. This should
address some of the issues in this newsgroup thread as well as another
thread that talked about indexing with the form x('mylabel').
%INDEXOBJ Create an INDEXOBJ.
% y = INDEXOBJ(data,index) creates an indexed object from the vectors
% data and index. The two vectors together describe the indexed
% object such that
%
% y(index(i)) = data(i)
%
% Referencing an INDEXOBJ object:
%
% If y is referenced in code, it will return data.
% If y.data is referenced in code, it will also return data.
% If y.index is referenced in code, it will return index.
% If y(k) is referenced and k is one of the elements in
% y.index, then data(i) is returned. Otherwise an error is
% returned.
% If y(logical(k)) is referenced, it will return data(logical(k))
%
% Special syntax:
%
% Because of the way it is defined above, when using an INDEXOBJ
% as an argument to a function, it will by default pass y.data.
% To pass the actual object, use y.object instead. This is the
% only time the reference y.object is valid.
%
% Valid Assignments:
%
% y.data = (something the same size as y.index)
% y.index = (something the same size as y.data)
%
%
% Other calling forms:
%
% y = INDEXOBJ(data,index) where index is an array of cell strings
% y = INDEXOBJ(data,index) where both data and index are arrays of
% cell strings
% Ex.
% n = -99:99;
% x = cos(2*pi/10*n);
% y = signal(x, n);
% plot(y.index, y, 'b-', 0, y(0), 'ro'); hold on;
% % Plots the signal and highlight the first term
% plot(y.index(y<0), y(y<0), 'y');
% % Plots values for y less than zero in yellow
%
% Y = signal(fft(y,256), 0:255);
% plot(Y.index, abs(Y), '-', 0, abs(Y(0)), 'ro');
% % Plots the magnitude response and highlights DC term
%
% Ex.
% y = indexobj(0:4, {'a','b','c','d','e'});
% z = y('a') + y('b'); % z = 1
%
% y = indexobj({'red','blue','green'},
{'Color1','Color2','Color3'});
% disp(y('Color1')); % Displays 'red'
One problem is how to handle things like z = y1 + y2 when both are INDEXOBJ
objects. The way I have defined it above this will convert to z = y1.data +
y2.data and so the sum will not be an INDEXOBJ. I figured it was best to do
it this way and leave it up to the user. If one wanted to create z as an
INDEXOBJ, the user could use something like z = signal(y1+y2,y1.index).
Some things to note:
1) This addresses some of the DSP community problems, i.e., it makes it easy
to define alternate indices.
2) It is backward compatible since any older code called with just y as an
argument will pass y.data just as if you were not using the INDEXOBJ
wrappings. If newer code wants to take advantage of the object properties
it can be passed to the function with y.object. This should appease Cleve's
concerns.
3) It does not hamper the use of the find command since one can always
reference the actual data. For example, k = find(y<3), z = y.Data(k).
4) It is very general and adds useful functionality.
5) Performance not likely to be very good. Consider the reference
y(1:3:end). Matlab would need to check that each element in (1:3:end) is an
element of y.index. Logically, all(ismember(1:3:end,y.index)) needs to be
checked. For now, however, Cleve said he wasn't concerned about
performance, so that is all I will say about this. I figure let's worry
about performance after we can settle on a possible solution.
Now, if we want to make things even more useful to the DSP community, we can
create a SIGNAL object for the signal processing toolbox that builds upon
the INDEXOBJ. It would mostly be the same except for some overloaded
functions:
% Overloaded functions:
%
% Should only overload for signals which are uniformly sampled, i.e.,
%
% all(diff(y.index)==diff(y.index(1:2)).
%
% Otherwise, give a warning that it is not being treated as a SIGNAL
object
% and then call builtin versions of the function with y.data.
%
% Y = FFT(y): Finds the fft and adjusts for the delay/advance given
by
% y.index(1). Sets the index to Y.index =
freqspace(length(y),'whole')
% Y = FFT(y,NFFT) same thing with length NFFT.
% Y = FFT(y,NFFT,index) instead sets Y.index = index.
%
% FILTER(b,a,y), FILTER(y1,y2), CONV(y1,y2) where y,y1,y2 are SIGNAL
% objects will return a signal object and adjust index lengths as
% necessary.
%
% (...Other SP toolbox functions can be similarly adjusted...)
Adding those options to the fft would make it much nicer to deal with
signals that do not start at zero. Perhaps, unlike the proposal for the
INDEXOBJ, the sum of two SIGNAL objects could be another SIGNAL object whose
indices are appropriately adjusted to cover the support of the two signal
being added. Although the various possibilities for a SIGNAL object are
intriguing I think I am getting ahead of myself. I'll wait to express these
ideas until after receiving feedback about the feasibility of the INDEXOBJ
idea.
Okay, I'm done for the night (actually, I guess its morning now). :)
I've suggested what I think can be used as a possible solution to our little
conundrum. Now let's see what holes we can poke in this. What am I
missing?
Have fun,
Jordan
PS Cleve, I know I didn't answer your request to see some concrete examples
that would take advantage of the x-based system. Personally, I always
agreed with you that adding one to the index was not a big deal so there are
none that stick out well in my mind. This proposal (if it actually winds up
being feasible after the public scrutiny) goes even further than just
x-based indexing since it also includes referencing like x('red'). So my
suggestion to consider this idea is because it would not only appease the
concerns of the people who have been so vocal lately on the indexing issue,
but would also add quite a bit of functionality to Matlab (without affecting
the people who do not care to take advantage of it).
Grant Griffin
>
> Grant:
>
> Isn't it a little dishonest to spend all of your time slamming Matlab's
> pricing structure without clearly stating that you are selling a competitive,
> even if very limited, DSP package?
No. To do as you suggest would be to advertise my off-topic product in
an comp.soft-sys.matlab.
(Besides, if you've ever seen ScopeFIR and Matlab's FIR filter design
GUI, you'd know there's no competition. ;-)
Seriously, I specifically make it a point not to put down competitors.
In all honesty, I don't consider Matlab and Iowegian to be in
competition, because the products are so different. Mine is a
single-purpose, highly polished thing and Matlab is a highly flexible
thing which can do the same stuff as mine (and much more, obviously) but
from a programming-language, not GUI paradigm.
(Apples don't specifically compete with oranges, notwithstanding the
fact that any given user might bite into either.)
> And if Cleve is a slimey capitalist
> because he charges more than you think he should for MATLAB,
> what should we make of the fact that you want $100 for your shareware
> DSP package that we can download off of the net?
Read my lips, Jeff. My point is not--and has never been--that Cleve is
a slimey capitalist. (Although you gotta admit that the trick about
trying to get me to tell them my address just for the privilige of
learning what their product costs was pretty slick--I think I described
that as "genius" ;-) In fact, if you read carefully, you will discover
that I admire him for his business success.
My point is mainly that Matlab costs too much. I say this from a
customer perspective, not from a competitor's perspective, and not from
a businessman's perspective (even though I sometimes wear those hats).
Specifically, I have never worked for an employer who thought he could
afford to buy me Matlab. This is the genesis of my customer
perspective. And when I find that the Matlab folks actually _pay_
people to tell me what it costs--at great trouble to me, as it was a
couple of years ago when I last checked--then my attitude worsens.
Also, as a moral issue, I reject the idea that software should cost
twice as much as the computer it runs on. (By "moral issue", I mean
that I can't justify this in any way, I simply feel it deep in my
bones.)
Note, though, that every time Henry Ford lowered the price of the
Model-T, profits increased. If this sort of thing were to happen in
Matlab's case as a result of prodding by this customer (this
non-customer, actually), I would be doing them a favor. And if they
were to lower the price, but profits declined, I would at least be doing
other customers a favor.
But let's not give me too much credit: surely I'm not the first person
to ever suggest that Matlab costs too much.
> Does it really
> cost you $100 to post your packages to an ftp site, or <GASP> are
> you making a profit at the expense of users?
(welcome to my parlor said the spider to the fly...)
Yep, I make a profit. In fact, since I sell my stuff as shareware, my
per-unit cost is very small. So it's almost all net. But as you might
imagine, my volume is much lower than Matlab's. As a hint, let me tell
you that very few people get rich selling shareware. And those who do
certainly don't target a *very* small niche like DSP developers. So I'm
not gonna be buying a Learjet anytime soon. (Besides, who can afford
the fuel? ;-)
In fact, the smallness of this niche is the reason why companies like
TMW are able to sell their stuff for thousands, whereas a far _more_
complex piece of software like Windows goes for about $100. Therefore,
professional-quality DSP applications which sell for $100 or less
are...dare I say it?...cheap. (BTW, the student version of Matlab is
_extremely_ cheap--it has much more capability than mine at about the
same price. If the professional version of Matlab were to cost, say,
five times what the student edition costs--$500--you wouldn't hear from
me: it's well worth $500.)
But I digress. The beauty of shareware (for the vendor, and therefore
also for the customer), is that you can do it at virtually zero per-unit
cost. With shareware, I don't even have to spend the $50 (or, most
likely, much less) that Cleve is spending for each disk/book/box he
sells you. Besides what the credit-card people take, the only real
per-unit cost is support, and my customers require virtually zero of
that. So shareware is almost all gravy.
Cleve has a somewhat different business model. His customers probably
require more support, if, for no other reason than the fact that the
product is much more complex. (As a total guess, maybe 100 of TMW's
employees do support.) Also, Cleve, as you well know, spends a great
deal of money on advertising: direct mail, magazine ads, etc. Oh, and
he has to pay people to answer questions about how much Matlab costs.
(Which was strictly his own choice, BTW...) But in business terms, if
Cleve can spend $2000 to round up one customer who pays $2500 for a
package that costs him $50 per unit to manufacture (plus, let's say
$200--as a total guess--for support), he has netted $250 for that unit,
and the $2000 was very well spent--at least from _his_ perspective. In
fact, maybe we should all thank him for all the nice magazines he buys
us.
The shareware business model is _much_ different. The "advertising" is
pretty-much web pages (and other free forums like Usenet ;-). This
allows the vendor to sell stuff for cheap. For example, my nearest
actual competitor (who shall remain nameless) sells his filter design
package for about $800. True, it has a few extra features, but mine is
better in other ways. So the shareware business model makes it possible
for me to sell at 1/8 the price of my nearest competitor.
The down side, though, for the vendor is that people won't pay a lot for
shareware. (Notwithstanding the fact that many large software vendors
are now providing trial versions and selling the software online--except
that they don't call that "shareware".) You need to give most people a
disk/book/box plus do a lot of feel-good advertising in order to
convince them to pay much more than about $100.
> And if so, why is it
> okay for you to make a profit, but wrong for Cleve to make one?
God bless Cleve and his heavy wallet. I'm not putting him down. (Oh,
except for that shady pricing thing... ;-) HONEST, I think there's
every reason to believe he's a very nice man with excellent technical
and business skills. I'm simply encouraging his customers to realize
that they don't have to pay so much. And once his customers realize
this, Cleve will realize it too. It looks like the price has already
come down, but it has a lot more room to go.
> And,
> I am sure that your $100 has to help cover the costs of a far smaller
> pool of full time employees (one? two? three?) at Iowegian International
You flatter me. <blush> One day I hope to grow to a full-time staff of
one.
> than the large staff of full-time programmers, full time support personnel
> and full time business personnel at the Mathworks that has to be supported
> by the per-copy price of Matlab.
If The Mathworks finds that they can make the most money with inflated
prices and an inflated cost structure, God bless 'em. There is
absolutely nothing wrong with that.
My point is merely that we customers should encourage a little deflation
here. The existence of a rich set of open/free alternatives makes that
possible, if only we will realize that the games in this town are
manifest and legion. More importantly, I think We The DSP People could
make something even better.
BTW, if my efforts here are wildly successful, it can, at best, hurt my
business. How many people are gonna want to pay $100 for an apple when
they can get an orange for free. Think about it.
>
> Finally, if you do not know Cleve, and if you have never met him, how is
> it that you know so much about his income and spending habits? Or
> are all of the snide remarks about Cleve's learjet and his ill-gotten wealth
> supposed to win points where your logic fails?
It was a joke, Jeff. Among other things, Usenet is for fun.
nobody-ever-seems-to-complain-about-potshots-at-Bill-Gates-ly y'rs,
Andrew Reilly
this enormous thread because I've dealt with the issue to my own
satisfaction long ago. I just picked up when I saw Cleve's name
in the From list...
In article <38933933...@news.primenet.com>, Eric Jacobsen wrote:
>On 28 Jan 2000 21:13:27 -0500, mo...@mathworks.com (Cleve Moler)
>wrote:
>In addition to the other good ideas already stated, I'll offer the
>following (which may have been already stated as well):
>
> function ... = ...(X,...)
> n = length(X);
> for k = SINDEX:n-(1-SINDEX)
> ... X(k) ...
> end
>
>where SINDEX is a constant, global variable, whatever, that indicates
>where the array index starts. In this case it can be 0,1, whatever,
>and the legacy user code is still compatible with the library if the
>system initialization sets SINDEX to 1.
No, that breaks library code. And the mathworks aren't the only
folk with library code. I've got buckets of my own, thanks.
The reason it breaks library code is that the libray code might,
and probably does, have computational dependancies on the values
of k. All of a sudden, your transforms have twisted 1/nth to the
right...
>Matlab, IMHO and especially for people in this forum, is a tool for
>visualizing and exercising the effects of various algorithms and
>processes. Very often these algorithms and processes start out life
>as a mathematical analysis done in common mathematical notation,
>which, oddly enough, uses indices that very often start at zero. I'm
>sure I don't need to explain to you that zero has some very special
>mathematical properties, so in many cases the value and meaning of the
>index is very important to the algorithm or process.
I'll snip here, becasue this last sentece is the crux of the issue,
as far as I can see.
The people who want zero (or other) based indexing, want to be able
to impute a physical significance on the indices of the matrices
that they are manipulating, whithout writing that relationship
down. Matlab is a matrix toolbox. Every text on matrices that
I've ever seen numbers the elements the way Matlab does, in rows
and columns, starting at 1. That's probably why Fortran does it
that way too. C wasn't designed with mathematical modelling in
mind. C's arrays start at 0 because of the equivelance between
indices and pointer arithmetic. Pretty obviously, if you have a
block of memory pointed to by a double *p, then *(p+0) is the first
element, and so p[0] must also be the first element. They didn't
do it that way because they thought that the first element might
be used to represent the DC value of the positive extent of a
frequency spectrum.
When I use matlab to plot frequency spectra, I usually generate a
vector of the appropriate values [-1,1/N,1-1/N] to apply to the X
axis.
If I'm dealing with a time series, it's not that hard to translate
a vector of milisecond offsets into the appropriate range of indices.
You have to do it explicitly. That's a good thing.
--
Andrew
Michael C Schweisguth
the odd thing is that i dont see this as an issue of DSPer
> Okay, I know this is somewhat obvious. The reason I wanted to belabor this
> point is because it illustrates that the argument concerning the indexing
> does not arise because of a difference in the textbook conventions, but
> arises because people in the DSP field do not separate the "physical" units
> of x[n] from the indices to its storage array.
vs the rest of the world. instead, i agree with your broad
theme that some people like writing x(0) for x at time 0 and
X(0) for the DC component of signal x.
its too bad that structures werent around from day one. otherwise,
functions could have been designed to return both the ordinate vector
and the abcissa vector. then, one would call: plot(ordinate, abscissa).
however, i think that this would be shunned because people like to
nest function calls like this :
fftshift(fft(y))
currently, i dont think that it is possible for fftshift() to
influence how many outputs that fft() returns. of course, now
that MATLAB has structures, a single output can be interpretted
as a lightweight workspace containing lots of variables.
#2
> One of the first sections entitled "Representing Signals" does not
> even give a plot of the signal being represented.
when plot(data.y) is called, it seems that MATLAB shouldnt
label the x-axis at all. because MATLAB *does* label the
x-axis, it leans to confusion because the default labels
really have no meaning. hence, they should not be shown.
therefore, i think that we both agree that displaying
the x-axis labels, when none are specified, is a bug.
all functions should probably return both an ordinate vector
and an abcissa vector--> where appropriate.
#3 (an observation -- not really directly related)
ive never used the symbolic toolbox, but i am sure that one day-- or
even now-- the user could give the symbolic code to the symbolic
toolbox and it would spit out a MATLAB function that would calculate
the result. hence, the symbolic toolbox would be responsible for
transforming the symbolic function into something that MATLAB
could calculate in an efficient way.
OMATRIX has a "function class" which can hold a runtime compiled
function-- which is quite advanced when compared to MATLAB's
@inline object. if this technology was added to MATAB, then
there might be an easy way to efficiently let MATLAB do the
transformation gruntwork.
#4
> % Y = FFT(y,NFFT,index) instead sets Y.index = index.
do you think that adding additional input parameters to functions
makes sense? typically, i find that people like defaults--> which
is why a MATLAB plot can easily fool someone about the domain and
range of a function. (seeing is believing)
#5
your thinking is much like mine in that you are thinking of a local
solution rather than a global solution. that is, anytime that
an INDEXOBJ is passed to a function it is converted to double(),
or perhaps INDEXOBJ would have a method that would be called to do
the conversion. the only exception to this rule would be if
MATLAB was invoking a method on isa(INDEXOBJ) object. in this
case, it wouldnt do the conversion.
hence, you would only overload the functions that are absolutely
necessary, like subsref() and subsasgn(). these functions would
assume that the inputs are "1" based.
the reason why i would let the object do the conversion is that
some people may want to use floats, for example.
#6
by the way Cleve, if you feel that any of these posts have value,
you could send us a check for consulting!
Janez Makovsek
> 80% of our talent doesnt program in C.
>
> it was sad that it was nearly impossible to distribute our code
> since the runtime environment makes the application expensive.
> and, mcc just couldnt compile this many m-files to a reasonable
> application size--> maybe it could do it if we spent more time
> laying out the program's architecture.
There are two ways to the solution:
Move C++ closer to Matlab. Try to move Matlab closer to C++. I know that
many people think that those who are fond of C++ dont know anything about
Matlab (and that's why they are using C++).
The truth is, with a really good object oriented numerical library for C++,
you would forget all about Matlab and wonder how come you have started to
use it. Why that library has not yet been written is a riddle. All the
syntax, all the language constructs, all the code, .. can also be done C++.
(and it has been done (by Mathworks)). For example, why does Matlab's C++
interface has to interface their Linpack? It shouldnt take more then one man
and three months, to relink the whole thing to LAPACK 3.0 which is free.
You say you had eight people. God knows how long you needed to design that
code and now your commerce is stopped because you cant see over the first
ridge. Why dont you hire just one real programmer?
Maybe numerical C++ library has been designed, but people are just blind.
One of the "advantages " of Matlab is that it just does not give the chance
to write "bad" code. (meaning efficient). Stripping those features insures
that all the m files are always simple and readable (and slow).
As it was well pointed out. People who use Matlab dont think about ever
making a true application. And if they do: they cant sell it because of the
price, and if they do get the price: well.. there is that dorn indexing,
and then there is performance, and.... Matlab's code will never be as fast
plaing programing, simply because it enforces complicated solutions to
otherwise simple problems.
(for example: find command and index selections. Never done this way in
normal life.).
Human resources are much more expensive then any development enviorenment.
And anybody ignoring anything is paying for it out of his own pocket.
Those who dont, just dont care.....
Janez.
Jordan Rosenthal
> #4
>
> > % Y = FFT(y,NFFT,index) instead sets Y.index = index.
>
> do you think that adding additional input parameters to functions
> makes sense? typically, i find that people like defaults--> which
> is why a MATLAB plot can easily fool someone about the domain and
> range of a function. (seeing is believing)
In this case yes. The way I tried to describe it, this form would only be
allowed if y were a SIGNAL object. I agree with you about the
defaults....which is why I mentioned that Y = fft(y,NFFT) would
automatically set Y.index = freqspace(length(y),'whole');
I actually didn't think too much about the SIGNAL object, and put that out
there as a "bonus" of something that might be possible. I was more focused
on the INDEXOBJ (until I started to fall back asleep).
Thanks,
Jordan
Jordan Rosenthal
I realized I made a small error in the examples for the INDEXOBJ. I used
the function name signal instead of the name indexobj. The example should
be fixed to read:
% Ex.
> % n = -99:99;
> % x = cos(2*pi/10*n);
> % y = indexobj(x, n);
> % plot(y.index, y, 'b-', 0, y(0), 'ro'); hold on;
> % % Plots the signal and highlight the first term
> % plot(y.index(y<0), y(y<0), 'y');
> % % Plots values for y less than zero in yellow
> %
> % Y = indexobj(fft(y,256), 0:255);
> % plot(Y.index, abs(Y), '-', 0, abs(Y(0)), 'ro');
> % % Plots the magnitude response and highlights DC term
Jordan