The Gaussian elimination sketchpad facilitates comparisions of the results of applying different sequences of elementary row operations to a matrix.
Specify the dimensions of the matrix you want to work with by either typing the row and column sizes in the "Number of rows" and "Number of columns" input fields, or using the input fields' up and down arrows. Clicking the Submit button will then produce an array of input fields that allow you to type the entries of your matrix. For better or worse, the app bends over backwards to accommodate any expression that either vanilla Javascript or the math.js library can recognize as having a numerical value. So, for example, sin(pi/4), -2*e/3, sqrt(7), and log(2) are all allowable as matrix entries. Note, however, that math.js symbolic simplification capabilities are modest and that you're advised to use the app with rational entries unless you have a specific reason to do otherwise. Hovering over the Submit button below the matrix entry input field array will trigger a green background if the input fields have all been populated with valid numerical expressions, and a red background otherwise. After submission of a matrix, the "Enter matrix dimensions" and "Enter matrix entries" fieldsets will be slid off the page, and a typeset version of your matrix will appear followed by an arrow button and, just above the arrow button, a text entry field. At this point you'd need to reload the page to change to a different "starting"/"working" matrix.
To scale row i by k, type Ri <= k ri in the input field above the arrow button to the right of your matrix (of course with i and k replaced by appropriate values), then click the arrow button. Capitalization matters. Big R on the left side of the op specification stands for new-row-to-be-computed, while little r stands for current-row. Spacing in this and all operations is ignored by the parser and thus only matters for legibility. So, for example, R2<=1/3r2 and R2 < = 1 / 3 r 2 are equivalent (and both valid if and only if the current working matrix has more than 1 row), while r2<=1/3r2 , R2 <= 1/2 r3 , and R2<=1/3 R2 will all be rejected by the parser. Note also that the assignment operator <= can alternatively be entered as the leftwards arrow ← (Unicode U+2190), which can be entered however you like to enter Unicode on your OS, but is also available for copy and paste in the title line at the top of the app canvas. Hovering over the arrow button will trigger a red background for the button whenever the input field atop the button does not contain a valid operation specification -- and clicking the button in this state has no effect. If the text field contains a valid operation specification (whether of a scaling operation or any of the other operations described below) the hover will trigger a green background, and a click will cause the operation to be performed and the result typeset to the right together with the appartus to perform a subsequent operation.
The format for adding a scaled copy of one row into another row is Ri ← k rj + ri , where i and j are currently valid and distinct row indices, and k is a (non-empty) string (without any r's) that can be recognized as representing a numerical value. For example (for a matrix with 4 or more rows) R2 ← pi/3 r4 + r2 , R3 <= 1 r1 + r3 , and R2 <= cos(pi/2) r4 + r2 are all valid (though of course the last is useless), but R2 <= pi/3 r4 + r3 , R3 <= r1 + r3 , R2 <= r2 + pi/3 r4 , R3 <= 2 r1 + 1 r3 , R2 <= 5 r2 + r2 , and R2 <= -1 r2 + r2 are not accepted. The policies encoded in the parser are (deliberately) a bit pedantic for a few reasons, not least of which is a desire (in the case of this type of row op) to emphasize the lack of symmetry between the i and j indices. (Note that while the scalar k is not taken to default to 1 if left blank, a plain minus sign may be used to set its value to -1. So for example R2 ← -r1 + r2 is acceptable.
The capitalization semantic introduced above suggests that the syntax for a row interchange should be something like Ri ← rj, Rj ← ri . But since here the pedantic approach is both rather cumbersome and in conflict with dominant conventions, we cease to enforce the capitalization policy and employ a leftright arrow (with <=> and ↔ [ U+2194 ] treated as equivalent). So, for example, R3 <=> R2 , r3<=>r2 , and r3 ↔R2 are all valid (given a matrix with 3 or more rows) and equivalent. Like the leftarrow, the leftrightarrow is easily accessible for copy-and-paste purposes in the title line at the top of the app canvas.
The (non case-sensitive) command auto triggers a sequence of row operations to be generated and applied, one at a time, with results displayed left to right terminating in a matrix in row echelon form (if the matrix to which auto was applied wasn't in row echelon form already) or reduced row echelon form (otherwise). If auto is applied to a matrix already in reduced row echelon form then it has no effect. (Arguably, in this case, the auto should trigger on hover the red background mentioned above for the corresponding arrow button. Currently it doesn't. If this really bothers you, file a [low-priority] bug report.)
Double-clicking the Suggest row op label corresponding to a matrix which is not in row echelon form will cause the system to fill the corresponding elementary row operation text input field with a row op specification. That row op can then be applied as usual by clicking the corresponding arrow button. By default, the system will suggest row interchanges to maximize the absolute values of pivots. (Actually it's a bit misleading to describe this as a "default" since currently it's the only behavior available. I am open, though, to feature requests relating to options for alternative algorithms for suggested row ops [and the auto command].) For a matrix already in row echelon row, a simple double-click on the label yields nothing. However, if the matrix isn't in reduced row echelon form, it can be induced to make a suggestion if you hold down the CTRL key while double-clicking. (This behavior, like the two stage auto command, is designed to prompt the user to think about whether there really is any value in continuing to apply row operations.)
The (non case-sensitive) command eval causes all entries in the matrix to be evaluated numerically. A future version of the app may well upgrade the eval command to accept an optional display precision specification.
Double-clicking on either the left or right bracket delimiting any matrix in the sketchpad will create a new "op sequence row" with a copy of the double-clicked matrix. A new (and independent) thread of elementary row operations can be applied within the new display row facilitating comparison of the effects of different strategies or algorithms. (Though I'm not writing much now about this functionality, I consider it a key feature.)
Hovering over a matrix (that isn't the first in its op sequence row) will trigger highlighting of whatever row(s) in that matrix and its immediate predecessor that are referenced in the row op that produced the matrix being hovered over.
Hovering over an arrow button creates a magnified copy of the contents of the corresponding text entry field in the upper right corner of the app canvas. This can be helpful if the contents of the field are too wide to be displayed all at once within the field, or if the user, like myself, has vision issues.
Any row op specification can be changed and (if valid) re-entered at any time. An edit (with re-entry) in the middle of an existing sequence of row ops prompts cascading recomputation to the end of the op sequence row. Since this behavior is inconsistent with the function of the auto command, the auto command is not valid in the middle of a chain. If desired, a matrix in the middle of a chain can be duplicated into a new row (by double-clicking on one of its brackets as described above), and there may have the auto command applied to it.
The heuristic behind animated auto-scrolling is weak, and therefore, on occasion, the user may need to scroll manually to view the results of the latest computation.
The meaning behind color changes in the brackets delimiting matrices in the sketchpad will become apparent to the user.
Adding the query string aug=false to the app's URL will trigger some behavioral modifications. Final columns are not visually partitioned, zero rows are only marked in a subtle fashion, and rows that are zero except for a final non-zero entry are not distinguished at all. In subsequent releases of the app there are likely to be further effects of setting aug to false consistent with dropping the presumption that the working matrix is an augmented matrix representation of a linear system of equations.