On Thu, 9 Nov 2017, Hal Finkel wrote:
Forwarded Message
...
From Jim Thomas. I???ll leave it to you to forward this to Austin Group.
Hal is correct, and I think the response to him misses the
point that he raised.
Agreed.
What Hal was talking about was the fact
On Thu, 9 Nov 2017, Joseph Myers wrote:
On Thu, 9 Nov 2017, Hal Finkel wrote:
Thus, neither cabs, nor most other math.h/complex.h functions taking
floating-point inputs and producing a floating-point output, should ever
formally overflow (because even infinity lies within the represented
On 11/09/2017 05:43 PM, Joseph Myers wrote:
On Thu, 9 Nov 2017, Hal Finkel wrote:
Thus, neither cabs, nor most other math.h/complex.h functions taking
floating-point inputs and producing a floating-point output, should ever
formally overflow (because even infinity lies within the represented
On Thu, 9 Nov 2017, Hal Finkel wrote:
> Thus, neither cabs, nor most other math.h/complex.h functions taking
> floating-point inputs and producing a floating-point output, should ever
> formally overflow (because even infinity lies within the represented set), and
> so shouldn't set ERANGE
FYI
Forwarded Message
Subject:RE: complex.h functions and errno
Date: Thu, 9 Nov 2017 11:38:54 -0700
From: Barry Hedquist
Reply-To: b...@peren.com
Organization: Perennial, Inc
To: 'Jim Thomas' , 'David Keaton'
Hi, Geoff, Bruce, Joseph, et al.,
Thanks for responding! This is very informative. Let me attempt to
summarize...
1. It is not the intent of POSIX to restrict implementation choices here
made available by the C specification. Oversights aside, places where
POSIX intentionally restricts
BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//opengroup.org//NONSGML kigkonsult.se iCalcreator 2.18//
CALSCALE:GREGORIAN
METHOD:REQUEST
BEGIN:VTIMEZONE
TZID:America/New_York
X-LIC-LOCATION:America/New_York
BEGIN:STANDARD
DTSTART:20171105T02
TZOFFSETFROM:-0400
TZOFFSETTO:-0500
RDATE:20181104T02
Bruce Evans wrote, on 10 Nov 2017:
>
> The meta-rules in C99 and C11 are:
> - F.9p4 requires (math_errhandling & MATH_ERREXCEPT) != 0. (MATH_ERROR
> seems to be allowed, but is not normally.)
> - F.9p6 defines "overflow" to have normal semantics. In particular,
>
On Fri, 10 Nov 2017, Bruce Evans wrote:
> Hmm, POSIX has the caveat that functions might never see signaling NaNs
> since parameter passing might turn them into quiet NaNs (and raise an
> exception). I'm used to i387 floating point where this tends to always
So indeed does TS 18661-1
On Wed, 8 Nov 2017, Joseph Myers wrote:
On Wed, 8 Nov 2017, Bruce Evans wrote:
This is without Annex F (IEEE754/IOCmumble bindings). With Annex F,
Actually Annex G (F is for plain floating point types and G is for complex
floating point types).
cabs() is specified in terms of hypot() and
On Wed, 8 Nov 2017, Don Cragun wrote:
> Hi Hal,
> I agree with what others have already said in this thread, but I think
> there is a more basic issue at play here. In the example you provided:
> cabs(1.7e308+I*1.7e308);
> the multiplication is not being performed by the function. It is
11 matches
Mail list logo