Date: Thu, 30 May 2013 07:56:24 -0600 From: Warner Losh <imp@bsdimp.com> To: David Schultz <das@FreeBSD.ORG> Cc: Stephen Montgomery-Smith <stephen@missouri.edu>, freebsd-standards@freebsd.org, pfg@freebsd.org, freebsd-numerics@freebsd.org Subject: Re: standards/175811: libstdc++ needs complex support in order use C99 Message-ID: <A3633CF7-B0D3-4E09-88FC-1D40197C652C@bsdimp.com> In-Reply-To: <20130530064635.GA91597@zim.MIT.EDU> References: <201302040328.r143SUd3039504@freefall.freebsd.org> <510F306A.6090009@missouri.edu> <C5BD0238-121D-4D8B-924A-230C07222666@FreeBSD.org> <20130530064635.GA91597@zim.MIT.EDU>
next in thread | previous in thread | raw e-mail | index | archive | help
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 = <stephen@missouri.edu> 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=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?A3633CF7-B0D3-4E09-88FC-1D40197C652C>