caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Markus Mottl <mottl@miss.wu-wien.ac.at>
To: Jan Skibinski <jans@numeric-quest.com>
Cc: OCAML <caml-list@inria.fr>
Subject: Re: Announcement: LACAML
Date: Thu, 25 Jan 2001 17:46:59 +0100	[thread overview]
Message-ID: <20010125174659.A18722@miss.wu-wien.ac.at> (raw)
In-Reply-To: <Pine.LNX.4.21.0101250516001.12230-100000@info.numeric-quest.com>; from jans@numeric-quest.com on Thu, Jan 25, 2001 at 06:20:54 -0500

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



      reply	other threads:[~2001-01-26 21:12 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
2001-01-25 12:58   ` Markus Mottl
2001-01-25 11:20     ` Jan Skibinski
2001-01-25 16:46       ` Markus Mottl [this message]

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=20010125174659.A18722@miss.wu-wien.ac.at \
    --to=mottl@miss.wu-wien.ac.at \
    --cc=caml-list@inria.fr \
    --cc=jans@numeric-quest.com \
    /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).