[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Nitpick with FLOOR etc.
> | 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
> 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] ?