[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?