Re: [Caml-list] Matrix libraries

[Shivkumar Chandrasekaran <shiv@ece.ucsb.edu>]

On Dec 13, 2003, at 1:38 PM, Oleg Trott wrote:

>
> 3.) Regarding "WORK" arguments. Why not have a shared workspace:
>
> (* module Workspace, untested *)

I was thinking of using weak arrays for this, so that a one-time use of 
a large workspace does not consume memory for too long.

>
> (* private *)
> let workspace = ref (Array1.create float64 100)
>
> (* public *)
> let size () = Array1.dim !workspace
>
> let resize n = workspace := Array1.create float64 n
>
> let delete () = resize 0
>
> let get_float64 n = if size () >= n then !workspace
>                                                 else (resize n; 
> !workspace)
>
> This way, one does not need to "hoist" workspace allocation out of 
> loops
> manually. OTOH performance does not suffer from allocating workspace
> for each function call. I don't know how this would inter-operate with
> threading or SMP though.

Since the "naive" way of doing multiple OCaml-threads does not imply 
that multiple processors will be used (see old posts on this subject), 
I was hoping to write yet another interface to Lapack+Blas where each 
fortran call would run in its own C thread. That way the user can 
precisely control the threading. Anybody has any advice on this matter?

Apparently ATLAS BLAS already can exploit SMP, but it does not seem to 
matter for small matrix sizes, which is my case. I just happen to have 
lots of them!


>
> 4) Submatrices. For a function f that takes a matrix argument "a" of 
> size m by
> n, you normally use something like
>
> f ar ac a m n
>
> where ar and ac refer to the "beginning" of the submatrix. Even though 
> they
> can default to 1, this is kind of inconvenient compared to
>
> f a
>
> I would propose using the latter everywhere, and letting the "mat" type
> include ar, ac, m and n.
>
> submatrix : int -> int -> int -> int -> mat -> mat
> (* submatrix x1 y1 x2 y2 a *)
>
> would provide "views" into matrix a.

See my previous "pre-announcement" for CamlFloat. It provides such a 
mechanism, and tracks all the nasty details of unit diagonal 
lower-triangular matrices, etc., etc., for you. That is, all the usual 
things that make most non-trivial Lapack programs buggy.

>
> 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.
>
> 6) License. Have you thought of adding a static linking exception to 
> your LGPL
> license? Even INRIA did with Caml standard library. I might even 
> consider
> contributing then :-)
>
> -- 
> 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

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