bug-gsl
[Top][All Lists]
Advanced

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

Re: [Bug-gsl] value of gsl_sf_bessel_i0_scaled at 0


From: address@hidden
Subject: Re: [Bug-gsl] value of gsl_sf_bessel_i0_scaled at 0
Date: Thu, 12 Jul 2012 11:43:36 -0700

Sorry for multiple postings, but I've finally found out the source of the
problem. Contrary to the documentation, the gsl_sf_bessel_i0_scaled
function in GSL actually implements

  \exp(-|x|) (\sqrt{\pi}/\sqrt{2x}) I_{1/2}(x)

  See
http://www.wolframalpha.com/input/?i=exp%28-%7Cx%7C%29+%28sqrt%28pi%29%2Fsqrt%282x%29%29+BesselI%5B1%2F2%2C+x%5D

and not

  \exp(-|x|) \sqrt{\pi/(2x)} I_{1/2}(x)

  See
http://www.wolframalpha.com/input/?i=exp%28-%7Cx%7C%29+%28sqrt%28pi+%2F+2x%29%29+BesselI%5B1%2F2%2C+x%5D

Note that these are different, since 1/\sqrt{x} != \sqrt{1/x} for negative
x.

Victor

On Thu, Jul 12, 2012 at 9:59 AM, address@hidden <
address@hidden> wrote:

> After some experiments, I don't think it's a bug. In the documentation (
> http://www.gnu.org/software/gsl/manual/html_node/Regular-Modified-Spherical-Bessel-Functions.html),
>  gsl_sf_bessel_i0_scaled
> and gsl_sf_bessel_i0_scaled_e are defined as follows:
>
>   These routines compute the scaled regular modified spherical Bessel
> function of zeroth order, \exp(-|x|) i_0(x).
>
> where
>
>   i_l(x) = \sqrt{\pi/(2x)} I_{l+1/2}(x)
>
> If you use the formula for i_0(x) from the documentation, Wolfram Alpha,
> which is based on Mathematica, gives different values (-1 and 1) for one
> sided limits:
>
>
> http://www.wolframalpha.com/input/?i=lim+exp%28-%7Cx%7C%29+sqrt%28pi%2F%282x%29%29+BesselI%5B1%2F2%2C+x%5D+as+x+-%3E+0%2B
>
> However, assuming \sqrt(x) = i \sqrt(-x) for negative x, gives
>
> i_0(x) = \exp(-|x|) sinh(x) / x
>
> and i_0(0) = 1 which is consistent with the GSL implementation.
>
> Best regards,
> Victor
>
>
> On Wed, Jul 11, 2012 at 5:16 PM, address@hidden <
> address@hidden> wrote:
>
>> Hi All,
>>
>> Is there any particular reason that gsl_sf_bessel_i0_scaled(0) returns 1
>> instead of NaN, or is it a bug? The function has different one-sided limits
>> at 0 (-1 and 1).
>>
>> Thanks,
>> Victor
>>
>
>


reply via email to

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