Add admonition concerning array view mutation #420
Conversation
There was a problem hiding this comment.
The change LGTM, modulo my one comment, and is in line with what we discussed last week. This makes it easier to later on require raising an exception - possibly in a "strict" mode which guarantees portability.
Let me ping @apaszke and @shoyer for visibility, given that this is especially relevant from JAX's perspective.
|
As this has been reviewed and was discussed and approved in the consortium meeting held on 2022-04-21, will merge. |
| .. admonition:: Mutating views | ||
| :class: important | ||
|
|
||
| Array API consumers are *strongly* advised to avoid *any* mutating operations when an array object may be either a "view" (i.e., an array whose data refers to memory that belongs to another array) or own memory of which one or more other array objects may be views. This admonition may become more strict in the future (e.g., this specification may require that view mutation be prohibited and trigger an exception). Accordingly, only perform mutation operations (e.g., in-place assignment) when absolutely confident that array data belongs to one, and only one, array object. |
There was a problem hiding this comment.
Does the standard actually specify any in-place operations? I expect that those will be impossible to implement in JAX unless we wrap all our immutable arrays in a layer of indirection that tries to mimic the NumPy-style aliasing rules.
There was a problem hiding this comment.
No it doesn't specify that any operation must be in-place, because those are indeed not possible to implement for at least JAX and TensorFlow. It does specify syntax like +=, which the wording here tries to refer to. But it's probably worth tweaking that wording, since I guess you were concerned about the phrases "mutating operations" "(in-place assignment)"?
There was a problem hiding this comment.
Right, I guess my main concern is that at the moment the standard says "only perform mutation operations (e.g., in-place assignment) when absolutely confident that array data belongs to one, and only one, array object.". But how can one be confident about this when they're writing library polymorphic code, which as far as I understand is the point of the standard?
There was a problem hiding this comment.
I don't think this is hard in many specific cases. It's normally a bug in library code to mutate any inputs to a function, so it's a common pattern to make a copy before doing an operation in-place. Or it's done on arrays that are created within the function (e.g. create an empty output array of the correct shape, then fill it).
To be clear: I don't expect this to be the final state. We want to require raising exceptions when this requirement is met, it's just a significant amount of work to implement the required machine for this in NumPy et al. (rough estimate for NumPy: one person-month) so we can't do it right now.
This PR