{"id":5941,"date":"2025-02-19T03:05:11","date_gmt":"2025-02-19T11:05:11","guid":{"rendered":"https:\/\/wonghoi.humgar.com\/blog\/?p=5941"},"modified":"2025-04-30T11:47:54","modified_gmt":"2025-04-30T19:47:54","slug":"dictionary-of-equivalent-analogous-concepts-in-programming-languages","status":"publish","type":"post","link":"https:\/\/wonghoi.humgar.com\/blog\/2025\/02\/19\/dictionary-of-equivalent-analogous-concepts-in-programming-languages\/","title":{"rendered":"Dictionary of equivalent\/analogous concepts in programming languages"},"content":{"rendered":"\n

<\/p>\n\n\n\n

<\/td>Common<\/td>C<\/td>C++<\/td>MATLAB<\/td>Python<\/td><\/tr>
<\/td>Variable arguments<\/td><stdarg.h><\/code>
T f(...)<\/code>
Packed in va_arg<\/code><\/td>		Very BAD!

Cannot overload
when signatures are uncertain.<\/td>		varargin<\/code>
varargout<\/code>

Both packed as cells.

MATLAB does not have named arguments<\/a><\/td>		*args<\/code> (simple, stored as tuples)

**kwargs<\/code> (specify input by keyword, stored as a dictionary)<\/td><\/tr>
<\/td>Referencing<\/td>
N\/A<\/td>		operator[]<\/code><\/td>(_)<\/code> is for references
subsindex
subsassgn<\/code>

[_]<\/code> is for concat
{_}<\/code> is for (un)pack<\/td>		__getitem__()
__setitem__()<\/code><\/td><\/tr>
<\/td>Default
values<\/td>		N\/A<\/td>Supported<\/td>Not supported.
Manage with inputParser()<\/code> or
newer arguments<\/code><\/td>		Non-intuitive static data behavior. Stick to None<\/code> or immutables.<\/td><\/tr>
<\/td>Name-Value
Argument
Matching<\/td>		<\/td><\/td>Old way:
.., 'PropName', Value<\/code>
and parse varargin<\/code>

Since R2021a:
Name=Value<\/code>
options<\/code> in arguments<\/code><\/td>		Name=Value<\/code>
**kwargs<\/code><\/td><\/tr>
<\/td>Major
Dimension<\/td>		Row<\/td>Row<\/td>Column<\/td>Row (Native\/Numpy)
Column for Pandas<\/td><\/tr>
<\/td>Constness<\/td>const<\/code><\/td>const<\/code><\/td>Only in classes<\/td>N\/A (Consenting adults)<\/td><\/tr>
<\/td>Variable
Aliasing<\/td>		Pointers<\/td>References<\/td>NO! Rely on Copy-on-write
(No in-place functions*)

Handle classes under limited circumstances<\/td>		References<\/td><\/tr>
<\/td>=<\/code> assignment<\/td>Copy one
element<\/td>		Values: Copy
References: Bind<\/td>		New Copy
Copy-on-write<\/td>		NO VALUES
Bind references only
(could be to unnamed objects)<\/td><\/tr>
<\/td>Chained
access operators<\/td>		N\/A<\/td>Difficult to operator overload it right<\/td>Difficult to get it right. MATLAB had some chaining bugs with dataset()<\/code> as well.<\/td>Chains correctly natively<\/td><\/tr>
<\/td>Assignment
expressions
(assignment evaluates to assigned lvalue)<\/td>		=<\/code><\/td>=<\/code><\/td>N\/A<\/td>Named Expression<\/a> :=<\/code> <\/td><\/tr>
<\/td>Version Management<\/td><\/td><\/td>verLessThan()<\/code>
isMATLABReleaseOlderThan<\/code><\/a><\/td>		virtenv<\/code> (Virtual Environment)<\/td><\/tr>
<\/td>Exponentiation<\/td><math.h><\/code>
pow()<\/code><\/td>		<cmath><\/code>
pow()<\/code><\/td>		^<\/code><\/td>**<\/code><\/td><\/tr>
<\/td>Stream
(Conveyor belt mechanism. Saves memory)<\/td>		I\/O (std, file, sockets)
<\/td>		iterator<\/code> in
STL containers<\/td>		MATLAB doesn’t do references. Just increment indices.<\/td>iterators (uni-directional only)
iter(): __iter__()<\/code>
next(): __next__()<\/code><\/td><\/tr>
<\/td>Looping<\/td>for(init, cont_cond, next)<\/td>C-style

for(auto running: iterable)<\/td>		for k = array to iterate
<\/td>		list-comp

for (index, thing) in enumerate(lists)<\/td><\/tr>
<\/td><\/td><\/td><\/td><\/td><\/td><\/tr><\/tbody><\/table>
Since MATLAB doesn’t do references, iterators (by extension generators) and functions that do in-place operations do not make sense (unless you bend it very hard with anti-patterns such as handles and dbstack).<\/figcaption><\/figure>\n\n\n\n

<\/p>\n\n\n\n

Data Types<\/h2>\n\n\n\n
Common<\/td>C<\/td>C++<\/td>MATLAB<\/td>Python<\/td><\/tr>
Sets<\/td>N\/A<\/td>std::set<\/code><\/td>Only set operations, not set data type<\/td>{ , , ...}<\/code><\/td><\/tr>
Dictionaries<\/td><\/td>std::unordered_map<\/code><\/td>– Dynamic fieldnames
(qualified varnames as keys)
– containers.Map()<\/code> or dictionary<\/a>()<\/code> since R2022b<\/td>		Dictionaries
{key:value}<\/code>
(Native)<\/td><\/tr>
Heterogeneous containers<\/td><\/td><\/td>cells {}<\/code><\/td>lists (mutable)
tuples (immutable)<\/td><\/tr>
Structured
Heterogeneous containers<\/td>		<\/td><\/td>table()<\/code>
dataset()<\/code> [Old]

Mix in classes<\/td>		Pandas Dataframe<\/td><\/tr>
Array,
Matrices &
Tensors<\/td>		<\/td><\/td>Native [ , ; , ]<\/code><\/td>Numpy\/PyTorch<\/td><\/tr>
Records<\/td>struct<\/td>class
(members)<\/td>		dynamic field (structs)
properties (class)

getfield()\/setfield()<\/code><\/td>		No structs
(use dicts)

attribute (class)
getattr()\/setattr()<\/code><\/td><\/tr>
Type deduction<\/td>N\/A<\/td>auto<\/code><\/td>Native<\/td>Native<\/td><\/tr>
Type extraction<\/td>N\/A<\/td>decltype()<\/code> for compile time (static)

typeid()<\/code> for RTTI (runtime)<\/td>		class()<\/code><\/td>type()<\/code><\/td><\/tr>
Categorical Arrays<\/td><\/td>categorical()<\/code>
Previously
ordinal()\/nominal()<\/code> <\/td>		pd.cut(x, bins, labels)<\/code><\/td><\/td><\/tr><\/tbody><\/table>
Native sets operations in Python are not stable and there’s no option to use stable algorithm like MATLAB does. Consider installing orderly-set<\/code> package.<\/figcaption><\/figure>\n\n\n\n

Array Operations<\/h2>\n\n\n\n
<\/td>Common<\/td>MATLAB<\/td>Python<\/td><\/tr>
<\/td>Repeat<\/td>repmat()<\/code><\/td>[] * N<\/code>
np.repeat()<\/code><\/td><\/tr>
<\/td>Logical Indexing<\/td>Native<\/td>List comprehension
Boolean Indexing (Numpy)<\/td><\/tr>
<\/td>Equally spaced numbers<\/td>Internally colon()<\/code>:
start:step:end<\/code>

linspace<\/code>\/logspace<\/code><\/td>		range(begin, past_end, step)<\/code>
produces an iterator

list(range())<\/code> or tuple(range())<\/code>
iterates to realize the vector<\/td><\/tr>
<\/td>Equally spaced indexing<\/td>MATLAB has no generators,
so produced vector only<\/td>		[start:past_end:step]<\/code> is internally
slice()<\/code> which produces a slice<\/strong><\/em> object, not range\/lists\/tuple. Faster but not iterable<\/strong><\/td><\/tr>
<\/td>Shallow copy<\/td>Deep copy-on-write<\/td>Slice: x = y[:]<\/code>
copy.copy()<\/code><\/td><\/tr>
<\/td>Deep copy<\/td>Deep copy-on-write<\/td>copy.deepcopy()<\/code><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Editor Syntax<\/h2>\n\n\n\n
<\/td>Common<\/td><\/td>C<\/td>C++<\/td>MATLAB<\/td>Python<\/td><\/tr>
<\/td>Commenting<\/td><\/td>\/* ... *\/<\/code>

\/\/<\/code> (only for newer C)<\/td>		\/\/<\/code> (single line)

\/* ... *\/<\/code> (block)<\/td>		%<\/code> (single line)

(Block):
%{
...
%}<\/code> <\/td>		#<\/code> (single line)

\"\"\"<\/code> or '''<\/code>
is docstring which might be undersirably picked up<\/td><\/tr>
<\/td>Reliable multi-line
commenting
(IDE)<\/td>		<\/td><\/td><\/td>Ctrl+(Shift)+R<\/code>(Windows), \/<\/code> (Mac or Linux)<\/td>[Spyder]:
Ctrl+1<\/code>(toggle), 4<\/code>(comment), 5<\/code>(uncomment)<\/td><\/tr>
<\/td>Code cell
(IDE)<\/td>		<\/td><\/td><\/td>%%<\/code><\/td>[Spyder]:
# %%<\/code><\/td><\/tr>
<\/td>Line
Continuation<\/td>		<\/td>\\<\/code><\/td>\\<\/code><\/td>...<\/code><\/td>\\<\/code><\/td><\/tr>
<\/td>Console
Precision<\/td>		<\/td><\/td><\/td>format<\/code><\/td>%precision<\/a><\/code> (IPython)<\/td><\/tr>
<\/td>Clear variables<\/td><\/td><\/td><\/td>clear<\/code> \/ clearvars<\/code><\/td>%reset -sf<\/code> (IPython)<\/td><\/tr><\/tbody><\/table>
Macros only make sense in C\/C++. This makes code less transparent and is frowned upon in higher level programming languages. Even its use in C++ should be limited. Use inline functions whenever possible.

Python is messy about the workspace, so if you just delete <\/figcaption><\/figure>\n\n\n\n

Object Oriented Programming Constructs<\/h2>\n\n\n\n
<\/td>Common<\/td><\/td>C++<\/td>MATLAB<\/td>Python<\/td><\/tr>
<\/td>Getters
Setters<\/td>		<\/td>No native syntax.

Name mangle (prefix or suffix) yourself to manage<\/td>		Define methods:
get.x<\/em><\/code>
set.x<\/em><\/code><\/td>		Getter:
@property
def x(self): ...<\/code>

Setter:
@x.setter
def x(self, value): ...<\/code><\/td><\/tr>
<\/td>Deleters<\/td><\/td>Members can’t be
changed on the fly<\/td>		Members can’t be
changed on the fly<\/td>		Deleter (removing attributes
dynamically by del<\/code>)<\/td><\/tr>
<\/td>Overloading
(Dispatch function by signature)<\/td>		<\/td>Overloading<\/td>Overload only by
first argument<\/td>		@overload<\/code> (Static type)
@singledispath
@multipledispatch<\/code><\/td><\/tr>
<\/td>Initializing class variables<\/td><\/td>Initializer Lists
Constructor<\/td>		Constructor<\/td>Constructor<\/td><\/tr>
<\/td>Constructor<\/td><\/td>ClassName()<\/code>
Does not return
(*this<\/code> is implicit)<\/td>		obj=ClassName(...)<\/code>
MUST output the constructed object<\/td>		__init__(self, ...)<\/code>
Object to be constructed is 1st argument<\/td><\/tr>
<\/td>Destructor<\/td><\/td>~ClassName()<\/code><\/td>delete()<\/code><\/td>__del__()<\/code><\/td><\/tr>
<\/td>Special
methods<\/td>		<\/td>Special member functions<\/td>(no name)
method that control specific behaviors<\/a><\/td>		Magic\/Dunder methods<\/td><\/tr>
<\/td>Operator overloading<\/td><\/td>operator<\/code><\/td>operator methods to define<\/a><\/td>Dunder methods<\/a><\/td><\/tr>
<\/td>Resource
Self-cleanup<\/td>		<\/td>RIAA<\/td>onCleanup()<\/code>: make a dummy object with cleanup operation as destructor to be removed when it goes out of scope<\/td>with<\/code> Context Managers<\/td><\/tr>
<\/td>Naming for the object itself<\/td><\/td>Class: (class’s own name by SRO ::<\/code>)
Instance: *this<\/code><\/td>		Class: (class’s own name)
Instance: obj<\/code> (or any output name defined in constructor)<\/td>		Class: cls<\/code>
Instance: self<\/code>
(Recommended PEP8 names)<\/td><\/tr><\/tbody><\/table>
Python allows adding members (attributes) on the fly with setattr()<\/code>, which includes methods. MATLAB’s dynamicprops allows adding properties (data members) on the fly with addprop

onCleanup()<\/code> does not work reliably on Python because MATLAB’s object destructor time is deterministic (MATLAB specifically do not garbage collect user objects to avoid this mess. It only garbage collects PODs) while Python leaves it up to garbage collector.

*this<\/code> is implicitly passed in C++ and not spelled out in the method declaration. The self object must be the first argument in the instance method’s signature\/prototype for both MATLAB and Python. <\/figcaption><\/figure>\n\n\n\n

<\/p>\n\n\n\n

Functional Programming Constructs<\/h2>\n\n\n\n
<\/td>Common<\/td><\/td>C++<\/td>MATLAB<\/td>Python<\/td><\/tr>
<\/td><\/td><\/td><\/td><\/td><\/td><\/tr>
<\/td><\/td><\/td><\/td><\/td><\/td><\/tr>
<\/td>Function as
variable<\/td>		<\/td>Functors
(Function Objects)
operator()<\/code><\/td>		Function Handle<\/td>Callables
(Function Objects)
__call__()<\/code><\/td><\/tr>
<\/td>Lambda
Syntax<\/td>		<\/td>Lambda
[capture](inputs) {expr} -> optional trailing return type<\/code><\/td>		Anonymous Function
@(inputs) expr<\/code><\/td>		Lambda
lambda inputs: expr<\/code><\/td><\/tr>
<\/td>Closure<\/a>
(Early binding): an
instance of function objects<\/td>		<\/td>Capture []<\/code> only as necessary.

Early binding [=]<\/code> is capture all.<\/td>		Early binding ONLY for anonymous functions (lambda).

Late binding for function handles to loose or nested functions<\/a>.<\/td>		Late binding* by default, even for Lambdas.

Can capture Po<\/code> through default values
lambda x,P=Po: x+P<\/code>
(We’re relying users to not enter the captured\/optional input argument)<\/td><\/tr><\/tbody><\/table>
Concepts of Early\/Late Binding also apply to non-lambda functions. It’s about when to access (usually read) the ‘global’ or broader scope (such as during nested functions) variables that gets recruited as a non-input variable that’s local to the function itself.

An instance of a function object is not a closure if there’s any parameter that’s late bound. All lambdas (anonymous functions) in MATLAB are early bound (at creation).

The more proper way (without creating an extra optional argument that’s not supposed to be used<\/a>, aka defaults overridden) to convert late binding to early binding (by capturing variables) is called partial application<\/a>, where you freeze the parameters (to be captured) by making them inputs to an outer layer function and return a function object (could be lambda) that uses these parameters.

The same trick (partial application) applies to bind (capture) variables in simple\/nested function handles in MATLAB which do behave the same way (early binding) like anonymous functions (lambda).

Currying is partial application one parameter at a time, which is tedious way to stay faithful to pure<\/strong> functional programming.<\/figcaption><\/figure>\n\n\n\n

List comprehension is a shorthand syntax for transform\/map() and copy_if\/remove_if\/filter() in one shot, but not accumulate\/reduce(). MATLAB and C\/C++ does not have listcomp, but listcomp is not specific to Python. Even Powershell has it.<\/p>\n\n\n\n

Listcomp syntax, if wrapped in round brackets like (x**x for x in range(5))<\/code>, gives a generator. Wrapping in square bracket is the shortcut of casting the generator into a list, so [x**x for x in range(5)]<\/code> is the same as list(x**x for x in range(5))<\/code>.<\/p>\n\n\n\n

Coroutines \/ Asynchronous Programming<\/h2>\n\n\n\n

MATLAB natively does not support coroutines. <\/p>\n\n\n\n

Common<\/td>C++20<\/td>Python<\/a><\/td><\/tr>
Generators<\/td>Input Iterators<\/td>Functions that yield value_to_spit_out_on_next<\/code>
(Implicitly return a generator\/functor with iter<\/code> and next<\/code>)<\/td><\/tr>
Coroutines<\/td><\/td>Functions that value_accepted_from_outside = yield<\/code>
Send value to the continuation by g.send(user_input)<\/code>

async<\/code>\/await <\/code>(native coroutines)<\/td><\/tr>
<\/td><\/td><\/td><\/tr>
<\/td><\/td><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Matrix Arrays<\/h2>\n\n\n\n

The way Numpy requires users to specify matrices with a bracket for every row drives me nuts. Not only there’s a lot of typing, the superfulous brackets reinforce C’s idea of row-major which is horrendous to people with a proper math background who see matrices as column-major \"\mathbf{A}_{r,c}\". Pytorch is the same.<\/p>\n\n\n\n

Once you are trained in APL\/MATLAB’s matrix world-view, you’ll discover going back to the world where matrices aren’t first class citizens is clumsy AF. <\/p>\n\n\n\n

With Python, you lose the clutter free readability where your MATLAB code is one step away from the matrix equations in your scientific computing work, despite a lot of the features that addresses frequent use patterns are implemented earlier in Python than MATLAB. <\/p>\n\n\n\n

Don’t believe those who haven’t lived and breathed MATLAB tell you Python is strictly superior. No it isn’t. They just didn’t know what they were missing as they haven’t made the intellectual leap in MATLAB yet. Python is very convenient as a swiss-army knife but scientific computing is an afterthought in Python’s language design.<\/p>\n\n\n\n

The only way to use MATLAB-like semi-colon to change rows only works for np.matrix() type, which they plan to deprecate. For now one can cast matrix into array like np.array(np.matrix(matrix_string))<\/code>.<\/p>\n\n\n\n

Even numpy’s ndarray (or matrix to be deprecated) are CONCEPTUALLY equivalent to a matrix of cells in MATLAB. There isn’t native numerical matrices like in MATLAB that doesn’t have the overhead of unpacking arbitrary data types. You don’t want to do numerical matrices in MATLAB with cell matrices as it’s insanely slow. <\/p>\n\n\n\n

You get away without the unpacking penalty in Numpy if all the contents of the ndarray happens to have the same dtype<\/a><\/code> (such as numerical), aka known to be uniform. In other words, MATLAB’s matrices are uniform if it’s formed by []<\/code> and heterogeneous if formed by {}<\/code>, while for Python []<\/code> is context-dependent, kept track of by dtype<\/code>.<\/p>\n\n\n\n

Concept<\/strong><\/td>MATLAB<\/strong><\/td>Numpy<\/strong><\/td><\/tr>
Construction<\/td>[8,9;6,4]<\/code><\/td>np.array([[8,9],[6,4]])<\/code><\/td><\/tr>
Size by dimension<\/td>size()<\/code><\/td>A.shape<\/code><\/td><\/tr>
Concatenate
within existing dimensions<\/td>		[A;B]<\/code> or vertcat()<\/code>
[A,B]<\/code> or horzcat()<\/code>
cat(dim, A, B, ...)<\/code><\/td>		np.vstack()<\/code>
np.hstack()<\/code>
np.concatenate(list, dim)<\/code><\/td><\/tr>
Concatenate expanding
to 3D (expand in last dimension)<\/td>		cat(3, A, B, ...)<\/code><\/td>np.dstack()<\/code>
‘d’ for depth (3rd dimension)<\/td><\/tr>
Concatenate
expanding dimensions<\/td>		cat(newdim, A, B, ...)<\/code>
then permute()<\/code><\/td>		np.stack([A, ..], expand_at_axis)<\/code>
np.array([A, ..])<\/code> expands at first
dimension as outermost bracket
refers to first dimension<\/td><\/tr>
Tiling<\/td>repmat()<\/code><\/td>np.tile()<\/code><\/td><\/tr>
Fill with same value<\/td>repmat()<\/code><\/td>np.full()<\/code><\/td><\/tr>
Fill with ones\/zeros<\/td>ones(), zeros()<\/code><\/td>np.ones(), np.zeros()<\/code><\/td><\/tr>
Fill minicking another
array’s size<\/td>		repmat(x, size(B))
ones(x, size(B))<\/code>
zeros(x, size(B))<\/code><\/td>		np.full_like(B, x)<\/code>
np.ones_like(B)<\/code>
np.zeros_like(B)<\/code><\/td><\/tr>
Preallocate<\/td>Any of the above
(Must be initialized)<\/td>		np.empty()<\/code>
np.empty_like()<\/code>
UNINITIALIZED<\/td><\/tr><\/tbody><\/table>
repelem()<\/code> is just repmat()<\/code> with the repetition by axes vector expanded out as variable input arguments one per dimension. Using ones vector to broadcast a singleton instead of repmat() is horrendously inefficient and non-intuitive. <\/figcaption><\/figure>\n\n\n\n

Heterogeneous Data Structures<\/h2>\n\n\n\n

Heterogeneous Data Structures are typically column major as it is a concept that derives from Structs of Arrays (SoA) and people typically expect columns to have the same data type from spreadsheets.<\/p>\n\n\n\n

While Pandas offers a lot of useful features that I’ve easily implemented with wrappers in MATLAB, the indexing syntax of Pandas\/Python is awkward and confusing. It’s due to the nature that matrix is a first-class citizen in MATLAB while it’s an afterthought in Python.<\/p>\n\n\n\n

Python does not have the { }<\/code> cell pack\/unpack operator in MATLAB, so in Pandas, you select the Series<\/code> object (think of it as a supercharged list<\/code> with conveniences<\/a> such as handling missing values and keeping track of row\/column labels) then call its .values<\/code> attribute.<\/p>\n\n\n\n

However, Pandas is a lot more advanced than MATLAB in terms of using multiple columns as keys and have more tools to exploit multi-key row names (row names not mandatory in MATLAB but mandatory in Pandas). In the old days I had to write my own MATLAB function with unique(.., 'rows')<\/code> exploit its index output to build unique keys under the hood.<\/p>\n\n\n\n

Concept<\/td>MATLAB<\/td>Python (Pandas
Dataframe)<\/td><\/tr>
<\/td><\/td><\/td><\/tr>
Rows<\/td>Observations (dataset()<\/code>)
Row (table()<\/code>)<\/td>		Rows
index<\/td><\/tr>
Columns<\/td>Variables<\/td>Columns<\/td><\/tr>
Select rows\/columns<\/td>T(rows, cols)<\/code><\/td>T.loc[r, col_name]<\/code>
T.iloc[r,c]<\/code>

Caveats:

– single index
(not wrapped in list)
have content extracted

– iloc<\/code> on LHS cannot
expand table but loc<\/code> can, but it can only inject 1 row

– can get index number of names by T.get_loc()<\/code> to use with T.iloc[]<\/code><\/td><\/tr>
Remove rows\/columns<\/td>T(rows, cols) = []<\/code><\/td>T.drop(index=rows, columns=cols)<\/code>
Optionally: inplace=True<\/code>
del T[rows, cols]<\/code> does NOT work<\/td><\/tr>
Extract one column<\/td>T{:, c}<\/code><\/td>T[c].values<\/code><\/td><\/tr>
Extract one entry<\/td>T{r, c}<\/code><\/td>T.at[r,col_name]<\/code>
T.iat[r,c]<\/code>

Faster than loc\/iloc<\/code><\/td><\/tr>
Show first few rows<\/td>T(1:5, :)<\/code><\/td>T.head()<\/code><\/td><\/tr>
Drop duplicate rows<\/td>unique(T, 'stable')<\/code><\/td>T.drop_duplicates()<\/code><\/td><\/tr>
<\/td><\/td><\/td><\/tr>
<\/td><\/td><\/td><\/tr>
Ordinal<\/td>categorical()<\/code>
ordinal()<\/code> <\/td>		Categorical()<\/code>
Index()<\/code><\/td><\/tr>
Getting column names\/labels<\/td>T.Properties.VariableNames<\/code>
(returns cellstr()<\/code> only)<\/td>		T.columns<\/code>
(returns Index()<\/code> or RangeIndex()<\/code>)<\/td><\/tr>
Getting row
names\/labels<\/td>		T.Properties.RowNames<\/code><\/td>T.index<\/code><\/td><\/tr>
Transpose table<\/td>rows2vars()<\/code><\/td>T.transpose()<\/code><\/td><\/tr>
<\/td><\/td><\/td><\/tr>
Move columns
by name<\/td>		movevars()<\/code> since R2023a<\/td><\/td><\/tr>
Rename columns<\/td>renamevars()<\/code> since R2020a<\/td>T.rename(columns<\/strong>={source:target})<\/code><\/td><\/tr>
Rename rows<\/td>Modify
T.Properties.RowNames<\/code><\/td>		T.rename(index<\/strong>={source:target})<\/code><\/td><\/tr>
Use column as row indices<\/td>T.Properties.RowNames<\/code> = T.cellstr_variablename<\/code>
If multiple columns are needed, need to combine them into one column using some user rules<\/td>		T.set_index(column_to_use)<\/code>
Dataframe allows multiple columns as row index keys<\/td><\/tr>
Reorder or partial selection<\/td>T[rows, cols]<\/code><\/td>T.reindex(columns<\/strong>=..., index<\/strong>=...)<\/code>
New labels will autofill by NaN<\/code><\/td><\/tr>
Select columns<\/td>T[:, cols]<\/code><\/td>T[list_of_cols]<\/code><\/td><\/tr>
Pick column by data type<\/td>T[:, varfun(...)]<\/code><\/td>T.select_dtypes(include=[list of type names])<\/code><\/td><\/tr>
Pick column by string match<\/td>T[:, varfun(...)]<\/code><\/td>T.filter(like=str_to_match)<\/code><\/td><\/tr>
Blindly concatenate columns of 2 tables<\/td>[T1, T2]<\/code>

If you defined optional rownames, they must match. You can delete it with T.Properties.RowNames = {}<\/code><\/td>		Pandas assign row indices (labels) by default.

Mismatched row labels do not combine in the same row. Consider reset_index()<\/code> or overwrite the row indices of one table with another, like
pd.concat([T1, T2.set_index(T1.index)]<\/code><\/td><\/tr>
Blindly
concatenate rows of 2 tables<\/td>		[T1; T2]<\/code><\/td>pd.concat([T1, T2], ignore_index=True)<\/code><\/td><\/tr>
<\/td><\/td><\/td><\/tr>
Format export<\/td>writetable()<\/code><\/td>.to_*()<\/code><\/td><\/tr><\/tbody><\/table>
MATLAB tables does not support ranging through column names (such as 'apple':'grapes'<\/code>) yet Pandas DataFrame support it. I don’t think it’s fine to use it in the interpreter to poke around, but this is just asking for confusing logic bugs when the columns are moved around and the programmer has a false sense of security knowing exactly what’s where because they are using only names.

Dataframe is a little smarter than MATLAB’s table() in terms of managing column names and indices as it’s tracked with Index()<\/code> type which is the same idea as MATLAB’s ordinal()<\/code> ordered categorical type, where uniques names are mapped to unique indices and it’s the indices under the hood. This is how 'apple':'grapes'<\/code> can work in Python but not MATLAB.

MATLAB T.Properties.VariableNames<\/code> is a little clumsy. I usually implement a consistent interface called varnames()<\/code> that’d output the same cellstr()<\/code> headings whether it’s struct, dataset or table objects.

MATLAB’s table()<\/code> by default do not make up row names. Pandas make up row names by default sequentially.

MATLAB table()<\/code> do requires qualified string characters as variable names. Dataframe doesn’t care what labels you use as long as Index()<\/code> takes it. It can get confusing because you can have a number 1 and ‘1’ as column headers at the same time and they look the same when displayed in the console.<\/figcaption><\/figure>\n\n\n\n

”<\/p>\n\n\n\n

<\/p>\n

<\/div>

<\/path><\/svg><\/i> \"Loading\"<\/p>

<\/div>","protected":false},"excerpt":{"rendered":"

Common C C++ MATLAB Python Variable arguments <stdarg.h>T f(…) Packed in va_arg Very BAD! Cannot overloadwhen signatures are uncertain. vararginvarargout Both packed as cells. MATLAB does not have named arguments *args (simple, stored as tuples) **kwargs (specify input by keyword, … Continue reading →<\/span><\/a><\/p>\n

<\/div>\n

<\/path><\/svg><\/i> \"Loading\"<\/p>\n

<\/div>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"inline_featured_image":false,"footnotes":""},"categories":[30,25,59,61,10,34],"tags":[],"class_list":["post-5941","post","type-post","status-publish","format-standard","hentry","category-c-programming","category-cpp","category-concepts","category-functional-programming","category-matlab","category-python"],"_links":{"self":[{"href":"https:\/\/wonghoi.humgar.com\/blog\/wp-json\/wp\/v2\/posts\/5941","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/wonghoi.humgar.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/wonghoi.humgar.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/wonghoi.humgar.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/wonghoi.humgar.com\/blog\/wp-json\/wp\/v2\/comments?post=5941"}],"version-history":[{"count":139,"href":"https:\/\/wonghoi.humgar.com\/blog\/wp-json\/wp\/v2\/posts\/5941\/revisions"}],"predecessor-version":[{"id":6534,"href":"https:\/\/wonghoi.humgar.com\/blog\/wp-json\/wp\/v2\/posts\/5941\/revisions\/6534"}],"wp:attachment":[{"href":"https:\/\/wonghoi.humgar.com\/blog\/wp-json\/wp\/v2\/media?parent=5941"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/wonghoi.humgar.com\/blog\/wp-json\/wp\/v2\/categories?post=5941"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/wonghoi.humgar.com\/blog\/wp-json\/wp\/v2\/tags?post=5941"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}