Talk:MATLAB/Archive 1

Archive 1

Archive 2

Limitations Section

The following from the article seems unprofessional

"For instance, in MATLAB the DFT (or FFT) is defined with the DC component at index 1 instead of index 0, which is not consistent with the standard definition of the DFT in any literature. On the other hand, users are not supposed to use the array indices to identify spectral component from Matlab FFT outputs anyway, and a frequency labeling array should be constructed starting from 0, therefore such accusation of indexing is unthoughtful. " —Preceding unsigned comment added by 38.115.166.174 (talk) 05:30, 16 November 2009 (UTC)

Criticism (sample rate)

I have some problems with the following fragment:

"The matrix data type is devoid of important attributes required by real world data such as engineering units, sampling rates and time/date markers. These attributes must be managed by the user with custom programming.

The lack of sample rate information is a serious flaw for signal processing applications, where data is typically sampled at a constant interval. To produce properly scaled results, MATLAB programs require or must generate both the amplitude values and the explicit time values. Because twice the volume of data is necessary, computation is further slowed for large matrices."

The complaint in the first paragraph seems to be that the matrix data type is a matrix data type and does not have any other attributes. That is not a valid criticism.

The second paragraph claims that twice as much memory is needed, but I doubt very much that that is true. I'm not sure what applications the writer had in mind, but anything I can think of can easily be done with just the amplitude values and the sample rate. --Jitse Niesen (talk) 14:01, 28 August 2005 (UTC)

I did not write these criticisms, but I easily could have and I think they are quite valid. I believe the first criticism is about the implications of MATLAB using the matrix as the main data type. Other products (like Mathcad) also use a matrix, but it automatically includes properties such as units. Perhaps that data type is an array and the MATLAB matrix is a subset of the more general purpose array type. Properly converting units is a tedious but important step in data analysis, a detail that the computer should perform automatically. MATLAB forces the user to write this code. It is rumored that the Mars lander that crashed due to improper English/Metric unit conversion used software written in MATLAB.

The point about sample intervals is something I have experienced many times. For example, to produce a simple plot of data with a constant sample interval, I have to provide MATLAB with the x data in the PLOT function to get the correct axes values. This can lead to very slow performance when plotting large data files (twice the volume of data is used). Again, with other products, the sample interval is a property of the data and the plotting is much faster and far less error prone. Serious problems also occur when calculating Fourier transforms, data interpolation, decimation, extraction, curve fitting, filtering and just about any operation on data where the sample interval is not unity or multiple data sets have different intervals. I have to "manually" carry all this time data throughout my computations, slowing things down due to data bloat. My colleagues routinely complain about the lack of automatic sample interval support in MATLAB. All of this is due to the matrix data type with no properties. You can attempt to code around it, but then you are dealing with details the language should handle and you find yourself further removed from the problem at hand. I am not disparaging MATLAB (I use it almost everyday), but these are real criticisms when one applies MATLAB to real data. MATLAB was clearly designed to operate on numbers (matrices), not data (arrays). Perhaps applying MATLAB to real data is a misuse of MATLAB.--EdMiller

Sorry for not commenting earlier but the criticisms section was merged from a page from AfD called "MATLAB problems" (I did the merging) - anyway I want to say that you guys did a great job and should be commended :) --Ryan Norton ^{T | @ | C} 07:50, 8 September 2005 (UTC)

EdMiller's comment convinced me that there are some valid criticisms in the section I quoted, though perhaps badly worded, and I rewrote the section in response. The main point, as I see it, and with which I agree, is that "MATLAB was clearly designed to operate on numbers (matrices), not data (arrays)". This should perhaps be emphasized more in the article.

Indeed, for PLOT twice the volume of data is used, but I am not convinced that that's the reason why plotting large data files is so slow. For Fourier transforms, data interpolation &c, you indeed have to program around it, which is a bad thing (it takes time to program around it, and the extra code may contain errors). However, again I doubt that it slows the program down; after all, even if the data type supported a sample rate, the necessary rescalings should be done (only not by the code supplied by the user but by the program itself). --Jitse Niesen (talk) 13:01, 8 September 2005 (UTC)

I personally dislike this criticism, too. Essentially, this criticism says to me "MATLAB is a general purpose program and it's not a more specialized program." There are things like the Signal Processing Toolbox (I've not used it, so I can't say much about it) that may partially address these concerns. This criticism says that MATLAB is not exactly what I need for my specific purpose, but in my opinion, it wasn't designed to be that. I think that the text should be removed. --Wsloand 16:14, 13 November 2005 (UTC)

