From: "S. Loisel" <loisel@math.mcgill.ca>
To: caml-list@inria.fr
Subject: [Caml-list] Generics & a working mathematician's testimonial
Date: Mon, 02 Jun 2003 23:50:57 -0400 [thread overview]
Message-ID: <3EDC1B21.8020403@math.mcgill.ca> (raw)
Dear Bedouins,
Recently, there have been encouraging rumours[1] to the effect that
"extensional polymorphism" would get more love. I am writing this to
share with you my enthusiasm regarding this kind of polymorphism.
My current work is in scientific computing (solving PDE's and that kind
of stuff) and, in a previous life, I worked in pure math in analysis,
with computer proofs. As has been hinted by others[2,4,5,6], many in the
scientific computing community (including adjacent disciplines such as
weather simulation and such) are moving to C++ (while still using
primarily Fortran) with a large contingent of people content to use Matlab.
For this community, it is very important to be able to write complicated
mathematical expressions in a simple, legible fashion. It is also
relatively important to be able to control the underlying number
representations. Most applications use 64-bit floating point numbers,
but some use 96 bits, and a small number of application are content to
use 32 bit floating point. In addition, some applications need to use
real numbers, and other applications need to use complex numbers, and a
few applications need to use stranger scalar types. Some applications
require interval arithmetic, while most people wouldn't be willing to
carry that overhead. The cartesian product of all these is large.
The most important application is, of course, in linear algebra, where
it is important to be able to manipulate vectors, matrices, and, in some
cases, higher-order tensors with some elegance.
Fortran is clearly the incumbant, and in a way it does everything less
well than the languages which are vying against it in the modern
numerical laboratory. At the moment, Matlab, with its extremely large
library of "toolboxes" and very efficient algorithms, is widely
considered to be the tool that is easiest to use, and at the same time
able to produce results that are important in the real world. Of course,
from a language theorist's perspective, the Matlab language is brain
damaged, in addition to its interpreter being hopelessly slow.
The appeal of C++ is obvious. To most of us, the polymorphism available
in C++ is far greater than what is available in all other alternatives.
And while it is not possible to define new operators, the overloading
capabilities combined with the ample variety of existing operators to
pick from make this language a self-evident choice when we wish to write
mathematical expressions and programs in a clear way.
I for one believe it is easier to write erroneous C++ code, compared to
(say) g'caml. The primary culprit is C++'s lack of garbage collection,
but sometimes I think that C++'s somewhat lax automatic type conversion
plays a complicit role.
Many of my predecessors of the eighties held high hopes for Lisp, but us
younguns prefer to be able to write mathematical expressions with infix
operators, thank you very much. I also think that "overloading" wouldn't
work very well in a dynamically typed language. Lastly, most of us
aren't willing to pay for language features in performance, and dynamic
typing can exact a toll (unless you go back and add typing hints with
your profiler...)
In summary, to the community that I am most familiar with, genericity is
a showstopper. A language such as g'caml would be welcome (at least by
myself) with open arms as the promised saviour. However, it is with
great sadness that I had to abandon previous work with ocaml, because
all my operators were three characters long and the expressions had
stopped making sense. There are issues, aside from genericity, which are
suboptimal for my community[3], but in the interest of staying
focused, I will not discuss them.
I would invite relevant individuals to comment on their idea of what's
in the future for such features, and I would like to thanks Jun Furuse
for the very useful prototype that is g'caml.
Sincerely yours,
Sébastien Loisel
Notes:
[1] http://caml.inria.fr/archives/200305/msg00059.html
[2] e.g., http://caml.inria.fr/archives/200305/msg00205.html
[3] I know a lot of people who use SMP and NUMA, unlike what Xavier
Leroy suggests here: http://caml.inria.fr/archives/200211/msg00274.html
[4] http://osl.iu.edu/~tveldhui/papers/DrDobbs2/drdobbs2.html
[5]
http://www.codesourcery.com/pooma/pooma_publications/how_templates_enable_high_performance_scientific_computing_in_cplusplus
This link should have no spaces. If some mail agent breaks up the
line, you might have to rearrange it manually.
[6] I personally use mainly C++, and so does S. W. Drury (my advisor for
the master's thesis, http://www.math.mcgill.ca/drury/.)
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
reply other threads:[~2003-06-03 3:51 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=3EDC1B21.8020403@math.mcgill.ca \
--to=loisel@math.mcgill.ca \
--cc=caml-list@inria.fr \
/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