23
$\begingroup$
  1. The following code in Mathematica 11:

    iList = {i, -10, 10, 2};
    Table[i, iList]
    

    produces this result:

    {i, i, i, i}
    
  2. Where in version 10 (and presumably earlier versions) it produced an error:

    Table::itform: Argument iList at position 2 does not have the correct form for an iterator. >>

Note that WRI have stated in an email to a colleague that the code in 1, is not valid syntax.

Can we consider this a bug?

$\endgroup$
  • 1
    $\begingroup$ Indeed it is not valid syntax. That is why I would expect a clear error message, not random behaviour. $\endgroup$ – Szabolcs Aug 16 '16 at 10:00
  • 3
    $\begingroup$ Use the magic cookie Evaluate iList = {i, -10, 10, 2}; Table[i, Evaluate@iList] to tell the kernel to call up iList $\endgroup$ – Conor Cosnett Aug 16 '16 at 10:04
  • 3
    $\begingroup$ Actually after thinking about it I disagree that this is not valid syntax. My personal opinion is that it was simply a very bad idea to allow the syntax Table[expr, n] (since version 10.2) because it has created ambiguity. $\endgroup$ – Szabolcs Aug 16 '16 at 10:21
  • $\begingroup$ The issue is (at least partially) addressed in the documentation for Table under the section Possible Issues where a somewhat similar example is given using With and Block. Note that With[{ iList = {i, -10, 10, 2} }, Table[i, iList] ] will work. $\endgroup$ – gwr Aug 16 '16 at 11:07
  • $\begingroup$ There too is Table[i, #] &[iList] $\endgroup$ – Coolwater Aug 16 '16 at 20:45
25
$\begingroup$

This is just a long comment trying to shed light on where the problem may be coming from.

Since version 10.2, the following is valid syntax:

Table[x, 5]

Before we could only use

Table[x, {5}]

or

Table[x, {i, 5}]

This implies that we should expect the following to work too:

n=5;
Table[x, n]

the same way as Table[x, {n}] or Table[x, {i, 1, n}] work too.

As @Kuba pointed out, it seems that when n is not set to a number, but to a list, Table uses the length of the list as the number of times to repeat.

Even in version 10.4.1, we get

n = {1, 2, 3};
Table[x, n]

(* {x, x, x} *) 

n = {y, y, y, y, y, y};
Table[x, n]

(* {x, x, x, x, x, x} *)

What could the reason be?

The simplest explanation is that Table[expr, n] maps directly to Table[expr, {i, n}]. You'll notice that the following form is valid too:

Table[expr, {i, {val1, val2, ...}}]

i will simply take val1, val2, ... in turn.

And this is exactly what seems to be happening here. The mapping to the Table[expr, {i, n}] form is carried out even if n is a list. This seems incorrect because Table[expr, n] is documented only for the cases when n is an integer.

My personal conclusion, which others may disagree with, is that it was a bad idea in the first place to allow the syntax Table[expr, n] when we already had the equally short Table[expr, {n}]. Allowing this has created ambiguity in the syntax. [Update: Actually, looking at older documentation, it seems that Table[expr, {n}] was replaced with Table[expr, n] as the official syntax.]

For the reasons stated above I also disagree with Wolfram Support that Table[i, iList] is invalid syntax when iList is a symbol (possibly with a value). The syntax seems valid, the question is what values are appropriate for iList?

Table[expr, {i, n}] is documented syntax and has worked for a long time when n had the value of either an integer or a list. Table[expr, n] is also documented syntax. It is implied in the documentation that in this latter case n should be an integer, but it is not at all clear that it cannot be a variable with an integer value.


These kinds of ambiguities in syntax do appear from time to time in Mathematica. The reason is that lists are commonly used both as part of syntax (as in Table[expr, {i,1,10}]) and as a collection of data. It would seam to me that given this situation, extreme care is necessary when designing and extending the Wolfram Language.

Another example of such an ambiguity is Lookup, which allows both Lookup[asc, key] and Lookup[asc, {key1, key2, ...}]. What if a key is a list? That is not uncommon. At least we have the disambiguator head Key.

Yet another example which appears to allow for ambiguity is Extract, where all of these forms are allowed: Extract[expr, 1], Extract[expr, {1,2}], Extract[expr, {{1}, {2}}], Extract[expr, {{1, 2}}]. Can you tell me quickly what each one does, without trying? But aside from some potential minor confusion to the user, I think that there is no problem with Extract. It is always easy to disambiguate, keeping in mind that a proper position specification is always a depth-1 list, and also thanks to the fact that Extract is not HoldAll.

One might argue that what yo observe with Table is not a bug because once we understand the rules, we can see what is happening, just like with Extract. Personally I still think that even allowing this syntax for the more complex case of Table (which is HoldAll and which localizes its iterator) was a mistake. We might as well call the decision a bug. This is admittedly a debatable, subjective opinion, so I won't tag the post as .

$\endgroup$
6
$\begingroup$

The above analysis is quite correct. I also don't disagree that the decision to not require braces was questionable. I spent quite a period of time in this spring analyzing the design issues introduced by this change and how to resolve them. The basic issue is that with the list syntax, the first argument is never evaluated unless it is the only argument. This way the variable can be localized, protected from any global values (very important). All the other entries in the list are evaluated, because we need to know where to start and end. That's why a variable as an endpoint or list to take values from always worked.

Now, what about expressions with no explict list? If we first evaluate the non-list argument, we risk contaminating the variable. If we just wrap it in a list a hope for the best, we get the odd behavior described above. So we finally settled on: if the expression does not have a list structure, it must evaluate to a real numberic value. So the new behavior in 11.2 will be

In[1]:= iList = {i, -10, 10, 2};
Table[i, iList]
During evaluation of In[1]:= Table::nliter: Non-list iterator iList at position 2 does not evaluate to a real numeric value.
Out[2]= Table[i, iList]

I have also updated and clarified the documentation on this point, in particular that Possible Issues example mentioned above that really made no sense with the 10.2--11.1 behavior.

Thanks for bringing this to our attention so we can make it better, even if it took a little while for it to propogate to the right people to fix it.

$\endgroup$
  • $\begingroup$ Having a note in the documentation about the syntax change would be helpful. I just ran into this issue. I've been learning to use Mathematica on my laptop with variants of version 11, but I'm submitting my code to run on a linux cluster which has version 10.1. I ran into errors using the syntax Table[0, 4]. I could see from the documentation that a change had been made in version 10.2, but I couldn't see what the change was. A short note describing the older syntax would have sufficed for helping me track down the issue, but instead I had to come to stack exchange. $\endgroup$ – FalafelPita Oct 7 '17 at 19:00

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.