[Bug-gsl] [bug #30885] nans from gsl_sf_coulomb_wave_FG_e(1.2693881947287221e-07, 0.0, lam_F=37, lam_G=36)

[Brian Gough]

URL:
  <http://savannah.gnu.org/bugs/?30885>

                 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

    _______________________________________________________

Details:

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
coulomb_F_recur
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:

  <http://savannah.gnu.org/bugs/?30885>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/