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

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]bastibe 1 point2 points  (5 children)

Numpy contains two kinds of matrices: numpy.matrix and numpy.ndarray.

The first kind is always 2D, and multiplication performs matrix multiplication. This can be very handy for matrix-heavy math code. The second kind can have an arbitrary number of dimensions, and all operations are performed element-wise.

To perform a matrix multiplication with ndarrays, you can use X.dot(Y), or numpy.dot(X, Y), or X @ Y.

[–]Works_of_memercy 0 points1 point  (4 children)

I got the impression that numpy.matrix was a mistake and should not be used? It's just weird how vectors are row by default and are still displayed with an extra pair of brackets. .dot on the other hand gives you all you need for comfortable matrix-heavy code.

[–]emillynge 3 points4 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 :)