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

This page is part of the web mail archives of SRFI 77 from before July 7th, 2015. The new archives for SRFI 77 contain all messages, not just those from before July 7th, 2015.

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