From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id LAA22083; Mon, 15 Dec 2003 11:01:30 +0100 (MET) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id LAA22035 for ; Mon, 15 Dec 2003 11:01:29 +0100 (MET) Received: from fichte.ai.univie.ac.at (fichte.ai.univie.ac.at [131.130.174.156]) by nez-perce.inria.fr (8.11.1/8.11.1) with ESMTP id hBFA1S122579 for ; Mon, 15 Dec 2003 11:01:28 +0100 (MET) Received: from fichte.ai.univie.ac.at (markus@localhost [127.0.0.1]) by fichte.ai.univie.ac.at (8.12.3/8.12.3/Debian-6.6) with ESMTP id hBFA1OHn018198; Mon, 15 Dec 2003 11:01:24 +0100 Received: (from markus@localhost) by fichte.ai.univie.ac.at (8.12.3/8.12.3/Debian-6.6) id hBFA1NpI018196; Mon, 15 Dec 2003 11:01:23 +0100 Date: Mon, 15 Dec 2003 11:01:23 +0100 From: Markus Mottl To: Oleg Trott Cc: OCaml Subject: Re: [Caml-list] Matrix libraries Message-ID: <20031215100123.GB14959@fichte.ai.univie.ac.at> Mail-Followup-To: Oleg Trott , OCaml References: <20031213135142.GA8519@gentoo.malaquias.no-ip.org> <200312131638.01256.oleg_trott@columbia.edu> <20031214150152.GB4945@fichte.ai.univie.ac.at> <200312141810.58462.oleg_trott@columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200312141810.58462.oleg_trott@columbia.edu> User-Agent: Mutt/1.4.1i X-Loop: caml-list@inria.fr X-Spam: no; 0.00; caml-list:01 oleg:01 lacaml:01 low-level:01 blas:01 lapack:01 passing:01 lapack:01 interfacing:01 blas:01 low-level:01 vectors:01 error-prone:01 abstraction:01 hash:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk 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