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

Feedback on API, project=, projection=, other? #874

Open
zerothi opened this issue Nov 22, 2024 · 0 comments
Open

Feedback on API, project=, projection=, other? #874

zerothi opened this issue Nov 22, 2024 · 0 comments

Comments

@zerothi
Copy link
Owner

zerothi commented Nov 22, 2024

Describe the issue
We have many routines which allows various return values.

For instance we have:

    def inner(
        self,
        ket=None,
        matrix=None,
        projection: Literal["diag", "atoms", "basis", "matrix"] = "diag",
    ):

Now this projection argument is a bit annoying to me, we changed from sum to this, but I don't think it is sufficient.
So what would our users expect, and how should they look like?

There are also interpretation differences between many parts of sisl where the keywords are not consistent.

So, should we rename this? Should different projections have specific methods?
The reason for changing from sum was that it became annoying to have 2 flags, that were mutually exclusive.

Also, when we get there, the different allowed values should be streamlined.

  • trace|sum (sum of diagonal of matrix)
  • diag|basis|orbitals, diagonal of matrix
  • atoms, trace for each atom of the matrix
  • matrix, full matrix

Others?

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

1 participant