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