Re: [Caml-list] Rounding mode + extended

[Xavier Leroy <xavier.leroy@inria.fr>]

> 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