6
$\begingroup$

I'm confused as to why the following leads to unpacking of a PackedArray:

Needs["Developer`"]
On["Packing"]
a = ToPackedArray@{RandomReal[], RandomReal[]};
a // PackedArrayQ (* returns True*)

b f[a]
b + f[a]

Both of the last commands produce a FromPackedArray::unpack warning, specifically:

FromPackedArray: Unpacking array in call to Times.

and

FromPackedArray: Unpacking array in call to Plus.

(And one can verify that in the produced output a is no longer a PackedArray e.g. using PackedArrayQ[(b + f[a])[[2, 1]]].)

This was tested in Mathematica 12.1. In Mathematica 12.3, the above code does not lead to unpacking. However, if b is replaced by a number, for example 2 f[a] and 2 + f[a], then unpacking occurs in version 12.3 as well. No unpacking occurs in 12.3 when b is replaced by an extact numerical quantity (that is not an integer) such as inSqrt[2] + f[a]


This behaviour to me is unexpected. Since a is inside the f wrapper, I would not expect a to interact with the Plus and Times operations. If anybody can shed some light on why this happens, I would be most grateful. Even better would be tips on how to shield the PackedArray from unpacking in this type of situation.

$\endgroup$
7
  • $\begingroup$ I do not get the unpacking message with your example. I used M12.3 on macOS, tried in a fresh kernel. $\endgroup$
    – Szabolcs
    Jun 23, 2021 at 8:19
  • $\begingroup$ I can echo @Szabolcs' comment, M12.3 on Win 10. $\endgroup$
    – ciao
    Jun 23, 2021 at 8:19
  • $\begingroup$ @Szabolcs Interesting, I'll try some different versions. This was on 12.1 on Windows $\endgroup$
    – TimRias
    Jun 23, 2021 at 8:20
  • $\begingroup$ I can indeed reproduce this in 12.1. $\endgroup$
    – Szabolcs
    Jun 23, 2021 at 8:29
  • $\begingroup$ I can reproduce the same problem in 12.3 with 1 + f[a] but not with b + f[a]. Additionally, (1 + f[a])[[2, 1]] // PackedArrayQ is False and (b + f[a])[[2, 1]] // PackedArrayQ is True in M12.3, consistent with the unpacking message. Can you update the question with this new info @mmeent, or is it okay if I make the edit? $\endgroup$
    – Szabolcs
    Jun 23, 2021 at 8:32

1 Answer 1

5
$\begingroup$

I do not know why this happens, but I know of ways to prevent it. I ran into a very similar problem while working on the BoolEval package:

Unfortunately, I do not recall the details, but I said in a comment under that question that WRI responded to me about the issue (I can't find the exchange anymore) and the ultimate conclusion was that this behaviour is unlikely to change due to how the system is designed. Sorry for not being able to recall more.

Some ways to get around the problem:

Presumably, eventually you will give b and f definitions, and let the arithmetic expression evaluate.

Until you do that, you may keep the expression held: Hold[b + f[a]] does not unpack. This is what I use in BoolEval.

Alternatively, the value of the array variable can be removed for the time while you manipulate the arithmetic expression: Block[{a}, manipulate[ b + f[a] ] ]. In this example, I expect that by the time manipulate finishes, b and f will have definitions. The value of a will be inserted only afterwards.

$\endgroup$
1
  • $\begingroup$ Thanks. I don't this particular work around will help my current purpose, but the improved behaviour of 12.3 seems sufficient for the moment. $\endgroup$
    – TimRias
    Jun 23, 2021 at 12:03

Your Answer

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

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