Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

pytriqs '*' operator is dot product -- not pythonic #599

Open
DerWeh opened this issue Jun 25, 2018 · 4 comments
Open

pytriqs '*' operator is dot product -- not pythonic #599

DerWeh opened this issue Jun 25, 2018 · 4 comments

Comments

@DerWeh
Copy link
Contributor

DerWeh commented Jun 25, 2018

Correct me if I am wrong, but it seems to me that you overloaded * with matrix multiplication.
This is very contra-intuitive from a python point of view. I think it should be depreciated and a dot function should be introduced.

The reason is simply consistency. In numpy, which is the basis for most scientific calculations in python, * is element-wise multiplication.

PEP 465 even introduces a dedicated infix operator for matrix multiplication (which is part of Python 3.5's syntax). This is the @ operator.

Hence, I think using * for matrix multiplication reduces readability. People familiar with numpy or python would expect and element-wise product.

@HugoStrand
Copy link
Member

Dear DerWeh,

In principle I agree with you. However, if you take a rank 2 numpy.ndarray and you turn it into a matrix,

import numpy as np
A = np.random.random((5, 5))
B = A * A # element wise product
M = np.mat(A)
C = M * M # matrix product

I think the rationale for a matrix valued greens function is that it is matrix valued, and hence default to matrix multiplication.

Do you have a more explicit example on how this gives unexpected behavior?

Best, Hugo

@parcollet
Copy link
Member

Yes, Gf are matrix valued by default.
Probably we should use np.matrix instead of np.array ?
It would make the API more consistent.
Would it break code ?
@HugoStrand : Can you say if this replacement would be affect codes ?
@Wentzell : opinion ?

@Wentzell
Copy link
Member

Probably we should use np.matrix instead of np.array ?
It would make the API more consistent.

I agree that this would be much more consistent!
We should explore if and how much code this would break..

@Wentzell
Copy link
Member

Wentzell commented Aug 11, 2020

Unfortunately the use numpy matrix is deprecated.
This is unfortunate because numpy matrix would be the proper solution here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants