On Sunday 14 December 2003 10:01 am, Markus Mottl wrote:
> In any case, LACAML is supposed to stay a low-level interface to
> BLAS/LAPACK. 

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.:
>
>   http://www.math.ucsb.edu/~lyons/camlFloat/index.html

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