16 comments

[ 3.2 ms ] story [ 40.6 ms ] thread
Why not go to the source? https://numpy.org/devdocs/user/absolute_beginners.html

Is there something wrong there? We (NumPy) would love to get feedback and improve it.

This would be a natural “next step” https://numpy.org/devdocs/user/theory.broadcasting.html

Wow, I've been using NumPy for quite a while and I've never seen this alternative documentation site, I've only ever seen https://numpy.org/doc/stable/user/absolute_beginners.html
Hahaha seriously this alt documentation is actually an excellent intro with very clear explanation of foundational concepts. Makes for a decent cheat sheet, wish I'd found this sooner!
Excellently written documentation. Beautiful visualizations. Thanks for the link.
I am not the creator of the blog post, just to be clear.

It never hurts to have several sources explaining the same concepts. It's like course books, they usually have different ways to explain the same concepts and focus on different aspects. Different people prefer different styles and sometimes you have to combine multiple sources to get a good understanding of the concepts that are being explained. I don't think that it's an indication that there's anything wrong with the source.

Since you asked for feedback though, on my laptop half the page is taken up by menus on the right and left side. It would be nice if those parts could be hidden so that you only see the content. I could do that by using reader view in my browser but that removes the layout and the images, which is kind of important here.

I really don't enjoy numpy, the syntax is so cumbersome compared to the alternatives, some operations are in np/rng while others are defined as methods, and some operations are by reference (hi bugs) while others copy.

I really wish some aspects of matlab or k could be adapted into the language. Like adverbs, letting you type .* to multiply two matrices by element, or {x$x}/ for numerically finding eigenvectors of a Markov transition matrix.

AFAIK all array oriented languages sometimes return copies and sometimes return views. Not sure if this is what you mean by operations by reference. It's a common abstraction leak necessary for efficiency reasons that causes lots of problems to newcomers (and sometimes to experienced developers too...)
In k, returning copies and views is made very distinct through the assignment operators : and ::

    q)x:til 100
    q)y::10 10#x
    q)y
    0  1  2  3  4  5  6  7  8  9
    10 11 12 13 14 15 16 17 18 19
    20 21 22 23 24 25 26 27 28 29
    30 31 32 33 34 35 36 37 38 39
    40 41 42 43 44 45 46 47 48 49
    50 51 52 53 54 55 56 57 58 59
    60 61 62 63 64 65 66 67 68 69
    70 71 72 73 74 75 76 77 78 79
    80 81 82 83 84 85 86 87 88 89
    90 91 92 93 94 95 96 97 98 99
    q)x:x+1
    q)y
    1  2  3  4  5  6  7  8  9  10
    11 12 13 14 15 16 17 18 19 20
    21 22 23 24 25 26 27 28 29 30
    31 32 33 34 35 36 37 38 39 40
    41 42 43 44 45 46 47 48 49 50
    51 52 53 54 55 56 57 58 59 60
    61 62 63 64 65 66 67 68 69 70
    71 72 73 74 75 76 77 78 79 80
    81 82 83 84 85 86 87 88 89 90
    91 92 93 94 95 96 97 98 99 100
Alternatives? I really have never heard of any serious alternatives if you actually need the speed and ubiquity of numpy. Maybe if you're willing to leave Python behind and go to C, but frankly within the Python ecosystem there just isn't a realistic alternative if you even remotely need efficient numerical processing.
Julia is the best 'alternative', imho it's much better. You don't need to use C to get performance.
Julia is definitely a fair counterpoint to my comment about C, but I don't think it really has comparable ubiquity to numpy + Python and C/C++ in the computational science/numerical computing communities. What is nice about ubiquity is that if I need to use a rather esoteric numerical technique for research, odds are there are at least prototypes for it already made in numpy + Python or C/C++, if not a fully-fledged, well tested package for it.

Julia might be catching up there. I hope so, because I do think my area of computational science would benefit from not only relying on 1 or 2 programming language ecosystems for 99% of all work.

> odds are there are at least prototypes for it already made in numpy + Python or C/C++, if not a fully-fledged, well tested package for it.

Odds are that there is one in Julia as well - if not only in Julia. Also, with PyCall you can just seamlessly use any Python library. So, use Julia - the better language for scientific programming - and use Python libraries where needed. This is one of the reasons I'm investing time into Julia, especially for deep learning and natural language processing.

Speed is not really an argument against k though, there are cases where it's decidedly faster than C
Sure, I was speaking in terms of within the Python ecosystem. I just use C as an example because it's the main alternative for numerical computing in my field.
Code snippets in a blog-post should use special formatting and syntax highlighting, so as to distinguish it from the rest of the text