caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Jan Skibinski <jans@numeric-quest.com>
To: Markus Mottl <mottl@miss.wu-wien.ac.at>
Cc: OCAML <caml-list@inria.fr>
Subject: Re: Announcement: LACAML
Date: Thu, 25 Jan 2001 02:21:47 -0500 (EST)	[thread overview]
Message-ID: <Pine.LNX.4.21.0101250144290.9468-100000@info.numeric-quest.com> (raw)
In-Reply-To: <20010125011143.A11727@miss.wu-wien.ac.at>


	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




  reply	other threads:[~2001-01-26 21:04 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-01-25  0:11 Markus Mottl
2001-01-25  7:21 ` Jan Skibinski [this message]
2001-01-25 12:58   ` Markus Mottl
2001-01-25 11:20     ` Jan Skibinski
2001-01-25 16:46       ` Markus Mottl

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.LNX.4.21.0101250144290.9468-100000@info.numeric-quest.com \
    --to=jans@numeric-quest.com \
    --cc=caml-list@inria.fr \
    --cc=mottl@miss.wu-wien.ac.at \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).