What should go in a next-generation MATLAB X?

Let's say MathWorks decides to create a MATLAB X release, which takes a big one-time breaking change that abandons back-compatibility and creates a more modern MATLAB language, ditching the unfortunate stuff that's around for historical reasons. What would you like to see in it?

I'm thinking stuff like syntax and semantics tweaks, changes to function behavior and interfaces in the standard library and Toolboxes, and so on.

(The "X" is for major version 10, like in "OS X". Matlab is still on version 9.x even though we use "R20xxa" release names now.)

What should you post where?

Wishlist threads (#1 #2 #3 #4 #5): bugs and feature requests for Matlab Answers

Frustation threads (#1 #2): frustrations about usage and capabilities of Matlab itself

Missing feature threads (#1 #2): features that you whish Matlab would have had

Next Gen threads (#1): features that would break compatibility with previous versions, but would be nice to have

@anyone posting a new thread when the last one gets too large (about 50 answers seems a reasonable limit per thread), please update this list in all last threads. (if you don't have editing privileges, just post a comment asking someone to do the edit)

[Walter Roberson]

Related question: https://www.mathworks.com/matlabcentral/answers/1680-what-parts-of-matlab-would-you-not-miss?s_tid=srchtitle

[Andrew Janke]

Oh, thanks! Reading through that now.

[Walter Roberson]

Benjamin : you flagged this as Not Appropriate for MATLAB Answers . However, it is a classic discussion that fits in well, similar to existing questions such as https://www.mathworks.com/matlabcentral/answers/1325-what-is-missing-from-matlab from early 2011.

[Voss]

OK

[Andrew Janke]

Personally, I think that the Answers format is particularly well suited to this sort of discussion, because instead of a linear threading model like a regular forum, it allows people to post various suggestions as top-level Answers and to have them be voted on to indicate community interests, and to let each of those suggestions have their own discussion thread hanging off it.

[Rik]

I just added this thread to the list of 'where to post' discussion threads. At 41 answers as of today it is getting pretty large already, so I think a second thread will soon be a good idea.

[Andrew Janke]

Cool, thanks!

Answer 1

[Jan]

A complete list of changes for each command.

Currently we find "introduced in Rxy" already, but modifications of inputs and outputs are very useful also. Examples: When did unique introduce the 'legacy' flag? When did strncmp change the behaviour for empty strings and n=0?

[Andrew Janke]

This would be useful.

No reason to wait until MATLAB X to start doing it though; MathWorks could add a per-function/class Changelog to the doco any time, I think!

Answer 2

[Matt J]

My wish list:

(1) Colon operator produces column vectors, not row vectors:

x=1:4

x = 4×1

1 2 3 4

(2) Optimization Toolbox solvers should have only one algorithm per solver, i.e., instead of,

x1=lsqnonlin(fun,x0,lb,ub, optimoptions(@lsqnonlin,'Algorithm','levenberg-marquardt'))
x2=fminunc(fun,x0, optimoptions(@fminunc,'Algorithm','trust-region'))

we would just have

x1=lsqnonlinLevMarq(fun,x0,lb,ub)
x2=fminuncTrustReg(fun,x0)
etc...

(3) The Image Processing and the Computer Vision Toolboxes would be designed around the coordinate conventions of ndgrid() instead of meshgrid().

(4)One-dimensional array types, i.e., with ndims(X)=1.

[Walter Roberson]

Matt, if colon operators produces column vectors, then how would you deal with the fact that at present, for loops iterate over columns?

for i = [1 2 3; 4 5 6]
   disp(i)
end

     1
     4

     2
     5

     3
     6

[Matt J]

They can iterate over rows or over the individual entries of the input matrix in linear indexing order. I don't care. I don't think I've ever used that feature in 25 years of using Matlab.

[Walter Roberson]

I have used the feature a couple of times. Not often.

[Andrew Janke]

Why do you want column vectors instead of row vectors for the colon operator?

Row vectors seem easier to read, because they produce more compact, single-line output when displayed at the command window.

And the for loop iterates over columns of the array, so for i = 1:100 would now only do one pass. I think this use of a for loop to iterate over numbers in a range is a common use case.

[Andrew Janke]

I think I would also like 1-dimensional array types. Having to deal with vectors as a special degenerate case of 2-d arrays is a bit of a hassle, IMHO, and can cause edge cases in interface definitions.

[Matt J]

Why do you want column vectors instead of row vectors for the colon operator?

In linear algebra (which Matlab is designed around), the convention is to work more with column vectors than row vectors. I always find myself cursing under my breath whenever I have to type x=(1:N).'. I would settle for a new operator, though, e.g. x=1::N

And the for loop iterates over columns of the array, so for i = 1:100 would now only do one pass. I think this use of a for loop to iterate over numbers in a range is a common use case.

Walter said the same thing, but since we're saying we don't care about back compatibility, that could be abandoned as well.

[Andrew Janke]

Gotcha.

I think I'd be fine with for looping over elements instead of columns; I don't know that I've ever (intentionally) used the looping-over-columns behavior. But maybe that just means that I don't know what it's used for.

[Paul]

I've often (well, not really all that often) wondered why the for statement was designed to loop over columns from the very beginning. I think I might have used that feature once to loop over eigenvectors.

OTOH, it's probalby more common to have to do things like

for v = x(:).'

when one needs to loop over elements of a vector and it's unknown if the vector is column or row, e.g., due to user input or something.

[Steven Lord]

FYI there's an old discussion on comp.soft-sys.matlab from shortly before I started at MathWorks where Cleve stated:

I will admit to:

a) "Inventing" this "clever" feature in the original MATLAB, and

b) Never using it for anything useful.

[Andrew Janke]

OMG I love this. Thank you Steve!

Your link was broken for me. This one might work.

[Tucker Downs]

@Paul I don't think the dot operator is necisary in your example. Just transpose.

Only one character, but for something I type A LOT it's syntax convieniences like this that matter. Also, for anyone else reading, you can capture a colon-operator list and transpose it to a column. Not as convinient but maybe helpful.

for v = x(:)'
end

y = [[1:5]' [3:7]']

[J. Alex Lee]

I agree anything that returns a 1D array of something should default to returning it in a column vector, or at least pick an orientation! Some functions return columns, some return rows. Maybe an alternate approach if you don't want to break the for loop is to add a "for..in" construct that behaves like Matt proposes, just going through even element in linear index order.

The ndgrid vs meshgrid is an interesting one...wouldn't that mean for images we would want to index columns first, then rows? If I haven't got it mixed up, that seems juxtaposed to the previous sentiment about wanting default to columns?

Answer 3

[Andrew Janke]

In MATLAB X, I would like to see:

• An object display customization API like Python's __str__ and __repr__. (`disp` isn't suitable.) (See The Dispstr API)
• In mixed-mode arithmetic (combining floats and ints), ints widen to floats instead of narrowing to ints.
• Integer-looking literals (like 1234) produce ints instead of doubles.
• Both single-quoted and double-quoted string literals produce string arrays; to get char arrays you need to explicitly call char(...).
• Every function uses string arrays instead of char vectors or cellstrs in its return values, when not determined by the type of one of the inputs.
• Figure handle properties use string arrays instead of char vectors.
• In string literals, backslash escapes are interpreted by the string literal itself, and not by the *printf() functions.
• import statements have file scope, not function scope.
• Class properties with (1,1) string validators default to string(missing) instead of the empty string "".
• There's a date-only localdate type to complement the date + time datetime type.
• now() and today() return datetime and localdate values, instead of double datenums.
• For that matter, pretty much every date or time returned by a function is a datetime or localdate instead of a double datenum.
• Maybe classes and functions in the same package are visible by default, using unqualified names, instead of requiring package qualification or an import statement. (Though this is mostly handled if import gets file scope.)
• The "`if false or true`" parsing quirk (where the stuff after "false" is considered the first statement inside the if block) is fixed, and the whole "false or true" is considered part of the if condition.
• File IO is done OOP style, with fopen returning a file object instead of a numeric handle.
• UTF-8 becomes the default encoding for all external text IO on all platforms.
• A revamped helptext system for embedding somewhat-formatted, somewhat-structured API reference documentation in source code. The existing helptext format is too simple and loosey-goosey.
• Maybe chars should become Unicode code points instead of UTF-16 code units, and strings and chars should be stored in Python-style "flexible-width string" format. Would save memory, and make it easier to work with emoji or exotic scripts.
• The GUI Layout Toolbox's functionality is pulled in to base Matlab, including support for relative positioning and sizing of widgets (like how Java Swing layouts work), and relative positioning layouts become the default (instead of 'normalized' or absolute-units positioning like it is now).

Things I do not want to see:

• Multithreading.

[Walter Roberson]

if false or true

To clarify: do you mean literally using the operator spelt out as or instead of the | operator ?? The named operators have never been infix in MATLAB.

Could you give a short example ?

[Andrew Janke]

No. I do not want "or" to become an infix operator. I'm talking about a syntax/parsing quirk with the if statement, where if you put more stuff after the first thing following the if which is a valid expression, that stuff is interpreted as the first statement inside the if block and not as part of the condition for the if.

I'm using "or" here to illustrate a potentially common newbie mistake that gets interpreted by Matlab's parser in a surprising and potentially misleading way.

Here's another example:

if false whatever bogus stuff you want here
  disp('yup')
else
  disp('nope')
end

Run this and you get:

nope
>> 

Similarly:

if true or 2 < 3
  disp('yup')
end

You get:

Error using  | 
Too many input arguments. 
>> 

I think this is confusing to newbies, a potential source of subtle bugs, and the grammar/parsing weirdness just bothers me.

[Andrew Janke]

This is reported as MathWorks Tech Support case #05062335.

[Walter Roberson]

I was curious about the performance differences between char and string:

format long g
N = 1e5;
Achar = char(randi([33 127], 1, N));
Astr = string(Achar);
idx = randi(N, 1, floor(N/10));
t0 = timeit(@() Achar(idx), 0)

t0 = 
               3.51935e-05

t1 = timeit(@() Astr{1}(idx), 0)

t1 = 
               3.86935e-05

t1/t0

ans = 
          1.09945018256212

t2 = timeit(@() arrayfun(@(K) extract(Astr, K), idx), 0)

t2 = 
               1.421328801

t3 = timeit(@() arrayfun(@(K) K, idx), 0)

t3 = 
               0.020044801

The extract() version is the official API, with the {1}(idx) being considered to be a legal but discouraged hack. The extract() version is, however, up to fifty thousand times slower in my tests (one of my earlier runs had higher ratios than this one)

round(t2/t0)

ans = 
       40386

round(t3/t0)

ans = 
   570

part of this is the time required for the arrayfun(), but you can see from t3 compared to t2 that extract has by far the major cost.

[Andrew Janke]

Well yeah. Goes without saying that I'd want it to be Fast.

[Andrew Janke]

Even as is, I'm not too worried about the performance difference here. If you want to do characterwise operations, convert the string to a char array. Like you do in Java. I just think that characterwise operations are a relatively unusual case in Matlab, seldom happen inside performance-critical code, and in most cases strings are a better type, to the extent that I don't think it's best to have the '...' and "..." literal expressions produce characters. Could be wrong here; I dunno. So maybe '...' should stay as chars. I'd just like it to produce strings because

a) I want to use strings pretty much everywhere, and I don't like doing the extra work of holding down the shift key to produce " when writing string literals.

b) I think the language should encourage most developers to use string arrays pretty much everywhere, and getting to char arrays should be extra work.

