I am defining a sparse array as a function of argument x, i.e.

f[x_] = SparseArray[{1->x}, {3}]

In Mathematica 12 this works perfectly, I can pass arguments and they will be substituted to the array. For example,


returns a sparse array with 1 at its first element. However, in Mathematica 13 the passed argument is ignored: the first element is allways x. Is it a bug?

Here is a screenshot for v12:

enter image description here

And for v13:

enter image description here

  • 3
    $\begingroup$ I believe this is an intentional change. Just use SetDelayed instead of Set. $\endgroup$
    – Carl Woll
    Jan 25, 2022 at 20:06
  • 4
    $\begingroup$ SparseArray is an atomic expression. That means that there are no guarantees about the behaviour in such a situation. While this kind of thing should definitely be better documented, I would not blame Wolfram for the change. Relying on this behaviour was taking a big risk. $\endgroup$
    – Szabolcs
    Jan 25, 2022 at 20:57
  • 2
    $\begingroup$ "Atomic" means that it doesn't really have parts, even if it appears so. The x symbol is not part of a SparseArray in the same way that it would be a part of a compound expression, such as a List. It's no surprise that it won't be interpreted as a pattern name. Personally, I would not have relied on this behaviour, even though I do rely on undocumented functionality when it seems necessary. This seems more risky to me, than long-standing undocumented functions. $\endgroup$
    – Szabolcs
    Jan 25, 2022 at 22:21
  • 2
    $\begingroup$ [1 / 2] I will join Szabolcs here: in this context, being atomic for an object means that it may break variable bindings at will. Once an object is evaluated, any bound variables inside it (like x here) may lose their bindings and therefore will not be affected in subsequent function calls with different concrete values of x passed. Same happens also with associations, for example. SetDelayed works for a different reason: the new rule created by it contains atomic / raw object constructor on the r.h.s., rather than a fully formed object. Constructors may look the same syntactically, ... $\endgroup$ Jan 26, 2022 at 0:55
  • 2
    $\begingroup$ [ 2 / 2 ] ... but they, in contrast to fully formed raw objects (which live in the kernel and only imitate their FullForm), are actually normal expressions and obey more usual rules. In particular, the variable bindings are kept intact, just as for any normal expression. I have discussed this problem in slightly different context in my answer here, but actually this particular behavior may need a dedicated answer. $\endgroup$ Jan 26, 2022 at 1:00


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.