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: 2003-12-14 (23:11)
From: Oleg Trott <oleg_trott@c...>
Subject: Re: [Caml-list] Matrix libraries
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 ?

> Others are working on higher-level ones, e.g.:

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

> I'd also like to see something like that, but I am skeptical that this
> is realistically possible. Writing the C-code for the interface is very
> little work. It's the OCaml-code around it that costs time to write,
> especially error handling.

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.

> > 3.) Regarding "WORK" arguments. Why not have a shared workspace:
> Yes, that's exactly the problem: what about SMP-machines and threading
> then?

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 ?)

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

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.

> > 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.
> This would collide with 4), wouldn't it? Vector arguments in LAPACK
> don't have anything like a "leading dimension" so this wouldn't help you
> unless you allow copying data. 

Just a runtime error if LD does not equal the number of rows would be good.
(If your matrix type includes info about both the number of rows and LD)

Oleg Trott <>

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