This page is part of the web mail archives of SRFI 70 from before July 7th, 2015. The new archives for SRFI 70 contain all messages, not just those from before July 7th, 2015.
> | 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] ?