NWChemEx / TensorWrapper

A type-erased wrapper around various tensor backends
https://nwchemex.github.io/TensorWrapper/
Apache License 2.0
0 stars 0 forks source link

A few questions/comments on symmetry.rst #157

Closed twindus closed 1 year ago

twindus commented 1 year ago

Related to https://github.com/NWChemEx-Project/TensorWrapper/blob/master/docs/source/developer/design/symmetry.rst

Line 40: Instead of a slice mapping to itself, shouldn't it be a slice mapping to another slice? Or to be more general to itself or another slice.

Line 130: Does nesting being out of scope present a problem when we use nested tensors in our algorithms? Or is it out of scope for the moment and will be considered at a later date?

Figure 5: The relationship between Symmetry and SymmetryOp is not clear to me from the image. I believe that Symmetry will contain the SymmetryOp information, but I am not sure. Also, might it be useful to invert the diagram so that the base classes are a the top of the diagram? I know it doesn't really matter since you defined the direction of the arrows, but I believe it is more "standard" that way.

Line 225: If I want an asymmetric rank 2 tensor, would I do Symmetry sa (2); If so, perhaps that default should be added as well.

Line 260: It seemed like something else was meant to be said after "Having to specify all of the asymmetric pairs is tedious," since what followed didn't quite make sense to me. I changed it to be a sentence, but it should be modified if there was a different intent.

Line 375: Should row 4 be row 3?

This is a more general question: If I identify the symmetries of the tensors and I operate on one of the elements/tiles/slices/chips/etc that are symmetrically related to another element/tile/slice/chip/etc, the code (under the hood) should figure out what piece is actually stored in physical memory and where to do the update. I assume that is correct?

ryanmrichard commented 1 year ago

There will be a PR incoming, but I wanted to answer the questions here.

Line 40: Instead of a slice mapping to itself, shouldn't it be a slice mapping to another slice? Or to be more general to itself or another slice.

AFAIK that's the standard mathematical verbiage, although I can see how it's confusing. Wording has been changed.

Line 130: Does nesting being out of scope present a problem when we use nested tensors in our algorithms? Or is it out of scope for the moment and will be considered at a later date?

I just deleted this section. What I was trying to say is that I don't think nesting requires anything special from the symmetry component, even though I originally thought it would.

Figure 5: The relationship between Symmetry and SymmetryOp is not clear to me from the image. I believe that Symmetry will contain the SymmetryOp information, but I am not sure. Also, might it be useful to invert the diagram so that the base classes are a the top of the diagram? I know it doesn't really matter since you defined the direction of the arrows, but I believe it is more "standard" that way.

SymmetryOp objects are the elements of a Symmetry object. I explicitly added this and redrew the figure.

Line 225: If I want an asymmetric rank 2 tensor, would I do Symmetry sa (2); If so, perhaps that default should be added as well.

Added.

Line 260: It seemed like something else was meant to be said after "Having to specify all of the asymmetric pairs is tedious," since what followed didn't quite make sense to me. I changed it to be a sentence, but it should be modified if there was a different intent.

The change is correct.

Line 375: Should row 4 be row 3?

Yep.

This is a more general question: If I identify the symmetries of the tensors and I operate on one of the elements/tiles/slices/chips/etc that are symmetrically related to another element/tile/slice/chip/etc, the code (under the hood) should figure out what piece is actually stored in physical memory and where to do the update. I assume that is correct?

Figuring out where things live is dictated by the physical layout. In theory users only interact with the logical layout so they shouldn't have to worry about this directly. That said,at least initially, users will probably be playing with the physical layout too.

I added to the "out of scope" section that exploiting symmetry is not done by the symmetry component and that it falls to the layout and backends.