Re: Aw: Re: TR1 Special Math
On Thu, 19 Nov 2015, Ed Smith-Rowland wrote: > Testing coverage is growing. > I starting to build check_inf tests for everyone (but they aren't in the > patch. > I'll look at musl to see how you do check_denorm, etc. FWIW, in glibc I've systematically put special cases and a representative range of input values in auto-libm-test-in (where the test inputs and mathematical results are finite, but possibly overflowing / underflowing) / libm-test.inc (where not all finite). Random test generation has also been done with both mpcheck and ad hoc scripts that put random inputs in auto-libm-test-in before regenerating auto-libm-test-out and running the testsuite, in order to find cases with large errors or spurious or missing exceptions (those cases then being added to auto-libm-test-in when the bugs are fixed). This all relies heavily on having MPFR / MPC support for the functions in question in order to compute the ideal correctly rounded results for all rounding modes (so if new functions were added to glibc, it would be a very good idea to add them to MPFR / MPC first). -- Joseph S. Myers jos...@codesourcery.com
Re: Aw: Re: TR1 Special Math
On 17/11/15 02:00, Ed Smith-Rowland wrote: On 11/16/2015 07:28 PM, Florian Goth wrote: Any particular pointers how I can help in improving the implementation? Immediately: I have a good patch with xfails where #include should inject into namespace std. That's probably a one liner in the makefiles that's better done in tree. That stuff kills me. The values checking and NaN checking is very good. there are several correctness bugs visible in the code. (e.g. sinc(inf) returning nan instead of 0.) so at least test all combinations of special numbers (+-0, +-inf, qnan, and possibly a few other points including subnormal, small normal large normal input, this helped me catch corner-case bugs in musl math lib). it would be nice to know something about the expected accuracy of these functions (some of them i'd guess to be hard to implement with low ulp errors).
Re: Aw: Re: TR1 Special Math
On 11/16/2015 07:28 PM, Florian Goth wrote: Hi all, just a quick note that I'm still around... Any particular pointers how I can help in improving the implementation? Cheers, Florian. Gesendet: Samstag, 14. November 2015 um 21:40 Uhr Von: "Ed Smith-Rowland" <3dw...@verizon.net> An: "Jonathan Wakely" Cc: libstdc++ , gcc-patches , "Florian Goth" Betreff: Re: TR1 Special Math On 11/14/2015 03:28 PM, Ed Smith-Rowland wrote: On 11/13/2015 11:20 AM, Ed Smith-Rowland wrote: On 11/13/2015 10:32 AM, Jonathan Wakely wrote: On 25 October 2015 at 20:48, Jonathan Wakely wrote: On 25 October 2015 at 17:46, Ed Smith-Rowland <3dw...@verizon.net> wrote: On 10/24/2015 11:38 PM, Jonathan Wakely wrote: On 8 May 2015 at 15:05, Ed Smith-Rowland <3dw...@verizon.net> wrote: On 05/07/2015 12:06 PM, Jonathan Wakely wrote: Hi Ed, The C++ committee is considering the http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4437.pdf proposal to make C++17 include the contents of ISO 29124:2010 (the special math functions from TR1 that went into a separate standard, not into C++11). What is the status of our TR1 implementation? Is it complete? Good enough quality to move out of the tr1 sub-dir? Even if N4437 isn't accepted for C++17 we could move things around to turn the TR1 code into an iso29124 implementation, do you think that would make sense? That would make absolute sense. I actually have a tree where I've done that. All the functions are in there (29124 removed the hypergeometric functions. I'd like to keep those as extensions. I have some bugfixes also. I have a better version of the Carlson elliptic functions (which are used in the 29124 elliptic functions). Ed Hi Ed, Florian, Here's a patch to re-use the TR1 math functions to implement IS 29124, what do you think of this approach? Ed, were you just going to copy the files and have duplicated code? We should probably uglify the names of the hypergeometric functions if they are not in the final standard. This doesn't include Florian's patch, which should be applied. (I want to get this done before stage 1 ends in a couple of weeks, so am posting this for review now, but I'll be unavailable for the next week or two and might not be able to actually commit anything until stage 3). Hi all! I am actually very aware of the stage 1 deadline and am working furiously! This patch adds the hypergeometric and confluent hypergeometric functions that were actually stricken fromTR29124. I actually had a mind to add those back especially since the confluent one is actually pretty stable in it's realm and is used in some statistics tests. I expect that some people have ventures to use both and so TR29129 would not be a full replacement for TR1 without them. I intend to post within the next few days. I have to realize that some of my hopes and dreams would be better done with these in tree! ;-) Thank you for lighting a fire Jonathan! Excellent, glad to hear you're on this, as you know the code and the specs, whereas I'm poking around blindly :-) Hi Ed, Have you been able to find enough time to work on this? Will you be able to make the stage 1 deadline tomorrow, and if not, do you think I should apply my patch to re-use the TR1 stuff? (We can apply Florian's bug fix to that as well). I'm going to post something in a few hours. OK, this is still testing but I wanted to get it in under the deadline. It is basically a combination of Jonathan's approach using TR1 (which I do for C++03) Plus the start of a new impl in bits. Plus patches from Florian. Ed The last patchwas missing some tests. I'm also going to bzip it - I realized it was huge. Immediately: I have a good patch with xfails where #include should inject into namespace std. That's probably a one liner in the makefiles that's better done in tree. That stuff kills me. The values checking and NaN checking is very good. Once this gets in we'll have all the functions in TR29124 and most of n3494 - A proposal to add special mathematical functions according to the ISO/IEC 8-2:2009 standard. I stuck the latter in namespace __gnu_cxx. We need test cases - especially ones that cross switches between different algorithms. I discovered while testing the Airy functions that I had a long standing bug that the x<2 and fractional order bessel functions were returning junk! Our Bessel functions are dodgy for nu >~ 50 - We need an Olver asymptotic expansion. Many one dimensional functions could use a fit (Checbyshev, polynomial, rational...). I still want general algorithms around so we have the tools to generate these magic numbers though. Where angels fear to tread... The special functions TRs punted on complex functions. I see no reason to deprive our users of some of these functions. The gamma function is easy and is actually standardized in C11 or somesuch. I threw in hankel functions of real argument like boost. I have most of an implementation for all the bessel functions for
Aw: Re: TR1 Special Math
Hi all, just a quick note that I'm still around... Any particular pointers how I can help in improving the implementation? Cheers, Florian. > Gesendet: Samstag, 14. November 2015 um 21:40 Uhr > Von: "Ed Smith-Rowland" <3dw...@verizon.net> > An: "Jonathan Wakely" > Cc: libstdc++ , gcc-patches , > "Florian Goth" > Betreff: Re: TR1 Special Math > > On 11/14/2015 03:28 PM, Ed Smith-Rowland wrote: > > On 11/13/2015 11:20 AM, Ed Smith-Rowland wrote: > >> On 11/13/2015 10:32 AM, Jonathan Wakely wrote: > >>> On 25 October 2015 at 20:48, Jonathan Wakely > >>> wrote: > On 25 October 2015 at 17:46, Ed Smith-Rowland <3dw...@verizon.net> > wrote: > > On 10/24/2015 11:38 PM, Jonathan Wakely wrote: > >> On 8 May 2015 at 15:05, Ed Smith-Rowland <3dw...@verizon.net> wrote: > >>> On 05/07/2015 12:06 PM, Jonathan Wakely wrote: > Hi Ed, > > The C++ committee is considering the > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4437.pdf > proposal to make C++17 include the contents of ISO 29124:2010 (the > special math functions from TR1 that went into a separate > standard, > not into C++11). > > What is the status of our TR1 implementation? Is it complete? Good > enough quality to move out of the tr1 sub-dir? > > Even if N4437 isn't accepted for C++17 we could move things > around to > turn the TR1 code into an iso29124 implementation, do you think > that > would make sense? > > >>> That would make absolute sense. > >>> I actually have a tree where I've done that. > >>> All the functions are in there (29124 removed the hypergeometric > >>> functions. > >>> I'd like to keep those as extensions. > >>> I have some bugfixes also. > >>> > >>> I have a better version of the Carlson elliptic functions (which > >>> are used > >>> in > >>> the 29124 elliptic functions). > >>> > >>> Ed > >>> > >> Hi Ed, Florian, > >> > >> Here's a patch to re-use the TR1 math functions to implement IS > >> 29124, > >> what do you think of this approach? Ed, were you just going to copy > >> the files and have duplicated code? > >> > >> We should probably uglify the names of the hypergeometric > >> functions if > >> they are not in the final standard. > >> > >> This doesn't include Florian's patch, which should be applied. > >> > >> (I want to get this done before stage 1 ends in a couple of > >> weeks, so > >> am posting this for review now, but I'll be unavailable for the next > >> week or two and might not be able to actually commit anything until > >> stage 3). > > Hi all! > > > > I am actually very aware of the stage 1 deadline and am working > > furiously! > > > > This patch adds the hypergeometric and confluent hypergeometric > > functions > > that were actually stricken fromTR29124. > > I actually had a mind to add those back especially since the > > confluent one > > is actually pretty stable in it's realm and is used in some > > statistics > > tests. > > I expect that some people have ventures to use both and so TR29129 > > would not > > be a full replacement for TR1 without them. > > > > I intend to post within the next few days. I have to realize that > > some of > > my hopes and dreams would be better done with these in tree! ;-) > > > > Thank you for lighting a fire Jonathan! > Excellent, glad to hear you're on this, as you know the code and the > specs, whereas I'm poking around blindly :-) > >>> Hi Ed, > >>> > >>> Have you been able to find enough time to work on this? > >>> > >>> Will you be able to make the stage 1 deadline tomorrow, and if not, do > >>> you think I should apply my patch to re-use the TR1 stuff? (We can > >>> apply Florian's bug fix to that as well). > >>> > >> I'm going to post something in a few hours. > >> > >> > > OK, > > > > this is still testing but I wanted to get it in under the deadline. > > It is basically a combination of Jonathan's approach using TR1 (which > > I do for C++03) > > Plus the start of a new impl in bits. > > Plus patches from Florian. > > > > Ed > > > > > The last patchwas missing some tests. > I'm also going to bzip it - I realized it was huge. > >
