This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.

Index Nav:	[Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav:	[Date Prev] [Date Next]	[Thread Prev] [Thread Next]
Other format:	[Raw text]

Re: __builtin_cpow((0,0),(0,0))

From: Paolo Carlini <pcarlini at suse dot de>
To: Robert Dewar <dewar at adacore dot com>
Cc: gcc at gcc dot gnu dot org, libstdc++ <libstdc++ at gcc dot gnu dot org>
Date: Mon, 07 Mar 2005 16:43:58 +0100
Subject: Re: __builtin_cpow((0,0),(0,0))
References: <422C63ED.8020200@suse.de> <422C6C28.6070309@suse.de> <422C6FF8.6020102@adacore.com>

Robert Dewar wrote:

Paolo Carlini wrote:

Actually, sorry, __builtin_cpow returns (nan, nan) (got sidetracked by a strange issue I'm seeing in the C++ library), even "worse", so to speak...

Paolo.
Well it certainly seems the right result in this case to me. Does the
standard really require the wrong result here?

You mean (nan, nan) is ok? Why, exactly? Isn't (1,0) more consistent with the behavior of real power? (*) The standard is rather vague, in my reading, allowing "spurious exceptions" in "special cases", thus allowing a plain cexp(c*clog(z)).

Paolo.

(*) This "intuition" is confirmed by a range of independent "appliances", like high quality HP calculators or Maple...

References:
- __builtin_cpow((0,0),(0,0))
  - From: Paolo Carlini
- Re: __builtin_cpow((0,0),(0,0))
  - From: Paolo Carlini
- Re: __builtin_cpow((0,0),(0,0))
  - From: Robert Dewar

Index Nav:	[Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav:	[Date Prev] [Date Next]	[Thread Prev] [Thread Next]