[Andrew Janke]

Oh yeah. Your performance concerns here totally make sense to me. I'm not suggesting we get rid of the char datatype. I'm just saying that the literal expression 'foobar' should produce a string array by default, and if you really want chars, you call char('foobar') and get a char array back and it works pretty much like chars do now and you can index into it and get individual characters or char subarrays. All I want here is a change in the behavior of the literals, not the datatypes.

[Andrew Janke]

Also, and this is kind of off-topic, but: I'm kind of disappointed with the overall performance of string arrays in current versions of Matlab. It seems like since they're a dedicated datatype that has (or should have!) a simpler internal storage model than cellstrs, they should outperform cellstrs in many cases, and never be slower. But in my testing as of R2019b or so, they often don't!

I've reported this to Tech Support and discussed it with a couple MW developers. If this is a concern to y'all, maybe you could pile on and report your own results too?

[Steven Lord]

A few of these you can do already, more or less.

• An object display customization API -- see the documentation on customizing the display of objects.
• Figure handle properties use string arrays instead of char vectors. -- I think most if not all Handle Graphics properties that could accept char vectors or cellstrs should also be able to accept string arrays. If you see one that you think should accept strings but it does not, please report that to Technical Support.

[Andrew Janke]

Hi Steven! Thanks for responding.

I find the current API for customizing the display of objects inadequate for a lot of my uses:

• It doesn't differentiate between contexts needing per-element string representations, or a single string representation for a whole array.
• It doesn't work for formatting objects for inline display to %s placeholders in the *printf family of functions. (I think? Maybe there's
• It doesn't apply when the user-defined objects are stored inside fields, cells, or properties of compound data types, such as structs, cell arrays, table arrays, or other objects.
• Doesn't apply to display inside the Workspace widget of the Matlab desktop.
• It would be nice to have a distinction between human/user-presentation formats (like "str" in Python) and lower-level debugging oriented formats (like "repr" in Python).

As far as I can tell, the new extended display customization API (beyond the original disp and display override support) is just a way of conveniently producing more complexly-structured disp output.

I'll see if I can find time to write up a blog post about this; I discuss it often enough.

I've had no problem passing string arrays to properties of Handle Graphics figure handles, but they seem to get converted to char or cellstr when you do that, and always come back out as char or cellstr;

>> disp(version('-release'));
2021a
>> f = figure;
>> f.Name
ans =
  0×0 empty char array
>> f.Name = "marshmallow";
>> f.Name
ans =
    'marshmallow'
>> 

So user code still has to deal with chars in this case. Would be nice if it were just uniformly string-ified.

[Walter Roberson]

I just think that characterwise operations are a relatively unusual case in Matlab, seldom happen inside performance-critical code

Character operations are important for parsing, which has strong connections to file I/O.

[Andrew Janke]

Do people do much parsing in Matlab? These days, most Matlab-relevant data seems to come in standard formats like CSV, JSON, XML, or Excel, for which there is built-in native I/O and parsing support. Are people writing custom/unusual file format parsers in M-code?

I don't think this change would be a big problem for parsing: the char array type would still be available, and implicit conversion between char and string would handle the rest. Only concern I can see would be performance implications of creating the extra temporary string arrays. Dunno how much to worry about that: parsing code would already be creating a bunch of temporary char arrays, and even now if you do parsing of nontrivial text file formats in M-code, you're going to be a sad panda when it comes to performance.

[Walter Roberson]

Yes, it is common for users to do custom parsing. regexp() and textscan() get a lot of work-out. loops of fgetl and sscanf() too, but if you have the memory, you can often get much higher performance by reading the entire file as character and fishing through with regexp() or strmatch()

I have not re-checked lately, but at least for several years, readtable()'s handling of xlsx files involved using regexp()

As measured in my post above, the random-access performance using extract() is far far slower than using character indexing.

[Andrew Janke]

You've inspired me to add some string array vs char array comparisons to matlab-bench: https://github.com/janklab/matlab-bench/blob/master/bench_matlab_ops/compareStringAndCharOps.m. If you want to contribute some items for use cases relevant to your parsing activity, I could use some more examples here!

Strings are significantly slower than chars for pretty much every operation I tested. The most relevant one here, I think, is implicit conversion of 1-character-long strings to char arrays. That could really hurt performance of char array operations if '...' literals were to construct strings intead of char arrays.

>> compareStringAndCharOps(NaN, ["convert"])
String vs. char benchmark:

