Separate class for grading vectors/matrices

[ChristopherChudzicki]

Related to #70

I suggest creating a subclass of FormulaGrader for grading vectors/matrices:

class ArrayFormulaGrader(FormulaGrader):
  # custom configuration schema
  # custom default functions and variables
  # shadows check_answer

Reasons to create a new ArrayFormulaGrader class for grading vectors/matrices:

• Have separate default functions and variables.

  • I for Identity: ArrayFormulaGrader could have a default variable named I for the identity operator.

  If FormulaGrader has a default variable named I, it is going to be useless most of the time, AND if authors try to overwrite it, they'll get warning errors (which can be suppressed, but still annoying).

  • Conceptually, it also makes sense to only provide transpose and adjoint functions when dealing with matrices. However, naming conflict is very unlikely for these.

• Separate Default Configuration: Currently, vectors and arrays are currently enabled through a max_array_dim configuration key. This can be hard-coded to 0 (scalars only) for FormulaGrader, and configurable for ArrayFormulaGrader (with a default of 2, for matrices). Not a big deal, but I find it conceptually nice.

• Customized Error Handling: Currently, whenever something goes predictably wrong with matrices, students get an error NOT marked incorrect. Examples:

  • multiplying / adding matrices with a shape mismatch
  • raising non-square matrix to powers

  I think that raising errors in this situation makes sense as a default. However, I can easily imagine a linear algebra course where the concept being assessed is shape mismatch. In that case, it might make sense to mark student incorrect for shape mismatch rather than raise an error.

  ArrayFormulaGrader could have configuration keys for this, easily implemented by shadowing FormulaGrader.check_answer and catching the appropriate exceptions.

  Of course, we could do this directly in FormulaGrader, but that class is, in my opinion, a bit bloated already.

[jolyonb]

Seems reasonable. I think we should aim for a single subclass of FormulaGrader where we load in the appropriate machinery. I don't want to have separate vector/matrix/tensor classes though. Add trace, det, and possibly a cross product to the list of functions to expose in this situation.

[ChristopherChudzicki]

I agree!

[ChristopherChudzicki]

@jfrench @jolyonb I'm adding defaults for MatrixFormulaGrader. Does anyone have strong feelings about names for the extra default functions?

• transpose: trans or transpose?
• conjugate transpose: ctrans or ctranspose or adjoint?

none of these render nicely by default in Asciimath. (adjoint(A) is amusingly terrible in asciimath by default. Try to guess what it looks like ... )

Also if anyone has a name preference... ArrayFormulaGrader or MatrixFormulaGrader. (It would handle vector/matrix/tensor either way. Matrix maybe sounds nicer if is misleading.)

[jolyonb]

I'm in favor of trans rather than transpose. We don't ask people to type tangent or hyperboliccosine.

I prefer dagger to ctrans or ctranspose, but I am willing to go for adjoint.

I don't expect any of these to render nicely in asciimath, a priori, as asciimath doesn't know what any of them are, and will need to be taught. I'm actually not sure that they can be taught; I suspect that they'll need preprocessing. The adjoint rendering is really cute though at the moment!

I prefer MatrixFormulaGrader. Yes, slight misnomer, but sounds so much better.