[Numpy-discussion] Re: broadcasting question

[Sebastian Berg]

On Wed, 2023-03-22 at 12:00 -0400, Robert Kern wrote:
> 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.


I will note that it is not hard to insert the new axes.
`np.expand_dims` may be convenient.  many functions (ufuncs) also have
the `outer` version which does this: `np.add.outer()`, etc.

However, I agree.  Unless the use-case exceedingly clear about
requiring "outer" behavior.  "outer" behavior is uncommon for functions
in the NumPy world and broadcasting is what users will generally expect
(and that includes future self). 

- 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] Re: Consider linking to Accelerate in Apple Silicon ARM64 wheels

[Ralf Gommers]

On Thu, Mar 23, 2023 at 1:55 AM Clemens Brunner 
wrote:

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

Hi Clemens, thanks for the suggestion and benchmarks. We actually discussed
this in the last community meeting. Accelerate as of today is supported
when building from source, and that will use 32-bit BLAS/LAPACK (the LP64
interface). Since NumPy 1.22 we're shipping our wheels with the 64-bit
(ILP64) interface, which Accelerate doesn't provide. That's about to change
though, in macOS 13.3:
https://developer.apple.com/documentation/macos-release-notes/macos-13_3-release-notes#Accelerate.
That release will also upgrade to LAPACK 3.9.1, which means we can
re-enable it for SciPy too.

For macOS 14 we will most likely, if things go well, ship wheels linked
against the new ILP64 Accelerate build. Due to packaging limitations (the
`packaging` library ignores minor versions of macOS), we can't ship wheels
for >=13.3, only >=14.

Cheers,
Ralf
___
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: Consider linking to Accelerate in Apple Silicon ARM64 wheels

[Clemens Brunner]

Thanks Ralf, this sounds great! Just making sure I understand, this means that 
for macOS 13, we have to enable Accelerate by building NumPy from source. Once 
macOS 13.3 is out, building SciPy from source will also link to Accelerate. 
Finally, Accelerate support will be enabled by default in binary wheels for 
NumPy and SciPy once macOS 14 is out (presumably some time in October this 
year). Correct?

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

[Numpy-discussion] Re: Consider linking to Accelerate in Apple Silicon ARM64 wheels

[Ralf Gommers]

On Thu, Mar 23, 2023 at 10:43 AM Clemens Brunner 
wrote:

> Thanks Ralf, this sounds great! Just making sure I understand, this means
> that for macOS 13, we have to enable Accelerate by building NumPy from
> source.


Indeed. Either that, or use a packaging system that's more capable in this
regard - conda-forge for example will give you runtime switching of BLAS
and LAPACK libraries out of the box (
https://conda-forge.org/docs/maintainer/knowledge_base.html#switching-blas-implementation).
Several Linux distros support this too, via mechanisms like
`update-alternatives` - but that won't help you much on macOS of course.

Once macOS 13.3 is out, building SciPy from source will also link to
> Accelerate. Finally, Accelerate support will be enabled by default in
> binary wheels for NumPy and SciPy once macOS 14 is out (presumably some
> time in October this year). Correct?
>

Yes, if I had to guess now then I'd say that this will be the default in
NumPy 2.0 at the end of the year.

Cheers,
Ralf
___
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

[Neal Becker]

On Thu, Mar 23, 2023 at 5:21 AM Sebastian Berg 
wrote:

> On Wed, 2023-03-22 at 12:00 -0400, Robert Kern wrote:
> > 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.
>
>
> I will note that it is not hard to insert the new axes.
> `np.expand_dims` may be convenient.  many functions (ufuncs) also have
> the `outer` version which does this: `np.add.outer()`, etc.
>
> However, I agree.  Unless the use-case exceedingly clear about
> requiring "outer" behavior.  "outer" behavior is uncommon for functions
> in the NumPy world and broadcasting is what users will generally expect
> (and that includes future self).
>
> - Sebastian
>
> Thanks for the advice!  On reflection, I agree.
___
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] Fortran-style support in ctypeslib.as_array()?

[monte . b . hoover]

Would it be okay to add an argument to ctypeslib.as_array() that allowed 
specifying that a pointer references column-major memory layout? 

Currently if we use ndarray.ctypes.data_as() to get a pointer to a 
Fortran-ordered array and then we use ctypeslib.as_array() to read that same 
array back in, we don't have a way of doing the round trip correctly.

For example:
>>> import ctypes as ct
>>> a = np.arange(6).reshape(2,3)
>>> a = np.asfortranarray(a) 
>>> a
array([[0, 1, 2],
   [3, 4, 5]])
>>> a_ptr = a.ctypes.data_as(ct.POINTER(ct.c_int)) 
>>> b = np.ctypeslib.as_array(a_ptr, shape=a.shape) 
>>> b
array([[0, 3, 1],
   [4, 2, 5]])

The proposed function signature would be something like:
numpy.ctypeslib.as_array(obj, shape=None, order='None'), with order{‘C’, ‘F’}, 
optional

Thanks,
Monte
___
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: Fortran-style support in ctypeslib.as_array()?

[Eric Wieser]

Hi Monte,

This strikes me as a slightly strange request; ctypes is intended to
interface with the C memory model, which has no native representation of
fortran arrays.
The underlying workings of `as_array` is to cast your ctype pointer into a
ctypes array object, and then pass that into numpy.
That approach doesn't work when there is no ctypes representation to begin
with

If you were writing C code to work with fortran arrays, probably you would
flatten your data into a single 1D array. You can use the same approach
here:

>>> np.ctypeslib.as_array(a_ptr, shape=(a.size,)).reshape(a.shape,
order='F')
array([[0, 1, 2],
   [3, 4, 5]])

Eric

On Thu, 23 Mar 2023 at 17:04,  wrote:

> Would it be okay to add an argument to ctypeslib.as_array() that allowed
> specifying that a pointer references column-major memory layout?
>
> Currently if we use ndarray.ctypes.data_as() to get a pointer to a
> Fortran-ordered array and then we use ctypeslib.as_array() to read that
> same array back in, we don't have a way of doing the round trip correctly.
>
> For example:
> >>> import ctypes as ct
> >>> a = np.arange(6).reshape(2,3)
> >>> a = np.asfortranarray(a)
> >>> a
> array([[0, 1, 2],
>[3, 4, 5]])
> >>> a_ptr = a.ctypes.data_as(ct.POINTER(ct.c_int))
> >>> b = np.ctypeslib.as_array(a_ptr, shape=a.shape)
> >>> b
> array([[0, 3, 1],
>[4, 2, 5]])
>
> The proposed function signature would be something like:
> numpy.ctypeslib.as_array(obj, shape=None, order='None'), with order{‘C’,
> ‘F’}, optional
>
> Thanks,
> Monte
> ___
> 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: wieser.eric+nu...@gmail.com
>
___
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: dropping support for Gitpod and our Docker image builds

[Ralf Gommers]

On Mon, Mar 20, 2023 at 9:09 PM Ralf Gommers  wrote:

>
> So my proposal is to drop all the Docker Hub and Gitpod related code and
> docs. I have already discussed this with Tania Allard, who did most of the
> heavy lifting on the initial creation of the Gitpod machinery (for SciPy,
> which was then synced to NumPy).
>

It seems everyone is happy with removing Gitpod. To close the loop on this,
here is the relevant PR: https://github.com/numpy/numpy/pull/23444.

Cheers,
Ralf
___
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