[Numpy-discussion] next NumPy Newcomers' Hour - 8 pm UTC
Our next Newcomers' Hour will be held this Thursday, December 15th at 8 pm UTC. Stop by to ask questions or just to say hi. To add to the meeting agenda the topics you’d like to discuss, follow the link: https://hackmd.io/3f3otyyuTte3FU9y3QzsLg?both Join the meeting via Zoom: https://us06web.zoom.us/j/82563808729?pwd=ZFU3Z2dMcXBGb05YemRsaGE1OW5nQT09 -- Cheers, Inessa Inessa Pawson Contributor Experience Lead | NumPy https://numpy.org/ GitHub: inessapawson ___ 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
[Numpy-discussion] Re: Addition of useful new functions from the array API specification
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/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
[Numpy-discussion] Re: Addition of useful new functions from the array API specification
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/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.
[Numpy-discussion] Re: Addition of useful new functions from the array API specification
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/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/la
[Numpy-discussion] Re: Addition of useful new functions from the array API specification
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/signatures.linear_algebra_functions.matrix_transpose.html > > > > > > > > - namedtuple outputs for eigh, qr, slogdet and svd. This would > > > > only > > > > apply to the instances where they currently return a tuple > > > > (e.g., > > > > svd(compute_uv=False) would still just return an array). See > > > > the > > > > corresponding pages at > > > > https://data-apis.org/array-api/latest/extensions/index.html fo > > > > r the > > > > namedtuple names. These four functions are the ones that are > > > > part of > > > > the array API spec, but if there are other functions that > > > > aren't part > >
