Re: [Numpy-discussion] ANN: pyMIC v0.5 released
Hi Jerome, -Original Message- From: numpy-discussion-boun...@scipy.org [mailto:numpy-discussion- boun...@scipy.org] On Behalf Of Jerome Kieffer Sent: Friday, March 27, 2015 8:41 PM To: numpy-discussion@scipy.org Subject: Re: [Numpy-discussion] ANN: pyMIC v0.5 released Interesting project. How close is the C++ kernel needed from OpenCL kernels ? That depends a bit on what the kernel does. If the kernel implements something really like a dgemm, it is just calling MKL's dgemm routine and passing the parameters into the routine. If the kernel does more, you would need regular C/C++ coding (with whatever is needed) plus a threading model such as OpenMP and TBB. Is it directly portable ? I would say no, just because OpenCL does a lot in terms of parallelization of the kernel whereas pyMIC only gives you control over data transfer and passing control over to the coprocessor. Threading and SIMD vectorization then is done by the compiler and/or the programmers. I have tested my OpenCL code (via pyopencl) on the Phi and I did not get better performances than the dual-hexacore Xeon (i.e. ~2x slower than a GPU). What type of code are you offloading? Cheers, -michael Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen, Deutschland Sitz der Gesellschaft: Feldkirchen bei Muenchen Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk Registergericht: Muenchen HRB 47456 Ust.-IdNr./VAT Registration No.: DE129385895 Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Behavior of np.random.multivariate_normal with bad covariance matrices
On Sun, Mar 29, 2015 at 7:39 PM, Blake Griffith blake.a.griff...@gmail.com wrote: I have an open PR which lets users control the checks on the input covariance matrix. The matrix is required to be symmetric and positve semi-definite (PSD). The current behavior is that NumPy raises a warning if the matrix is not PSD, and does not even check for symmetry. I added a symmetry check, which raises a warning when the input is not symmetric. And added two keyword args which users can use to turn off the checks/warnings when the matrix is ill formed. So this would only cause another new warning to be raised in existing code. This is needed because sometimes the covariance matrix is only *almost* symmetric or PSD due to roundoff error. Thoughts? My only question is why is **exact** symmetry relevant? AFAIU A empirical covariance matrix might not be exactly symmetric unless we specifically force it to be. But I don't see why some roundoff errors that violate symmetry should be relevant. use allclose with floating point rtol or equivalent? Some user code might suddenly get irrelevant warnings. BTW: neg = (np.sum(u.T * v, axis=1) 0) (s 0) doesn't need to be calculated if cov_psd is false. - some more: svd can hang if the values are not finite, i.e. nan or infs counter proposal would be to add a `check_valid` keyword with option ignore. warn, raise, and fix and raise an error if there are nans and check_valid is not ignore. - aside: np.random.multivariate_normal is only relevant if you have a new cov each call (or don't mind repeated possibly expensive calculations), so, I guess, adding checks by default won't upset many users. Josef PR: https://github.com/numpy/numpy/pull/5726 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Rename arguments to np.clip and np.put
Hello everyone, What does the list think of renaming the arguments of np.clip and np.put to match those of ndarray.clip/put? Currently the signatures are np.clip(a, a_min, a_max, out=None) ndarray.clip(a, min=None, max=None, out=None) np.put(a, ind, v, mode='raise') ndarray.put(indices, values, mode='raise') (The docstring for ndarray.clip is incorrect, too). I suggest the signatures might be changed to this: np.clip(a, min=None, max=None, out=None, **kwargs) np.put(a, indices, values, mode='raise') We can still take care of the old argument names for np.clip using **kwards, while showing a deprecation warning. I think that would be fully back-compatible. Note this makes np.clip more flexible as only one of min or max are needed now, just like ndarray.clip. np.put is trickier to keep back-compatible as it has two positional arguments. Someone who called `np.put(a, v=0, ind=1)` would be in trouble with this change, although I didn't find anyone on github doing so. I suppose to maintain back-compatibility we could make indices and values keyword args, and use the same kwargs trick as in np.clip, but that might be confusing since they're both required args. Any opinions or suggestions? Allan ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Rename arguments to np.clip and np.put
On Mon, Mar 30, 2015 at 3:59 PM, Allan Haldane allanhald...@gmail.com wrote: Hello everyone, What does the list think of renaming the arguments of np.clip and np.put to match those of ndarray.clip/put? Currently the signatures are np.clip(a, a_min, a_max, out=None) ndarray.clip(a, min=None, max=None, out=None) np.put(a, ind, v, mode='raise') ndarray.put(indices, values, mode='raise') (The docstring for ndarray.clip is incorrect, too). I suggest the signatures might be changed to this: np.clip(a, min=None, max=None, out=None, **kwargs) np.put(a, indices, values, mode='raise') We can still take care of the old argument names for np.clip using **kwards, while showing a deprecation warning. I think that would be fully back-compatible. Note this makes np.clip more flexible as only one of min or max are needed now, just like ndarray.clip. np.put is trickier to keep back-compatible as it has two positional arguments. Someone who called `np.put(a, v=0, ind=1)` would be in trouble with this change, although I didn't find anyone on github doing so. I suppose to maintain back-compatibility we could make indices and values keyword args, and use the same kwargs trick as in np.clip, but that might be confusing since they're both required args. Ideally we would want the signature to show as you describe it in the documentation, but during the deprecation period be something like e.g. np.put(a, indices=None, values=None, mode='raise', **kwargs) Not sure if that is even possible, maybe with functools.update_wrapper? Jaime Any opinions or suggestions? Allan ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion -- (\__/) ( O.o) ( ) Este es Conejo. Copia a Conejo en tu firma y ayúdale en sus planes de dominación mundial. ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
