![](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'