Does 1.*2 call times or mtimes?

2 views (last 30 days)
Daniel Shub
Daniel Shub on 3 Jun 2013
Following on from Jan's question about puzzling syntax. It is clear from the documentation that a*b is equivalent to mtimes(a,b) and a.*b is equivalent to times(a,b) as those are the only possible valid parsings. Similarly, 1*2 must be equivalent to mtimes(1,2) and the oddly, but perfectly valid, 1..*2 (yes, there are two dots in the expression) must be equivalent to times(1,2) since they are the only valid ways of parsing the expressions. What I cannot find is where in the documentation it says that
should be parsed as
You can check this by overloading times and mtimes to be
function varargout = mtimes(varargin)
[varargout{1:nargout}] = builtin('mtimes', varargin{:});
function varargout = times(varargin)
[varargout{1:nargout}] = builtin('times', varargin{:});
and place the overloaded functions in a folder called @double.
I naively, and correctly, assumed that 1.*2 would be times(1,2), but this was before I realized that 1..*2 was valid. The precedence documentation doesn't say what the precedence of numbers are, but I always assumed they had the highest precedence and should be parsed first. While presumably this behavior doesn't really matter as it would only surface when times and/or mtimes are overloaded and data are being read-in in an odd format that gives rise to the horrendous 1. notation, but is this behavior documented?
As a follow up, I also thought that there should be a slight performance difference between mtimes and times due to differences in error checking (but I don't see one).
One possible explaination of the behavior is that operators have a higher precedence then numbers. If this is true, then I would expect functions to also have a higher precedence than numbers. To test this I created the following two functions
function d = e(f)
d = f;
function d = ee(f)
d = f;
If I call ee(1ee2) I get "Error: Unexpected MATLAB operator.", but if I call e(1e2) I get 100.0. I expected the same operator error.
Jan on 11 Jun 2013
@Walter: Randy cares about the ordering already.

Sign in to comment.

Answers (2)

Jan on 10 Jun 2013
Edited: Jan on 10 Jun 2013
Now with a fresh setup Matlab 2011b and with Daniel's @double/times and @double/mtimes:
>> 2*3
ans =
>> 2.*3
times % ??????? This is "2 .* 3", I expetced "2. * 3"
ans =
>> 2.0*3
ans =
Wow, Daniel, I agree that this is weird. I'd expect the numbers to be parsed with the highest priority. But obviously the * character has the power to grab the dot for its own personal purpose.
Note that "2.*3" is valid C syntax, but let be stress the answer of the technical support again: All formats supported by format are documented, while omitting zeros before and after the dot are not documented:
.1, 1. % working, ugly, confusing and not documented

Jan on 3 Jun 2013
Edited: Jan on 3 Jun 2013
Fortunately the results of
2 .* array
2. * array
are identical in Matlab, such that only your smart method to overlaod the times() reveal what happens. In opposite to Matlab, the trailing dot matters in C, because "2." is a floating point constant, while "2" is an integer there.
I think, the complete parsing of the number has the highest precedence. In "2..*2" the 2nd dot indicates, that the number has been read completely, as e.g. in "2.+2". Therefore Matlab's behaviour is intuitive and clear in my opinion. Because this is the reason, why this is not documented (or at least not in a place where I could find it).
But because I do not like to let the readers of my code guess any details, I add spaces before and after every operator.
I've contacted the technical support, because I did not find the location in the docs, where the validity of "2." and ".2" in Matlab code is explained, as well as the accepted exponent characters, e.g. that 2d3 is supported and how many leading zeros the exponent can have.
Another idea: Perhaps the parsing of the dot does not have a higher precedence than the mtimes-operator, but the rule of processing from left to right matters.
Btw.: I've wondered how the continuation mark handles this:
c = 2... % invalid, because this is parsed as "2. .."
d = 2.... % valid
This is another example of the difficulties of the syntax highlighting.
Jan on 4 Jun 2013
Perhaps I've confused something. Please let me perform further investigations under different Matlab versions in the evening (in 10 hours).
Btw., the reply of the technical support was not very detailed: The formats supported by the function format are guaranteed, all other formats are not. This would concern e.g. these constants:
Beside the spaces, I avoid .1 and 1. als and write the more clearly 1.0 and 0.1 .

Sign in to comment.

Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!