(Sorry, Patrick. I forgot to CC haskell-cafe.)
Salute! Excellent!
Patrick Perry
Wow, thanks for noticing, Alberto! For anyone interested, I put up a formal announcement describing the bindings a little bit here:
I just registered the domain yesterday, so it may take a few days to resolve the DNS magic. Here's the text of the announcement:
The magic is working, now.
I’m really happy that people seem to be interested in the library. Alberto, in particular, is the primary author of hmatrix, another haskell linear algebra library (which I stole a few ideas from), so if he endorses it, that means a lot to me.
So, Yet Another Linear Algebra Library? I’ve already mentioned hmatrix. There’s also another one called HBlas. Why would anyone want a third? Here are my reasons:
* Support for both immutable and mutable types. Haskell tries to make you use immutable types as much as possible, and indeed there is a very good reason for this, but sometimes you have a 100MB matrix, and it just isn’t very practical to make a copy of it every time you modify it. hmatrix only supports immutable types, and HBlas only supports mutable ones. I wanted both.
I didn't use hmatrix a lot, because I wrote some STUArray things and I wasn't sure what to do with that. However, I just noticed that there is a bunch of ST growing under Data.Packed in hmatrix. Guess things is going to change, soon. And perhaps with your work, Alberto doesn't need to reinvent the wheel anymore.
* Access control via phantom types. When you have immutable and mutable types, it’s very annoying to have separate functions for each type. Do I want to have to call “numCols” for immutable matrices and “getNumCols” for mutable ones, even though both functions are pure, and both do exactly the same thing? No. If I want to add an immutable matrix to a mutable one, to I want to first call “unsafeThaw” on the immutable one to cast it to be mutable? No. With the phantom type trick, you can get around this insanity. Jane Street Capital has a very good description of how this works.
Lovely!
* Phantom types for matrix and vector shapes. This is a trick I learned from darcs. It means that the compiler can catch many dimension-mismatch mistakes. So, for instance, a function like foo :: (BLAS1 e) => Matrix (m,n) e -> Matrix (n,k) e -> Int -> Vector m e foo a b i = let x = row b i in a <*> x will not type-check. (”<*>” is the function to multiply a matrix by a vector. Everything is ok if you replace “row” by “col”.) This feature has caught a few bugs in my code.
If I understand this correctly, the compiler can catch dimension mismatches so that using `col' will result in a compilation error when m and k are different, is it so?
LAPACK support is on the horizon, but that may take awhile. Also, I probably won’t do more than SVD, QR, and Cholesky, since those are all I need. Expect a preliminary announcement by the end of the summer.
This work would not have been possible without looking at the other excellent linear algebra libraries out there. In particular the GNU Scientific Library was the basis for much of the design. I also drew inspiration from hmatrix and the haskell array libraries.
Please let me know if you have any success in using the library, and if you have any suggestions for how to make it better.
I haven't look through the code, yet. But it looks like there are certain levels of similarities between blas and hmatrix. Is it possible for these two libraries to cooperate well with each other? (I didn't look at HBlas, so can't say much about that.) Apart from some warnings, the library compiles fine in my system. But there is a minor issue about the library it links against when `./Setup test'. I need to use `-lcblas' instead of `-lblas' to get it to link to correct libraries. I don't know other people's system. But in my system, Gentoo Linux, I use blas library provided by atlas, and libblas.so is a fortran library and libcblas.so is for C. All in all, good job. Thanks. Xiao-Yong -- c/* __o/* <\ * (__ */\ <