Mailman 3 Addition of useful new functions from the array API specification - NumPy-Discussion

newer
Re: Documentation Team meeting -...

Addition of useful new functions from the array API specification

older
status of long double support and...

Aaron Meurer

7 Dec 2022 7 Dec '22

1:21 p.m.

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/signature... - 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.linal... and https://data-apis.org/array-api/latest/extensions/generated/signatures.linal.... - 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/signature... - 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

Show replies by thread

Ilhan Polat

7 Dec 7 Dec

2:48 p.m.

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. On Wed, Dec 7, 2022 at 10:26 PM 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:

- 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/signature...

- 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.linal... and https://data-apis.org/array-api/latest/extensions/generated/signatures.linal... .

- 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/signature...

- 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-leave@python.org https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ Member address: ilhanpolat@gmail.com

Ralf Gommers

8 Dec 8 Dec

2:41 a.m.

On Wed, Dec 7, 2022 at 11:51 PM Ilhan Polat 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 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/signature...

- 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.linal... and https://data-apis.org/array-api/latest/extensions/generated/signatures.linal... .

- 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/signature...

- 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-leave@python.org https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ Member address: ilhanpolat@gmail.com

_______________________________________________ NumPy-Discussion mailing list -- numpy-discussion@python.org To unsubscribe send an email to numpy-discussion-leave@python.org https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ Member address: ralf.gommers@googlemail.com

Aaron Meurer

2:50 p.m.

On Wed, Dec 7, 2022 at 3:49 PM Ilhan Polat 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. Aaron Meurer

...

On Wed, Dec 7, 2022 at 10:26 PM 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:

- 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/signature...

- 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.linal... and https://data-apis.org/array-api/latest/extensions/generated/signatures.linal....

- 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/signature...

- 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-leave@python.org https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ Member address: ilhanpolat@gmail.com

_______________________________________________ NumPy-Discussion mailing list -- numpy-discussion@python.org To unsubscribe send an email to numpy-discussion-leave@python.org https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ Member address: asmeurer@gmail.com

Ilhan Polat

4:51 p.m.

I am familiar with that issue and many older ones in this mailing list too. The argument I am trying to make is that just because it is a view should not directly imply that it should go in the NumPy main namespace. I don't know what array API designers think but .H is order of magnitude more common than tensor transpose. numpy.sort is also inplace and also tricky but we have it. Plus ".H" can have the correct transpose for the tensors and can behave like matrix_transpose for reals or whatever. The point I was trying to make is that this array API spec should also involve usability aspects of the tool and if complex operations are not discussed in array API then either this API spec is incomplete or it is a float array API. But like I said, I don't want to start any discussion, did a bit too much spectral work on time-series lately so finger-wounds are still fresh I guess. Apologies for the rant. On Thu, Dec 8, 2022 at 11:54 PM Aaron Meurer wrote:

...

On Wed, Dec 7, 2022 at 3:49 PM Ilhan Polat 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.

Aaron Meurer

...
On Wed, Dec 7, 2022 at 10:26 PM 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:

- 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/signature...

...
...
- 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.linal...

...
and https://data-apis.org/array-api/latest/extensions/generated/signatures.linal... .

- 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/signature...

...
- 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-leave@python.org https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ Member address: ilhanpolat@gmail.com

_______________________________________________ NumPy-Discussion mailing list -- numpy-discussion@python.org To unsubscribe send an email to numpy-discussion-leave@python.org https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ Member address: asmeurer@gmail.com

NumPy-Discussion mailing list -- numpy-discussion@python.org To unsubscribe send an email to numpy-discussion-leave@python.org https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ Member address: ilhanpolat@gmail.com

Aaron Meurer

9 Dec 9 Dec

6:05 p.m.

On Thu, Dec 8, 2022 at 5:54 PM Ilhan Polat wrote:

...

I am familiar with that issue and many older ones in this mailing list too.

The argument I am trying to make is that just because it is a view should not directly imply that it should go in the NumPy main namespace. I don't know what array API designers think but .H is order of magnitude more common than tensor transpose.

