From: steve on
program testjn
integer, parameter : dp = kind(1.d0)
real(dp) z
z = 2.4048255576957729_dp
print *, besjn(3,z)
end program testjn

If your compiler returns a value other than 0.19899990535769083,
you may want to contact your OS/compiler vendor.

--
steve
From: Arjen Markus on
On 26 feb, 06:56, steve <kar...(a)comcast.net> wrote:
> program testjn
>    integer, parameter : dp = kind(1.d0)
>    real(dp) z
>    z = 2.4048255576957729_dp
>    print *, besjn(3,z)
> end program testjn
>
> If your compiler returns a value other than 0.19899990535769083,
> you may want to contact your OS/compiler vendor.
>
> --
> steve

I had some very weird results - not only with this value of z, but
also with 2.1, 2.2, ..., 3.1

I will contact that particular vendor. (Not that I have had much use
for Bessel functions of late, but still!)

Regards,

Arjen
From: Arjan on
> If your compiler returns a value other than 0.19899990535769083,
> you may want to contact your OS/compiler vendor.

I added a loop of 1001 iterations to let z run from 0 to twice the
critical value shown (for readers unfamiliar with Bessel-functions,
2.4048255576957729_dp is the value where J_1(z) is 0). On MinGW/MSYS,
g95 and gfortran, this resulted in nice, smooth series for J_3(z),
with the exception of a spurious value 0 for z =
2.4048255576957729_dp. On linux, g95 gave the same result as on MinGW/
MSYS, but gfortran changed the 0 at z = 2.4048255576957729_dp into -
Infinity... On linux, ifort (11.0) and Portland (old version 6.1)
produced complete bogus series for all values of z, with a value 0 for
the critical z! Interestingly enough, these two compilers agreed on
their bogus...

It looks as if it is even worse than suggested in the first message!

A.
From: Arjan on
> If your compiler returns a value other than 0.19899990535769083,
> you may want to contact your OS/compiler vendor.

I added a loop of 1001 iterations to let z run from 0 to twice the
critical value shown (for readers unfamiliar with Bessel-functions,
2.4048255576957729_dp is the value where J_0(z) is 0). On MinGW/MSYS,
g95 and gfortran, this resulted in nice, smooth series for J_3(z),
with the exception of a spurious value 0 for z =
2.4048255576957729_dp. On linux, g95 gave the same result as on MinGW/
MSYS, but gfortran changed the 0 at z = 2.4048255576957729_dp into -
Infinity... On linux, ifort (11.0) and Portland (old version 6.1)
produced complete bogus series for all values of z, with a value 0 for
the critical z! Interestingly enough, these two compilers agreed on
their bogus...

It looks as if it is even worse than suggested in the first message!

A.
From: Arjen Markus on
On 26 feb, 11:09, Arjan <arjan.van.d...(a)rivm.nl> wrote:
> > If your compiler returns a value other than 0.19899990535769083,
> > you may want to contact your OS/compiler vendor.
>
> I added a loop of 1001 iterations to let z run from 0 to twice the
> critical value shown (for readers unfamiliar with Bessel-functions,
> 2.4048255576957729_dp is the value where J_0(z) is 0). On MinGW/MSYS,
> g95 and gfortran, this resulted in nice, smooth series for J_3(z),
> with the exception of a spurious value 0 for z =
> 2.4048255576957729_dp. On linux, g95 gave the same result as on MinGW/
> MSYS, but gfortran changed the 0 at z = 2.4048255576957729_dp into -
> Infinity... On linux, ifort (11.0) and Portland (old version 6.1)
> produced complete bogus series for all values of z, with a value 0 for
> the critical z! Interestingly enough, these two compilers agreed on
> their bogus...
>
> It looks as if it is even worse than suggested in the first message!
>
> A.

Ah, so that is what is special about z = 2.4048... :)

ifort requires dbesjn() instead of besjn() - apparently besjn() is not
recognised as a generic name.

I tried with ifort 11.0 and these changes - that worked fine (correct
value of J3(z) and some others) - but in the Intel Forum Les Neilson
reported a value of -Infinity for infort 11.1.

Regards,

Arj_e_n