| From: Michael Sperber <xxxxxx@informatik.uni-tuebingen.de>
 | Date: Mon, 11 Jul 2005 08:55:33 +0200
 |
 | Aubrey Jaffer <xxxxxx@alum.mit.edu> writes:
 |
 | >  | From: Michael Sperber <xxxxxx@informatik.uni-tuebingen.de>
 | >  | Date: Thu, 07 Jul 2005 10:44:08 +0200
 | >  |
 | >  | The definition of FLOOR, like R5RS, starts out with:
 | >  |
 | >  | "These procedures return integers."
 | >  |
 | >  | Then it goes on to say:
 | >  |
 | >  | (floor 1/0) => 1/0
 | >  |
 | >  | which is not an integer by the current draft.
 | >
 | > Good catch!  I have removed those two examples.
 |
 | 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