MatLisp: A library for scientific computation in Common Lisp(github.com)
github.com
MatLisp: A library for scientific computation in Common Lisp
https://github.com/matlisp/matlisp
7 comments
[deleted]
Looks like a well designed library. I'll try it out soon.
I'm actually super curious, how many computationally heavy science folks are writing code in Lisp? Seems much more elegant than, say, Matlab.
My guess it's a proportionally low number. I looked into matlisp when I did my PhD in scientific computing - none of the other people I worked with had any interest in it. I couldn't pursue it since I would have to reimplement or interface each and every library myself, a workload I couldn't justify at the time.
So, although lisp might have been great, in the end I stayed with Python/C++. Guess I'm not the only one with similar experiences.
So, although lisp might have been great, in the end I stayed with Python/C++. Guess I'm not the only one with similar experiences.
You'd be surprised by how much less elegant CL is, right off the bat.
Thankfully, however, one can tweak it in so astonishing a way - I still miss parameterized types though - that once you realize the nature of your problem, and put in lots of due work, things tend to become easy in the long run; I particularly adore being able to write iterate macros (adding new "for" clauses").
That said, Matlisp is still in a stage of infancy ("research grade"), and while I welcome contributions, it should be noted that it is not yet a replacement for R/Numpy/MATLAB, atleast not for the casual user.
Thankfully, however, one can tweak it in so astonishing a way - I still miss parameterized types though - that once you realize the nature of your problem, and put in lots of due work, things tend to become easy in the long run; I particularly adore being able to write iterate macros (adding new "for" clauses").
That said, Matlisp is still in a stage of infancy ("research grade"), and while I welcome contributions, it should be noted that it is not yet a replacement for R/Numpy/MATLAB, atleast not for the casual user.
I work in a research lab and we never touch anything like Lisp.
What we use: C/C++, Matlab, Python, R, Fortran, and the occasional Mathematica. I myself have been getting into Julia.
What we use: C/C++, Matlab, Python, R, Fortran, and the occasional Mathematica. I myself have been getting into Julia.
My favorite E&M simulator is MEEP, http://ab-initio.mit.edu/wiki/index.php/Meep.
Although written in C++, it uses MIT-Scheme/guile as the control language. This is a problem because the steep learning curve discourages undergraduate students.
Although written in C++, it uses MIT-Scheme/guile as the control language. This is a problem because the steep learning curve discourages undergraduate students.
Ungrateful undergraduates. You give them a language that can be learned at a high rate and they go all demoralized on you! ;)
https://en.wikipedia.org/wiki/Learning_curve
MEEP looks interesting. Filed, for future use.
https://en.wikipedia.org/wiki/Learning_curve
MEEP looks interesting. Filed, for future use.
I wrote an old (and verbose) blog [1] about why I think Lisp is very suitable for heavy science – in my case Operations Research. In fact, the algorithm powering routific.com is written in it.
The key point is that if you were to map out different languages along the abstraction level, Lisp sits right in between the realms of low-level programming (e.g. Java) and modelling (e.g. Matlab). [2]
EDIT: added link to the image of languages along the axis of abstraction level
[1] https://kuomarc.wordpress.com/2012/03/05/the-uncommon-lisp-a...
[2] https://kuomarc.files.wordpress.com/2012/03/level-of-or-appr...
The key point is that if you were to map out different languages along the abstraction level, Lisp sits right in between the realms of low-level programming (e.g. Java) and modelling (e.g. Matlab). [2]
EDIT: added link to the image of languages along the axis of abstraction level
[1] https://kuomarc.wordpress.com/2012/03/05/the-uncommon-lisp-a...
[2] https://kuomarc.files.wordpress.com/2012/03/level-of-or-appr...
In all my time working in scientific computing and talking with others, I only know of one case.
The huge amount of libraries for Python, C, C++, and Fortran make them the obvious choice.
Plus functional programming paradigms aren't always the best to do scientific programming. It can be done, but it's really not the right tool for the job, in most cases.
The huge amount of libraries for Python, C, C++, and Fortran make them the obvious choice.
Plus functional programming paradigms aren't always the best to do scientific programming. It can be done, but it's really not the right tool for the job, in most cases.
I guess you can count Yann LeCun, Leon Bottou and Richard Sutton among those. And those are the ones I can think of off the top of my head. Regarding the first two, see also my comment about Lush in this thread.
rcl (invoke R inside lisp), cl-num-utils, cl-mathstats, cl-variates, cl-randist, antik...
Lisp was my first and last love. But I left her years ago due to lack of libraries and etc. Work mostly in R these days, but I do mess with my .emacs file every now and then.
Similar experience to yours, Mandus.
(oh, post-doc in computational biology, which should qualify as one branch of computationally heavy science)
Similar experience to yours, Mandus.
(oh, post-doc in computational biology, which should qualify as one branch of computationally heavy science)
Just getting into R, what are some killer features it has CL doesn't?
A huge amount of useful, user-created libraries for many statistical, ML, programming tasks. CL has some, but R has lots more traction in that realm.
Straight out of the box you get "a lot" of statistical functionality (not to mention things like easy io), a good repl on osx, and incredible plotting functionality is available almost instantly thru installing ggplot2.
it also is an interactive language, much like CL. This is a killer feature for exploratory work.
The other two posts are right about the main differentiators.
The other two posts are right about the main differentiators.
There is a new - more MOP-py - branch I'm working on, which is yet to be finished (ping me if you'd like to see a preview).
See,
https://github.com/matlisp/matlisp/tree/t2
The classes (and methods) are now "dynamically compiled" -like FEMLISP.
The classes (and methods) are now "dynamically compiled" -like FEMLISP.
I've personally been interested in implementing something similar on top of BLAS / LAPACK in Scheme (either CHICKEN or Guile). Any tips from the authors? Any tips at all? My main questions concern how you decided on an API, or how you decided to construct primitives (matrices, ndarrays) within the library itself?
Basically, I'm just not sure where to start with such a large project. Currently I'm just trying to learn the language and ecosystem (how the FFI works, etc.) to the point where something like this may be feasible. I want to switch over to using scheme as my de-facto language, and this would be the number 1 library that would make it possible; Unfortunately, the lack of resources on the web for learning how to make good lisp-like APIs is lacking, and I really need some help figuring out how to do it. Unlike Python, we don't have PEP 8, and I think the difficulty in constructing a domain specific language for numerics is under-appreciated.
Thoughts? Tips? It seems MatLisp has been around for some time (2000, I guess?), so there's got to be someone with considerable experience here, right?
Basically, I'm just not sure where to start with such a large project. Currently I'm just trying to learn the language and ecosystem (how the FFI works, etc.) to the point where something like this may be feasible. I want to switch over to using scheme as my de-facto language, and this would be the number 1 library that would make it possible; Unfortunately, the lack of resources on the web for learning how to make good lisp-like APIs is lacking, and I really need some help figuring out how to do it. Unlike Python, we don't have PEP 8, and I think the difficulty in constructing a domain specific language for numerics is under-appreciated.
Thoughts? Tips? It seems MatLisp has been around for some time (2000, I guess?), so there's got to be someone with considerable experience here, right?
Getting API right is hard because you have no idea about the scope of your project at first. It is easy to get initial inspiration from other projects, but I still believe that having an API set in stone is a bad idea; Matlisp itself has literally been rewritten ~4 times.
That said, I'd recommend checking out Numpy, and projects in lisp lisp scmutils, lisp-matrix, matlisp, femlisp...
That said, I'd recommend checking out Numpy, and projects in lisp lisp scmutils, lisp-matrix, matlisp, femlisp...
Thanks for the response. I definitely know about Numpy, it's currently what I use instead of lisp / scheme, mostly because it's currently the least painful way to do numerical computing (in my opinion, that is). Unfortunately, Python is not a lisp (and yes, I know of Hy) which does bring forth it's own limitations.
The biggest concern I have with re-implementing Numpy in Scheme / Lisp is that it's very object oriented. Certainly, many of the ufunc methods in Numpy can be composed or chained in a very functional style, but at its core Numpy is Pythonic, and Pythonic code means using OOP for abstraction. Mainly, I'm concerned with how one actually transfers this over into Lisp like languages. Sure, CHICKEN has coops, Guile has goops, which are basically Common Lisps' CLOS, but taking the concept of Numpy and expressing it in a CLOS-like system sometimes just feels wrong.
That said, I think the guys behind clojure.core.matrix have done some work facing similar challenges, but I don't really know enough to evaluate if they've done the right thing. Moreover, Clojure itself almost makes this job easier, because it has interfaces / protocols from the get-go, whereas Scheme and CL don't quite share the same properties.
In any case, thanks again for your reply. If you ever write anything regarding those 4 rewrites, or if you have written anything regarding your decisions on refactoring and improving an API, I'd love to read it. I know a lot of people hold Numpy up as a gold standard, but I still find it very hard to put in explicit terms what makes programming with Numpy arrays more pleasant than using MATLAB arrays, Eigen (C++) matrices / vectors, or other similar systems.
The biggest concern I have with re-implementing Numpy in Scheme / Lisp is that it's very object oriented. Certainly, many of the ufunc methods in Numpy can be composed or chained in a very functional style, but at its core Numpy is Pythonic, and Pythonic code means using OOP for abstraction. Mainly, I'm concerned with how one actually transfers this over into Lisp like languages. Sure, CHICKEN has coops, Guile has goops, which are basically Common Lisps' CLOS, but taking the concept of Numpy and expressing it in a CLOS-like system sometimes just feels wrong.
That said, I think the guys behind clojure.core.matrix have done some work facing similar challenges, but I don't really know enough to evaluate if they've done the right thing. Moreover, Clojure itself almost makes this job easier, because it has interfaces / protocols from the get-go, whereas Scheme and CL don't quite share the same properties.
In any case, thanks again for your reply. If you ever write anything regarding those 4 rewrites, or if you have written anything regarding your decisions on refactoring and improving an API, I'd love to read it. I know a lot of people hold Numpy up as a gold standard, but I still find it very hard to put in explicit terms what makes programming with Numpy arrays more pleasant than using MATLAB arrays, Eigen (C++) matrices / vectors, or other similar systems.
Well, sure you can't exactly copy what Numpy does, but it is not too difficult to do what they do with CLOS.
I think getting the slicing sematics right is crucial for making things easy, and without an infix reader it is hard, for a Lisp to compete on usability in Numerical computing.
I think getting the slicing sematics right is crucial for making things easy, and without an infix reader it is hard, for a Lisp to compete on usability in Numerical computing.
CLOS-style OO and infix syntax leads pretty naturally to Dylan (http://opendylan.org/) ... I'd love to see numeric stuff in Dylan, but no time for it myself. :(
I like my math infix, and my programs in prefix; Dylan - atleast the newer incarnation - does not fit the bill.
I wrote what amounts to this for scala/JVM. The API is definitely hard. I found numpy to be the best to follow in terms of API. It's what most people understand.
It is a very mature platform, and has an extensive library, including bindings to GSL, LAPACK, and BLAS.
Lush started out as a (differently named) project of Leon Bottou and Yann LeCun, which might serve as an endorsement... :)