[Numpy-discussion] Re: surprising behavior from array indexing

On Mon, Dec 30, 2024 at 1:51 PM Robert Kern wrote: > On Mon, Dec 30, 2024 at 10:28 AM Mark Harfouche via NumPy-Discussion < > numpy-discussion@python.org> wrote: > >> Happy new year everybody! >> >> I've been upgrading my code to start to support arr

[Numpy-discussion] surprising behavior from array indexing

Happy new year everybody! I've been upgrading my code to start to support array indexing and in my tests I found something that was well documented, but surprising to me. I've tried to read through https://numpy.org/doc/stable/user/basics.indexing.html#combining-advanced-and-basic-indexing and ev

[Numpy-discussion] Re: Please consider dropping Python 3.9 support for Numpy 2.0

I'm sorry to have used scikit-image as an example as it is an active project (with Juan and other core dev even replying to this thread) and we can try to release 0.22.1 just for this purpose. But, what I'm trying to do is to avoid the churn that many other developers will have when this gets rolle

[Numpy-discussion] Re: Please consider dropping Python 3.9 support for Numpy 2.0

On Mon, May 6, 2024 at 6:46 AM Sebastian Berg wrote: > On Mon, 2024-05-06 at 09:17 +1000, Matti Picus wrote: > > On 05/05/2024 11:32, Mark Harfouche wrote: > > > > but to me it makes sense to support it for the > > large 2.0 release. > > The release will

[Numpy-discussion] Please consider dropping Python 3.9 support for Numpy 2.0

I know this is somewhat the 11th hour for the numpy 2.0 release but as downstream packager and user of numpy, I would really like to ask that Numpy strives to adhere to NEP29, and SPEC0 SEPC0 makes it pretty clear that Python 3.9 should not be included in any "future" versions. Leading by example

[Numpy-discussion] __array_function__ for assignment?

I've been working on creating a few lazy arrays for our applications. For large data volumes, it is often critical to avoid the use of bounce buffers. Essentially, I'm looking to see if there exists a function like `np.take` that would take: 1. A slice for the input array. 2. A slice for the out

[Numpy-discussion] Re: Numpy tools for getting the results of indexing operations

if an index is an advanced index or not), but they are >> definitely in scope and I would love to add them. >> >> Aaron Meurer >> >> On Mon, Jan 30, 2023 at 9:28 PM Mark Harfouche >> wrote: >> >>> I'm trying to make a few different file backed

[Numpy-discussion] Numpy tools for getting the results of indexing operations

I'm trying to make a few different file backed array-like objects. However, I find myself struggling to get all the indexing operations right. Is there a collection of utilities that answer questions like: 1. Given a shape, and key that would be valid in numpy, what is the resulting shape. 2. Gi

[Numpy-discussion] Re: Congratulation to our newest maintainer Mukulika Pahari

Congratulations! Quite exciting! On Sun, Jan 29, 2023 at 11:15 AM Mukulika Pahari wrote: > Thank you, everyone! Happy to be here and contribute to the project :) > ___ > NumPy-Discussion mailing list -- numpy-discussion@python.org > To unsubscribe send

[Numpy-discussion] Re: Test suite for duck arrays

Wow this looks great! On Mon, Jan 16, 2023 at 10:52 AM Ralf Gommers wrote: > > > On Mon, Jan 16, 2023 at 3:28 PM Mark Harfouche > wrote: > >> I am trying to create a few different duck arrays that are backed by >> different files. >> >> Is there a

[Numpy-discussion] Test suite for duck arrays

I am trying to create a few different duck arrays that are backed by different files. Is there a standard test suite that we can inspire ourselves from that helps us assert: "Arrays should implement all these different functions and the results should be correct" _

Re: [Numpy-discussion] np.{bool,float,int} deprecation

I guess if the answer is to stop people from from numpy import * there is a good fix for that doesn’t involve deprecating dtype=np.int. If the answer is to deprecate np.int(1) == int(1) then one can add a warning to the __init__ of the np.int class, but continue to subclass the python int clas

Re: [Numpy-discussion] NumPy 1.20.x branch in two weeks

Juan made a pretty good argument for keeping 3.6 support in the next scikit-image release, let me try to paraphrase: - Since nobody has made the PR to explicitly drop python 3.6 from the scikit-image build matrix, we will continue to support it, but if somebody were to make the PR, I (Juan) would

Re: [Numpy-discussion] NumPy 1.20.x branch in two weeks

> > > Do you think the proposal is not in compliance? There is no requirement > that we drop anything more than 42 months old, it is just recommended. The > change in the Python release cycle has created some difficulty. With the > yearly cycle, 4 python yearly releases will cover 3-4 years, which

Re: [Numpy-discussion] NumPy 1.20.x branch in two weeks

I know it seems silly, but would an amendment to NEP29 be reasonable? Many downstream packages look to numpy to understand what versions should be supported and NEP29 gave some good guidance. That said, if it is worth ignoring, or revisiting, some clarity on how to apply NEP29 given recent develop

Re: [Numpy-discussion] the NumPy paper is out!

Great work all! It got to the top of new.ycombinator.com ;) On Thu, Sep 17, 2020 at 6:35 PM Derek Homeier < de...@astro.physik.uni-goettingen.de> wrote: > I did not want to put any more load on the list, but let me just report > that this news has got > 177 likes within 24 hours in the Python use

Re: [Numpy-discussion] new numpy.org is live

