{"id":6339,"date":"2025-04-21T16:31:27","date_gmt":"2025-04-22T00:31:27","guid":{"rendered":"https:\/\/wonghoi.humgar.com\/blog\/?p=6339"},"modified":"2025-11-30T22:46:53","modified_gmt":"2025-12-01T06:46:53","slug":"matlab-features-conveniences-not-available-in-python-c","status":"publish","type":"post","link":"https:\/\/wonghoi.humgar.com\/blog\/2025\/04\/21\/matlab-features-conveniences-not-available-in-python-c\/","title":{"rendered":"MATLAB features\/conveniences not available in Python\/C++"},"content":{"rendered":"\n

A lot of MATLAB’s conveniences over Python and vice versa stem from their design choices of what are first class citizens and what are afterthoughts. <\/p>\n\n\n\n

MATLAB has its roots from scientific computing, so operations (use cases) that are natural to scientists come first. Python is a great general purpose language but ultimately the motivation came from a computer science point of view. It will eventually get clumsy when Python tries to do everything MATLAB does.<\/p>\n\n\n\n

Matrix (a stronger form of array) takes the center stage in MATLAB<\/h2>\n\n\n\n

In MATLAB, matrix is a first-class citizen. Unlike other languages that starts with singleton and containers are built to extend it to arrays (then to matrices), nearly everything is assumed to be a matrix in MATLAB so a singleton simply seen as a 1×1 matrix. <\/p>\n\n\n\n

\"\"<\/a><\/figure>\n\n\n\n

This is a huge reason why I love MATLAB over Python based on the language design. <\/p>\n\n\n\n

Lists in Pythons are cell containers in MATLAB, so a list of numbers in Python is not the same as an array of doubles in MATLAB because the contents of [1, 2, 3.14] must the same type in MATLAB. <\/p>\n\n\n\n

Non-uniform arrays like cells\/lists are much slower because algorithms cannot take advantage of uniform data structure packed very locally (the underlying contents right next to each other) and do not need extra logic to make sure different types are handled correctly.<\/p>\n\n\n\n

np.array()<\/code> is an after thought so the syntax specifying a matrix is clumsy! The syntax is built on lists of lists (composition like arr[r][c] in C\/C++). There used to be a way to use MATLAB’s syntax of separating rows of a matrix with a semicolon ‘;’ with np.matrix('')<\/code> through a string (which clearly is not native and code transparent). <\/p>\n\n\n\n

Given that np.matrix<\/code> is deprecated, this option is out of window. One might think np.array<\/code> would take similar syntax, but heck no! If you typed a string of MATLAB style matrix syntax, np.array<\/code> will treat it as if you entered an arbitrary (Unicode) string, which is a scalar (0<\/code> dimension).<\/p>\n\n\n\n

For my own use, I extracted the routine numpy.matrix<\/code> used to parse MATLAB style 2D matrix definition strings as a free function. But the effort wasted to get over these drivels are the hidden costs of using Python over MATLAB.<\/p>\n\n\n\n

import ast\n\n''' \nmat2list() below is _convert_from_string() copied right off\nhttps:\/\/github.com\/numpy\/numpy\/blob\/main\/numpy\/matrixlib\/defmatrix.py\nbecause Numpy decided to phase out np.matrix yet choose not to\ntransplant this important convenience feature to ndarray\n'''\n\ndef mat2list(data):\n    for char in '[]':\n        data = data.replace(char, '')\n\n    rows = data.split(';')\n    newdata = []\n    for count, row in enumerate(rows):\n        trow = row.split(',')\n        newrow = []\n        for col in trow:\n            temp = col.split()\n            newrow.extend(map(ast.literal_eval, temp))\n        if count == 0:\n            Ncols = len(newrow)\n        elif len(newrow) != Ncols:\n            raise ValueError(\"Rows not the same size.\")\n        newdata.append(newrow)\n    return newdata<\/pre>\n\n\n\n
Numpy array is really cornering users to keep track of the dimensions by providing at least 2 pairs of brackets for matrices! No brackets = singleton, 1 pair of brackets [...]<\/code> = array (1D), 2 pairs\/levels of brackets [ [row1], [row2], ... [rowN] ]<\/code> = matrix (2D). Python earns an expletive from me each time when I type in a matrix!<\/p>\n\n\n\n
Slices are not first class citizens in Python<\/h2>\n\n\n\n
Slices in Python are roughly equivalent to colon<\/code> operator in MATLAB. <\/p>\n\n\n\n
However, in MATLAB, the colon<\/code> operator is native down to the core so you can create a row matrix of equally spaced numbers without surrounding context. end<\/code> keyword, as a shortcut to get the length (which happen to be the last index due to 1-based indexing) of the dimension when indexing, obviously do not make sense (and therefore invalid) for colon in free form.<\/p>\n\n\n\n
Python on the other hand, uses slice object for indexing. Slice object can be instantiated anywhere (free form) but buidling it from the colon syntax is exclusively handled inside the square brakcet []<\/code> acess operator known as the __getitem__<\/code> dunder method. Slice <\/code>objects are simpler than range <\/code>as it’s not iterable so it’s not useful to generate a list of numbers like colon<\/code> operator in MATLAB. In other words, Python reserved the colon syntax yet does not have the convenience of generating equally spaced numbers like MATLAB does. Yuck!<\/p>\n\n\n\n
Since everything is a matrix (2<\/code> dimensions or more) in MATLAB, there’s no such thing as 0<\/code> dimension (scalar) and 1<\/code> dimension (array\/vector) as in Numpy\/Python.<\/p>\n\n\n\n
Transposes in Python makes no sense for 1D-arrays so it’s a nop. A 1D-array is promoted into a row vector when interacting with 2D arrays \/ matrices), while slices makes no sense with singletons.<\/p>\n\n\n\n
Because of this, you don’t get to just say 3:6<\/code> in Python and get [3,4,5]<\/code> (which in MATLAB it’s really {3,4,5}<\/code> because lists in Python are heterogeneous containers like cells. The 3:5<\/code> in MATLAB gives out a genuine matrix like those used in numpy). <\/p>\n\n\n\n
You will have to cast range(3,6)<\/code>, which is an iterator, into a list, aka list(range(3,6))<\/code> if the function you call with it does not recognize iterators but instead want a generated list stored in memory. <\/p>\n\n\n\n
This is one of the big conveniences (compact syntax) that are lost with Python.<\/p>\n\n\n\n
More Operator Overloading<\/h2>\n\n\n\n
Transposes in Numpy is an example where CS people don’t get exposed to scientific computing enough to know which use case is more common:<\/p>\n\n\n\n
MATLAB<\/td>Numpy<\/td>Meaning<\/td><\/tr>
a.'<\/code><\/td>a.transpose()<\/code> or a.T<\/code><\/td>transpose of a<\/code><\/td><\/tr>
a'<\/code><\/td>a.conj().transpose()<\/code> or a.conj().T<\/code><\/td>conjugate transpose (Hermitian) of a<\/code><\/td><\/tr><\/tbody><\/table>
https:\/\/numpy.org\/devdocs\/user\/numpy-for-matlab-users.html<\/a><\/figcaption><\/figure>\n\n\n\n
Complex numbers are often not CS people’s strong suit. Whenever we do a ‘transpose’ with a physical meaning or context attached to it, we almost always mean Hermitian (conjugate transpose)! Most often the matrix is real anyway so many of us got lazy and call simply call it it transpose (a special case), so it’s easy to overlook this if one design\/implement do not have a lot of firsthand experience with complex matrices in your math.<\/p>\n\n\n\n
MATLAB is not cheap on symbols and overloaded an operator for transposes, with the shorter version being the most frequent use case (Hermitian). In Python you are stuck with calling methods instead of typing these commonly used operators in scientific computing like they are equations.<\/p>\n\n\n\n
At least Python can do better by implementing a a.hermitian()<\/code> and a.H<\/code> method. But judging that the foresight isn’t there, the community that developed it are likely not the kind of people sophisticated enough in complex numbers to call conjugate transposes Hermitians.<\/p>\n\n\n\n
Conventions that are more natural to scientific computing than programming<\/h2>\n\n\n\n
Slices notation in Python put the step<\/code> size as the last (3rd) parameter, which makes perfect sense from the eyes of a programmer because it’s messy to have the second parameter mean step or end point depending on whether there’s one colon or two. By placing the step parameter consistently as the 3rd argument, the optional case is easier to program.<\/p>\n\n\n\n
To people who think in math, it’s more intuitive when you specify a slice\/range in the order you draw the dots on a numbered line: you start with a starting point, then you’ll need the step-size to move onto the next point, then you’ll need to know when to stop. This is why it’s start:step:stop<\/code> in MATLAB.<\/p>\n\n\n\n
Python’s slice start:stop_exclusive:step<\/code> convention reads like “let’s draw a line with a starting point and end points, then we figure out what points to put in between”. It’s usually mildly unpleasant to people who parse what they read on the fly (not buffering until the whole sentence is complete) because a 180 degree turn (meaning reversed) can appear at the end of a sentence (which happens a lot with Japanese or Reverse-Polish-Notation).<\/p>\n\n\n\n
Be careful that the end points in Python’s slice and C++’s STL .end()<\/code> are exclusive (open), which means the exact endpoint is not included. 0<\/code>-based index systems (Python an C++) love to specify “one-past-last” instead of the included end points because it happens to align with the total count N<\/code>: there are N<\/code> points from [0, N-1]<\/code> (note N-1<\/code> is in<\/strong>clusive, or a closed<\/strong> end) which is equivalent to [0, N)<\/code>, where N<\/code> is an open end, for integers. This half-open (or open-end) convention avoids painfully typing -1<\/code> all over the place in most use cases in a 0<\/code>-based indexing system.<\/p>\n\n\n\n
0-based indexing is convenient when doing modulo (which is more common with programmers) while 1-based indexing matches our intuition of natural numbers (which starts from 1, bite me. lol) so when we count to 5, there are 5 items total. My oscilloscope don’t call the first channel Channel 0 and I work with floats more than I work with modulo, so 1-based indexing has a slight edge for my use cases.<\/p>\n\n\n\n
MATLAB autoextends when assigning index out of range, not Python<\/h2>\n\n\n\n
This is one behavior I really hated Python for it, with passion. Enough for me to keep MATLAB in parallel with Python instead of ditching MATLAB completely.<\/p>\n\n\n\n
In MATLAB, I simply assign the result x{3} = 4<\/code> even when the list x<\/code> starts with an empty cell x={}<\/code> and MATLAB will be smart enough to autoextend the list. Python will give you a nasty IndexError: list assignment index out of range<\/code>.<\/p>\n\n\n\n
I pretty much have to preallocate my list with [None] * target_list_size<\/code>. MATLAB are pretty tight-assed when it comes to not allowing syntax\/behaviors that allow users to hurt themselves in insidious ways, yet they figured if you expanded a matrix that you didn’t intend to, soon you’ll find out when the dimensions mismatch.<\/p>\n\n\n\n
Note that numpy array has the same behavior (refuses to autoexpand array when assigned an index out of the current range).<\/p>\n\n\n\n
No consistent interface for concatenation in Python<\/h2>\n\n\n\n
In MATLAB, if you have a cell of tables C<\/code>, you can simply vertically concatenate them simply with vertcat(C{:})<\/code>, because MATLAB has a consistent interface for vertical concatenation, which is what the operator [;]<\/code> calls. <\/p>\n\n\n\n
Note that cell unpack {:} in MATLAB translate to comma separated list, putting a square bracket over commas like as [C{:}] is horzcat(C{:})<\/code> because it’s [,]<\/code>. <\/p>\n\n\n\n
Python doesn’t have such consistent interface. Lists are concatenated by +<\/code> operator while Dataframes are concatenated by pd.concat(list_or_tuples_of_dataframes, ...)<\/code>, as +<\/code> in Dataframes means elementwise<\/strong> application of +<\/code> (whatever +<\/code> means to the pair of elements involved). <\/p>\n\n\n\n
I just had a simple use case where I have a list containing dataframes<\/strong> corresponding to tests on each channel (index) that I’ll run the experiments on one by one. They don’t need to be run in order nor all of the tests need to be completed before I collect (vertically stack) the dataframes into one big dataframe!<\/p>\n\n\n\n
Vertically stacking such a list of Dataframes is a nightmare. Pandas haphazardly added a check that throws an error for pandas.concat()<\/code> if everything in the list is None<\/code>, which throws an error “ValueError: All objects passed were None<\/code>“!<\/p>\n\n\n\n
If I haven’t run any tests yet, attempting to collect an aggregrate table from all empty tables should return None instead of throwing a ValuerError<\/code>! Checks for attempting to do a nop<\/code> depending on the source data should be left for users! It’s safer to do less and let users expand on it than nannying and have users painfully undo an unwanted goodwill!<\/p>\n\n\n\n
How empties are handled in each data type like cell<\/code> or table()<\/code> is a important part for a consistent generic interface to make sure different data type work together (cast or overload automatically) seamlessly. TMW support showed me a very detailed thought process<\/a> on what to do when the row is empty (length 0) or column is empty (length 0) in our discussion getting into the implementation details or dataset<\/code>\/table <\/code>(heterogenous data type). I just haven’t seen the thoughtfulness in Python (lists), Numpy (array) or Pandas (dataframe) yet.<\/p>\n\n\n\n
Now that with the poorly thought out extra check in pd.concat()<\/code>, I have to check if the list is all None<\/code>. I often do not jump to listcomp or maps if there’s a more intuitive way as listcomps\/maps are shorthands for writing for-loops instead a expressing specific concept, such as list.count(np.nan)==len(list)<\/code> or set(list)=={'None'}<\/code> for checking if all entries in the list are NaN<\/code> or None<\/code>. Both of them are no-go because:<\/p>\n\n\n\n