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`? * `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. - 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: arch...@mail-archive.com
