bug-gsl
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-gsl] Confluent Hypergeometric 1F1 request


From: Patrick Alken
Subject: Re: [Bug-gsl] Confluent Hypergeometric 1F1 request
Date: Fri, 03 Oct 2014 09:12:44 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.8.0

I confess I'm not an expert on these functions, and have never used them in my work, and it doesn't look like other experts are involved in this discussion.

The two files you sent earlier - I added them to the bug tracker - do they contain a fix for all these bugs you've found, or is it an incomplete fix? I imagine implementing a highly robust code for these functions which handle all possible argument ranges would be a large task.

Patrick

On 10/02/2014 04:30 PM, Raymond Rogers wrote:
On 10/02/2014 02:16 PM, Patrick Alken wrote:
On 10/02/2014 12:11 PM, Raymond Rogers wrote:
I believe I have found some problems and perhaps a solution in the
1F1 code.
Could somebody (s) evaluate the following in Maple and Mathematica and
post the results?
1F1( -1, -2, -4)

The online Mathematica answer is: -1.000000000000000000000
Whereas GSL gives 0.0549469166662

If anybody is willing to discuss the calculation details; I would be
grateful.   I have reached a conclusion that should be double checked.

Ray

My mathematica says -1.

Let me give a short form of why GSL (and some other algorithms) go wrong.
Let b<a<0  be negative integers.  Then we have a finite sum (polynomial)
if x>0  or x<0 .  But in order to avoid certain calculation probems ; if
x<0 Kummers transform is applied M(a,b,x)=e^x M(b-a,b,-x)  .  Notice
that b<(b-a)<0 afterwards so the same summation is applied to M(b-a,b,x)
yielding another polynomial.
But if this were valid we could say.
e^x  =  ratio of two polynomials; which isn't true.






reply via email to

[Prev in Thread] Current Thread [Next in Thread]