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

*To*: William D Clinger <will@xxxxxxxxxxx>, <srfi-77@xxxxxxxxxxxxxxxxx>*Subject*: Re: ambiguous sign notation support?*From*: Paul Schlie <schlie@xxxxxxxxxxx>*Date*: Tue, 04 Jul 2006 00:49:06 -0400*Delivered-to*: srfi-77@xxxxxxxxxxxxxxxxx*In-reply-to*: <E1FxS5s-0004PI-7P@xxxxxxxxxxxxxxxxx>*Thread-index*: AcafJS3wbLe6cgsYEdu/mwADk1ictA==*Thread-topic*: ambiguous sign notation support?*User-agent*: Microsoft-Entourage/11.2.3.060209

> From: William D Clinger <will@xxxxxxxxxxx>> >> 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. >> ... > 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 I agree that they need not be mandated, however the designation of +nan.0 as the default NaN notation would seem to imply a positive numerical ambiguity; thereby suspect if R6RS formalized '~' as being a formally accepted notation for numerical sign ambiguity, then ~nan.0 could be formally specified as the notation for a generally ambiguous value; from which other somewhat more precise ambiguities may then be utilized as a compatible extension? -paul-

**References**:**Re: ambiguous sign notation support?***From:*William D Clinger

- Prev by Date:
**Re: SRFI-77 with more than one flonum representation** - Next by Date:
**number->string should use either no exponent or an e-exponent** - Previous by thread:
**Re: ambiguous sign notation support?** - Next by thread:
**number->string should use either no exponent or an e-exponent** - Index(es):