NetBSD Problem Report #45372

From jruohone@gmail.com  Sat Sep 17 06:54:01 2011
Return-Path: <jruohone@gmail.com>
Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11])
	by www.NetBSD.org (Postfix) with ESMTP id 1342E63B86B
	for <gnats-bugs@gnats.netbsd.org>; Sat, 17 Sep 2011 06:54:01 +0000 (UTC)
Message-Id: <20110917065357.5F56F56C9@marx.bitnet>
Date: Sat, 17 Sep 2011 09:53:57 +0300 (EEST)
From: Jukka Ruohonen <jruohonen@iki.fi>
Sender: a b <jruohone@gmail.com>
Reply-To: jruohonen@iki.fi
To: gnats-bugs@gnats.NetBSD.org
Subject: A bug in pow(3)
X-Send-Pr-Version: 3.95

>Number:         45372
>Category:       lib
>Synopsis:       A bug in pow(3)
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    lib-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sat Sep 17 06:55:00 +0000 2011
>Last-Modified:  Tue May 01 06:10:03 +0000 2012
>Originator:     Jukka Ruohonen
>Release:        NetBSD 5.99.55/amd64
>Organization:
-
>Environment:
>Description:

For pow(x, y), if x = -1 and y = +- Inf, 1.0 should be returned. But NetBSD
returns incorrectly NaN.

>How-To-Repeat:

A simple test case reveals this.

>Fix:

NA.

>Audit-Trail:
From: Jukka Ruohonen <jruohonen@iki.fi>
To: gnats-bugs@NetBSD.org
Cc: lib-bug-people@NetBSD.org, gnats-admin@NetBSD.org,
	netbsd-bugs@NetBSD.org
Subject: Re: lib/45372: A bug in pow(3)
Date: Sat, 17 Sep 2011 11:11:33 +0300

 Also: if y is odd, y < 0, and x is -Inf, -0.0 should be returned. This is OK
 for pow(3) but powf(3) returns without the sign, i.e. +0.0.

From: "Jukka Ruohonen" <jruoho@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/45372 CVS commit: src
Date: Sat, 17 Sep 2011 08:15:43 +0000

 Module Name:	src
 Committed By:	jruoho
 Date:		Sat Sep 17 08:15:43 UTC 2011

 Modified Files:
 	src/distrib/sets/lists/tests: mi
 	src/tests/lib/libm: Makefile
 Added Files:
 	src/tests/lib/libm: t_pow.c

 Log Message:
 IEEE corner case tests for the pow(3) family (incl. PR lib/45372).


 To generate a diff of this commit:
 cvs rdiff -u -r1.385 -r1.386 src/distrib/sets/lists/tests/mi
 cvs rdiff -u -r1.9 -r1.10 src/tests/lib/libm/Makefile
 cvs rdiff -u -r0 -r1.1 src/tests/lib/libm/t_pow.c

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

From: Thomas Klausner <wiz@NetBSD.org>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: lib/45372: A bug in pow(3)
Date: Sat, 17 Sep 2011 11:25:12 +0200

 On Sat, Sep 17, 2011 at 06:55:00AM +0000, Jukka Ruohonen wrote:
 > For pow(x, y), if x = -1 and y = +- Inf, 1.0 should be returned. But NetBSD
 > returns incorrectly NaN.

 So you're saying that -1^(+infinity) is 1?
 Which standard defines that?

 e_pow.c explicitly mentions the case:
  *      9.  +-1         ** +-INF is NAN
 and I tend to agree.
  Thomas

From: Jukka Ruohonen <jruohonen@iki.fi>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: lib/45372: A bug in pow(3)
Date: Sat, 17 Sep 2011 12:57:44 +0300

 On Sat, Sep 17, 2011 at 09:30:06AM +0000, Thomas Klausner wrote:
 >  So you're saying that -1^(+infinity) is 1?

 Yes, in libm(3).

 >  Which standard defines that?

 IEEE.

 >  e_pow.c explicitly mentions the case:
 >   *      9.  +-1         ** +-INF is NAN
 >  and I tend to agree.

 It is wrong. There is little room for interpretation in the standards. 
 Note also that Linux and other operating systems have this right.

 - Jukka.

From: Jukka Ruohonen <jruohonen@iki.fi>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: lib/45372: A bug in pow(3)
Date: Sat, 17 Sep 2011 13:17:00 +0300

 On Sat, Sep 17, 2011 at 10:00:07AM +0000, Jukka Ruohonen wrote:
 >  >  Which standard defines that?
 >  
 >  IEEE.

 Clarification: both IEEE and ISO. For the latter see (p. 460) in

 	http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf

 - Jukka.

From: Thomas Klausner <wiz@NetBSD.org>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: lib/45372: A bug in pow(3)
Date: Sat, 17 Sep 2011 12:21:36 +0200

 On Sat, Sep 17, 2011 at 10:00:07AM +0000, Jukka Ruohonen wrote:
 >  Yes, in libm(3).

 We don't have libm(3). Which do you mean?

 >  >  Which standard defines that?
 >  
 >  IEEE.

 Ok. I also found open group saying so in
 http://pubs.opengroup.org/onlinepubs/009695399/functions/pow.html

 >  It is wrong. There is little room for interpretation in the standards. 
 >  Note also that Linux and other operating systems have this right.

 I still disagree mathematically, but I agree that we should follow the
 standard.
  Thomas

From: Jukka Ruohonen <jruohonen@iki.fi>
To: gnats-bugs@NetBSD.org
Cc: Thomas Klausner <wiz@NetBSD.org>
Subject: Re: lib/45372: A bug in pow(3)
Date: Sat, 17 Sep 2011 13:30:56 +0300

 On Sat, Sep 17, 2011 at 10:25:03AM +0000, Thomas Klausner wrote:
 >  We don't have libm(3). Which do you mean?

 Oh, math(3) then.

 >  I still disagree mathematically, but I agree that we should follow the
 >  standard.

 That is entirely different question (which should be debated in the
 standardization committees).

 Since this is about IEEE floating point specification and about the core C
 language, indeed I agree that there should be no room for divergence, unlike
 with, say, POSIX that is always open to discussion.

 - Jukka.

From: David Holland <dholland-bugs@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: lib/45372: A bug in pow(3)
Date: Sun, 18 Sep 2011 23:26:58 +0000

 On Sat, Sep 17, 2011 at 10:35:02AM +0000, Jukka Ruohonen wrote:
  > Since this is about IEEE floating point specification and about
  > the core C language, indeed I agree that there should be no room
  > for divergence, unlike with, say, POSIX that is always open to
  > discussion.

 Indeed. It's kind of odd though; usually when floating-point
 operations lead to nonsense results there's a reason that follows from
 the properties of floating-point numbers; in this case though I really
 don't see what. I guess it must be for consistency with something
 else?

 -- 
 David A. Holland
 dholland@netbsd.org

From: Jukka Ruohonen <jruohonen@iki.fi>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: lib/45372
Date: Tue, 1 May 2012 09:10:13 +0300

 For cross-references; see also PR standards/46388.

Home	PR Database Search