3 ms·

It would be nice to have an equivalent post, but with programming languages. The fact that different programs perform an identical computation is important. F

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.

jimhefferon 6y ago
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.
lordgrenville 6y ago
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 6y ago
  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 6y ago
    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 6y ago
      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 6y ago

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.

lordgrenville 6y ago

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 6y ago
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 6y ago
  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 6y ago
    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?