TODO

=============================
  Package "Math-MatrixReal"
=============================

Plans for the future:
---------------------
 * Jonathan Leto ideas:

Row echelon form
Column echelon form
Hard: Jordan form
More examples in docs
print as mathematica,scilab,other,...
DONE:print as latex
DONE:print as matlab
DONE:make each,each_diag 1-based for consistency SOON
t/basic.t should check results
alphabetize section of docs

$matrix->set_option( expand_on_assign => 1 );
Pade' matrix exponential

 * Steffen Beyer ideas:

Define accurate test cases (which is not so trivial since results will
depend on the local implementation of floating point arithmetics on
a given machine!).

Compute the characteristic polynom, orthogonal matrices, ...

Deal with symmetric and with orthogonal matrices, multilinear functions, ...

Create a module "Math::MatrixCplx" to deal with matrices of complex numbers...

Deal with hermitian matrices, multilinear functions, ...


 * Rodolphe Ortalo remarks and thoughts:

Some restructuring/recoding ideas:

 RO1- Wouldn't it be better to use a hash reference for MatrixReal
objects? I feel $matrix->{ROWS} is much clearer than $matrix->[1],
and it is probably as efficient. Do you have objections on such
evolutions? This would probably be an important update...

 RO2- Sparse matrix, Symetric matrix, (Tridiagonal, Permutation[1]?)
Is it desirable to use special-hooks in MatrixReal objects,
or would it better to use object-oriented inheritance?
 * In the first case, maintainance may be difficult.
 * In the second case, efficiency problems may arise (all value
accesses should go through methods like ->element() and assign(),
even for internal computation routines of the module...)
I'd favour the second solution, but it would involve a big
update of the existing methods (e.g. if we want MatrixReal
->multiply() to work also on derived matrix classes).

 RO3- Sparse matrix: use hash tables ($M->[0]{$i}{$j})? I personnally
think that this would be general and simple. Real techniques for
sparse matrix manipulation (e.g. Yale representation) are much
better - but more difficult to use (especially as they are optimized
for some operation like multiplication of a vector).
Furthermore, it would be possible to use these matrix for other
purposes rather efficiently (permutation matrix would be easy)
and without worrying too much... (The last reason if probably
the most important to me... :-)
If we don't want too much maintainance problems, this is linked
to RO4 - unfortunately...

 RO4- Add ->get() and ->set() methods, that uses index value where
(i,j) is in (0...n-1,0...m-1). ->element() and ->assign() use
indexes variying in (1..n,1..m) and this involves two additional
'++' operations. These may be costly (IF they are used heavily
for computations of course).
 ==> I tried! This has a VERY BAD impact on performance. It's
probably unacceptable to add this method call. (Even a subroutine
call is very costly.) Such modifications occur in the inner loop
of all algorithms so it's very touchy of course to change these
things. Well. I don't have an idea on this. Maybe future versions
of Perl itself would be able to inline the call, and enable us
to use such access methods.

 RO5- The POD documentation deserves some more structuring. For
example, sections for
 - arithmetic ('+,-,*,/') operations,
 - linear system solving,
 - eigensystems,
 - Kleene transformation, etc.

UPDATE: working on it -- leto


[1] What I mean by "permutation matrix" is a matrix where only a
single element of each column (or each row) is non-zero, and that
element is equal to 1. Such a matrix allow to 'shuffle axes' easily.