Fun with Friedrich Bessel
in [Fortran]
|
From: Arjan on 26 Feb 2010 05:28 I ran the same test under Portlan-6.1 and ifort 11.0 for J_n(z), but now with n=0,1,2,3,4,5 and got bogus for all values of n. Apparently, Arjen is right in concluding that besjn is not recognized as generic name. A.
From: Les Neilson on 26 Feb 2010 06:31 "Arjen Markus" <arjen.markus895(a)gmail.com> wrote in message news:9f44196a-377a-43da-a292-84530440a3ab(a)g10g2000yqh.googlegroups.com... <snip>> > ifort requires dbesjn() instead of besjn() - apparently besjn() is not > recognised as a generic name. > According to the ifort Help All of the the dbes* and bes* functions are part of the ifport portability suite. The bes* functions are single precision, and the Dbes* functions are double precision. There didn't appear to be a generic form. Les
From: Arjen Markus on 26 Feb 2010 06:53 On 26 feb, 12:31, "Les Neilson" <l.neil...(a)nospam.co.uk> wrote: > "Arjen Markus" <arjen.markus...(a)gmail.com> wrote in message > > news:9f44196a-377a-43da-a292-84530440a3ab(a)g10g2000yqh.googlegroups.com... > <snip>> > > > ifort requires dbesjn() instead of besjn() - apparently besjn() is not > > recognised as a generic name. > > According to the ifort Help > All of the the dbes* and bes* functions are part of the ifport portability > suite. The bes* functions are single precision, and the Dbes* functions are > double precision. There didn't appear to be a generic form. > > Les Just checked: they are not part of the Fortran 90/95 standard, nor of the Fortran 2003 standard. So that is the reason current compilers disagree on the meaning of the name "besjn". But that leaves the rather odd variation in values of course ;). Regards, Arjen
From: steve on 26 Feb 2010 10:17 On Feb 26, 2:09 am, 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. It is indeed much worse. If you have this problem, then it may occur at every zero of J0(x). A longer explanation is http://gcc.gnu.org/ml/fortran/2010-02/msg00213.html In addition, all odd order Bessel functions will by -Inf. troutmask:kargl[217] cat testjn.c #include <stdio.h> #include <math.h> int main(void) { double z; int i, n; z = 2.4048255576957729; for (n = 2; n < 10; n++) printf("%d %e\n", n, jn(n,z)); return (0); } troutmask:kargl[218] cc -o z testjn.c -lm && ./z 2 4.317548e-01 3 -inf 4 4.069027e-02 5 -inf 6 3.247664e-03 7 -inf 8 7.495602e-05 9 -inf With the patch I posted to the gfortran list, one gets troutmask:kargl[215] ./z 2 4.317548e-01 3 1.989999e-01 4 6.474667e-02 5 1.638924e-02 6 3.404818e-03 7 6.006884e-04 8 9.216579e-05 9 1.251727e-05 -- steve
From: user1 on 27 Feb 2010 09:28
steve wrote: > On Feb 26, 2:09 am, 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. > > It is indeed much worse. If you have this problem, then it may > occur at every zero of J0(x). A longer explanation is > > http://gcc.gnu.org/ml/fortran/2010-02/msg00213.html > > In addition, all odd order Bessel functions will by -Inf. > > troutmask:kargl[217] cat testjn.c > #include<stdio.h> > #include<math.h> > > int > main(void) > { > double z; > int i, n; > > z = 2.4048255576957729; > for (n = 2; n< 10; n++) > printf("%d %e\n", n, jn(n,z)); > return (0); > } > troutmask:kargl[218] Solaris-o z testjn.c -lm&& ./z > 2 4.317548e-01 > 3 -inf > 4 4.069027e-02 > 5 -inf > 6 3.247664e-03 > 7 -inf > 8 7.495602e-05 > 9 -inf > > With the patch I posted to the gfortran list, one gets > > troutmask:kargl[215] ./z > 2 4.317548e-01 > 3 1.989999e-01 > 4 6.474667e-02 > 5 1.638924e-02 > 6 3.404818e-03 > 7 6.006884e-04 > 8 9.216579e-05 > 9 1.251727e-05 > > -- > steve Is it a gfortran problem or a system supplied library ? I got correct values (match above) using the Sun Studio compiler on OpenSolaris, and strange results using Sun Studio compiler on Linux. |