Design of LinBox v2.0
Main points to be addressed:
- Redesign the matrix/BlackBox toward a more intuitive and simpler usage. See MatrixDesign.
- Update the solutions wrt the new matrix interface. Clean the current code and make it uniform for all solutions. See SolutionDesign.
2a. In particular, enrich and fix the solver solutions, see SolverDesign.
- Change the configuration system to SCons: M Abshoff, can you maybe make a short wiki entry on this point (motivation, port to MSVC, ...)
- Chinese remainder code: uniformize the way it is used (matrixHom), make it faster
- Clarify the distinction between Ring and Field:
- separate directories? [bds: No, because some classes (Modular<>) provide both. We might change the field directory name to arithmetic. My proposal is to have concepts indicated by what name you choose for the template parameter (and eventually by official "C++ concepts", if that language change is done in a way that works for us). Thus when you say template<class Ring> foobar(), you imply that you won't use div (or use it when only when it has a unique solution), and won't depend on multiplicative commutativity, whereas when you say template<class Field> foobar() you have stronger expectations of the operations. Further, if you say template<class RichRing>, you are implying that the class must provide functions such as isZeroDivisor. The concept names are
- Ring (or BasicRing), same C++ interface as Field, but weaker expectations on div and inv, no assumption that mul is comutative. (eg. MatrixDomain (should) meets the BasicRing requirement -- for the arithmetic of k by k blocks).
- Field
- RichRing, Field interface plus a couple of things: isZeroDivisor, isRegular, isUnit, ...
- !LocalPIR (is used by !localSmithForm and perhaps could be used by local sparseelim.) The local rings we have now represent ZZ mod a power of a prime. A !LocalPIR meets RichRing plus gcdin(). Locality means that for g = gcd(a,b) and a, b not both zero, one of a/g or b/g is a unit.
- PIR (eg. reps of integers mod composite n) RichRing plus extended gcd.
- PID has PIR interface plus assumption of no zero divisors.
- If you have an algorithm that works with more than one arithmetic, but requires it provide additional functionality, you may create a concept to serve. Using the concept name in the template class name serves to document that the concept requirements are needed, eg. FieldWithConjugationOperator).
- inheritance? which way? Template parameters are class variables, not classes per se, so no C++ inheritance involved. Wrappers can add (trivial) functions to a class that is a higher structure ring, but hasn't been provided the functions. For instance, any field can be wrapped to meet the RichRing or PID concept.
- update the Domain traits (ModularTag doesnt tell whether the ring is a field...). Sure, but 1) where needed? and 2) as we have things now, this is not determinable at compile time (modular<double> F(3), G(9), H(12);).
- Hadamard bounds: create a solution/detBound.h
- detBound.h rather than hadamard.h because some matrices may get a better bound from Gershgorin or ovals of Cassini than from Hadamard (specializations can get at this).
- Error to call it except when IntegerTag or RationalTag?
- for SparseMatrix and DenseMatrix: compute the effective bound, using row and col iterators.
- compute the vector norms over Z ? (over whatever subring of Complexes)
- otherwise, majoration of each entry by a power of 2, and manipulation with the bit indices to compute the log(sum_i(|aij|))
- for BlackBoxes : ?? ...is the bound for the det or for the length of the det?
- Should they provide a method maxEntry (returning max |a_{i,j}|)? [the rawIterator was a stab at providing this generically, but inadequate...]
- use 'apply' to recover the col/row vectors and then compute the bound (probably way too expensive). Early termination to the rescue!
- as with getEntry(), local functions in some classes of blackbox, thus: A.detBound(), and special handling of Compose<Diagonal, BB> are desirable.
