Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
[Caml-list] Matrix libraries
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Markus Mottl <markus@o...>
Subject: Re: [Caml-list] Matrix libraries
On Sun, 14 Dec 2003, Oleg Trott wrote:
> On Sunday 14 December 2003 10:01 am, Markus Mottl wrote:
> > In any case, LACAML is supposed to stay a low-level interface to
> The $1e6 quesion: do you want the library to be safe from user abuse, i.e.
> no function input should result in corrupted memory ?

Yes, absolutely! That's why I think that checking all parameters before
passing them to LAPACK is a necessity even if it is a bit tedious
to implement considering the huge number of arguments that some
LAPACK-functions take.

> Thanks for the link! CamlFloat isn't even in Google yet. It must be new. Are 
> there others?

Yes, CamlFloat is fairly new. I don't know whether there are
others. Interfacing BLAS/LAPACK is not for the fainthearted: it has tons
of functions each with lots of parameters of various types so it's a
bit boring to do and very easy to make mistakes. Most people probably
don't have the patience for this.

CamlFloat definitely seems to aim at professional use so I expect that
it may become the library of choice for linear algebra, my library acting
as convenient low-level interface.

> Some of this error-handling like checking that input matrices/vectors have 
> compatible sizes seems tedious (and error-prone), and I think it can be 
> auto-generated from parsing *.f files (including comments) But, yes, maybe 
> it's too hard and not worth the effort.

By relying on as much abstraction as possible, the effort of parameter
checking can be reduced to a reasonable level. Using existing functions as
guideline, it most often shouldn't take longer than an hour to implement
and test new LAPACK-functions. Due to the macro system, this automatically
covers alls four kinds of functions (S/D/C/Z).

> Each thread oviously needs its own workspace. I think this can be done using
> (int * vec ref) list ref            (* int  = id (self ()) *)
> association list (or hash table).  Now, "get", "resize", etc. could check if 
> the thread has its workspace and return it, allocating if necessary.
> I think there is a problem with this approach though: each thread's workspace
> needs to be removed once the thread terminates. OCaml has at_exit but no 
> at_thread_exit that I can find (Maybe it can be defined using 
> Sys.set_signal's ?)

Well, there is always the tension between convenience and simplicity. I
think that features like this should be added in a separate layer.

> > I had indeed thought about this, but that would have made it more
> > inconvenient to people who want to keep accessing "a" directly using
> > the Bigarray-module and the .{}-notation. 
> I think the inconvenience is minimal:
> a.{...}  vs a.mat_data.{...}
> (and it's just typing)

And what about other matrix types like band, tridiagonal, etc.? You'd need
a discriminated union for this, which requires pattern matching.  Again,
I think this should be done on a higher level - e.g. as in CamlFloat.

> But it saves you from the very error-prone and boring task of having to 
> remember which variables designate which dimensions ("Is it m x n or n x k, 
> did I transpose that?"), etc.
> OTOH submatrices/slices probably aren't the most frequently used features,
> so I haven't made up my mind as to which is better.

Exactly. I think that libraries should attempt to optimize for the likely
cases. And a low-level library, which is mainly used by other libraries
again, should IMHO not go overboard with convenience for end users.


Markus Mottl

To unsubscribe, mail Archives:
Bug reports: FAQ:
Beginner's list: