[Numpy-discussion] Re: Switching default order to column-major

[Kevin Sheppard]

I think you can always using order="F" in your own code.

If you patched NumPy and then the downstream libraries had to use your
customized NumPy I think you would see some breaks.  Probably not a lot,
since many use the python numpy API which handles C or F well.  Some code
does do things like call array.flat after creating an array with default
arguments from a list or using "copy=True" and then expects the data to be
ordered as if order="C".

Kevin


On Sat, Nov 11, 2023 at 3:03 PM Valerio De Benedetto 
wrote:

> Hi, I found that the documented default row-major order is enforced
> throughout the library with a series of `order='C'` default parameters, so
> given this I supposed there's no way to change the default (or am I wrong?)
> If, supposedly, I'd change that by patching the library (substituting 'C's
> for 'F's), do you think there would by any problem with other downstream
> libraries using numpy in my project? Do you think they assume a
> default-constructed array is always row-major and access the underlying
> data?
> ___
> 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: kevin.k.shepp...@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] NumPy triage meeting - November 15, 2023 at 5pm UTC

[Inessa Pawson]

The next NumPy triage meeting will be held this Wednesday, November 15th at
5pm UTC. This is a meeting where we synchronously triage prioritized PRs
and issues.
Join us via Zoom:
https://numfocus-org.zoom.us/j/82096749952?pwd=MW9oUmtKQ1c3a2gydGk1RTdYUUVXZz09
.
Everyone is welcome to attend and contribute to a conversation.
Please notify us of issues or PRs that you’d like to have reviewed by
adding a GitHub link to them in the meeting agenda:
https://hackmd.io/68i_JvOYQfy9ERiHgXMPvg.

-- 
Cheers,
Inessa

Inessa Pawson
GitHub: inessapawson
___
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] NumPy 1.26. 2 released

[Charles R Harris]

Charles R Harris 
Sat, Oct 14, 3:03 PM
to numpy-discussion, SciPy, bcc: python-announce-list
Hi All,

On behalf of the NumPy team, I'm pleased to announce the release of NumPy
1.26.2. NumPy 1.26.2 is a maintenance release that fixes bugs and
regressions discovered after the 1.26.1 release. The Python versions
supported by this release are 3.9-3.12. Wheels can be downloaded from PyPI
; source archives, release notes,
and wheel hashes are available on Github
. The release notes
have documentation of the new meson functionality.

*Contributors*

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

   - @stefan6419846
   - @thalassemia +
   - Andrew Nelson
   - Charles Bousseau +
   - Charles Harris
   - Marcel Bargull +
   - Mark Mentovai +
   - Matti Picus
   - Nathan Goldbaum
   - Ralf Gommers
   - Sayed Adel
   - Sebastian Berg
   - William Ayd +



*Pull requests merged*
A total of 25 pull requests were merged for this release.

   - #24814: MAINT: align test_dispatcher s390x targets with
   _umath_tests_mtargets
   - #24929: MAINT: prepare 1.26.x for further development
   - #24955: ENH: Add Cython enumeration for NPY_FR_GENERIC
   - #24962: REL: Remove Python upper version from the release branch
   - #24971: BLD: Use the correct Python interpreter when running tempita.py
   - #24972: MAINT: Remove unhelpful error replacements from
   ``import_array()``
   - #24977: BLD: use classic linker on macOS, the new one in XCode 15
   has...
   - #25003: BLD: musllinux_aarch64 [wheel build]
   - #25043: MAINT: Update mailmap
   - #25049: MAINT: Update meson build infrastructure.
   - #25071: MAINT: Split up .github/workflows to match main
   - #25083: BUG: Backport fix build on ppc64 when the baseline set to
   Power9...
   - #25093: BLD: Fix features.h detection for Meson builds [1.26.x
   Backport]
   - #25095: BUG: Avoid intp conversion regression in Cython 3 (backport)
   - #25107: CI: remove obsolete jobs, and move macOS and conda Azure
   jobs...
   - #25108: CI: Add linux_qemu action and remove travis testing.
   - #25112: MAINT: Update .spin/cmds.py from main.
   - #25113: DOC: Visually divide main license and bundled licenses in
   wheels
   - #25115: MAINT: Add missing ``noexcept`` to shuffle helpers
   - #25116: DOC: Fix license identifier for OpenBLAS
   - #25117: BLD: improve detection of Netlib libblas/libcblas/liblapack
   - #25118: MAINT: Make bitfield integers unsigned
   - #25119: BUG: Make n a long int for np.random.multinomial
   - #25120: BLD: change default of the ``allow-noblas`` option to true.
   - #25121: BUG: ensure passing ``np.dtype`` to itself doesn't crash


Cheers,

Charles Harris
___
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: Switching default order to column-major

[Aaron Meurer]

High level abstractions like .flat or boolean indexing / np.nonzero()
always use C ordering regardless of the underlying data.

>>> list(np.asarray([[0, 1], [2, 3]]).flat)
[0, 1, 2, 3]
>>> list(np.asarray([[0, 1], [2, 3]], order='F').flat)
[0, 1, 2, 3]

C and Fortran ordering are really just special cases of contiguous
strides. In general an array could be non-contiguous, or virtually
broadcasted, or have some other virtual ordering due to stride tricks,
and it might not even make sense to say that it's C or Fortran
ordered.

The real issue with using Fortran ordering is that you might have bad
performance, because most libraries are written assuming C ordering,
performing operations on what would be contiguous memory if the array
were C ordered but isn't when it's Fortran ordered. For example,

In [1]: import numpy as np

In [2]: a = np.ones((100, 100, 100)) # a has C order (the default)

In [3]: %timeit np.sum(a[0])
8.57 µs ± 121 ns per loop (mean ± std. dev. of 7 runs, 100,000 loops each)

In [4]: a_f = np.asarray(a, order='F')

In [5]: %timeit np.sum(a_f[0])
26.3 µs ± 952 ns per loop (mean ± std. dev. of 7 runs, 10,000 loops each)

Summing a[0] is 3 times faster for a C-ordered array because a[0] is
contiguous in C order. The exact reverse timings will hold for
np.sum(a[..., 0]) vs. np.sum(a_f[..., 0]). But it's typical to write
code like this, and you can see that even the very basic NumPy
indexing API favors C ordering by letting you write a[0] instead of
a[..., 0] to get a contiguous piece of memory.

The degree to which this matters in practice will depend on the exact
thing a given library is doing and also things like the size of your
data relative to your CPU caches.

Aaron Meurer

On Sun, Nov 12, 2023 at 8:18 AM Kevin Sheppard
 wrote:
>
> I think you can always using order="F" in your own code.
>
> If you patched NumPy and then the downstream libraries had to use your 
> customized NumPy I think you would see some breaks.  Probably not a lot, 
> since many use the python numpy API which handles C or F well.  Some code 
> does do things like call array.flat after creating an array with default 
> arguments from a list or using "copy=True" and then expects the data to be 
> ordered as if order="C".
>
> Kevin
>
>
> On Sat, Nov 11, 2023 at 3:03 PM Valerio De Benedetto  wrote:
>>
>> Hi, I found that the documented default row-major order is enforced 
>> throughout the library with a series of `order='C'` default parameters, so 
>> given this I supposed there's no way to change the default (or am I wrong?)
>> If, supposedly, I'd change that by patching the library (substituting 'C's 
>> for 'F's), do you think there would by any problem with other downstream 
>> libraries using numpy in my project? Do you think they assume a 
>> default-constructed array is always row-major and access the underlying data?
>> ___
>> 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: kevin.k.shepp...@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: asmeu...@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