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
next prev parent 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