I don't know if I believe that, but regardless, it seems rather orthogonal to the discussion of .mT. They are separate methods, and each has its own uses. matrix_transpose makes sense even when the array is not numeric, for instance. As I noted, Hermitian transpose hasn't even been discussed for the array API yet. I opened https://github.com/data-apis/array-api/issues/555 to discuss it there. Feel free to weigh in with your opinions. Ideally, .T would do a matrix transpose, but due to a poor design decision in the past, it does not for stacked matrices. Changing its behavior would be a huge break, hence the new attribute.

...

numpy.sort is also inplace and also tricky but we have it. Plus ".H" can have the correct transpose for the tensors and can behave like matrix_transpose for reals or whatever. The point I was trying to make is that this array API spec should also involve usability aspects of the tool and if complex operations are not discussed in array API then either this API spec is incomplete or it is a float array API.

Complex numbers are discussed in the spec, but as I noted, they were only added recently (in the upcoming 2022 version of the spec). Part of the reason for this is that some array libraries like pytorch and tensorflow have only recently added complex number support, and another reason is that specifying behavior for complex numbers is more work than just integers and floats. So the first version of the spec did not include them. What this means is that some things relating to complex numbers (and in particular, things surrounding linear algebra) haven't been discussed as much yet. Aaron Meurer

...

But like I said, I don't want to start any discussion, did a bit too much spectral work on time-series lately so finger-wounds are still fresh I guess. Apologies for the rant.

On Thu, Dec 8, 2022 at 11:54 PM Aaron Meurer wrote:

...
On Wed, Dec 7, 2022 at 3:49 PM Ilhan Polat 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.

Aaron Meurer

...
On Wed, Dec 7, 2022 at 10:26 PM 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:

- 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/signature...

- 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.linal... and https://data-apis.org/array-api/latest/extensions/generated/signatures.linal....

- 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/signature...

- 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-leave@python.org https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ Member address: ilhanpolat@gmail.com

_______________________________________________ NumPy-Discussion mailing list -- numpy-discussion@python.org To unsubscribe send an email to numpy-discussion-leave@python.org https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ Member address: asmeurer@gmail.com

_______________________________________________ NumPy-Discussion mailing list -- numpy-discussion@python.org To unsubscribe send an email to numpy-discussion-leave@python.org https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ Member address: ilhanpolat@gmail.com

_______________________________________________ NumPy-Discussion mailing list -- numpy-discussion@python.org To unsubscribe send an email to numpy-discussion-leave@python.org https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ Member address: asmeurer@gmail.com

Sebastian Berg

12 Dec 12 Dec

7:43 a.m.

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/signature...

- 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.linal... and https://data-apis.org/array-api/latest/extensions/generated/signatures.linal... .

- 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/signature...

- 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-leave@python.org https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ Member address: sebastian@sipsolutions.net

Aaron Meurer

12:23 p.m.

On Mon, Dec 12, 2022 at 8:46 AM Sebastian Berg 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? 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/signature...

- 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.linal... and https://data-apis.org/array-api/latest/extensions/generated/signatures.linal... .

- 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/signature...

- 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-leave@python.org https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ Member address: sebastian@sipsolutions.net

_______________________________________________ NumPy-Discussion mailing list -- numpy-discussion@python.org To unsubscribe send an email to numpy-discussion-leave@python.org https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ Member address: asmeurer@gmail.com

Warren Weckesser

3:20 p.m.

On 12/12/22, Aaron Meurer wrote:

...

On Mon, Dec 12, 2022 at 8:46 AM Sebastian Berg 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/signature...

- 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.linal... and https://data-apis.org/array-api/latest/extensions/generated/signatures.linal... .

- 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/signature...

- 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-leave@python.org https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ Member address: sebastian@sipsolutions.net

_______________________________________________ NumPy-Discussion mailing list -- numpy-discussion@python.org To unsubscribe send an email to numpy-discussion-leave@python.org https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ Member address: asmeurer@gmail.com

