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

[Raymond Rogers]

Thanks for reminding me about the testing.  I fixed the Confluent 
Hypergeometric U() errors for my tests; but neglected to revise 
test_hyperg.c by killing the U() fixme's.  I have now done that and the 
tests all succed for U().  I will send you the modified test_hyperg.c; 
the other file hyperg_U.c  is unchanged.  It should be reviewed and 
double checked on another system.  If it passes then somebody can take 
out the "fixme" for U() permanently.
I have done nothing for M() except try to find out where the egregious 
errors are and understand them.  I haven't even figured out how to fix 
the thing I mentioned below; I will probably try killing the Kummer 
Transform and see how bad the regular summation is with x<0 ; otherwise ...

Ray
On 10/03/2014 11:12 AM, Patrick Alken wrote:
> 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.

--
The primary use of conversation is to satisfy the impulse to talk
George Santanyana