On Wed, Dec 7, 2022 at 11:51 PM Ilhan Polat <ilhanpo...@gmail.com> wrote:
> > On matrix_transpose() : > Every time this discussion brought up, there was a huge resistance to add > more methods to array object or new functions (I have been involved in some > of them on the pro .H side, links you have given and more in the mailing > list) and now we are adding .mT and not .H? That is very surprising to me > (and disappointing) after forcing people to write A.conj().T for years > which is fundamentally the most common 2D operation regarding transpose and > from a user experience perspective. Having a function name with the word > "matrix" is already problematic but I can live with that. But adding .mT to > the main namespace seems really going against all decisions made in the > past. I also wish for cache-oblivious inplace transposition too that would > make many linalg functions perform faster but I wouldn't dare to propose > inplace_transpose() or .iT because it is not that important for *all* > users. And in a way, neither is mT. > > Again not trying to starting an old dumpster fire but surely there must > have been some consideration for .H before we ended up with milliTranspose. > In fact, as I am typing this, I am already regretting it. > In that case, I propose to not dive into .H here - it is a separate and more complicated topic that was not proposed here. Chuck brought it up in the community meeting, we had a chat about it. tl;dr "it is complicated". That said, the thing that got a clearer thumbs up (both on GitHub and yesterday) is the `matrix_transpose` function, not the ndarray attribute. Aaron, given that you are looking for functionality that has value and can be implemented in a backwards compatible fashion, I suggest implementing `matrix_transpose`, and not deal with `.mT` right now. Cheers, Ralf Just a rant about typing too much conj().T lately I guess. > > > > > > > > On Wed, Dec 7, 2022 at 10:26 PM Aaron Meurer <asmeu...@gmail.com> 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: >> >> - 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: ilhanpo...@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: ralf.gomm...@googlemail.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
