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

*To*: srfi-77@xxxxxxxxxxxxxxxxx*Subject*: Re: ambiguous sign notation support?*From*: William D Clinger <will@xxxxxxxxxxx>*Date*: Mon, 03 Jul 2006 13:20:20 -0400*Delivered-to*: srfi-77@xxxxxxxxxxxxxxxxx

Paul Schlie wrote: > Any possibility of considering a somewhat more numerically > consistent abstract notation for ambiguously signed values? > > (i.e. ~nan.0 replaces the positively signed +nan.0 notation) > > Thereby enabling the optionally supported designations: > > ~inf.0 ~inf.0 > -inf.0 -0.0 0 +0.0 +inf.0 > <|------------------------|-----------------------|> > <--------- -nan.0 -------> <-------- +nan.0 -------> > <---------------------- ~nan.0 --------------------> This is an interesting question. The IEEE-754 standard does not mandate *any* means for determining the sign of a NaN, but recommends a CopySign function that could be used for that purpose. > (/ -0.0) => -inf.0 > > (/ 0) => ~inf.0 (or basic ~nan.0) > > (/ +0.0) => +inf.0 > > (/ -inf.0 +0.0) => -nan.0 (or basic ~nan.0) > > (/ ~inf.0 +0.0) => ~nan.0 > > (/ +inf.0 +0.0) => +nan.0 (or basic ~nan.0) > > Enabling a basic implementation to simply map: > > ~inf.0 -nan.0 +nan.0 => ~nan.0 SRFI 77 does not require all NaNs to print as +nan.0. In fact, I don't believe SRFI 77 forbids any of the NaNs you wrote above to print as ~nan.0. In that sense, I believe SRFI 77 already allows the extension you desire. The extension you desire should not be mandated, however, because the IEEE standards explicitly allow a very large variety of encodings for the NaN values they specify. Will

**Follow-Ups**:**Re: ambiguous sign notation support?***From:*Paul Schlie

- Prev by Date:
**Re: SRFI-77 with more than one flonum representation** - Next by Date:
**Re: SRFI-77 with more than one flonum representation** - Previous by thread:
**ambiguous sign notation support?** - Next by thread:
**Re: ambiguous sign notation support?** - Index(es):