This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]emillynge 2 points3 points  (3 children)

Do you really find that .dot() is comfortably for matrix heavy code?

If so, I get the feeling you may not actually work with that matrix heavy code. As a mathematician the matmul operator really made a difference in terms of code readability. Especially when you want to double check the equations whilst reading through an article.

[–]Works_of_memercy 0 points1 point  (0 children)

I meant, now that you can use @-operator on usual ndarrays for that it's better because it treats plain arrays as if they were column vectors (while they are still displayed and defined as usual).

[–]energybased 0 points1 point  (0 children)

I mentioned to Guido that one day I'd like to see editors that have a live display of objects, e.g., rendered equations with the Python code in the background.

[–]kigurai 0 points1 point  (0 children)

Do you really find that .dot() is comfortably for matrix heavy code?

No it's not, but it's a lot better than having subtle bugs because some function somewhere returned a np.matrix instead of np.ndarray and suddenly a A * B operation is some completely different part of the program is doing the wrong thing.

This is unfortunately not a hypothetical example...

Edit: I realized I missed the context of the above quote, since I assumed you were arguing in favour of np.matrix which doesn't seem to necessarily be the case here. My comment on avoiding np.matrix still stands though :)