[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: comparison operators and *typos*From*: Aubrey Jaffer <agj@xxxxxxxxxxxx>*Date*: Thu, 30 Jun 2005 23:32:24 -0400 (EDT)*Cc*: srfi-70@xxxxxxxxxxxxxxxxx*Delivered-to*: srfi-70@xxxxxxxxxxxxxxxxx*In-reply-to*: <BEEA0257.AAEE%schlie@xxxxxxxxxxx> (message from Paul Schlie on Thu, 30 Jun 2005 20:11:03 -0400)*References*: <BEEA0257.AAEE%schlie@xxxxxxxxxxx>

| Date: Thu, 30 Jun 2005 20:11:03 -0400 | From: Paul Schlie <schlie@xxxxxxxxxxx> | | > If we make (/ +1 0.0) ==> #i+1/0, then (/ -1 0.0) ==> #i-1/0. | > This choice is arbitrary; ... | | - which seems very reasonable. | | > | > Inexact infinities have reciprocals: zero. Their reciprocals | > | > are not unique, but that is already the case with IEEE-754 | > | > floating-point representations: | > ... | > Zero is at the center of 0.0's neighborhood. R5RS division by 0.0 | > is an error; leaving latitude for SRFI-70's response. | | - also seems very reasonable, and provide the opportunity to reconsider | eliminating IEEE-754's otherwise inconsistent asymmetry, by defining: | | (/ #i-0/1) => #i-1/0 ; -inf.0 | (/ #i+0/1) => #i+1/0 ; +inf.0 | | thereby truly consistently symmetric with the above: | | (/ #i-1/0) => #i-0/1 ; -0.0 | (/ #i+1/0) => #i+0/1 ; +0.0 It does not remove the asymmetry -- which neighborhood does (unsigned) 0.0 belong to: -0.0 or +0.0? | > Most neighborhoods mapping through piecewise-continuous functions | > project onto adjacent neighborhoods. But / near 0 is not the | > only function which does not. TAN near pi/2 is another example. | | - and please reconsider this may be consistently symmetrically defined: | [where ~ denotes a value being simultaneously positive and negative] | | (/ #i~0) => #i~1/0 ; ~inf.0 | (/ #i~1/0) => #i~0 ; ~0.0 #i~0 is not a real number because it cannot be ordered (relative to 0.0). Damaging the total ordering of the real numbers is too high a price for symmetry. | (tan pi/2) => #i~1/0 ; ~inf.0 (atan #i+1/0) ==> 1.5707963267948965 The next larger IEEE-754 number is 1.5707963267948967. But there is no IEEE-754 number whose tangent is infinite: (tan 1.5707963267948965) ==> 16.331778728383844e15 (tan 1.5707963267948967) ==> -6.218352966023783e15 Note that the one-sided LIMIT gets it right without needing any new numbers: (limit tan 1.5707963267948965 -1.0e-15) ==> +1/0 (limit tan 1.5707963267948965 1.0e-15) ==> -1/0 | (abs ~inf.0) => +inf.0 | (- (abs ~inf.0) => -inf.0 | (abs ~0.0) => +0.0 | (- (abs ~0.0)) -0.0 | | (+ +0.0 -0.0) => ~0.0 | | Where I believe it's reasonable to redefine the use of IEEE's NAN | values to encode these values, as arguably ~inf.0 may be thought | of as being NAN, and ~0.0 as being 1/NAN (leaving 0.0 == +0.0) For some expressions returning #i0/0, no number has any more claim to correctness than any other. For example any number x satisfies: 0*x=0. So #i0/0 could be any number (if we forget that division by zero is undefined). The reciprocal of this #i0/0 potentially maps to any number; which is represented by #i0/0.

**Follow-Ups**:**Re: comparison operators and *typos***From:*Paul Schlie

**References**:**Re: comparison operators and *typos***From:*Paul Schlie

- Prev by Date:
**Re: comparison operators and *typos** - Next by Date:
**Re: comparison operators and *typos** - Previous by thread:
**Re: comparison operators and *typos** - Next by thread:
**Re: comparison operators and *typos** - Index(es):