On Mon, Dec 12, 2022 at 11:54 PM Sebastian Berg <sebast...@sipsolutions.net> wrote: > > On Mon, 2022-12-12 at 18:20 -0500, Warren Weckesser wrote: > > On 12/12/22, Aaron Meurer <asmeu...@gmail.com> wrote: > > > 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? > > > > > > > IIUC, the proposed vectornorm supports an arbitrary number of axis. > The ufunc does not unless I am missing some gufunc definition.
That is correct. https://data-apis.org/array-api/latest/extensions/generated/signatures.linalg.vector_norm.html Aaron Meurer > > - 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/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 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.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: warren.weckes...@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: 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
