On Mon, Dec 12, 2022 at 8:46 AM Sebastian Berg <sebast...@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? 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/signatures.linear_algebra_functions.matrix_transpose.html > > > > - 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 for 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.linalg.vector_norm.html > > and > > https://data-apis.org/array-api/latest/extensions/generated/signatures.linalg.matrix_norm.html > > . > > > > - 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/signatures.linear_algebra_functions.vecdot.html#signatures.linear_algebra_functions.vecdot > > > > - 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-le...@python.org > > https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ > > Member address: sebast...@sipsolutions.net > > > > > > > _______________________________________________ > NumPy-Discussion mailing list -- numpy-discussion@python.org > To unsubscribe send an email to numpy-discussion-le...@python.org > https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ > Member address: asmeu...@gmail.com _______________________________________________ NumPy-Discussion mailing list -- numpy-discussion@python.org To unsubscribe send an email to numpy-discussion-le...@python.org https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ Member address: arch...@mail-archive.com
