>  | From: Michael Sperber <xxxxxx@informatik.uni-tuebingen.de>
>  | Huh.  I was kind of expecting you to remove the "integers" sentence. :-)
>
> That is also a reasonable approach.
>
>  | What are the return values for infinities supposed to be?
>
> From a mathematical point of view, it seems like a slippery slope.
> Often, the result of ROUND, CEILING, FLOOR, or TRUNCATE is passed to
> INEXACT->EXACT.  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'?
>
>  | Are these procedures allowed to signal an error in those cases?
>
> As SRFI-70 is now I believe the answer can be yes; because infinities
> are non-integers and there is no closest integer.  But if an
> implementation lacks inexact bignums, then there is a closest integer,
> namely the largest magnitude inexacts!
>
> If the stipulation that inexacts args produce inexacts results takes
> priority over finding the closest integer, then only inexact integers
> are eligible.  For an implementation having IEEE-754 64.bit flonum
> inexacts:
>
> procedure  #i-/0   #i+/0
> =========  =====   =====
>
> floor   error  179.76931348623157e306
>
> ceiling  -179.76931348623157e306  error
>
> truncate -179.76931348623157e306 179.76931348623157e306
>
> round  -179.76931348623157e306 179.76931348623157e306

- are you proposing that a run-time error must be signaled; or more
  reasonably only that it may, and/or alternatively return -1/0 +1/0 ?
  [which I tend to view as being equivalent to #i-/0, #i+/0]

  - what about -0/1, +0/1 ?

  - should (= (floor x) (/ (ceiling (/ x))) [or reasonable approximation] ?