Skip to content

Add admonition concerning array view mutation #420

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
May 2, 2022
Merged

Add admonition concerning array view mutation #420

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
f1f1f86
Add admonition concerning array view mutation
kgryte Apr 21, 2022
11b2575
Update admonition
kgryte May 2, 2022
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 5 additions & 3 deletions spec/design_topics/copies_views_and_mutation.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -3,6 +3,11 @@
Copy-view behaviour and mutability
==================================

.. 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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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)"?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.


Strided array implementations (e.g. NumPy, PyTorch, CuPy, MXNet) typically
have the concept of a "view", meaning an array containing data in memory that
belongs to another array (i.e. a different "view" on the original data).
Expand Down Expand Up @@ -70,6 +75,3 @@ of reusing arrays that are no longer needed as buffers.
This leaves the problem of the initial example - with this API standard it
remains possible to write code that will not work the same for all array
libraries. This is something that the user must be careful about.

.. note::
It is recommended that users avoid any mutating operations when a view may be involved.