[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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.

*To*: sperber@xxxxxxxxxxxxxxxxxxxxxxxxxxx*Subject*: Re: Nitpick with FLOOR etc.*From*: Aubrey Jaffer <agj@xxxxxxxxxxxx>*Date*: Fri, 15 Jul 2005 22:01:25 -0400 (EDT)*Cc*: srfi-70@xxxxxxxxxxxxxxxxx*Delivered-to*: srfi-70@xxxxxxxxxxxxxxxxx*In-reply-to*: <y9lvf3hu90a.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> (message from Michael Sperber on Mon, 11 Jul 2005 08:55:33 +0200)*References*: <y9l8y0j80pz.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxxx> <20050709002445.C8F721B77B4@xxxxxxxxxxxxxxxx> <y9lvf3hu90a.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>

| 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

**Follow-Ups**:**Re: Nitpick with FLOOR etc.***From:*Paul Schlie

**Re: Nitpick with FLOOR etc.***From:*Paul Schlie

**References**:**Nitpick with FLOOR etc.***From:*Michael Sperber

**Re: Nitpick with FLOOR etc.***From:*Aubrey Jaffer

**Re: Nitpick with FLOOR etc.***From:*Michael Sperber

- Prev by Date:
**Re: infinity notations** - Next by Date:
**Re: Nitpick with FLOOR etc.** - Previous by thread:
**Re: Nitpick with FLOOR etc.** - Next by thread:
**Re: Nitpick with FLOOR etc.** - Index(es):