[Numpy-discussion] Re: Dispatching on `where=` in `__array_ufunc__`?
On Mon, 2023-03-13 at 11:22 +0100, Sebastian Berg wrote: > Hi all, > > Without concerns voiced, I will probbaly merge the PR: > > https://github.com/numpy/numpy/pull/23240 I put this PR in, if it turns out there are issues or general dislike, please let us know and we can reconsider. - Sebastian > > soon. It proposes to dispatch also on the `where=` argument to > ufuncs > for __array_ufunc__. This allows a use-case of an "uncertainty" > boolean array (which is not really boolean). > I guess there may be other use-cases, although I am not sure. It > thus > may be a bit narrow in scope. > > The main effect of this should be that implementors of > __array_ufunc__ > may have to add logic to check for `where` in the kwargs > (eventually), > otherwise a user passing their array type as `where=` might run into > issues (for some types). > > That is slightly tedious, but I doubt it causes much issues in > practice > (where isn't used much, and for most types it doesn't matter much > either way, except for rejecting weirder inputs). > > Cheers, > > Sebastian > > ___ > 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: sebast...@sipsolutions.net > ___ 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] broadcasting question
I have a function F def F(a, b): c = a * b Initially, a is a scalar, b[240,3000]. No problem. Later I want to use F, where a[240] is a vector. I want to allow both the scalar and vector cases. So I write: def F(a,b): a = np.atleast_1d(a) c = a[:,None] * b This now works for scalar a or vector a. But this solutions seems inelegant, and somewhat fragile. Suppose later we want to allow a[240,3000], a 2d array matching b. Certainly don't want to write code like: if a.ndim == 0:... Is there a more elegant/robust approach? Thanks, Neal ___ 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: broadcasting question
On Wed, Mar 22, 2023 at 9:34 AM Neal Becker wrote: > I have a function F > def F(a, b): > c = a * b > > Initially, a is a scalar, b[240,3000]. No problem. > Later I want to use F, where a[240] is a vector. I want to allow both the > scalar and vector cases. So I write: > > def F(a,b): > a = np.atleast_1d(a) > c = a[:,None] * b > > This now works for scalar a or vector a. But this solutions seems > inelegant, and somewhat fragile. Suppose later we want to allow > a[240,3000], a 2d array matching b. > > Certainly don't want to write code like: > if a.ndim == 0:... > > Is there a more elegant/robust approach? > I would leave it as `c = a * b` and simply record in the docstring that `a` and `b` should be broadcastable. Yes, that means that the user will have to write `F(a[:, np.newaxis], b)` for that one case, and that looks a little ugly, but overall it's less cognitive load on the user to just reuse the common convention of broadcasting than to record the special case. -- Robert Kern ___ 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] Consider linking to Accelerate in Apple Silicon ARM64 wheels
Hello! I recently got a new MacBook Pro with an M2 Pro CPU (ARM64). When I ran some numerical computations (ICA to be precise), I was surprised how slow it was - way slower than e.g. my almost 10 year old Intel Mac. It turns out that the default OpenBLAS, which is what you get when installing the binary wheel with pip (i.e. "pip install numpy"), is the reason why computations are so slow. When installing NumPy from source (by using "pip install --no-binary :all: --no-use-pep517 numpy"), it uses the Apple-provided Accelerate framework, which includes an optimized BLAS library. The difference is mind-boggling, I'd even say that NumPy is pretty much unusable with the default OpenBLAS backend (at least for the applications I tested). In my test with four different ICA algorithms, I got these runtimes with the default OpenBLAS: - FastICA: 6.3s - Picard: 26.3s - Infomax: 0.8s - Extended Infomax: 1.4s Especially the second algorithm is way slower than on my 10 year old Intel Mac using OpenBLAS. Here are the times with Accelerate: - FastICA: 0.4s - Picard: 0.6s - Infomax: 1.0s - Extended Infomax: 1.3s Given this huge performance difference, my question is if you would consider distributing a binary wheel for ARM64-based Macs which links to Accelerate. Or are there any caveats why you do not want to do that? I know that NumPy moved away from Accelerate years ago on Intel Macs, but maybe now is the time to reconsider this decision. Thanks! Clemens ___ 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
