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