Version française
Home     About     Download     Resources     Contact us    
Browse thread
Announcement: LACAML
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Jan Skibinski <jans@n...>
Subject: Re: Announcement: LACAML

	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