Re: Nitpick with FLOOR etc.

[Paul Schlie <schlie@xxxxxxxxxxx>]

>  | From: Michael Sperber <sperber@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
>  | 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] ?