Following this question on the plus operator I have a follow-up question. We know the difference between plus and uplus, and thus that 1+2
resolves to 3
My suspicion is that this has to do with how numeric literals are parsed. In particular, consider the following complex examples:
>> [1+2i]
ans =
1.0000 + 2.0000i
>> [1 +2i]
ans =
1.0000 + 0.0000i 0.0000 + 2.0000i
>> [1 + 2i]
ans =
1.0000 + 2.0000i
There's a conflict between space as an array separator and space as a part of a complex number.
I believe the parser was written such that it tries to make sense of complex numbers (versus complex arrays) as reasonably as possible. This can easily lead to non-trivial behaviour in parsing expressions involving addition/subtraction and whitespace.
To be a bit more specific:
1 ++ 2
might parse as 1 +2
, since multiple unary pluses are still a unary plus, and a unary plus can only act on the 2
.
But 1 + + 2
might parse as 1 + (+ 2)
where the latter plus is consumed as a unary plus, leaving 1 + 2
which is a single "complex" number.
A further follow-up after an inquisitive comment from @Adriaan:
[...]
[1 ++ + 2]
is[1 2]
, but[1 + ++ 2]
is3
So my proper guess would be that the parser moves from right to left.
[1 ++ + 2]
-> [1 ++ (+ 2)]
-> [1 ++ 2]
, versus[1 + ++ 2]
-> [1 + (++ 2)]
-> [1 + 2]
.This would also imply that any combination of [1 + ...2]
(where there is only one plus in the first connected block of pluses) will give you [3]
whereas if the first block of pluses contains two or more you will get [1 2]
. A few pseudorandom tests seemed to verify this behaviour.
Of course until The MathWorks makes their parser open-source or documented we can only guess.