Я подозреваю, что это связано с тем, как анализируются числовые литералы.В частности, рассмотрим следующие сложные примеры:
>> [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
Существует конфликт между пробелом как разделителем массива и пробелом как частью комплексного числа.
Я считаю, что парсер был написан такчто он пытается разобраться в комплексных числах (по сравнению со сложными массивами) настолько разумно, насколько это возможно.Это может легко привести к нетривиальному поведению при разборе выражений, включающих сложение / вычитание и пробел.
Чтобы быть немного более конкретным:
1 ++ 2
может анализироваться как 1 +2
, поскольку множественные унарные плюсы все еще являются унарным плюсом, а унарный плюс может действовать только на 2
.
Но 1 + + 2
может рассматриваться как 1 + (+ 2)
, где последний плюс потребляется как унарный плюс., оставляя 1 + 2
, который является единственным "сложным" числом.
Дальнейшее продолжение после пытливого комментария от @ Adriaan :
[...] [1 ++ + 2]
- это [1 2]
, но [1 + ++ 2]
- это 3
Поэтому мое правильное предположение состоит в том, что парсер перемещается справа налево.
[1 ++ + 2]
-> [1 ++ (+ 2)]
-> [1 ++ 2]
, против [1 + ++ 2]
-> [1 + (++ 2)]
-> [1 + 2]
.
Thisтакже подразумевает, что любая комбинация [1 + ...2]
(где в первом подключенном блоке плюсов есть только один плюс) даст вам [3]
, тогда как, если первый блок плюсов содержитдва или более вы получите [1 2]
.Несколько псевдослучайных тестов, казалось, подтвердили это поведение.
Конечно, пока MathWorks не сделает свой парсер открытым исходным кодом или документально подтвержденным, мы можем только догадываться.