On Di, 2016-06-07 at 00:32 +0200, Jaime Fernández del Río wrote: > On Mon, Jun 6, 2016 at 9:35 AM, Sebastian Berg <sebastian@sipsolution > s.net> wrote: > > On So, 2016-06-05 at 19:20 -0600, Charles R Harris wrote: > > > > > > > > > On Sun, Jun 5, 2016 at 6:41 PM, Stephan Hoyer <sho...@gmail.com> > > > wrote: > > > > If possible, I'd love to add new functions for "generalized > > ufunc" > > > > linear algebra, and then deprecate (or at least discourage) > > using > > > > the older versions with inferior broadcasting rules. Adding a > > new > > > > keyword arg means we'll be stuck with an awkward API for a long > > > > time to come. > > > > > > > > There are three types of matrix/vector products for which > > ufuncs > > > > would be nice: > > > > 1. matrix-matrix product (covered by matmul) > > > > 2. matrix-vector product > > > > 3. vector-vector (inner) product > > > > > > > > It's straightful to implement either of the later two options > > by > > > > inserting dummy dimensions and then calling matmul, but that's > > a > > > > pretty awkward API, especially for inner products. > > Unfortunately, > > > > we already use the two most obvious one word names for vector > > inner > > > > products (inner and dot). But on the other hand, one word names > > are > > > > not very descriptive, and the short name "dot" probably mostly > > > > exists because of the lack of an infix operator. > > > > > > > > So I'll start by throwing out some potential new names: > > > > > > > > For matrix-vector products: > > > > matvecmul (if it's worth making a new operator) > > > > > > > > For inner products: > > > > vecmul (similar to matmul, but probably too ambiguous) > > > > dot_product > > > > inner_prod > > > > inner_product > > > > > > > I was using mulmatvec, mulvecmat, mulvecvec back when I was > > looking > > > at this. I suppose the mul could also go in the middle, or maybe > > > change it to x and put it in the middle: matxvec, vecxmat, > > vecxvec. > > > > > > > Were not some of this part of the gufunc linalg functions and we > > just > > removed it because we were not sure about the API? Not sure > > anymore, > > but might be worth to have a look. > We have > from numpy.core.umath_tests import inner1d > which does vectorized vector-vector multiplication, but it's > undocumented. There is also a matrix_multiply in that same module > that does the obvious thing. > And when gufuncs were introduced in linalg, there were a bunch of > functions doing all sorts of operations without intermediate storage, > e.g. sum3(a, b, c) -> a + b + c, that were removed before merging the > PR. Wasn't involved at the time, so not sure what the rationale was.
I think it was probably just that the api was not thought out much. Adding sum3 to linalg does seem a bit funny ;). I would not mind it in numpy as such I guess, if it quite a bit faster anyway, but maybe in its own submodule for these kind of performance optimizations. - Sebastian > Since we are at it, should quadratic/bilinear forms get their own > function too? That is, after all, what the OP was asking for. > Jaime > -- > (\__/) > ( O.o) > ( > <) Este es Conejo. Copia a Conejo en tu firma y ayúdale en sus > planes de dominación mundial. > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > https://mail.scipy.org/mailman/listinfo/numpy-discussion
signature.asc
Description: This is a digitally signed message part
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
