Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

NumPy 2.0

numpy.org

Post reply on HN
Print view View original

11–20 of 78 posts

Re: NumPy 2.0

#11

Post by brcmthrowaway »

scoresmoke wrote: post #4
fbdab103 wrote: post #3

Any notable highlights for a consumer of Numpy who rarely interfaces directly with it? Most of my work is pandas+scipy, with occasionally dropping into the specific numpy algorithm when required. I am much more of an "upgrade when there is a X.1" release kind of guy, so my hat off to those who will bravely be testing the version on my behalf.

The most important changes are deprecations of certain public APIs: https://numpy.org/devdocs/release/2.0.0-notes.html#deprecati... One new interesting feature, though, is the support for string routines: https://numpy.org/devdocs/reference/routines.strings.html#mo...

Does numpy use GPU?

Re: NumPy 2.0

#12

Post by notatoad »

it feels like the first major release in 18 years which introduces lots of breaking changes should just be a fork rather than a version.

let me do `pip install numpy2` and not have to worry about whether or not some other library in my project requires numpy<2.

Re: NumPy 2.0

#13

Post by ahurmazda »

brcmthrowaway wrote: post #11
scoresmoke wrote: post #4

Earlier quoted context omitted.

The most important changes are deprecations of certain public APIs: https://numpy.org/devdocs/release/2.0.0-notes.html#deprecati... One new interesting feature, though, is the support for string routines: https://numpy.org/devdocs/reference/routines.strings.html#mo...

Does numpy use GPU?

No.

You may want to check out cupy

https://cupy.dev/

Re: NumPy 2.0

#14

Post by ayhanfuat »

ssahoo wrote: post #7
amelius wrote: post #5

Earlier quoted context omitted.

> One new interesting feature, though, is the support for string routines Sounds almost like they're building a language inside a language.

No. Native python ops in string suck in performance. String support is absolutely interesting and will enable abstractions for many NLP and LLM use cases without writing native C extensions.

> Native python ops in string suck in performance.

That’s not true? Python string implementation is very optimized, probably have similar performance to C.

Re: NumPy 2.0

#15

Post by ahurmazda »

scoresmoke wrote: post #4
fbdab103 wrote: post #3

Any notable highlights for a consumer of Numpy who rarely interfaces directly with it? Most of my work is pandas+scipy, with occasionally dropping into the specific numpy algorithm when required. I am much more of an "upgrade when there is a X.1" release kind of guy, so my hat off to those who will bravely be testing the version on my behalf.

The most important changes are deprecations of certain public APIs: https://numpy.org/devdocs/release/2.0.0-notes.html#deprecati... One new interesting feature, though, is the support for string routines: https://numpy.org/devdocs/reference/routines.strings.html#mo...

This one will be rough :|

> arange’s start argument is positional-only

Re: NumPy 2.0

#16

Post by dahart »

The thing I want most is a more sane and more memorable way to compose non-element-wise operations. There are so many different ways to build views and multiply arrays that I can’t remember them and never know which to use, and have to relearn them every time I use numpy… broadcasting, padding, repeating, slicing, stacking, transposing, outers, inners, dots of all sorts, and half the stack overflow answers lead to the most confusing pickaxe of all: einsum. Am I alone? I love numpy, but every time I reach for it I somehow get stuck for hours on what ought to be really simple indexing problems.

Re: NumPy 2.0

#17

Post by make3 »

notatoad wrote: post #12

it feels like the first major release in 18 years which introduces lots of breaking changes should just be a fork rather than a version. let me do `pip install numpy2` and not have to worry about whether or not some other library in my project requires numpy<2.

knowing how careful the NumPy devs are, this was likely a very well pondered decision & all of these deprecations likely have been announced for a long time. Seeing knee jerk reactions like this is annoying.

Re: NumPy 2.0

#18

Post by akasakahakada »

dahart wrote: post #16

The thing I want most is a more sane and more memorable way to compose non-element-wise operations. There are so many different ways to build views and multiply arrays that I can’t remember them and never know which to use, and have to relearn them every time I use numpy… broadcasting, padding, repeating, slicing, stacking, transposing, outers, inners, dots of all sorts, and half the stack overflow answers lead to th…

To be honest einsum is the easiest one. You get fine control on which axis matmul to which. But I wish it can do more than matmul.

The others are just messy shit. Like you got np.abs but no arr.abs, np.unique but no arr.unique. But now you have arr.mean.

Sometimes you got argument name index, sometimes indices, sometimes accept (list, tuple), sometime only tuple.

Re: NumPy 2.0

#19

Post by ayhanfuat »

> The default integer type on Windows is now int64 rather than int32, matching the behavior on other platforms

This was a footgun due to C long being int32 in win64. Glad that they changed it.

Re: NumPy 2.0

#20

Post by samsartor »

akasakahakada wrote: post #18
dahart wrote: post #16

The thing I want most is a more sane and more memorable way to compose non-element-wise operations. There are so many different ways to build views and multiply arrays that I can’t remember them and never know which to use, and have to relearn them every time I use numpy… broadcasting, padding, repeating, slicing, stacking, transposing, outers, inners, dots of all sorts, and half the stack overflow answers lead to th…

To be honest einsum is the easiest one. You get fine control on which axis matmul to which. But I wish it can do more than matmul. The others are just messy shit. Like you got np.abs but no arr.abs, np.unique but no arr.unique. But now you have arr.mean. Sometimes you got argument name index, sometimes indices, sometimes accept (list, tuple), sometime only tuple.

https://github.com/mcabbott/Tullio.jl is my favorite idea for extending einsum notation to more stuff. Really hope numpy/torch get something comparable!
Post reply on HN