Mailman 3 November 2010 - NumPy-Discussion

Anyone with Core i7 and Ubuntu 10.04?
by Ian Goodfellow 09 Nov '10

09 Nov '10

I'm wondering if anyone here has successfully built numpy with ATLAS and a Core i7 CPU on Ubuntu 10.04. If so, I could really use your help. I've been trying since August (see my earlier messages to this list) to get numpy running at full speed on my machine with no luck. The Ubuntu packages don't seem very fast, and numpy won't use the version of ATLAS that I compiled. It's pretty sad; anything that involves a lot of BLAS calls runs slower on this 2.8 ghz Core i7 than on an older 2.66 ghz Core 2 Quad I use at work.

4 4

ANN: NumPy 1.5.1 release candidate 2
by Ralf Gommers 09 Nov '10

09 Nov '10

Hi, I am pleased to announce the availability of the second release candidate of NumPy 1.5.1. This is a bug-fix release with no new features compared to 1.5.0. Please test and report any issues on the numpy mailing list. If no new issues are reported, the final 1.5.1 release will follow in a week. Binaries, sources and release notes can be found at https://sourceforge.net/projects/numpy/files/. OS X binaries are not up yet, they should follow by tomorrow. Enjoy, Ralf

1 0

Stop program when getting a warning (invalid value encountered in sqrt)
by Jóan Petur Petersen 09 Nov '10

09 Nov '10

Hi, I have write quite a large program, but I occationally get the following warning message: Warning: invalid value encountered in sqrt The programs runs for several hours finding the hyperparameters of a Gaussian Process, but occationally this warning pop up. Maybe due tue rounding errors or maybe because some numbers become nan. Can I make the program stop instead of just giving a warning, so that I get a traceback to where it comes from? For example in IPython: In [4]: def test(): ...: np.sqrt(-1) ...: np.sqrt(-1) ...: In [5]: test() Warning: invalid value encountered in sqrt Warning: invalid value encountered in sqrt Gives the warning two times instead of stopping. Best regard, Jóan Petur Petersen

2 1

Trouble cloning numpy Github repo over HTTP
by Scott Sinclair 09 Nov '10

09 Nov '10

Hi, I'm behind a firewall that doesn't allow me to use the git protocol so I can't use the git:// URL. I see the following problem: $ git clone http://github.com/numpy/numpy.git numpy Initialized empty Git repository in /home/scott/external_repos/numpy/.git/ error: RPC failed; result=22, HTTP code = 417 I never have trouble cloning other repos off of Github over HTTP. See http://support.github.com/discussions/repos/4323-error-rpc-failed-result22-… Does anyone else see this problem? Thanks, Scott

3 4

Catching and dealing with floating point errors
by Skipper Seabold 09 Nov '10

09 Nov '10

I am doing some optimizations on random samples. In a small number of cases, the objective is not well-defined for a given sample (it's not possible to tell beforehand and hopefully won't happen much in practice). What is the most numpythonic way to handle this? It doesn't look like I can use np.seterrcall in this case (without ignoring its actual intent). Here's a toy example of the method I have come up with. import numpy as np def reset_seterr(d): """ Helper function to reset FP error-handling to user's original settings """ for action in [i+'='+"'"+d[i]+"'" for i in d]: exec(action) np.seterr(over=over, divide=divide, invalid=invalid, under=under) def log_random_sample(X): """ Toy example to catch a FP error, re-sample, and return objective """ d = np.seterr() # get original values to reset np.seterr('raise') # set to raise on fp error in order to catch try: ret = np.log(X) reset_seterr(d) return ret except: lb,ub = -1,1 # includes bad domain to test recursion X = np.random.uniform(lb,ub) reset_seterr(d) return log_random_sample(X) lb,ub = 0,0 orig_setting = np.seterr() X = np.random.uniform(lb,ub) log_random_sample(X) assert(orig_setting == np.seterr()) This seems to work, but I'm not sure it's as transparent as it could be. If it is, then maybe it will be useful to others. Skipper

