| Date: Sun, 17 Jul 2005 13:23:26 -0400
 | From: Paul Schlie <xxxxxx@comcast.net>
 |
 | > From: Aubrey Jaffer <xxxxxx@alum.mit.edu>
 | >  | Date: Sat, 16 Jul 2005 05:12:13 -0400
 | >  | From: Paul Schlie <xxxxxx@comcast.net>
 | >
 | > ...
 | > 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).