6
$\begingroup$

According to the official documentation of Times[], multiplication of $x$ and $y$ is represented as one of

  • x*y

  • x×y

  • x y

  • Times[x, y]

However, in practice I can write 2x instead of 2 x, and (1+x)(1+y) instead of (1+x) (1+y).

I think this behavior contradicts with the documentation. Is this a bug? Or is this an expected behavior? I'm looking for an official source to determine that.


Please note:

This is a question that would be tagged "language-lawyer" if posted on other stackexchange sites. Because Mathematica is not an open-source software, we have no way other than official articles to rely on to determine whether or not some non-trivial syntax is an expected one. I would like to ask is

Is there a document page that tells us 2x is valid?

$\endgroup$
  • 2
    $\begingroup$ It seems useful that 2x is 2*x; for one thing it's common in mathematical expressions, also, since identifiers cannot start with numbers (as in most languages) there's no other obvious way to parse it. $\endgroup$ – lirtosiast Aug 11 at 8:47
  • 6
    $\begingroup$ I think the reason is simply that 2x cannot be interpreted as a symbol since symbol names cannot start with a number by convention (a convention shared by many languages). There is no ambiguity about what 2x means because of that, so that's why it can be valid syntax. $\endgroup$ – Sjoerd Smit Aug 11 at 10:40
  • 3
    $\begingroup$ I don't see where 2x contradicts the documentation, which itself contains the examples 0x and 0.0x, as well as 2{x,y,z} and {{a,b},{c,d}}{x,y} which don't contain spaces. It says "Enter Times with spaces," but that's one alternative. The documentation is notoriously incomplete. For instance, it tells you that 2 x is sufficient to enter Times[2,x], but it does not tell you whether the space is necessary. That the documentation is not a complete definition of the language does seem a valid criticism, but the documentation isn't meant to be one. $\endgroup$ – Michael E2 Aug 11 at 15:03
  • 10
    $\begingroup$ I am reopening this, but I also think the OP's energies are not well-spent on worrying about this matter. $\endgroup$ – J. M. will be back soon Aug 12 at 9:08
  • 3
    $\begingroup$ Why does this sort of pedantry matter .... ? $\endgroup$ – user6014 Aug 12 at 15:05
17
$\begingroup$

From Your First Wolfram Language Calculations:

2x means 2*x.

Examples of no-space multiplication from Times:

0x evaluates to 0, and 0.0x evaluates to 0.0.
...
Times threads element-wise over lists:

In[1]:= 2{x,y,z}
Out[1]= {2 x,2 y,2 z}
In[2]:=  {{a,b},{c,d}}{x,y}
Out[2]= {{a x,b x},{c y,d y}}

Update: As Sjoerd notes, according to Symbol, a symbol name cannot begin with a digit. This implies 2x would either be a syntax error or not; if not, then what? The standard mathematical interpretation is an obvious choice. J.M. notes further that it would be confusing to have symbol names begin with a number. I'm not sure this all captures the argument in the most natural way. I think humans do a pretty good job getting used to whatever the rules are, and identifiers starting with a number wouldn't be that bad. I think the starting point for the argument is that it was desired from the beginning to interpret 2x as Times[2,x], which implies you cannot have symbols start with a number (which nobody wants anyway, if I may alter J.M.'s remark a little). But now we're wading into the opinion-based territory for which this Q&A was originally closed. It's also clear that (almost) everyone wants xy to be interpreted as Times[x,y], but that poses lexical analysis problems that couldn't be solved satisfactorily.

$\endgroup$
  • $\begingroup$ Thank you. The first reference answers my question. However, in the documentation of Times, there is a space between 2 and {x, y, z}, & between } and {x,y}. In addition, the documentation says not {x,y} but {x, y}. As you may know, you can cite the documentation by using the functionality Copy to clibboard.. Anyway, could you please edit to remove the latter part of your answer (the part after "..." is not related to my question)? $\endgroup$ – ynn Aug 12 at 7:31
  • 1
    $\begingroup$ You could add the following remark from the "Details" section of Symbol: "The string "name" in Symbol["name"] must be an appropriate name for a symbol. It can contain any letters, letter-like forms, or digits, but cannot start with a digit.". In other words: 2x cannot really mean anything other than Times[2, x]. The only alternative would be to raise a syntax error, which would be unnecessarily pedantic since there's no ambiguity. $\endgroup$ – Sjoerd Smit Aug 12 at 9:05
  • 1
    $\begingroup$ As Sjoerd notes, I see no reason why one would wish for a symbol that starts with a number; it would be quite confusing. $\endgroup$ – J. M. will be back soon Aug 12 at 9:10
  • $\begingroup$ @J.M.isaway I believe it's also a thing about parsing. If you have the convention that symbols can start with numbers, parsing code becomes more expensive because you don't know in advance if you're dealing with a symbol or a number. In the worst-case scenario you'd have to read all characters till the next white space/delimiter to know if you're dealing with a number or a symbol. Not sure how much this matters in WL, but this is a concern in other languages, from what I understood. $\endgroup$ – Sjoerd Smit Aug 12 at 10:40
  • $\begingroup$ @SjoerdSmit It's certainly more expensive, but I doubt it's a significant expense. It may have been when M was first developed. The code being parsed in M is probably comparatively small in most cases. $\endgroup$ – Michael E2 Aug 12 at 10:53
9
$\begingroup$

It is not a bug.

See for example the documentation of Mathematica 2 chapter 1.1.6 :

...It also allows multiplication to be indicated without an explicit * or other character. As a result, Mathematica can handle expressions like 2x and a x or a (1+x) , treating them just as in standard mathematical notation

This is also written in the other Mathematica books (The last one is for Mathematica 5.2)

$\endgroup$
  • 1
    $\begingroup$ Darn, I looked for this in my hardcopy but missed it. The form shows up in many code examples, also in the first edition, but I couldn't find this. (+1) $\endgroup$ – Michael E2 Aug 13 at 10:53
6
$\begingroup$

No, you are right; there "does not seem to be a document page that tells us that "2x is valid"" but there should be (if not a page, a line of clarification). If it is good enough for the documentation to confirm the mathematically obvious 0x = 0 then one might reasonably expect that it also be good enough to state:

  • cx parses to Times[c, x] when c appears as an atomic, real number (but not as basic constants like \[Pi] and E).

With such an insertion it becomes clear, for example, why (possibly against initial expectations) each member of

enter image description here

does not evaluate to 0 unlike the expression

enter image description here

The last example illustrates how "mathematical obviousness" is not always the clear, disambiguating arbiter that might be initially presumed. This is further reinforced by the following elements not evaluating to 0 in apparent disregard of multiplicative commutativity (despite Times being Orderless) and BIMDAS' precedence rules (despite Times's parsing generally conforming to it):

enter image description here

Of course, the above exemplifies the extra challenges faced by a computational system compared with traditional mathematical notation but it is also an argument for the importance of documentation clarity. While the particular case 2x does appear elsewhere in the documentation, it is not foreshadowed in the initial specifications (as redundant as this may appear to experienced users) nor does its particular appearance necessarily infer the more general case.

The instructiveness of the OP's question seems to be less about the number 2, a little more about how numbers/letters are parsed to the (fundamental) Times operation but most of all it seems to be about users' relationship to the Help Documentation. The OP's question is probing to what extent the documentation should be taken as a formal description of the WL. The remarkable aspect of WL's documentation is how closely it does come to describing a formal grammar while retaining a natural expressiveness and consistency. Part of this involves completeness together with pedagogically progressing from the general to the particular and a general awareness of this constancy, IMO, invariably holds new users in good stead.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.