This looks really great! I love the Ecosystem section at the bottom! Great job emphasising the importance, and the elegance of the library! On Sun, May 24, 2020 at 2:20 PM Stephen Waterbury wrote: > This is an absolutely beautiful and very informative site! > It is clear all the work and thoug

Re: [Numpy-discussion] manylinux2010.

Chuck, Cool stuff! Will manylinux1 wheels compiled with older numpy (say 1.14) work with manylinux2010 wheels? What is your recommendation for downstream projects that depend on Cython/numpy to do? Do you have a document we can read? Mark On Fri, Feb 14, 2020 at 11:05 AM Charles R Harris wro

Re: [Numpy-discussion] numpy pprint?

experiment with on that sense. That said. That might just be a doctest issue and not a numpy issue. On Tue, Nov 6, 2018 at 5:18 AM Foad Sojoodi Farimani wrote: > In between your lines: > > On Tue, Nov 6, 2018 at 11:07 AM Mark Harfouche > wrote: > >> Foad, >> In resp

Re: [Numpy-discussion] numpy pprint?

ders just like Pandas... >>> >>> F. >>> >>> On Tue, Nov 6, 2018 at 6:51 AM Eric Wieser >>> wrote: >>> >>>> Hijacking this thread while on the topic of pprint - we might want to >>>> look into a table-based `_html_repr_` or

Re: [Numpy-discussion] numpy pprint?

Foad, Visualizing data is definitely a complex field. I definitely feel your pain. Printing your data is but one way of visualizing it, and probably only useful for very small and constrained datasets. Have you looked into set_printoptions

Re: [Numpy-discussion] out parameter for np.fromfile

points the array at the memory that holds the buffer). > > All the best, > > Marten > > > On Sun, Nov 4, 2018 at 10:35 PM Mark Harfouche > wrote: > >> I was wondering what would your thoughts be on adding an output parameter >> to np.fromfile? >> >&g

Re: [Numpy-discussion] Prep for NumPy 1.16.0 branch

> Thoughts on how to proceed are welcome. I've been involved in scikit-image and that project tore out the python2 only code rather quickly after 2.7 support was dropped. I think it caused a few hiccups when backporting bugfixes. I imagine that `1.16.1` and `1.16.2` releases will come out quickly

[Numpy-discussion] out parameter for np.fromfile

I was wondering what would your thoughts be on adding an output parameter to np.fromfile? The advantage would be when interfacing with executables like ffmpeg which are arguably easier to use by calling them as a subprocess compared to a shared library in python. Having the output parameter in np

Re: [Numpy-discussion] BIDS/NumPy dev meetings, Wednesdays 12pm Pacific

Stefan. I would like to simply listen in. I cant seem to find the meeting ID that we need to call in. On Tue, Oct 16, 2018 at 6:42 PM Allan Haldane wrote: > I'll try to make it, especially as it looks like you want to discuss two > of my PRs! :) > > I have a different meeting a bit before then w

[Numpy-discussion] A zeros_like implementation based on calloc instead of copyto

Hello, Currently, `zeros_like` is based `copyto` as opposed to `calloc`. This causes inconsistencies in the amount of time it takes to create an array with `zeros` + `shape` and `zeros_like` for large arrays. This was first raised https://github.com/numpy/numpy/issues/9909 It seems to me that a m

Re: [Numpy-discussion] ndrange, like range but multidimensiontal

ase? > > Tuples are just one of the four options I listed in a previous message. > The downside of tuples is there’s no easy way to say “take just the first > axis of this range”. > Whatever we pick, the return value should be such that > np.array(ndrange(...))[ind] > == ndran

Re: [Numpy-discussion] ndrange, like range but multidimensiontal

Eric, interesting ideas. > __getitem__(Tuple[int]) which returns numpy scalars I'm not sure what you mean. Even if you supply a numpy uint8 to range, it still returns a python int class. Would you like ndrange to return a tuple of `uint8` in this case? ``` In [3]: a = iter(range(np.uint8(10)))

Re: [Numpy-discussion] ndrange, like range but multidimensiontal

I’m really open to these kinds of array extensions but, I (personally) just don’t know how to do this efficiently. I feel like ogrid and mgrid are probably enough for people that want think kind of feature. My implementation would just be based on python primitives which would yield performance si

Re: [Numpy-discussion] ndrange, like range but multidimensiontal

8 at 21:59 Stephan Hoyer wrote: > >> The speed difference is interesting but really a different question than >> the public API. >> >> I'm coming around to ndrange(). I can see how it could be useful for >> symbolic manipulation of arrays and indexing operatio

Re: [Numpy-discussion] ndrange, like range but multidimensiontal

gt; interface. > > That said, I'm not convinced this is really worth the trouble. I think the > nested loop is still pretty readable/clear, and there are few times when > I've actually found ndindex() be useful. > > On Mon, Oct 8, 2018 at 12:35 PM Allan Haldane > wrot

Re: [Numpy-discussion] ndrange, like range but multidimensiontal

Allan, Sorry for the delay. I had my mailing list preferences set to digest. I changed them for now. (I hope this message continues that thread). Thank you for your feedback. You are correct in identifying that the real feature is expanding the `ndindex` API to support slicing. See comments about

[Numpy-discussion] ndrange, like range but multidimensiontal

Hi All, I've been using numpy array objects to store collections of 2D (and soon ND) variables. When iterating through these collections, I often found it useful to use `ndindex`, which for `for loops` behaves much like `range` with only a `stop` parameter. That said, it lacks a few features that