[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Nitpick with FLOOR etc.
| 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).