3 9

LapackError:non-native byte order
by LittleBigBrain 09 Nov '10

09 Nov '10

Hi everyone, In my system '<' is the native byte-order, but unless I change the byte-order label to '=', it won't work in linalg sub-module, but in others works OK. I am not sure whether this is an expected behavior or a bug? >>> import sys >>> sys.byteorder 'little' >>> a.dtype.byteorder '<' >>> b.dtype.byteorder '<' >>> c=a*b >>> c.dtype.byteorder '=' >>> d=npy.linalg.solve(a, c) Traceback (most recent call last): File "<pyshell#20>", line 1, in <module> d=npy.linalg.solve(a, c) File "C:\Python27\lib\site-packages\numpy\linalg\linalg.py", line 326, in solve results = lapack_routine(n_eq, n_rhs, a, n_eq, pivots, b, n_eq, 0) LapackError: Parameter a has non-native byte order in lapack_lite.dgesv >>> cc=c.newbyteorder('<') >>> cc.dtype.byteorder '<' >>> d=npy.linalg.solve(a, cc) Traceback (most recent call last): File "<pyshell#46>", line 1, in <module> d=npy.linalg.solve(a, cc) File "C:\Python27\lib\site-packages\numpy\linalg\linalg.py", line 326, in solve results = lapack_routine(n_eq, n_rhs, a, n_eq, pivots, b, n_eq, 0) LapackError: Parameter a has non-native byte order in lapack_lite.dgesv >>> d=npy.linalg.solve(a.newbyteorder('='), c) >>> d.shape (2000L, 1000L) Thanks, LittleBigBrain

4 4

Solving Ax = b: inverse vs cholesky factorization
by Joon 08 Nov '10

08 Nov '10

Hi, I was wondering when it is better to store cholesky factor and use it to solve Ax = b, instead of storing the inverse of A. (A is a symmetric, positive-definite matrix.) Even in the repeated case, if I have the inverse of A (invA) stored, then I can solve Ax = b_i, i = 1, ... , n, by x = dot(invA, b_i). Is dot(invA, b_i) slower than cho_solve(cho_factor, b_i)? I heard calculating the inverse is not recommended, but my understanding is that numpy.linalg.inv actually solves Ax = I instead of literally calculating the inverse of A. It would be great if I can get some intuition about this. Thank you, Joon

5 8

updated 1.5.1 release schedule
by Ralf Gommers 08 Nov '10

08 Nov '10

Hi, Since we weren't able to stick to the original schedule for 1.5.1, here's a short note about the current status. There are two changes that need to go in before RC2: https://github.com/numpy/numpy/pull/11 https://github.com/numpy/numpy/pull/9 If no one has time for a review I'll commit those to 1.5.x by Tuesday and tag RC2. Final release should be one week after that, unless an RC3 is necessary. Cheers, Ralf

4 6

Solving Ax = b: inverse vs cholesky factorization
by Joon 08 Nov '10

08 Nov '10

Hi, I was wondering when it is better to store cholesky factor and use it to solve Ax = b, instead of storing the inverse of A. (A is a symmetric, positive-definite matrix.) Even in the repeated case, if I have the inverse of A (invA) stored, then I can solve Ax = b_i, i = 1, ... , n, by x = dot(invA, b_i). Is dot(invA, b_i) slower than cho_solve(cho_factor, b_i)? I heard calculating the inverse is not recommended, but my understanding is that numpy.linalg.inv actually solves Ax = I instead of literally calculating the inverse of A. It would be great if I can get some intuition about this. Thank you, Joon

1 0

OFFTOPIC: simple databases
by Renato Fabbri 08 Nov '10

08 Nov '10

Dear All, i want to find simple databases, like a 5 dimensional with more than 30 samples. i am having difficult times with this. where do you get them? all the best, rf -- GNU/Linux User #479299 skype: fabbri.renato

2 1

NumPy-Discussion November 2010