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

*To*: schlie@xxxxxxxxxxx*Subject*: Re: Nitpick with FLOOR etc.*From*: Aubrey Jaffer <agj@xxxxxxxxxxxx>*Date*: Sun, 17 Jul 2005 18:43:49 -0400 (EDT)*Cc*: sperber@xxxxxxxxxxxxxxxxxxxxxxxxxxx, srfi-70@xxxxxxxxxxxxxxxxx*Delivered-to*: srfi-70@xxxxxxxxxxxxxxxxx*In-reply-to*: <BF000C4E.ADAB%schlie@xxxxxxxxxxx> (message from Paul Schlie on Sun, 17 Jul 2005 13:23:26 -0400)*References*: <BF000C4E.ADAB%schlie@xxxxxxxxxxx>

| Date: Sun, 17 Jul 2005 13:23:26 -0400 | From: Paul Schlie <schlie@xxxxxxxxxxx> | | > From: Aubrey Jaffer <agj@xxxxxxxxxxxx> | > | Date: Sat, 16 Jul 2005 05:12:13 -0400 | > | From: Paul Schlie <schlie@xxxxxxxxxxx> | > | > ... | > 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'? | | - not sure, but it seems that the alternative is likely less desirable? | | (as I suspect it's plausible to consider that an exact infinity may be | simply an exact value who's magnitude exceeds practical representation, | thereby each representational form supports the designation of a value | which exceeds the it's practical representational precision. Which is | likely required as it's improper to return an inexact infinity when | the dynamic range of an inexact implementation is less than that of | an exact implementation's maximum representational precision, as in | the case for example if any value greater than 10^306, for the sake | of argument, is considered infinite in a given inexact implementation, | but an exact implementation is capable of representing value with | up to 1024 digits of precision, as the threshold for an exact infinity | would then be substantially larger than that for an inexact one. i.e: Exact infinities are not needed for SRFI-70. | (> #e1/0 #e10^1000 #i10^300) => #t | | as otherwise: (> (* #e10^1000 #e10^1000) #e10^1000) | | :: (> #i1/0 #e10^1000) => #f That conflicts with SRFI-70, which specifies that #i+1/0 compares as larger than any finite real number, exact or inexact: For any finite real number x: (< #i-1/0 x #i+1/0)) ==> #t (> #i+1/0 x #i-1/0)) ==> #t | where it should more ideally be: | | :: (> #e1/0 #e10^1000) => #t | | > | (As otherwise the marginal error resulting from the conversion may | > | be infinite itself which seems inconsistent with the expectations | > | of the conversion.) | > | > I grepped through SLIB and several Scheme applications' source for | > occurrences of ROUND, CEILING, FLOOR, and TRUNCATE. In essentially | > all 30+ cases INEXACT->EXACT was called with the results of these | > functions. So having ROUND, CEILING, FLOOR, and TRUNCATE return | > infinities will only slightly delay the exception. | | - which seems like the more correct place for it to occur; The largest IEEE-754 non-integer is 4503599627370495.5. Calling rounding functions for inexacts over 285 orders of magnitude larger than this is laughable. So I will change the specification of ROUND, CEILING, FLOOR, and TRUNCATE to accept only finite real numbers. | if the concept of an exact infinity was not reasonably acceptable. The possibility that systems may implement exact infinities rules out having the error be with INEXACT->EXACT (passed real infinities).

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

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

- Prev by Date:
**Re: Nitpick with FLOOR etc.** - 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):