GNU Scientific Library - Bugs: bug #30885, nans from...
You are not allowed to post comments on this tracker with your current authentication level.
bug #30885: nans from gsl_sf_coulomb_wave_FG_e(1.2693881947287221e-07, 0.0, lam_F=37, lam_G=36)
Submitter: | -Deleted Account- <bjg> | ||
Submitted: | Fri 27 Aug 2010 10:48:31 AM UTC | ||
Category: | Runtime error | Severity: | 3 - Normal |
Operating System: | Status: | Confirmed | |
Assigned to: | None | Open/Closed: | Open |
Release: | 1.14 |
No files currently attached
Depends on the following items: None found
Items that depend on this one: None found
CC list is empty
No changes have been made to this item
Powered by Savane 3.13-02a9.
Corresponding source code
From: "Alexey A. Illarionov" <alexey.illarionov@gmail.com>
To: -email is unavailable-
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).