WIP: New RPI Coeff Implementation #17
Conversation
test cg and RI functions
cortner
changed the title
|
I extended the test suite to make it comprehensive. At the moment the tests fail when an (nn, ll) doesn't have any invariants at all, e.g., for It seems your new code doesn't like this, but I think this needs to be allowed - one can't expect the user to do this filtering i.e. to know a priori what the zeros in the CG are? |
|
I rewrite the test functions a bit so that the same random batch can be used for all tests so the spans can now be tested more easily. I'll let you clean up the rest of the tests please. |
Give Llset a new and unified implementation. The generation of CG are changed correspondingly.
Test for L = 1:4
Add an interface for EQM - to use the current code, at most 5 lines in EQM should be changed
Avoid ComplexF64 allocation for real-valued matrices
| @@ -0,0 +1,169 @@ | |||
| # Alternative to the computation of rotation equivariant coupling coefficients | |||
There was a problem hiding this comment.
If this is to become the new main implementation of O3, can you please move it to the main src folder and rename it O3.jl.
There was a problem hiding this comment.
I guess this can hardly be done right now because O3_alternative can just provide the coupling coefficients for the complex spherical vector case. It is still missing how the CCs for the real spherical vectors can be obtained in this way. So I think we can retain both (or even do a merge?) for now? I will no matter what file an issue mentioning this.
|
It seems good to go to me. In terms of O3 and O3_alternative - it should be filed as an issue, but I am also wondering if it could be a follow-up comment on Issue #3, which indeed concerns the speed of evaluating the coupling coefficients (maybe we will need to rename the issue though). What is left now is that we haven't yet had a faster evaluation of the CCs for the real equivariant vector, and once it has been implemented in O3_alternative, we can do a replacement and retire O3.jl. Another reason why I think this might be a good compromise is that retaining both O3 and O3_alternative for now would allow anyone who uses EQM (if any...) not to change anything. |
Continuing from #16