From owner-freebsd-standards@FreeBSD.ORG Mon Oct 24 11:02:19 2005 Return-Path: X-Original-To: freebsd-standards@freebsd.org Delivered-To: freebsd-standards@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 36AD516A41F for ; Mon, 24 Oct 2005 11:02:19 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id F1B9E43D45 for ; Mon, 24 Oct 2005 11:02:18 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j9OB2IIb062131 for ; Mon, 24 Oct 2005 11:02:18 GMT (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id j9OB2IDP062125 for freebsd-standards@freebsd.org; Mon, 24 Oct 2005 11:02:18 GMT (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 24 Oct 2005 11:02:18 GMT Message-Id: <200510241102.j9OB2IDP062125@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: freebsd-standards@FreeBSD.org Cc: Subject: Current problem reports assigned to you X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2005 11:02:19 -0000 Current FreeBSD problem reports Critical problems Serious problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2001/03/05] bin/25542 standards /bin/sh: null char in quoted string o [2002/12/13] kern/46239 standards posix semaphore implementation errors o [2003/04/21] standards/51209standards [PATCH] add a64l()/l64a/l64a_r functions o [2003/07/12] standards/54410standards one-true-awk not POSIX compliant (no exte o [2005/06/25] standards/82654standards C99 long double math functions are missin 5 problems total. Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2000/09/24] bin/21519 standards sys/dir.h should be deprecated some more o [2001/01/16] bin/24390 standards Replacing old dir-symlinks when using /bi s [2001/01/24] standards/24590standards timezone function not compatible witn Sin s [2001/06/18] kern/28260 standards UIO_MAXIOV needs to be made public p [2001/11/20] standards/32126standards getopt(3) not Unix-98 conformant s [2002/03/19] standards/36076standards Implementation of POSIX fuser command o [2002/06/14] standards/39256standards snprintf/vsnprintf aren't POSIX-conforman p [2002/08/12] standards/41576standards POSIX compliance of ln(1) o [2002/10/23] standards/44425standards getcwd() succeeds even if current dir has o [2002/12/09] standards/46119standards Priority problems for SCHED_OTHER using p o [2002/12/21] standards/46441standards /bin/sh does not do parameter expansion i o [2003/07/25] standards/54833standards [pcvt] more pcvt deficits o [2003/07/25] standards/54839standards [pcvt] pcvt deficits o [2003/07/31] standards/55112standards glob.h, glob_t's gl_pathc should be "size o [2003/09/05] standards/56476standards cd9660 unicode support simple hack o [2003/10/29] standards/58676standards grantpt(3) alters storage used by ptsname s [2004/02/14] standards/62858standards malloc(0) not C99 compliant o [2004/03/29] kern/64875 standards [patch] add a system call: fdatasync() o [2004/05/07] standards/66357standards make POSIX conformance problem ('sh -e' & o [2004/05/11] standards/66531standards _gettemp uses a far smaller set of filena o [2004/08/22] standards/70813standards [PATCH] ls(1) not Posix compliant o [2004/08/26] docs/70985 standards [patch] sh(1): incomplete documentation o o [2004/09/22] standards/72006standards floating point formating in non-C locales o [2005/03/20] standards/79055standards Add an IFS regression test for shells o [2005/03/20] standards/79056standards regex(3) regression tests o [2005/03/21] standards/79067standards /bin/sh should be more intelligent about a [2005/04/23] standards/80293standards sysconf() does not support well-defined u o [2005/05/20] standards/81287standards [PATCH]: fingerd(8) might send a line not o [2005/07/21] standards/83845standards [libm] [patch] add log2() and log2f() sup o [2005/08/18] standards/85080standards output of long double subnormals (with pr o [2005/08/18] standards/85090standards [patch] add memalign() and posix_memalign 31 problems total. From owner-freebsd-standards@FreeBSD.ORG Tue Oct 25 05:38:50 2005 Return-Path: X-Original-To: freebsd-standards@hub.freebsd.org Delivered-To: freebsd-standards@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D676916A41F; Tue, 25 Oct 2005 05:38:50 +0000 (GMT) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9584F43D53; Tue, 25 Oct 2005 05:38:50 +0000 (GMT) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j9P5cobj028966; Tue, 25 Oct 2005 05:38:50 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id j9P5codx028962; Tue, 25 Oct 2005 05:38:50 GMT (envelope-from linimon) Date: Tue, 25 Oct 2005 05:38:50 GMT From: Mark Linimon Message-Id: <200510250538.j9P5codx028962@freefall.freebsd.org> To: kevlo@FreeBSD.org, linimon@FreeBSD.org, freebsd-standards@FreeBSD.org Cc: Subject: Re: kern/64875: [libc] [patch] [feature request] add a system call: fdatasync() X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2005 05:38:51 -0000 Synopsis: [libc] [patch] [feature request] add a system call: fdatasync() State-Changed-From-To: open->suspended State-Changed-By: linimon State-Changed-When: Tue Oct 25 05:38:40 GMT 2005 State-Changed-Why: Mark as 'suspended' since this does not seem as though it is being actively worked on. http://www.freebsd.org/cgi/query-pr.cgi?pr=64875 From owner-freebsd-standards@FreeBSD.ORG Wed Oct 26 19:01:56 2005 Return-Path: X-Original-To: freebsd-standards@FreeBSD.ORG Delivered-To: freebsd-standards@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7668716A41F for ; Wed, 26 Oct 2005 19:01:56 +0000 (GMT) (envelope-from das@FreeBSD.ORG) Received: from VARK.MIT.EDU (VARK.MIT.EDU [18.95.3.179]) by mx1.FreeBSD.org (Postfix) with ESMTP id D95B543D46 for ; Wed, 26 Oct 2005 19:01:55 +0000 (GMT) (envelope-from das@FreeBSD.ORG) Received: from VARK.MIT.EDU (localhost [127.0.0.1]) by VARK.MIT.EDU (8.13.3/8.13.1) with ESMTP id j9QJ0FNF052816; Wed, 26 Oct 2005 15:00:15 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by VARK.MIT.EDU (8.13.3/8.13.1/Submit) id j9QJ0FPX052815; Wed, 26 Oct 2005 15:00:15 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Date: Wed, 26 Oct 2005 15:00:15 -0400 From: David Schultz To: Steve Kargl Message-ID: <20051026190015.GA52635@VARK.MIT.EDU> Mail-Followup-To: Steve Kargl , freebsd-standards@FreeBSD.ORG References: <20050929195552.GA14982@troutmask.apl.washington.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050929195552.GA14982@troutmask.apl.washington.edu> Cc: freebsd-standards@FreeBSD.ORG Subject: Re: complex.h math functions X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2005 19:01:56 -0000 On Thu, Sep 29, 2005, Steve Kargl wrote: > Is it permissible to implement the complex.h math > functions in terms of functions in math.h. For > example, if z = x + I * y, then > > cos(z) = cos(x) * cosh(y) - I sin(x) * sinh(y) > > This can be (naively?) implemented as > > double complex > ccos(double complex z) > { > double x, y; > x = creal(z); > y = cimag(y); > return (cosh(y) * (cos(x) - I * sin(x) * tanh(y))); > } > > I don't own a copy of C99, so I can't easily check > the wording of the standard. So I unfortunately don't have time to look into this right now, but I have a few brief comments. Yes, all of the complex.h functions can be implemented in terms of ordinary math.h functions that operate on the real and imaginary parts. However, with the exception of carg() and the functions already implemented in FreeBSD, implementing them this way could result in significant errors in corner cases. (For instance, underflow or overflow might occur at points near the real or imaginary axes.) On the other hand, doing better than this is no easy task. [1] describes for complex arcsine and arccosine what the troublesome cases are and how to do better. (You don't need to use all their funny `optimizations' involving exception handling.) That said, it's unclear whether we want to go through that much effort. I believe IBM is the only vendor to have put together reasonable implementations of the complex math functions. The GNU C library just uses trivial implementations of the complex math functions in terms of real math functions. In at least one case, the implementation is completely bogus, which gives you an idea of how much people are using this stuff at this point... In any case, I'm not up enough on this stuff to even remember what a complex arctangent is supposed to look like, nor do I have time to look into it right now. It's fine with me if you want to implement the remaining complex.h functions in terms of simple routines that use the real math routines that already exist. It would probably be a good idea to add a big XXX in the source pointing out that we could do better if someone has the inclination. --David [1] http://portal.acm.org/citation.cfm?id=275324 From owner-freebsd-standards@FreeBSD.ORG Thu Oct 27 05:04:31 2005 Return-Path: X-Original-To: freebsd-standards@freebsd.org Delivered-To: freebsd-standards@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 948E016A41F; Thu, 27 Oct 2005 05:04:31 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailout1.pacific.net.au (mailout1.pacific.net.au [61.8.0.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id E2EA943D45; Thu, 27 Oct 2005 05:04:30 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.0.86]) by mailout1.pacific.net.au (8.13.4/8.13.4/Debian-3) with ESMTP id j9R54T2f005424; Thu, 27 Oct 2005 15:04:29 +1000 Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailproxy1.pacific.net.au (8.13.4/8.13.4/Debian-3) with ESMTP id j9R54QVK022594; Thu, 27 Oct 2005 15:04:27 +1000 Date: Thu, 27 Oct 2005 15:04:26 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: David Schultz In-Reply-To: <20051026190015.GA52635@VARK.MIT.EDU> Message-ID: <20051027145316.Y23976@delplex.bde.org> References: <20050929195552.GA14982@troutmask.apl.washington.edu> <20051026190015.GA52635@VARK.MIT.EDU> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-standards@freebsd.org, Steve Kargl Subject: Re: complex.h math functions X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2005 05:04:31 -0000 On Wed, 26 Oct 2005, David Schultz wrote: > On Thu, Sep 29, 2005, Steve Kargl wrote: >> Is it permissible to implement the complex.h math >> functions in terms of functions in math.h. For >> example, if z = x + I * y, then >> >> cos(z) = cos(x) * cosh(y) - I sin(x) * sinh(y) >> >> This can be (naively?) implemented as >> ... >> return (cosh(y) * (cos(x) - I * sin(x) * tanh(y))); > > So I unfortunately don't have time to look into this right now, > but I have a few brief comments. Yes, all of the complex.h > functions can be implemented in terms of ordinary math.h functions > that operate on the real and imaginary parts. However, with the "all" == only the C99 ones. The bessel, erf and gamma families don't have any useful decomposition into real and imaginary parts AFAIK. > exception of carg() and the functions already implemented in > FreeBSD, implementing them this way could result in significant > errors in corner cases. (For instance, underflow or overflow > might occur at points near the real or imaginary axes.) On the > other hand, doing better than this is no easy task. We decided not to handle these cases better than ordinary complex multiplication. Even z*z is hard to implement perfectly, and gcc doesn't try. However, complex functions in the exp family are easier to handle than complex multiplication, since they only require real multiplication and no subtraction. In the above, the real and imaginary parts can be made accurate independently just by calculating the real functions accurately, and overflow is fairly easy to avoid using an frexp() format for exp(): cosh(y) * cos(x) ~ (1/2 * exp(y)) * cos(x) for large y = (1/2 * 2**N) * ((exp(y) / 2**N) * cos(x)) exp() already has the frexp()-like format internally and its last step is to add N to the exponent. It just needs a higher overflow threshold and its internals exported to work in the above (and extra precision for it and sin() and the last "*" for the final relative error to be < 1 ulp). The frexp() format is already needed to get an error of < 1 ulp for real cosh(): cosh(x) ~ 1/2 * exp(y) for large y = (1/2 * 2**N) * ((exp(y) / 2**N) but the actual implementation is: cosh(x) ~ 1/2 * exp(y) for large y = 1/2 * (exp(y/2)*exp(y/2)) which may have an error of up to 2.5 ulps, just like naive ccosh() for the non-overflow case. (Its actual max error for coshf() is more like 1.5 ulps). > [1] describes for complex arcsine and arccosine what the > troublesome cases are and how to do better. (You don't need to Thanks; I'll look at it. > The GNU > C library just uses trivial implementations of the complex math > functions in terms of real math functions. In at least one case, > the implementation is completely bogus, which gives you an idea of > how much people are using this stuff at this point... Cephes is better (much more complete and less bogus), but is still very inaccurate. But obviously not many people use even cos(), else the would notice that the error for i387 cos(x) near pi/2 is about 2**40 ulps :-). > In any case, I'm not up enough on this stuff to even remember what > a complex arctangent is supposed to look like, nor do I have time > to look into it right now. It's fine with me if you want to Complex inverse trig functions are simpler in some ways than real ones. They are all given by simple formulas involving other complex functions. E.g.: cacos(z) = -I*clog(z + csqrt(z*z - 1)) where the branches of log() and sqrt() must be chosen carefully. This might be easier to use than a power series, except near z == 1. Bruce