I am removing it (we'll see how long that lasts). It really does seem absurd to criticize a matrix for not being a multi-part structure. Like... what the hell? I mean, MATLAB allows you to encapsulate matrices in a structure if you'd like. Personally, I would be annoyed if every time I instantiated a matrix, extra space and processing time were automatically wasted on sampling rate nonsense whether I needed it or not.

Sorry for the double update. Essentially, I think that this criticism is a general criticism of most languages (i.e. the same could be said about C, FORTRAN, Perl, python, etc.) so it is not a good criticism for this language. Also, the part about writing your own code being error prone, that implies that the people who write code at Mathworks never get anything wrong (I personally found a bug just last week in part of the figure manipulation routines). --Wsloand 16:29, 13 November 2005 (UTC)

Ditto. - DNewhall

Criticism (procedural)

I also dislike the criticism that starts "MATLAB is a procedural programming language, so it cannot automatically update variables in response to input changes as one might want for simulations or exploratory data analysis" because it is a general criticism for a procedural programming language. This criticism (like the one above) is just that the language operates the way it was designed. --Wsloand 16:29, 13 November 2005 (UTC)

Yeah, the way it was poorly designed. They tried to fix the total lack of OOP by adding java "objects" but this is complete crap, let me tell you. If I sound bitter it's becasue I spend several hours a day programming matlab. Dsol 02:55, 4 December 2005 (UTC)

I agree, the criticism is warranted. The lack of having variables that automatically update a dependency chain is a serious omission for a technical computing data analysis language. Mathcad, Mathematica and even Excel include this basic feature. DADiSP has a procedural language component called SPL (Series Processing Language) that includes what they call "hot variables," variables that automatically update like spreadsheet cells. The starting thread here is similar to saying criticizing the fact that Model T Fords only came in one color is inappropriate since they were designed to only come in black. EdMiller

While it might be valid criticism that part should be removed or seriously reworded since as Ed Miller just showed you can have a procedural language with automatically updating variables. Also, it's possible that someone could make the argument that being a strict procedural language is one of its strengths since you could retrain your Fortran programmers quicker and cheaper then switching to Mathematica or something. I think it should say that Matlab lacks automatically updating variables which is a feature of many other numerical processing products that some researchers/workers have come to rely on. I spend most of my work day programming acoustic data analysis programs and have never found this to be a problem so I wonder how prevalent this criticism is. - DNewhall

From my point of view, a criticism section is entirely warranted. As an engineering student forced to learn how to use Matlab (which I find entirely useless), I can very much appreciate criticism of any kind concerning the program :)

Is a "Criticism" section appropriate?

I'm a new Wiki* contributor but have used it for a while. Also, my name is Dave and I'm a Matlab-olic (hi Dave!). It struck me as odd that an article about a piece of software has a criticism section. For comparison, there's no such section in the Microsoft Word or Octave articles. I could easily add a criticism section to Octave ("It sucks compared to Matlab") but this is totally inappropriate, in my opinion. People's opinions about matlab syntax or features doesn't seem to be basic information about what Matlab is.

Having said this, I personally think some of the critiques are valid. "Vendor lock-in" has become an especially poignant issue in my life after leaving grad school. But the point is, should there be a section discussing these things here?

Is the controversy over Matlab an important part of what Matlab is? Some wikipedia topics, like nuclear energy, discuss the controversy around that issue. I would say this is legit since I, and most intelligent I speak to, consider there to be real controversy in the public about nuclear energy. As empirical evidence I point to the fact that the page has been flagged NPOV for most of this year :) I remember seeing a wiki topic "X controversy" about some topic X before, but can't find an example now.

Either way, in my judgement there are no controversies about Matlab that are "inherent" to Matlab, any more than there are always disagreements within any software user community about what product is best. Besides, why have a criticism section without an 'advantages' section, which would have to acknowledge Matlab's overwhelming market dominance.

