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.
> 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 > Most neighborhoods mapping through 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 (tan pi/2) => #i~1/0 ; ~inf.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)