41–50 of 78 posts
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.
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…
I've been writing my own low-level numeric routines lately, so I'm not up-to-date on the latest news, but there have been a few ideas floating around over the last few years about naming your axes and defining operations in terms of those names [0,1,2,3]. That sort of thing looks promising to me, and one of those projects might be a better conceptual fit for you.
[0] https://nlp.seas.harvard.edu/NamedTensor
[1] https://pypi.org/project/named-arrays/
Earlier quoted context omitted.
> Native python ops in string suck in performance. That’s not true? Python string implementation is very optimized, probably have similar performance to C.
It is absolutely true that there is massive amounts of room for performance improvements for Python strings and that performance is generally subpar due to implementation decisions/restrictions. Strings are immutable, so no efficient truncation, concatenation, or modifications of any time, you're always reallocating. There's no native support for a view of string, so operations like iteration over windows or ranges h…
Earlier quoted context omitted.
From a consumer (developer consumer) point of view, I hear you. From a project point of view, there are some pretty strong contra-indicators in the last 20 years of language development that make this plan suspect, or at least pretty scary — both Perl and Python had extremely rocky transitions around major versions; Perl’s ultimately failing and Python’s ultimately taking like 10 years. At least. I think the last tim…
Could you elaborate further on this? Is it not the case that they'll still need to support numpy 1.x for at least the near-term future? My understanding was the parent comment was specifically talking about the technical difficulty of multiple versions for the same Python package, not the social problem of project and community management across breaking changes.
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…
Makes it look like they pressed publish before filling in their template, or is this on purpose?
Earlier quoted context omitted.
From a consumer (developer consumer) point of view, I hear you. From a project point of view, there are some pretty strong contra-indicators in the last 20 years of language development that make this plan suspect, or at least pretty scary — both Perl and Python had extremely rocky transitions around major versions; Perl’s ultimately failing and Python’s ultimately taking like 10 years. At least. I think the last tim…
Could you elaborate further on this? Is it not the case that they'll still need to support numpy 1.x for at least the near-term future? My understanding was the parent comment was specifically talking about the technical difficulty of multiple versions for the same Python package, not the social problem of project and community management across breaking changes.
My point, or at least the point I had in mind, was that the social and technical go together in a lot of subtle and sometimes surprising ways; in this case, I’d bet the idea of a second package name a) is a bad one because it’s likely to create differing community expectations about whether or not it’s okay to keep using the 1.0 package, and b) would let people feel okay not upgrading for a while / demanding security and bug fix point releases on 1.x longer than if the package itself just updates its major version.
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…
ChatGPT is really good at this. Using it to solve numpy and matplotlib problems is worth the cost of the subscription.
Earlier quoted context omitted.
When I started out I was basically stumbling around for code that worked. Things got a lot easier for me once I sat down and actually understood broadcasting. The rules are: 1) scalars always broadcast, 2) if one vector has fewer dimensions, left pad it with 1s and 3) starting from the right, check dimension compatibility, where compatibility means the dimensions are equal or one of them is 1. Example: np.ones((2,3,1…
Explicit internal broadcasting (by adding an axis with an explicit `indefinite` size instead of `1`) would be so much simpler to reason about. Unfortunately there is far too much existing code and python is not type-safe.
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.