CoCoA » CoCoA-5

Anna omitted to mention explicitly that it is deemed desirable that the printed form of a matrix should also be valid as input (or as nearly as is possible). This would certainly make cut-and-paste use easier.

In fact, in CoCoA-4 there was the general rule that printed output should be valid as input (with strings being a highly visible exception). JAA agrees that a similar generale rule should apply to CoCoA-5 with the proviso that printed form must be natural and easy to read (so naturalness is more important than validity as input).
-----------------------------------------
JAA: we assume that printing of matrices (or any value) should produce essentially the same output whether done inside CoCoA-5 or inside CoCoALib

1. the ring containing the entries
2. the dimensions of the matrix (rows,cols)
3. the entries of the matrix

Which of these components should be included in the printed form? And why?

JAA thinks that the entries must be included.
JAA thinks that the matrix dimensions are redundant information (if the entries are printed out as a rectangular array).
JAA thinks that printing out the ring is often redundant (because the user already knows to which ring they belong), and could be "misleading" if the printed form is cut-and-pasted as input to a C5 session (or perhaps it gives some extra safety?). Consider the example below:

R ::= QQ[x,y,z];
Use S ::= ZZ/(7)[x,y];
M := matrix(R,[[1,x],[1,y]]); // cut-and-pasted

It seems that both AMB and JAA are leaning towards the idea of not printing out the ring when printing a matrix. JAA thinks it would be too easy for a (new) user to believe that the presence of the ring would guarantee creation of the matrix over that ring [but this is not what the current evaluation rules would do].

Printing just the matrix entries would follow the KISS philosophy, and would maintain backward compatibility with C4 (if we use the tag Mat rather than the tag matrix).

1. Mat is backward compatible with C4
2. matrix is better aligned with current CoCoALib naming convention

If we want the printed form to be readable as input then the tag must be the name of a matrix constructor.
-----------------------------------
JAA using matrix is only mildly backward-incompatible as it is pretty simple changing matrix into Mat.

We could also consider the tag Matrix, so backward compatibility could be achieved simply by defining a C4 function called Matrix

Given that JAA and AMB are both largely convinced that it is best to print out just the matrix elements, AMB made a verbal proposal similar to her first proposal: here is an example to illustrate her idea

matrix(/*QQ 2x2*/ [[1, 2], [3, 4]])

1. the printed form of a ring can be long and hard to read, making it quite difficult for the user to read the actual value of the matrix
2. if the user really wants to see the ring, then he may also easily print it out by an explicit command (e.g. PrintLn RingOf(M))

Anna's suggestion could be made more workable if the ring/dimensions were printed in a comment after the matrix value:

matrix([[1, 2], [3, 4]])
/* 2x2 matrix over QQ */

I have deliberately placed the comment with dimensions and ring on the line after the matrix entries. Since matrices are currently always printed on a single (possibly very long) line, it seems more sensible to move the comment to the next line as it might otherwise be lost from view.

JAA thinks it may be interesting to offer a function which produces a value containing the information about the type of a value (e.g. think of the Shape function in C4). Here's a hasty example:

prompt# Fulltype(M);
Record[NumCols := 2, NumRows := 2, ring := QQ, type := MATRIX]

after using the "old style" for a while I'm getting more and more convinced that a matrix should also print its own ring, this is my new proposal

mat( /* QQ */ [
  [1, 0, 1],
  [0, 0, 1]
])

I do not like the "abandoned" square bracket at the end of the first line.

After speaking yesterday, we also concluded that we would use matrix rather than just mat (through the abbreviated form is fine in compound names). Here is my suggestion:

matrix( /* QQ */
 [[1,2,3],
  [4,5,6]
 ])

Generally I prefer that matching brackets be aligned vertically or horizontally -- it seems difficult to achieve this without wasting several lines of vertical space.

I note that the original proposal use the comment-to-end-of-line but Anna's latest proposal uses /* ... */ comments. JAA thinks this second proposal is probably a better choice (especially considering the cut-and-paste bug in the GUI related to end-of-line comments).

John Abbott wrote:

I do not like the "abandoned" square bracket at the end of the first line.

Generally I prefer that matching brackets be aligned vertically or horizontally -- it seems difficult to achieve this without wasting several lines of vertical space.

I note that the original proposal use the comment-to-end-of-line but Anna's latest proposal uses /* ... */ comments. JAA thinks this second proposal is probably a better choice (especially considering the cut-and-paste bug in the GUI related to end-of-line comments).

JAA:

matrix( /* QQ */
 [[1,2,3],
  [4,5,6]
 ])

matrix( /* QQ */
 [[1,2,3],
  [4,5,6]]
 )

JAA has just changed slightly the way matrices are printed: removed two newlines.
The newly changed code would produce something like this:

matrix( /*QQ*/
 [[1,2,3],
  [4,5,6]])

It really seems difficult to produce a uniform style which does not look wrong in some context. Perhaps we should use different styles if a matrix is printed alone or if it is printed as part some other structure (such as a RECORD)??

The problem arose because the new PreprocessPts commands produce a RECORD containing a matrix, and the printing looked horribly wrong!

A significant problem is that the printed form is produced by CoCoALib which naturally knows nothing about variable values etc. in CoCoA-5.

We may have to settle for a partial/compromise solution (that ideally works in most usual circumstances).

now it prints the ring itself (when ring is uniquely defined)

matrix(QQ,
 [[1, 1, 1],
  [1, 0, 0],
  [0, 1, 0]])