MATLAB Sadness @matlabsadness-blog - Tumblr Blog

Space-sensitive!

(submitted by dave r.)

I would have thought it a general principal of any modern language that mathematics are not space-sensitive: that is, that: 1-1 == 1 -1 == 1 - 1

This is the case in MATLAB, you say? Usually, but not when using the matrix constructor [ ]:

>> a = [1 -1, 0] a = 1 -1 0 >> a = [1-1, 0] a = 0 0

All spaces are treated as delimiters! Nice trap for newcomers…

The length() function returns the longest dimension length

If you ever write functions in MATLAB, you’ve probably learned by not to never rely on the length function. This function is admittedly ill-defined for matrices, but if you happen to use it anyway, you’ll soon be surprised when things start breaking. Say your function that relies on length takes an N×M matrix where, usually, N>M. Here, the length is N, and everything works fine until N<M, at which point length returns M.

Long story short, use size(MAT, 1) and size(MAT, 2), not length.

Importantly, some languages do define the length of an array in a consistent way. For instance, in Python/NumPy, len returns the number of items an iterator would produce. In particular, len(arr) for an array arr returns the length of the left-most index, irrespective of how many indices arr has.

Julia, meanwhile, has a different but still internally-consistent behavior. There, length returns the number of elements in an array (N M in the above example).

That MATLAB does not consistently define length doesn't imply that it can't be done.

#submissions #submission

Author Sadness: Neglecting the Submission Box

Sometimes, it's not MATLAB making me sad, but myself. For instance, I've been ignoring the submissions people have been sending in about their own MATLAB sadnesses, but it's time I start changing that. In the meantime, thanks for sharing!

Few things make me quite as sad as when I have something I need to get done, and I'm presented with this:

$ /usr/local/MATLAB/R2013a/bin/matlab License checkout failed. License Manager Error -15 MATLAB is unable to connect to the license server. Check that the license manager has been started, and that the MATLAB client machine can communicate with the license server. Troubleshoot this issue by visiting: http://www.mathworks.com/support/lme/R2013a/15 Diagnostic Information: Feature: MATLAB License path: /home/cgranade/.matlab/R2013a_licenses:/usr/local/MATLAB/R2013a/licenses/license.dat:/usr/local/MATLAB/R2013a/licenses/network.lic Licensing error: -15,570. System Error: 115

Well, maybe sad isn't the right word for this one.

A Few Words About FFIs

No language or development environment is an island unto itself. Eventually you'll have to call code outside your dev environment, be it a native C driver some vendor provided, antique legacy code that you don't have the time or inclination to rewrite, or even something where you've exported some functions to native for speed. Thus, the foreign function interface (FFI) for a language matters.

In MATLAB, external code can either by writing native code that exports MATLAB functions via MEX (something that has made us sad before), or by the use of the loadlibrary function. The latter is most properly an FFI, as it in principle allows you to load arbitrary dynamic libraries written using C or STDCALL conventions and call their exports as if they were MATLAB functions.

loadlibrary leaves much to be desired, however. To start, loadlibrary is inherently based off of global state: you give the library you're loading a name as a string that is then shared across all MATLAB namespaces, as opposed to simply representing the loaded library as a a data structure within the language. This can couple your code in surprising and undesired ways, such as if you have the misfortune of giving the same name to two different native libraries (this might happen, for instance, if your external library is itself loaded by a MATLAB-language library).

Moving on, though, loadlibrary makes the bizarre restriction that it can only load libraries given a C-language header file describing that library's exports. This is then turned into what MATLAB calls a prototype file, which you can modify by hand if MATLAB fails to parse the header file, but these prototype files are difficult to parse in any human readable manner, as this example shows:

fcns.name{fcnNum}='mxGetNumberOfDimensions'; fcns.calltype{fcnNum}='cdecl'; fcns.LHS{fcnNum}='int32'; fcns.RHS{fcnNum}={'MATLAB array'}; fcns.alias{fcnNum}='mxGetDims'; % Alias defined fcnNum=fcnNum+1; % Increment fcnNum

What MATLAB type is 'MATLAB array' representing? What useful information is being carried by fcnNum? Where are any of these struct fields documented?

Don't get me wrong; when MATLAB can parse a header file correctly, that's a huge win, as it allows for a lot of tedious tasks to be automated. The problem is that this is a very hard thing to do robustly, due to the nature of C/C++ preprocessors, and so you need a way to fail gracefully. Instead, MATLAB dumps you squarely into editing poorly documented and automatically generated functions by hand, if you're lucky. If you're unlucky, you won't even get that far, and will run afoul of MATLAB's automatic thunk generation.

