Questions about IEEE arithmetic for Scheme Standards

[Peter McGoron]

[Below is the email I sent to Brad Lucier. I sent this from another
email because my usual email gets blocked by .edu domains sometimes.]

___________________________________________________________________

Hello,

The working group has recently been discussing tightening requirements
for inexact arithmetic on IEEE-754 format values for the next draft of
the R7RS-Large. Your input on the matter would be greatly appreciated.

We have come up with the idea of type specific libraries, where, for
example, (scheme flonum binary64) would export monomorphic procedures
that operate on and return binary64 formatted values (if the
implementation supports it). Specifying that (scheme flonum binary32),
(scheme flonum binary64), etc. operate on IEEE-754 format values raises
the question of whether or not we should require stricter conformance to
IEEE-754 arithmetic, such as

1. Rounding modes (if we should mandate a default rounding mode, or
mandate the ability to switch to one of the standard's rounding modes)
2. Floating point exceptions (if we mandate that implementations must
keep on going even if exceptions occur, or if we mandate the ability to
have those exceptions visible)
3. The existence of denormals, which may not be available or may be slow
on some platforms. Similarly, if we have a standard switch for DAZ/FTZ
mode).

What are your thoughts on stricter requirements for IEEE arithmetic?

Thank you for your time,

-- Peter McGoron

[Peter McGoron]

[Below is Bradley Lucier's response, which seems to have not gotten to
the mailing list.]

__________________________________________________________

Dear Peter:

Thank you for your note.

I have not studied the IEEE floating-point standards in detail in some
time, so my comments will be of a more general nature.

I think the committee should consider what type of programs one hopes to
write with R7RS Large. I’m not an expert on the MPFR library, for
example, but I think it requires:

1. Setting and reading status flags.

2. Setting and reading rounding modes.

3. Specifying the precision of arguments and results.

So my recommendation would be to specify Scheme floating-point libraries
that are more-or-less equivalent to an FFI for the required operations
in the standard; separate them into different precisions and bases if
convenient.

There have been several IEEE floating-point standards, and I suspect
that there will be more, so I’d recommend making the year the standard
was promulgated an optional part of the library name.

Some more general comments follow.

The IEEE numeric standards have always been about systems, recognizing
that compliance required cooperation between hardware and software, in
the form of libraries and compilers and in some cases microcode (dealing
with subnormals on some Alpha processors, for example). This can make
things tricky if one does not control the entire computational “stack”.

I’ll give two examples from the Gambit runtime.

Gambit computes the integer square root of nonnegative fixnums by:

1. Convert the fixnum to a double precision flonum. This can incur a
rounding error.

2. Compute the flonum square root.

3. Truncate the flonum to a fixnum.

4. Correct the result if it’s too big by 1.

I checked that this works no matter the rounding mode, so if someone
happens to set the rounding mode to something other than
round-to-nearest, we’re OK.

The second example is that Gambit uses a complex double-precision FFT to
compute the product of (very large) bignums.

The theorems that prove the algorithm works (which are not mine, by the
way) absolutely require round-to-nearest and (if I remember correctly)
they don’t consider the possibility of fused multiply add (fma) operations.

Gambit compiles Scheme to C, and the C compiler may choose to insert fma
operations in places (one can disable this, but generally one doesn’t
want to for performance reasons), so one must think about whether that
might invalidate the theorems.

It turns out that using fma operations does not invalidate the theorems.

So for this algorithm one ideally would like to read and temporarily
reset, if necessary, the rounding mode.

I hope this helps and I’m willing to discuss this more if necessary.

Brad

[Peter McGoron]

[Here is a follow up email from Bradley Lucier.]

_________________________________________

> I think the committee should consider what type of programs one hopes
to write with R7RS Large. I’m not an expert on the MPFR library, for
example, but I think it requires:

It was the recent work to get correctly rounded elementary functions
into glibm that I was thinking of.

> Gambit compiles Scheme to C, and the C compiler may choose to insert
fma operations in places (one can disable this, but generally one
doesn’t want to for performance reasons), so one must think about
whether that might invalidate the theorems.

Perhaps I should clarify that while an fma operation usually runs faster
than a sequence of one multiply and one add, it is the fact that fma
incurs only one rounding is, for algorithmic purposes, its most
important property, and one that must be maintained.