newscipy - special problems
![](https://secure.gravatar.com/avatar/beebe07772844149dcd47e23e5276e72.jpg?s=120&d=mm&r=g)
I installed newcore and newscipy on my laptop and run into two types of problems for scipy.test(10,10): a) linalg problems: Both test_cgemv and test_sgemv give a floating point exception. Defining aroun line 402 in site-packages/scipy/linalg/tests/test_fblas.py class test_cgemv: pass class test_sgemv: pass skips thoses tests and all other linalg related ones are ok. b) special problems The first one is: check_gdtrix (scipy.special.basic.test_basic.test_cephes) ... ok check_hankel1 (scipy.special.basic.test_basic.test_cephes) floating point exception If I comment out the following tests all other tests pass! - check_hankel1 cbesh_wrap1 - check_hankel1e cbesh_wrap1_e - check_hankel2 cbesh_wrap2 - check_hankel2e cbesh_wrap2_e - check_h1vp uses hankel1 - check_h2vp uses hankel1 - test_ive cbesi_wrap_e - test_jve cbesj_wrap_e - test_k0 test uses k0(0.1) and kv(0,0.1) - test_k0e _cephesmodule.c, direct - test_k1 _cephesmodule.c, direct - test_k1e _cephesmodule.c, direct - test_kv cbesk_wrap - test_kve cbesk_wrap_e - test_kvp uses kv - test_y0_zeros uses: specfun.cyzo(nt,kf,kc) - test_yve ? It looks as if most (all?) are coming from the amos_wrappers.c E.g.: For import scipy.special._cephes as cephes cephes.hankel1(1,1) I still see all printf's before the call of F_FUNC Py_complex cbesh_wrap1( double v, Py_complex z) { int n = 1; int kode = 1; int m = 1; int nz, ierr; Py_complex cy; printf("IN: cbesh_wrap1\n"); printf("v %e\n",v); printf("z %e\n",z.real); printf("z %e\n",z.imag); F_FUNC(zbesh,ZBESH)(CADDR(z), &v, &kode, &m, &n, CADDR(cy), &nz, &ierr); printf("IN2: cbesh 2 ...\n"); DO_MTHERR("hankel1:"); return cy; } Inserting some print's in zbesh.f shows that floating point exception happens here: print *, " in ZBESH1 C" BB=DBLE(FLOAT(I1MACH(9)))*0.5D0 print *, " in ZBESH1 D" At this point I am stuck - What could go wrong? Is there a way to compile this particular wrapper (or the whole cephes) without optimization to find out if this is a compiler bug? Best, Arnd SystemInfo: - debian sarge - gcc version 3.3.5 (Debian 1:3.3.5-13) - CPU information: getNCPUs has_mmx has_sse is_32bit is_Intel is_Pentium is_PentiumII is_PentiumIII is_i686 is_singleCPU ------ - In [2]: scipy.__core_version__ Out[2]: '0.4.3.1386' - In [4]: scipy.__scipy_version__ Out[4]: '0.4.2_1402'
![](https://secure.gravatar.com/avatar/4d021a1d1319f36ad861ebef0eb5ba44.jpg?s=120&d=mm&r=g)
Arnd Baecker wrote:
print *, " in ZBESH1 C" BB=DBLE(FLOAT(I1MACH(9)))*0.5D0 print *, " in ZBESH1 D"
Is the problem with i1mach? You could replace the line with BB=DBLE(2147483647)*0.5D0 or BB=DBLE(FLOAT(21477483647))*0.5D0 and see if that helps. The other problems may be ATLAS issues. Yes, it could be compiler optimization problems. Presumably distutils has a way to turn off compiler optimizations. You could compile the amos library manually without compiler optimizations and just place it in the build/tempYYYYY/ directory where it will be picked up by distutils. -Travis
![](https://secure.gravatar.com/avatar/beebe07772844149dcd47e23e5276e72.jpg?s=120&d=mm&r=g)
On Sat, 29 Oct 2005, Travis Oliphant wrote:
Arnd Baecker wrote:
print *, " in ZBESH1 C" BB=DBLE(FLOAT(I1MACH(9)))*0.5D0 print *, " in ZBESH1 D"
Is the problem with i1mach?
I don't think so (at least not directly) as BB=I1MACH(9) got me beyond that point.
You could replace the line with
BB=DBLE(2147483647)*0.5D0
also gets me beyond that point but then gets a floating point exception when calling CALL ZBKNU(ZNR, ZNI, FNU, KODE, NN, CYR, CYI, NZ, TOL, ELIM, ALIM) (whose code contains similarly DBLE(FLOAT(I1MACH(14)-1)) - but I did not follow this further ...)
or
BB=DBLE(FLOAT(21477483647))*0.5D0
leads to: ^ Integer at (^) too large error: Command "/usr/bin/g77 -Wall -fno-second-underscore -fPIC -O3 -funroll-loops -march=pentium3 -mmmx -msse -fomit-frame-pointer -malign-double -c -c Lib/special/amos/zbesh.f -o build/temp.linux-i686-2.3/Lib/special/amos/zbesh.o" failed with exit status 1
and see if that helps. > >
The other problems may be ATLAS issues.
Though that ATLAS works fine with "old" scipy and the corresponding debian packages. So I am not sure what to do about it ...
Yes, it could be compiler optimization problems. Presumably distutils has a way to turn off compiler optimizations.
That would be the nicest solution, I'd guess.
You could compile the amos library manually without compiler optimizations and just place it in the build/tempYYYYY/ directory where it will be picked up by distutils.
I will have to leave that for tomorrow (if I find a way how to do this - at first glance it was not obvious to me ...) Best, Arnd
participants (2)
-
Arnd Baecker
-
Travis Oliphant