[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*: Wed, 20 Jul 2005 15:25:19 -0400 (EDT)*Cc*: srfi-70@xxxxxxxxxxxxxxxxx*Delivered-to*: srfi-70@xxxxxxxxxxxxxxxxx*In-reply-to*: <BF016959.ADF9%schlie@xxxxxxxxxxx> (message from Paul Schlie on Mon, 18 Jul 2005 14:12:41 -0400)*References*: <BF016959.ADF9%schlie@xxxxxxxxxxx>

| Date: Mon, 18 Jul 2005 14:12:41 -0400 | From: Paul Schlie <schlie@xxxxxxxxxxx> | | > From: Aubrey Jaffer <agj@xxxxxxxxxxxx> | > ... | > One might argue that large exact numbers being within the | > +/0. interval make them `=' to it. But that foils transitivity for | > `=': | > | > (= (expt 10 1000) +/0. (expt 10 999) | > | > Large exact numbers can not be greater than +/0. because the entire | > real line is covered by inexact neighborhoods in SRFI-70. | > | > So large exact numbers must be less than +/0.. | | - maybe I misunderstand, but my attempted point was that since many | exact implementations enable the representation of value of greater | magnitude than the value range that an inexact infinity begins, it | seems incorrect to define that (> #i1/0 1e1000) if #i1/0 represents | all values greater than an inexact 1e306 for example. For the purpose of comparisons, the nominal value (not the real interval) of an inexact is used. This is so that mixed comparisons maintain total order with transitivity: (let ((big-inex (expt 2. 100))) (< (- (inexact->exact big-inex) 1) big-inex (+ (inexact->exact big-inex) 1))) ==> #t For real infinities, there is no nominal value. SRFI-70 chooses to have them behave as though their values are upper and lower bounds of all the finite real (exact and inexact) values an implementation supports. | I would presume: | | (> #i1/0 1e1000) => #f Okay. (number->string 1e1000) ==> #i+/0 If you meant #e1e1000, then the answer should be #t. | and | (= #i1/0 1e1000) => #f This should be #t for the same reason. If you meant #e1e1000, then the answer should be #f; no finite number should be equal to infinity. | yet | (> #e1/0 1e1000) => #t | | assuming #e1/0 were unique from #i1/0, and representing all values | greater than the representational range of an exact implementation, | assuming that all implementations of exact have some practical | limit. Thereby also: | | (>= #e1/0 #i1/0) => #t ; as #i1/0 is a subset of #e1/0, not > or =. Then we lose the total ordering of the reals. Subset-of as a metric does not produce a total ordering. Note that SRFI-70 does not specify where the border is between finite and infinite numbers. The spacing between the largest finite numbers is very large: (- 179.76931348623157e306 179.76931348623156e306) ==> 1.99584030953472e+292 For adjoining neighborhoods, the border between them is the point equidistant from their nominal values. #i+/0 has no nominal value; so we need not link its boundary to some nominal value we assign. Picking a nominal value which is the same as an exact infinity nominal value makes conversions between them work and preserves the total order for mixed comparisons.

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