Re: [PATCH, PR] Crash of Bessel functions at x==0!

[FranÃois Dumont <frs dot dumont at gmail dot com>]

Just a small remark, in bessel_function.tcc, the following:

+      if (__x == _Tp(0))
+    {
+          if (__nu == _Tp(0))
+            return _Tp(1);
+          else if (__nu == _Tp(1))
+            return _Tp(0);
+          else
+            return _Tp(0);
+    }

could be simplified into

+      if (__x == _Tp(0))
+        return (__nu == _Tp(0)) ? _Tp(1) : _Tp(0);


Even if the compiler will surely do so itself.

FranÃois


On 02/08/2013 05:09 AM, Ed Smith-Rowland wrote:
> On 02/07/2013 09:44 AM, Ed Smith-Rowland wrote:
> > On 02/07/2013 06:45 AM, Paolo Carlini wrote:
> > > Hi,
> > >
> > > On 02/07/2013 04:34 AM, Ed Smith-Rowland wrote:
> > > > All,
> > > >
> > > > This patch catches cyl_bessel_i, and cyl_bessel_j returning -nan 
> > > > for zero argument.  Not sure how i missed that.
> > > >
> > > > Anyhow, this patch cleans that up.
> > > > Also, spurious const is removed from numeric arguments of internal 
> > > > functions throughout the TR1 special maths.
> > > These two hunks look straightforward and can certainly go in now. 
> > > Thanks.
> > > > Also, a better asymptotic treatment of Bessel functions is supplied.
> > > This one worries me a bit: we don't want to introduce regressions on 
> > > some less known platform at this stage. Can we delay it to post 
> > > 4.8.0? 4.8.1 would be also fine. 
> > I get it.  I'll split this off.  I'd like a unit test on this myself.
> > > By the way, in general, in __cyl_bessel_jn_asymp and in other 
> > > places, something like an hardcoded 1000, without a comment, without 
> > > a specific analysis explaing why 1000 instead of 100 or 10000 is 
> > > something we should really, really, really, avoid. At minimum, if we 
> > > can't do better in terms of analyzing the behavior of each specific 
> > > algorithm, those constants should be given a name (likely bundled 
> > > together in sets), be documented in the docs to enable the users to 
> > > change the values away from the defaults.
> > I agree.  The math special functions are going to get a working on 
> > these and other issues.  Then my goal is to proceed, for 4.9 of 
> > course, with ISO/IEC 29123 - basically adding these functions to 
> > namespace std, versioned, and guarded with a macro as described 
> > inhttp://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3060.pdf.
> > <http://www.open-std.org/jtc1/sc22/wg21/docs/projects#29123>
> > > In any case, please remove the "// { dg-do compile }" from the 
> > > testcase: we want to *run* it (the default behavior), right? Also, 
> > > please try to follow the common format, have a separate function 
> > > with the tests, called by main, definining a test variable, etc, etc.
> > >
> > > Thanks!
> > > Paolo.
> Here is a reworked patch...  The asyptotic stuff is removed for now.
> Builds and tests cleanon x86_64-unknown-linux.