Let's start working on the design for LinBox version 2.0.

First, I could not find the wiki page that was written after our Post
ISSAC07 discussions.
The page http://linalg.org/projects/linalg/wiki/PostIssac07 now points
to the irrelevant page
http://linalg.org/projects/linalg/wiki/LinBox.
Dave, can you investigate with Udel eecis staff if any problem occured
during the migration of the Trac server?

I wrote a few draft pages about my vision for the design, trying to
remember from what went out of our discussions and adding some personal
considerations.
Have a look at http://linalg.org/projects/linalg/wiki/LinBox-2.0 and the
pages pointed from there.

Please contribute to these pages, especially by adding anything I forgot
to mention.
For non trivial design modifications, a good way to proceed would be to
first start a discussion on linbox-devel, for each point you want to
discuss, and after we have reached a concensus, we can update the wiki.
Do you agree with the protocol?

We can also consider organizing a meeting on our IRC channel
#linbo-devel, if the mail discussions are too slow.

I'll be in France in april, and that could also be an opportunity to
organize a few days of coding sprints with JG, Pascal, Gilles,...
depending on your availabilities.

Cheers,

Clément

I agree that proposals can be made both by mods to the wiki pages (a
collaborative/competitive design process that wikis are good for). and
by initial discussion here.  I'll try some of each.

(1) I added some functions to the blackbox list on the matrixDesign
page.  rebind() is essential.  read() and write() too.

(2) dense matrix reps.  We have 2 now and have agreed to transition
from DenseMatrix to BlasBlackBox as the primary one.  I expect there
will be future ones having to do with parallelism, i.e. distibuted
matrix schemes, and with out of core matrices, of which the jit
blackbox is a start.

I offer the thought that the interface we have now is too low level.
I expect we will NOT be abstracting elimination just by calling the
rep's row iterator or col iterator routines.  Those are not
appropriate for blocked and distributed matrices.  Perhaps the common
interface of the various dense matrix reps should be a LQUP function.

(3) Sparse matrix reps.  Ditto what I said about dense matrices.  Our
sparse reps will differ in ways which make the row ops and col ops NOT
the best common interface.  Again, (beyond the blackbox interface)
provision for a sparse elimination method tailored to the specific
representation would be what is expected of each sparse rep.

In other words, I'm proposing to bind each sparse or dense matrix
representation to a corresponding elimination strategy.  Other
Method::Elimination solutions such as det(), rank(), solve(), etc.
could then be generic over this class of elimination providing
representations.  (This would not preclude sparse matrix reps which
only support the blackbox interface.)

Cheers, -dave

On Mar 7, 8:08 pm, Clement Pernet <clement.per...@gmail.com> wrote: