On Wed, Dec 7, 2022 at 3:49 PM Ilhan Polat <firstname.lastname@example.org> 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. Just a rant about typing too much conj().T lately I guess.
.H was discussed in this issue https://github.com/numpy/numpy/issues/13797
The problem with .H is that it wouldn't be a view, since it takes a
conjugate. Some ideas were suggested to fix this, but they are much
more nontrivial to implement, and it's not even clear if they are
desired (basically you'd need a new complex conjugate dtype). x.mT on
the other hand can easily be a view, since it's basically just a
shorthand for swapaxes(x, -1, -2).
More to the point, my plan here is only to work on functions that are
part of the array API specification (and possibly extending these
features to related things like adding namedtuples for other functions
if there are any). Hermitian transpose has not yet been discussed for
addition to the array API specification, which only recently gained
support for complex numbers.
> On Wed, Dec 7, 2022 at 10:26 PM Aaron Meurer <email@example.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
>> - 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
>> - 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 -- firstname.lastname@example.org
>> To unsubscribe send an email to email@example.com
>> Member address: firstname.lastname@example.org
> NumPy-Discussion mailing list -- email@example.com
> To unsubscribe send an email to firstname.lastname@example.org
> Member address: email@example.com
NumPy-Discussion mailing list -- firstname.lastname@example.org
To unsubscribe send an email to email@example.com
Member address: firstname.lastname@example.org