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

*To*: schlie@xxxxxxxxxxx*Subject*: Re: Nitpick with FLOOR etc.*From*: Aubrey Jaffer <agj@xxxxxxxxxxxx>*Date*: Thu, 21 Jul 2005 19:37:08 -0400 (EDT)*Cc*: srfi-70@xxxxxxxxxxxxxxxxx*Delivered-to*: srfi-70@xxxxxxxxxxxxxxxxx*In-reply-to*: <BF016FE8.AE02%schlie@xxxxxxxxxxx> (message from Paul Schlie on Mon, 18 Jul 2005 14:40:40 -0400)*References*: <BF016FE8.AE02%schlie@xxxxxxxxxxx>

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

**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: inexactness vs. exactness** - Previous by thread:
**Re: Nitpick with FLOOR etc.** - Next by thread:
**Re: Nitpick with FLOOR etc.** - Index(es):