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: a Guile linear-algebra package, RFC



This is a great idea --- I've done a bit of numerical stuff in guile
for which this would have come in handy (eg a raytracer (shudder)).

; 1) Is anyone interested in this package (if no one is interested,
;    maybe I should not bother).

Yes.

; 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.

I'd go for the flushing out bugs --- if someone felt up to writing a
test suite, many routines can be easily tested (eg, SVDcmp), and you
could use this for regression testing.  Something like c-torture. 

; 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.

I don't know Meschach, so it won't confuse me.  But it might be worth
binding them into + - * and / wherever possible. 

; 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).

Easier not...  if people are doing dynamic-linking then that setup
may be complicated.

; 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.

I don't have a problem with it (after having used NR code with
1-offset arrays in C)

; 6) Should I include only a subset of the above libraries?

Might as well just use the whole mess. 

; 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.

I'd port it to mine, but it wouldn't help --- my system is a Linux box
as well.  I might be able to test it on solaris, ultrix, sunos, irix, 

; 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?)

I wouldn't worry about it... how hard would it be to package LAPACK,
BLAS and FFTPACK with it? 

Thanks for the great package --- I do a lot of numerical hacking.  Now
I have a real incentive to get ctax working.  Scheme isn't that nice
for interactive use. 

Andrew
aarchiba@undergrad.math.uwaterloo.ca