One last thought - among physicists the commercial products used for numerics most commonly used are Matlab and IDL (I don't use the latter). If people are mentioning competitors like DaDiSP, perhaps IDL should be listed.

Thoughts? --Dstrozzi 00:38, 5 December 2005 (UTC)

A "Criticism" section on just about any Wiki topic seems fairly standard. Java, C, IDL, they all have them. The criticisms about MATLAB are inherent to MATLAB in that MATLAB, like any product, entails certain design decisions that result in systemic problems - problems that lead to criticisms by the MATLAB community. Also, market dominance often has much more to do with marketing ability and promotion than technical superiority. -- EdMiller

A Criticism based on vendor-lockin is dogmatic, and not appropriate. It is plainly obvious that using a specific product ties you to the environment and infrastructure supporting that product, be it Matlab, MS Windows, or a Toyota Corolla. I buy a specific kind of pen, therefore I buy specific kinds of replacement ink cartridges. As for other criticism, it seems a place for people to vent. I'm not sure that everyone has worked out their own solutions to roadblocks they encounter. —The preceding unsigned comment was added by 71.132.140.250 (talk • contribs) 18:29, 14 October 2006 (UTC)

I think you are missing the point about vendor lock-in. Unlike C/C++, FORTRAN, ADA, Pascal and many other programming languages, the MATLAB language is completely proprietary and controlled by a single company. There is no independent, public organization to supervise language definition or features – i.e. no ANSI MATLAB - nor is there likely to be one in the future. The design, features and compatibility of the language are at the utter whim of the Mathworks. Unlike standardized languages such as C/C++ where a large number of vendors offer competing implementations, MATLAB is only available from the Mathworks, resulting in vendor lock-in. As mentioned, this is certainly not the case with other programming languages. -- EdMiller

I fully agree that this vendor lock-in criticism doesn't make sense. The MATLAB language itself isn't proprietary, only the implementation and the trademark are. It's easy to develop code that is compatible with both MATLAB and Octave, or both MATLAB and Sysquake, and it's feasible to develop other implementations. If one considers lock-in with respect to proprietary implementations, then an equivalent criticism should be made for free software, which has "free lock-in". But the mention of the kind of license is sufficient. Engelec 23:07, 22 October 2006 (UTC)

Really - is there an ANSI standard MATLAB? If I develop code using the MathWorks implementation, which features are part of the standard language and which are vendor specific? Is it the case that the open source GNU Octave version is considered the language standard and the MathWorks version is simply a commercial, proprietary derivative? Also, if my source relies on vendor specific features of the MathWorks proprietary derivative, would I not be subject to vendor lock-in? EdMiller 18:38, 13 November 2006 (UTC)

No, there is no such standard. It's proprietary. Octave tries to be nearly compatible. That's about all there is to it. Vendor lock-in is in fact a real issue for many matlab users like me, since Octave is not fully compatible. Dicklyon 18:45, 13 November 2006 (UTC)

What seems to be the closest thing to a standard is the Numerical Mathematics Consortium (NMC), which seems to target Matlab 4. It's therefore way behind Matlab 7.3 and even Octave and Sysquake. Its members include INRIA (Scilab), Maplesoft (Matlab symbolic toolbox) and National Instruments (LabView), so it will be intersting to see if it can have an effect on the current situation. None of these companies has a direct contender with Matlab 7.3, btw. Engelec 22:33, 13 November 2006 (UTC)

doesn't make sense

I found the following in the criticism section:

"MATLAB was originally implemented in FORTRAN and later re-written in C. The language shows this mixed heritage with a sometimes erratic syntax: neither C nor FORTRAN, but a combination of both."

This doesn't make any sense. The language used to implement MATLAB has nothing to do with the syntax of MATLAB itself.

There is a relationship... because what people used to write it in is also likely to influence they way they design the syntax of the language as well. Because the designers were "C thinkers" and/or "FORTRAN thinkers", that is they way they viewed and thought about code. Now this influence is not always apparent or even existing in the new language which is created, but this is what the writer of that section is trying to imply. And in the case of MATLAB, this is a quite reasonable conclusion to reach. Mathmo ^Talk 20:53, 11 September 2007 (UTC)

While I agree to some extent with the expression "erratic syntax", I don't see how it would come from a "mixed heritage" from Fortran and C. And since it's highly subjective, personal research, etc., it doesn't belong to WP. Engelec 09:47, 12 September 2007 (UTC)

One thing that's being overlooked in this discussion, indeed much of the criticism section, is Wikipedia's policy of "no original research". These issues aren't supposed to be debated here. A statement only belongs on the page if can be backed up by a reputable source. --User:Matthewsim 15:25, 13 September 2007 (UTC)

Criticism (references)

MATLAB doesn't support references, which makes it very difficult to implement data structures which contain indirections, such as open hash tables, linked lists, trees, and various other common computer science data structures.

In actual fact there is MATLAB Pointers Library which implements pointers/references in MATLAB. It is used in Data Structures and Algorithms toolbox. --Zolotykh 10:54, 9 August 2006 (UTC)

In addition, the judicious (albeit inconvenient) use of 'assignin' allows one to implement these data structures mentioned (as we have been doing for several semesters at Georgia Tech's introductory computing course). Additionally, Matlab 7 supports OOP within Matlab. --Viggyjiggy 21:30, 06 November 2006 (UTC)

Actually, OOP was added in Matlab 5, 9 or 10 years ago. Engelec 22:27, 6 November 2006 (UTC)

Now (version 7.6) MATLAB supports references (natively) See [1] --Zolotykh —Preceding unsigned comment added by 85.143.0.30 (talk) 15:19, 4 April 2008 (UTC)

Multiprocessor support

According to http://www.cs.cornell.edu/Info/People/lnt/multimatlab.html, a major weakness of MATLAB is that it does not support multiple processors. Is this still true?

Ssc1997 00:25, 25 October 2006 (UTC)

There is a distributed computing engine. I never used it, but I assume that would do the job. The standard version does not support multiple processors, as far as I know. -- Jitse Niesen (talk) 01:08, 25 October 2006 (UTC)

Dubious criticisms

Some of the criticisms are not valid. The one about data sampling has been commented on several times above. Some of the others seem to be written by computer scientists and C programmers who have fixed ideas about how computer programs should work. For example, the idea that arrays should start from 0 - the whole point of matlab is that you hardly ever need to use array indices (and if you do it slow things down a lot). You just write for example x=[0:100]*pi/100;y=sin(x);plot(x,y); Ironically, if you really want zero subscripts you can easily do this with a function that adds 1, making use of another of the 'criticisms'! There are other possible criticisms - one thing that bugs me is that i and j both default to root(-1). Paul Matthews 17:12, 31 October 2006 (UTC)

I agree. Imaginary numbers should be written with i or j suffix (e.g. 2j instead of 2*j) to avoid possible bugs. Engelec 20:41, 31 October 2006 (UTC)

For example, the idea that arrays should start from 0 - the whole point of matlab is that you hardly ever need to use array indices (and if you do it slow things down a lot). -- that is a statement of ignorance. if you did signal processing for a living you would know that DSPers often need the index of minimum or maximum of something, whether it is lag in autocorrelation or the (normalized) frequency of some spectrum. at one time, the most pervasive MATLAB toolbox was the Signal Processing toolbox (i also believe that was the very first toolbox) and one of the authors, Tom Krause, told TMW that they needed to fix this indexing thing so that after applying the FFT, the DC component could go into bin 0 where it belongs. they (Cleve) ignored him and this ugly index offset of 1 continues to exist to this day. the formula that MATLAB implements for the DFT is not the same as in the textbooks because of this array indexing shortcoming. there is a backward compatible way to fix this, but it has to be done at the executable level by TMW (users cannot do it) and they have consistently declined to do it. in the 1990's, this came up multiple times on the newsgroup comp.dsp with cross-posting to comp.soft-sys.matlab with some exchange with Cleve, and although they did not (and could not) refute the basis of the criticism, continued to deny the reality of the problem. it's a legitimate critique of the package. r b-j 21:55, 31 October 2006 (UTC)

well you've made my point, you have fixed ideas about things that are just conventions. I'm with Cleve. In most applications you just work with the whole array and you dont need indices. The first entry in the DFT is the mean component and whether you label that 1 or 0 is arbitrary. You can subtract 1 if you really want to! And if we are to have such a long section of criticisms we should allow some rebuttals of those criticisms. Paul Matthews 14:23, 2 November 2006 (UTC)

dunno how you came to such conclusion. there are good conventions (that are compact and natural) and bad conventions. nonetheless, the criticism is not that MATLAB won't change its convention (that would break all of this existing code), but that it insists on only this one convention which is flawed for a very large consituency of users.

"You can subtract 1 if you really want to!"

no, i am forced to subtract 1 from a returned index or to add 1 when i convert frequency to index. it is something that DSP engineers do all of the time with the FFT. consider this code segment:

     N = 65536;
     f0 = 285/N;                        % f0 is frequency of sine wave in cycles per sample.
     t = linspace(0, N-1, N)';          % t is measured in units of samples.
     x = sin(2*pi*f0*t) .* hanning(N);  % generate smooth windowed sinusoid
     X = fft(x);
     [maxValue indexOfMaxValue] = max( abs( X(1:N/2) ) );  % don't look at the "negative frequencies"
     indexOfMaxValue

assuming you're familiar with the DFT, from the textbook definition of the DFT, what should the index (indexOfMaxValue) of the peak value of the spectrum be? and what comes out, if i don't modify it. in a complicated program it's easy to overlook this because, from the textbook definition (and MATLAB has purported to allow one to type equations virtually identical to how they are written mathematically) the index that is of the peak would be the equal to the number of cycles the sinusoid makes in the FFT array. DSP engineers are dealing with the indices of spectra all the time, and we have to remember to always subtract 1 when converting index to frequency and always add one when converting frequency to index. for a "high-level" language that purports to allow one to model physical and mathematical systems simply and efficiently, this is nearly intolerable. it is a variance from the definition of the DFT in the literature that is hard-coded into the system. a high-level language like MATLAB is supposed to serve us the users, to accomodate us, not the other way around. r b-j 04:30, 3 November 2006 (UTC)

One shouldn't add one, one should consider (Matlab) indices as values in a domain distinct from times or frequencies. In your example, one can define a frequency vector similar to t and pick the frequency from it:

     f = 0:N-1;
     freqOfMaxValue = f(indexOfMaxValue);

This allows to have arbitrary sampling frequencies, which 0-based indexing wouldn't permit.

that's an additional level of junk you're saying that people have to write when they are dealing with a mathematical object that has uniformly spaced and discrete indices (so they are naturally integers) to begin with.

Yes, but explicit junk is sometimes easier to handle than implicit junk. Engelec 23:26, 6 November 2006 (UTC)

Mixed indexing would be a nightmare to propagate.

why? mixed array sizes aren't a problem. if you try to do something that doesn't make sense between two arrays (or "matices", whatever semantic you give it) of different sizes or shapes, MATLAB presently spits out an error. you can actively change the upper array limits with reshape(). why not a rebase() that allows for changing the default base of some dimension of the array from 1 to a specified integer? even a negative integer (for modeling symmetrical and non-causal impulse responses, rather than always having to add and subtract half of the length). r b-j 22:47, 6 November 2006 (UTC)

I can answer to that, but I'm not sure I'll convince you. I guess that the result of X=fft(rebase(x,n)) would be 0-based for any x and n. Then what's the base of ifft(X)? 0 or 1, I presume. Can you add it to rebase(x,n)? If yes, then the sum must have the same base of one of the terms; which one? Addition wouldn't be commutative anymore; nasty. Otherwise, a lot of existing code will break when you feed it with n-based arrays.

Expressions like vec(find(...)) would fail when vec isn't 1-based, because find is a simple function which can't guess the base it's supposed to assume. Of course, find is not required here, but it's very common. The list of such problems is endless. Engelec 23:26, 6 November 2006 (UTC)

find() would have to be modified to check the properties of the MATLAB variable it's working on to return the correct indices. that's not a problem. fft() could not be used as such because its definition has already been corrupted with the offset of 1. a different function (i might call it dft()) would need to be there for MATLAB users that use the conventional indexing and that could even be extended so that the DFT and iDFT would be:

$X_{k}=\sum _{n=n_{0}}^{n_{0}+N-1}x_{n}e^{-{\frac {2\pi i}{N}}kn}$

$x_{n}={\frac {1}{N}}\sum _{k=k_{0}}^{k_{0}+N-1}X_{k}e^{{\frac {2\pi i}{N}}kn}$.

where k₀ and n₀ are any finite integer. being a periodic sequence, the DFT should be robust enough to work on any input with non-"regular" index range and still have meaningful results. we went through all this in the thread. the comp.dspers pretty much agreed that this is the "right way" and the c.s-s.m people kept saying it would not be backward compatible (but not really proving it). r b-j 00:12, 7 November 2006 (UTC)

Isn't it what you've just admitted by writing that fft had "already been corrupted"? :-) Engelec 00:38, 7 November 2006 (UTC)

i didn't say, with this extension or generalization of indexing in MATLAB, that people would choose to use the definition of the DFT that was not compatible with the textbooks. a counterpart with compatible definition would have to be defined and leave the old "one-based" definition for purposes of backward compatibility. r b-j 01:05, 7 November 2006 (UTC)

A lot of code assumes 1-based indexing implicitly. It would probably be possible to introduce mixed indexing without breaking any existing code, but afterwards, there would be a lot of bugs coming from mixing incompatible functions (i.e. calling functions assumed to be aware of arbitrary indexing which are not, or errors in converting existing code). Matlab has already the bad habit to try to be smarter than the user and fail (see my own criticisms); I can understand the decision of Cleve. Engelec 08:49, 3 November 2006 (UTC)

Dubious is right! Don't people have better things to do than pick on a computer language? I use Matlab a LOT for the last 15+ years, and there's one thing I'm glad of: consistent indexing conventions. Sometimes the fact that it starts at 1 instead of 0 is a nuisance; just like in c, where sometimes the fact that it starts at 0 instead of 1 is a nuisance. But in both, it's good that it's consistent. Live with it. Dicklyon 06:10, 3 November 2006 (UTC)

Dick, this is what different MATLAB manuals and docs say about the language:

MATLAB is a high-performance language for technical computing. It integrates computation, visualization, and programming in an easy-to-use environment where problems and solutions are expressed in familiar mathematical notation. (Getting Started with MATLAB, v. 5)

from an earlier manual: MATLAB integrates numerical analysis, matrix computation, signal processing, and graphics in an easy-to-use environment where problems and solutions are expressed just as they are written mathematically.

for a product that purports to do that and then REdefine the DFT to be

$X_{k}=\sum _{n=1}^{N}x_{n}e^{-{\frac {2\pi i}{N}}(k-1)(n-1)}\quad \quad k=1,\dots ,N$

$x_{n}={\frac {1}{N}}\sum _{k=1}^{N}X_{k}e^{{\frac {2\pi i}{N}}(k-1)(n-1)}\quad \quad n=1,\dots ,N$.

is just dumb. as soon as they found themselves forced to redefine the DFT, is when red flags should have gone up. and they actually did. the co-author of the original Signal Processing Toolbox, told them they needed to change it. the other co-author (can't remember her name) and Cleve were never open to what the problem is.

(Disclosure: I'm a MathWorks employee.) The historical reason that MATLAB has one-based indexing is that it was designed by a specialist in linear algebra who thought of the base data type as a mathematical matrix, not a computer science array. Typically mathematicians index into an array with (1,1) in the upper left corner. I think it's appropriate to have a sentence or two stating that this convention is different than most other programming languages, and that some mathematical ideas are better expressed with other indexing. I don't think this is the place to debate the pros and cons of this convention, as it isn't MATLAB specific. There is already good discussion on this subject on the linked-to page, Array#Indices_into_arrays. The criticism section tends to grow out of control, as everyone (including me) has some specific thing they find annoying about MATLAB. Thanks for those of you who have helped keep this section under control. I try not to stay mostly out of it, as I'm not a disinterested party! Matthew Simoneau 15:11, 3 November 2006 (UTC)

OK, thanks for all that discussion. Unfortunately there is still a problem with the page. The dubious criticism remains and whenever I add a rebuttal or mitigation it gets deleted immediately by an editor who wont accept any view but his own, contradicting the NPOV policy. The page should at least reflect that it is debatable. I am not a Mathworks employee, I use Matlab FFT all the time, and the 1 indexing is no problem. Paul Matthews 18:33, 6 November 2006 (UTC)

The indexing convention seems better described as a "drawback" than a "criticism". Baccyak4H 18:38, 6 November 2006 (UTC)

just for your information guys, this has been hashed through a bit on comp.soft-sys.matlab with cross-posting to comp.dsp. the links that i can find in Google Groups are

[2]

[3]

in the latter thread, Cleve said:

I agree that it would be possible to add zero-based indexing to MATLAB, using either new notation or an object that overloaded all of our existing indexing notation. It could be backwards compatible in the sense that old code that didn't know about or use the new stuff would still work.

he didn't like it, but did eventually admit that it was, according to the definition of the term, backward compatible. of course, to really make this useful anything that returned indices (like min(), max(), find(), etc.) would have to be modified to return the correct indices for these arrays that don't start with index 1. but they utterly failed to prove why those could not be done in time, once the MATLAB variables (objects in C++) where generalized to subtract something other than 1 from the indices to get the address of the element in the array. why not subtract "n" which is initially set to 1 when the MATLAB variable is first created and can only be changed with a rebase() or similarly named call that would change that property just like the present reshape() changes the upper limits of the indices? r b-j 23:06, 6 November 2006 (UTC)

(replying to Baccyak4H) I don't think it's correct to describe it as a "drawback". Usually, it is precisely what you want. I'd describe it as a "design choice". Anyway, I had a go at rewriting the paragraph.

Another problem with the "criticism" section is that it seems not to be supported by any reference (WP:NOR is the applicable acronym). -- Jitse Niesen (talk) 00:16, 7 November 2006 (UTC)

well, in an earlier version there was some reference: Edsger W. Dijkstra Why numbering should start at zero or the hand-written original and i referenced the DFT definition. also, even though i do not dispute your edit, Jitse ("This matches the definition of a matrix in mathematics"), it should be said that the convention to start numbering sequence at 1 is just an accident of history. there is no natural motivation or mandate to do so and i think that Dijkstra (as well as simple unsigned binary numbers) show why. but, i am not advocating that WP depart from the convention, only that this criticism is legit. r b-j 05:50, 7 November 2006 (UTC)

So do I. I'm not as sure as r b-j about the compatibility issues and I think Mathworks people have weighted the consequences of both the status quo and a change (have they learnt to be very careful with new decisions, I'm sometimes doubtful), but I totally agree it's a nuisance for DSP. If one were going to design a language from scratch, index bases should be seriously considered. Engelec 15:15, 7 November 2006 (UTC)

even so, the real flaw is that it is hard-wired. there would be nothing wrong with the default base of indices for every dimension in the array to be 1, but to insist that this base must always be 1 and make no reasonable provision for setting it to something else (and meaningfully deal with that in the basic operations, as i have spelled out in the USENET posts) can only be a flaw (and an unnecessary flaw). there is no other word for it. "drawback" isn't a bad word for it. insisting that the DC value of the DFT output be placed in bin #1 cannot honestly be identified as a "feature". how did he put it in The Bonfire of the Vanities (film)?: "when your dog craps on the rug, you clean it up. you don't serve it to the guests and call it 'caviar.'" r b-j 02:52, 8 November 2006 (UTC)

Can only be a flaw? Seems like a reasonable POV. But when I search for comments in books, they seem to be more neutral on it. Like this one. Dicklyon 03:14, 8 November 2006 (UTC)

It seems that this discussion is the result of two distinct understandings of the word "index". It may be useful to first agree on what an index is, as used in the context of MATLAB. One suggestion of the definition of "index": [4]. That is to say, in common english, index is the word for something that tell us where some data are located, and is not the same as the data themselves. For example, we do not confuse the page number of a book with the information that any particular page contains.
Yet it seems there is a confusion that results in people trying to link MATLAB function (input/output) data with the index of where each datum is located. Or, as has already been very beautifully explained: "one should consider (MATLAB) indices as values in a domain distinct from times or frequencies". The starting index used (zero, one, or any other) will make no difference to a well written program, as long as this usage is consistent, as an index should ONLY be used in order to reference/find/define/etc any datum, as per the definition of index. The "criticism" that MATLAB has matrix indexing starting with one is as relevant as critiquing a book for starting with page one. In both cases, the page/index allows one to retrieve the correct information, if one uses the given index to go to the page/location where the information is contained. An index system is arbitrary, but must be consistently used.
If one wishes to find information on Zachary Taylor in a book on presidents of the U.S.A., one does not simply look on the twelth page: one uses the page number (index) to locate the point in the book where this information is written. Likewise it is poor form to assume that the value located at position twelve in a vector is twelve as well.
Scripting using MATLAB usually starts with the user defining a matrix of values over the domain required ($X$), and then running a script(function) on those domain values to give output values ($Y$), as shown here: $X=[x(a),x(b),...x(n)],Y=f(X)=[y(a),y(b),...,y(n)]$. Note that the function $f$ operates on the domain values ($X$) and NOT their indices ($N=[a,b,..n]$). hence the domain values ($X$) may be any numerical values: integer or decimal, sequential or nonsequential, evenly-spaced or quite random (amongst many possibilities) and may start and end with any value. It is clear that someone wishing to work with an FFT analysis would quite simply define a domain vector to be sequential integers starting with zero: ($X=[0,1,..m]$), although the function fft.m does not require this explicitly as an input. This method allows for functions to be used "as seen" (able to be copied "unchanged" from the source text) and simultaneously encourages the user to utilize MATLAB good practice (particularly vectorization [5] and array preallocation [6]).
This "criticism" of MATLAB is not the correct forum for discussing poor programming practices (as used in other programming languages) exacerbated by a misunderstanding of what an index is. Perhaps it would be of more use to the "average" Wikipedia reader, if instead there was a small description of what an index is, and how to use it to best effect? This would seem to provide to those readers wishing to understand MATLAB, how to work with matrix data. Obviously this explanation applies to more than just MATLAB, yet it seems there is a need for a slightly more thorough explanation on this front.
Disclosure: daily MATLAB user.

Why criticisms?

Why do we even have the criticisms sections? Is this a place for our pov & "original research" about what we don't like about matlab? Or are there criticisms out there that are verifiable and should be reported here? Or what? Seems more like the former. Can we delete it? Maybe start over with a language properties section with more neutral comments, and/or a criticism section to document criticisms that are verifiably out there?

By the way, the bit about no way to modify an object without replacing it is not quite true. It's easy enough to add a field, assign to a field, etc. What's really being discussed is that you can't modify something in a function by passing a refernce, and it's no different between objects and arrays; the language is consistently call-by value. But it also has some pretty clever machinery so that you don't always suffer a copy penalty where you would naively think you might. That kind of optimization of call by value would not be possible if you could also pass references.

Dicklyon 06:29, 7 November 2006 (UTC)

I'll answer for the third paragraph which I've written. There are facts which are documented in Mathworks manuals, there are facts which can be verified with Matlab and which aren't documented in Mathworks manuals (and that's a criticism), and there are generalizations which are justified but could be qualified as "original research", though I wouldn't dare to pretend they're original. I can sort that if you want. But if the whole section is to be deleted, I prefer to work on something else. Engelec 08:36, 7 November 2006 (UTC)

Does the manual say "becomes a nuisance"? (am I looking at the paragraph you're referring to?) Or was that an opinion? I think it would be better to edit the section to be just verifiable facts, rather than remove it. If you find such things published in the form of a criticism, then it's appropriate to this section. Otherwise, a different section title would be more appropriate for contrastive language details. Dicklyon 16:40, 7 November 2006 (UTC)

I guess the manual doesn't say that. It isn't an opinion, it's a fact. But if you feel you must enforce WP policy this far, please go ahead. At least I'll have learnt something new about Wikipedia. Engelec 23:59, 7 November 2006 (UTC)

I can see why you might see the "nuisance" thing as fact. But is it a verifiable fact? Is there a credible source to whom we can attribute the notion that it is a nuisance? If not, I don't see how we can take it to be other than either opinion or "original research". I do feel that wikipedia policy is worth following here; I'm hoping it doesn't fall to just me to "enforce" it. Dicklyon 00:18, 8 November 2006 (UTC)

it's not an ad for the Math Works, Dick. if the critique is accurate and salient, there is no reason for it not to be there. disputing either the accuracy or significance of the criticism is something that is expected. r b-j 14:47, 7 November 2006 (UTC)

As Jossi keeps telling me, the wikipedia criterion is verifiability, not truth. Anything that can be sourced is verifiable, but most of things I tagged as "citation needed" can not, I suspect, because they are just opinions about how a particular property of matlab is "annoying" or "nuisance" or "serious shortcoming".

I took out the part that I thought was inaccurate. As to significance, that's a matter of opinion that I don't want to get in to. But let's stick to verifiable criticisms and neutral properties.

If the section is to be called "criticisms" it should be for documenting criticisms that have been published about matlab. The neutral language properties should be in another section about contrasting properites with other languages or something like that, and your opinions of how serious or nuisance those differences are should not really be a part of it.

Dicklyon 16:20, 7 November 2006 (UTC)

Quick look at GBS finds some pubished criticisms, but not much like what we have here. [7] [8] [9] [10] [11] [12] Dicklyon 16:35, 7 November 2006 (UTC)

It depends whether you prefer criticisms which are obsolete (1994 for double matrices as the only type or even 2004 for the comment on Matlab-to-C compiler) or laughable (Matlab should also be symbolic, but is already too complicated) but published, or based on experience which anybody can check and reproduce. But since you said you didn't care about truth... Engelec 23:59, 7 November 2006 (UTC)

You've got me all wrong. The reason Jossi keeps telling me that is that I do care about truth. I particularly care that we do not include untrue things as if they are true, just because someone said it. But I also agree with the policy that things we include should be verifiable. I'm not suggesting we include obsolete criticisms, just pointing out that there are some published criticisms we could draw on, instead of making up our own, which is not the wikipedia way. Dicklyon 00:15, 8 November 2006 (UTC)

The policy is quite clear that criticisms can only be presented if they are sourced. You cannot base them on experience, since everyone has different experiences (see, e.g., Paul's comment above that he doesn't consider one-based arrays as a problem). Of course that doesn't mean we should include ridiculous criticisms. If we can't find any decent published criticisms, then we shouldn't mention any. -- Jitse Niesen (talk) 00:43, 8 November 2006 (UTC)

the universally accepted definition of the DFT is:

$X[k]=\sum _{n=0}^{N-1}x[n]e^{-{\frac {2\pi i}{N}}kn}\quad \quad 0\leq k<N$

$x[n]={\frac {1}{N}}\sum _{k=0}^{N-1}X[k]e^{{\frac {2\pi i}{N}}kn}\quad \quad 0\leq n<N$

yet there is no direct reference for this in the DFT article. shall we insist that they refer to any one of hundreds of textbooks that define it that way (with the possible variance of where the scaling factor 1⁄N goes)? it is defined in MATLAB as

$X[k]=\sum _{n=1}^{N}x[n]e^{-{\frac {2\pi i}{N}}(k-1)(n-1)}\quad \quad 0<k\leq N$

$x[n]={\frac {1}{N}}\sum _{k=1}^{N}X[k]e^{{\frac {2\pi i}{N}}(k-1)(n-1)}\quad \quad 0<n\leq N$.

shall i refer to the MATLAB page where that definition is? then shall i quote the MATLAB manuals that, in the introduction to the language, say:

MATLAB is a high-performance language for technical computing. It integrates computation, visualization, and programming in an easy-to-use environment where problems and solutions are expressed in familiar mathematical notation.

MATLAB integrates numerical analysis, matrix computation, signal processing, and graphics in an easy-to-use environment where problems and solutions are expressed just as they are written mathematically. ??

the fact is MATLAB, in this very specific case, objectively fails to perform as promised. it does not express the "problems and solutions ... in familiar mathematical notation" or "just as they are written mathematically". the problem is systemic, not just the misdefinition of the DFT. it's a flaw that forces them (and the MATLAB programmer) to misdefine the DFT, discrete convolution of sequences, and other formulae that is both naturally expressed and defined in the literature as having zero and/or negative indices. and an unnecessary flaw. to deny that this is a bona fide flaw, from the very definition of the term, is akin to saying McDonalds serves really high quality food. in both cases, McDonalds and TMW are satisfied with the quality of the product they market when they should not be. r b-j 03:26, 8 November 2006 (UTC)

I'm not interested in discussing whether it's a flaw or not. The only thing to be discussed here is whether it should be mentioned on Wikipedia that it is a flaw. You are collecting and combining information from different sources to arrive at a critism of Matlab. WP:NOR#Synthesis of published material serving to advance a position says specifically that that is not allowed here. -- Jitse Niesen (talk) 03:39, 8 November 2006 (UTC)

Changed criticisms to limitations and downsides

It's a partial fix. We might still want a criticisms section if someone finds some verifiable criticisms to support. What I've changed it to is a more neutral statement of some limitations, toned down to remove hyperbole like "very" and "must" and "especially" and value judgements like "nuisance". The inclusion of facts about matlab in this section is still somewhat based on opinion of which language features are "limitations" or "downsides", but I think it's much less opinion-based than before.

I'm sure it can be improved, so go for it. Dicklyon 04:18, 8 November 2006 (UTC)

Good work, this is definitely an improvement. As you say it is quite subjective. For example I find it annoying that I cant define a function within a .m script, but I certainly wouldnt regard this as a problem that deserves a mention in an encyclopedia. Paul Matthews 14:40, 9 November 2006 (UTC)

First time I've read this article and the Limitations section strikes me as a bit biased (clearly written by a C programmer). Who else would say that using parentheses to index arrays and enclose function parameters was erratic syntax, when FORTRAN, Pascal, Ada, Modula all use this same syntax. My inclination would be to delete that whole paragraph about erratic syntax. On the other hand some of the later paras might have more substance. Sangwine 21:01, 15 December 2006 (UTC)

What about the claim "MATLAB is a proprietary product of The MathWorks, so users are subject to vendor lock-in."? Isn't GNU Octave supposed to be source compatible? // Liftarn

there's a lot of MATLAB calls (especially toolbox calls) that Octave does not yet support. r b-j 15:57, 31 January 2007 (UTC)

Inappropriate Material

The content below is unsourced, so it doesn't belong in the article. Wikipedia isn't a review site. Nor is Wikipedia a place to publish original thought. This smacks of a PR job done by MATLAB competitors. The material can be re-added only if it can be attributed to a reliable source. Jehochman (^Talk/_Contrib) 13:09, 11 April 2007 (UTC)

MATLAB is a proprietary product of The MathWorks, so users are subject to vendor lock-in. Some other source languages, however, are partially compatible and provide a migration path.

The language shows a mixed heritage with a sometimes erratic syntax. For example, MATLAB uses parentheses, e.g. y = f(x), for both indexing into an array and calling a function. Although this ambiguous syntax can facilitate a switch between a procedure and a lookup table, both of which correspond to mathematical functions, a careful reading of the code may be required to establish the intent.

Many functions have a different behavior with matrix and vector arguments. Since vectors are matrices of one row or one column, this can give unexpected results. For instance, function sum(A) where A is a matrix gives a row vector containing the sum of each column of A, and sum(v) where v is a column or row vector gives the sum of its elements; hence the programmer must be careful if the matrix argument of sum can degenerate into a single-row array. While sum and many similar functions accept an optional argument to specify a direction, others, like plot, do not, and require additional checks. There are other cases where MATLAB's interpretation of code may not be consistently what the user intended (e.g. how spaces are handled inside brackets as separators where it makes sense but not where it doesn't, or backslash escape sequences which are interpreted by some functions like fprintf but not directly by the language parser because it wouldn't be convenient for Windows directories). What might be considered as a convenience for commands typed interactively where the user can check that MATLAB does what the user wants may be less supportive of the need to construct reusable code.

Though other datatypes are available, the default is a matrix of doubles. This array type does not include a way to attach attributes such as engineering units or sampling rates. Although time and date markers were added in R14SP3 with the time series object, sample rate is still lacking. Such attributes can be managed by the user via structures or other methods.

Array indexing is one-based which is the common convention for matrices in mathematics, but does not accommodate the indexing convention of sequences that have zero or negative indices. For instance, the DFT (or FFT) is defined with the DC component at index 1 instead of index 0, which is not consistent with the standard definition of the DFT. This one-based indexing convention is hard coded into MATLAB, making it impossible for a user to define their own zero-based or negative indexed arrays to concisely model an idea having non-positive indices.

MATLAB doesn't support references, which makes it difficult to implement data structures that contain indirections, such as open hash tables, linked lists, trees, and various other common computer science data structures. In addition, since the language is consistently call-by-value, it means that functions that modify array or object values must return these through output parameters and the caller must assign those modified values for the change to be persistent.

The rest of the article is equally unsourced and unencyclopedic. Before we throw it all out, though, let's tag it and see if some can come up with appropriate references. We already worked on this section a while back, changing it from opinions of disadvantages to more objective limitations. Should be easy to source each item, or remove if not. Dicklyon 14:22, 11 April 2007 (UTC)

How about a citation to the instruction manual? Most of this is fact: the last paragraph is, for example, as is the second from last, as is the third from last. The first two are trickier, and the third does confuse fact with interpretation thereof. Splash - tk 00:23, 14 April 2007 (UTC)

Please do go ahead and add what refs you can. Then it will be clear what else needs to be worked on. Dicklyon 01:02, 14 April 2007 (UTC)

i wrote the paragraph regarding Array indexing. other than the MATLAB manual, what source should i be using? it's clear and obvious to anyone using MATLAB that the arrays indices start at 1 and it is hard-wired. it's not something you can change in Preferences nor something you can change with a MATLAB call. it's equally clear and obvious to anyone using the DFT (of which the FFT is simply a "fast" implementation of) that the indices naturally start at 0. but in MATLAB it's 1. so they are not "source-compatible". this section used to be called Criticisms and someone renamed it Limitations because they thought it was somehow more NPOV. i am completely opposed to taking this out. then the article because an ad for TMW. identifying accurate criticisms of MATLAB (as well as strengths) is a perfectly appropriate thing for a neutral encyclopedia, and i also disagree that there should be no "review" of MATLAB here. Wikipedia is here for information. useful and neutral information. if we can help someone make an informed and optimal buying decision about MATLAB before having to commit, then Wikipedia served a useful purpose. that decision might well be to buy it. BTW, i use MATLAB a lot, despite my reservations. Octave still doesn't have all of the functionality of MATLAB and i find MATLAB to be, warts and all, still both useful and necessary. r b-j 08:31, 14 April 2007 (UTC)

Absolutely agree that "identifying accurate criticisms of MATLAB (as well as strengths) is a perfectly appropriate thing." We just need to distiguish between identifying (with sources) versus making up our own criticisms. Dicklyon 16:07, 14 April 2007 (UTC)

The trouble with "Limitations", sourced or unsourced, is that anything that doesn't work the way one person expects is a limitation. Doesn't handle nuclear physics? It's a limitation. Doesn't handle terabyte datasets? It's a limitation. Doesn't have vi keystroke support? It's a imitation. Even a source doesn't really help because that's just one person's opinion. DJ Clayworth (talk) 17:57, 15 April 2008 (UTC)

Also, there is a general problem with criticism sections of this type: They are difficult to source to Wikipedia standards and so end up being sourced to things like Usenet. --Pleasantville (talk) 18:05, 15 April 2008 (UTC)

Removed a "limitation" of Matlab that is far more appropriately called a limitation of matrix algebra, namely, that the "sum" function has some weird behavior when the matrix is only one-dimensional (a vector). IMHO, anyone confused by this function is really confused by linear algebra. I would be very confused if Matlab didn't process the way it does. Rewrote the rest of the paragraph so it didn't depend on the removed content. Garykempen (talk) 17:21, 19 September 2009 (UTC)

Limitations

The discussion on M-code compatibility under the Limitations section appears to confuse .m code with .mat data files. The differences in versions given in the example refer to saved data structures; these files in my experience do not contain functions or otherwise executable code. There are, of course, differences in compatibility for Matlab functions. Versions of Matlab, for example, use different default algorithms for random number generation. Thus it is possible that M-code based on different implementations could result in incompatible code across versions of Matlab. I am uncomfortable editing this section because I have no experience with the Matlab complier (.mex files) - would there be limitations involving these? 128.135.84.45 (talk) 16:07, 29 October 2008 (UTC)

The limitations section has several apparently subjective statements presented as fact: "Productivity of a development team working on a large software project in MATLAB will likely be several times slower and result in a higher defect rate than development in a language and IDE with type checking, code completion, reference search, refactoring tools, and unit testing support." This statement is presented without citation and represents an opinion. -smj —Preceding unsigned comment added by 71.42.142.65 (talk) 01:00, 10 March 2010 (UTC)