Announcement: LACAML

Announcement: LACAML

[Markus Mottl]

Hello,

as recently proposed, there should be some interface to the BLAS and
LAPACK-libraries for efficiently doing linear algebra with bigarrays.
I have just put my first attempt ("lacaml") online: it only implements
a couple of functions that I wanted to try out, but I have tried to
design this interface as cleanly as possible. Installation should be
simple enough, too.

Adding further functionality to this library by following the
implementation of the other functions is not difficult either (thanks
to the bigarrays), but it still requires some work, because the
FORTRAN-function interfaces are usually very fat: they often take more
than 10 arguments. This means writing a lot of error checking code if
one wants to handle all errors in OCaml - the default error handling
of these libraries is probably not advisable, because it aborts program
execution...

Here is a part of the README explaining some features:

---------------------------------------------------------------------------
  * The BLAS- and LAPACK-libraries have evolved over about two decades
    of time and are therefore extremely mature both in terms of stability
    and efficiency.

  * The OCaml-interface was designed in a way to combine both the
    possibility of gaining optimum efficiency (e.g. by allowing the
    creation of work arrays outside of loops) with simplicity (thanks
    to labels and default arguments).

  * The code is precision-independent (precision of floats). There are
    two modules that implement exactly the same interface modulo the
    precision type. If you refer to elements in this interface only,
    your code becomes precision-independent, too: you can choose at
    anytime whether you want to use single-precision or double-precision
    simply by "open"ing the required module.

  * You can fully exploit the library within multithreaded programs: most
    numerical routines are likely to run for a long time, but they will
    never block other threads. This also means that you can execute
    several routines at the same time on several processors if you use
    native threads.

  * To make things easy for people used to the "real" implementation
    in FORTRAN but also for beginners who need detailed documentation,
    both function- and argument names have been kept compatible to the
    ones used in the BLAS- and LAPACK-documentation. Only exception: you
    need not prefix functions with "s" or "d" to indicate the precision
    of floats, because OCaml gives us more powerful means to choose it.
---------------------------------------------------------------------------

I have already registered the project at SourceForge so that other people
can contribute functions they need (I will only implement ones that are
directly relevant to my work, but I will help if there are problems):

  http://sourceforge.net/projects/lacaml

Just tell me if you want to join!

Unfortunately, there are currently some technical problems with CVS at
SourceForge, which didn't allow me to check in my sources yet. In the
meanwhile you can get them from here:

  http://miss.wu-wien.ac.at/~mottl/ocaml_sources

Best regards,
Markus Mottl

-- 
Markus Mottl, mottl@miss.wu-wien.ac.at, http://miss.wu-wien.ac.at/~mottl

Re: Announcement: LACAML

[Jan Skibinski]

	Markus,

> Adding further functionality to this library by following the
> implementation of the other functions is not difficult either (thanks
> to the bigarrays), but it still requires some work, because the
> FORTRAN-function interfaces are usually very fat: they often take more
> than 10 arguments. This means writing a lot of error checking code if
> one wants to handle all errors in OCaml - the default error handling
> of these libraries is probably not advisable, because it aborts program
> execution...

	When writing Eiffel interface (*) to C version of NAG library
	(similar to LAPACK, including BLAS, but commercial), several
	years ago, we had two basic problems to solve:
 	1. argument obesity (a Fortran legacy), as you mentioned it above
	2. pointers to functions as arguments to other functions

	The first was easy to handle in the object oriented language:
	create an object with some defaults and provide auxiliary
	methods to change those defaults if needed. Another words,
	break those long chains of arguments into shorter pieces.
	It worked very well, but obviously required a lot of
	(exciting) engineering.
	But the result was stunningly clear, consise and easy to
	understand even by the beginners. 
	I do not know whether similar approach would be feasible with
	Ocaml objects, but if yes then I would recommend it highly.
 
	The second problem was awkward to tackle in Eiffel, but
	this is where Ocaml will shine with its higher order
	functions.


>   * To make things easy for people used to the "real" implementation
>     in FORTRAN but also for beginners who need detailed documentation,
>     both function- and argument names have been kept compatible to the
>     ones used in the BLAS- and LAPACK-documentation. 

	I do not see a need for this. The names are probably as awkward
	as in NAG. Just consistently refer to the original names in your
	documentation and you should be fine.

	Jan

	(*) This was EiffelMath for ISE Eiffel.
	ISE = Interactive Software Engineering, Santa Barbara, California

Re: Announcement: LACAML

[Markus Mottl]

