Mailman 3 December 2008 - SciPy-Dev

scipy.test() errors/failures
by Nils Wagner Dec. 5, 2008

Dec. 5, 2008

Hi all, Can someone reproduce these errors/failures ? I am using >>> scipy.__version__ '0.7.0.dev5221' >>> numpy.__version__ '1.3.0.dev6136' ====================================================================== ERROR: Testing that kmeans2 init methods work. ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.4/site-packages/scipy/cluster/tests/test_vq.py", line 147, in test_kmeans2_init data = data.reshape((200, 2)) ValueError: total size of new array must be unchanged ====================================================================== ERROR: Testing simple call to kmeans2 with rank 1 data. ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.4/site-packages/scipy/cluster/tests/test_vq.py", line 127, in test_kmeans2_rank1 data = data.reshape((200, 2)) ValueError: total size of new array must be unchanged ====================================================================== ERROR: Testing simple call to kmeans2 with rank 1 data. ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.4/site-packages/scipy/cluster/tests/test_vq.py", line 139, in test_kmeans2_rank1_2 data = data.reshape((200, 2)) ValueError: total size of new array must be unchanged ====================================================================== ERROR: This will cause kmean to have a cluster with no points. ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.4/site-packages/scipy/cluster/tests/test_vq.py", line 96, in test_kmeans_lost_cluster data = data.reshape((200, 2)) ValueError: total size of new array must be unchanged ====================================================================== ERROR: test_complex_write_read (test_mmio.TestMMIOCoordinate) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.4/site-packages/scipy/io/tests/test_mmio.py", line 290, in test_complex_write_read b = mmread(fn).todense() File "/usr/lib/python2.4/site-packages/scipy/io/mmio.py", line 52, in mmread return MMFile().read(source) File "/usr/lib/python2.4/site-packages/scipy/io/mmio.py", line 273, in read return self._parse_body(stream) File "/usr/lib/python2.4/site-packages/scipy/io/mmio.py", line 407, in _parse_body flat_data = flat_data.reshape(-1,4) ValueError: total size of new array must be unchanged ====================================================================== ERROR: read a hermitian matrix ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.4/site-packages/scipy/io/tests/test_mmio.py", line 213, in test_read_hermitian b = mmread(fn).todense() File "/usr/lib/python2.4/site-packages/scipy/io/mmio.py", line 52, in mmread return MMFile().read(source) File "/usr/lib/python2.4/site-packages/scipy/io/mmio.py", line 273, in read return self._parse_body(stream) File "/usr/lib/python2.4/site-packages/scipy/io/mmio.py", line 407, in _parse_body flat_data = flat_data.reshape(-1,4) ValueError: total size of new array must be unchanged ====================================================================== FAIL: read a general matrix ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.4/site-packages/scipy/io/tests/test_mmio.py", line 199, in test_read_geneal assert_array_almost_equal(a,b) File "/usr/lib/python2.4/site-packages/numpy/testing/utils.py", line 310, in assert_array_almost_equal header='Arrays are not almost equal') File "/usr/lib/python2.4/site-packages/numpy/testing/utils.py", line 295, in assert_array_compare raise AssertionError(msg) AssertionError: Arrays are not almost equal (mismatch 28.0%) x: array([[ 1.00000000e+00, 0.00000000e+00, 0.00000000e+00, 6.00000000e+00, 0.00000000e+00], [ 0.00000000e+00, 1.05000000e+01, 0.00000000e+00,... y: array([[ 1., 0., 0., 0., 0.], [ 0., 0., 0., 0., 0.], [ 0., 0., 0., 0., 0.],... ====================================================================== FAIL: read a skew-symmetric matrix ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.4/site-packages/scipy/io/tests/test_mmio.py", line 229, in test_read_skew assert_array_almost_equal(a,b) File "/usr/lib/python2.4/site-packages/numpy/testing/utils.py", line 310, in assert_array_almost_equal header='Arrays are not almost equal') File "/usr/lib/python2.4/site-packages/numpy/testing/utils.py", line 295, in assert_array_compare raise AssertionError(msg) AssertionError: Arrays are not almost equal (mismatch 24.0%) x: array([[ 1.00000000e+00, 0.00000000e+00, 0.00000000e+00, 0.00000000e+00, 0.00000000e+00], [ 0.00000000e+00, 1.05000000e+01, 0.00000000e+00,... y: array([[ 1., 0., 0., 0., 0.], [ 0., 0., 0., 0., 0.], [ 0., 0., 0., 0., 0.],... ====================================================================== FAIL: test_real_write_read (test_mmio.TestMMIOCoordinate) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.4/site-packages/scipy/io/tests/test_mmio.py", line 275, in test_real_write_read assert_array_almost_equal(a,b) File "/usr/lib/python2.4/site-packages/numpy/testing/utils.py", line 310, in assert_array_almost_equal header='Arrays are not almost equal') File "/usr/lib/python2.4/site-packages/numpy/testing/utils.py", line 295, in assert_array_compare raise AssertionError(msg) AssertionError: Arrays are not almost equal (mismatch 24.0%) x: array([[ 1.00000000e+00, 0.00000000e+00, 0.00000000e+00, 6.00000000e+00, 0.00000000e+00], [ 0.00000000e+00, 1.05000000e+01, 0.00000000e+00,... y: array([[ 1., 0., 0., 6., 0.], [ 0., 10., 0., 0., 0.], [ 0., 0., 0., 0., 0.],... ====================================================================== FAIL: test_sparse_formats (test_mmio.TestMMIOCoordinate) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.4/site-packages/scipy/io/tests/test_mmio.py", line 313, in test_sparse_formats assert_array_almost_equal(result, expected) File "/usr/lib/python2.4/site-packages/numpy/testing/utils.py", line 310, in assert_array_almost_equal header='Arrays are not almost equal') File "/usr/lib/python2.4/site-packages/numpy/testing/utils.py", line 295, in assert_array_compare raise AssertionError(msg) AssertionError: Arrays are not almost equal (mismatch 24.0%) x: array([[ 1., 0., 0., 6., 0.], [ 0., 10., 0., 0., 0.], [ 0., 0., 0., 0., 0.],... y: array([[ 1.00000000e+00, 0.00000000e+00, 0.00000000e+00, 6.00000000e+00, 0.00000000e+00], [ 0.00000000e+00, 1.05000000e+01, 0.00000000e+00,... ====================================================================== FAIL: test_imresize (test_pilutil.TestPILUtil) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.4/site-packages/numpy/testing/decorators.py", line 82, in skipper return f(*args, **kwargs) File "/usr/lib/python2.4/site-packages/scipy/misc/tests/test_pilutil.py", line 24, in test_imresize assert_equal(im1.shape,(11,22)) File "/usr/lib/python2.4/site-packages/numpy/testing/utils.py", line 174, in assert_equal assert_equal(len(actual),len(desired),err_msg,verbose) File "/usr/lib/python2.4/site-packages/numpy/testing/utils.py", line 183, in assert_equal raise AssertionError(msg) AssertionError: Items are not equal: ACTUAL: 0 DESIRED: 2 ---------------------------------------------------------------------- Ran 3460 tests in 159.021s FAILED (KNOWNFAIL=2, SKIP=17, errors=6, failures=5) <nose.result.TextTestResult run=3460 errors=6 failures=5> Nils

3 2

scipy.io.wav, data format convention
by David Cournapeau Dec. 5, 2008

Dec. 5, 2008

Hi, I wondered what would be the best data representation for audio data-related functionalities in scipy. Generally, since numpy uses "applying operation on last axis first", I thought it would make sense to use the representation of one channel / row. OTOH, I've just found out that scipy.io.wav does the contrary, and there is also the problem on how to deal with mono signals (column vector vs array) - as well as an efficiency question: most audio signals are interleaved (N consecutive samples in memory for signal with N channels), so the format of one column/channel is C-contiguous. I would like to keep audiolab as close as possible to whatever scipy will use, but I wondered if anyone thought about the issue at all ? cheers, David

3 3

ANN: SfePy 2008.4
by Robert Cimrman Dec. 4, 2008

Dec. 4, 2008

I am pleased to announce the release of SfePy 2008.4. SfePy (simple finite elements in Python) is a finite element analysis software based primarily on Numpy and SciPy. Mailing lists, issue tracking, mercurial repository: http://sfepy.org Home page: http://sfepy.kme.zcu.cz Major improvements: - framework for running parametric studies - greatly improved support for time-dependent problems - time derivatives of variables as term arguments - initial conditions via ics, ic_<number> keywords - live plotting using multiprocessing module - type of term arguments determined fully at run-time - new terms, namely piezo-coupling Applications: - enhanced acoustic band gaps code - dispersion analysis (polarization angle calculation) - applied load tensor computation - phase velocity computation for periodic perforated media with empty holes - improved schroedinger.py - plotting DFT iterations For more information on this release, see http://sfepy.googlecode.com/svn/web/releases/2008.4_RELEASE_NOTES.txt Best regards, Robert Cimrman

1 0

tagging 0.7rc1 this weekend?
by Jarrod Millman Dec. 4, 2008

Dec. 4, 2008

Hey, I would like to get 0.7.0 out ASAP. Is there any objection to tagging a release candidate this weekend? Are there any major regressions or release blockers that I should be aware of? Once we are ready to make 0.7.0rc1, I will create a 0.7.x branch and tag the rc1 from the branch. At that point the trunk will be open for 0.8 development and only bug-fixes will be allowed on the 0.7.x branch. Thanks, -- Jarrod Millman Computational Infrastructure for Research Labs 10 Giannini Hall, UC Berkeley phone: 510.643.4014 http://cirl.berkeley.edu/

10 16

Docs: it's not over yet! (and T-shirts)
by jh＠physics.ucf.edu Dec. 3, 2008

Dec. 3, 2008

Thanks to all the volunteers who have contributed docs in the Doc Marathon. The past month has seen an increase in activity, particularly for numpy.ma and the ufuncs. The PDF manual is now 445 pages. This is fantastic! But there's still much work to do. Here's the status of numpy documentation: State % Count Needs editing 38 374 Being written / Changed 30 296 Needs review 27 264 Needs review (revised) 2 20 Needs work (reviewed) 1 8 Reviewed (needs proof) 1 5 Proofed 3 26 Unimportant – 1488 So, while about 1/3 of the items have docs that someone thinks might be done ("Needs Review" or higher), 38% of the pages have not even been touched since the start of the marathon, including stuff in fft, lots more in ma, even some ndarray pages. Like these functions? Use them? Want others to use them? I hope that the semester/holiday break is a good chance for everyone to write some more. You don't need to be a developer to pitch in, just go to docs.scipy.org, click into the editing wiki, read the front page and guidelines, make a wiki name, and email this list to get edit privileges. There's a link to the source code on each function's doc wiki page, so you can easily refer to it when writing. We promised a cool T-shirt to everyone who has written 1000 words on the doc wiki. As of a few weeks ago, I think we are caught up on sending shirts out. If you think you should get a shirt but haven't, please email me (off list). Thanks! --jh-- Prof. Joseph Harrington Department of Physics MAP 414 4000 Central Florida Blvd. University of Central Florida Orlando, FL 32816-2385 (407) 823-3416 voice (407) 823-5112 fax (407) 823-2325 physics office jh(a)physics.ucf.edu

3 3

Fwd: scipy/lapack
by Charles سمير Doutriaux Dec. 3, 2008

Dec. 3, 2008

Just forwarding, maybe a more general way could be implemented? or at least an option for lapack3.2 Here's what's happening We have no lapack/blas on the system we built numpy (1.2.1 i believe) now we're trying to build scipy using LAPACK_SRC / BLAS_SRC But we downloaded LAPACK 3.2 it seems as the name of the source files is hardcoded somewhere at the numpy level and in 3.2 there's a lot of new source files. Any clues on this? (in the mean time we're building with 3.1) C. Begin forwarded message: > From: Bob Drach <drach(a)llnl.gov> > Date: December 3, 2008 2:04:35 PM PST > To: Bob Drach <drach(a)llnl.gov> > Cc: Charles Doutriaux <doutriaux1(a)llnl.gov> > Subject: Re: scipy/lapack > > numpy.distutils.system_info is hardwired for lapack 3.1. It has a > list of the routines to build which differ from 3.2. This module is > used by scipy to figure out which sources to build. There's no way > it would build with lapack 3.2 that I can see. I'm rebuilding from > scratch with blas and lapack enabled to see the current repository > version works. > > lapack-lite has the same functions as lapack, without the html and > man pages. So I'm happy with that if it works. > > Bob > > > > On Dec 2, 2008, at 7:10 PM, Bob Drach wrote: > >> Hi Charles, >> >> Do you know a straightforward way to build a usable scipy.linalg >> module? I don't care about having optimized Atlas libraries, etc. >> >> Bob >

1 0

two tickets with patches
by Jarrod Millman Dec. 3, 2008

Dec. 3, 2008

There are two tickets that contain donated code, which have been sitting around for over a year or more: http://scipy.org/scipy/scipy/ticket/354 http://scipy.org/scipy/scipy/ticket/457 I would like to see at least some comments on them about why they haven't been accepted. They are both first attempts but no one has made any critical comments or useful suggestions for what the authors need to do in order to have their code accepted. One provides support the Harwell-Boeing format and the other provides a FIR filter. For instance, would someone be willing to take a look and add a comment to the ticket that addresses at least: Do they need tests and coding style work? Or is there no interest in including this code in scipy? Thanks, -- Jarrod Millman Computational Infrastructure for Research Labs 10 Giannini Hall, UC Berkeley phone: 510.643.4014 http://cirl.berkeley.edu/

4 3

stats.cov versus np.cov
by josef.pktd＠gmail.com Dec. 3, 2008

Dec. 3, 2008

in http://scipy.org/scipy/scipy/ticket/425, stats mean, var and median got depreciated. Should this also be done for cov? Note: scipy and stats versions have different defaults for column versus row variables >>> x = np.array([[0, 2], [1, 1], [2, 0]]).T >>> np.cov(x) array([[ 1., -1.], [-1., 1.]]) >>> stats.cov(x) array([[ 2., 0., -2.], [ 0., 0., 0.], [-2., 0., 2.]]) >>> stats.cov(x.T) array([[ 1., -1.], [-1., 1.]]) >>> np.mean(x) 1.0 Josef

2 1

Possible bug in distutils compiler when using scipy's weave on windows
by Brian Thorne Dec. 3, 2008

Dec. 3, 2008

I am running python(x,y) which installs python and scipy and weave under the "program files" folder on windows. When using weave by having some inline C/C++ it uses a modified distutils to compile the inline source right? Unfortunately it doesn't seem to handle spaces in the path to either the output or to the temporary source files. I checked that this was the problem by copying the weave directory from site-packages and put it in another directory without spaces in the path - this worked fine. I then tried the exact g++ command from the stack trace at the command line and got the same error - so altered the command by adding quotes to the -c "path/to source/a.c" and the -o "objects". This worked at the command line so I set out changing it in weave... After spending a while debugging I found where quotes were added to the included libraries. After a lot more tracing found where the command line gets stringed together for the linker - in unixcompiler.py (surprising as I am under windows!) So I changed it to quote the source and the output objects and now it goes fine. What I changed was: In distutils.cygwinccompiler __revision__ = "$Id: cygwinccompiler.py 37828 2004-11-10 22:23:15Z loewis $": > def _compile(self, obj, src, ext, cc_args, extra_postargs, pp_opts): > if ext == '.rc' or ext == '.res': > # gcc needs '.res' and '.rc' compiled to object files !!! > try: > self.spawn(["windres", "-i", src, "-o", obj]) > except DistutilsExecError, msg: > raise CompileError, msg > else: # for other files use the C-compiler > try: > lis = ['"' + src + '"', '-o', '"' + obj + '"'] > cmd = self.compiler_so + cc_args + lis + extra_postargs > self.spawn(cmd) > except DistutilsExecError, msg: > raise CompileError, msg In distutils.unixccompiler __revision__ = "$Id: unixccompiler.py 54954 2007-04-25 06:42:41Z neal.norwitz $": > def link(self, target_desc, objects, > output_filename, output_dir=None, libraries=None, > library_dirs=None, runtime_library_dirs=None, > export_symbols=None, debug=0, extra_preargs=None, > extra_postargs=None, build_temp=None, target_lang=None): > objects, output_dir = self._fix_object_args(objects, output_dir) > libraries, library_dirs, runtime_library_dirs = \ > self._fix_lib_args(libraries, library_dirs, runtime_library_dirs) > > lib_opts = gen_lib_options(self, library_dirs, runtime_library_dirs, libraries) > if type(output_dir) not in (StringType, NoneType): > raise TypeError, "'output_dir' must be a string or None" > if output_dir is not None: > output_filename = os.path.join(output_dir, output_filename) > > if self._need_link(objects, output_filename): > objects = ['"' + o + '"' for o in objects] > self.objects = ['"' + o + '"' for o in self.objects] > ld_args = (objects + self.objects + > lib_opts + ['-o', '"' + output_filename + '"']) > if debug: > ld_args[:0] = ['-g'] > if extra_preargs: > ld_args[:0] = extra_preargs I don't know if that would still work on gnu/linux systems tho... Brian Thorne

1 0

license for code published in articles
by josef.pktd＠gmail.com Dec. 3, 2008

Dec. 3, 2008

Is code that is published verbatim inside a paper (not as attachment) license restricted? The Journal of Statistical Software publishes code under GPL. Does GPL also apply to source snippets or functions that are included in the text of the article, or is there a fair use assumption on the text of the article? example: Kolmogorov distribution for two-sided ks-test paper: http://www.jstatsoft.org/v08/i18 George Marsaglia, Wai Wan Tsang, Jingbo Wang: Evaluating Kolmogorov's Distribution, Journal of Statistical Software Vol. 8, Issue 18, Nov 2003 discussion: http://projects.scipy.org/pipermail/scipy-dev/2004-July/002182.html Josef

4 5