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

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.

*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):