On Mon, 2022-12-12 at 18:20 -0500, Warren Weckesser wrote:
On 12/12/22, Aaron Meurer <asmeurer@gmail.com> wrote:
On Mon, Dec 12, 2022 at 8:46 AM Sebastian Berg <sebastian@sipsolutions.net> wrote:
On Wed, 2022-12-07 at 14:21 -0700, Aaron Meurer wrote:
Hi all.
As discussed in today's community meeting, I plan to start working on adding some useful functions to NumPy which are part of the array API standard https://data-apis.org/array-api/latest/index.html.
Although these are all things that will be needed for NumPy to be standard compliant, my focus for now at least is going to be on new functionality that is useful for NumPy independent of the standard. The things that I (and possibly others) plan on working on are:
Generally, I don't have much opinion on these, most seem fine to me. The pure aliases/shortforms, I feel should maybe be discussed separately.
* `np.linalg.matrix_transpose` (basically an alias/replacement for `np.linalg.transpose). (No strong opinion from me, the name is a bit clearer.) Are you proposing to add `np.linalg.matrix_transpose` or also `np.matrix_transpose`?
The spec has the function in both namespaces, so that is the proposal (my PR https://github.com/numpy/numpy/pull/22767 only adds it to linalg for now because I wasn't sure the correct way to add it to np).
* `ndarray.mT`, I don't have an opinion on it. At some point I would have preferred transitioning `ndarray.T` to be this, but...
* Named tuples for tuple results (in linalg, such as `eigh`). I suppose this should be backwards compatible, and thus a simple improvement.
* vecdot: I guess we have vdot, but IIRC that has other semantics so this mirrors `matmul` and avoids multi-signature functions. (It would be good if this is a proper gufunc, probably).
* copy=... argument for reshape. I like that. An important step here is to also add a FutureWarning to the `copy=` in `np.array()`.
* `matrix_norm` and `vector_norm` seem OK to me. I guess only `matrix_norm` would be a proper gufunc unfortunately, while `vector_norm` would be almost the same as norm. In either case `matrix_norm` seems a bit tedious right now and `vector_norm` probably adds functionality since multiple axes are probably valid.
Why can't vector_norm be a gufunc?
IIUC, the proposed vectornorm supports an arbitrary number of axis. The ufunc does not unless I am missing some gufunc definition. - Sebastian
For what it's worth, I implemented vector norm and vector dot as gufuncs in ufunclab:
* https://github.com/WarrenWeckesser/ufunclab#vnorm * https://github.com/WarrenWeckesser/ufunclab#vdot
Warren
Aaron Meurer
- Sebastian
PS: For the `ndarray.H` proposal, "its complicated" is maybe too fuzzy: The complexity is about not being able to return a view for complex numbers. That is `.H` is:
* maybe slightly more expensive than may be expected for an attribute * different for real values, which could return a view * a potential problem if we would want to return a view in the future
So we need some answer to those worries to have a chance at pushing it forward unfortunately. (Returning something read-only could reduce some of those worries? Overall, they probably cannot be quite removed though, just argued to be worthwhile?)
- A new function matrix_transpose() and corresponding ndarray attribute x.mT. Unlike transpose(), matrix_transpose() will require at least 2 dimensions and only operate on the last two dimensions (it's effectively an alias for swapaxes(x, -1, -2)). This was discussed in the past at https://github.com/numpy/numpy/issues/9530 and https://github.com/numpy/numpy/issues/13797. See
https://data-apis.org/array-api/latest/API_specification/generated/signature...
- namedtuple outputs for eigh, qr, slogdet and svd. This would only apply to the instances where they currently return a tuple (e.g., svd(compute_uv=False) would still just return an array). See the corresponding pages at https://data-apis.org/array-api/latest/extensions/index.html fo r the namedtuple names. These four functions are the ones that are part of the array API spec, but if there are other functions that aren't part of the spec which we'd like to update to namedtuples as well for consistency, I can look into that.
- New functions matrix_norm() and vector_norm(), which split off the behavior of norm() between vector and matrix specific functionalities. This is a cleaner API and would allow these functions to be proper gufuncs. See https://data-apis.org/array-api/latest/extensions/generated/signatures.linal... and https://data-apis.org/array-api/latest/extensions/generated/signatures.linal... .
- New function vecdot() which does a broadcasted 1-D dot product along a specified axis
https://data-apis.org/array-api/latest/API_specification/generated/signature...
- New function svdvals(), which is equivalent to svd(compute_uv=False). The idea here is that functions that have different return types depending on keyword arguments are problematic for various reasons (e.g., they are hard to type annotate), so it's cleaner to split these APIs. Functionality-wise there's not much new here, so this is lower priority than the rest.
- New function permute_dims(), which works just like transpose() but it has a required axis argument. This is more explicit and can't be confused with doing a matrix transpose, which transpose() does not do for stacked matrices by default.
- Adding a copy argument to reshape(). This has already been discussed at https://github.com/numpy/numpy/issues/9818. The main motivation is to replace the current usage of modifying array.shape inplace. (side note: this also still needs to be added to numpy.array_api)
You can see the source code of numpy.array_api for an idea of what pure Python implementations of these changes look like, but to be clear, the proposal here is to add these to the main NumPy namespace, not to numpy.array_api.
One question I have is which of the new functions proposed should be implemented as pure Python wrappers and which should be implemented in C as ufuncs/gufuncs?
Unless there are any objections, I plan to start working on implementing these right away.
Aaron Meurer _______________________________________________ NumPy-Discussion mailing list -- numpy-discussion@python.org To unsubscribe send an email to numpy-discussion-leave@python.org https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ Member address: sebastian@sipsolutions.net
_______________________________________________ NumPy-Discussion mailing list -- numpy-discussion@python.org To unsubscribe send an email to numpy-discussion-leave@python.org https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ Member address: asmeurer@gmail.com
_______________________________________________ NumPy-Discussion mailing list -- numpy-discussion@python.org To unsubscribe send an email to numpy-discussion-leave@python.org https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ Member address: warren.weckesser@gmail.com
_______________________________________________ NumPy-Discussion mailing list -- numpy-discussion@python.org To unsubscribe send an email to numpy-discussion-leave@python.org https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ Member address: sebastian@sipsolutions.net