| Date: Sat, 16 Jul 2005 05:12:13 -0400
 | From: Paul Schlie <xxxxxx@comcast.net>
 |
 | > From: Aubrey Jaffer <xxxxxx@alum.mit.edu>
 | > procedure        #i-/0            #i+/0
 | > =========        =====            =====
 | >
 | > floor            error           179.76931348623157e306
 | >
 | > ceiling  -179.76931348623157e306  error
 | >
 | > truncate -179.76931348623157e306 179.76931348623157e306
 | >
 | > round    -179.76931348623157e306 179.76931348623157e306
 |
 | - it's not clear this is necessarily desirable?
 |
 | As upon further thought it seems most reasonable that infinities
 | return infinities, or optionally throw an exception, for all such
 | scenarios to be most consistent?

If infinities are the only non-integers allowed to be returned from
these functions, should infinities be the only inexacts allowed to be
returned from `INEXACT->EXACT'?

 | (As otherwise the marginal error resulting from the conversion may
 | be infinite itself which seems inconsistent with the expectations
 | of the conversion.)

I grepped through SLIB and several Scheme applications' source for
occurrences of ROUND, CEILING, FLOOR, and TRUNCATE.  In essentially
all 30+ cases INEXACT->EXACT was called with the results of these
functions.  So having ROUND, CEILING, FLOOR, and TRUNCATE return
infinities will only slightly delay the exception.