Matlab R2021a on MACI64
OS: Mac OS X 10.14.6
Intel(R) Xeon(R) W-2150B CPU @ 3.00GHz, 10 cores, 128 GB RAM 

                            Name                             CharNsec    StringNsec    StringWin
    _____________________________________________________    ________    __________    _________
    Construct from char, n=1                                    85          1666         -18.67 
    Construct from char, n=1000                                272           606          -1.23 
    Construct from char, n=100000                              133          9221         -68.12 
    Convert scalar string as char for (s{1}), n=1              129           522          -3.05 
    Convert scalar string as char for (s{1}), n=1000           272           749          -1.75 
    Convert scalar string as char for (s{1}), n=100000          85         10096        -118.42 
    Convert scalar string as char for (char(s)), n=1            32           103          -2.19 
    Convert scalar string as char for (char(s)), n=1000         37           171          -3.58 
    Convert scalar string as char for (char(s)), n=100000       14          6620        -466.44 
    Impl conv to from variable scalar char, n=1                 52          5642        -108.02 
    Impl conv to from variable scalar char, n=100                3          5130          -1908 
    Impl conv to from variable scalar char, n=1000               2          5123        -2630.2 
    Impl conv to from variable scalar char, n=10000              1          5257        -4331.1 
    Impl conv to from variable scalar char, n=100000             3          5099        -2035.8 
    Impl conv from literal to scalar char, n=1                  10          4797        -474.25 
    Impl conv from literal to scalar char, n=100                 4          5110        -1231.2 
    Impl conv from literal to scalar char, n=1000                1          5228        -4806.5 
    Impl conv from literal to scalar char, n=10000               1          5123        -4601.6 
    Impl conv from literal to scalar char, n=100000              3          5070        -1729.6 

[Andrew Janke]

I'm going to send these string vs. char benchmarks along to MathWorks Tech Support and engineering later this week as part of a "Please speed up string arrays" enhancement request. If you'd like to be on that email thread and TS ticket, send me the email you have your MathWorks account under and I'll include you.

[Andrew Janke]

@Steven Lord - Have a look at Tech Support case #04456828, where I've put in a related suggestion for this before.

[Steven Lord]

That's okay, I trust our Technical Support team to handle that case.

[Walter Roberson]

"In mixed-mode arithmetic (combining floats and ints), ints widen to floats instead of narrowing to ints."

What would be your proposals for how the following should work?

a = intmax('uint64') / 8 + 5

a = uint64 2305843009213693957

b = double(1)

b = 1

c = single(1)

c = single 1

a - b

ans = uint64 2305843009213693956

a - c

Error using -
Integers can only be combined with integers of the same class, or scalar doubles.

[Walter Roberson]

format long g
a = intmax('uint64') / 8 + 5

a = uint64
   2305843009213693957

b = double(1)

b = 
     1

c = single(1)

c = single
     1

fprintf('double(%.999g)\n', double(a) - b)     %widen uint64 to double

double(2305843009213693952)

fprintf('single(%.999g)\n',single(a) - c)    %widen uint64 to single

single(2305843009213693952)

[Andrew Janke]

I think I'd have them work pretty much like C's mixed-mode conversion rules.

a = intmax('uint64') / 8 + 5

8 and 5 should be signed int32s; 8 + 5 yields an int32 13; that int32 widens to uint64 when combined with the intmax result and a is a uint64.

If you did 5 - 8 instead to get -3, I think that should throw an error (a type of overflow error) when combined with a uint, because uints can't represent negative numbers.

b = double(1)
a - b

Combining a double and a uint64 would produce a double, and you'd live with the roundoff.

c = single(1)
a - c

I think this should produce a single, following the general rule of "ints 'widen' to floats".

When integers of different classes are combined, like so:

int8(3) + int32(420)

Then the smaller ints should widen to the larger ints.

Maybe it could go to an even wider type if necessary to hold both values, like the combination of a uint32 too large to fit in an int32 and a negative int32; that could widen to an int64. Raise an error if no type could be found that could exactly represent all of the input values. I'm not sure if that's actually feasible, though; the algorithm might be complex, and it could cost extra array scans and min/max accumulation when an arithmetic operation is being done on nonscalars.

[Walter Roberson]

8 and 5 should be signed int32s; 8 + 5 yields an int32 13;

Careful, the expression was not

a = intmax('uint64') / (8 + 5)

In some languages, the rule for integer-like literals not marked as unsigned, is that they occupy the narrowest integers that they fit into, so in this case 8 and 5 would be int8.

Maybe it could go to an even wider type if necessary to hold both values, like the combination of a uint32 too large to fit in an int32 and a negative int32; that could widen to an int64.

So the resulting type would be determined dynamically ? A uint32 + B uint32 results in uint32 if it fits and uint64 if necessary? If you are vectorizing then you might not know you need to widen until some distance into the array... do you go back and widen the already-calculated results and resume ? Do you calculate in maximum width that is possible for adding two values of that type (in this case uint64) and then later scan to find out if widening was needed, and if so then demote down to the narrower type? Do you demote to the narrowest type that will fit all of the results, so uint64(1) + uint64(2) demotes right down to uint8(3) ?

... remembering that integer types are often used in hardware interfaces or interfaces that expected a fixed type...

[Andrew Janke]

Oops, you're right; got order of operations wrong.

a = intmax('uint64') / 8 + 5

Should be intmax('uint64') gives you a uint64; 8 is an int32 which widens to a uint64; then 5 is an int32 which then widens to a uint64.

"Narrowest type that fits" – you're right; that's C's behavior – instead of defaulting to an int32 might not be as convenient for Matlab, where literals might be used to initialize an array, which is then assigned into elementwise. x = repmat(0, [1 1000]) giving you an int8 may not be ideal, because then x(1) = 420 won't work. int32 seems like a nice common default type for ints to be.

> So the resulting type would be determined dynamically ?

Yup. The temporary output variable would probably need to start out wide, and then be narrowed if the result fits in a narrower type. Or start it out narrower and then dynamically widen it if the operation hits an element that doesn't fit. (That might be really hard to do for multithreaded operations.) Like I said, might not be feasible.

> Do you demote to the narrowest type that will fit all of the results, so uint64(1) + uint64(2) demotes right down to uint8(3) ?

Don't think I'd bother with that, for stuff like the assignment reasons mentioned above.

> integer types are often used in hardware interfaces or interfaces that expected a fixed type...

Ooh, didn't think of that. Yeah, dynamic widening based on the actual value of arithmetic results probably isn't a good idea. Getting too clever here.

[Walter Roberson]

The fact that basic arithmetic is divided into multi-core pieces tells us that dynamic widening based upon actual values gets a bit messy. Possible though. It would probably be a lot easier to widen and do the arithmetic and then determine whether any location needs the wider type and if not to drop down (you might be able to get the value scan nearly "for free" as you store the values.)

I tell you though, that the current behaviour of saturating when adding two uint8 is relied upon by a lot of image processing... expected dynamic range is determined by the datatype, so if you overflow a single uint8(255) to uint8(256) based upon dynamic widening, then suddenly what used to display as full-bright colors are only 1/16th intensity colors....

[Andrew Janke]

That's a good point about saturation behavior, and I don't have an idea for how to handle it gracefully. (A global setting to control saturation vs. overflow errors vs. auto-widening in int arithmetic would be terrible. You could define separate saturating and widening/overflow-erroring int datatypes, but eww.) Maybe auto-widening is just a bad idea.

[Walter Roberson]

The fixed-precision toolbox permits defining saturation and related behaviours on a per-object basis. I have a vague memory of seeing a FI object that could expand its bit representation at need (with an upper bound... I think it was 1023 bits.)

[Steven Lord]

There's a new feature in release R2021b that allows you to customize how your object is displayed when it's stored in a container like a cell array or a struct array.

[Andrew Janke]

I saw this in the release notes and in discussion on the Discord! Very interested! I am going to play with this over the next week or so, and then I'm sure I will have Opinions. Thanks!

[Steven Lord]

Regarding some of the date and time related requests, in release R2022a we moved some of the functions for working with dates and times from Financial Toolbox into MATLAB. In particular today will give you today's date [just like datetime('today') does.]

Also in release R2022a "MATLAB uses UTF-8 as its system encoding on Windows®, completing the adoption of Unicode® across all supported platforms."

[Andrew Janke]

Sweet! That's a nice little convenience. I missed the R2022a Prerelease this time around, but will hop on the main release this weekend.

Answer 4

[Andrew Janke]

A possibly radical one:

Semicolons are no longer needed to suppress display of a statement's result. Instead, output is suppressed by default, and if you do want it displayed, you append a "!" (or something else) to the end of the statement. Semicolons are now just statement separators, and you can omit them in most places with no effect.

