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