[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*: 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):