Does 1.*2 call times or mtimes?

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

1.*2

should be parsed as

times(1,2)

You can check this by overloading times and mtimes to be

function varargout = mtimes(varargin)
  disp('mtimes');
  [varargout{1:nargout}] = builtin('mtimes', varargin{:});
end

and

function varargout = times(varargin)
  disp('times');
  [varargout{1:nargout}] = builtin('times', varargin{:});
end

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).

EDIT

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;
end

function d = ee(f)
  d = f;
end

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.

[Matt J]

What is the outcome of 1..*2 that you are seeing. Are you saying that it calls MTIMES instead of TIMES?

[Jan]

1..*2 is equivalent to 1.0 .* 2 and calls mtimes() in consequence.

[Daniel Shub]

I am saying that 1..*2 must be TIMES since it is the only valid thing. What I cannot figure out is why 1.*2 calls TIMES when it could just as easily (and possibly more consistently) call MTIMES.

[Matt J]

I am saying that 1..*2 must be TIMES since it is the only valid thing.

Jan seems to disagree with you. He claims that it calls MTIMES. Did you verify that 1..*2 is TIMES the same way you verified that 1.*2 is TIMES?

[Daniel Shub]

Jan is wrong 1.0 .* 2 uses TIMES as I think even Jan would expect.

[Matt J]

Well, all I can say is that I would hate for 1.*2 to call MTIMES when a.*2 calls TIMES. I'm glad operators are parsed with higher precedence than numbers.

[Jan]

Sorry, while Matlab calls exactly the function I expect, it does not call the function names as I expect. So I've confused "times" and "mtimes". It is just a difference of one character...

I meant: 1..*2 is equivalent to 1.0 .* 2 and calls the function, which is called for ".*" operator in all cases how ever this function is called.

@Daniel: "even Jan"? Does this mean "Jan would expect this also"? Or am I known for preferring the wrong solution usually?

[Daniel Shub]

@Jan, I used "even" to me "Jan would expect this also" trying to hint at the difficulties of explaining differences in functions that vary in a single letter and notation that involves a single "dot". Your English is better than you give yourself credit for.

[Jan]

@Daniel: Ok, then I understand the intention of this sentence.

You ask interesting questions. Thanks! I've looked into the list of contributors ordered by the number of questions and found a very strange ordering. I'd expect this list to be ordered more excatly. Let's ask Randy.

[Walter Roberson]

The 0's in the middle of that list of contributors appears to correspond to accounts which have had questions automatically deleted because they were spam.

I cannot quite account for some of the other orderings, but possibly questions that got Closed and autodeleted.

[Jan]

@Walter: Randy cares about the ordering already.

Answer 1

[Jan]

Now with a fresh setup Matlab 2011b and with Daniel's @double/times and @double/mtimes:

>> 2*3
mtimes
ans =
     6

>> 2.*3
times        % ???????  This is "2 .* 3", I expetced "2. * 3"
ans =
     6

>> 2.0*3
mtimes
ans =
     6

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

Answer 2

[Jan]

Fortunately the results of

2 .* array

and

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.

[Daniel Shub]

While I attempt to make good use of whitespace in my coding, I am beginning to hate the fact that I have to. So it appears that * will grab a leading . while .. will attempt to give it away suggesting that * has a higher "parsing precedence" than ..

[Jan]

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:

1e6
1.
.2

Beside the spaces, I avoid .1 and 1. als and write the more clearly 1.0 and 0.1 .