]> 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 > > 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 ? 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. Regards, Markus -- Markus Mottl http://www.oefai.at/~markus markus@oefai.at ------------------- 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