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

Re: Nitpick with FLOOR etc.

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.



 | 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) ==> ??