Mailman 3 October 2014 - SciPy-Dev

Documentation page on API
by Yuxiang Wang 14 Dec '14

14 Dec '14

(Sorry about sending this to the wrong list, scipy-user instead of scipy-dev, before; apologize to those who saw this twice) Hi all, I was reading through the link (http://docs.scipy.org/doc/scipy/reference/api.html#guidelines-for-importing…) and it mentioned that the first form is preferred over the second one under most circumstances: # first form from scipy import stats stats.lomax(...) # second form from scipy.stats import distributions distributions.lomax(...) I honestly think the second form is far more frequently used in the examples given in the document, for example: http://docs.scipy.org/doc/scipy/reference/tutorial/special.html http://docs.scipy.org/doc/scipy/reference/tutorial/integrate.html http://docs.scipy.org/doc/scipy/reference/tutorial/optimize.html http://docs.scipy.org/doc/scipy/reference/tutorial/interpolate.html http://docs.scipy.org/doc/scipy/reference/tutorial/fftpack.html Would you think it'd be better to update this link? -Shawn

2 2

Re: [SciPy-Dev] removing umfpack wrapper
by Robert Cimrman 23 Nov '14

23 Nov '14

On 11/12/2013 11:22 PM, Ralf Gommers wrote: > On Tue, Nov 12, 2013 at 10:20 AM, Robert Cimrman <cimrman3(a)ntc.zcu.cz>wrote: > >> Hi Ralf, >> >> On 11/10/2013 04:36 PM, Ralf Gommers wrote: >>> Hi all, >>> >>> This is long overdue, but I think it's time to remove the UMFPACK wrapper >>> before the next release. I'd like some feedback on how to do that and to >>> what package (if any) to point existing users. >>> >>> As for why to remove the wrapper, see: >>> https://github.com/scipy/scipy/issues/3002 >>> http://permalink.gmane.org/gmane.comp.python.scientific.user/20451 >>> Short summary: UMFPACK changed from a BSD-compatible license to GPL at >> some >>> point. >>> >>> The deprecation warning in sparse.linalg has been referring people to >>> scikits.umfpack until now, however that package has disappeared >> completely >>> as far as I can tell. I suspect it was in the old scikits svn repo and >> was >>> never moved before that was killed. The alternatives seems to be >> Pysparse ( >> >> I missed that the scikit was lost in transition... >> >> How much work would be to move it to the new site - move from SVN to git, >> and? >> I would be willing to do it, if there is interest. >> > > Hi Robert, I think the moving wouldn't be a lot of work (assuming svn > access can still be arranged). If you'd revive the scikit it's not a > one-time effort though - it's only useful if the code is being maintained > imho. That can still be low effort perhaps, but with reviewing some PRs, > maintenance releases, putting it on pypi, etc. I'd expect at least an hour > a week or so. > > Are there scikits.umfpack users now? Would it make sense to salvage > whatever is useful from the scikit and contribute it to pysparse instead? We are using it in sfepy as the default direct solver. It seems to me that the pysparse interface requires the input matrix to be in the LL (linked list) format, which is unfortunate for us, as we use CSR. The scipy (and former scikit) umfpack wrappers have used CSR, so no copies were necessary. (After all, I have created the original scipy wrappers to be used from sfepy in the first place...) So in case others are not interested in having the scikit, I can see two possible solutions from my perspective: either enhance pysparse interface to allow CSR as well, or move the wrappers to sfepy (which I maintain anyway, but swig -> cython conversion would be needed). Not sure yet which solution I prefer. Cheers, r. > Cheers, > Ralf >> >> Cheers, >> r. >> >>> http://pysparse.sourceforge.net) and PyUBlasExt ( >>> https://pypi.python.org/pypi/PyUblasExt). Scikits.sparse is dead(-ish) >> and >>> doesn't wrap umfpack it looks like. PyUBlasExt has something that looks >>> like a wrapper but for C++ (?). So can we refer people to pysparse? >>> >>> Other question: do we call Pysparse instead of scikits.umfpack when >>> available? And if so, by default or not? Or do we rip out everything that >>> sits under useUmfpack=True? >>> >>> Cheers, >>> Ralf

2 5

Expose Lapack for Cython
by Ian Henriksen 20 Nov '14

20 Nov '14

Hi all, I have put together pxd files that allow direct access from Cython to the the blas and lapack functions wrapped in scipy.linalg.blas and scipy.linalg.lapack. The idea is to make these low level functions available in Cython without the corresponding Python level function call that is necessary when using the wrappers already in SciPy. They are currently in my github repository https://github.com/insertinterestingnamehere/cylinalg. The approach is based on the gist https://gist.github.com/pv/5437087. I think this would be a good addition to SciPy since it is really only another interface to the wrappers that are already there. Where would be the best place to put this? Also, what sorts of tests should be included? Any other input is welcome too. Thanks! -Ian Henriksen

7 17

0.14.1 and 0.15.0 release schedule
by Ralf Gommers 04 Nov '14

04 Nov '14

Hi all, It's about time for a couple of releases. 0.14.1 fixes some regressions as well as a lot of test failures against numpy 1.9.0 (due to __numpy_ufunc__) removal. All known regressions are fixed now, so I plan to tag it this weekend. If there's anything really urgent that still needs to go in, please speak up. For 0.15.0 there are still 17 issues/PRs, but most of those we should be able to merge/fix relatively quickly. I propose the following release schedule: - beta 1: 16 Sep - release candidate 1: 4 Oct - release candidate 2: 18 Oct (if needed) - final release: 25 Oct Does that work for everyone? Are there issues/PRs that aren't under the 0.15.0 milestone but have to go in? Cheers, Ralf

7 13

ndimage reflect mode
by Matthew Brett 03 Nov '14

03 Nov '14

Hi, Sorry if this is a dumb question, but I just noticed some behavior of scipy.ndimage that surprised me: In [63]: oned = np.arange(1, 10, dtype=float) In [64]: scipy.ndimage.affine_transform(oned, [1], [-2], mode='reflect') Out[64]: array([ 2., 1., 1., 2., 3., 4., 5., 6., 7.]) OK so far. But this I was surprised by: In [68]: scipy.ndimage.affine_transform(oned, [1], [-2 - 1e-15], mode='reflect') Out[68]: array([ 2., 1., 2., 2., 3., 4., 5., 6., 7.]) Why did the third value turn from a 1 into a 2? I am missing something obvious? Matthew

2 2

[ANN - JOB] Assistant Researcher - Berkeley Institute for Data Science
by Fernando Perez 30 Oct '14

30 Oct '14

Hi all, the newly founded Berkeley Institute for Data Science is hiring researchers with a focus on open source tools for scientific computing, please see here for details: https://aprecruit.berkeley.edu/apply/JPF00590 Cheers, f -- Fernando Perez (@fperez_org; http://fperez.org) fperez.net-at-gmail: mailing lists only (I ignore this when swamped!) fernando.perez-at-berkeley: contact me here for any direct mail

1 0

[ANN] Python for Scientific Computing conference in Boulder, CO; April'15
by Fernando Perez 28 Oct '14

28 Oct '14

Hi folks, a colleague from NCAR in Boulder just sent me this link about a conference they are organizing in the spring: https://sea.ucar.edu/conference/2015 I figured this might be of interest to many on these lists. The actual call isn't up yet, so if you're interested, watch that site for an upcoming call when they post it (I'm not directly involved, just passing the message along). Cheers f -- Fernando Perez (@fperez_org; http://fperez.org) fperez.net-at-gmail: mailing lists only (I ignore this when swamped!) fernando.perez-at-berkeley: contact me here for any direct mail

1 0

Use vecLibFort instead of Accelerate?
by Sturla Molden 27 Oct '14

27 Oct '14

There is a library called vecLibFort that re-exports all the BLAS and LAPACK symbols in Accelerate with gfortran ABI: https://github.com/mcg1969/vecLibFort For scipy.linalg vecLibFort would solve several issues: - Special wrappers for Accelerate would no longer be needed and can be removed from the source. - For the new Cython layer, the fortranname bug in f2py would go away – the wrappers are no longer needed. - The sgemv AVX segfault in Mavericks is corrected for by calling sgemm when data are not 32 byte aligned. Sturla

4 32

Travis?
by Sturla Molden 26 Oct '14

26 Oct '14

I posted a WIP PR to SciPy but there is no Travis build. https://github.com/scipy/scipy/pull/4104 Do we use Travis on SciPy? (I should remember, but I don't.) Sturla

1 1

ANN: NumPy 1.9.1 release candidate
by Julian Taylor 26 Oct '14

26 Oct '14

Hi, We have finally finished the first release candidate of NumOy 1.9.1, sorry for the week delay. The 1.9.1 release will as usual be a bugfix only release to the 1.9.x series. The tarballs and win32 binaries are available on sourceforge: https://sourceforge.net/projects/numpy/files/NumPy/1.9.1rc1/ If no regressions show up the final release is planned next week. The upgrade is recommended for all users of the 1.9.x series. Following issues have been fixed: * gh-5184: restore linear edge behaviour of gradient to as it was in < 1.9. The second order behaviour is available via the `edge_order` keyword * gh-4007: workaround Accelerate sgemv crash on OSX 10.9 * gh-5100: restore object dtype inference from iterable objects without `len()` * gh-5163: avoid gcc-4.1.2 (red hat 5) miscompilation causing a crash * gh-5138: fix nanmedian on arrays containing inf * gh-5203: copy inherited masks in MaskedArray.__array_finalize__ * gh-2317: genfromtxt did not handle filling_values=0 correctly * gh-5067: restore api of npy_PyFile_DupClose in python2 * gh-5063: cannot convert invalid sequence index to tuple * gh-5082: Segmentation fault with argmin() on unicode arrays * gh-5095: don't propagate subtypes from np.where * gh-5104: np.inner segfaults with SciPy's sparse matrices * gh-5136: Import dummy_threading if importing threading fails * gh-5148: Make numpy import when run with Python flag '-OO' * gh-5147: Einsum double contraction in particular order causes ValueError * gh-479: Make f2py work with intent(in out) * gh-5170: Make python2 .npy files readable in python3 * gh-5027: Use 'll' as the default length specifier for long long * gh-4896: fix build error with MSVC 2013 caused by C99 complex support * gh-4465: Make PyArray_PutTo respect writeable flag * gh-5225: fix crash when using arange on datetime without dtype set * gh-5231: fix build in c99 mode Source tarballs, windows installers and release notes can be found at https://sourceforge.net/projects/numpy/files/NumPy/1.9.1rc1/ Cheers, Julian Taylor

1 0