Matrix Sampling - Structure

[jolyonb]

So, let's sort out how matrix sampling should work, in terms of classes and subclasses. Here's a proposal.

• ArraySamplingSet. Abstract class. Properties: complex (bool), shape (tuple of integers) and norm (value, range or RealInterval).
  • VectorSamplingSet. Abstract class. Overrides shape definition (integers >= 2 (coerced), or a (n,) tuple).
    • RealVectors. Overrides complex property definition.
    • ComplexVectors. Overrides complex property definition.
  • MatrixSamplingSet. Abstract class. Overrides shape definition ((m, n) tuple).
    • GeneralMatrices. Abstract class. Properties: triangular (None, upper, lower).
      • RealMatrices. Overrides complex property definition.
      • ComplexMatrices. Overrides complex property definition.
    • SquareMatrixSamplingSet. Abstract class. Overrides shape definition (integers >= 2 (coerced), or a (n, n) tuple).
      • OrthogonalMatrices. Properties: unitdet (bool) (norm and complex are ignored).
      • UnitaryMatrices. Properties: unitdet (bool) (norm and complex are ignored).
      • IdentityMatrixMultiples. Properties: coefficient (range or ScalarSamplingSet) (norm and complex are ignored).
      • SquareMatrices. Properties: symmetry (any, diagonal, symmetric, antisymmetric, hermitian, antihermitian), trace (any, zero), det (any, one, zero) (norm is ignored if det is set to one).

I think this should allow for ArraySamplingSet to write a generic sampler according to complex, shape and norm to cover pretty much everything except for the SquareMatrixSamplingSet subclasses. (GeneralMatrices will need to perform the triangular fix is all, I think.)

Comments welcome. Perhaps we should also break out matrix sampling into a separate file?

[jolyonb]

@ChristopherChudzicki Any thoughts on this structure? I've got some time to implement it this week, if you give me a green light!

[ChristopherChudzicki]

@jolyonb This seems good. I really like your suggestion to use configuration keys to facilitate mix and matching matrix properties.

Question: In OrthogonalMatrices and UnitaryMatrices, what is the unitdet (bool) key? Why bool? Should this be unitdet ( Any(-1, +1)) for Orthogonal and unitdet (number) for Unitary?

Thought: There are multiple ways to get complex square matrices ComplexMatrices(shape=(3,3)) or SquareMatrices(shape=3, complex=True). But I don't think that's a problem. (I thought about suggesting to scrap the Real/Complex classes, and just use keys. But we already need Real classes for backward compat, and they are more descriptive names.)

Sorry slow reply—first week of spring term :)

[jolyonb]

Not a problem :-)

My thoughts on unitdet were that U(n) and O(n) have arbitrary determinants, while SU(n) and SO(n) have unit determinants, and the idea was to have a way to select a unit determinant by setting a flag to true.

I don't mind that there are multiple ways to make square matrices (real or complex). RealMatrices and ComplexMatrices can handle whatever shape you want, including square matrices. If you want special square properties though, go for the SquareMatrices utility. There will always be some overlap... I'm fine keeping Real and Complex versions of things, rather than using keys. It's obvious from the name what's going on.

[ChristopherChudzicki]

My thoughts on unitdet were that U(n) and O(n) have arbitrary determinants, while SU(n) and SO(n) have unit determinants, and the idea was to have a way to select a unit determinant by setting a flag to true.

Does "unit" mean unit magnitude, or does "unit" mean 1 in this case? The usual definition for U(n) and O(n) have unit magnitude determinants, with SO(n) and SU(n) having det=1, right? But maybe scaling the dets (orthogonal but not normalized rows) is useful , too? Whatever you decide is fine 👍

[jolyonb]

"unit" was meant to mean exactly 1 here. Anyway, that part has to wait for a new version of scipy, so that's a discussion for later ;-)