Log of events

Proposal writing, summer 1997.
Spaghetto Meeting, Raleigh, April 1998.

Java meeting, Grenoble, August 1998.

Brigitte meeting, Newark, September 1998.

Zyzygy meeting, Grenoble, January 1999.

Primepower meeting, London (Ontario) February 1999.
Giesbrecht, Saunders, Villard.
Leanbox meeting, Raleigh, April 1999. Picture at Wrightsville Beach, North Carolina.

99 Summer seminar at Del.
Lake Louise meeting, Calgary, July 1999. Picture at Moraine Lake.
Eberly, Kaltofen, Villard.
Produced List of problems and results, later list with modifications
Ratatouille meeting, Newark, November 1999.
Caviness, Chen, Dumas, Eberly, Gautier, Giesbrecht, Kaltofen, Saunders, Turner, Villard.
We resolved the field naming and structure questions and installed several fields in linbox.
We will try the use of doc++ and of cvs version control, with repository at UDel.
Parallel computation is coming to the fore.
To learn the power of p in the last Smith form entry we can q-adicallly lift one coefficient of x, where (p^k I + q A(I + ev^t))x = b, for random vectors v and b and random prime q and e = (1 1 ... 1).
Butterfly networks can be used to build efficient preconditioners for the "leading cols independent" problem.
A survey of preconditioners is proposed.
Cream Cheese Meeting, London, February, 2000.
Chen, Dumas, Eberly, Gautier, Giesbrecht, Kaltofen, Saunders. Villard. Joined by: James Davenport, George Labahn, Steve Watt.
We set up an outline directory structure for linbox, refined some implementation issues.
Computed Diophantine Solution to large linear system arising from a block design existence question. Possible step toward solution of longstanding conjecture.

Oreo Meeting, Grenoble, June/July, 2000.
Dumas, Eberly, Gautier, Giesbrecht, Kaltofen, Lobo, Roch, Saunders, Turner, Villard. Joined by Arne Storjohann.
We agreed on several design issues:

apply will take a handle to the arithmetic (the matrix domain in bds request)
apply will take iterators rather than vectors - this deserves checking the details and further review.

Integers:
  We use the Givaro Integer (in Linbox called "integer"), 
  which wraps GMP, giving them the look and feel of a widening of long.
  [ The domain class (a ring) which uses these as element type s called 
  Integers.  It is suggested when instantiating to use the name "Z" as
  in "Integers Z; " ]
  We should move to use of int_32 (int or long) and int_64 (long long) when 
  it is necessary or desired to use truncated integers.

Naming conventions
 Domain type names are capitalized.
 The associated classes of a linbox type X are
 class X_archetype, 
 class X_abstract, 
 class X_envelope : public X_abstract {...};
 class X_verifier : public X_envelope

 data member names in a class have underscore prefix, "_rowdim".

 Domain names are capitalized.
 All Domains have the interface 
   typedef SOME_TYPE element
   and basic object things on the element type.
   ..and basic "set" things.
 Fields, Vector spaces, and other domains extend from this.
 Wrappers contain name of package (NTL Giv etc)
 Header files: name of file = name of class (of a predominant class in the file)

Algorithmic work proceeded on many fronts, particularly char poly.

