NumPy-Discussion

Download

[email protected]

October 2004

36 participants
42 discussions

dot!=matrixmultiply bug when dotblas is present
by Fernando Perez Oct. 1, 2004

Oct. 1, 2004

Hi all, I found something today a bit unpleasant: if you install numeric without any BLAS support, 'matrixmultiply is dot==True', so they are fully interchangeable. However, to my surprise, if you build numeric with the blas optimizations, they are NOT identical. The reason is a bug in Numeric.py. After defining dot, the code reads: #This is obsolete, don't use in new code matrixmultiply = dot and at the very end of the file, we have: # try to import blas optimized dot, innerproduct and vdot, if available try: from dotblas import dot, innerproduct, vdot except ImportError: pass Obviously this means that matrixmultiply is stuck with the _old_ definition of dot, and does not benefit from the blas optimizations. This is BAD, as for a 1024x1024 matrix the difference is staggering: planck[Numeric]> pylab In [1]: a=rand(1024,1024) In [2]: b=rand(1024,1024) In [3]: from IPython.genutils import timing In [4]: timing 1,dot,a,b ------> timing(1,dot,a,b) Out[4]: 0.55591500000000005 In [5]: timing 1,matrixmultiply,a,b ------> timing(1,matrixmultiply,a,b) Out[5]: 68.142640999999998 In [6]: _/__ Out[6]: 122.57744619231356 Pretty significant difference... The fix is trivial. In Numeric.py, at the very end of the file, this part: # try to import blas optimized dot, innerproduct and vdot, if available try: from dotblas import dot, innerproduct, vdot except ImportError: pass should read instead: # try to import blas optimized dot, innerproduct and vdot, if available try: from dotblas import dot, innerproduct, vdot matrixmultiply = dot #### <<<--- NEW LINE except ImportError: pass I just checked and the problem still exists in Numpy 23.4. Cheers, f

3 3

Re: [Numpy-discussion] random number facilities in numarray and main Python libs
by Faheem Mitha Oct. 1, 2004

Oct. 1, 2004

On Fri, 1 Oct 2004, Bruce Southey wrote: > Hi, > > I presume that you have R and can build the standalone library. I have > attached my SWIG Smath.i , the SWIG Smath_wrap.c and the > Smath.py files. With these last two files, you shouldn't need SWIG. > > Note that I have not touched the void functions here as I have yet to check > how these work in SWIG. Also, there are a few function in the R header that > are only headers. Eventually someone has to fixed these and add suitable > documentation in some package. I'm not sure what you mean by void functions. > If you have SWIG you can directly use the Smath.i file - while SWIG can take > a .h file directly it would not work in Python. So I just edited the header > file into a .i file. > > The following is my process using Linux (I don't know about other platforms): > > 0) Have swig installed and built the R math library > 1) $ swig -python Smath.i > 2) $ gcc -c Smath_wrap.c -I/usr/local/include/python2.3 > -I/home/bsouthey/Rproject/R-1.9.1/src/nmath > -I/home/bsouthey/Rproject/R-1.9.1/include > 3) $ ld -shared Smath_wrap.o -o _Smath.so -lm -lRmath > -L/home/bsouthey/Rproject/R-1.9.1/src/nmath/standalone > > Of course you must change the include (-I) and library (-L) paths to where > python lives and standard alone Rmath library lives. Thanks. I'm particularly interested in knowing how you interface with the random number generator at the top (Python) level. Can you supply an example? Specifically, I'm looking for the following method. 1) When C/C++ code called, reads seed from python random state. 2) Does its stuff. 3) Writes seed back to python level when it exits. R has this built it, but here one needs to build ones own mechanism. This is complicated by the fact that Numarray and the base Python random library use different RNG mechanisms, so one has to chose which one to use. Which one did you use? Faheem.

1 0