Re: [Numpy-discussion] Allowing broadcasting of code dimensions in generalized ufuncs

[Eric Wieser]

I don’t understand your alternative here. If we overload np.matmul using
*array_function*, then it would not use *ether* of these options for
writing the operation in terms of other gufuncs. It would simply look for
an *array_function* attribute, and call that method instead.

Let me explain that suggestion a little more clearly.

   1. There’d be a linalg.matmul2d that performs the real matrix case,
   which would be easy to make as a ufunc right now.
   2. __matmul__ and __rmatmul__ would just call np.matmul, as they
   currently do (for consistency between np.matmul and operator.matmul,
   needed in python pre-@-operator)
   3. np.matmul would be implemented as:

   @do_array_function_overridesdef matmul(a, b):
   if a.ndim != 1 and b.ndim != 1:
   return matmul2d(a, b)
   elif a.ndim != 1:
   return matmul2d(a, b[:,None])[...,0]
   elif b.ndim != 1:
   return matmul2d(a[None,:], b)
   else:
   # this one probably deserves its own ufunf
   return matmul2d(a[None,:], b[:,None])[0,0]

   4. Quantity can just override __array_ufunc__ as with any other ufunc
   5. DataArray, knowing the above doesn’t work, would implement something
   like

   @matmul.register_array_function(DataArray)def __array_function__(a, b):
   if a.ndim != 1 and b.ndim != 1:
   return matmul2d(a, b)
   else:
   # either:
   # - add/remove dummy dimensions in a dataarray-specific way
   # - downcast to ndarray and do the dimension juggling there


Advantages of this approach:

   -

   Neither the ufunc machinery, nor __array_ufunc__, nor the inner loop,
   need to know about optional dimensions.
   -

   We get a matmul2d ufunc, that all subclasses support out of the box if
   they support matmul

Eric
​
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] SciPy 2018

[Charles R Harris]

Hi All,

Thought I'd raise the topic of meeting up at SciPy 2018. I wasn't planning
on registering for the main conference, but would be happy to fly down for
a couple of days if we plan on a meetup during sprints or some other point
in the conference schedule.

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

Re: [Numpy-discussion] SciPy 2018

[Matti Picus]

On 12/06/18 14:26, Charles R Harris wrote:

Hi All,

Thought I'd raise the topic of meeting up at SciPy 2018. I wasn't 
planning on registering for the main conference, but would be happy to 
fly down for a couple of days if we plan on a meetup during sprints or 
some other point in the conference schedule.


Chuck


There will be a NumPy sprint July 14-15. I have requested a BOF room.
For the BOF, I hoped to continue the discussion of the NumPy roadmap 
https://github.com/numpy/numpy/wiki/NumPy-Roadmap as well as provide a 
forum to meet in person.


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

[Numpy-discussion] Permissions to upload to PyPI

[Matti Picus]

Almost ready to finish the 1.14.5 release, but it seems I need 
permissions to upload to PyPI (makes sense). My user name there is 
mattip. Can someone help out?

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

Re: [Numpy-discussion] Permissions to upload to PyPI

[Charles R Harris]

On Tue, Jun 12, 2018 at 4:22 PM, Matti Picus  wrote:

> Almost ready to finish the 1.14.5 release, but it seems I need permissions
> to upload to PyPI (makes sense). My user name there is mattip. Can someone
> help out?
> Matti
>

Done. Sorry I missed that.

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

[Numpy-discussion] NumPy 1.15.x branched.

[Charles R Harris]

Hi All,

NumPy 1.15.x has been branched and master is now open for 1.16 development.
If there are any remaining PRs that *just have to be in 1.15*, please
complain here :0

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

[Numpy-discussion] NumPy 1.14.5 released

[Matti Picus]

Hi All,

I am pleased to announce the release of NumPy 14.4.5.

This is a bugfix release for bugs reported following the 1.14.4 release. The
most significant fixes are:

* fixes for compilation errors on alpine and NetBSD

The Python versions supported in this release are 2.7 and 3.4 - 3.6. The 
Python

3.6 wheels available from PIP are built with Python 3.6.2 and should be
compatible with all previous versions of Python 3.6. The source releases 
were

cythonized with Cython 0.28.2 and should work for the upcoming Python 3.7.

Contributors


A total of 1 person contributed to this release.  People with a "+" by their
names contributed a patch for the first time.

* Charles Harris

Pull requests merged


A total of 2 pull requests were merged for this release.

* `#11274 `__: BUG: Correct 
use of NPY_UNUSED.
* `#11294 `__: BUG: Remove 
extra trailing parentheses.


Cheers,
Matti
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Allowing broadcasting of code dimensions in generalized ufuncs

[Marten van Kerkwijk]

On Tue, Jun 12, 2018 at 2:35 AM, Eric Wieser 
wrote:

> Frozen dimensions:
>
> I started with just making every 3-vector and 3x3-matrix structured arrays
> with the relevant single sub-array entry
>
> I was actually suggesting omitting the structured dtype (ie, field names)
> altogether, and just using the subarray dtypes (which exist alone, but not
> in arrays).
>
> Another (small?) advantage is that I can use `axis
>
> This is a fair argument against my proposal - at any rate, I think we’d
> need a better story for subarray dtypes before trying to add support to
> them for ufuncs
>
Yes, I've been wondering about the point of the sub-arrays... They seem
interesting but in arrays just disappear. Their possible use would be to
change the shape as seen by the outside world (as happens if one does
define that sub-array as a 1-part structured array).

Anyway, for another discussion!


> --
>
> Broadcasting dimensions
>
> But perhaps a putative weighted_mean … is a decent example
>
> That’s fairly convincing as a non-chained ufunc case. Can you add an
> example like that to the NEP?
>
Done.


> Also, it has the benefit of being clear what the function can handle by
> inspection of the signature
>
> Is broadcasting (n),(n)->(),() less clear that (n|1),(n|1)->(),()? Can
> you come up with an example where only some dimensions make sense to
> broadcast?
>
Not a super-convincing one, though I guess one could think of a similar
function for 3-vectors (which somehow must care about those being
three-dimensional, because, say, it calculates the average direction of the
cross product in spherical angles...), then, in the signature
`(n,3),(n,3)->(),(),(),()` one would like to indicate that the `n` could be
broadcast, but the `3` could not.

As I now write in the NEP, part of the reason of doing it by distinct
dimension is that I already need a flag for flexible, so it is easy to add
one for broadcastable; similarly, in the actual code, there is quite a bit
of shared stuff.

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