8000 ENH: Break the assumption that all ufuncs and gufuncs want is element-wise loop aliasing · Issue #11416 · numpy/numpy · GitHub
[go: up one dir, main page]

Skip to content

ENH: Break the assumption that all ufuncs and gufuncs want is element-wise loop aliasing #11416

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

Closed
mattip opened this issue Jun 25, 2018 · 4 comments

Comments

@mattip
Copy link
Member
mattip commented Jun 25, 2018

The current implementation of both ufuncs and gufuncs (those with core-dimensions and an inner-loop signature) use the NPY_ITER_OVERLAP_ASSUME_ELEMENTWISE flag to prevent allocating buffer memory if it can be determined that:

  • the data pointers of all overlapping operands are equal
  • the strides and dimensions are equivalent
  • the dtypes are equal.
  • solve_may_have_internal_overlap() for single-byte overlap returns `0

Let's call this element-wise aliasing, since it is intended for elementwise ufuncs like np.sin.
For all other cases, output ndarrays will use writeback semantics to allocate temporary memory.

There should be a point in the gufunc call that a gufunc can say "element-wise aliasing is OK", or "leave all aliasing to the inner loop" or "always copy-on-any-overlap". We need a flag to indicate these (and maybe other, like contiguous) strategies. See also PR #11381 (closed) which proposed unilaterally changing the default.

@njsmith
Copy link
Member
njsmith commented Jun 25, 2018

I'm not sure, but my initial impression is that the two relevant cases are: (1) the loop can tolerate some core inputs being identical to some core outputs, (2) the loop can't tolerate overlap at all. For cases where there's partial overlap between core dimensions, or overlap between different loop iterations, then maybe we should unconditionally copy? Are there any other interesting cases?

@pv
Copy link
Member
pv commented Jun 25, 2018 via email

@pv
Copy link
Member
pv commented Jun 25, 2018 via email

@mattip
Copy link
Member Author
mattip commented Dec 1, 2018

Allowed overriding the ufunc flags in #11580

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants
0