Hi guys (and gals!) of CLL,
I'm in the process of moving our main data taking/processing/what-if?
app from Matlab to SBCL (for reasons not needed to be spelled out for
this particular group :-), but they include actually having control
over what is going on to the lowest level, being able to think at the
highest level, an no, this is not a DSP application at all). One of the
immediate problems is the absence of obvious and de-facto accepted
standard for doing medium-level math in CL. I mean something in-between
linear algebra (matlisp for BLAS/LAPACK level works just fine for me)
and higher-level abstract things (I bet there are solutions, but I
personally have not yet encountered a problem! ;-) ) -- simple things
like non-linear function fitting, etc., -- minpack port distributed
with matlisp fails to run its own regression tests quite spectacularly
for me!
Thus a question to any kind soul who has been through the same process
-- what is the best recommended practices now?
There is that clmath tarball -- obviously not maintained, but some
parts are useful, some fail... CLOCC has math module -- is it
maintained at all? I've noticed that f2cl is maintained much more
actively than matlisp -- should I just fetch the most recent release
and unleash it on some random NETLIB function, as needed? Should I be
religious about installing the monthly releases of SBCL?
In short, where would someone actively using CL in this context suggest
me to look?
Thanks in advance!
Paul B.
From: Ken Tilton
Subject: Re: Reliable numerics in LISP? Matlisp, f2cl, Maxima, help to port xlispstat, clean the dust off NumRec, or what?
Date:
Message-ID: <FSrOg.358$%W2.197@newsfe10.lga>
······@gmail.com wrote:
> Hi guys (and gals!) of CLL,
>
> I'm in the process of moving our main data taking/processing/what-if?
> app from Matlab to SBCL
Cut your losses. Use Java.
> (for reasons not needed to be spelled out for
> this particular group :-)
The echo you hear reflects the size of this group. Ping Bradshaw for
tips on moving to Java.
>, but they include actually having control
> over what is going on to the lowest level, being able to think at the
> highest level, an no, this is not a DSP application at all). One of the
> immediate problems is the absence of obvious and de-facto accepted
> standard for doing medium-level math in CL. I mean something in-between
> linear algebra (matlisp for BLAS/LAPACK level works just fine for me)
> and higher-level abstract things (I bet there are solutions, but I
> personally have not yet encountered a problem! ;-) ) -- simple things
> like non-linear function fitting, etc., -- minpack port distributed
> with matlisp fails to run its own regression tests quite spectacularly
> for me!
>
> Thus a question to any kind soul who has been through the same process
> -- what is the best recommended practices now?
>
> There is that clmath tarball -- obviously not maintained, but some
> parts are useful, some fail... CLOCC has math module -- is it
> maintained at all? I've noticed that f2cl is maintained much more
> actively than matlisp -- should I just fetch the most recent release
> and unleash it on some random NETLIB function, as needed? Should I be
> religious about installing the monthly releases of SBCL?
Oh, yeah, pull some bit-rotten lib down out of the attic and make it
hum. You'll write it from scratch faster.
>
> In short, where would someone actively using CL in this context suggest
> me to look?
Away from CL. Can't you find a good C library? Then:
http://common-lisp.net/project/cffi/
There's a CFFI-grovel or some such out there that might even write the
bindings for you.
hth, kt
--
Cells: http://common-lisp.net/project/cells/
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
······@gmail.com wrote:
> I'm in the process of moving our main data taking/processing/what-if?
> app from Matlab to SBCL
I guess you must have your reasons for that, but I'll recommend
pretty strongly to use R for number crunching.
Broad scope, strong core, lots of add-ons, active development,
active user community. http://www.r-project.org/
> I've noticed that f2cl is maintained much more
> actively than matlisp -- should I just fetch the most recent release
> and unleash it on some random NETLIB function, as needed?
I have used f2cl + sbcl to translate a few Netlib files and it seems
to work as advertised, although the documentation is lacking.
As for Maxima, it runs without a hitch with sbcl on Linux.
Maxima has some functions specifically for number crunching
but there are a lot of gaps. That said, it would be terrific if you
want to contribute to the project. Eventually I think Maxima will
be well-suited to mixed symbolic/numerical computation
(e.g. data processing in which some of the data are symbols)
but Maxima is still weak on the numerical side.
FWIW
Robert Dodier
From: Pascal Bourguignon
Subject: Re: Reliable numerics in LISP? Matlisp, f2cl, Maxima, help to port xlispstat, clean the dust off NumRec, or what?
Date:
Message-ID: <87odthzh4l.fsf@thalassa.informatimago.com>
······@gmail.com writes:
> Hi guys (and gals!) of CLL,
>
> I'm in the process of moving our main data taking/processing/what-if?
> app from Matlab to SBCL (for reasons not needed to be spelled out for
> this particular group :-), but they include actually having control
> over what is going on to the lowest level, being able to think at the
> highest level, an no, this is not a DSP application at all). One of the
> immediate problems is the absence of obvious and de-facto accepted
> standard for doing medium-level math in CL. I mean something in-between
> linear algebra (matlisp for BLAS/LAPACK level works just fine for me)
> and higher-level abstract things (I bet there are solutions, but I
> personally have not yet encountered a problem! ;-) ) -- simple things
> like non-linear function fitting, etc., -- minpack port distributed
> with matlisp fails to run its own regression tests quite spectacularly
> for me!
>
> Thus a question to any kind soul who has been through the same process
> -- what is the best recommended practices now?
What about maxima?
I don't know its status on sbcl (it's developed on gcl), so some
porting work may be in order.
--
__Pascal Bourguignon__ http://www.informatimago.com/
You're always typing.
Well, let's see you ignore my
sitting on your hands.
From: Richard S. Hall
Subject: Re: Reliable numerics in LISP? Matlisp, f2cl, Maxima, help to port xlispstat, clean the dust off NumRec, or what?
Date:
Message-ID: <f7xOg.7950$v%4.2613@newsread1.news.pas.earthlink.net>
Maxima builds fine under SBCL (recent versions at least)...
-- Rick
"Pascal Bourguignon" <···@informatimago.com> wrote in message
···················@thalassa.informatimago.com...
> ······@gmail.com writes:
>
>> Hi guys (and gals!) of CLL,
>>
>> I'm in the process of moving our main data taking/processing/what-if?
>> app from Matlab to SBCL (for reasons not needed to be spelled out for
>> this particular group :-), but they include actually having control
>> over what is going on to the lowest level, being able to think at the
>> highest level, an no, this is not a DSP application at all). One of the
>> immediate problems is the absence of obvious and de-facto accepted
>> standard for doing medium-level math in CL. I mean something in-between
>> linear algebra (matlisp for BLAS/LAPACK level works just fine for me)
>> and higher-level abstract things (I bet there are solutions, but I
>> personally have not yet encountered a problem! ;-) ) -- simple things
>> like non-linear function fitting, etc., -- minpack port distributed
>> with matlisp fails to run its own regression tests quite spectacularly
>> for me!
>>
>> Thus a question to any kind soul who has been through the same process
>> -- what is the best recommended practices now?
>
> What about maxima?
>
> I don't know its status on sbcl (it's developed on gcl), so some
> porting work may be in order.
>
> --
> __Pascal Bourguignon__ http://www.informatimago.com/
> You're always typing.
> Well, let's see you ignore my
> sitting on your hands.
From: Raymond Toy
Subject: Re: Reliable numerics in LISP? Matlisp, f2cl, Maxima, help to port xlispstat, clean the dust off NumRec, or what?
Date:
Message-ID: <sxdd59xxhh0.fsf@rtp.ericsson.se>
>>>>> "pbunyk" == pbunyk <······@gmail.com> writes:
pbunyk> standard for doing medium-level math in CL. I mean something in-between
pbunyk> linear algebra (matlisp for BLAS/LAPACK level works just fine for me)
pbunyk> and higher-level abstract things (I bet there are solutions, but I
pbunyk> personally have not yet encountered a problem! ;-) ) -- simple things
pbunyk> like non-linear function fitting, etc., -- minpack port distributed
pbunyk> with matlisp fails to run its own regression tests quite spectacularly
pbunyk> for me!
I'm not sure they ever worked. But the version that's included with
f2cl does work.
pbunyk> There is that clmath tarball -- obviously not maintained, but some
pbunyk> parts are useful, some fail... CLOCC has math module -- is it
pbunyk> maintained at all? I've noticed that f2cl is maintained much more
pbunyk> actively than matlisp -- should I just fetch the most recent release
pbunyk> and unleash it on some random NETLIB function, as needed? Should I be
Yes, matlisp has languished quite a bit. But I don't use matlisp at
all anymore, so it does everything I need. :-) And no one else that
has really sent messages about missing functionality so it's
feature-complete AFAICT. (Yes, I know there are a couple of
outstanding issues that have not be taken care of.)
f2cl won't work on "random" netlib functions, but will work on some of
the more "well-written" ones.
Please send mail to the matlisp lists and to the f2cl lists if
something is not working for you or you need something.
The other option is to use cffi (or uffi) to interface to precompiled
C (or Fortran) functions or gsl.
Ray
Raymond Toy wrote:
> >>>>> "pbunyk" == pbunyk <······@gmail.com> writes:
>
> pbunyk> standard for doing medium-level math in CL. I mean something in-between
> pbunyk> linear algebra (matlisp for BLAS/LAPACK level works just fine for me)
> pbunyk> and higher-level abstract things (I bet there are solutions, but I
> pbunyk> personally have not yet encountered a problem! ;-) ) -- simple things
> pbunyk> like non-linear function fitting, etc., -- minpack port distributed
> pbunyk> with matlisp fails to run its own regression tests quite spectacularly
> pbunyk> for me!
>
> I'm not sure they ever worked. But the version that's included with
> f2cl does work.
>
> pbunyk> There is that clmath tarball -- obviously not maintained, but some
> pbunyk> parts are useful, some fail... CLOCC has math module -- is it
> pbunyk> maintained at all? I've noticed that f2cl is maintained much more
> pbunyk> actively than matlisp -- should I just fetch the most recent release
> pbunyk> and unleash it on some random NETLIB function, as needed? Should I be
>
> Yes, matlisp has languished quite a bit. But I don't use matlisp at
> all anymore, so it does everything I need. :-) And no one else that
> has really sent messages about missing functionality so it's
> feature-complete AFAICT. (Yes, I know there are a couple of
> outstanding issues that have not be taken care of.)
>
> f2cl won't work on "random" netlib functions, but will work on some of
> the more "well-written" ones.
>
> Please send mail to the matlisp lists and to the f2cl lists if
> something is not working for you or you need something.
>
> The other option is to use cffi (or uffi) to interface to precompiled
> C (or Fortran) functions or gsl.
MATLISP is quite fine, actually. Just needs a bit of documentation.
XLispStat shouldn't be ported if you want CommonLisp. There are issues
with the CommonLispStat implementation that I've been mangling through
for the past year, but it's getting there. I got sidetracked by
predicate dispatch (which is a rather nice way of handling statistical
calculations cleanly, with a minor (planned) performance hit).
For the person mentioning R -- There are a number of CL <-> R gateways,
we've got one working, and would release except for some perfectionist
issues.
best,
-tony
From: ············@gmail.com
Subject: Re: Reliable numerics in LISP? Matlisp, f2cl, Maxima, help to port xlispstat, clean the dust off NumRec, or what?
Date:
Message-ID: <1158641294.317500.265180@h48g2000cwc.googlegroups.com>
I'm thinking of redoing Matlisp to support things like matrix views,
which are handy for the recursively-structured approach to linear
algebra that's popular nowadays, and also handy for my research.
Matlab doesn't support the in-place factorizations that I want to do in
order to save memory, and it also doesn't give me access to things like
the Householder vector representation of a Q factor in a QR
factorization, but I'm not keen on doing it all in C or Fortran. (I've
written up a bunch of ideas -- let me know if you want to help. I've
only been serious with Lisp for a year and a half or so, though I've
been coding for almost 20 years and professionally for some of that.
I've got a lot of ideas about exploiting code transformations via
macros to make things more efficient and easier to use.)
Lisps can be tricky about numerics. For example, I wanted to generate
a NaN in C code without using C99 features, so I did "const double x =
0.0 / 0.0". It worked fine by itself. Then I called that function
from Allegro CL 8.0 on a Mac G3 (PPC) with the FFI, and behold! a
floating-point exception. Apparently some Lisps change the
floating-point processor flags and make things signal when they
normally wouldn't. (This kind of makes sense for Lisp being more
interactive than C and all, but it breaks your C and Fortran if you
call it through an FFI.) So I think there are incompatibilities and
issues between the different Lisp systems that have yet to be resolved.
(I don't think Franz is keen on fixing that stuff because their
customers are enterprise / DB types -- scientists would tend to use the
open-source Lisps if they use Lisp at all. Just my guess though.)
You could always get the help of SWIG to wrap the GSL (GNU Scientific
Library), but I can't vouch for the correctness, accuracy or efficiency
of any of the algorithms in there. Plus it's GPL'd, not LGPL'd, so you
might have troubles there. If you aren't a commercial operation, you
can get a free (as in beer, not as in code) version of Intel's Math
Kernel Library (MKL) and use the goodies in there. Other processor
vendors may have their own free (beer) math libraries that you can use.
Just wrap 'em with SWIG or your favorite FFI.
Lisp could really use a GSL-like project that exploits native Lisp
idioms. I think that could make Matlab look like some high-school
kid's weekend project, if it were carried to fruition. (Think how easy
it would be to make a "Matlab compiler" for example, if you write a
translator from Matlab to a Lispy interface language and run the
results straight through the Lisp compiler. Plus you could have macros
that do code optimization for you.)
Best,
Mark Hoemmen
http://www.cs.berkeley.edu/~mhoemmen/
From: Raymond Toy
Subject: Re: Reliable numerics in LISP? Matlisp, f2cl, Maxima, help to port xlispstat, clean the dust off NumRec, or what?
Date:
Message-ID: <sxdhcz3hmfd.fsf@rtp.ericsson.se>
>>>>> "mark" == mark <············@gmail.com> writes:
mark> Lisps can be tricky about numerics. For example, I wanted to generate
mark> a NaN in C code without using C99 features, so I did "const double x =
mark> 0.0 / 0.0". It worked fine by itself. Then I called that function
mark> from Allegro CL 8.0 on a Mac G3 (PPC) with the FFI, and behold! a
mark> floating-point exception. Apparently some Lisps change the
mark> floating-point processor flags and make things signal when they
mark> normally wouldn't. (This kind of makes sense for Lisp being more
This depends on the Lisp implementation, but cmucl can do this:
CL-USER> (set-floating-point-modes :traps nil)
; No value
CL-USER> (/ 0.0 0.0)
#<SINGLE-FLOAT Quiet NaN>
I know that matlisp goes out of its way to make sure the FPU flags are
set so no exceptions are signaled, because some Sun(?) Fortran manual
said Fortran code expected that.
Ray
············@gmail.com wrote:
> Lisps can be tricky about numerics.
> So I think there are incompatibilities and
> issues between the different Lisp systems that have yet to be resolved.
After some investigation of floating point arithmetic in CL
(in hopes of getting Maxima to work the same on all CL implementations)
I have concluded that the spec is just not strong enough to make it
straightforward to write 100% portable floating point code.
There are inconsistencies that cannot be resolved by appealing to the
spec.
In particular, CL is uncomfortable with IEEE 754 infinity and
not-a-number, because the definition of floating point number
rules out nonnumeric float values. ("A float is a mathematical rational
....")
Implementations differ as to treatment of nonnumeric values.
Other issues: implementations differ as to the definitions
of different float sizes (short, single, double, and long).
The part of the spec which defines branch cuts for complex
functions is apparently susceptible to multiple interpretations.
Probably if you stick to a single implementation and avoid
funny stuff like inf and nan, you won't run into problems.
> (I don't think Franz is keen on fixing that stuff because their
> customers are enterprise / DB types -- scientists would tend to use the
> open-source Lisps if they use Lisp at all. Just my guess though.)
I have it on good authority (Fateman) that Allegro's behavior wrt
floating point numerics is motivated by a close reading of the CL spec.
FWIW
Robert Dodier
From: ············@gmail.com
Subject: Re: Reliable numerics in LISP? Matlisp, f2cl, Maxima, help to port xlispstat, clean the dust off NumRec, or what?
Date:
Message-ID: <1158746334.206838.226130@d34g2000cwd.googlegroups.com>
Robert Dodier wrote:
> Probably if you stick to a single implementation and avoid
> funny stuff like inf and nan, you won't run into problems.
Hm, inf and nan can be pretty important for certain LAPACK functions.
If the hardware supports fast arithmetic with infs and nans, it helps
them a lot, but some processors trap on infs and nans which makes the
code really slow. Sometimes the LAPACK developers resort to writing
two different versions of the code -- one for misbehaving machines and
one for good machines. I'm not an expert with that stuff but I suspect
that it relates to eigenvalues and generalized eigenvalues -- I can
poke around and ask LAPACK developers at Berkeley if you like.
I can always catch Lisp-signaled floating-point exceptions for cases
like trying to invert a singular matrix. The exceptions aren't as
helpful as if they were thrown by straight Lisp code, because you
probably won't be able to examine the Fortran source, and even if you
could, LAPACK code is very hard to read for the uninitiated. (Or worse
yet, some auto-tuned assembly language xTRMM divides by zero... -- if
the Lisp _doesn't_ signal an exception, I'll have to scan the output
for NaNs / Infs.)
At least Lisp doesn't make the mistake of APL by saying 0.0/0.0 == 1 ;p
> > (I don't think Franz is keen on fixing that stuff because their
> > customers are enterprise / DB types -- scientists would tend to use the
> > open-source Lisps if they use Lisp at all. Just my guess though.)
>
> I have it on good authority (Fateman) that Allegro's behavior wrt
> floating point numerics is motivated by a close reading of the CL spec.
I stand corrected :) (I should have taken the time to ask Prof.
Fateman last semester when he talked about floating-point in his
computer algebra lectures...)
Many thanks,
mfh
From: HL
Subject: Re: Reliable numerics in LISP? Matlisp, f2cl, Maxima, help to port xlispstat, clean the dust off NumRec, or what?
Date:
Message-ID: <863basu1i0.fsf@agora.my.domain>
······@gmail.com writes:
> Hi guys (and gals!) of CLL,
>
> I'm in the process of moving our main data taking/processing/what-if?
> app from Matlab to SBCL (for reasons not needed to be spelled out for
> this particular group :-),
Hi --
I'm not sure this is the answer you expect, but you should look at
this thread in comp.lang.scheme:
http://groups.google.com/group/comp.lang.scheme/browse_thread/thread/d1c0255247b3bb4d/f245fdf28725d219?lnk=gst&q=number+crunching&rnum=2#f245fdf28725d219
There's a Physics PhD in it from Cornell who claims Bigloo Scheme
gives a whopping performance. My answer, of course, implies you want
to roll or adapt your own routines.
And, BTW, did you know, while I'm in that area, did you see the
benchmarks for GHC (Glasgow Haskell Compiler) as compared to Fortran
G95? It's just amazing:
http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=ghc&lang2=g95
If the last URL got you curious, then read more form the GHC homepage...
I don't know about you, but me, I orbit around these languages and I
think skills gathered in one lead you easily to the other. So, I'm
really not loyal to one or to the other.
HTH,
HL