Hacker News Reader

Comment by enriquto | Hacker News Reader

Sometimes I wake up suddenly at night, sweating, terrified, and crying like a baby, because python+numpy has become a sort of standard in numerical computing.

Arrays of numbers should be a native type of a programming language used for serious numerical computing. Strings and dictionaries are nice, but I can do without. However, arrays of numbers are fundamental and it is very sad that they are accessible only via idiosyncratic libraries such as numpy or pytorch.

View on HN

Python has statically typed arrays in the standard library: in the array module (e.g. array.array).

It’s not used much for scientific computing because numpy made a better tool.

Also, the list data structure in Python is a contiguous memory array... it’s just designed to store a contiguous array of PyObject pointers, and the use case for list is exactly when the flexibility and abstraction of using PyObject data structures is more important than raw performance. You would use numpy arrays or special jitted functions or custom C-level data structures you write in Cython, etc. etc., when raw performance is the higher priority.

My point exactly. Python was not thought from the beginning as a language for numerical computing, and when you try to force it for that, there is a lot of friction. Just having to "import" a library to have sane support for arrays is silly.

I feel like that's the point of Python - only provide the barebones of what you might need initially, and then make importing the rest fast and easy. For most use cases Pythons default collections work just fine (what does an array have that a list doesn't for everyday use?), but if you need more power, just import and go.

From my point of view, numeric arrays are barebones, and strings and dictionaries are fancy data structures that I never need, but they are nevertheless elevated as features of the language itself. It would seem much more natural if it was the other way round. In my everyday life I solve linear systems in octave by doing "x=A\b", but in python it becomes very cumbersome.

On the contrary, I prefer my languages lightweight, and capable of allowing arrays (and strings, dictionaries, etc) to be implemented by libraries.

> On the contrary, I prefer my languages lightweight, and capable of allowing arrays (and strings, dictionaries, etc) to be implemented by libraries.

I agree with this philosophy! But that is certainly not at all the case with python, where fancy strings and even fancier dictionaries are readily available at the language level, instead of being implemented as separate libraries that you have to import.

If Python did not support strings nor dictionaries as basic data types, you might have a point. But it does, and it chooses to ignore multidimensional arrays and their basic operations. This is weird, and even a bit offensive when all you need to do is dealing with such arrays of numbers. You always feel like an "outsider", unlike when you program in octave or julia, for example.

To give a different perspective:

- the existence of tools for working with strings and dictionaries doesn't take away from numpy at all

- I have never been offended by a programming language or felt like an outsider while using numpy

It always seems a bit weird to me that np.einsum needs to parse a string in its own private syntax. I guess it's a good thing that at least it has tools for this!

Semi-inactive Octave dev here.

Even though I use Python every day, and I have used scipy often, I still reach for Octave whenever I need a quick calculation that I don't feel like turning into a big project.

And yeah, it's nice that matrices are first-class objects. Sometimes I miss 1-dimensional arrays or sensible strings, but it's not a big deal, and for quick, short things, the Octave syntax is still a lot easier to deal with than Python.

Most of Octave's users describe themselves as "not a programmer", despite using a programming language, so I think there's still room for this kind of software in the world.

The big challenge with leaving core data structures and interfaces to the community is fragmentation. If you look at the rust/go numerical communities the big struggle has been a lack of universal ndarray implementation.

Most numeric libraries can be Described as functions of/on ndarrays that return ndarrays, not having a language wide ndarray is the equivalent of having every library carry it's own unique list interface/implementation.

Well, you could still have a set of "core" packages for basic data structures, or an official library. For example, C++ has STL, and most libraries build on top of that.

Probably explains Fortans continued hold on numerical computing

> Probably explains Fortans continued hold on numerical computing

indeed! a sizeable part of numpy is written in fortran

Only insofar as numpy relies on BLAS and LAPACK for certain functionality, and most (all?) implementations are written in Fortran. The actual numpy source code contains no Fortran; you don't need a Fortran compiler to build numpy. Scipy does contain Fortran, though.

"certain functionality" is a bit of an understatement, here. Those are precisely the core algorithms, that allow you to do things with matrices, solve systems, etc. As you put it, numpy is simply a wrapper for this.

I think that's an unfair characterization of numpy's functionality. Numpy introduces data structures not present in the core python library (another one of your complaints about python, though it's not clear to me why it matters that numpy is a separate library), and certain manipulations do not require BLAS/LAPACK acceleration, eg. multiplying an array by a scalar (yes, I know dscal exists in BLAS) or array slicing. Further, it is possible to use numpy without any BLAS/LAPACK libraries at all, and it continues to work (albeit more slowly).

Note that most accelerated implementations of BLAS are not written in Fortran, but use e.g. SIMD instructions directly.

I'm not sure I understand your point. What's the downside of numpy arrays being "non-native"?

Dunno man. I used MATLAB for most of my thesis, and once I discovered NumPy, I switched all my code to it in a heartbeat. Yes, MATLAB is better for matrix manipulation. For everything else, Python is better. My productivity went up quite a bit.

The secret of compiled languages (like Rust and Go) is that they are all mainly designed to implement compilers. After all, self-hosting is almost always the first and most formative software engineering goal. ;)

Would this be solved by inclusion of numpy into python’s standard library? Is there a chance it might? I know it was behind syntax changed in 3.

What do you mean exactly? Can I do matrix products and slices without importing anything? Yes, that would solve the problem. But I do not think that this would be possible without major changes in the language itself.

This is not a library problem, it is a focus problem of the language. The language supports strings and dictionaries natively, as basic data types, but not numeric arrays.

yes it does. nobody actually uses them, but a non-list ordered sequence of values is actually part of the library.

https://docs.python.org/3/library/array.html

For one-dimensional arrays, python's array can be faster. It's also directly accessible through the Python C API/Cython's wrapping of it, which makes it convenient to use.

You don't have to include all of numpy into python standard library. Unifying python's existing 'array' package with numpy arrays and allowing logical and arithmetic operation and the functions in the standard lib 'math' package to operate on those arrays would get you very far. Then you can still have numpy as a separate package for people who wanted more advanced functions.

Reply on news.ycombinator.com