WIP: rewrite MatRing to wrap a native matrix

[fingolfin]

This is code trying to address issue #1955 which I wrote last December but never finished.

@JohnAAbbott I am putting it here because it might be useful for you, e.g. you could use it as a basis and complete it (feel free to work on this PR, or copy it to a new one). Or perhaps you prefer to start from scratch, but then it might still be helpful to check what I've done here.

This is incomplete in that I am sure tests will fail and things are missing. A lot of code which is currently defined for MatrixElem may have to be changed (but it may also be possible to delay that for the time being -- e.g. changing det to delegate to det of the wrapped matrix is strictly speaking an optimization?)

[JohnAAbbott]

Comment/Question about matrix multiplication (and probably other binary operators): the current proposal is for a function *(M1::MatrixElem, M2::MatrixElem) to exist. Since MatrixElem is a union of 2 types this "single" function must cover 4 cases, namely (MatElem, MatElem), (MatElem, MatRingElem), (MatRingElem, MatElem) and (MatRingElem, MatRingElem).
Will the Julia compiler produce 4 distinct compiled functions? The two "homogeneous" cases are clearly wanted; do we also want the two "heterogeneous" cases? Does it make sense to multiply a MatElem by a MatRingElem? Bear in mind that there is a trivial "conversion" from a MatRingElem to a MatElem -- it is just a member access (in the proposed redesign).

[thofma]

I think the mixed-type cases must be removed. So if we still need this, it should be *(::T, ::T) where {T <: ...}.

[JohnAAbbott]

I think the mixed-type cases must be removed. So if we still need this, it should be *(::T, ::T) where {T <: ...}.

Sorry, it was my misreading/misremembering of the code. Anyway, the only cases of interest are the two "homogeneous" cases. Thanks for the feedback! I'll deal with it tomorrow.
Would the following design be OK?

function *(M1::MatRingElem{T}, M2::MatRingElem{T})  where ...
  return M1.data * M2.data
end

Then the "real" function takes two MatElem values, and does all checking & computation.
It'd be nice to have a proper accessor function instead of using an explicit field accessor; any suggestions for a name?

[thofma]

Yes, sounds good. I think data seems to be a common name for this (there are already uses of this).

[fingolfin]

@JohnAAbbott to partially answer your question: this function is removed in this PR

[fingolfin]

@JohnAAbbott ... while this was restricted to the "both arguments have the same type.

But yeah it really should be

Suggested change

	function *(x::T, y::T) where {T <: MatrixElem}
	function *(x::T, y::T) where {T <: MatElem}

and then there should be MatRingElem methods for *, +, - etc. which delegate to the the underlying "plain" matrix.

I.e., also the existing changes in this PR in lines 826 and 837 of this file need to be furhter modified.

[fingolfin]

An access for this could be matrix(m::MatRingElem) = m.data

That would be consisting for the existing matrix(x::MatrixGroupElem) method in OSCAR which also works like that.