> From: Aubrey Jaffer <xxxxxx@alum.mit.edu>
>  | 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'?

- not sure, but it seems that the alternative is likely less desirable?

  (as I suspect it's plausible to consider that an exact infinity may be
  simply an exact value who's magnitude exceeds practical representation,
  thereby each representational form supports the designation of a value
  which exceeds the it's practical representational precision. Which is
  likely required as it's improper to return an inexact infinity when
  the dynamic range of an inexact implementation is less than that of
  an exact implementation's maximum representational precision, as in
  the case for example if any value greater than 10^306, for the sake
  of argument, is considered infinite in a given inexact implementation,
  but an exact implementation is capable of representing value with
  up to 1024 digits of precision, as the threshold for an exact infinity
  would then be substantially larger than that for an inexact one. i.e:

  (> #e1/0 #e10^1000 #i10^300) => #t

  as otherwise: (> (* #e10^1000 #e10^1000) #e10^1000)

  :: (> #i1/0 #e10^1000) => #f

  where it should more ideally be:

  :: (> #e1/0 #e10^1000) => #t

>  | (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.

- which seems like the more correct place for it to occur; if the
  concept of an exact infinity was not reasonably acceptable.