Design alternatives

Underlying storage

  1. Lisp k-D array:
    Advantages: Disadvantages:
  2. Lisp 1-D array:
    Advantages: Disadvantages:
  3. C 1-D array:
    Advantages: Disadvantages:

Level 1 (lowest Lisp level) interface generation

  1. Parse the Fortran comment headers and function declarations
    Advantages: Disadvantages:
  2. Write the CFFI interfaces ourselves
    Advantages: Disadvantages:
  3. Run SWIG on the CBLAS and CLAPACK headers
    Advantages: Disadvantages:

Level 2 interface

  1. Support general tensors
    Advantages: Disadvantages: Notes:

Higher-precision arithmetic

The chief issue here is getting the full LAPACK-like functionality without rewriting it all by hand.

System for managing temporary variables

Whenever we go from a vector expression to a function that expects a vector or vector view, we have to generate a temporary. For example:

(solve! x A (+ w y z))
(which solves Ax = b (with b = w + y + z) and puts the result in x) has to create a temporary to store the result of w + y + z. If this code is called many times, e.g. in a loop, we end up creating a lot of temporaries. That's not something we can fix with vector expression optimization, because the solver expects a vector proper, not a series or some kind of expression template. (One could get around this by coding up a solver in Lisp that can take a series or expression template, but we don't want to redo the work of the LAPACK developers!)

It may be a good idea to have some sort of temporary vector management system that keeps and recycles temporaries. We could perhaps take advantage of finalization to make this system easier to implement. A system like this is handy if all the objects are about the same size, as for example with arbitrary-precision floating-point objects that are all set to have the same precision. However, for a heterogeneous collection of vectors and matrices, there would be a lot of overhead in matching sizes and shapes of storage.

Last modified: Sun Oct 15 00:25:31 CST 2006