CoCoA » CoCoALib

I believe that ConstMatrixView is not the right type, because a matrix "view" is a way of looking at another object so that it appears to be a matrix; but for these matrices there is no "other object". In particular, a ConstMatrixView is not the owner of the value (just the owner of that way of viewing the other object).

It could be argued that these "constant" matrices are just ways of viewing the empty set, so it does not matter that there is no other object. Technically this is correct, but I found it quite confusing yesterday (when I could not understand what was going on in the old code, which worked seemingly miraculously).

The new design I am considering is the following. There is a new class, called ConstMatrix which derives directly from ConstMatrixView in essentially the same way that matrix derives from MatrixView. The specific examples of constant matrices are then instantiable classes derived from ConstMatrix.

Note that this design does mean that the type matrix has no inheritance relationship with ConstMatrix; the nearest common ancestor is ConstMatrixView.

Having ConstMatrix derive from ConstMatrixView means that values of type ConstMatrix can be passed as args to functions expecting ConstMatrixView, but they cannot be passed as args of type MatrixView -- this could be a problem for BlockMat2x2?

I have found a reasonable way to circumvent the problem of passing a ZeroMat (of type ConstMatrix) to BlockMat2x2.

An unreasonable solution would be to offer 16 signatures for BlockMat2x2; I discard this.

Since the only real problematic case (so far, anyway) is passing a zero matrix, I have invented a new enum with a single element zeroes. It functions as a zero matrix of "flexible" dimension, so it can choose the right size to allow BlockMat2x2 to succeed. This does require adding some new signatures to BlockMat2x2: so far just to cover the cases needed by ConcatDiag and ConcatAntiDiag. In principle another four signatures could be needed if we want to allow just a single block of zeroes.

Internally, the zeroes placeholder is replaced by a private impl of ZeroMat (with flexible dimensions). There are actually two private ZeroMat impls: one which is properly const and the other which is not (but no entry is writable). So that the existing data structure employing matrix views can continue to function, I have added a new field containing a "flexible, private zero mat" (even when it is not needed).

One nice feature of zeroes is that the caller does not need to specify the correct dimensions.

A not-so-nice feature is that it is a bit of a "dirty hack" -- but it does allow a convenient user interface.

What do you think?

JAA continues to like the idea of ConstMatrix. A nice advantage compared to ConstMatrixView is that an object of type ConstMatrix clearly/explicitly does not refer to any other object (except its ring, of course). This should make it easier for someone reading code to convince themselves of the correctness.

I'll now check the state of the documentation... let me guess: there isn't any? :-/

I've written some hasty documentation... it's better than nothing.