Problem in Hypergeometric functions with GSL

Dear ROOTers,

for the purposes of a multifit [which are irrelevant in this discussion] I have written down a function which contains the two solutions of the confluent hypergeometric equation: the Kummer’s function of the first kind M(a;b;z) [also denoted as 1_F_1(a;b;z)] and the Kummer’s function of the second kind, U(a;b;z).

To introduce these objects into my code, I leaned on the well-known GNU Scientific Library [GSL] where these two functions are implemented like this:

M(a;b;z) : double gsl_sf_hyperg_1F1 (double a, double b, double x) and,
U(a;b;z) : double gsl_sf_hyperg_U (double a, double b, double x).

Nevertheless, the fit fails for some, probably, serious reasons since for some logical values of a, b, and z the M and U seem to return irrational results.

For example for a = -1.5, b = 1.5, and z = -701.0, when calculating M, I take the followinq error message in my PC [I have the rather old version gsl-devel-1.5-2.rhel4]:

gsl: exp.c:256: ERROR: overflow
Default GSL error handler invoked.

while a collegue who has installed a more recent version of GSL [gsl-1.12-1.el5.rf.x86_64] takes the result 3.21333e+276!!! All these are totaly off value since the result, given by Mathematica, is simply 8259.38 . Also when I try to calculate U(11.14756, 0.5, 0.00175097) I face similar problems. [Usually I take the error message:

gsl: hyperg_U.c:121: ERROR: error
Default GSL error handler invoked.
Aborted ]

All these can be verified writing down the simple program:

// gsl_test.cpp

#include <gsl/gsl_sf_hyperg.h>

using namespace std;

int main()
cout << gsl_sf_hyperg_1F1(-1.5, 1.5, -701.0) << endl;
// OR ----> cout << gsl_sf_hyperg_U(11.14756, 0.5, 0.00175097) << endl;

So, I have the following simple quaestions:

  1. Can you confirm this as a bug?

  2. Do you know if these features are present in the more recent versions of GNU?

  3. Does anyone who have faced similar problems have managed to find a workaround?

  4. Does anyone knows another way to introduce M(a;b;z) and U(a;b;z) into my code that doesn’t share the same deficiencies?

[ I repeat: I only want to execute a Fit with Minuit and I want to be sure that the function that I use is accurate and gives logical results. For example it should be able to calculate accurately gsl_sf_hyperg_1F1(-1.5, 1.5, -701.0).]

Also, any other suggestion or advise might be extremely valuable…

Bast wishes and thank’s a lot a priori,

Hello, Leonidas.

  1. May be you should try Netlib ( )
    this helped me twice with unpredictable behaviour of GSL subroutines, but ways to make your program work may be not trivial
    a) either you have to write your own library in fortran, build it with gfortran and then link it with c/c++ code
    b) or generate c code from fortran with f2c (cant remember exactly why, but i didn’t like this way :slight_smile: )


I suspect there is a problem in GSL due to numerical overflow. I will investigate and eventually report to the author. I have checked also the latest version (1.13) and the problem is there. I will check also the fortran code from netlib.

Probably some asymptotic relations can be used for large negative values of x.
For negative x values but not too large ( x < -1 and x > -700) you can profit from the equation showed at (4) in … stKind.htm and write as workaround:

ROOT::Math::conf_hyperg(a,b, x) = exp( -x + log( ROOT::Math::conf_hyperg(b-a,b, -x) ) );

but for x = -701 you will get a numerical overflow in GSL.

Note that if you are using ROOT you can use the corresponding function in libMathMore (which are implemented using the GSL functions)
See … 875d860ecf

For the U(a,b,x) function I get results in agreement with Mathematica:

and using Mathematica I get HypergeometricU[11.14756, 0.5, 0.00175097] = 7.93064 E-8.

Best Regards


Hi Lorenzo,

thank’s a lot. Your reply was very illuminating. Nevertheless, I upgraded my GSL version to the 1.13 and, I believe, that the problems regarding the Tricomi confluent Hypergeometric function U persists. Just try to compute

