Peter McGoron
unread,Jun 16, 2026, 3:26:27 PM (17 hours ago) Jun 16Sign in to reply to author
Sign in to forward
You do not have permission to delete messages in this group
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
to scheme-re...@googlegroups.com
[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