[Top][All Lists]

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

[Bug-gsl] [bug #30885] nans from gsl_sf_coulomb_wave_FG_e(1.269388194728

From: Brian Gough
Subject: [Bug-gsl] [bug #30885] nans from gsl_sf_coulomb_wave_FG_e(1.2693881947287221e-07, 0.0, lam_F=37, lam_G=36)
Date: Fri, 27 Aug 2010 10:48:31 +0000
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv: Gecko/2009061118 Fedora/3.0.11-1.fc9 Firefox/3.0.11


                 Summary: nans from
gsl_sf_coulomb_wave_FG_e(1.2693881947287221e-07, 0.0, lam_F=37, lam_G=36)
                 Project: GNU Scientific Library
            Submitted by: bjg
            Submitted on: Fri 27 Aug 2010 11:48:31 AM BST
                Category: Runtime error
                Severity: 3 - Normal
        Operating System: 
                  Status: Confirmed
             Assigned to: None
             Open/Closed: Open
                 Release: 1.14
         Discussion Lock: Any



From: "Alexey A. Illarionov" <address@hidden>
To: address@hidden
Subject: [Bug-gsl] bug in gsl_sf_coulomb_wave_FG_e (gsl 1.14 compiled with   
 gcc 4.5.0)
Date: Wed, 25 Aug 2010 23:41:14 -0400

[1  <text/plain; UTF-8 (7bit)>]                                              
Hi guys,

It seems that I find a bug in gsl_sf_coulomb_wave_FG_e. For large values
of lambda and small values of x, with eta = 0 it produces nan values
without raising of the flag.

Here the sample cases (see attachment with example)
  gsl_sf_coulomb_wave_FG_e(0.,1.2693881947287221e-07, 37, 1, ...)
  gsl_sf_coulomb_wave_FG_e(0.,5.911135077240691e-07, 39, 1, ...)
  gsl_sf_coulomb_wave_FG_e(0.,6.118185507743884e-07, 40, 1, ...)
and lots of others.

It seems that the origin of the problem is at
function (call at coulomb.c:970), that return garbage-like big numbers
but the error flag is not raised.

Here since we are interested only in unnormalized values  we can makes a
workaround like checking if values greater than some number, renormalize
them to 1 for some value. But if this function is used elsewhere with
the need of normalized values, this workaround will produce problems there.

Unfortunately I don't have time right now to dig in more, I'll try look
at it at the weekend if the issue is not solved by that date.

P.S. I'm not sure, but for me at this values of arguments (x <<
x_{turning_point}) using series approximation directly is more adequate
(if we do not consider G and Gp which I'm not sure how to deal).


Reply to this item at:


  Message sent via/by Savannah

reply via email to

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