[SciPy-dev] newscipy - special problems

[Arnd Baecker]

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'