Mailman 3 October 2005 - SciPy-Dev

signm
by Nils Wagner Oct. 31, 2005

Oct. 31, 2005

Hi all, Can someone reproduce the following (wrong) result using newscipy w i t h o u t ATLAS [[ 4.37893189 +1.16931579j -10.35820234 -0.85562669j 22.88516273 +5.26136512j 10.29316548 +1.10228001j 8.41737971 +2.08144719j] [ -0.92449912 -0.38734485j 2.55899387 +0.31688062j -5.74188412 -1.87245744j -2.95587871 -0.35141682j -3.00842621 -0.7724415j ] [ -1.04771148 -0.4097215j 2.82256666 +0.33074828j -6.31761424 -1.96343222j -3.18685611 -0.37353876j -3.15301437 -0.80605845j] [ -2.09461007 -0.38040313j 4.48073743 +0.23575022j -9.78741206 -1.5465713j -3.92661581 -0.37607293j -2.4579986 -0.5714881j ] [ 0.91756308 +0.42099707j -2.63664054 -0.34995887j 5.93570303 +2.05662992j 3.13741039 +0.37967162j 3.30630428 +0.85330874j]] 0.4.3.1401 0.4.2_1407 It should be [[ 11.94933333 -2.24533333 15.31733333 21.65333333 -2.24533333] [ -3.84266667 0.49866667 -4.59066667 -7.18666667 0.49866667] [ -4.08 0.56 -4.92 -7.6 0.56 ] [ -4.03466667 1.04266667 -5.59866667 -7.02666667 1.04266667] [ 4.15733333 -0.50133333 4.90933333 7.81333333 -0.50133333]] Nils

1 0

Using doctest
by David M. Cooke Oct. 31, 2005

Oct. 31, 2005

I've added some tests for scipy.base.polynomial and scipy.base.ufunclike, but I used doctests instead of writing out something with unittest. They're run by using a test_suite(level) function in the appropriate test module. They were much easier to write than using the unittest API: copy-and- paste from my terminal window, mostly :-) I'm not familiar with the internals of scipy.test.testing, so I don't know if there's something I'm missing when setting them up. It does require Python 2.3 or higher to make a unittest test suite from the doctest, though. On another note: the shadowing of the scipy.test package by the scipy.test function can be annoying, especially if someone wants to reuse it. All usages of scipy.test.testing in scipy right now are of the form "from scipy.test.testing import *". But because of the test () function, you can't do "import scipy.test.testing as T" for instance, which is just plain confusing, and difficult for us in the "no-import-*" camp :-). Now, you can do "from scipy.test import testing as T", but that's not obvious. Personally, I'd suggest renaming the test() function to runtests(), but I can see how this is a problem considering the documentation, etc., about test. -- |>|\/|< /------------------------------------------------------------------\ |David M. Cooke http://arbutus.physics.mcmaster.ca/dmc/ |cookedm(a)physics.mcmaster.ca

3 6

NameError: global name 'nx' is not defined
by Nils Wagner Oct. 30, 2005

Oct. 30, 2005

====================================================================== ERROR: check_assoc_laguerre (scipy.special.basic.test_basic.test_assoc_laguerre) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/local/lib/python2.4/site-packages/scipy/special/tests/test_basic.py", line 527, in check_assoc_laguerre a1 = genlaguerre(11,1) File "/usr/local/lib/python2.4/site-packages/scipy/special/orthogonal.py", line 273, in genlaguerre p = orthopoly1d(x,w,hn,kn,wfunc,(0,inf),monic) File "/usr/local/lib/python2.4/site-packages/scipy/special/orthogonal.py", line 73, in __init__ poly1d.__init__(self, roots, r=1) File "/usr/local/lib/python2.4/site-packages/scipy/base/polynomial.py", line 372, in __init__ c_or_r = poly(c_or_r) File "/usr/local/lib/python2.4/site-packages/scipy/base/polynomial.py", line 70, in poly if isinstance(a.dtype, nx.complexfloating): NameError: global name 'nx' is not defined

2 1

A = mat(asarray(A)) versus A = asarray(A)
by Nils Wagner Oct. 30, 2005

Oct. 30, 2005

Hi all, I have used asarray(A) instead of mat(asarray(A)) in matfuncs.py. Now the tests concerning logm passed. For what reason ? # A = mat(asarray(A)) A = asarray(A) Nils

1 0

Easier now for extension writers to reuse type names
by David M. Cooke Oct. 30, 2005

Oct. 30, 2005