_______________________________________________ NumPy-Discussion mailing list -- numpy-discussion@python.org To unsubscribe send an email to numpy-discussion-leave@python.org https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ Member address: warren.weckesser@gmail.com

Sebastian Berg

10:47 p.m.

On Mon, 2022-12-12 at 18:20 -0500, Warren Weckesser wrote:

...

On 12/12/22, Aaron Meurer wrote:

...
On Mon, Dec 12, 2022 at 8:46 AM Sebastian Berg 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. - 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/signature...

- 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.linal... and https://data-apis.org/array-api/latest/extensions/generated/signatures.linal... .

- 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/signature...

- 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-leave@python.org https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ Member address: sebastian@sipsolutions.net

_______________________________________________ NumPy-Discussion mailing list -- numpy-discussion@python.org To unsubscribe send an email to numpy-discussion-leave@python.org https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ Member address: asmeurer@gmail.com

_______________________________________________ NumPy-Discussion mailing list -- numpy-discussion@python.org To unsubscribe send an email to numpy-discussion-leave@python.org https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ Member address: warren.weckesser@gmail.com

_______________________________________________ NumPy-Discussion mailing list -- numpy-discussion@python.org To unsubscribe send an email to numpy-discussion-leave@python.org https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ Member address: sebastian@sipsolutions.net

Aaron Meurer

13 Dec 13 Dec

12:11 a.m.

On Mon, Dec 12, 2022 at 11:54 PM Sebastian Berg wrote:

...

On Mon, 2022-12-12 at 18:20 -0500, Warren Weckesser wrote:

...
On 12/12/22, Aaron Meurer wrote:

...
On Mon, Dec 12, 2022 at 8:46 AM Sebastian Berg 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.linal... 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/signature...

- 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.linal... and https://data-apis.org/array-api/latest/extensions/generated/signatures.linal... .

- 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/signature...

- 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-leave@python.org https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ Member address: sebastian@sipsolutions.net

_______________________________________________ NumPy-Discussion mailing list -- numpy-discussion@python.org To unsubscribe send an email to numpy-discussion-leave@python.org https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ Member address: asmeurer@gmail.com

_______________________________________________ NumPy-Discussion mailing list -- numpy-discussion@python.org To unsubscribe send an email to numpy-discussion-leave@python.org https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ Member address: warren.weckesser@gmail.com

_______________________________________________ NumPy-Discussion mailing list -- numpy-discussion@python.org To unsubscribe send an email to numpy-discussion-leave@python.org https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ Member address: sebastian@sipsolutions.net

_______________________________________________ NumPy-Discussion mailing list -- numpy-discussion@python.org To unsubscribe send an email to numpy-discussion-leave@python.org https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ Member address: asmeurer@gmail.com

Ralf Gommers

12:29 p.m.

On Mon, Dec 12, 2022 at 4:44 PM Sebastian Berg 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.)

A correction on this for completeness: this is not correct, `np.linalg.transpose` does not exist, there is only a *private* `np.linalg.linalg.transpose` function. So this adds a new public function - one that has been pointed out previously as missing and important to add, but somehow no one got around to actually doing that. Cheers, Ralf

Aaron Meurer

16 Dec 16 Dec

3:43 p.m.

Another feature I missed that can be added to this list is the descending flag to sort() and argsort(). See https://github.com/numpy/numpy/issues/14728 and https://data-apis.org/array-api/latest/API_specification/generated/signature.... Aaron Meurer On Wed, Dec 7, 2022 at 2:21 PM 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:

- 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/signature...

- 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.linal... and https://data-apis.org/array-api/latest/extensions/generated/signatures.linal....

- 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/signature...

- 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

495

Age (days ago)

504

Last active (days ago)

List overview

Download

12 comments

5 participants

participants (5)

Aaron Meurer
Ilhan Polat
Ralf Gommers
Sebastian Berg
Warren Weckesser

Addition of useful new functions from the array API specification

tags

participants (5)