From owner-freebsd-standards@FreeBSD.ORG Thu Dec 25 20:35:09 2014 Return-Path: Delivered-To: freebsd-standards@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CDA6532F for ; Thu, 25 Dec 2014 20:35:09 +0000 (UTC) Received: from nm1-vm1.bullet.mail.bf1.yahoo.com (nm1-vm1.bullet.mail.bf1.yahoo.com [98.139.213.163]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 715242DB5 for ; Thu, 25 Dec 2014 20:35:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1419539702; bh=d5IAv6vlQux4qC3rmaQA0p1PJt11Jl5mFAWpnxuCq7I=; h=Date:From:To:CC:Subject:References:In-Reply-To:From:Subject; b=PqnjAMuLAPawLYyCDKw6eW08vRxEGqlHtynvHaYY+Xqio/T3sD0M6xEu1L4EpGIRxHg8v77gsef11yg8J47QuILTBZCO1uc+ElJhyA7/AdBZvyYkhypA4DOcAWXjjtGFxeyzzTtWHcGaBaYoQBN/V/qd2TxkNPaxS3F5CGIgPQXkuLCW6CM0R3V0848hOw6TlZhb9vhbI3jLyLGF+ze2mTYkL3WMxPo7SPla4BO1YWsb0AhDqNp6TUNWNXGgH2ttKy6j/sYLTanJEc4WGqC/FyF7SxP4NpMY5MDyIxJ9BuGgc78+yOQqyo1chGFwNmSUaMypqBk1QW2zj2U8tjjMGw== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s2048; d=yahoo.com; b=uYjmxxhK78xiHFKUqj5XviPTpNceH9FhhL+nWHcNw/7X7A90OOGfFisp+F0V2JLMGYvWLgJ0x3vUfS/DEwefTbqmZsW0Bvxl66B/51heVta7U8Ui7a+akUbcycZcMZHzr128dcN2YIeCJcAwFP5X7BTH4W8cdnTiv9OHMediyNcR+9xIvkYgbGnB3xo4UMaJKYtGX7SXo2oNqWSc3XcE0DqGUI1GLvUywI29iYheiEdHopQ++s2RyBGbqdbYRvDsOBFa/YC8V8dKbwvSh3wYTBu4LWPwOGwrXyaS/yAXfk3qrEnAZ8R3GKD/oCGLnMwhSUvrXqxDK7EUOkNROUJ0Ww==; Received: from [98.139.215.140] by nm1.bullet.mail.bf1.yahoo.com with NNFMP; 25 Dec 2014 20:35:02 -0000 Received: from [98.139.211.202] by tm11.bullet.mail.bf1.yahoo.com with NNFMP; 25 Dec 2014 20:35:02 -0000 Received: from [127.0.0.1] by smtp211.mail.bf1.yahoo.com with NNFMP; 25 Dec 2014 20:35:02 -0000 X-Yahoo-Newman-Id: 355196.36589.bm@smtp211.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: zOawjpwVM1lCfRGJcFOIjwdnZE.TFfH3PLt2z.1yMI0.D9Z rezJb8gCJuplgTwkn87vPnxoGZ2aZwKxQO.oaH5eG53S05P.E3UmRQcsa0oT wNSRwkW7JYTb.3C2DHDAQEgPeDh2Tze0T_SItSRUU8iA9gUSeRdgFANbgCnj .xHLfsSPpKdMiXRTiFa_6vSkqP.m.I523gYd5LfAV10s.WqyzHFzKkdBeUb_ Ahi17nrsvd7Ji4VLB7agGhNbdhvEKNmRR.lX.u37gsFBPhMkEUxxegEeeIN0 W7VNw_trUhJp_FzsKGeuYa7uh.X_wtMHaPQzGzOGOlPTP6qy4QuhAQ1jipug tzgKmahSPBjV2LeZcLr4BorLsh5i1NkkRGN0uGwPA4mXrg4RHS.K3iDDrUc3 gHLcyeAvK9dRogcb5ay9Usd4CwofUEPbQkQDsYNYX1LkuY_s_eZ1j2RVPY1j CVd9aqLBA4zgg0T0OWVfy8yoLOEMlFbrJPL66tM_BBuf8xyicp2OAXl0g2P7 dyS7jIRfoUPahWx.hqWQOEgUHbPm5ofYzCZGIQSDbWD._90pDMja.c64aSOn sisfG4ifI4Jw0sCuBexFuaw6Oke6GxEKbzwfM1yVqLDw1HaJlu9DNWdBoKkV QlPi0llhw3IJmbGngMVLcj4pfIz8OPZ.HvM9sOHHlXakkYZg2t5t9zrUfg8x xpcL89jyk X-Yahoo-SMTP: xcjD0guswBAZaPPIbxpWwLcp9Unf Message-ID: <549C7516.5070204@FreeBSD.org> Date: Thu, 25 Dec 2014 15:35:34 -0500 From: Pedro Giffuni User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Warner Losh Subject: Re: Does posix say anything about the sign in NaNs ? References: <549B1115.8000909@FreeBSD.org> <20141225235228.H927@besplex.bde.org> <003E7D36-61E0-4572-A98C-24351F6ADF5A@freebsd.org> <2A81225A-09C3-4DFF-A4DA-6B440AFFB857@bsdimp.com> In-Reply-To: <2A81225A-09C3-4DFF-A4DA-6B440AFFB857@bsdimp.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-standards@freebsd.org X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Dec 2014 20:35:09 -0000 On 12/25/14 14:35, Warner Losh wrote: >> On Dec 25, 2014, at 7:53 AM, Pedro Giffuni wrote: >> >> Hello; >> >>> Il giorno 25/dic/2014, alle ore 09:00, Bruce Evans ha scritto: >>> >>> On Wed, 24 Dec 2014, Pedro Giffuni wrote: >>> >>>> I got the attached patch from OpenBSD. >>>> >>>> It says: >>>> ____ >>>> Show the sign for NaN as per POSIX; from Elliott Hughes. >>>> ok martynas@, millert@, doug@ >>>> ____ >>>> >>>> I can't find a reference in POSIX documentation to support it though. >>> The behaviour is implementation-defined. From n869.txt for printf: >>> >>> X A double argument representing an infinity is >>> X converted in one of the styles [-]inf or [-]infinity >>> X -- which style is implementation-defined. A >>> X double argument representing a NaN is converted in >>> X one of the styles [-]nan or [-]nan(n-char-sequence) >>> X -- which style, and the meaning of any n-char- >>> X sequence, is implementation-defined. The F >>> X conversion specifier produces INF, INFINITY, or NAN >>> X instead of inf, infinity, or nan, respectively.220) >>> >>> "style" is not clearly defined. The format for input in strtod() >>> is formally defined as [-]something without using the term "style", >>> but the specication for actually handling the minus sign is even less >>> complete (see below). >>> >>> The library intentionally suppresses the sign for NaNs on output. >>> This is consistent with it ignororing the sign for NaNs on input. >>> >> >> Interesting and pretty much the reason why I wanted to discuss the change. >> >> I can see the sign information is important for infinity but indeed it makes >> very little sense (if any) for NaN. OTOH, we are doing an extra assignment >> to hide something the standard permits. If we are ignoring the sign of NaNs >> on input there should be no such sign information in the first place and >> ignoring the value is unnecessary. >> >> While I am tempted to follow the change, I think it is pretty much innocuous >> as no reasonably correct program should depend on the sign of NaN. > My only concern with this change is that numeric programs might actually break because they know this implementation detail. Its here some way to discover if things my pysci or R have any change in behavior here? In addition to the standard, numerical methods have much apocrypha associated with them. > > Warner Well, you should only get a NaN when you did something wrong in your calculation and that's pretty much the end of it. Googling around, it appears glibc did a similar change, and it did cause issues to someone: http://stackoverflow.com/questions/3772835/getting-a-negative-nan-on-g-4-4-3-is-this-standard Given it's implementation dependent I now think it is better to keep the historical behavior consistent so I won't be committing the change. Cheers, Pedro.