Summary
SymmetryGroup currently stores generator literals together with a separate axes tuple. That is fine for the core API, but it can be awkward for inspection/debugging because the generators are local to axes, not full-rank.
Example:
import whest as we
G = we.SymmetryGroup.young(((2, 3),))
print(G)
# SymmetryGroup([1, 0], axes=(2, 3))
For some workflows it would be more convenient to expose either:
- a
num_axes / full-rank construction form, or
- a convenience method that returns generators re-indexed onto
tuple(range(num_axes))
For example:
- current:
SymmetryGroup([1, 0], axes=(2, 3))
- possible convenience view:
SymmetryGroup([0, 1, 3, 2], num_axes=4)
Notes
This is an interface ergonomics request, not a correctness bug.
It should stay out of #51 unless the change can be made without reopening the symmetry API design.
Summary
SymmetryGroupcurrently stores generator literals together with a separateaxestuple. That is fine for the core API, but it can be awkward for inspection/debugging because the generators are local toaxes, not full-rank.Example:
For some workflows it would be more convenient to expose either:
num_axes/ full-rank construction form, ortuple(range(num_axes))For example:
SymmetryGroup([1, 0], axes=(2, 3))SymmetryGroup([0, 1, 3, 2], num_axes=4)Notes
This is an interface ergonomics request, not a correctness bug.
It should stay out of
#51unless the change can be made without reopening the symmetry API design.