How do other languages handle this? Python provides ctypes, which while tedious, is significantly better documented and allows the programmer to take control. This is essential when interacting with libraries that use strange tricks in their header files that break FFI tools like loadlibrary. Moreover, there's significantly less sharing of global state, as ctypes uses Python objects to keep track of external libraries. The result is that external libraries look and feel like Python:

>>> libc = cdll.msvcrt >>> print libc.time(None) 1150640792

The upshot is that ctypes makes the contract between your code and external code something that is directly under your control, such that it is possible to deal with strange external libraries by directly specifying types, using well-documented Python objects to carry type information:

>>> strchr.restype = c_char_p >>> strchr.argtypes = [c_char_p, c_char]

Here, c_char_p and c_char can be looked up in the ctypes API reference, and you can call help() on them to get information. Types other than the primitive C types can be built up in this way, such as arrays, pointers and structures, all using the richness of the language rather than an (opaque that bears arbitrary restrictions)[http://www.mathworks.com/help/matlab/matlab_external/passing-arguments-to-shared-library-functions.html#f48795], such as no triple-pointers (yes, those sometimes come up).

As an alternative to ctypes, cffi allows for you to parse header files, but again provides more graceful failures and handles more of the task within the host language itself.

Julia and Rust, for their parts, each follow a strategies similar to ctypes, in which you specify the signatures of each external function that you would like to call. These being newer languages, header-file based tools like cffi are not yet available, and some important features are missing, but they get the fundamentals right: you can specify signatures explicitly in an easy-to-read fashion, and the task of handling external calls is done within the language itself, rather than by the use of a stringly-typed interface. This is precisely where MATLAB fails: its more advanced header-based functionality can and often does fail, leaving you with navigating its arcane prototype and thunk interfaces with little documentation to guide you.

Three Kinds of Maps

In most functional programming languages, map is a function which takes two arguments, a function and a list, then returns a new list where the function has been applied to each element. That is, map(f, [a, b, c]) returns the list [f(a), f(b), f(c)]. Many operations performed in the course of programming can be expressed in terms of map, providing a common structure for expressing computational tasks.

The functional programming primitive map is a powerful tool both in purely functional languages and in imperative languages like MATLAB. Since relatively recently, MATLAB has included implementations of map built in to the MATLAB standard library. I say "implementations" because MATLAB actually includes three different functions which implement map, but behave slightly differently: arrayfun, cellfun and structfun.

These different implementations each act on a different data type, so that arrayfun acts on each element of an ordinary array, cellfun on each element of a cell array and structfun on the values stored in each field a of structure array. The options and semantics of these three implementations are not identical (for example, cellfun allows one to use a string to name one of several predefined functions, but the documentation of arrayfun and structfun make no reference to the function being specified as a string), forcing the programmer to remember and be aware of these non-uniformities when selecting a data type.

In many languages, this problem would be solved by having a common idea of an iterator or sequence, but the closest MATLAB has to this idea is the comma-separated list we encountered in our exploration of cell array indexing, as can be seen from how for loops with cell arrays can act like foreach loops in many other languages. Because of the lack of a common notion of what it means to iterate over a sequence, or of what it means to act as a container, MATLAB exposes the programmer to the task of specializing code based on data types and to managing the task of remembering eccentricities of the various standard library routines.

#consistency #api-design

Slicing a Cell Array Doesn't Do What You'd Expect

As discussed earlier, if you want to retrieve an element of an array in MATLAB, you use syntax like arr(idx), while if you want to retrieve an element of a cell array, arr{idx} does the trick. Similarly, if you want to retrieve a range of elements from an ordinary array, you can use a slice, like arr(idx_start:idx_end), which returns another ordinary array. Given that, it's reasonable to expect two things: that indexing by slices preserves types, and that {} are used in place of () when using cell arrays. If you came to that set of expectations, the following exchange with MATLAB will likely be very surprising to you:

>> arr = {'a', 12, [1 10 30]} arr = 'a' [12] [1x3 double] >> class(arr) ans = cell >> class(arr{2:3}) Error using class The CLASS function must be called from a class constructor.

To understand why this is, it's useful to re-examine the the first assumption. Indexing an array or cell array by () preserves type:

>> class(arr(2)) ans = cell >> class(arr(2:3)) ans = cell

Thus, () and {} aren't analogous at all, but do entirely different things. Indeed, {} extracts an element or slice of a cell array into a data structure peculiar to MATLAB: the comma-separated list. The line class(arr{2:3}), then, was equivalent to class(arr{2}, arr{3}). The two-argument form of class takes as its first argument a structure and as its second argument a class name, then unpacks the structure into an instance of the named class. This is obviously invalid for the contents of arr, and so we get a very cryptic error for having used the wrong kind of indexing brackets.

This is again an example of what would otherwise be a useful language feature, implemented in a way that instead makes it arcane and error-prone. Rather than making the intent to unpack arguments into class explicit, MATLAB allows us to introduce a subtle error by treating a single expression as if it was a sequence of expressions with almost no visual indication. As a result, both cell arrays and argument unpacking are made significantly less useful, which makes me sad.

Single Dispatch Methods Can Hide Functions

In common object-oriented parlance, a method is often thought of as a function that's attached to a class and that can make reference to the internal state of the instance of that class with which the method is called. The type of the receiver of a method thus determines which of the different functions gets executed when that method is called, a process known as single-dispatch.

In principle, then, there is no difference between calling a method with syntax like obj.foo() and with syntax like foo(obj); the single-dispatch can be resolved based on the type of obj either way. Because of this, some languages, including both D and MATLAB, allow either syntax to be used.

The difficulty comes in, however, when we note that as a result of the fact that method calls can be written out as ordinary function calls, the methods of a class can hide ordinary functions. As a concrete example (in particular, an example that caused colleagues of mine a considerable amount of grief), the serial class has a method called fprintf, such that the line fprintf(sp, format, val1) for some serial instance sp looks as if it would call fprint treating sp as a file descriptor. This is not the case, but rather, sp.fprintf(format, val1) gets called instead. That said, this is not inherently problematic, so long as the arguments to serial.fprintf mimic those of fprintf such that new functionality is added. It should come as no surprise that serial.fprintf does not do this, but rather behaves in a subtly different way such that hard-to-diagnose errors are introduced.

In particular, fprintf(sp, value) for a serial instance sp is equivalent to serial.fprintf(sp, '%s\n', value), while serial.fprintf(sp, format, value) writes to the serial port the result of sprintf(format, value). Thus, because the one-argument form has an additional newline that the two-argument form does not, the equivalence between fprintf(fd, format, value) and fprintf(fd, sprintf(format, value)) exhibited by the ordinary function fprintf is broken. Removing the sprintf call can therefore break software that depends on the implicit newline, but this programmer error is difficult to spot due to the hiding of fprintf by serial.fprintf. Needless to say, any language that makes it easy to introduce such hard-to-spot errors makes me sad.

(Bonus: serial.fprintf is documented in two places, but the two descriptions contradict each other about which types can be accepted for the second argument.)

#consistency #documentation #readability

Non-Orthogonal Indexing

At the suggestion of David Warde-Farley, I'd like to focus a little bit on how MATLAB makes us sad in how its language fails to be orthogonal. Roughly speaking, orthogonality demands that each language feature be usable independently of each other language feature, such that you do not need to be aware of special cases and context in order to write an expression or statement. As such, orthogonality helps the programmer in quickly understanding code and in making code that works in a predictable way regardless of context. When orthogonality is violated, we are surprised that something we thought we understood no longer works.

Take indexing in MATLAB as an example. If you have an array called arr, then arr(i:j) will return the ith through jth elements of arr (of course, since arr has two indices, it may not be clear what those elements are). These elements can then be fed into a function, call it f, that computes the sample moments of those elements, returning a new array. If you are only intefrested in the first moment, you might do something like f(arr(i:j))(2), since you know that expr(2) will give you the second element of expr. You would be surprised, however:

>> f(arr(i:j))(2) Error: ()-indexing must appear last in an index expression.

This is not an inherent restriction in the MATLAB language, though, as Octave can figure out how this works just fine:

octave:1> m = f(arr(i:j))(2);

If you want to achieve this in MATLAB, you must break the single expression you care about into two pieces, using a secondary variable to maintain state:

>> t = f(arr(i:j)); >> m = t(2);

This is problematic in two ways: first, your intent (to grab the second element of the output of f) is made less clear by splitting across two lines. Second, a new variable is introduced into the namespace, creating a new potential for name conflicts and bugs down the road.

MATLAB's indexing syntax thus fails to be orthogonal such that we cannot simply model the result of f as a value that we are free to act on further, unnecessarily introducing more confusion and special cases into the language.

#orthogonality #restrictions

Two Kinds of Arrays

In MATLAB, arrays defined using [ and ] are always homogeneous in type. Such arrays are then indexed by expressions like arr(1) and arr(end). The homogeneity restriction is useful for writing efficient and type-safe code, but can sometimes be very limiting.

As a less restrictive alternative, MATLAB also has different kind of array, called a cell array. Literal cell arrays are defined using { and }, and are normally indexed by expressions like arr{idx}. Elements in a cell array can be any type, including other cell arrays.

The problem, however, is that as a result of this split between the two kinds of arrays, there are two distinct kinds of syntax that must be remembered for what are actually very similar concepts. Many languages handle the same problem by allowing the type of an array to be a reference or an object, but MATLAB forces the programmer to deal with two different concepts that are almost identical, but that diverge in annoying ways.

#consistency #syntax

Everything Has At Least Two Indices

Arrays in MATLAB cannot have just one index, but rather must have at least two indices. This is especially confusing as literals like [0 1 2 3], which seem to have only one index, have an extent along the second index rather than the first:

>> x = [0 1 2 3] >> size(x, 1) 1 >> size(x, 2) 4

As a consequence, special cases are introduced into the language that serve only to confuse. "Row" and "column" objects simply do not behave in the same way as two-index and higher-rank tensors.

#consistency #assumptions #special-cases

No Functions and Classes at the Terminal

It's often useful to test functionality by quickly defining useless but instructive functions and classes at the terminal, rather than creating a new source file to hold one-off testing code. In MATLAB, however, one is arbitrarily forbidden from doing so:

function y = f(x) ??? function y = f(x) | Error: Function definitions are not permitted in this context.

This restriction makes MATLAB less expressive and less useful by making it more difficult to rapidly prototype code. Moreover, the restriction is completely arbitrary, as is evidenced by the fact that Octave, an open-source reimplementation of the MATLAB language and standard library, has no such restriction:

octave:1> function y = f(x) > y = x^2 > end

#restrictions #arbitrary #prototyping #interpreter

No Nice String Type

Strings are a pain to work with in any language. Even setting aside issues of character sets, representations and i18n, there's a lot of things to watch out for when handling strings. Many object-oriented languages try to make this easier on the programmer by hiding the complexities of string handling behind a built-in string class.

In MATLAB, strings are not a distinct type, but are an array of characters, as in C. While that approach works in a low-level systems programming language like C, it is questionable at best in a high-level language like MATLAB, especially given that MATLAB supports the operator overloading needed to make classes appear like arrays.

As a result of not giving strings their own type, the sadness of having to remember a new set of functions for string manipulation and comparison is introduced; for example, strcmp must be used instead of ==. This in turn increases the number of functions that a MATLAB programmer must remember while providing very little value.

strcmp

In order to determine whether two strings are equivalent in Matlab, you can't overload an operator, you have to evaluate strcmp(string_one, string_two). This is the kind of thing I'd put in my software if I ran into some obscure problem with string manipulation at 3 AM the day of the release, and opted just to get the thing out the door. I'll put up with this kind of thing in a low-level, compiled language, but to see it in commercial software "designed" to make numerics easy? Give me a break.

(Submitted by Ben Criger.)

One Function Per MEX Compilation Unit

The One Function Per M-File rule gets especially frustrating when extended to MEX, MATLAB's system for writing native code that exposes itself to interpreted MATLAB code. MEX wraps one of several C or Fortran compilers and compiles your code to a shared library called a MEX file. Each MEX file then can only expose exactly one name to the MATLAB interpreter.

Want two functions to be exposed? They must be in separate compilation units, and thus may not directly share state. This restriction makes it easier for the MATLAB interpreter to find your symbols by reducing the problem of resolving an unknown function name to that of finding a file with a given extension, but makes it very difficult to write code that shares resources in a sensible way.

On Stack Overflow, it has been suggested that accepting an additional string, then writing several public M-files to pass that string, is a good way of working around this problem. This workaround makes code organization more opaque, however, and causes the programmer to have to define each function to be exposed via MEX multiple times.

#code-reuse #native-code #c-api

One Function Per M-File

Writing functions is a great way of keeping code organized and clean. The style that many languages encourage is to write lots of small functions, each of which has a clearly identifiable purpose and behaviour. MATLAB is not one of those languages.

Instead, each function that is visible to the rest of your code must be in a separate file, called an M-File. While you can declare multiple functions in an M-File, all but one such function is private to that file. This makes it difficult to quickly review groups of related functions and encourages the writing of longer functions. Moreover, it causes even the smallest of projects to be separated into many smaller source files, even when that obscures the organization and layout of the code.

While Python requires similar of modules and Java requires similar of classes, MATLAB is unique in making the one-visible-function-per-file rule.

#code-reuse #organization

Trending Blogs

Recently Viewed Blogs

MATLAB Sadness