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]

Re: Guile numerical work and uniform arrays


>>>>> "K" == Klaus Schilling <Klaus.Schilling@home.ivm.de> writes:

    K> What is the advantage of using uniform arrays over
    K> application-specific smobs as in Chris Lee's example for g-wrap
    K> (from the Meschach lib)?  The gsl already contains a few matrix
    K> utilities which might be wrapped as well.  Chrlib seems to work
    K> along these lines, based on BLAS and LAPACK.

I'm sorry I have been absent from this conversation -- I've been
traveling to conferences and such and have had very limited Internet
access for more than a week.

My numerical work in Guile is based purely on my own needs, so I'll
describe briefly what I am doing and why.

I am a robotics student, so much numerical code I write needs to be
portable to a real-time operating system at some point, and sometimes
I use some cranky old real-time systems.  Also, I have an interest in
virtual reality applications, and want my numerical code to be
suitable for these as well.  This means that although I want to use
Guile for much of my most exploratory coding, I also need to be able
to port my code to locations where Guile will not work (weird
real-time OSes), and is not suitable (say VR applications where only
real-time GC would make sense).  For this reason, the fact that most
numerical code (i.e. linear algebra/control Matlab kinds of things) is
not written with Scheme in mind, and the fact that I want all my
Scheme interface as portable to other interpreters as possible, I
avoid any Guile specific code as much as possible.  Using built-in
Guile uniform arrays is out of the question for me -- with a matrix
SMOB type and a few exported functions for setting/checking dimensions
and setting/referencing elements, I can do anything I need without
using built-ins for uniform arrays.  What I use Guile for is the
ability to use exported C types (as smobs) and functions and Scheme
together, and sometimes its module system.

This is how I structure my system:

1 - CHRLIB (the C interface) must be able to stand on its own.
    Fundamentally, this is an interface for programming matrix code in
    C, not Scheme.  I often write C code for CHRLIB which is not
    linked against Guile.  CHRLIB is basically a C programming wrapper
    for BLAS and LAPACK.  Although these are very good numerical
    libraries, they do make CHRLIB more difficult for some people to
    use because they are less packaged than GNU software.  I have
    these on my IRIX and Debian Linux systems, but don't know where to
    point others who want RPMs or tar.gz files with Makefiles.  There
    are some tricky issues on using FORTRAN and C together if you
    aren't used to this, although I see some relevant patches for
    autoconf/automake out there and try to support as many systems as
    possible with my ./configure file.  I used to be a C++ geek, but
    have grown wary of it and won't put any C++ code in CHRLIB.
    Linking issues with only C and FORTRAN are tricky enough, and the
    C++ compilers on some old real-time systems I use are outdated and
    flaky.

2 - G-CHRLIB (the Scheme interface) must be fully portable.
    There is actually no Guile code in G-CHRLIB.  All code
    specifically for interfacing CHRLIB to Guile is generated by
    G-Wrap.  For this reason, I can port CHRLIB to any other Scheme
    interpreter by rewriting the code generator in G-Wrap.  In fact,
    I am testing my new version of G-Wrap which generates wrappers for
    RScheme as well as Guile, and am using it with my new version of
    CHRLIB.  The nice thing about this is it lets me switch
    interpreters at will.  I don't know which I will prefer in the
    end, but I want to try both for this task.
    G-CHRLIB uses four or more smobs, depending on what modules you
    use.  Matrices, vectors, integer vectors, and permutations each
    have their own smobs.  In my new matrix library, I am combining
    matrices and vectors together, and integer vectors and
    permutations together.  I use a flags word to distinguish them,
    and to support some new features.

-- 
Christopher Lee
http://www.cs.cmu.edu/~chrislee
chrislee@ri.cmu.edu