8000 Add section on copy-view behaviour and mutability by rgommers · Pull Request #66 · data-apis/array-api · GitHub
[go: up one dir, main page]

Skip to content

Add section on copy-view behaviour and mutability #66

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.

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
Nov 3, 2020
Merged
Changes from 1 commit
Commits
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
Prev Previous commit
Add note on tracing that may make implementing out= impossible.
  • Loading branch information
rgommers committed Nov 3, 2020
commit 2427d47f2fa290feb74dea2a0b6a92df5c0003f3
15 changes: 9 additions & 6 deletions spec/design_topics/copies_views_and_mutation.md
Original file line number Diff line number Diff line change
Expand Up @@ -57,12 +57,15 @@ The situation with `out=` is slightly different - it's less heavily used, and
easier to avoid. It's also not an optimal API, because it mixes an
"efficiency of implementation" consideration ("you're allowed to do this
inplace") with the semantics of a function ("the output _must_ be placed into
this array). There's alternatives, for example the donated arguments in JAX
or working buffers in LAPACK, that allow the user to express "you _may_
overwrite this data, do whatever is fastest". Given that those alternatives
aren't widely used in array libraries today, this API standard chooses to (a)
leave out `out=`, and (b) not specify another method of reusing arrays that
are no longer needed as buffers.
this array). There are libraries that do some form of tracing or abstract
interpretation over a language that does not support mutation (to make
analysis easier); in those cases implementing `out=` with correct handling of
views may even be impossible to do. There's alternatives, for example the
donated arguments in JAX or working buffers in LAPACK, that allow the user to
express "you _may_ overwrite this data, do whatever is fastest". Given that
those alternatives aren't widely used in array libraries today, this API
standard chooses to (a) leave out `out=`, and (b) not specify another method
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
Expand Down
0