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: Markus Mottl <mottl@m...>
Subject: Re: Announcement: LACAML
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