Choucroute Meeting, Lyon, June, 2001.
Dumas, Giesbrecht, Hovinen, Kaltofen, Saunders, Storjohann, Turner, Villard.
We adopted automake/autoconf, made some directory organizational changes:
1. examples/ (tests/ same or different?) outside of src/
2. merge src/library/wrappers/ into /src/library/objects/ so that the linbox domain classes are in their respective domain directory in objects/ regardless of the means of implementation.
3. Adopt a HACKING file to record development conventions.
4. A solutions/ directory to contain problem specific interfaces to the algorithms.
We resolved to make a distribution by then end of July (by ISSAC if possible). The first distribution is to include:
1. At least one implementation of each finite field (every mathematical finite field in principle, and in practice reasonable impl of each prime field and each field of size less than 10^20, say)
2. At least one algorithm to solve each of the following problems
  - linsolve0 - random solution to homogeneous eqn.
  - linsolve1 - Ax = b, for A singular
  - non_singular_linsolve - Ax = B, A known to be nonsingular. (Block Lancos for the above three>
  - determinant - A square - Will, Erich goal to provide
  - rank - Wiedemann
  - minpoly - Wiedemann
  - charpoly - Gilles' goal
  - pseudoinverse - Dave, Bradford goal
  - Diophantine ... Most of the above Smith Form - Mark, Arne goal (direct methods)
3. Preconditioners: diagonal, butterfly

Rootbeer Meeting, Newark, April, 2002.
Devore, Duran, Giorgi, Giesbrecht, Hovinen, Kaltofen, Morozov, Saunders, Storjohann, Turner, Villard, Wan, Xiang.

1. We agreed to adopt a new directory structure It has a two level source directory organized by purpose.
This organization mixes in one directory the archetype system as well as those wrappers and generic codes
whose product meets the archetype (or a closely related archetype). The purposes are

field: fields and rings
blackbox: the matrix types
algorithm: alg implementations (wiedemann, lancos, berlekamp-massey, ...)
randiter: random element generators
util: error, debug, integer, commentator
element: basics needed for archetype system
solutions: simple interfaces by matrix problem (rank, det, solve, ...) to selected algorithms

A corresponding two level include directory will be built by "make install."
For example for the source directory linbox, there are files such as

linbox/field/modular.h
linbox/blackbox/butterfly.h

The corresponding include directives are
#include "linbox/field/modular.h"
#include "linbox/blackbox/butterfly.h"

2. Every field, blackbox, algorithm, and solution has a unit test in the tests directory.
Make the appropriate entries in the tests/Makefile.am so that the unit test is run as part of
linbox's "make check" feature.

3. We agreed that FieldArchetype and BlackboxArchetype are frozen, meaning no changes are made to these
classes without full team consensus.

4. To capture the distinction between wrappers dependent on other software and non-dependent generic code,
we agreed to generally prefix wrapper names with the wrapped library, thus "givaro-zech-log.h" wraps
the Zech log fields of givaro (or so I wish), and "ntl-RR.h" wraps NTL rationals.
Also we agreed to have a system of header files defined by dependency on external software systems.
Thus, for example, linbox/field/ntl.h contains:

#include "linbox/field/ntl-RR.h"
#include "linbox/field/ntl-ZZ_p.h"
#include "linbox/field/ntl-zz_p.h"

5. We agreed to capitalize all class names (except integer). When a name is a a multiword phrase,
each word is capitalized. Thus "Element", "DenseMatrix". However filenames are in lowercase, "diagonal.h",
distinguishing them from build system files such as "ChangeLog" and "Makefile". Generally, in filenames,
hyphenation replaces internal word capitalization, "dense-matrix.h".

6. We agreed to apply the GNU Library General Public License to linbox and to assert our copyright in most
files with preamble entries like:

Assertions of authorship are also generally part of the preamble comment of files. Use entries
like "Written by X", "Created by X". Where one file serves as a template for another, but is
finally pretty much overwritten, an entry such as "evolved from F.h by X" is appropriate.
Where a developer makes significant changes, entries like "modified by Y", "slightly modified by Y"
may be added to the authorship of a file. When a new person takes primary responsibility for
a file previously created by another, a line like "maintained by X" may be useful.

7. This version currently resides in the CVS repository "linbox-new".
When committing changes, make an entry in the directory's ChangeLog and copy it into the CVS log as well.
ChangeLog entries will be accessbile to users who download a tarball, whereas CVS log entries are only
available to developers.

Ice-fish Meeting, Waterloo, Feb, 2003. We resolved to enable alternative memory models by adopting STL style allocators and using the allocator's types for ptrs, references, etc. We established a CVS linbox-devel module for things that are not yet clearly part of linbox but may become so. Topics under development include Block Lanczos LEM Large exponent model floats Integer matrix algorithms Polynomial matrix algorithm infrastructure for field extensions / homomorphic images / isomorphic images Maple interface Web server extension and web server portability GenBlas and ffblas unification.
Humidity Meeting(s), Williamsburg, Raleigh, Philly, Newark, July/Aug 2003. Various subgroups of the LinBox team had discussions at SIAMLA in Williamsburg, ACA in Raleigh, at ISSAC in Philadelphia, and finally on Aug 7-9 in Newark, DE. Participating: Brad Botting, Carl Devore, Jean-Guillaume Dumas, Ahmet Duran, Wayne Eberly, Mark Giesbrecht, Pascal Giorgi, Bradford Hovinen, Claude-Pierre Jeannerod, Erich Kaltofen, Wen-shin Lee, Austin Lobo, John May, Dmitriy Morozov, Clement Pernet, David Saunders, Eric Schrag, Richard Seagraves, Peter Steijn, Arne Storjohann, William Turner, Gilles Villard, Zhendong Wan, George Yuhasz. Claude-Pierre Jeannerod joined LinBox. Welcome Claude-Pierre! The following decisions emerged. 1. To make a 1.0 release in the near future. 2. To include .C files (files including main()) in the examples that serve as models for solving various linear algebra problems and illustrate the choice of field, blackbox, algorithm. 3. To make clear the nature of solutions/ and some other areas as work-in-progress. (particularly regarding small fields). 4. To remove the Vector template parameter from the blackbox classes and give blackbox apply() two template parameters: the InVector and OutVector. Most blackboxes still take the Field template parameter. template OutVector& MyBB::apply(OutVector& y, const InVector& x); 5. To have a documentation system that produces an alphabetical index and includes more "why" information and more "restrictions" information.