This is the mail archive of the guile@cygnus.com mailing list for the guile project.
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Hi --
I've been using Guile for a while now as a kind of Matlab-substitute
in research projects, and find it a fun way to write numerical
programs. Because I heard some interest in the base code for this
project a while ago, I have spent a couple of days trying to make my
libraries usable by the outside world (i.e. automake/autoconf/libtool
work), and would like feedback before I prepare the final version to
distribute (under the GPL). Depending upon the feedback, I should be
able to put in in a distributable form this week. I don't intend this
to be any kind of "official" linear-algebra package for Guile, but it
may be useful to some people.
The basic idea to make it easy to call high-performance numerical code
from guile, and to easily port numerical code easily between C and
guile (i.e. I sometimes like to prototype in Guile, and then port to a
stand-alone C program). At the moment, only double-precision real
numbers are supported (not single-precision nor complex). The Guile
uniform-array code is _not_ utilized, because I want the C to work
without libguile, and so the code is portable to other Scheme
implementations.
I have organized the code into two separate layers of libraries. The
first layer was originally the Meschach library, but I have replaced
it with a wrapper for the FORTRAN library BLAS and a little bit of
FFTPACK and LAPACK. The C-to-FORTRAN interface is built using the
cfortran.h header file (Burkhard Burow, University of Toronto, 1993).
As in Meschach, VEC is a C-structure representing a vector, MAT
represents a matrix, IVEC is a vector of integers, and PERM is a
permutation. A set of C functions performs memory management, and an
easy and (theoretically) dummy-proof interface to the underlying
FORTRAN libraries. I chose to build the first layer on top of FORTRAN
libraries because they were the highest-quality freely-obtainable
numerical libraries I know of, and they are included pre-built and
highly optimized on the SGI I use in my lab (and a few projects for
building high-performance BLAS for i586-Linux are ongoing).
The second layer is a set of libraries which wrap the first layer as
Guile modules. Most of the C-code for this layer is generated with
G-Wrap. In fact, this is why I originally wrote G-Wrap. This means
that the second-layer can be ported to other Scheme implementations by
porting the interface-generation code, and one can track changes to
the Guile interface by keeping G-Wrap up to date (I was inspired by
originally trying to do stuff like this on guile-iii -- or maybe it
guile-ii :). There is also some Guile-specific module code written in
Scheme at this layer.
The first layer can be used to write stand-alone programs in C,
without linking to Guile. It can also read and write most structures
like MATs and VECs in a manner compatible with the Scheme wrapper.
Here is the basic structure of the libraries.
--- layer-1 ------ libcmatrix -- MAT, VEC, IVEC, PERM
| memory management, BLAS, FFTPACK,
| LAPACK interface
+- libvv -- V_VEC and V_IVEC
| vector-of-vectors, vector of integer
| vectors -- useful for neural networks
+- libbinread
| hacks for reading and writing
| binary representations of VECs, MATs
+- libbp backprop-style neural network code,
| training via LBFGS-B algorithm
+- libht minimal homogeneous transform code,
| useful for graphics, robotics
+- libmarkov some hidden-markov-modelling (HMM)
code, useful for
gesture/speech-recognition algorithms
I'd like to get some feedback before I do the final preparations for
releasing the code:
1) Is anyone interested in this package (if no one is interested,
maybe I should not bother).
2) This code has been used to support a couple of my own personal
projects, but is not yet widely used or fully tested. The
underlying FORTRAN libraries are reliable, but it is possible that
there are bugs in the code which calls those libraries which could
result in incorrect results. Should I let people play with it at
their own risk and help me flush-out bugs bazzare-style, or is this
simply too risky for numerical code. Maybe I should wait until I
can test it more fully (a month or two) to reduce the risks?
At minimum, I will mark the routines which I haven't used much
so that they can be inspected before they are tried and trusted.
3) Even though I no longer am using Meschach, I still use many of the
same function names that Meschach uses. Worse, I changed the order
of some parameters. For instance, in Meschach, C = B + A (C,B,A
are matrices) is written as
m_add(B,A,C) or C = m_add(B,A,MNULL);
where in my library I use
m_add(C,B,A) or C = m_add(MNULL,B,A);
Is this a fatal flaw? Should I change the names of all my
functions? This would be a real pain for me because I'd have to
update all my personal code, but if potential users feel strongly
about this I will do it.
4) Should I assume that people know what BLAS and LAPACK are? Can
I let people find these themselves or should I try to write-up
some instructions for finding/compiling/installing them (I'm not an
expert on this, but I've done a little).
5) Does anyone have serious problems with column-major matrix
representation? I chose to be compatible with the FORTRAN
convention because it simplified the project as a whole.
6) Should I include only a subset of the above libraries?
7) Would people be willing to port this to their own systems and send
me patches to make the code more universal? I've set-up the
autoconf scripts so that it works on my Irix 6.3 and Debian Linux 2.0
machines, but the way FORTRAN libraries are used on these systems
is very different. Tweaking configure.in for other systems may
take a few tries.
6) I don't make much use of LAPACK yet. LAPACK-related code be in a
separate library so that people without LAPACK can use the
BLAS-only stuff? (Same with FFTPACK?)
Thanks for any comments,
-Chris