Ms/generalized euclidean matrices

[MatthiasSachs]

This pull requests contains implementations of subdivision of 3x3 matrix functions into

• EuclideanMatrix <: AbstractEuclideanMatrix (no particular symmetry)
• SymmetricEuclideanMatrix <: AbstractEuclideanMatrix (symmetric, i.e., A = A^T)
• AntiSymmetricEuclideanMatrix <: AbstractEuclideanMatrix (anti-symmetric, i.e., A = -A^T)

The implementation is not ideal (redundant lines of code are avoided via code-generation instead of making efficient use of the type hierarchy). Also, for some weird reason coupling matrices for anti-symmetric matrix function bases tend to have 1 or more rows consisting of only zeros which I presume suggests that there is some issue with the clean-up of the coupling matrix in this particular setting.

I presume that a more elegant way of implementing the symmetries would be to make EuclideanMatrix a parametrized composite type of the form `EuclideanMatric{T,S} where S takes the values Val{:general}, Val{:symmetric}, Val{:antisymmetric}.

[cortner]

thank you - I'll take a look as soon as I can.

[MatthiasSachs]

I tried to remove redundant code. But weirdly enough if

for E = (:EuclideanMatrix,:SymmetricEuclideanMatrix, :AntiSymmetricEuclideanMatrix)
   eval(
      quote
          complex(φ::$E) = $E(complex(φ.val))
       )
end

is replaced by

complex(φ::M) where {M <: AbstractEuclideanMatrix} = M(complex(φ.val))

an error is produced. Shouldn't the two codes do the same, i.e., generate a method complex(φ::M) for each subtype M of AbstractEuclideanMatrix ? I guess I might be missing some subtlety coming from the additional parameter T of the composite types EuclideanMatrix{T}, SymmetricEuclideanMatrix{T} ?