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 <kevin.k.shepp...@gmail.com> 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 <po...@debevv.com> 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
