[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*: Sun, 24 Jul 2005 21:15:57 -0400 (EDT)*Cc*: srfi-70@xxxxxxxxxxxxxxxxx*Delivered-to*: srfi-70@xxxxxxxxxxxxxxxxx*In-reply-to*: <BF05BAFD.AED1%schlie@xxxxxxxxxxx> (message from Paul Schlie on Thu, 21 Jul 2005 20:50:05 -0400)*References*: <BF05BAFD.AED1%schlie@xxxxxxxxxxx>

| Date: Thu, 21 Jul 2005 20:50:05 -0400 | From: Paul Schlie <schlie@xxxxxxxxxxx> | | After attempting to digest everything discusses, although realizing | your desire to not require any corresponding impact to either rsrx | or exact semantics; I don't believe it's reasonably possible, as it | seems that the only way to achieve what you desire, and maintain | reasonable consistency with mixed exact/inexact arithmetic would be | to: | | - as suggested by "bear", define the requirement that exact and | inexact value representations be constrained to the same value | range. I am reluctant to add that requirement unless someone can provide an example from practice where the ranges being unequal caused bad software behavior. | - define infinites and their reciprocals to abstractly commonly | represent the greatest/smallest values at bounds of the | representable numerical range, As I written previously, using the boundary for the nominal value is the worst choice from that neighborhood. Doing so means that nearly every calculation which projects into #i+/0 is larger than the nominal value. | exclusive of 0 representing an absolute 0, who's reciprocal is | itself 0. This would mean (* 0 (/ 0)) would no longer signal an error or return 0/0, thus failing to meet some of the original goals of SRFI-70. What would (/ 0.0) return (exact or inexact)? What would (/ 0 0) do? How about (/ 0 0.0)? | - thereby the range of all numerical transforms map to a | correspondingly representable domain (although may optionally | signal a run-time exception as may be desired in certain | circumstances). This would have been nice, but the smallest (unnormalized) numbers in IEEE-754 are not symmetrical with the largest magnitude numbers: (/ 179.76931348623157e306) ==> 5.562684646268003e-309 (/ 5.562684646268003e-309) ==> #i+/0 There are unnormalized numbers down to 4.0e-324, all of whose reciprocals are #i+/0. | Which overall seems to eliminate all the contentious issues, as | long as one is willing to accept the consequences saturating | arithmetic, in lieu of an typically arguably less useful more | abstract treatment of infinites. | | Effectively resulting in: | | .. -1.0 .. | .. +1.0 .. | -1/0 .. -1/1 .. -0/1 | +0/1 .. +1/1 .. +1/0 | -------------------- 0 --------------------- (multiplicative inverse axis) | -0/1 .. -1/1 .. -1/0 | +1/0 .. +1/1 .. +0/1 | .. -1.0 .. | .. +1.0 .. | | | (additive inverse axis) How is this different from your "more abstract treatment of infinities"?

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