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] |
>>>>> "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