In order to enjoy the full power of Lisplab you must install some foreign libraries. These are

- BLAS – Basic Linear Algebra Subprograms. Preferably the Atlas build.
- LAPACK – Matrix library. Preferably the Atlas build.
- FFTW – The fastest Fast Fourier Transform available.

Lisplab has been developed with SBCL, SLIME and ASDF on Linux, and there are yet unnecessary bindings to these platforms.

- Some of the optimized lisp code uses the
SBCL macro
`truly-the`

. - The FFTW FFI works only for SBCL.
- The Matlisp FFI should in theory be portable to other lisps and Windows, but it has not yet been tested.
- The
`*READ-DEFAULT-FLOAT-FORMAT*`

must be`double-float`

when compiling Slatec. This is a minor problem.

Except from this, Lisplab should be self-contained and not depend on any other projects.

Lisplab is ASDF installable, but before you come so far you need to specify the location of the foreign libraries. You specify these in three special variables,

`*lisplab-libblas-path*`

`*lisplab-liblapack-path*`

`*lisplab-libfftw-path*`

`start.lisp`

, or
probably the easiest: directly in `lisplab.asd`

.
ASDF sub-systems:

*Lisplab*– the full Lisplab installation.*Lisplab-base*– the part of Lisplab without external dependencies.*Lisplab-matlisp*– FFIs to BLAS and LAPACK. These are modified version from Matlisp.*Lisplab-fftw*– FFI to FFTW for Fast Fourier Transform.*Slatec*– special functions, generated from Fortran by f2cl. Originally made for Maxima.*Quadpack*– integration routines, generated from Fortran by f2cl.

The simplest way to test Lisplab is to load `start.lisp`

.
If you have problems loading, first look at `start.lisp`

and see if you can hack it. Then look at `lisplab.asd`

.

To install BLAS, LAPACK, and FFTW, if you are too lazy to do a custom build, and is lucky enough to administer a Debian or Ubuntu machine, you typically write

# aptitude install libatlas3gf-base # aptitude install libfftw3-3

- The matrix classes and constructors follow the naming convention
from BLAS where you give names based on element type and
matrix structure.
The most used types are
*f - float*,*d - double*,*c - complex float*,*z - complex double float*, while for matrix structure*ge - general*,*di - diagonal*, and many more. So*matrix-dge*is a general matrix with double float elements, while*matrix-zge*is a general matrix with complex double float elements. - The generic functions of the basic algebra start with a dot:
`.+`

,`.-`

,`.*`

,`./`

,`.^`

,`.sin`

`.cos`

,`.tan`

,`.besj`

,`.re`

, etc. On numbers these functions work as the non-dotted Common Lisp functions and on matrices they work elementwise. - Linear algebra functions tend to start with
*m*:`m*`

,`minv`

,`mmax`

,`mtp`

, etc., but this conventions is not strictly followed. - The naming convention of files follow the layered structure of Lisplab, with level0 to level3.
- See Structure, for more about the naming conventions of matrix classes.

Lisplab has been developed for physics simulations and data handling. Lisplab started as a refactoring of Matlisp, but most of the code has been replaced and a lot new code has been written. The only Matlisp code that is kept is the interfaces to BLAS and LAPACK.

Some large extensions that could be fun to do:

- Parallel computation, e.g. using MPI.
- More native linear algebra routines, e.g. eigenvalue computation.
- New non-matrix algebra items, e.g. quaternions, polynomes or arbitrary precision floats.
- Symbolic manipulation. Could make something like
*ginac*in`c++`

. - New matrix optimization for new usage, e.g. integer matrices for image processing or cryptography.
- Interface to new foreign libraries, e.g. GSL.
- More special functions.

The purpose of Lisplab is to be a platform for mathematical computations. From this perspective it is clear that it will never be complete. Also, since there is no spec it is not obvious what is a bug and what is not!

Hence, the list in this section must be read as non-systematic gathering of problem features.

- Lisplab runs only on SBCL. Lisplab is mainly ANSI Common Lisp, so just minor changes in the build-system should make it run on other lisps, but the problem is that it will most probably be slow. It should be fast on CMUCL, though.
- Lacks a formal spec.
- Poorly tested.
- Lacks error checks (but these should not be made before a spec!)