Maybe this should apply only to function and classdef files, and statement result display is on by default in script files, and you still suppress its display by appending a ";" there.

[Munin]

How would this remain compatible with current command dual syntax?

[Andrew Janke]

I'm not sure I see the issue? In command syntax currently, trailing semicolons are treated specially. The trailing "!" or whatever could be similarly treated specially in this alternate behavior.

function out = fooblah(in)
if nargin > 0
    fprintf('in="%s"\n', in);
end
out = 420.69;
end

Output:

>> fooblah
ans =
  420.6900
>> fooblah x
in="x"
ans =
  420.6900
>> fooblah x;
in="x"
>> 

Or am I misunderstanding the concern here?

[Walter Roberson]

I am not in favour of anything that would lead to differences between pasting code at the command line (script) and having the exact same code inside a function or classdef file.

Suppose you are debugging and you have stopped at a statement, and you wish to examine the results of the statement without formally executing it. Remembering that if you formally execute a statement inside a function that you cannot tell MATLAB to repositition its notion of the "current" execution point. You might be expecting errors, perhaps; you might be needing to explore possibilities for what-ever reason.

So you are stopped at a statement, you copy the statement out using copy-and-paste, you paste the code in at the command line... and it gives you a different result than would be the case for telling MATLAB to go ahead and execute the statement. Because the command line is "script" environment and you defined scripts and functions to execute differently.

Maybe this should apply only to function and classdef files

Remembering that applies to the idea that "Semicolons are now just statement separators, and you can omit them in most places with no effect." The implication is that syntax that would be valid inside function files would not be valid inside scripts or command line...

if you do want it displayed, you append a "!" (or something else) to the end of the statement

At the moment, the comma statement separator acts as a separator and does not suppress output. Would

a = 3, b = 5

get transformed into

a = 3! b = 5!

or would it get transformed into

a = 3!, b = 5!

[Andrew Janke]

That's a good point. Whatever is done should work uniformly; no different behavior in classdef/function files vs scripts or on the command line.

I would expect this would be how to do it:

a = 3!, b = 5!

Commas separate statements; output suppression is a per-statement property, so each statement should get its own output suppression control thingie.

[Andrew Janke]

My thinking here is this: If there's two ways to do something, and one of the ways is much more common and what you usually want, then that way should be the default way and take less work to accomplish, and the less-common way should be the way that requires some extra work or indicator.

I think suppressing output display for statements is by far the more common case. Even the Matlab Editor seems to agree with me! If you omit a semicolon, it'll flag a code inspection, and if that's really what you want, you have to add an inspection-suppressing %#ok<NOPRT> pragma to quiet it down. (I like having code that is "code-inspection-clean".)

And sometimes I run in to the problem that somewhere in a large code base, somebody omitted a semicolon somewhere, and now my program is spitting out lots of undesired output. It is pretty difficult to search for a missing semicolon in a Matlab codebase! Hard to write a grep or regex pattern that will detect it. Because there are lots of non-statement code constructs that are lines that don't end in semicolons but also don't produce output (like classdef Foo, if <something>, for i = 1:10, etc etc), you can't just search for non-blank lines that don't end in semicolons. And there's no M-lint report generator any more AFAIK, so you can't try looking for that NOPRT inspection across a large body of code.

Searching a code base for exclamation marks would be pretty easy, since they have little other syntactic role in Matlab code. (Not much code is probably using the !some shell command syntax, and if it is, you can just search for "! that isn't at the beginning of a line", which is easy enough.) So it'd be easier to find where unexpected/undesired output is coming from.

[Gregory Vernon]

