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> | Date: Mon, 11 Jul 2005 08:55:33 +0200 | | Aubrey Jaffer <agj@xxxxxxxxxxxx> writes: | | > | From: Michael Sperber <sperber@xxxxxxxxxxxxxxxxxxxxxxxxxxx> | > | 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