From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id OAA07273 for caml-red; Sat, 14 Oct 2000 14:35:59 +0200 (MET DST) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id AAA03449 for ; Sat, 14 Oct 2000 00:17:50 +0200 (MET DST) Received: from hebe.or.intel.com (hebe.or.intel.com [134.134.248.4]) by concorde.inria.fr (8.10.0/8.10.0) with ESMTP id e9DMHnD24768 for ; Sat, 14 Oct 2000 00:17:49 +0200 (MET DST) Received: from ichips-ra.pdx.intel.com (ichips-ra-hme3.intel.com [10.7.7.35]) by hebe.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.32 2000/10/12 22:57:04 dmccart Exp $) with ESMTP id PAA19608 for ; Fri, 13 Oct 2000 15:30:02 -0700 (PDT) Received: from dhpc0010.pdx.intel.com (dhpc0010.pdx.intel.com [10.7.21.33]) by ichips-ra.pdx.intel.com (8.9.1a/8.9.1/d: internal.m4,v 1.2 1998/11/09 19:18:37 iwep Exp iwep $) with ESMTP id PAA04897; Fri, 13 Oct 2000 15:17:42 -0700 (PDT) Received: from ichips.intel.com (johnh@localhost [127.0.0.1]) by dhpc0010.pdx.intel.com (8.9.1a/8.9.1/d: client-ra.m4,v 1.1 1998/12/24 19:00:55 jamesw Exp jamesw $) with ESMTP id PAA04645; Fri, 13 Oct 2000 15:17:42 -0700 (PDT) Message-Id: <200010132217.PAA04645@dhpc0010.pdx.intel.com> To: caml-list@inria.fr cc: John Harrison Subject: Re: OCaml and C math routines Date: Fri, 13 Oct 2000 15:17:40 -0700 From: John R Harrison Sender: weis@pauillac.inria.fr David McClain writes: | OCaml'ers... I would be very interested to hear your response to this! I guess I should comment, since I work closely with the people designing math functions for various Intel architectures, and have even written a few myself. | Members of the SML basis committee and the Ocaml group probably can | tell us the pros and cons of calling the native math library vs. having | it written in ML itself. There are (at least) three things to consider in writing a good math library function: * accuracy * speed * proper handling of exceptional cases Getting good speed and accuracy together (or sometimes just one of them at at a time) is often non-trivial. And even given a good basic design for the core function, it's a serious amount of work to make all the peculiar corner cases work sensibly, e.g. detecting overflow and underflow correctly, behaving sensibly when unusual exceptions like "inexact" are enabled, or even providing accurate answers when the rounding mode is not the default of round-to-nearest or when trigonometric functions are applied to huge arguments. Besides, there's room for disagreement over what *should* be done in many of the obscure cases. There's no IEEE standard for the transcendentals, though C99 is establishing some sort of norm. In the absence of absolute standards, there are hard trade-offs to be made between various desirable characteristics. So, on the one hand, it's ambitious bordering on hubristic for SML experts who are not floating point specialists to reimplement all this stuff themselves. On the other hand, it's certainly true that most available math libraries have shortcomings in some area or another, so if the SML people are able and determined enough, it would be possible in principle for them to do better. For an idea of some of the techniques we've used at Intel in recent math library work, you might look at the following: "The Computation of Transcendental Functions on the IA-64 Architecture" http://developer.intel.com/technology/itj/q41999/articles/art_5.htm "New Algorithms for Improved Transcendental Functions on IA-64" http://euler.ecs.umass.edu/paper/final/paper-118.ps The original question seemed particularly focused on speed. In my experience the really critical math functions tend to be coded in assembler, simply because C compilers don't usually provide adequate control or provide intrinsics to access special hardware features. For less popular functions (like the cube root and Bessel functions), it's common to use some portable C routines such as those in FDLIBM: http://www.netlib.org/fdlibm There's certainly a case for having a similar library in ML, but the case for using it as the default for important functions is more questionable. Cheers, John.