PackageDescription: Smallapack-External


Smallapack - External

Last published: May 3, 2012 by 'nice'

Defines 26 Classes
Extends 26 Classes

Smallapack-External is a package part of Smallapack (The Smalltalk interface to LAPACK).
It holds classes required to interface with external C and FORTRAN functions and objects making the LAPACK/BLAS library.

The libraries are:
BlasLibrary : a basic linear algebra system (mainly sum and products of matrix/vector).
CBlasLibrary : blas version with more C-like argument conventions
LapackLibrary : the linear algebra package.
ArrayLibrary : Other functions needed to optimize Smallapack execution time (profiling).

Some versions of BLAS library are highly optimized, some commercial and some non commmercial.
Most noticeable non commercial optimization of BLAS is ATLAS.
ATLAS implement the C-like interface used by CBLAS (passing const argument by value instead of pointers).

Array library contains C code for many operations not included in BLAS nor LAPACK as for example:
- converting Matrix from double to single precision,
- or doing elementwise product (the matlabish a(:) .* b(:) or FORTRAN-95 A(:)*B(:) ).
If library is not available, then Smallapack with fall back using a naive slow implementation.
Sources (machine independant) and a makefile (for linux) can be found at [http://ncellier.ifrance.com/Smallapack/index.html] in tar.gz format.
Sources are in C-code. Unlike ATLAS, they are not highly optimized.

Each Library has four subclasses specialized for handling:
- IEEE 754 single precision real matrix/array/vector (BLAS and LAPACK convention use letter S)
- IEEE 754 double precision real matrix/array/vector (BLAS and LAPACK convention use letter D)
- IEEE 754 single precision complex matrix/array/vector (BLAS and LAPACK convention use letter C)
- IEEE 754 single precision complex matrix/array/vector (BLAS and LAPACK convention use letter Z)
It is a convenient way to organize and factor Smalltalk code (polymorphism and genericity).
Usually, there is a single .dll or .so library holding functions for the four kinds.

Most of the C-Interface has been automagically generated, not using .h and VW ExtenalInterfaceBuilder,
but a the very specific SmallapackBuilder package.
This package interpret code comments in function header to check if variable are input/output
and generate the wrapper functions needed to pass arguments by pointer.
No memory is allocated inside LAPACK, pointers must be provided in the function argument list (the work arrays).
The Smalltalk interface implement wrapper functions for allocating memory.
This is a teddious work to code by hand, and should also be automated.
But comments concerning work array size in LAPACK are harder to interpret...
They spread on several lines and use mixed natural language like LWORK >= 1 AND LWORK >= MINMN*3+N WHERE MINMN=...

All these libraries have an abstract mother CMathLibrary that is used to hold common C declarations and definitions.

An old trick (since VW3.1 I think) is still implemented to handle multiplatform compatible external library name and path.
Unfortunately, it seems not to work anymore, so I did patch it, maybe not the right way, but it seems to work.
This is why there is an overriding extension patching ExternalLibraryHolder.

The external objects accessed by these libraries are mainly pointers to external collections of numbers (Arrays stored in contiguous memory).
The element type can be integer, logical, single and double IEEE 754 floating point real and complex numbers.
The direct C/FORTRAN objects are accessed by Smalltalk with a 1-base convention.
- CArrayAccessor is the class for handling any of these CType
- specialized subclasses for the four floating points kinds (SDCZ) are mostly here to deal
with moving efficiently memory to/from Smallatlk ByteArray like collections...

Beware, some messages do error bounds checking, some other do not.
Since these classes are doing direct pointer handling, Smalltalk natural protections are bypassed.
Interfering at this low level is dangerous: a bug here can cause a SEGV or worse, silently corrupt the image !
Note that reference to external data do not normally survive to image snapshots.
This is another reason why you should avoid using these class directly, unless you develop Smallapack extensions.
In other words, these classes should be declared private.
By now, they are public but you are warned.

For any detail concerning the LAPACK library, please refer to user guide [http://www.netlib.org/lapack/lug/].

LICENSE: (MIT) See copyright