Live data from Hacker News

MatLisp: A library for scientific computation in Common Lisp

github.com

21–29 of 29 posts

Re: MatLisp: A library for scientific computation in Common Lisp

#21

I'm actually super curious, how many computationally heavy science folks are writing code in Lisp? Seems much more elegant than, say, Matlab.

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

Re: MatLisp: A library for scientific computation in Common Lisp

#22
post #14

Earlier quoted context omitted.

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

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 oriente…

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.

Re: MatLisp: A library for scientific computation in Common Lisp

#23

I'm actually super curious, how many computationally heavy science folks are writing code in Lisp? Seems much more elegant than, say, Matlab.

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.

Re: MatLisp: A library for scientific computation in Common Lisp

#24
post #7

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)

Just getting into R, what are some killer features it has CL doesn't?

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.

Re: MatLisp: A library for scientific computation in Common Lisp

#25
post #22

Earlier quoted context omitted.

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 oriente…

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.

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. :(

Re: MatLisp: A library for scientific computation in Common Lisp

#26
For those who are looking for a LISPish replacement for Matlab, you might want to try lush (at http://lush.sourceforge.net/ ) ?

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

Re: MatLisp: A library for scientific computation in Common Lisp

#27

I'm actually super curious, how many computationally heavy science folks are writing code in Lisp? Seems much more elegant than, say, Matlab.

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.

Re: MatLisp: A library for scientific computation in Common Lisp

#28
post #25
post #22

Earlier quoted context omitted.

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.

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.

Re: MatLisp: A library for scientific computation in Common Lisp

#29
post #26

For those who are looking for a LISPish replacement for Matlab, you might want to try lush (at http://lush.sourceforge.net/ ) ? 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... :)

Yann and his group have moved to Torch 7.

I think the last commit on LUSH was from ~2012 (I could be wrong). It also doesn't come with Lexical scope, or CLOS support (again I could be wrong). It is very impressive though.

Post reply on HN