[enriquto]

It would be nice to have an equivalent post, but with programming languages. The fact that different programs perform an identical computation is important. For example, in Python/numpy you can write

    c = 0
    for i in range(u.size):
        c = c + u[i] * v[i]

or

    c = u.T @ v

and even if the result is identical, the computation is not, the first one being orders of magnitude slower. There is no good reason for it to be so, unfortunately.

[lordgrenville]

I was with you until your last line, which I categorically disagree with. These two alternatives perfectly map to two different ways of thinking about the vector c:

- As a regular array (for someone with Python experience but no knowledge of linear algebra). In this case you can just loop over it as with any iterable.

- As a vector, with the associated mathematical properties. In this case you can operate on the entire vector, which is much faster; this happens to be because of implementation details (using C structures instead of Python lists, parallelisation, whatever), but is also just highly intuitive.

I'd argue that this is exactly what Tao is saying, about how different notations suit different contexts, and that allowing both methods in no way violates the Zen of Python (in reference to jimhefferon's comment).

[enriquto]

My problem is a practical one, not philosophical. I would expect that the computer operations in both cases are identical and thus the performance exactly the same. It is 2020 and optimizing compilers exist, and even JITs. The first code is just a notation for the second one. The fact that the first code is extremely slow (thing about iterating over all the pixels of a video sequence) is utterly disheartening. Of course, in that particular case you can say "just use the vectorized version", but in practice not all the computations that you need to do can be expressed in that form. If you try to iterate, in python, over all the pexels of a realtime video using integer indices you are in for a world of pain; it is just not possible and this is a major limitation of the expressivity of the language.

[lordgrenville]

It isn't just notation, though. It's a different way of operating. For example, the following adaptation of your code:

    c = 0
    for i in range(u.size):
        if u[i] < u[i + 1]:
            c = c + u[i] * v[i]
        else:
            c = 0

cannot be vectorised (ignoring the off-by-one error for simplicity's sake).

Saying that the Python interpreter should reinterpret the iterative code as if it were vectorised isn't increasing the expressivity, it's reducing it, by overriding the user's intentions.

[enriquto]

My point exactly! If I need to implement your algorithm in Python, why am I condemned to be hopelessly slow? Or worse, condemned to find a "trick" that vectorizes this code while it becomes unreadable?

[jimhefferon]

When Python first came out, one of its most appealing characteristics was that, in very strong contrast to Perl's There's-More-Than-One-Way, in Python there was a canonical way. That's no longer true, and it makes the language less valuable.