Re: [SciPy-Dev] postponing 0.9.0rc1 by one week
On Sun, Jan 16, 2011 at 3:59 PM, Ralf Gommers <ralf.gommers@googlemail.com> wrote:
Hi all,
There is still one release blocker for 0.9.0, the change in behavior of convolve/correlate. See the old_behavior keyword in correlate/convolve/correlate2d/convolve2d, and also http://projects.scipy.org/scipy/ticket/1301. Therefore the release of RC1 is postponed by one week. If anyone has time to look at this, that would be great.
Three other things that could be fixed as well are the following: 1. Medfilt test failure on linux 64-bit, see http://news.gmane.org/gmane.comp.python.scientific.devel. This will be marked as knownfail for this release if no one has time to investigate. 2. CorrelateComplex192 failures on Windows, see the other email I just sent. 3. Test warnings from interpolate and linalg, see below. Will just be filtered out for 0.9.0 unless they are fixed in time.
/Users/rgommers/Code/scipy/scipy/interpolate/fitpack2.py:673: UserWarning: The coefficients of the spline returned have been computed as the minimal norm least-squares solution of a (numerically) rank deficient system (deficiency=7). If deficiency is large, the results may be inaccurate. Deficiency may strongly depend on the value of eps. warnings.warn(message) ....../Users/rgommers/Code/scipy/scipy/interpolate/fitpack2.py:604: UserWarning: The required storage space exceeds the available storage space: nxest or nyest too small, or s too small. The weighted least-squares spline corresponds to the current set of knots. warnings.warn(message)
/Users/rgommers/Code/scipy/scipy/linalg/decomp_qr.py:91: ComplexWarning: Casting complex values to real discards the imaginary part qr, tau, work, info = geqrf(a1, lwork=lwork, overwrite_a=overwrite_a) /Users/rgommers/Code/scipy/scipy/linalg/decomp_qr.py:126: ComplexWarning: Casting complex values to real discards the imaginary part Q, work, info = gor_un_gqr(qqr, tau, lwork=lwork, overwrite_a=1)
These warnings come from the fact that lwork returned from a workspace query has the same dtype as the principal matrix, but when we call the computational routine it expects an integer value. A simple workaround is here: https://github.com/fabianp/scipy-svn/commit/5942b71bd321b0960fd179c9785273c2... Although it would be more correct to convert it also to integer, i.e., lwork = int(work[0].real) Fabian.
participants (1)
-
Fabian Pedregosa