DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:reply-to:subject:to:references:from:message-id
	:date:mime-version:in-reply-to:content-type
	:content-transfer-encoding; q=dns; s=default; b=NOmMhVwgScuSL+3Y
	eXEofCF7qxC41AMgRolVY41c6P3UqEXFcSUzdPnWDCmGpZdJIW86TA+qGK7IvYjL
	5833rSUB2TUQxPc2zOzBuQE2xhl4iLKA/oQ4mzLjZQyYhAIOqztGUZKejrZdJ4Bf
	iHhCOIkzBHWtRDasTGEEjx0+Nwo=
Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
Reply-To: Brian.Inglis@SystematicSw.ab.ca
Subject: Re: strtod ("nan") returns negative NaN
To: cygwin@cygwin.com
References: <CANnLRdii8mX71D936AhhEYm+S0s4gS5RGgpPhV_rB6=kzmXKsw@mail.gmail.com> <20180814.100952.1684125661222835312.trueroad@trueroad.jp> <20180814.113135.1571893395887584078.trueroad@trueroad.jp> <20180814.134527.917341694729989717.trueroad@trueroad.jp> <20180814095618.GT3747@calimero.vinschen.de> <20180814103900.GU3747@calimero.vinschen.de> <87lg98eoq2.fsf@Rainer.invalid>
From: Brian Inglis <Brian.Inglis@SystematicSw.ab.ca>
Openpgp: preference=signencrypt
Message-ID: <219cb2f1-60fd-36ee-d273-7e2aac261654@SystematicSw.ab.ca>
Date: Mon, 20 Aug 2018 12:06:39 -0600
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <87lg98eoq2.fsf@Rainer.invalid>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

On 2018-08-14 13:24, Achim Gratz wrote:
> Corinna Vinschen writes:
>> With your patch, strtold looks more correct, but it still prints the
>> sign of NaN:
>>
>>   strtod ("nan", NULL) = nan
>>   strtod ("-nan", NULL) = nan
>>   strtold ("nan", NULL) = nan
>>   strtold ("-nan", NULL) = -nan
>>   nan ("") = nan
>>
>> Question: What's wrong with that?  Wouldn't it be more correct if
>> strtod returns -NaN for "-nan" as well?
> 
> That's iffy, the treatment of sign bits for NaN is quite different from
> the usual arithmetic rules.  A NaN is literally "not a number", i.e. the
> computation has left the domain of representable FP numbers, so it
> really doesn't have a sign.  That doesn't stop folks from using the sign
> bit on its representation, but that's a different story.  The sign
> properly belong to what is called the "payload", which is usally
> ignored.  So converting "-nan" (or NaN multiplied by -1) really ought to
> be just plain NaN.

Except the most significant bit of the significand is not payload either, which
may matter for newlib platforms; from
https://en.wikipedia.org/wiki/NaN#Encoding:

". most processors (including those of the Intel and AMD's x86 family, the
Motorola 68000 family, the AIM PowerPC family, the ARM family, the Sun SPARC
family, and optionally new MIPS processors) set the signaling/quiet bit to
non-zero if the NaN is quiet, and to zero if the NaN is signaling. Thus, on
these processors, the bit represents an 'is_quiet' flag;
. in NaNs generated by the PA-RISC and old MIPS processors, the signaling/quiet
bit is zero if the NaN is quiet, and non-zero if the NaN is signaling. Thus, on
these processors, the bit represents an 'is_signaling' flag."

"The 2008 revision of the IEEE 754 standard (IEEE 754-2008) makes formal
recommendations for the encoding of the signaling/quiet state.

. For binary formats, the most significant bit of the significand field should
be an 'is_quiet' flag i.e. this bit is non-zero if the NaN is quiet, and zero if
the NaN is signaling."

"For IEEE 754-2008 conformance, the meaning of the signaling/quiet bit in recent
MIPS processors is now configurable via the NAN2008 field of the FCSR register.
This support is optional in MIPS Release 3 and required in Release 5."

and for libraries supporting decimal FP for COBOL et al:

". For decimal formats, whether binary or decimal encoded, a NaN is identified
by having the top five bits of the combination field after the sign bit set to
ones. The sixth bit of the field is the 'is_quiet' flag. The standard follows
the interpretation as an 'is_signaling' flag i.e. the signaling/quiet bit is
zero if the NaN is quiet, and non-zero if the NaN is signaling. A signaling NaN
is quieted by clearing this sixth bit."

Further requirements for IEEE 754:2008 as ISO/IEC/IEEE 60559:2011 may apply
documented in ISO/IEC TS 18661-1:2014 and ISO/IEC TS 18661-4:2015 and summarized
at:
https://en.cppreference.com/w/c/experimental/fpext1
https://en.cppreference.com/w/c/experimental/fpext4

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple