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 AAA00097; Mon, 15 Dec 2003 00:11:05 +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 AAA00154 for ; Mon, 15 Dec 2003 00:11:04 +0100 (MET) Received: from jalapeno.cc.columbia.edu (jalapeno.cc.columbia.edu [128.59.59.238]) by nez-perce.inria.fr (8.11.1/8.11.1) with ESMTP id hBENB3128240 for ; Mon, 15 Dec 2003 00:11:03 +0100 (MET) Received: from tw304h3.cpmc.columbia.edu (tw304h3.cpmc.columbia.edu [156.111.84.180]) (user=ot14 mech=LOGIN bits=0) by jalapeno.cc.columbia.edu (8.12.10/8.12.10) with ESMTP id hBENB0di025765 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sun, 14 Dec 2003 18:11:02 -0500 (EST) From: Oleg Trott To: Markus Mottl Subject: Re: [Caml-list] Matrix libraries Date: Sun, 14 Dec 2003 18:10:58 -0500 User-Agent: KMail/1.5.4 Cc: OCaml References: <20031213135142.GA8519@gentoo.malaquias.no-ip.org> <200312131638.01256.oleg_trott@columbia.edu> <20031214150152.GB4945@fichte.ai.univie.ac.at> In-Reply-To: <20031214150152.GB4945@fichte.ai.univie.ac.at> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200312141810.58462.oleg_trott@columbia.edu> X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.35 X-Loop: caml-list@inria.fr X-Spam: no; 0.00; oleg:01 oleg:01 caml-list:01 lacaml:01 low-level:01 blas:01 lapack:01 higher-level:01 c-code:01 ocaml-code:01 vectors:01 error-prone:01 threading:01 hash:01 resize:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk 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 ------------------- 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