First draft of linearalgebra.mac for the contrib folder.

[LukeLongworth]

I don't expect this pull request to be accepted right now, I just thought that this would be a better way to solicit feedback than to post an issue. You can see at the bottom of this description a (non-exhaustive) list of things I still want to consider adding to this.

Linear Algebra

This is the first draft of a linear algebra inclusion package. I still have more work I want to do before this reaches version 1.0. Feedback is appreciated! Let me know if I am duplicating existing functionality, if naming conventions could be improved, or generally if I could improve any parts of this. I've solicited specific advice below (and commented in the file itself).

Note that I have written all of this with the expectation that students will be working by hand and as such will be dealing with relatively simple/small matrices. There are files here (e.g. mat_cond2) that probably shouldn't be run on matrices much bigger than 5 by 5, and my hope is that teachers who use this file will be expecting this, as only more experienced users are likely to use contrib packages anyway.

Contains:

• Helper functions c() and r() for students to input vectors with associated texput functions and two different options for decoding (which makes sense? Either?)
• triu, tril, and get_diag to extract the upper triangular, lower triangular, or diagonal of a matrix. diagify could be a better name for get_diag, which might be confused with the below diag_entries function.
• Predicate functions to test for each of the above shapes
• REFp, a predicate function to test whether a matrix is in row echelon form. Optional input normalise_pivots=true checks whether pivots are exactly equal to 1. Could be renamed refp or echelonp to better match native rref or echelon function.
• diag_entries to return a list of the diagonal entries of a matrix
• diagmatrix_like to construct a diagonal matrix with given diagonal entries as a list and size m by n. This differs from existing functions by allowing you to select the size of the matrix.
• lin_indp to check whether a given set of vectors is linearly independent. Very open to changing behaviour here if requested.
• sf_map to map the significantfigures function over a matrix, or run normally if given a list or a number. Should this be default behaviour? What about for things like sets or ntuples?
• mat_norm2 and mat_cond2 to compute the 2-norm and 2-condition number of a matrix. I'm really not sure whether this is useful, but it felt odd to me that these functions existed for 1-, inf- and Frobenius norms but not 2. This whole package is designed assuming students will be doing hand working and dealing with "small" matrices, so it doesn't feel overly risky to allow functions like this.
• row_equiv and col_equiv to check row or column equivalence between two matrices.

Still TODO:

• Perhaps wrap up the existing LU functions with something more intuitive like get_PLU(M) := get_lu_factors(lu_factor(M))
• Perhaps a function to generate Gershgorin discs. Biggest difficulty will be finding an appropriate format to use that is flexible but still useful.
• Investigate the feasibility of bespoke functions for QR factorisation, SVD, pseudoinverses, least squares solutions (some of this feels unlikely without lapack, but perhaps could be supported up to certain size of matrix?)
• Write a function like rand_orth to randomly generate sensible matrices with orthonormal columns of size m x n (m<=n). Would likely take the form of a lengthy list of vetted examples with some row/column swapping/changing signs. Similar functions could be used to randomly generate matrices with determinant of ±1, with integer eigenvalues or singular values, symmetric/Hermitian matrices
• Investigate some other predicate functions, possibly including: whether a matrix is symmetric, whether a given vector is an eigenvector, generalised eigenvector or singular vector of a matrix, positive definiteness/semi-definiteness.

[LukeLongworth]

I have some updates on this.

1. I have moved my work here and am testing it using stack_include. My ultimate goal is to create a new library of quiz questions for our 200-level engineering linear algebra course which import from this branch as a beta test, and then move linearalgebra.mac to the master branch here at the end of the semester.
2. I have rather dramatically expanded the number of functions in the other file.
3. I have reworked the c() and r() notation to avoid annoying error messages. They are now inert functions that can be converted into matrix form using vec_convert, which will return the original expression if the matrices do not conform.

The load times are currently quite long, so I have also created linearalgebra_no_test.mac which has all s_test_case lines to see if this helps. Luckily, after deploying variants, quiz load times seem normal from a student perspective. I assume that stack_include will run all s_test_case lines when saving the question. If so, is this desired behaviour? I have been writing a lot of test cases for functions that weren't written to be very efficient and running all of them at every save doesn't feel ideal.

[LukeLongworth]

This has been superceded by #1185