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" <jwakely....@gmail.com>
Cc: libstdc++ <libstd...@gcc.gnu.org>, gcc-patches <gcc-patches@gcc.gnu.org>, "Florian
Goth" <captainsi...@gmx.de>
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 <jwakely....@gmail.com>
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 <math.h>
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 80000-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 fully
complex arg and order.
The Carlson elliptic functions work for complex right now.
I think I'm a couple branch cut selections of getting the classical
elliptic functions to work as well.
The zeta functions should work for large chunks of C.
Anything you hear in the wild in terms of new algorithms, usage of our
libraries, stress testing, etc.
Ed
