[nis251413]

The syntax of actual array languages can be beautifully concise and expressive. You can express mathematical formulas in ways that makes sense when you read a single line, and once you get used to the notation and some originally non-intuitive quirks (from a programming background perspective), you can write in very few lines what otherwise would take you several lines of rather ugly, less readable code.

In my view, python+numpy is not actually an array language. Numpy as a library adds vectorization operations to python in order to help with speed. This is different. It does not (intend to) bring the advantages that array language syntax has, even if it was a bit more consistent.

[throwaway314155]

Does numpy market itself as an array language or something?

[nis251413]

Not that I know of, and I did not claim it does.

[throwaway314155]

Guess I'm just curious why you think comparisons to array languages are so naturally apt, when most developers haven't even touched an array language.

[nis251413]

I mean, the article and discussion are about numpy's syntax around vectorised code and problems people have with that. Many comments make comparisons with matlab, and I am pointing that a language allowing you do use arrays and write vectorised code, and a language being an array language are not the same thing. Writing vectorised code in a language were everything is based on arrays is in general more natural. The variable definitions are simpler (you do not specify what is array and what is not because everything is an array), and operations tend to work more consistently. Eg in matlab operations are by default done column-wise, because that's how the language is designed and works internally. So functions acting on 2+D arrays act by default column-wise, it does not depend on other context, and they are designed so in order to be faster, not merely consistent to the user. Consistency comes from how arrays are internally represented in memory and the need to have fast code, not just as an arbitrary design choice at the highest level.

Most developers do not touch array languages but I guess most developpers don't in general (need to) vectorise code this way and avoid loops (because they work in other problem domains, use lower level languages etc). If anything, not all problems can be vectorised anyway (or at least elegantly). But if one writes vectorised code, doing that in an array language makes more sense.

[aborsy]

Yeah. Compare

A = [1, 2; 3, 4];

x = [5; 6];

y = A * x;

with this uglier version:

import numpy as np

A = np.array([[1, 2], [3, 4]])

x = np.array([[5], [6]])

y = A @ x

[threeducks]

You don't have to wrap the lists in np.array if you use NumPy functions (or if one of the arguments already is a NumPy array, which usually is the case):

    from numpy import *

    A = [[1, 2], [3, 4]]
    x = [[5], [6]]
    y = dot(A, x)

[nis251413]

That's nice, but only works, as I understand it, if you use numpy-only functions, which means that you should not use those who denote also base-pythonic, eg +,* etc operations, because then they are interpreted differently. Eg `A + x` gives

    [[1, 2], [3, 4], [5], [6]] 

instead of

    array([[ 6,  7],[ 9, 10]])

You have to keep track of the context there to know what you can do and what not I guess, which is not ideal.