From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id SAA23797; Thu, 13 Nov 2003 18:35:42 +0100 (MET) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f 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 SAA23578 for ; Thu, 13 Nov 2003 18:35:41 +0100 (MET) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id hADHZe125333; Thu, 13 Nov 2003 18:35:40 +0100 (MET) Received: (from xleroy@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id SAA23804; Thu, 13 Nov 2003 18:35:39 +0100 (MET) Date: Thu, 13 Nov 2003 18:35:39 +0100 From: Xavier Leroy To: Christophe Raffalli Cc: caml-list@inria.fr Subject: Re: [Caml-list] Rounding mode + extended Message-ID: <20031113183539.A22904@pauillac.inria.fr> References: <3FAF975F.5070105@univ-savoie.fr> <16305.25815.3793.545198@karryall.dnsalias.org> <3FB25357.5060401@univ-savoie.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <3FB25357.5060401@univ-savoie.fr>; from Christophe.Raffalli@univ-savoie.fr on Wed, Nov 12, 2003 at 04:35:51PM +0100 X-Loop: caml-list@inria.fr X-Spam: no; 0.00; caml-list:01 rounding:01 rounding:01 floats:01 bytecoded:01 api:01 floats:01 -byte:01 non-trivial:01 unboxed:01 printf:01 32,:01 nativeint:01 bigarrays:01 32,:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk > At this address, you will find a very small library for changing the > rounding mode from OCaml (works on 6 processors, but only tested on i486) A general comment on the rounding mode issue and your question about extended-precision floats. While I agree it would be nice to have full IEEE 754 support in OCaml, one has to keep in mind that the OCaml standard libraries are severely constrained by the general requirement that the bytecoded part should work on any "reasonable" platform, where "reasonable" is currently defined as "ANSI C plus Unix 98". Unfortunately, this combination of standards has very little to offer in terms of advanced features of IEEE float arithmetic. In particular, there's no standardized API for controlling rounding modes. ISO C9X does provide functions (fegetround, fesetround) to control rounding modes, and it might be a good idea to use them in your library when available. The problem is that very few platforms implement these functions, let alone full ISO C9X. For instance, glibc is the only C library that I know of that provides fe[gs]etround. So, between standards that few implement and processor-specific asm statements like you did, there is very little hope of achieving portability. > Is it possible to use "extended" instead of "double" in OCaml for float > (I am ready to recompile OCaml for this) You mean "long double"? :-) (That's the ISO C9X name for extended-precision floats.) The core bytecode system might keep working if you do this change, except output_value/input_value on floats, which require 8-byte floats. As for the native-code compiler, that would require non-trivial changes throughout. > What was the reason to have only one type of "float" ? Three types of > float (float, double and extended) do not explode the complexity of the > optimization for float array or float in record (I think). If you want all three array types (float array, double array, extended array) to be unboxed, it will certainly explode that complexity, turning (in the polymorphic case) a 2-way branch into a 4-way branch. > Ok, you should have three additions +. +.. and +... :-( And much more, notably conversions between the various float types, conversions to/from integers, to/from strings, printf formats, and so on. Just look at the Int32, Int64 and Nativeint modules for an idea of the combinatorics involved. > Is this the only reason ? No, there are two others. The first is that single-precision floats (32 bits) are nearly useless, since modern processors compute just as fast over double-precision floats. The only case where you'd want to use single-precision floats is as a storage type, to halve the size of large arrays of numbers, but that's an option supported by bigarrays. The second is that extended-precision floats are not fully specified (these can use 80, 96 or 128 bits if I remember correctly), and few processors implement them efficiently in hardware: IA32, perhaps IA64, maybe some IBM 360 series processors. Even on IA32, the trend is to use SSE2 for floating-point computation, which don't support 80-bit floats. So, again, if you program for the common denominator, you'd use 64-bit floats and nothing else. - Xavier Leroy ------------------- 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