Clear articulation of why Numpy syntax is provincial and difficult to learn. Perhaps the clearest part of it clicks when the author compares the triple-nested loop to the numpy-function approach. The former is IMO (And the author thinks so) much easier to understand, and more universal.
Pretty sure Numpy’s einsum[1] function allows all of this reasoning in vanilla numpy (albeit with a different interface that I assume this author likes less than theirs). Quite sure that first example of how annoying numpy can be could be written much simpler with einsum.<p>[1]: <a href="https://numpy.org/doc/stable/reference/generated/numpy.einsum.html" rel="nofollow">https://numpy.org/doc/stable/reference/generated/numpy.einsu...</a>
I think I'll just use Julia, since it has great libraries for doing matrix operations and mapping loops etc onto GPUs and handling indices etc. And if you need some Python library it's easily available using the fantastic PyCall library.<p>This is a big improvement over numpy, but I don't see much of a compelling reason to go back to Python.
Lots to like here but I'm not so sure about this:<p>> In DumPy, every time you index an array or assign to a dp.Slot, it checks that all indices have been included.<p>Not having to specify all indices makes for more generic implementations. Sure, the broadcasting rules could be simpler and more consistent, but in the meantime (implicit) broadcasting is what makes NumPy so powerful and flexible.<p>Also I think straight up vmap would be cleaner IF Python did not intentionally make lambdas/FP so restricted and cumbersome apparently due to some emotional reasons.
I’ve known some people who didn’t want to learn the syntax of numpy and did it all in loops, and the code was not easy to read. It was harder to read. The fundamental issue is that operations on high dimensional arrays are very difficult to reason about. Numpy can probably be improved, but I don’t think loops are the answer.
In the way that `ggplot2` tries to abstract those common "high dimensional" graphing components into an intuitive <i>grammar</i>, such that you may in many places be able to <i>guess</i> the sequence of commands correctly, I would love to see an equivalent ergonomic notation. This gets part way there by acknowledging the problem.<p>Mathematical operations aren't obliged to respect the Zen of Python, but I like the thought that we could make it so that most have an <i>obvious</i> expression.
It seems like a neat idea. If it can just be layered on top of Jax pretty easily… I dunno, seems so simple it might actually get traction?<p>I wish I could peek at the alternative universe where Numpy just didn’t include broadcasting. Broadcasting is a sort of ridiculous idea. Trying to multiply a NxM matrix by a 1x1 matrix… should return an error, not perform some other operation totally unrelated to matrix multiplication!
I’m not convinced by the loops proposal. TensorFlow had this kind of lazy evaluation (except I guess TF was the worst of both worlds) and it makes debugging very difficult to the point that I believe it’s the main reason PyTorch won out. Such systems are great if they work perfectly but they never do.<p>NumPy definitely has some rough edges, I sympathize with the frustrations for sure.
I don't think this is such a great solution. With regular numpy you can create functions that take arrays with arbitrary shapes. It is not easy, as the author explained in a prior post, but it is doable. But with loops this just doesn't work. The number of nested loops depends on the shape of the inputs.<p>My solution, very, very inelegant, was to focus on the scalar case, and ask Copilot to vectorize my code. I did that just the last two days. It is not all that easy. Copilot will give you something, but you still need to tweak it. In the end, I still had to write line by line the code, and make sure I understand what it is doing.
That is amazing. My main doubt would be how future proof this is. Does it wrap numpy? Or something equivalent? Does it require continuous development to keep up?<p>Also I both understand the need for declaring the matrices up front and think it's a bit of a shame that it is not seamless.<p>Here are some (ill-advised?) alternatives:<p><pre><code> X, Y, Z = dp.Slots()
with dp.Slot() as X:
...
import dp.Slot as new
X = new['i','j'] = ...
X = dp['i','j'] = ...</code></pre>
Fantastic article.<p>I don’t use numpy often enough - but this explains the many WTF moments why it’s so annoying to get numpy pieces to work together.
Always wanted to experiment with a syntax like this myself, thanks to author! I completely agree with you reasoning re complexity of mental model for indexing vs broadcasting. Moreover, it appears to me that such a representation should allow for finding more optimal low level impls (something like deeper "out of order" op fusing, idk)? I've seen a paper from either nvidia or meta around five years ago doing exactly that - translating an index-based meta-language built on top of python into cuda kernels (usually several variants and picking the best), can't find the reference unfortunately.
I think this sort of DSL construction is a perfect fit for languages with macros: Lisp, Nim, etc. I spend a lot of time on both so I might explore the possibilities. What should a higher-dimensional array indexing, looping, and broadcasting syntax even look like, if until now it's just been cludges? Is it just APL but with actual words?
Dupe. Posted a number of times the past day and a half:<p><a href="https://news.ycombinator.com/item?id=44072775">https://news.ycombinator.com/item?id=44072775</a><p><a href="https://news.ycombinator.com/item?id=44063553">https://news.ycombinator.com/item?id=44063553</a><p><a href="https://news.ycombinator.com/item?id=44078019">https://news.ycombinator.com/item?id=44078019</a><p><a href="https://news.ycombinator.com/item?id=44063490">https://news.ycombinator.com/item?id=44063490</a>
The kind of person with the background to need these operations, and who is working on the kinds of problems where this stuff comes up, is more than capable of learning numpys syntax. Its not that bad.<p>Avoiding the special purpose tools designed by and used by the people who work on these problems every day is the instinct of someone who has just started needing them and wants to solve new kinds of problems with the tools they already know. But the people with experience don't do it that way (for a reason), you need to learn what the current best solution is before you can transcend it.<p>Guys, every few months some well meaning person posts their great new library here that "fixes" something to remove all that pesky complexity. Invariably its made by some beginner with whatever it is who doesn't understand why the complexity exists, and we never hear of them or the library again. This is absolutely one of those times.