On Thu, 25 Jan 2001, Jan Skibinski wrote:
> 	But the result was stunningly clear, consise and easy to
> 	understand even by the beginners. 
> 	I do not know whether similar approach would be feasible with
> 	Ocaml objects, but if yes then I would recommend it highly.

I think that default arguments in OCaml are a very fine means to hide the
complexity of function interfaces without sacrificing richness of features
and efficiency. Using objects would also be a solution, but having to call
methods of objects to parameterize them does not seem so natural to me.

Some time ago, when there was a flame war on this list whether labels are
really of any use, I tried several ways of parameterisation (objects,
option lists, default arguments), and I found that default arguments
were both the most elegant and the most efficient solution. Furthermore,
I am somewhat reluctant what concerns using objects, but that's another
story...

> >   * To make things easy for people used to the "real" implementation
> >     in FORTRAN but also for beginners who need detailed documentation,
> >     both function- and argument names have been kept compatible to the
> >     ones used in the BLAS- and LAPACK-documentation. 
> 
> 	I do not see a need for this. The names are probably as awkward
> 	as in NAG. Just consistently refer to the original names in your
> 	documentation and you should be fine.

Funny as it may seem, I find awkward names easier to remember. If names
become too similar, which may happen when there are so many functions
for similar problems, one can easily mix them up. Humans don't seem to
have problems memorizing thousands of foreign words so using "awkward"
names for functions is probably less confusing than requiring people
to lookup different identifiers in documentation. (Btw., there is some
logic behind the naming of BLAS- and LAPACK-functions).

- Markus Mottl

-- 
Markus Mottl, mottl@miss.wu-wien.ac.at, http://miss.wu-wien.ac.at/~mottl

Re: Announcement: LACAML

[Jan Skibinski]

	Markus,

	Some final comments...

> > 	I do not know whether similar approach would be feasible with
> > 	Ocaml objects, but if yes then I would recommend it highly.
> 
> I think that default arguments in OCaml are a very fine means to hide the
> complexity of function interfaces without sacrificing richness of features
> and efficiency. 

	I do not follow ocaml closely enough to appreciate supposed
	elegancy and efficiency of default arguments. If by this you
	mean that you can shorten the list of arguments when user wants
	to use defaults, but he still needs to supply all of them
	otherwise then this sounds as half a solution to me.

	By going this route you will present the user with exactly the
	same complexity as the original Fortran specification.
	
	To respond to your other objections I point you to a short
	introduction:
	http://www.eiffel.com/doc/eiffelworld/5.1/new_release.html

	Please do not take it lightly: LANPACK is a complex piece of
	software and there is no reason why your library would follow
	suit all those complexities and other quirks.

	Jan

Re: Announcement: LACAML

[Markus Mottl]

On Thu, 25 Jan 2001, Jan Skibinski wrote:
> 	I do not follow ocaml closely enough to appreciate supposed
> 	elegancy and efficiency of default arguments. If by this you
> 	mean that you can shorten the list of arguments when user wants
> 	to use defaults, but he still needs to supply all of them
> 	otherwise then this sounds as half a solution to me.

I don't understand what you mean by "still needs to supply all of them".

E.g. if you want to solve a linear regression problem with the
"gels"-function, the minimum you may want to write is:

  gels data_matrix result_matrix

If you want to specify more, you could do the following:

  gels data_matrix ~m:42 ~trans:true result_matrix

This would only make use of the first 42 rows and interpret "data_matrix"
as a transposed matrix.

> 	To respond to your other objections I point you to a short
> 	introduction:
> 	http://www.eiffel.com/doc/eiffelworld/5.1/new_release.html

Maybe the misunderstanding is that my interface is intended as a
high-level one, since it supports default arguments. This is not the
case: it should be as close as reasonable to the FORTRAN interface
(but should not impose too much complexity).

If you want to make use of more abstraction (e.g. to have interfaces
for various "solvers", whatever), it might be a good idea to add further
modules (functors) and specify high-level interfaces. I think that most
people would agree that modules and algebraic datatypes are a more natural
way to encode operations on (linear) algebras than objects.  Christophe
Raffalli's work on the FORMEL-library goes into such a direction.

> 	Please do not take it lightly: LANPACK is a complex piece of
> 	software and there is no reason why your library would follow
> 	suit all those complexities and other quirks.

No doubt about this: LAPACK is a huge beast. I only needed a couple of
functions, but I thought that implementing their interface as well as
possible would make it easier for other people (with more experience in
numerical algorithms) to add or change code.

Regards,
Markus Mottl

-- 
Markus Mottl, mottl@miss.wu-wien.ac.at, http://miss.wu-wien.ac.at/~mottl