Notes on Assignment 3: Matrices

At this point in your career, you should be thinking about more than just what functions to include in an object and how to implement them. In particular, it is important to consider

• preconditions and postconditions,
• exceptions (which will often be governed by preconditions and postconditions), and
• modular design and related issues.

In building The my own solution to this assignment, I found that I needed a wide variety of utility classes. These included a variant of Bailey's Assert class that threw exceptions rather than terminating the program. I also chose to use a newly-defined BoundsException for most of the errors pertaining to my matrix.

The my own solution is somewhat excessive. I tend to include many preconditions and throw exceptions whenever the smallest error occurs. I also try to ensure that my data structures remain coherent when errors occur. For example, if someone tries to insert the 10th row in a two-row matrix, we shouldn't change the original matrix. (I don't think that many of you do, but that's a warning.) Note also that exceptions are the only ways in which your utility classes should indicate errors. Only your main/interface class should print warnings!

A small design issue was the choice of indices to use. While Java uses zero-based indexing for its arrays and vectors, I felt that one-based indexing was more appropriate for our class, as most people describe arrays with one-based indices (or at least the linear algebra text on my shelf does).

A similar concern was the ordering of row and column. I had originally designed a Point class (giving discrete (x,y) points). However, I noted that Cartesian coordinates and matrix indices have "opposite" orientations. On the Cartesian plane, we list the horizontal offset first (the x value). In matrices, we list the vertical offset first (the row). This led to the design of a MatrixIndex class which I used in place of the Pair class from the assignment and the Point class I had originally designed.

Did I have problems building my class? I spent awhile deciding on appropriate preconditions for fillLine. For example, I needed to think about whether offsets could be 0 and whether we had to end at the final point, or simply "beyond" it. I chose to allow offsets of 0 (but only for one of the offsets) and to require that we end at the final point.

I also wondered about the appropriate restrictions to (and meaning of) insertion of rows and columns. I decided that insertion before another row or column was appropriate. I also decided to allow insertion directly after the last row or column using the same method. Implementing this correctly ended up being more difficult than I had expected, and I may have been better off disallowing it or providing a separate method.

One big concern was the effect of these operations when the matrix was empty. In some sense, they seemed to be the only available mechanism for expanding an empty matrix. Without them, empty matrices are completely useless. However, it was clear that insertion into an empty matrix would be particularly difficult and potentially unclear. In the end, I chose utility over ease of coding.

The method that took me the most time to get right was my draw method, which I provided as an alternative to toString(). I found it quite easy to define toString() using the standard methods associated with java.util.Vector. However, that output was not appealing or easy to read. Hence, I worked on a two-dimensional alternative. Making sure that the matrix was evenly spaced took some time and eventually required me to write The helper class to handle some of the string formatting.

Should your version have been as excessive as mine? Certainly not. Would I be happy if it were? Certainly.