I like how it's done in Julia, where if you're in the REPL and enter a single line of code without a semicolon:

               _
   _       _ _(_)_     |  Documentation: https://docs.julialang.org
  (_)     | (_) (_)    |
   _ _   _| |_  __ _   |  Type "?" for help, "]?" for Pkg help.
  | | | | | | |/ _` |  |
  | | |_| | | | (_| |  |  Version 1.5.4 (2021-03-11)
 _/ |\__'_|_|_|\__'_|  |  Official https://julialang.org/ release
|__/                   |

julia> x = abs(-2)
2

julia> x = abs(-2);

julia>

it prints output. But within functions it doesn't require semicolons to suppress output:

julia> function hypot(x,y)
           x = abs(x)
           y = abs(y)
           if x > y
               r = y/x
               return x*sqrt(1+r*r)
           end
           if y == 0
               return zero(x)
           end
           r = x/y
           return y*sqrt(1+r*r)
       end
hypot (generic function with 1 method)

julia> d = hypot(-2,1)
2.23606797749979

[Walter Roberson]

I think suppressing output display for statements is by far the more common case.

Not when you are working at the command line. Or in scripts.

Basically, people who write scripts usually expect output for each statement unless they turn the output off. And a lot of people use MATLAB in mostly-interactive mode instead of writing functions (or only writing functions from time to time.)

[Andrew Janke]

> Not when you are working at the command line. Or in scripts.

Hmmmmmm. At work, I do a fair amount of command line work, and we've got a good collection of scripts from our users. In our scripts and command line usage, it seems a lot more common to do small "dumb" modifications like for i = 1:numel(x); x(i) = some_simple_operation(x(i)); end where you'd want the output suppressed, or do things like:

obj = MyBigObject;
obj.Property1 = 'something';
obj.Property2 = 420;
obj.Property3 = 69

where you wouldn't want to get a big 40-line dump of the new obj state on every property setting operation.

I'd be interested in seeing some objective analysis of this. Maybe someone with some ANTLR skill could whip up a little analyzer to scan a code base (of scripts), take a look at the number of lines which have suppressible output, and count up the number and proportion where they were actually suppressed?

I may be biased here; I'm working in a large-ish enterprise-y codebase, and all our stuff operates in that context.

[Loren Shure]

FYI, only in reference to creating reports from the Code Analyzer, please see this page of the doc! Glad you are talking about what you would like to see changed...

--loren

[Andrew Janke]

Thanks @Loren Shure! That actually looks totally like I was looking for; I guess I'm just not up to speed on how the Matlab Code Analyzer works these days. In particular, it looks like one could easily use that to do "show me all the missing semicolons in this code base" by building on checkcode calls. This will be useful to me.

[Tucker Downs]

How about function attributes [[nodiscard]] (Error if this function is called without output arguments) and [[nodisp]] supress all print statements. Possibly other useful traits

[Andrew Janke]

> How about function attributes [[nodiscard]] (Error if this function is called without output arguments) and [[nodisp]] supress all print statements. Possibly other useful traits

Personally, I'm hesitant about this. This is probably a matter of taste and judgment, but in my view this seems like a substantial increase in complexity of Matlab code definitions, which is not great for the typical Matlab user. Especially because it makes behavior of a given line of code more context/scope dependent. Seems like this would make M-code start looking like modern Java, and I'd be plastering [[nodisp]] over every single function/method I write. That doesn't seem ideal to me, especially if your software design style involves factoring things into lots of small functions or OOP methods.

I think that I would actually enjoy being able to write Matlab code that used function/method annotations or decorators (like Java and recent Python do), but I suspect 99% of my fellow Matlab coders would hate me for doing so, and have trouble working with that code.

I would rather have more uniform code behavior and live with the inconvenience of hunting down missing semicolons, I think.

[Andrew Janke]

It seems easy enough to implement the [[nodiscard]] behavior using regular M-code constructs with current Matlab.

Add this function to your library:

function mustCaptureOutput(callerNargout)
    if callerNargout == 0
        error('You must capture the output of this function!')
        % ... and use fancy dbstack() parsing techniques if you want
        % to automatically include the name of the called function in the
        % error message ...
    end
end

Then in your functions that want their outputs to be captured, you can say:

function outYouReallyWant = myFunc(x, y, z)
    mustCaptureOutput(nargout);
    % ... do stuff ...
end

I can not think of a way to deal with auto-display on omitted semicolons in this manner; that's a different language mechanism.

[Walter Roberson]

Checking nargout and error if not being assigned, is already done by some of the functions to process Import Options, such as setvartype()

[Tucker Downs]

@Walter Roberson sure. But wouldn't it be nice if you could write all the code to check if nargout > 1 and if it is exit by just typing [[nodiscard]] or, for even more control [[nodiscard=3]]

[Walter Roberson]

@Tucker Downs

Hmmm... I think that's a NO, from me, that that would not be nice. My belief is that if a function that can output something, and it does not deliberately avoid output when nargout == 0, then the proper response from MATLAB is to display the output, not to complain that the values are not being assigned to variables.

For example I think that the proper response for having a setvartype() without an assignment, is not for there to be an error, but rather for it to be flagged as a warning by mlint

If, hypothetically, a new assignment operator were created that allowed the user to manage

A = object_of_class_B

inside class B, something along the lines of

function newobj = assign(obj, newobj)     %obj being the object of the class

then yes in such a case it might be important to verify that newobj really was present, since it could make a difference in how you manage reference counts or whatever. But shy of such a new operator... No, I think the semantics you propose is not good design.

Question: if [[nodiscard]] were implemented, then would

[~, ~, ~] = function_call(parameters)

be counted as "discarding" the outputs in violation of the proposed [[nodiscard=3]] ?

[Tucker Downs]

Sure, if displaying an output is a side effect that you want, you don't have to use nodiscard. The nice thing about function attributes (as a feature idea) is that you wouldn't have to use them.

Your last example raises a good point. I would like to say that yes that would count as discarding. But in matlab we need to accomodate the case where you want the 3rd output but not the other two. So I would say no, that does not count as discarding.

Another useful attribute would be [[supress_output]] so I can prevent contributors from causeing output by accidently deleting a semicolon. Also [[const]] on object functions to prevent / guarantee that the object properties state of a handle object isn't gonig to change. But that might be an entire new can of worms.

[Tucker Downs]

@Andrew Janke that is a useful mixin / util. I'll promptly be adding it to our code. Simple idea. I just haven't thought about no-discard until this conversation. I got the idea from C++

[Walter Roberson]

@Tucker Downs

By your logic, we might as well add every function attribute that we can possibly think of

[[NeverOnASunday]] [[HighTide]] [[NoSiciliansWhenDeathIsOnTheLine]] [[Alignment=4096]] [[SpellMyNameWithAnS]] [[IFeelOrangeToday]] [[KOI8FilesOnly]] [[NoThreads]] [[NeverGonnaGiveYouUp]] [[OddResults]] [[BaseIndex=0]] [[BirbImagesOnly]]

Answer 5

[gwoo]

I don't know the technical name for it but being able to call methods, properties, or indexing without having to make a new variable first. Kind like in python where you can call a function that will output an array or whatever and instead of saving it to a variable first and then indexing, you can just index right off the end of the function call. I know you can do this for strings and structs, but not for cells or arrays. Also, being able to perform a series of functions on an array, the way you can now with strings.

For example:

[5, 1, 2](2) = 1

horzcat([3;2;1], [5;6;7])(3,2) = 1

[Andrew Janke]

Cool!

I've heard this called "chained indexing" or "chained operations" in other contexts.

[Michael Zauner]

This would also be really helpful for anonymous functions where you can not define a variable at all.

Answer 6

[Andrew Janke]

Remove the length function.

Its behavior of "size along the longest dimension, picked at run time" is a little weird, most junior programmers don't expect it, and it leads to subtle bugs that can silently produce incorrect results instead of erroring out. In my 15 years of Matlab programming experience, I've seen so many people call length, and I've never seen one who actually wanted what length does instead of numel or size.

Let everyone just use numel or size instead; those work "safely".

Answer 7

[Tucker Downs]

Yes! I think in all established products it's occasionally neccissary to make major pruning of older functionality for the good of the product / eco system. In companies I've worked for we've done this and made plenty of annoucements "Your legacy code might not work in version!!!! but we have guides on how to change it / we will support old matlab for the next X (many many) years."

For the most part it's always been well recieved.

I'll add

max(2,[]) should not return []

++ incrementing

maps as a more prominant base data type

expose more internal apis for making subclasses for plot objects, like custom arrows

[Andrew Janke]

Oh, yeah, I'd like "augmentation operations" like ++ and +=, too.

I'm not sure we're ready for maps as a more prominent base type: IMHO, nobody has yet figured out what a good general-purpose Map or Dictionary type in Matlab should look like, in terms of interface and semantics. containers.Map definitely ain't it.

Lower-level APIs for custom plot objects would be great too.

[Tucker Downs]

I think just... python string maps would be good to have more prominant. More complicated maps could still require special constructors.

Also I'd like to add nesting scopes for variables in functions. I don't care if the variables aren't cleaned until the parent function returns but it would make my workspace so much cleaner when debugging. It's also a really useful way to group a "thought" in your code that isn't yet deserving of being a function on it's own.

function out = myFun(x,y,z)
    SomeVariable = %...  
    {
        %Can access SomeVariable from the parent scope here
        DifferentVariable = 3;
        if condition && exFunction(SomeVariable, DifferentVariable)
            %do something interesting
        end
    }
    %Cant access DifferentVariable here, it's out of scope
end

[Andrew Janke]

But Python maps do not take strings as keys... they take "hashables" (i.e. immutable, valuewise-equivalance-testable objects that the Python interpreter can create hashcodes for). A Matlab equivalent could be "anything that supports isequal and is nonmodifiable".

I get where you're coming from, though. I run in to this use case a lot, and always end up just hashing/munging my keys to be valid Matlab variable names so I can use a struct for this case. A decent Map or Dictionary type would be really nice. And I think it would have to be a built-in type, and possibly introduce the notion of a generic "hashcode(value)" operation, in order for it to perform decently. Otherwise you're left iterating isequal over a list of keys; ouch.

I wonder if that's something that could be strapped on to the existing Matlab using a MEX implementation, without requiring a non-back-compatible change?

[Andrew Janke]

I dig your block scoping idea. Establishing scope like this by breaking things up into subfunctions can be a hassle.

I really would want the variables to be cleared at the end of the block, though: then it could be used for RAII/SBRM style resource management using onCleanup and object delete destructors!

[Steven Lord]

As of release R2019b you can create your own custom chart classes using the matlab.graphics.chartcontainer.ChartContainer class.

As of release R2022a you can also create your own custom Live Editor tasks or custom UI components in App Designer. See the Release Notes for more information.

[Andrew Janke]

Oh, cool! I'm on R2019b now, and I didn't realize that was already a thing. Going to try upgrading to R2022a soon anyway to get the other UI coding improvements.

Answer 8

[Walter Roberson]

This would not break backwards compatibility, but something to consider:

A lot of time, people try to

for x = first:increment:last

with non-integer increment. And then they want to

    f(x) = value;

but of course x is non-integer so that fails.

There are standard ways of rewriting this: the common

    counter = 1;
    for x = first:increment:last
      f(counter) = value;
      counter = counter + 1;
    end
    x = 

or (less likely by far, but cleaner since counter is more sensible)

    counter = 0;
    for x = first:increment:last
      counter = counter + 1;
      f(counter) = value;
    end

or the formal and flexible

    xvals = first:increment:last;
    num_x = numel(xvals);
    f = zeros(1, num_x);
    for xidx = 1 : num_x
       x = xvals(xidx);
       f(xidx) = value;
    end

But... keeping those counters is a bit of a nuisance, and people get them wrong.

So I would suggest something I have seen in a couple of programming languages: that there be an accessible automatic counter. We could imagine, for example,

    for x = 0:.01:2*pi
      f(#x) = sin(x.^2 - pi/7);
    end

where the #x translates as "the number of x values we have processed so far".

Indexing a variety of arrays with the same # would be considered valid, so you could write

    for x = 0:.01:2*pi
      f(#x) = sin(x.^2 - phase(#x));
    end

But now we have a question that might lead to some backwards incompatibility: suppose we have

    for x = 0:.01:2*pi
      y = 0;
      for x = 1 : .5 : 5
        y = y + z.^(x-1)./gamma(x+1);
      end
      f(#x) = sin(x.^2 - y);
    end

and the question is: in that f(#x) that is after the nested for x, should the #x refer to

1. the last index associated with the inner x?
2. the index after the last one associated with the inner x?
3. the index associated with the outer x?

Consistency with existing nested for loops would say it should be the first of those, that at any point, this hypothetical #x should refer to the last for index for variable x that was encounted in the flow of execution -- just like the way that the sin(x.^2 - y) is going to use the last x value from the for x = 1 : .5 : 5 .

I would kind of like such an operator to be associated with the innermost enclosing loop so that in this example the f(#x) would be counting relative to the for x = 0:.01:2*pi loop, but I do admit that it would be confusing to have the #x refer to that loop at the same time that the x itself would be what was left-over for the for x = 1: 0.5 : 5 loop. Also, in a context such as

    f = zeros(1,5000);
    for x = 0:.01:2*pi
      if x.^2 - sin(x) > 1; break; end
      f(#x) = acos(x);
    end
    f(#x+1:end) = [];

then it would make sense for the counter to survive the loop itself, which argues for the status quo of "last value assigned" rather than "according to scope". I think the factors are in tension here.

Now, if we are going to have automatic counters with for loops it might make sense to have automatic counters associated with while loops as well:

    x = 0;
    while x <= 2*pi & x.^2 - sin(x) < 1
       f(#???) = acos(x);
       x = x + 0.01;
    end

But while loops have no associated variable. So I might suggest

    x = 0;
    while x <= 2*pi & x.^2 - sin(x) < 1
       f(#) = acos(x);
       x = x + 0.01;
    end

where # by itself is the counter for the innermost enclosing for or while loop. Which would then permit

    for x = 0:.01:2*pi
      f(#) = sin(x.^2 - phase(#));
    end

which is not ambiguous. Now about about with nested loops?

    for x = 0:.01:2*pi
      y = 0;
      for x = 1 : .5 : 5
        y = y + z.^(x-1)./gamma(x+1);
      end
      f(#) = sin(x.^2 - y);
    end

The innermost enclosing for or while loop would be the outer for x loop... the one the user probably intended in such a context.

With the discussion above about what #x means after the end of a for x loop, this proposed behavior of # by itself would lead to the possibility that at that point, assigning to f(#) would be assigning according to the loop counter for the outer for x, but that assigning f(#x) would be assigning according to the loop counter for the inner for x . That is not ideal for readability, and is likely to lead to confusion.

It seems to me that in some cases, people would want a #x at that point to refer to the outer loop, but people would also sometimes want a #x to refer to the inner for x . It would also not surprise me at all if people wanted both ways at the same time. Of course, if they wanted clarity and readability, they probably should not have used nested for loops with the same variable name !!!

[Image Analyst]

I think the people who forget to round their indexes to integers, and are the ones who would need #, would be the same people who would never even know/remember that it exists as an option, and would not even know how or when to use it.

[Walter Roberson]

MATLAB is intended to make it easy for people to write code, and

    for x = 0:.01:2*pi
      f(#x) = sin(x.^2 - pi/7);
    end

is significantly easier than thinking to initialize a counter and increment the counter in the right place and take care of the counter edge cases.

There is a additional factor to consider, which is that people often want to follow with something like

    plot(x, f)

with their intention being that the x refers to the entire span of values that x was assigned in the for loop. I'm not sure there is a reasonable way to handle that. But I can say that I would find it more compact and less thought to write

xvals = 0:.01:2*pi;
for x = xvals
  f(#x) = sin(x.^2 - pi/7);
end
plot(xvals, f)

-- that is, the more the formalized tracking burden can be reduced, the better.

However... there is one additional factor that careful programmers take into account that merits some additional thought, which is pre-allocation.

It is tempting to propose that in a loop that uses #, that MATLAB behind-the-scenes does:

1. If any destination array being indexed with #var or # did not already exist and MATLAB can deduce the number of elements involved, then MATLAB pre-allocates the array
2. MATLAB keeps track of the highest location written to, per dimension
3. After the loop, if MATLAB pre-allocated, then it also truncates per-dimension according to the highest written into

This would represent some backwards incompatibility, in that with current for loops and arrays that do not already exist, then inside the loop, size() and whos() currently show the size it has grown to based upon the code flow, whereas under the above proposal, size() and whos() would reflect the size preallocated.

This could potentially still be worked around, if size() and whos() reported based upon the largest dimension written to, with there also being a "shadow" size that reflected preallocation. But I'm sure there would be some complications about that. For example, what happens if you (:) an array with a shadow size that is larger than the consumed size? And does linear indexing work according to the consumed size?

... might be easier to insist that #var could only be used on output with pre-allocated variables.

[Tucker Downs]

I love #x idea. +1 that would save me so much LOC

[Andrew Janke]

I would end up using this a lot; I often have to restructure my for loops to get an index to go with the actual value.

What are your thoughts on Python's approach to this with the "for i, x in enumerate(xs)" sequence generator and multiple assignment for for loops? I could see Matlab doing something like this. Let's say you have some parallel arrays xs, ys, and zs, you could do:

for [i, x, y, z] = enumerate(xs, ys, zs)

and get an index plus the ith element from each of the input arrays. This might generalize to creating other loop-pass-dependent variables using "generator functions" or the like.

This doesn't help with the while case; I still like the convenience of an implicit # and don't see how to handle that using the "generator function" approach.

Answer 9

[Walter Roberson]

The ability to assign a subset of fields to a struct (array) would be useful. It is common to want to be change a few settings, such as in a user initialization file, or to have a function that is concerned with getting only a subset of properties from the user. There thus might be a struct of updates to be applied to an existing struct. At the moment you have to loop through the fieldnames of the update struct, setting the fields of the existing struct one by one.

The ability to concatenate or assign between structs with the same fields in different orders would be useful. We have the experience of tables to look at: tables re-order as necessary to match the first order.

[Andrew Janke]

+1. struct and object "subset of fields" assignment or "merging" like this is such a common use case in the sort of code that I work with that any nontrivial code base typically ends up with a half dozen different custom helper functions for doing this, each with slightly different behavior.

Answer 10

[Image Analyst]

I'd like a way to enter 2-D matrices interactively easier. The current way with inputdlg() or input() is not WYSIWIG and very clunky and non-intuitive (do I put bracket, parentheses, commas, semicolons - no clue!) We need something like

% Pop up a modal dialog box with a 4 by 5 grid (worksheet) where users can enter values:
m = inputmatrix('Enter your values', 4, 5);

[Sean de Wolski]

x = zeros(4,5)
openvar('x')

?

This wouldn't work in a compiled app but works fine for in MATLAB.

[Image Analyst]

@Sean de Wolski Uh, ok, but virtually no one would know to do that (even I didn't and have never heard of that function). We need an input function similar to what people already know how to use. If you put "input matrix" into the help, openvar does not show up.

[Sean de Wolski]

Personally, I just use Excel for that. It's the right tool for the job of manually entering data into a spreadsheet. MATLAB can import it easily.

[Andrew Janke]

Excel has a couple limitations here. It requires an Excel license and installation, doesn't work at all on Linux or Matlab Online, and is difficult to automate on Mac because you don't have COM/ActiveX automation. Not all users or execution environments are going to have that.

@Image Analyst This is the sort of thing that I or another developer could probably whip up with user M-code for current Matlab. Would this be something you'd be interested in if I wrote it up as a library? It'd be Java code, so it'd work now, but Jexit is coming so that's going to be less useful in the near future. And I don't think it'll work for Matlab Online or web-based Matlab presentation contexts, but I don't know how to do custom GUI components using the new web-tech-based Matlab GUI stuff.

Answer 11

[Munin]

An LSP for other IDEs, better documentation of the Python engine, easier install of MEfP using some kind of shell script or dep manager, and a modern IDE UI supporting dark theme.

Also all components like Coder require a support of MATLABs licensing scheme so that they are usable in CI etc.

[Andrew Janke]

"LSP" = "Language Server Protocol", right? I'd really like to see that too.

[Steven Lord]

I'm not sure what you mean by "Also all components like Coder require a support of MATLABs licensing scheme so that they are genuinely useful." Could you clarify why you think MATLAB Coder and/or Simulink Coder are not "genuinely useful" right now?

[Andrew Janke]

> Also all components like Coder require a support of MATLABs licensing scheme so that they are usable in CI etc.

Oh, I see what you mean! Yeah, I get tripped up by the fact that I can't run Matlab Compiler in CI. If somebody broke the build, I won't find out until I go to actually do a release. :/

[Steven Lord]

Thank you for editing the answer to clarify that you're looking to use the Coder products in a continuous integration system.

[Walter Roberson]

@Munin @Andrew Janke

What happens now when you try to use the products with Continuous Integration that you would like to see changed?

[Andrew Janke]

It raises a "no license for Matlab Compiler" error and the CI run fails.

[Andrew Janke]

For context: It would be nice to have CI runs test your Matlab Compiler builds, because this exercises your build & packaging scripts, and lets you test the actual compiled artifacts, but more importantly IMHO, it verifies that your new M-code code base can actually be compiled. In interactive Matlab, if there are syntax errors in your code, that raises a run-time error when you try to run that line or function or load that class, so it only matters if that code actually gets used, only affects that particular functionality, and unit testing can catch it. But in the Matlab Compiler, if there is a syntax error anywhere in a code base that is included in a compilation, it breaks the build and you cannot deploy your code at all. So errors that a programmer may have introduced and not even noticed in interactive testing can bork your entire system.

It's impractical to test this by compiling interactively, because the Matlab Compiler is so darn slow, and most of your developers probably won't have Matlab Compiler licenses anyway; only a few devs who do your builds/releases (I call these "release engineers") will have Compiler licenses, and their time is probably expensive.

Answer 12

[Sulaymon Eshkabilov]

Another good and useful tool for students is to have a built-in function to reset all changes made by a user in preferences and interface menu options back to the default. Students quite frequently make changes and have diffculty to reset back their MATLAB menu panel and preferences.

Answer 13

[Andrew Janke]

Oh, here's one!

• Comments can begin with "#" in addition to "%".

This would enable Octave compatibility. But I think that might be to MathWorks's benefit: it would enable you to easily take existing Octave code and migrate your workloads to Matlab, which is the direction that MathWorks would like people to move.

Also enables use of "shebang" lines on Unix, so you could easily create executable commands as Matlab scripts.

[Walter Roberson]

I also see a fair number of people trying to use // comments

[Gregory Vernon]

While the shebang functionality is a good reason for this, I don't believe this should be done for the sake of Octave users. It's easy enough to do a find/replace for # -> % that anyone who wants to convert from Octave to Matlab can with relative ease.

But it's Octave that makes the claim: "There are still a number of differences between Octave and Matlab, however in general differences between the two are considered as bugs." Continuing:

• Furthermore, Octave adds a few syntactical extensions to Matlab that might cause some issues when exchanging files between Matlab and Octave users.

Octave should conform to Matlab syntax, not the other way around. Thus I'm only interested in # from a shebang perspective.

[Andrew Janke]

> It's easy enough to do a find/replace for # -> %

How would one do this easily, without mangling # characters that are inside strings or comments?

> I don't believe this should be done for the sake of Octave users.

It is more for the sake of Matlab users that wish to take advantage of existing Octave code.

> Octave should conform to Matlab syntax, not the other way around.

This is likely never happening here, because there's too much Octave code out there using "#" comments, and Octave coders like "#" comments.

Answer 14

[Walter Roberson]

Currently the model of MATLAB is that it always evaluates from left to right [*] finding the left-most unprocessed sub-expression and evaluating it, and then finding and evaluating the right hand side operand, and then performing the operation. The right operand is not processed until the left is evaluated, but unless the left operand results in an error, or the operation is && or || the right will always be evaluated.

[*] exception: there are some funky things with chains of ^ and .^ operators, they are not left strictly left to right.

This behavior prevents there from being function forms of if/else operations -- there is no equivalent to C's ?: operation. In C, the unselected operation is not evaluated at all.

The hack work-arounds require embedding the work to be done inside an anonymous function and writing a function like

function varargout = ifelse(expr, basepart, elsepart)
   if expr
       if isa(base_part, 'function_handle')
          [varargout{:}] = basepart();
       else
           varargout{1} = basepart;
       end
   elseif isa(elsepart, 'function_handle')
      [varargout{:}] = elsepart();
   else
       varargout{1} = elsepart;
   end
end

and using that gets ugly... and probably messes up multiple output processing.

Piecewise(x ~= 0, 0, 1./x)

can't be done and would have to look like

Piecewise(x ~= 0, 0, @(x)1./x)

I would like to see a cleaner way of handling this -- one in which the function being called does not need to know that a delayed evaluation is being done.

In the Maple programming language, there are two related mechanisms available. First, there is a simple syntax to delay evaluation. This is indicated by using ' ' around the expression. For example,

Piecewise(x <> 0, 0, '1/x')

In Maple, this is not a quoted string: Maple uses double-quotes for strings. Instead it is a delayed evaluation. Each time the relevant expression is evaluated, one level of unevaluation is removed; when it is eventually evaluated in a context where there are not remaining protective uneval() levels, then the expression is evaluated.

Secondly, Maple allows procedures (that is, functions) to declare a parameter as being of type "uneval", which has the effect of adding a layer of uneval around what is passed in. For example,

Piecewise := proc(x, basepart::uneval, elsepart::uneval) #stuff; end proc;

would permit uses to code

Piecewise(x <> 0, 0, 1/x)

and the 1/x will not be evaluated before being passed in to the procedure.

Some programming languages deal with these kinds of issues by using "lazy evaluation". Something like

Piecewise(x <> 0, 0, 1/x)

would not evaluate any of the parameters until such time as the code inside Piecewise asked for their value -- so if the code logic did not ask for the value of a particular parameter, it would never be evaluated.

If I understand correctly, tallarray() already does some delayed evaluation, building up expressions and then internally finding ways to reduce the memory access during evaluation.

[Walter Roberson]

Besides making it easier to handle exceptional cases, having a method of delaying evaluation is quite important in symbolic processing.

For example, suppose I have

int(a*sin(theta)^4 + b*cos(theta)^4 + f(theta), theta, 0, 2*pi)

and suppose that f(theta) is expensive to attempt to integrate, and suppose in its current form the expression does not have a closed form, so the after struggling for a long time to find the integral, the int() is going to return the int() form unevaluated.

Now suppose that I want to rewrite a*sin(theta)^4 + b*sin(theta)^4 as something like (a-b)*sin(theta)^4 + b*sin(theta)^4 + b*cos(theta)^4 and then group to (a-b)*sin(theta)^4 + b*(sin(theta)^4 + cos(theta)^4) which would be (a-b)*sin(theta)^4 + b .

At present, once I have made int() struggle to evaluate the integral, knowing it will not succeed, I can get back the unevaluated symbolic integral into a variable, and then I can start using findSymType and mapSymType() to manipulate children() of the integral. And I might know full well that the result is not expected to converge either (or at least is not likely to); perhaps I have more processing steps to do afterwards. So how do I do that? If I ask MATLAB to evaluate int() of the revised expression, expecting that it will decide it cannot integrate and eventually return unevaluated int(), then that takes a lot of time. I need to be able to tell MATLAB that I have here an expression that I do not want to have evaluated just yet .

Recently, MATLAB introduced a mechanism that does help with this process: there is now the "hold" option for int(), so I could emit int(expression, variable, range, 'hold', true) . And in the specific case of int() that does help for sure...

But... eventually I want to matlabFunction() the integral, expecting it to produce a call to integral() inside an anonymous function. And matlabFunction() cannot process the "hold" option. matlabFunction() also cannot process vpaintegral() calls. So... I have to release() the hold on the integral and let it struggle to find a closed form (which could literally take days before it gives up), just to have the unevaluated int() in a form that matlabFunction() is willing to process.

When you are implementing any kind of rewriting rule such as trig identities or hypergeometric identities, or implementing differentiation rules, then you need to be able examine and change the form of a symbolic expression without continually triggering evaluation. And the primary mechanism for that is careful use of unevaluation.

[Andrew Janke]

Ooh, yeah. I'd also like lazy evaluation in some cases, especially in the context of a ?: ternary operator.

I use your ifelse function hack a lot, and it's not very satisfactory because it doesn't short-circuit.

Answer 15

[Walter Roberson]

As part of a discussion https://www.mathworks.com/matlabcentral/answers/1450984-what-should-go-in-a-next-generation-matlab-x#comment_1788796 I hypothesized that:

If, hypothetically, a new assignment operator were created that allowed the user to manage

A = object_of_class_B

inside class B, something along the lines of

function target = assign(obj, target)     %obj being the object of the class

then that could perhaps have some advantages.

But what should the semantics be ? What would the use-cases be?

• such a thing could potentially make resource tracking easier
• there might be reason to warn about assigning between unlike data types. For example if A were uint8 but class B carried int8 then you might want a warning about negative values being truncated
• not sure what else...

If such an operator existed, you would need a way to distinguish the case where the target was a location that did not exist yet.

Hypothetically that could be handled by nargin < 2 or exist('target', 'var') being false.

But hypothetically perhaps there would be reasons to instead associate each name with a class such as UnassignedLocation, and then isa(target, 'UnassignedLocation')

An existing target of an assignment should definitely be made available inside such a function, so that its datatype can be examined, and resources poked around at.

There is commentary somewhere along the lines that if the target of an assignment is a class name or static method of a class, then the class cannot have influence on what the assignment means: that otherwise the statement

A = B

could change its meaning if a new class A were introduced. I think the implication of that is that there should not be an operator introduced that intercepted assignments onto a class. But possibly I have overlooked some reason why the kind of assignment operator I describe here should not be created.

Answer 16

[Andrew Janke]

I would like to see support for a more structured form of helptext, like Javadoc or Markdown, which could be used to produce richer documentation pages from the inline helptext in class and function source code.

Right now, the helptext is minimally-processed (in a loosey-goosey manner that I've never found formally specified anywhere) that supports basic references to other functions and classes, and definition of an Examples section. In doc for user-defined classes and functions, the helptext is rendered simply, mostly as-is in fixed-width font.

I'd like to be able to have an alternate helptext format that produced richer documentation output, which could be rendered as web pages with proportional font by default and support for various formatting, like section headers (maybe multi-level), fixed-width and demarcated code examples, hyperlinks, maybe even embedded images. It might also be nice to have some structuring that allowed you to specifically document the exceptions a method throws, maybe pre-and-postconditions, function arguments (for functions and methods which do not have arguments blocks that document the arguments separately), return values, and so on.

For methods and functions which have arguments blocks, I'd like to be able to add helptext on each of the arguments, in the manner in which one can put helptext on individual class properties, and have the help for all those arguments be automatically incorporated into the display of help <func> and doc <func>. That auto-generated documentation should also include representations of any declarative type & value constraints and default values that are defined for those arguments. Would be nice if arguments were expanded to include output arguments, so those could be documented as well (though I'm not sure how that would work in the case where one uses the same variable name as both an input and output argument).

I think Markdown, specifically GitHub Flavored Markdown (but maybe allowing arbitrary embedded HTML; I'm not sure), would be a nice format to do this "richer helptext" in. It's easy for most people to pick up, very readable in its source form (for people who are browsing the source code and reading the help there, and for the back-compatibility case where you want to use Matlab code written in the new format in an older version of Matlab), and supports most of the formatting controls I would like.

Maybe there should be a mechanism to use alternate formats for helptext.

One way you could do this in a flexible and even back-compatible manner would be to introduce a new %# pragma for specifying the format that helptext is in: something like %#<helpfmt:foo> where "foo" is the format of the helptext, like "markdown" for Markdown, "helptext" for the legacy Matlab helptext format, maybe "html" for arbitrary HTML, or "<whatever>" for a new structured Matlab documentation format, if you want to use that. For example:

%#<helpfmt:markdown>
%#<helpfmt:helptext>
%#<helpfmt:html>

If the pragma appears at the beginning of a block of helptext for a classdef, function, property, or so on, it would apply only to that one helptext block. If it appears at the beginning of a file, before the initial classdef or function line (or at the top of a Contents.m file), it should apply to all helptext in that file (and could be overridden by additional %#<helpfmt:...> pragmas on a per-block basis. Maybe the could even be some config file at the root of a source tree (that is, in the directory that goes on the Matlab path) to set the default helptext format for all files in a project/codebase.

It would maybe be nice if this supported some mechanism for linking to separate doco pages supplied by a user-defined Matlab library/project as separate HTML/Markdown/whatever files, that could be viewed in the Matlab doc browser, but have larger and richer content than is feasible to stick into embedded helptext comments, or doesn't make sense as the main help for a specific function or class.

You could even support user-defined custom helptext formats by allowing the "format" in %#<helpfmt:format> to be an arbitrary identifier (valid Matlab name), and provide a per-session hook to register user-defined handlers for custom formats. Like matlab.registerHelpfmtHandler('formatname', 'pkg.qualified.class.Name' where pkg.qualified.class.Name is the name of a user-defined Matlab class that conforms to an interface (or maybe inherits from a specific abstract class) that Matlab defines for helpfmt processor/handlers. Maybe it should be an actual object instance, but I don't think that would play well with clear classes.

I've been playing around with something like this in my MlxShake project, but it's hard to implement decently without some built-in support from Matlab itself.

Answer 17

[Tobias Held]

A small but handy function that allows when in workspace to press a letter and automatically highlight the variable with this first letter.

[Rik]

This wouldn't break compatibility as far as I can see. Feel free to cross-post this here (and/or submit a feature request).

Answer 18

[James Strieter]

One thing that I love about the way MATLAB has evolved over the 20+ years I've been using it is the way you keep adding modern features while keeping the fast matrix operations. Beautiful plotting built in helps a lot too. Like a lot of other people, I've said, "I'll use Numpy because it's free," and then 8 hours later I'm like this would take 5 minutes in MATLAB. And then I do it in MATLAB and it's done. I love that. Here are my favorite features from other languages that could be added, probably without breaking anything:

• Haskell's guards and list comprehensions,
• Lazy containers,
• LISP keywords,
• LISP style maps, in which the :keyword-with-hyphens is also a function that retrieves data from an object,
• Python's convention of defining ```__str__(self)``` to mean "This is what happens when you cast to a string," ```__int___``` for "This is what happens when you cast to an int," etc. Optional methods that support every kind of cast you could want.
• More modern kinds of loops. ```for i in <arbitrary_container>``` for example. Whether the loop is executed in any particular order depends on whether the container has any kind of order, etc.
• An API for defining language extensions. This would allow the community to experiment with new language features, making it cheaper & easier for Mathworks to see which language features gain traction. Mathworks would always have the option to include the most popular language extensions in a future release.

[Walter Roberson]

Questions...

A table() is a container. What would it mean to for i in MyTable ?

A hggroup() is a container. What would it mean to for i in a hggroup ?

A scalar struct is a container. Would for i in the scalar struct mean to iterate over the fields? Giving you the content of the fields? Giving you a scalar struct that contains just the one field?

A nonscalar struct is a container. Would for i in the nonscalar struct mean to iterate over the array elements (giving you one full struct at a time), or would it mean to iterate over the fields? Giving you a nonscalar struct that contains just the one field? Giving you a cell array of the contents of the field?

[Walter Roberson]

LISP keywords,

Switching the editor to be emacs ??

CAR and CDR as alternative functions instead of indexing?

Or do you mean that you would like MATLAB to support, for example,

show_members :a p :b 'q :c 2

as an alternative syntax for

show_members( a=p, b='q', c=2 )

complete with it being the value of p that would be passed in to show_members, even though at present MATLAB's command-function equivalence would currently treat that call as

show_members(':a', 'p', ':b', '''q', ':c', '2')

in which all of the elements are treated as character vectors ?

... I think there would be conflicts with the existing use of : as the range operator, if you are going to start interpolating values from text...

[Andrew Janke]

A thought on tables specifically: From a SQL/relational algebra standpoint, and how it's done in Python, a table/dataframe is a container that holds a list of tuples (records or rows), and iterating over a table iterates over records, which are presented as something that looks in Matlab terms like a scalar struct array. That operation is kind of opposed to the array-oriented, vectorized (or "column-store") nature of (fast, idiomatic) Matlab code for data structures like this. I'm not sure that encouraging interation-oriented programming though convenience functions or syntax is necessarily a good idea for Matlab "containers" like this. I think we might want to lean more towards APIs that encourage the use or creation of vectorized or array-oriented operations, and push interation requirements out to the user-defined code you want to apply to tables and similar containers.