Alright, one thing that was bothering me was if you use arrayobject.h, and you're writing an extension that wraps some library, you may have a conflict with typedefs (Bool, intp, longlong, etc.). arrayobject.h is not such a good neighbour there. So, I've fixed up arrayobject.h and ufuncobject.h so that if the preprocessor symbol PY_ARRAY_TYPES_PREFIX is defined before they're imported, the typedefs in those header files define types prefixed with whatever the value of PY_ARRAY_TYPES_PREFIX is. Example: #define PY_ARRAY_TYPES_PREFIX PA_ #include "scipy/arrayobject.h" /* maybe this is in a header file for a library being wrapped */ typedef int Bool; This will work fine, as the typedef in arrayobject.h is instead typedef unsigned char PA_Bool; and all the PyArray API functions will be declared using PA_Bool instead within the module. This isn't a problem with calling the API, as the types are the same (just different names). This is analogous to PY_ARRAY_UNIQUE_SYMBOL used to store the API in a unique array. cheers! -- |>|\/|< /------------------------------------------------------------------\ |David M. Cooke http://arbutus.physics.mcmaster.ca/dmc/ |cookedm(a)physics.mcmaster.ca

1 0

newscipy, 64Bit, det problem
by Arnd Baecker Oct. 29, 2005

Oct. 29, 2005

Hi, as previously reported I get on the opteron (In [11]: scipy.__core_version__ Out[11]: '0.4.3.1385' In [12]: scipy.__scipy_version__ Out[12]: '0.4.2_1402' ): ====================================================================== FAIL: check_simple (scipy.linalg.basic.test_basic.test_det) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/abaecker/BUILDS2/Build_55/inst_scipy_newcore/lib/python2.4/site-pa ckages/scipy/linalg/tests/test_basic.py", line 273, in check_simple assert_almost_equal(a_det,-2.0) File "/home/abaecker/BUILDS2/Build_55//inst_scipy_newcore/lib/python2.4/site-p ackages/scipy/test/testing.py", line 649, in assert_almost_equal assert round(abs(desired - actual),decimal) == 0, msg AssertionError: Items are not equal: DESIRED: -2.0 ACTUAL: -0.0 The corresponding test routine is test_det def check_simple(self): a = [[1,2],[3,4]] a_det = det(a) assert_almost_equal(a_det,-2.0) Testing this line by line gives for: from scipy import * a = [[1,2],[3,4]] print type(a) linalg.det(a) the following: In [3]: a = [[1,2],[3,4]] In [4]: print type(a) <type 'list'> In [5]: linalg.det(a) Out[5]: -0.0 Interestingly the following gives the expected answer from scipy import * a = zeros( (2,2)) a[0,0]=1 a[0,1]=2 a[1,0]=3 a[1,1]=4 print type(a) linalg.det(a) In [7]: print type(a) <type 'scipy.ndarray'> In [8]: linalg.det(a) Out[8]: -2.0 Travis, does this help you in some way to understand what is going on? (Seems to be some list->array conversion problem ...) I'd guess that some of the other failures are of the same reason. Also note that the above works with newscipy on my laptop In [2]: a = [[1,2],[3,4]] In [3]: print type(a) <type 'list'> In [4]: linalg.det(a) Out[4]: -2.0 Best, Arnd

1 0

newscipy - special problems
by Arnd Baecker Oct. 29, 2005

Oct. 29, 2005

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'

2 2

vectorize and arguments with default settings
by Ralf Ahlbrink Oct. 29, 2005

Oct. 29, 2005

Hello! With the old scipy_core vectorize-ing functions, which have arguments with default settings, was possible. In the newcore (up to the current rev. 1386) the code is introspected, but default settings are not taken into account. I've attached a patch. Ralf.

2 1

Re: [SciPy-dev] [matplotlib-devel] new scipy and numerix
by Travis Oliphant Oct. 29, 2005

Oct. 29, 2005

Darren Dale wrote: >I was wondering, has anyone looked into extending numerix to handle the new >scipy? All scipy tests now pass on my 32bit system, but there is some >incompatibility between new scipy and mpl. For example: > >from pylab import * >from scipy import * >plot(linspace(-1,1,100)) >show() > > Which version of Numeric do you have? Currently you need Numeric 24.0 to use matplotlib with scipy. Numeric 24.0 uses the array interface to convert scipy arrays. If you do have the latest version. What problems are you seeing? I think the array interface is a better way to go then the numerix approach. John Hunter has indicated that he will eventually move to requiring newcore for matplotlib. I would rather push that direction, then have a messy 3-way numerix maintenance. -Travis

2 1

patch for minpack.py Newton
by Ryan Krauss Oct. 28, 2005

Oct. 28, 2005

I am using the Newton algorithm in minpack.py to find the roots of a complex expression. This seems to work correctly, but the error raised if it doesn't convert wasn't written with the possiblity of complex expressions in mind. I have changed the ending of the newton function (line 330) from raise RuntimeError, "Failed to converge after %d iterations, value is %f" % (maxiter,p) to if type(p) is complex: raise RuntimeError, "Failed to converge after %d iterations, value is %f%+fj" % (maxiter,real(p),imag(p)) else: raise RuntimeError, "Failed to converge after %d iterations, value is %f" % (maxiter,p) This just makes the function raise a more helpful error message. Otherwise it reads, error float is required. I made this change on my machine. Is it valuable and what is the procedure to make it part of scipy? And is it worth doing if I am not in the newscipy yet? Thanks, Ryan

2 2