Problem-specifications: matrix: non-square matrices are not addressed

[cmccandless]

The exercise description never states that only square matrices will be considered, yet the tests in the canonical data only cover
square matrices.

One of the following solutions is required:

• Add a statement to the description that only square matrices will be considered (Recommended; see below)
• Add tests for non-square matrices

As this exercise tends to occur earlier in many track progressions, adding tests that complicate the exercise further is inadvisable. It would be preferable to simply clarify the problem statement to the student without making the exercise more difficult.

This issue was brought to attention in exercism/python#1907

[sshine]

I don't think it's a principal problem that the exercise description doesn't mention rectangular matrices. There are, after all, many ways to characterize a matrix that we don't use.

I'm not sure why the exercise should be limited to only square matrices: Just because the tests do so now, will the exercise become any harder if there is a different number of rows than columns? And will it become any easier if we state that only square matrices are considered? We also make unwritten assumptions about what "numbers" are: Are they integers? positive integers? non-negative integers? Will the exercise get any easier if we state any assumptions here?

If you make the assumption that you know the number of rows because you know the number of columns, that assumption is unwarranted, and you would have to handle the error case when the assumption is wrong, rather than allow for an arbitrary amount of rows. So without having the assumption stated explicitly, the exercise is easier to solve without making it implicitly.

In general: You omit a third option: Leave the exercise under-specified as it is.

To deal with the origin of the problem, being that a particular kind of solution written with Python and numpy serializes the input into differently shaped data structures, I would suggest either:

• Decide if adding a non-square matrix to the test really does complicate the exercise. I may fail to see this. My impression is that as long as the matrices are not rugged (all rows having the same length), one would use the same assumptions and techniques scanning and representing square and rectangular matrices. If not, add another canonical test case. To tracks for which this matters, this is a benefit. To tracks for which this does not, the exercise has not become harder.

• Add a track-specific test, since the origin of the concern is rather implementation-specific.

[yawpitch]

I tend to agree with @sshine; we need not over specify and meeting the tests as is should be sufficient. We might specify the delimiters, as that would remove the esoteric numpy solution from play by making it unambiguous that 1 2 3 encodes a 1x3 matrix while 1\n2\n3 encodes a 3x1 matrix ... we define the serialization protocol, after all, but perhaps more explicitly doing so would help?

[DagmarTimmreck]

The referenced PR is addressing a similar issue: The existing test cases only cover the case that the matrix is non-square with more rows than columns. They don't cover the case that there are more columns than rows.

This is expected behaviour in all languages. So changing the wording to consider only square matrices would not fit with the canonical test cases that DO check for non-square matrices.

Also in Javascript there is a wrong solution that is ruled out by the additional test.

[sshine]

Since now two tracks have each their reason to address non-square matrices, I think this warrants another test case. @cmccandless: How would you feel about adding tests for non-square matrices as part of PR #1576?

[yawpitch]

There are two extant tests for a 3x4 matrix, one checking row extraction and one checking column extraction. Perhaps it would be best to simply restate both of those for a 4x3 matrix?

[sshine]

@yawpitch: Yes, I agree.

I got myself quite confused. So @DagmarTimmreck's proposal is to add

• 3 columns, 2 rows, extract 3rd column

  [ 1 2 3
  4 5 6 ] ~> [ 3 6 ]
  

  which adds:

  • coverage of non-square matrix where #columns > #rows
  • addresses column number which is not a valid row number

The current two exercises tests that address non-square matrices are

• 3 columns, 4 rows, extract 3rd row:

  [ 1 2 3
  4 5 6
  7 8 9
  8 7 6 ] ~> [ 7 8 9 ]
  

  If this instead extracted the 4th row, it would have the same benefit of @DagmarTimmreck's proposed test case.

• 3 columns, 4 rows, extract 3rd column

  [ 1 2 3
  4 5 6
  7 8 9
  8 7 6 ] ~> [ 3 6 9 6 ]
  

Whatever the intended purpose of this test is (it tests a few things, I think), the symmetry is completed by:

• 4 columns, 3 rows, extract 3rd row

  [ 1 2 3 4
  5 6 7 8
  9 8 7 6 ] ~> [ 9 8 7 6 ]
  

---

Either way, if #1576 currently resolves the issues of both exercism/python#1907 and exercism/javascript#718 without further additions, perhaps @cmccandless and @DagmarTimmreck could agree on a method of approach.

[cmccandless]

This issue was resolved in #1576