standards/175811: libstdc++ needs complex support in order use C99

[Warner Losh]

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 at missouri.edu> wrote:
>> 
>>> We do really seem to have a lot of working code right now.  And the main
>>> barrier to commitment seems to be style issues.
>>> 
>>> 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.
>>> 
>>> 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.
>>> 
>>> 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.
>>> 
>>> 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.
>>> 
>>> Let's commit what we have, even if it isn't perfect.
>> 
>> 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?
>> 
>> 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.
> 
> 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