Re: [Numpy-discussion] broadcasting for randint

[G Young]

Just wanted to ping the mailing list again in case this email (see below)
got lost in your inboxes.  Would be great to get some feedback on this!
Thanks!

On Sun, May 22, 2016 at 2:15 AM, G Young  wrote:

> Hi,
>
> I have had a PR  open for quite
> some time now that allows arguments to broadcast in *randint*.  While the
> functionality is fully in-place and very robust, the obstacle at this point
> is the implementation.
>
> When the *dtype* parameter was added to *randint* (see here
> ), a big issue with the
> implementation was that it created so much duplicate code that it would be
> a huge maintenance nightmare.  However, this was dismissed in the original
> PR message because it was believed that template-ing would be trivial,
> which seemed reasonable at the time.
>
> When I added broadcasting, I introduced a template system to the code that
> dramatically cut down on the duplication.  However, the obstacle has been
> whether or not this template system is too *ad hoc* to be merged into the
> library.  Implementing a template in Cython was not considered sufficient
> and is in fact very tricky to do, and unfortunately, I have not received
> any constructive suggestions from maintainers about how to proceed, so I'm
> opening this up to the mailing to see whether or not there are better
> alternatives to what I did, whether this should be merged as it, or whether
> this should be tabled until a better template can be found.
>
> Thanks!
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] ENH: compute many inner products quickly

[Stephan Hoyer]

On Mon, Jun 6, 2016 at 3:32 PM, Jaime Fernández del Río <
jaime.f...@gmail.com> wrote:

> Since we are at it, should quadratic/bilinear forms get their own function
> too?  That is, after all, what the OP was asking for.
>

If we have matvecmul and vecmul, then how to implement bilinear forms
efficiently becomes pretty clear:
np.vecmul(b, np.matvecmul(A, b))

I'm not sure writing a dedicated function in numpy itself makes sense for
something this easy.

I suppose there would be some performance gains from not saving the
immediate result, but I suspect this would be premature optimization in
most cases.
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] ENH: compute many inner products quickly

[Nathaniel Smith]

On Sun, Jun 5, 2016 at 5:41 PM, Stephan Hoyer  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

Given how core to linear algebra these are, and that this is a family
of somewhat expert-oriented functions, I think it'd even be fine to
leave the "product" part implicit, like:

np.linalg.matrix_matrix
np.linalg.matrix_vector
np.linalg.vector_matrix
np.linalg.vector_vector
np.linalg.vector_matrix_vector (for bilinear forms)

(or we could shorten matrix -> mat, vector -> vec if we must.)

-n

-- 
Nathaniel J. Smith -- https://vorpus.org
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] ENH: compute many inner products quickly

[Sebastian Berg]

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

Re: [Numpy-discussion] ENH: compute many inner products quickly

[Jaime Fernández del Río]

On Mon, Jun 6, 2016 at 9:35 AM, Sebastian Berg 
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 
> > 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.

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

Re: [Numpy-discussion] ENH: compute many inner products quickly

[Marten van Kerkwijk]

There I was thinking vector-vector inner product was in fact covered by
`np.inner`. Yikes, half inner, half outer.

As for names, I think `matvecmul` and `vecmul` do seem quite OK (probably
need `vecmatmul` as well, which does the same as `matmul` would for 1-D
first argument).

But as other suggestions, keeping the `dot` one could think of
`vec_dot_vec` and `mat_dot_vec`, etc. More obscure but shorter would be to
use the equivalent `einsum` notation: `i_i`, `ij_j`, `i_ij`, `ij_jk`.

-- Marten
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Integers to integer powers, let's make a decision

[Charles R Harris]

On Mon, Jun 6, 2016 at 2:11 PM, Marten van Kerkwijk <
m.h.vankerkw...@gmail.com> wrote:

> Hi Chuck,
>
> I consider either proposal an improvement, but among the two I favour
> returning float for `**`, because, like for `/`, it ensures one gets
> closest to the (mathematically) true answer in most cases, and makes
> duck-typing that much easier -- I'd like to be able to do x** y without
> having to worry whether x and y are python scalars or numpy arrays of
> certain type.
>
> I do agree with Nathaniel that it would be good to check what actually
> breaks. Certainly, if anybody is up to making a PR that implements either
> suggestion, I'd gladly check whether it breaks anything in astropy.
>
> I  should add that I have no idea how to assuage the fear that new code
> would break with old versions of numpy, but on the other hand, I don't know
> its vailidity either, as it seems one either develops larger projects  for
> multiple versions and tests, or writes more scripty things for whatever the
> current versions are. Certainly, by this argument I better not start using
> the new `@` operator!
>
> I do think the argument that for division it was easier because there was
> `//` already available is a red herring: here one can use `np.power(a, b,
> dtype=...)` if one really needs to.
>

It looks to me like users want floats, while developers want the easy path
of raising an error. Darn those users, they just make life sooo difficult...

Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Integers to integer powers, let's make a decision

[Marten van Kerkwijk]

Hi Chuck,

I consider either proposal an improvement, but among the two I favour
returning float for `**`, because, like for `/`, it ensures one gets
closest to the (mathematically) true answer in most cases, and makes
duck-typing that much easier -- I'd like to be able to do x** y without
having to worry whether x and y are python scalars or numpy arrays of
certain type.

I do agree with Nathaniel that it would be good to check what actually
breaks. Certainly, if anybody is up to making a PR that implements either
suggestion, I'd gladly check whether it breaks anything in astropy.

I  should add that I have no idea how to assuage the fear that new code
would break with old versions of numpy, but on the other hand, I don't know
its vailidity either, as it seems one either develops larger projects  for
multiple versions and tests, or writes more scripty things for whatever the
current versions are. Certainly, by this argument I better not start using
the new `@` operator!

I do think the argument that for division it was easier because there was
`//` already available is a red herring: here one can use `np.power(a, b,
dtype=...)` if one really needs to.

All the best,

Marten
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] ENH: compute many inner products quickly

[Sebastian Berg]

On So, 2016-06-05 at 19:20 -0600, Charles R Harris wrote:
> 
> 
> On Sun, Jun 5, 2016 at 6:41 PM, Stephan Hoyer 
> 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.

- Sebastian


> Chuck  
> 
> ___
> 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