FormulaGrader Enhancements: Non-scalar formulas

[ChristopherChudzicki]

The following are some enhancements to FormulaGrader related to handling non-scalar expressions. Some of these were discussed as summer projects for Chris.

1. Matrix/Vector Sampling: In formulas like a*b, sample a and b from vectors instead of scalars. Useful for grading any non-commutative mathematical expressions. Also possibly useful for specific matrices, like grading Pauli matrix identities in a quantum mechanics course.

   Implementation Difficulty: Straightforward and fast... 1 day for an initial PR?

2. [Implemented in #32] Custom Comparer functions: Currently correctness is determined by comparing student's input and author's answer using approximate equality. Allow author to pass an alternative comparer function. Examples: compare modulo 2π, compare whether expressions are parallel, compare whether student's input is in the span of some other vectors.

   Same as #30.

   Implementation Difficulty: Straightforward and fast... 1 day for an initial PR?

3. [Implemented in #59] Parse/Eval Multivariable: Parse functions with multiple variables, e.g., f(x, y) + g(x)*y^2

   Implementation Difficulty: A bit harder. Minor changes to parser and evaluator

4. [Implemented in #61] Parse/Eval Vectors and Matrices: Parse and evaluate expressions like A*[1,2,3] + b where A is a matrix and b a vector, or [1, x]/sqrt(1 + x^2). Jen has wanted this for linear algebra courses and it could be useful in physics, too. (Although, I suspect that physics prefers Dirac bra-ket notation).

   Implementation Difficulty: Much harder. Significant changes to parser and evaluator

If necessary, we can discuss each of these in-depth in its own issue. Current question:

Question: Should these enhancements all be rolled up into FormulaGrader? Or should the matrix-related enhancements be part of a new grader class?

[ChristopherChudzicki]

If we want to continue using the same parser/evaluator for all math graders, which I think we do, then I suggest we just roll all of these enhancements into the existing FormulaGrader class.

I have also looked into whether it makes sense to use an alternative math parser, rather than the one in calc.py. For example, sympy has an extensive math parser. However, edX uses sympy 0.7.1 (current version is sympy 1.1.1). Version 0.7.1 lacks several features that would facilitate the above goals (Example: 1.1.1 MatrixSymbol class, which 0.7.1 lacks. MatrixSymbol would be useful for implementing things like [1,x] + B). So I think it makes sense to continue using/modifying the calc.py parser.

[jolyonb]

I like 1, 2, and 3. They should fit into the current framework straightforwardly. 4 will be much, much harder, and I suggest we put it on the backburner for the moment. I'm happy to discuss each of 1-3 in individual issues.

I like the idea of keeping things in FormulaGrader. All of these ideas are enhancements there, and shouldn't necessitate a separate grading class.

I agree that keeping our own version of calc.py at this stage sounds good.

[jefrench]

For me, I am really only interested in having something like 4. I think that this is in some sense already done in Ike's calc library, and we should consider using existing frameworks. Or maybe pyzo?

[jolyonb]

So, 3 and 4 have both been implemented now (#59, #61). 4 isn't yet usable, as we need 1 to be in place to actually use it, but I suspect this will happen pretty quickly now!

[jolyonb]

I'm going to go ahead and close this. Everything discussed in this issue and associated comments has been implemented. Some associated bits and pieces that remain are discussed in #78.