Re: Nitpick with FLOOR etc.

[Aubrey Jaffer <agj@xxxxxxxxxxxx>]

 | Date: Mon, 18 Jul 2005 14:40:40 -0400
 | From: Paul Schlie <schlie@xxxxxxxxxxx>
 | 
 | > From: Aubrey Jaffer <agj@xxxxxxxxxxxx>
 | >  | Date: Sun, 17 Jul 2005 23:24:49 -0400
 | >  | From: Paul Schlie <schlie@xxxxxxxxxxx>
 | >  | 
 | >  | > From: Paul Schlie <schlie@xxxxxxxxxxx>
 | >  | >> The possibility that systems may implement exact infinities rules out
 | >  | >> having the error be with INEXACT->EXACT (passed real infinities).
 | >  | 
 | >  | - maybe that implies that infinities and their reciprocals are in a
 | >  | class by themselves, as neither are warranted to have some minimal
 | >  | precision, as both exact and inexact representations have, but
 | >  | rather represent an underflow of the minimal precision otherwise
 | >  | warranted, thereby effectively representing the bounds of an
 | >  | implementation's exact/inexact representations?
 | > 
 | > Infinity as a number is not what SRFI-70 is about.  In it, inexact
 | > numbers are real neighborhoods and inexact infinities are real
 | > half-lines.  These semantics seem to be working well; but they are not
 | > applicable to exact numbers.
 | > 
 | > See SRFI-73 for infinity-as-number.
 | 
 | sorry, I think I was partially responding within the context of:
 | 
 |   | > That conflicts with SRFI-70, which specifies that #i+1/0 compares as
 |   | > larger than any finite real number, exact or inexact:
 | 
 | which implied a relationship between an inexact infinity and exact
 | values which is not generally true,

Sure it is.  Large exact values fall within the real half-line which
is #i+/0.

  (exact->inexact (expt 10 1000)) ==> #i+/0

For finite neighborhoods, calculations and comparisons are done with
the nominal value near the center of the neighborhood.  What nominal
value should be used for the #i+/0 neighborhood?  The worst choice is
the border value for the half-line.  For flonum calculations we can
use IEEE +inf; it has the correct behavior in comparisons and
calculations.

Combinations of #i+/0 with exact numbers can convert to inexact before
operating.  This does not lose all sensitivity to number size:

  (- (/ 0.0) (expt 10 400)) ==> #i0/0

Alternatively, exact numeric operations could be modified to treat
#i+/0 as an infinitely large number.

 | >  | Merely indicating the value was greater in magnitude than the
 | >  | greatest representable inexact value, but less than the
 | >  | greatest representable exact value, but without a minimally
 | >  | sufficient resolvable precision?
 | >  | 
 | >  | Implying something along the line of:
 | >  | 
 | >  |   #e-1/0     ..  #e-xxx  ..      #e-0/1 0  ...
 | >  |     |     |                   |     |   |
 | >  |        #i-1/0 .. #i-xxx .. #i-0/1       0  ...

In such a system, #i+/0 is just another finite neighborhood.  But its
rules are more complicated than as an infinity.

There will be some value M such that (* M #i+/0) ==> #e+/0.

And new conumdrums:
(/ #e+/0 M) ==> ??
(/ #i+/0 M) ==> ??
(* #i+/0 #i+/0) ==> ??