Hi, I cleaned most of the noise in the test output (only stats module and a few random ones left): https://github.com/rgommers/scipy/tree/testnoise Can someone please check this and confirm that this can go into trunk as well as 0.9.x? Especially for the scipy.special commit. There are a few warnings that I'll only silence in 0.9.x because they indicate actual problems or should be fixed elsewhere (like astype() in numpy: http://projects.scipy.org/numpy/ticket/1709). For the ComplexWarning filter, is it preferable to be really granular with linenos like warnings.filterwarnings('ignore', category=np.ComplexWarning, lineno=98) or just filter it out of the whole module? Thanks, Ralf
On Tue, Jan 11, 2011 at 8:32 AM, Ralf Gommers <ralf.gommers@googlemail.com>wrote:
Hi,
I cleaned most of the noise in the test output (only stats module and a few random ones left): https://github.com/rgommers/scipy/tree/testnoise Can someone please check this and confirm that this can go into trunk as well as 0.9.x? Especially for the scipy.special commit.
There are a few warnings that I'll only silence in 0.9.x because they indicate actual problems or should be fixed elsewhere (like astype() in numpy: http://projects.scipy.org/numpy/ticket/1709).
For the ComplexWarning filter, is it preferable to be really granular with linenos like
warnings.filterwarnings('ignore', category=np.ComplexWarning, lineno=98) or just filter it out of the whole module?
Are the complex warnings for things that could be easily fixed? Chuck
On Tue, Jan 11, 2011 at 11:44 PM, Charles R Harris < charlesr.harris@gmail.com> wrote:
On Tue, Jan 11, 2011 at 8:32 AM, Ralf Gommers <ralf.gommers@googlemail.com
wrote:
Hi,
I cleaned most of the noise in the test output (only stats module and a few random ones left): https://github.com/rgommers/scipy/tree/testnoise Can someone please check this and confirm that this can go into trunk as well as 0.9.x? Especially for the scipy.special commit.
There are a few warnings that I'll only silence in 0.9.x because they indicate actual problems or should be fixed elsewhere (like astype() in numpy: http://projects.scipy.org/numpy/ticket/1709).
For the ComplexWarning filter, is it preferable to be really granular with linenos like
warnings.filterwarnings('ignore', category=np.ComplexWarning, lineno=98) or just filter it out of the whole module?
Are the complex warnings for things that could be easily fixed?
After looking again, yes:
https://github.com/rgommers/scipy/commit/fdf18166. They were calls to fblas funcs with the wrong dtype, obscured a bit by subclassing the test classes. So the only ones left are for ndarray.astype(), which should be fixed in numpy. Ralf
On Wed, Jan 12, 2011 at 6:18 PM, Ralf Gommers <ralf.gommers@googlemail.com>wrote:
On Tue, Jan 11, 2011 at 11:44 PM, Charles R Harris < charlesr.harris@gmail.com> wrote:
On Tue, Jan 11, 2011 at 8:32 AM, Ralf Gommers < ralf.gommers@googlemail.com> wrote:
Hi,
I cleaned most of the noise in the test output (only stats module and a few random ones left): https://github.com/rgommers/scipy/tree/testnoise Can someone please check this and confirm that this can go into trunk as well as 0.9.x? Especially for the scipy.special commit.
There are a few warnings that I'll only silence in 0.9.x because they indicate actual problems or should be fixed elsewhere (like astype() in numpy: http://projects.scipy.org/numpy/ticket/1709).
For the ComplexWarning filter, is it preferable to be really granular with linenos like
warnings.filterwarnings('ignore', category=np.ComplexWarning, lineno=98) or just filter it out of the whole module?
Are the complex warnings for things that could be easily fixed?
After looking again, yes:
https://github.com/rgommers/scipy/commit/fdf18166. They were calls to fblas funcs with the wrong dtype, obscured a bit by subclassing the test classes. So the only ones left are for ndarray.astype(), which should be fixed in numpy.
What's the reason for the almost identical test_fblas.py files in lib/blas/tests and linalg/tests by the way? Ralf
On Wed, Jan 12, 2011 at 6:25 PM, Ralf Gommers <ralf.gommers@googlemail.com>wrote:
On Wed, Jan 12, 2011 at 6:18 PM, Ralf Gommers <ralf.gommers@googlemail.com
wrote:
On Tue, Jan 11, 2011 at 11:44 PM, Charles R Harris < charlesr.harris@gmail.com> wrote:
On Tue, Jan 11, 2011 at 8:32 AM, Ralf Gommers < ralf.gommers@googlemail.com> wrote:
Hi,
I cleaned most of the noise in the test output (only stats module and a few random ones left): https://github.com/rgommers/scipy/tree/testnoise Can someone please check this and confirm that this can go into trunk as well as 0.9.x? Especially for the scipy.special commit.
There are a few warnings that I'll only silence in 0.9.x because they indicate actual problems or should be fixed elsewhere (like astype() in numpy: http://projects.scipy.org/numpy/ticket/1709).
For the ComplexWarning filter, is it preferable to be really granular with linenos like
warnings.filterwarnings('ignore', category=np.ComplexWarning, lineno=98) or just filter it out of the whole module?
Are the complex warnings for things that could be easily fixed?
After looking again, yes:
https://github.com/rgommers/scipy/commit/fdf18166. They were calls to fblas funcs with the wrong dtype, obscured a bit by subclassing the test classes. So the only ones left are for ndarray.astype(), which should be fixed in numpy.
Actually, there's one left that may be a bug. It happens in linalg.qr(), the failing test is TestQR.test_random_complex() (and a similar one in decomp_schur). But I can't reproduce it standalone, only if I run all linalg tests. Could you perhaps have a look? The other ones I'd like your opinion on is the fitpack warnings below. Not sure what's going on there. Ralf Running unit tests for scipy NumPy version 1.5.1 NumPy is installed in /Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/numpy SciPy version 0.10.0.dev SciPy is installed in /Users/rgommers/Code/scipy/scipy Python version 2.6.4 (r264:75821M, Oct 27 2009, 19:48:32) [GCC 4.0.1 (Apple Inc. build 5493)] nose version 0.11.1 ....................................................................................................................................................................................................................K.............................................................................../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) ......................K..K......................................................................................................................................../Users/rgommers/Code/scipy/scipy/io/matlab/mio.py:232: FutureWarning: Using oned_as default value ('column') This will change to 'row' in future versions oned_as=oned_as) ............................................................................................................................................................................................................................................................................./Users/rgommers/Code/scipy/scipy/io/wavfile.py:31: WavFileWarning: Unfamiliar format bytes warnings.warn("Unfamiliar format bytes", WavFileWarning) /Users/rgommers/Code/scipy/scipy/io/wavfile.py:121: WavFileWarning: chunk not understood warnings.warn("chunk not understood", WavFileWarning) ...............................................................................................................................................................................................................................SSSSSS......SSSSSS......SSSS.................................................................S.................................................../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:125: ComplexWarning: Casting complex values to real discards the imaginary part Q, work, info = gor_un_gqr(qqr, tau, lwork=lwork, overwrite_a=1) ......................../Users/rgommers/Code/scipy/scipy/linalg/decomp_schur.py:72: ComplexWarning: Casting complex values to real discards the imaginary part result = gees(lambda x: None, a, lwork=result[-2][0], overwrite_a=overwrite_a) .....................................................................................................................................K.......................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................SSSSSSSSSSS................................................................................................................................................................K...............................................................K...........................................................................................................................................................KK...............................................................................................................................................................................................................................................................................................................................................................................................................................K.K........................................................................................................................................................................................................................................................................................................................................................................................K........K.........SSSSSSS............................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................S....................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................... ---------------------------------------------------------------------- Ran 4815 tests in 83.378s OK (KNOWNFAIL=12, SKIP=36) Out[1]: <nose.result.TextTestResult run=4815 errors=0 failures=0> What's the reason for the almost identical test_fblas.py files in
lib/blas/tests and linalg/tests by the way?
Ralf
On Wed, Jan 12, 2011 at 9:37 AM, Ralf Gommers <ralf.gommers@googlemail.com> wrote:
On Wed, Jan 12, 2011 at 6:25 PM, Ralf Gommers <ralf.gommers@googlemail.com> wrote:
On Wed, Jan 12, 2011 at 6:18 PM, Ralf Gommers <ralf.gommers@googlemail.com> wrote:
On Tue, Jan 11, 2011 at 11:44 PM, Charles R Harris <charlesr.harris@gmail.com> wrote:
On Tue, Jan 11, 2011 at 8:32 AM, Ralf Gommers <ralf.gommers@googlemail.com> wrote:
Hi,
I cleaned most of the noise in the test output (only stats module and a few random ones left): https://github.com/rgommers/scipy/tree/testnoise Can someone please check this and confirm that this can go into trunk as well as 0.9.x? Especially for the scipy.special commit.
Just a suggestion, Is it possible to use a module global DEBUG and silence the warnings only "if not DEBUG"? Then we would still have a chance to look at the warnings that the tests produce, even though they are silenced for the public. Josef
On 01/13/2011 11:01 AM, josef.pktd@gmail.com wrote:
On Wed, Jan 12, 2011 at 9:37 AM, Ralf Gommers <ralf.gommers@googlemail.com> wrote:
On Wed, Jan 12, 2011 at 6:25 PM, Ralf Gommers<ralf.gommers@googlemail.com> wrote:
On Wed, Jan 12, 2011 at 6:18 PM, Ralf Gommers <ralf.gommers@googlemail.com> wrote:
On Tue, Jan 11, 2011 at 11:44 PM, Charles R Harris <charlesr.harris@gmail.com> wrote:
On Tue, Jan 11, 2011 at 8:32 AM, Ralf Gommers <ralf.gommers@googlemail.com> wrote:
Hi,
I cleaned most of the noise in the test output (only stats module and a few random ones left): https://github.com/rgommers/scipy/tree/testnoise Can someone please check this and confirm that this can go into trunk as well as 0.9.x? Especially for the scipy.special commit.
Just a suggestion,
Is it possible to use a module global DEBUG and silence the warnings only "if not DEBUG"?
I would rather not: those are mostly bugs, and are platform dependent. Hiding it by default means we will not be aware of it for platforms we don't often use, cheers, David
On Wed, Jan 12, 2011 at 9:20 PM, David <david@silveregg.co.jp> wrote:
On 01/13/2011 11:01 AM, josef.pktd@gmail.com wrote:
On Wed, Jan 12, 2011 at 9:37 AM, Ralf Gommers <ralf.gommers@googlemail.com> wrote:
On Wed, Jan 12, 2011 at 6:25 PM, Ralf Gommers<ralf.gommers@googlemail.com> wrote:
On Wed, Jan 12, 2011 at 6:18 PM, Ralf Gommers <ralf.gommers@googlemail.com> wrote:
On Tue, Jan 11, 2011 at 11:44 PM, Charles R Harris <charlesr.harris@gmail.com> wrote:
On Tue, Jan 11, 2011 at 8:32 AM, Ralf Gommers <ralf.gommers@googlemail.com> wrote: > > Hi, > > I cleaned most of the noise in the test output (only stats module and a > few random ones left): https://github.com/rgommers/scipy/tree/testnoise > Can someone please check this and confirm that this can go into trunk > as well as 0.9.x? Especially for the scipy.special commit.
Just a suggestion,
Is it possible to use a module global DEBUG and silence the warnings only "if not DEBUG"?
I would rather not: those are mostly bugs, and are platform dependent. Hiding it by default means we will not be aware of it for platforms we don't often use,
I've been setting numpy.errstate context manager with kwargs for a monkey-patched numpy.testing.nosetester.NoseTester.test to suppress floating point warnings. And you could also do the same with warnings.catch_warnings/simplefilter if you *really* want to suppress all warnings. If you want to catch the numpy floating point errors in the stats distributions fit that are known, I think you could just use errstate there. This might cut down on some of the true noise. Skipper
Wed, 12 Jan 2011 18:18:12 +0800, Ralf Gommers wrote:
https://github.com/rgommers/scipy/commit/fdf18166. They were calls to fblas funcs with the wrong dtype, obscured a bit by subclassing the test classes. So the only ones left are for ndarray.astype(), which should be fixed in numpy.
np.array(1+2j).astype(np.float64) IMHO should still raise a ComplexWarning. Cast, even explicit, from complex to float should strictly speaking be undefined. One should do np.array(1+2j).real.astype(np.float64) to be explicit. -- Pauli Virtanen
On Wed, Jan 12, 2011 at 5:49 AM, Pauli Virtanen <pav@iki.fi> wrote:
Wed, 12 Jan 2011 18:18:12 +0800, Ralf Gommers wrote:
https://github.com/rgommers/scipy/commit/fdf18166. They were calls to fblas funcs with the wrong dtype, obscured a bit by subclassing the test classes. So the only ones left are for ndarray.astype(), which should be fixed in numpy.
np.array(1+2j).astype(np.float64)
IMHO should still raise a ComplexWarning. Cast, even explicit, from complex to float should strictly speaking be undefined. One should do
np.array(1+2j).real.astype(np.float64)
Isn't .astype always an explicit request to (down)cast ? np.array(1.).astype(int) np.array(1+2j).astype(int) I don't think numpy has any other function that casts to int for example. (round to closest integer and cast) Just for consistency of astype, astype looks a bit dangerous to use for downcasting, as substitute for real_if_close. Josef
to be explicit.
-- Pauli Virtanen
_______________________________________________ SciPy-Dev mailing list SciPy-Dev@scipy.org http://mail.scipy.org/mailman/listinfo/scipy-dev
participants (6)
-
Charles R Harris -
David -
josef.pktd＠gmail.com -
Pauli Virtanen -
Ralf Gommers -
Skipper Seabold