I get an error message with gsl 1.13 . Please, can you check this also?



yes, for those values GSL reports an error due to a series not converging.
I will investigate it further, if an alternative implementation exists,

Best Regards


Hello all, I think these comments should be made.

Kummer’s function of the first kind 1_F_1(a, b, z)

GNU Scientific Libraries gives (I believe) right and extremely accurate results when both a, b are positive that makes one wonder why problems start to arise whenever a, in particular, becomes negative.

First case:
a = negative and non integer integer (e.g. -1.1 )
b = arbitrary (but allowed from the pole structure)
z < -500

[quote]GSL 1_F_1(-1.1, 1, -500) = 8.11565e+192
Mathematica = 891.627[/quote]

In this case the result can be built using an asymptotic relation as suggested by Lorenzo. I used this:

In my case the second branch of the expansion is very small, owing to the exponetial decay, and I neglect it. But, maybe the problem of the algorithm lies here since the $z^a-b$ is not defined in real numbers when z<0 (for generic values of a,b). This is strongly supported by the fact that for an integer a (negative or positive ) the code runs well. Since I’m not skilled in applied analysis I cannot know how such a term could arise when z<0, but I promise to consult a mathematical book when I’ll find some time.

Secons case:
a = negative integer
b = positive integer
z > 500

e.g. 1_F_1(-1., 1., 500) then GSL outputs

gsl: gamma.c:769: ERROR: error
Default GSL error handler invoked.

This must (???) result from the effort to calculate $\Gamma(-1)$ in the asymptotic expansion above. Note that even if the gamma function is singular at -1, $1/ \Gamma(-1)$ has a definite limit: zero.

Tricomi Hypergeometric Function

The problems here arise when a<10 and z close to zero. This can be remedied with the expansion around zero: … /01/03/01/

The codes in both cases are very easy (a for loop) that’s why I don’t include them. Note however that one must add such a number of terms each time that it takes the leading order.

cheers, Leonidas

Hi Leonidas,

Thank you very much for your comments. I will include in the documentation of the function.
Did you try also with the latest release 1.14 ? I reported some of the problem top them and something should have been fixed.
I did not have yet time to investigate other implementations from Netlib like d9chu (Fortran) or the one provided by Cephes (, which is written in C. It would interesting to see if those implementations are better in these regions.

Best Regards


Hi Lorenzo,

no I haven’t tested the latest version of GSL. I didn’t knew that that it was available, but I will do it soon enough. I haven’t also checked other implementations of M(a,b,z) and U(a,b,z) but I wouldn’t be surprised if they would be able to provide the right answers.

In the case of M(a,b,z) especially, it’s rather surprising for me to see that GSL calculates easily

but fails when a becomes non-integer.

The asymptotic behaviour of M is dominated by z. So if an overflow takes place this should originate from the value of z, not a. That makes me confident that it should be just a silly bug, nothing else.

Of course, I can be mistaken.

Best regards

If you have any outstanding bug reports, do please also post the test cases to . Thank you – Brian Gough (GSL Maintainer).

Hello all,
only to correct some silly typing mistakes I’ve made.

First, the Tricomi Hypergeometric fails sometimes when a>8 and z close to zero.

Second, GSL can calculate easily

but fails in the cases

Special thanks to collegues bring these errors to my attention.

Hello, I am coming quite late to this thread; but I thought I would give it a try.
I am trying to fix some things in the Confluent Hypergeometric 1F1, U implementations in GSL and would appreciate information/feedback/testing and problems.
Some of the previous problems have been fixed already and I thought I had cleared out the problems with U() but
./gsl_cli U 9.50605 0.5 .000160903
still fails. I will look into it.
./gsl_cli 1F1 -1.5 1.5 -701.0
Still fails but is probably due to a Kummer Transform to take -701 to 701 which involves exp(-701) which could bomb. It should have an asymptotic solution.

I am presently working of 1F1 code, but let me know if you find other U() errors
Do not use the Kummer Transform on 1F1 when b<a<0 a,b negative integers. It is provably wrong but I hope to “fix” it; as much as finite machines and myself can manage.