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

[François Dumont]

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.
>