]> I was hoping to hold off on announcing this until the new year..... So please take this as just a "pre-announcement". We plan to release CamlFloat, a "matlab-like" (hopefully better) interface to Lapack+Blas "soon". Unfortunately, it is *not* (yet) built on top of Lacaml. It comes with a fully documented interface, a tutorial, and a block-sparse matrix module. The code has been extensively used in our own research. For people who cannot wait, they can find a preliminary release here: http://www.math.ucsb.edu/~lyons/camlFloat/ CleanFloat, a similar package for Clean (http://cs.kun.nl/~clean) will also be made available. --shiv-- On Dec 13, 2003, at 1:38 PM, Oleg Trott wrote: > On Saturday 13 December 2003 11:36 am, Markus Mottl wrote: >> On Sat, 13 Dec 2003, romildo@uber.com.br wrote: >>> I am looking for a good library for numerical >>> matrixes manipulation in OCaml. Can anybody help me? >> >> Although it has already been on the web for a few weeks, I hadn't >> actually >> announced it yet, waiting for comments of some co-developers: >> >> Lacaml is available in a new major version. This library interfaces >> the Fortran libraries BLAS and LAPACK for heavy-weight linear algebra >> (i.e. matrix computations). New features include support for complex >> transformations (complex numbers), and a convenient way of accessing >> submatrices using labels. As usual, you can choose either single or >> double precision computations. The computations can run in parallel >> on SMP-machines. >> >> You can download the library here: >> >> http://www.oefai.at/~markus/home/ocaml_sources.html#LACAML >> >> I'd be grateful for feedback! > > All right! I was actually thinking of giving it lately. First of all, > I think > the library is very interesting. Here are some of my assorted thoughts > regarding improving it. > > 1.) I think a matrix library has to have >= 2 levels of > user-frienliness. One > level should be easy to use and have a MATLAB feel to it, i.e. if > someone > wants the eigenvalues of a real matrix, he should just be able to write > e_vals = eigenvalues(A) > or > (e_vals, e_vecs) = eigensystem(A) > without having to worry about details. This should be built on top of a > low-level interface similar to LAPACK functions themselves. E.g. DGEEV > does > not even return the eigenvectors corresponding to complex eigenvalues, > but > rather something from which they can be reconstructed (which is what > one might actually want sometimes) > > Right now, it appears to me that LaCaml is close to the low level, but > not > quite there (because e.g. some LAPACK interfaces _return_ a matrix > rather > then letting the user modify some piece of memory in place like in > FORTRAN) > > 2.) Currently, LaCaml interfaces only a fraction of LAPACK. LAPACK is > big, and > interfacing all of it by hand is a huge job. On the other hand, MOST > of the > information needed for the low-level interface can be parsed from > function > declarations in *.f files (I kept thinking about this while using > LAPACK in > my C++ programs). Maybe the way to interface all of LAPACK is > to parse those *.f files into some intermediate form, let humans edit > it (e.g. > add minimum workspace size expressions, etc. - obvious from docs, but > hard to > parse/NLP), and then auto-generate the whole interface from the > result. This > will have the addtional benefit of being consistent (If you just let a > bunch > of developers contribute interface code directly, they will bring > their own > "style" to their parts of the interface) > > 3.) Regarding "WORK" arguments. Why not have a shared workspace: > > (* module Workspace, untested *) > > (* private *) > let workspace = ref (Array1.create float64 100) > > (* public *) > let size () = Array1.dim !workspace > > let resize n = workspace := Array1.create float64 n > > let delete () = resize 0 > > let get_float64 n = if size () >= n then !workspace > else (resize n; > !workspace) > > This way, one does not need to "hoist" workspace allocation out of > loops > manually. OTOH performance does not suffer from allocating workspace > for each function call. I don't know how this would inter-operate with > threading or SMP though. > > 4) Submatrices. For a function f that takes a matrix argument "a" of > size m by > n, you normally use something like > > f ar ac a m n > > where ar and ac refer to the "beginning" of the submatrix. Even though > they > can default to 1, this is kind of inconvenient compared to > > f a > > I would propose using the latter everywhere, and letting the "mat" type > include ar, ac, m and n. > > submatrix : int -> int -> int -> int -> mat -> mat > (* submatrix x1 y1 x2 y2 a *) > > would provide "views" into matrix a. > > 5) I think a function that lets one view matrices as vectors > vec_of_mat is > needed. They are all just ordered sets of numbers after all. > > 6) License. Have you thought of adding a static linking exception to > your LGPL > license? Even INRIA did with Caml standard library. I might even > consider > contributing then :-) > > -- > Oleg Trott <oleg_trott@columbia.edu> > > ------------------- > To unsubscribe, mail caml-list-request@inria.fr Archives: > http://caml.inria.fr > Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: > http://caml.inria.fr/FAQ/ > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners ------------------- To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ Beginner's list: http://groups.yahoo.com/group/ocaml_beginners