From owner-freebsd-standards@FreeBSD.ORG Thu May 30 13:56:27 2013 Return-Path: Delivered-To: freebsd-standards@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 6889F490 for ; Thu, 30 May 2013 13:56:27 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) by mx1.freebsd.org (Postfix) with ESMTP id 39694371 for ; Thu, 30 May 2013 13:56:27 +0000 (UTC) Received: by mail-ie0-f172.google.com with SMTP id 17so656652iea.31 for ; Thu, 30 May 2013 06:56:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=IORAOblq2wOwGWSdSoX5BpqP8LFSxOX+toid05IcPvk=; b=e8nMr/hInpTU66HYPqmSefZ4tnlkAST6k602doDyp97SE8LCA5DTHeUCdkKgCztsyH TmvlM9PiyhCuO+YgQRAhxBVD+8QozgEHGg4gthJn2Ka34tpUR34B2hIEpa+s3aFQTtSl AtlmBf/O3aKT94/gfnM4McS9zHVtpqWbtUe7taRNsBInuexppm1or3fhiPm84eUkN633 O8U9O/1Y3APl9f/XjZ5h+HkeyqfzxcE5JRcXsjhxWdi5Fiw/KSpAb0hvgGqo64xMKwRW WXD+Su/n0PsCXsTIeXLXixMej1xXFQRNkjDX515JSpfojI64JEq4kOPFEGx4rBY/SKAd TMjA== X-Received: by 10.50.25.4 with SMTP id y4mr3701347igf.111.1369922186925; Thu, 30 May 2013 06:56:26 -0700 (PDT) Received: from 53.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id ik6sm7054727igb.3.2013.05.30.06.56.25 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 30 May 2013 06:56:26 -0700 (PDT) Sender: Warner Losh Subject: Re: standards/175811: libstdc++ needs complex support in order use C99 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <20130530064635.GA91597@zim.MIT.EDU> Date: Thu, 30 May 2013 07:56:24 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201302040328.r143SUd3039504@freefall.freebsd.org> <510F306A.6090009@missouri.edu> <20130530064635.GA91597@zim.MIT.EDU> To: David Schultz X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQko0mRj1NS5YJj2oSKB9Gfc/Ognh/WvgQvY2jzRE6NP83ROYdngu/rsFyoEPo26SVS7eR7x Cc: Stephen Montgomery-Smith , freebsd-standards@freebsd.org, pfg@freebsd.org, freebsd-numerics@freebsd.org X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 13:56:27 -0000 On May 30, 2013, at 12:46 AM, David Schultz wrote: > On Fri, Feb 22, 2013, David Chisnall wrote: >> On 4 Feb 2013, at 03:52, Stephen Montgomery-Smith = wrote: >>=20 >>> We do really seem to have a lot of working code right now. And the = main >>> barrier to commitment seems to be style issues. >>>=20 >>> For example, I have code at http://people.freebsd.org/~stephen/ for = the >>> complex arctrig functions. And Bruce has clog available. And >>> presumably he has logl and atanl also available. >>>=20 >>> The last I heard about my code is Bruce asking for some style = changes. >>> However I really don't think I will have time to work on it until at >>> least the summer. And to be honest, style just isn't my thing. >>>=20 >>> I propose (a) that someone else takes over my code (and maybe = Bruce's >>> code) and make the style changes, or (b) that we get a little less = fussy >>> about getting it all just so right and start committing stuff. >>>=20 >>> Let me add that the code we have is already far superior than = anything >>> in Linux or NetBSD, who clearly didn't worry about huge numerical = errors >>> in many edge cases. Come on guys, let's start strutting our stuff. >>>=20 >>> Let's commit what we have, even if it isn't perfect. >>=20 >> Yes, please can this happen? We are currently on 31 test >> failures in the libc++ test suite on -HEAD, of which at least 18 >> are due to linker failures trying to find missing libm >> functions. We are very close to having a complete C++11 >> implementation, yet we are held up by the lack of C99 support, >> and we are held up there by style nits? >>=20 >> On behalf of core, please can we commit the existing code and >> worry about the style later? Given the expertise required to >> work on the libm functions, most of the people who are able to >> hack on the code have already read it and so concerns about >> consistency readability are somewhat misplaced. >=20 > I didn't see this thread until now, but coincidentally, I just > wrote tests and manpages for and committed Stephen's > implementations of most of the missing double/float complex > functions. I don't know the status of clog() or cpow(), but > murray@ has a patch to port the NetBSD versions, which I'm also > willing to commit given the unacceptable delays in producing > something better. I'm all for better progress... Thank you for your efforts. > I was wondering if you could explain a bit about what your goal is > here, though. Is there some kind of certification you are trying > to achieve? Why can't you just comment out the few missing > functions? You've been adamant about this issue ever since > joining the Project, even suggesting that we commit bogus > implementations just for the sake of having the symbols. I > completely agree with you that the lack of progress is > unacceptable, and I'm sorry I haven't had more time to work on > this stuff myself, but I also don't understand the source of your > urgency. More and more projects are refusing to work around our gridlock. We have = to report R each new release because they have taken out the checks for = the missing symbols. It is really an embarrassment to the project. We've = let the perfect be the enemy of the good. There are R scripts that run = elsewhere and not on FreeBSD. R is the one I know most about since I've = been using R a lot to crunch numbers for work, but there are others. The urgency is we'd like to have this stuff done for 10, if at all = possible. And if not done, then a lot closer to done than where we are = today. > The reason I'm asking is that I'm pushing to get a lot of stuff > into the tree quickly, but realistically, in the short term we're > only going to get 95% of the way there. I doubt good > implementations of complicated functions that nobody uses, such as > erfcl() and tgammal(), are going to appear overnight. Thus, I > would like to know whether the last 5% is needed quickly, and if > so, why. I'm all for getting everything we can into the tree that produces an = answer that's not perfect, but close. What's the error that would be = generated with the naive implementation of long double tgammal(long double f) { return tgamma(f); } But assuming that, for some reason, produces errors larger than = difference in precision between double and long double due to extreme = non-linearity of these functions, having only a couple of stragglers is = a far better position to be in than we are today. Warner=