为什么加号和一元加号在数组语法上会表现出奇怪的现象? [英] Why do the plus and unary plus behave strange in array syntax?

查看:161
本文介绍了为什么加号和一元加号在数组语法上会表现出奇怪的现象?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

关于plus运算符的问题之后,我有一个后续问题.我们知道 plus uplus ,因此1+2解析为3 ,就像1++2甚至1++++++++2一样.奇怪的事情发生在数组语法中,请考虑以下示例:

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, just as 1++2 or even 1++++++++2. The strange thing happens in array syntax, consider this example:

>> [1 ++ 2]
ans =
     1     2 % Two unary plusses
>> [1 + + 2]
ans =
     3 % A normal plus and a unary one
>> [1++2]
ans =
     3 % A normal plus and a unary one

相同的方法适用于多个加号[1 +++..+++ 2],因此所有加号在中间连续产生[1 2],所有其他组合(据我测试)均为3.

The same works with multiple plusses, [1 +++..+++ 2], so with all plusses consecutively in the middle generates [1 2], all other combinations (as far as I tested) result in 3.

据我所知,空间在MATLAB中的重要性有限; exp(3*x/y)exp( 3 * x / y )相同.它们在创建数组中有一个用途:[1 2]会生成1个 -by- 2数组,还有其他一些用途,但是分隔运算符不是其中之一.

As far as I know spaces are of limited importance in MATLAB; exp(3*x/y) is the same as exp( 3 * x / y ). There is a use for them in creating arrays: [1 2] will generate a 1 -by- 2 array, and there are a few other uses, but separating operators is not one of them.

因此,我的问题是:为什么[1 ++ 2][1 + + 2]的解析方式不同?

Therefore my question: Why do [1 ++ 2] and [1 + + 2] resolve differently?

请注意, minus uminus 具有相同的行为,并且解析器非常神奇,足以将[1;;;3++ + + +--+ + ++4,;;;,;]解析为[1;7].

Note that the minus and uminus have the same behaviour, and that the parser is magic enough to parse [1;;;3++ + + +--+ + ++4,;;;,;] perfectly fine to [1;7].

推荐答案

我怀疑这与解析数字文字有关.特别是,请考虑以下复杂的示例:

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.

更具体一点:

1 ++ 2可能会解析为1 +2,因为多个一元加号仍然是一元加号,并且一元加号只能对2起作用.

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.

但是1 + + 2可能解析为1 + (+ 2),后者的加号被用作一元加号,而剩下的1 + 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.

[...] [1 ++ + 2][1 2],但是[1 + ++ 2]3

所以我的正确猜测是解析器从右移到左.

So my proper guess would be that the parser moves from right to left.

  • [1 ++ + 2]-> [1 ++ (+ 2)]-> [1 ++ 2],与
  • [1 + ++ 2]-> [1 + (++ 2)]-> [1 + 2].
  • [1 ++ + 2] -> [1 ++ (+ 2)] -> [1 ++ 2], versus
  • [1 + ++ 2] -> [1 + (++ 2)] -> [1 + 2].

这也意味着[1 + ...2]的任何组合(在第一个连接的加号中只有一个加号)将为您提供[3],而如果第一个加号中包含两个或多个,您将得到[3] c7>.一些伪随机测试似乎可以验证这种行为.

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.

当然,在MathWorks将其解析器开源或记录下来之前,我们只能猜测.

Of course until The MathWorks makes their parser open-source or documented we can only guess.

这篇关于为什么加号和一元加号在数组语法上会表现出奇怪的现象?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