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.linalg.vector_norm.html
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/signatures.linear_algebra_functions.matrix_transpose.html
> > > > >
> > > > > - namedtuple outputs for eigh, qr, slogdet and svd. This would
> > > > > only
> > > > > apply to the instances where they cu
