From bsouthey at gmail.com Thu Apr 1 09:51:49 2010 From: bsouthey at gmail.com (Bruce Southey) Date: Thu, 01 Apr 2010 08:51:49 -0500 Subject: [SciPy-Dev] Speaking of tickets... In-Reply-To: References: <4BB2DA58.2050903@enthought.com> Message-ID: <4BB4A4F5.7000204@gmail.com> On 03/31/2010 12:57 PM, Robert Kern wrote: > On Wed, Mar 31, 2010 at 11:32, wrote: > >> On Wed, Mar 31, 2010 at 1:15 AM, Warren Weckesser >> wrote: >> >>> Just curious: what are the plans for the "Statistic Review" tickets in >>> scipy.stats, from April, 2006? Can any of these be closed? >>> >> short answer: >> I looked at them and there are several that can be closed, especially >> the functions that have been removed or depreciated. For others, I >> have to check my notes to see which ones I verified and added tested. >> >> >> long answer (this were my initial notes when I browsed the tickets): >> >> I found them very inconvenient to work with. Many or most of them are >> empty and I didn't find an easy way to get an overview which ones of >> the tickets contain useful information and require attention. >> > Well, the point of them was to systematically review every function. > Those "empty" tickets need just as much attention as those that have > comments. > > However, it's obvious that I dropped the ball on organizing that > effort. They may be systematically closed now. > > Really these functions do need to be addressed but it is rather daunting task to go through all these functions especially for the assigned criteria and given the 'duplicated' masked array functions. There are about 187 functions involved in stats modules - although some are deprecated and 'redefinition' of existing functions. Some of the functions are more utilities than stats functions and some functions are very dimension specific. For example, there is a tmean(a, limits=(min,max)) function that is essentially doing "a.compress((a>min) & (a Hi all, Here is the test output of the scipy 0.7.2rc1 for OS X. All tests pass with numpy 1.3.0, two (harmless) failures with numpy 1.4.x branch. Outputs pasted below. The questions I have are: 1. during compilation, is it normal for sparsetools to take forever and use all available cpu cycles? I actually killed compilations before because I thought I must have passed in the wrong flags, but it seems to work in the end. 2. why am I warned about using fblas instead of cblas? 3. There seems to be a problem with the N_GSYM symbol, any idea what that complaint is about (see partial build log at the bottom of this mail)? Built with $ export CC=/usr/bin/gcc-4.0 $ export CXX=/usr/bin/c++-4.0 $ paver dmg -p2.6 Cheers, Ralf ################################################################################### In [2]: sp.test() Running unit tests for scipy NumPy version 1.3.0 NumPy is installed in /Users/rgommers/Code/numpy/numpy SciPy version 0.7.2rc1 SciPy is installed in /Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/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 /Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/scipy/linsolve/__init__.py:4: DeprecationWarning: scipy.linsolve has moved to scipy.sparse.linalg.dsolve warn('scipy.linsolve has moved to scipy.sparse.linalg.dsolve', DeprecationWarning) ............................................................................................................................................................................................................................./Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/scipy/interpolate/fitpack2.py:498: 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) ...../Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/scipy/interpolate/fitpack2.py:439: 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................................................................................................./Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/scipy/io/matlab/mio.py:111: Warning: Unreadable variable "testfunc", because "Cannot read matlab functions" matfile_dict = MR.get_variables() ........../Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/scipy/io/matlab/mio.py:165: FutureWarning: Using oned_as default value ('column') This will change to 'row' in future versions oned_as=oned_as) ........................./Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/scipy/io/matlab/tests/test_mio.py:438: FutureWarning: Using oned_as default value ('column') This will change to 'row' in future versions mfw = MatFile5Writer(StringIO()) ......../Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/scipy/io/matlab/mio.py:84: FutureWarning: Using struct_as_record default value (False) This will change to True in future versions return MatFile5Reader(byte_stream, **kwargs) ...............................Warning: 1000000 bytes requested, 20 bytes read. ./Users/rgommers/Code/numpy/numpy/lib/utils.py:108: DeprecationWarning: write_array is deprecated warnings.warn(str1, DeprecationWarning) /Users/rgommers/Code/numpy/numpy/lib/utils.py:108: DeprecationWarning: read_array is deprecated warnings.warn(str1, DeprecationWarning) ......................./Users/rgommers/Code/numpy/numpy/lib/utils.py:108: DeprecationWarning: npfile is deprecated warnings.warn(str1, DeprecationWarning) .........................................................................................................................................................SSSSSS......SSSSSS......SSSS....NO ATLAS INFO AVAILABLE ......................................... **************************************************************** WARNING: cblas module is empty ----------- See scipy/INSTALL.txt for troubleshooting. Notes: * If atlas library is not found by numpy/distutils/system_info.py, then scipy uses fblas instead of cblas. **************************************************************** ................S...................................................../Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/scipy/linalg/decomp.py:1177: DeprecationWarning: qr econ argument will be removed after scipy 0.7. The economy transform will then be available through the mode='economic' argument. "the mode='economic' argument.", DeprecationWarning) .......................................................................................................................................................................................................................................................................................... **************************************************************** WARNING: clapack module is empty ----------- See scipy/INSTALL.txt for troubleshooting. Notes: * If atlas library is not found by numpy/distutils/system_info.py, then scipy uses flapack instead of clapack. **************************************************************** ...Result may be inaccurate, approximate err = 7.68933681286e-09 ...Result may be inaccurate, approximate err = 7.27595761418e-12 .....SSS..................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................SSSSSSSSSSS...........................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................K.K.........................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................../Users/rgommers/Code/numpy/numpy/lib/function_base.py:324: Warning: The new semantics of histogram is now the default and the `new` keyword will be removed in NumPy 1.4. """, Warning) ....................................................................................S................................................................................../Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/scipy/stats/stats.py:420: DeprecationWarning: scipy.stats.mean is deprecated; please update your code to use numpy.mean. Please note that: - numpy.mean axis argument defaults to None, not 0 - numpy.mean has a ddof argument to replace bias in a more general manner. scipy.stats.mean(a, bias=True) can be replaced by numpy.mean(x, axis=0, ddof=1). axis=0, ddof=1).""", DeprecationWarning) ./Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/scipy/stats/stats.py:1329: DeprecationWarning: scipy.stats.std is deprecated; please update your code to use numpy.std. Please note that: - numpy.std axis argument defaults to None, not 0 - numpy.std has a ddof argument to replace bias in a more general manner. scipy.stats.std(a, bias=True) can be replaced by numpy.std(x, axis=0, ddof=0), scipy.stats.std(a, bias=False) by numpy.std(x, axis=0, ddof=1). ddof=1).""", DeprecationWarning) /Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/scipy/stats/stats.py:1305: DeprecationWarning: scipy.stats.var is deprecated; please update your code to use numpy.var. Please note that: - numpy.var axis argument defaults to None, not 0 - numpy.var has a ddof argument to replace bias in a more general manner. scipy.stats.var(a, bias=True) can be replaced by numpy.var(x, axis=0, ddof=0), scipy.stats.var(a, bias=False) by var(x, axis=0, ddof=1). ddof=1).""", DeprecationWarning) ./Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/scipy/stats/morestats.py:603: UserWarning: Ties preclude use of exact statistic. warnings.warn("Ties preclude use of exact statistic.") ....../Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/scipy/stats/stats.py:498: DeprecationWarning: scipy.stats.median is deprecated; please update your code to use numpy.median. Please note that: - numpy.median axis argument defaults to None, not 0 - numpy.median has a ddof argument to replace bias in a more general manner. scipy.stats.median(a, bias=True) can be replaced by numpy.median(x, axis=0, ddof=1). axis=0, ddof=1).""", DeprecationWarning) ....................................................................................................................................................................................................Warning: friedmanchisquare test using Chisquared aproximation ...............warning: specified build_dir '_bad_path_' does not exist or is not writable. Trying default locations ...warning: specified build_dir '..' does not exist or is not writable. Trying default locations ..warning: specified build_dir '_bad_path_' does not exist or is not writable. Trying default locations ...warning: specified build_dir '..' does not exist or is not writable. Trying default locations ............................building extensions here: /Users/rgommers/.python26_compiled/m13 ................................................................................................ ---------------------------------------------------------------------- Ran 3488 tests in 55.516s OK (KNOWNFAIL=4, SKIP=32) Out[2]: ################################################################################### In [6]: sp.test() Running unit tests for scipy NumPy version 1.4.0 NumPy is installed in /Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/numpy SciPy version 0.7.2rc1 SciPy is installed in /Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/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..K...........................................................................................................................F...............................................Warning: 1000000 bytes requested, 20 bytes read. .................................................................................................................................................................................SSSSSS......SSSSSS......SSSS............................................. **************************************************************** WARNING: cblas module is empty ----------- See scipy/INSTALL.txt for troubleshooting. Notes: * If atlas library is not found by numpy/distutils/system_info.py, then scipy uses fblas instead of cblas. **************************************************************** ................S............................................................................................................................................................................................................................................................................................................................................... **************************************************************** WARNING: clapack module is empty ----------- See scipy/INSTALL.txt for troubleshooting. Notes: * If atlas library is not found by numpy/distutils/system_info.py, then scipy uses flapack instead of clapack. **************************************************************** ...Result may be inaccurate, approximate err = 7.68933681286e-09 ...Result may be inaccurate, approximate err = 7.27595761418e-12 .....SSS..................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................SSSSSSSSSSS...........................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................K.K.....................................................................................................................................F.........................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................S..............................................................................................................................................................................................................................................................................................Warning: friedmanchisquare test using Chisquared aproximation ...............warning: specified build_dir '_bad_path_' does not exist or is not writable. Trying default locations ...warning: specified build_dir '..' does not exist or is not writable. Trying default locations ..warning: specified build_dir '_bad_path_' does not exist or is not writable. Trying default locations ...warning: specified build_dir '..' does not exist or is not writable. Trying default locations ............................................................................................................................ ====================================================================== FAIL: test_mio.test_warnings(, , '/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/scipy/io/matlab/tests/data/testdouble_7.1_GLNX86.mat') ---------------------------------------------------------------------- Traceback (most recent call last): File "/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/nose-0.11.1-py2.6.egg/nose/case.py", line 183, in runTest self.test(*self.arg) File "/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/numpy/testing/utils.py", line 973, in assert_raises return nose.tools.assert_raises(*args,**kwargs) AssertionError: FutureWarning not raised ====================================================================== FAIL: test_nrdtrisd (test_basic.TestCephes) ---------------------------------------------------------------------- Traceback (most recent call last): File "/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/scipy/special/tests/test_basic.py", line 349, in test_nrdtrisd assert_equal(cephes.nrdtrisd(0.5,0.5,0.5),0.0) File "/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/numpy/testing/utils.py", line 301, in assert_equal raise AssertionError(msg) AssertionError: Items are not equal: ACTUAL: -0 DESIRED: 0.0 ---------------------------------------------------------------------- Ran 3488 tests in 58.811s FAILED (KNOWNFAIL=4, SKIP=32, failures=2) Out[6]: ######################### part of build log ###################################### building 'scipy.special._cephes' extension compiling C sources C compiler: /usr/bin/gcc-4.0 -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk -fno-strict-aliasing -fno-common -dynamic -DNDEBUG -g -O3 compile options: '-I/Users/rgommers/Code/numpy/numpy/core/include -I/Library/Frameworks/Python.framework/Versions/2.6/include/python2.6 -c' gcc-4.0: scipy/special/specfun_wrappers.c gcc-4.0: scipy/special/toms_wrappers.c gcc-4.0: scipy/special/ufunc_extras.c gcc-4.0: scipy/special/cdf_wrappers.c gcc-4.0: scipy/special/amos_wrappers.c gcc-4.0: scipy/special/_cephesmodule.c /usr/local/bin/gfortran -Wall -undefined dynamic_lookup -bundle -arch i386 -arch ppc -Wl,-search_paths_first -Lbuild build/temp.macosx-10.3-fat-2.6/scipy/special/_cephesmodule.o build/temp.macosx-10.3-fat-2.6/scipy/special/amos_wrappers.o build/temp.macosx-10.3-fat-2.6/scipy/special/specfun_wrappers.o build/temp.macosx-10.3-fat-2.6/scipy/special/toms_wrappers.o build/temp.macosx-10.3-fat-2.6/scipy/special/cdf_wrappers.o build/temp.macosx-10.3-fat-2.6/scipy/special/ufunc_extras.o -Lbuild/temp.macosx-10.3-fat-2.6 -lsc_amos -lsc_toms -lsc_c_misc -lsc_cephes -lsc_mach -lsc_cdf -lsc_specfun -lgfortran -o build/lib.macosx-10.3-fat-2.6/scipy/special/_cephes.so ld: warning: can't find atom for N_GSYM stabs max_offset:G(0,32) in build/libgfortran.a(unit.o) ld: warning: can't find atom for N_GSYM stabs unit_root:G(0,1) in build/libgfortran.a(unit.o) ld: warning: can't find atom for N_GSYM stabs unit_lock:G(0,37) in build/libgfortran.a(unit.o) ld: warning: can't find atom for N_GSYM stabs l8_to_l4_offset:G(0,2) in build/libgfortran.a(main.o) ld: warning: can't find atom for N_GSYM stabs options:G(0,32)=(0,33)=s72stdin_unit:(0,8),0,32;stdout_unit:(0,8),32,32;stderr_unit:(0,8),64,32;optional_plus:(0,8),96,32;allocate_init_flag:(0,8),128,32;allocate_init_value:(0,8),160,32;locus:(0,8),192,32;separator_len:(0,8),224,32;separator:(0,5),256,32;mem_check:(0,8),288,32;use_stderr:(0,8),320,32;all_unbuffered:(0,8),352,32;default_recl:(0,8),384,32;fpu_round:(0,8),416,32;fpu_precision:(0,8),448,32;fpe:(0,8),480,32;sighup:(0,8),512,32;sigint:(0,8),544,32;; in build/libgfortran.a(environ.o) ld: warning: can't find atom for N_GSYM stabs compile_options:G(0,5)=(0,6)=s24warn_std:(0,4),0,32;allow_std:(0,4),32,32;pedantic:(0,4),64,32;convert:(0,4),96,32;record_marker:(0,7)=(0,8)=r(0,8);0;037777777777;,128,32;max_subrecord_length:(0,4),160,32;; in build/libgfortran.a(compile_options.o) ld: warning: object file compiled with -mlong-branch which is no longer needed. To remove this warning, recompile without -mlong-branch: /usr/local/lib/gcc/powerpc-apple-darwin8/4.2.3/crt3.o -------------- next part -------------- An HTML attachment was scrubbed... URL: From josef.pktd at gmail.com Thu Apr 1 11:54:06 2010 From: josef.pktd at gmail.com (josef.pktd at gmail.com) Date: Thu, 1 Apr 2010 11:54:06 -0400 Subject: [SciPy-Dev] Speaking of tickets... In-Reply-To: <4BB4A4F5.7000204@gmail.com> References: <4BB2DA58.2050903@enthought.com> <4BB4A4F5.7000204@gmail.com> Message-ID: On Thu, Apr 1, 2010 at 9:51 AM, Bruce Southey wrote: > On 03/31/2010 12:57 PM, Robert Kern wrote: >> On Wed, Mar 31, 2010 at 11:32, ?wrote: >> >>> On Wed, Mar 31, 2010 at 1:15 AM, Warren Weckesser >>> ?wrote: >>> >>>> Just curious: what are the plans for the "Statistic Review" tickets in >>>> scipy.stats, from April, 2006? ?Can any of these be closed? >>>> >>> short answer: >>> I looked at them and there are several that can be closed, especially >>> the functions that have been removed or depreciated. For others, I >>> have to check my notes to see which ones I verified and added tested. >>> >>> >>> long answer (this were my initial notes when I browsed the tickets): >>> >>> I found them very inconvenient to work with. Many or most of them are >>> empty and I didn't find an easy way to get an overview which ones of >>> the tickets contain useful information and require attention. >>> >> Well, the point of them was to systematically review every function. >> Those "empty" tickets need just as much attention as those that have >> comments. >> >> However, it's obvious that I dropped the ball on organizing that >> effort. They may be systematically closed now. >> >> > Really these functions do need to be addressed but it is rather daunting > task to go through all these functions especially for the assigned > criteria and given the 'duplicated' masked array functions. There are > about 187 functions involved in stats modules - although some are > deprecated and 'redefinition' of existing functions. Some of the > functions are more utilities than stats functions and some functions are > very dimension specific. For example, there is a tmean(a, > limits=(min,max)) function that is essentially doing "a.compress((a>min) > & (a masked array function, trimmed_mean, that does have an axis argument. > > However, I came to the conclusion that most of these have more problems > than they are worth making my original idea worthless. So it would be > better to have a clear plan for a proper set of statistical functions > than just 'blindly fixing' the existing functions. Because there are so many functions, because test coverage is still not sufficient and because of backwards compatibility, I still prefer an incremental approach. The trim functions are mostly convenience functions according to Gary, and since I haven't found yet a use for them, I mostly ignored them, except for adding some tests. The statistical tests are (almost?) completely verified and produce the advertised results. But in morestats.py there are still groups of functions, e.g. boxcox, kstat, ppcc that look ok but I'm not sure about them, and functions that I would like to (temporarily) delete or replace ('pdf_moments', 'pdf_fromgamma', 'pdfapprox') because the are incorrect. Overall, I think of scipy.stats a bit of a laundry list and it's still difficult to see what "a clear plan for a proper set of statistical functions than just 'blindly fixing' the existing functions" would be. My current opinion is that a lot of the more elaborate statistical functions should be classes instead, which I'm trying to do in statsmodels. I'm not a statistician and I ended up with scipy.stats a bit by accident, so if someone can come up with a good long term plan for it and implements it, I would be glad. My main objective is that we can trust any results that we get out of scipy.stats. (testing and verification) Josef > > > Bruce > > > > > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev > From d.l.goldsmith at gmail.com Thu Apr 1 20:33:18 2010 From: d.l.goldsmith at gmail.com (David Goldsmith) Date: Thu, 1 Apr 2010 17:33:18 -0700 Subject: [SciPy-Dev] Please remind Message-ID: What do we call the feature of pydocweb whereby it automatically finds the internal link for a function reference when we surround its name w/ back ticks (e.g., in numpy.polynomial.chebyshev, `chebdomain` is sufficient for "chebdomain" in the rendered docstring to be a link to http://docs.scipy.org/numpy/docs/numpy.polynomial.chebyshev.chebdomain/#chebdomain)? It's broken below numpy.polynomial.chebyshev.Chebyshev, e.g., in numpy.polynomial.chebyshev.Chebyshev.deriv, `chebder` is insufficient to find numpy.polynomial.chebyshev.chebder (I had to use the full reference to get the link to appear in the rendered docstring). I'll file a ticket, but I want to refer to the feature properly and succinctly. Thanks! DG -- Mathematician: noun, someone who disavows certainty when their uncertainty set is non-empty, even if that set has measure zero. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.gommers at googlemail.com Thu Apr 1 20:52:10 2010 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Fri, 2 Apr 2010 08:52:10 +0800 Subject: [SciPy-Dev] Please remind In-Reply-To: References: Message-ID: On Fri, Apr 2, 2010 at 8:33 AM, David Goldsmith wrote: > What do we call the feature of pydocweb whereby it automatically finds the > internal link for a function reference when we surround its name w/ back > ticks (e.g., in numpy.polynomial.chebyshev, `chebdomain` is sufficient for > "chebdomain" in the rendered docstring to be a link to > http://docs.scipy.org/numpy/docs/numpy.polynomial.chebyshev.chebdomain/#chebdomain)? > It's broken below numpy.polynomial.chebyshev.Chebyshev, e.g., in > numpy.polynomial.chebyshev.Chebyshev.deriv, `chebder` is insufficient to > find numpy.polynomial.chebyshev.chebder (I had to use the full reference to > get the link to appear in the rendered docstring). I'll file a ticket, but > I want to refer to the feature properly and succinctly. Thanks! > > I don't think it's broken.Both pages have errors in the header (the ':' in Parameters, and '__init__' in the header respectively). Before you report a bug, please fix the markup errors reported by the wiki first. Cheers, Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From d.l.goldsmith at gmail.com Thu Apr 1 21:32:10 2010 From: d.l.goldsmith at gmail.com (David Goldsmith) Date: Thu, 1 Apr 2010 18:32:10 -0700 Subject: [SciPy-Dev] Please remind In-Reply-To: References: Message-ID: On Thu, Apr 1, 2010 at 5:52 PM, Ralf Gommers wrote: > > > On Fri, Apr 2, 2010 at 8:33 AM, David Goldsmith wrote: > >> What do we call the feature of pydocweb whereby it automatically finds the >> internal link for a function reference when we surround its name w/ back >> ticks (e.g., in numpy.polynomial.chebyshev, `chebdomain` is sufficient for >> "chebdomain" in the rendered docstring to be a link to >> http://docs.scipy.org/numpy/docs/numpy.polynomial.chebyshev.chebdomain/#chebdomain)? >> It's broken below numpy.polynomial.chebyshev.Chebyshev, e.g., in >> numpy.polynomial.chebyshev.Chebyshev.deriv, `chebder` is insufficient to >> find numpy.polynomial.chebyshev.chebder (I had to use the full reference to >> get the link to appear in the rendered docstring). I'll file a ticket, but >> I want to refer to the feature properly and succinctly. Thanks! >> >> I don't think it's broken.Both pages have errors in the header (the ':' in > Parameters, and '__init__' in the header respectively). Before you report a > bug, please fix the markup errors reported by the wiki first. > Thanks Ralf, what a PITA, sorry for the noise everyone. DG > Cheers, > Ralf > > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev > > -- Mathematician: noun, someone who disavows certainty when their uncertainty set is non-empty, even if that set has measure zero. -------------- next part -------------- An HTML attachment was scrubbed... URL: From d.l.goldsmith at gmail.com Thu Apr 1 21:43:33 2010 From: d.l.goldsmith at gmail.com (David Goldsmith) Date: Thu, 1 Apr 2010 18:43:33 -0700 Subject: [SciPy-Dev] Please remind In-Reply-To: References: Message-ID: On Thu, Apr 1, 2010 at 6:32 PM, David Goldsmith wrote: > On Thu, Apr 1, 2010 at 5:52 PM, Ralf Gommers wrote: > >> >> >> On Fri, Apr 2, 2010 at 8:33 AM, David Goldsmith wrote: >> >>> What do we call the feature of pydocweb whereby it automatically finds >>> the internal link for a function reference when we surround its name w/ back >>> ticks (e.g., in numpy.polynomial.chebyshev, `chebdomain` is sufficient for >>> "chebdomain" in the rendered docstring to be a link to >>> http://docs.scipy.org/numpy/docs/numpy.polynomial.chebyshev.chebdomain/#chebdomain)? >>> It's broken below numpy.polynomial.chebyshev.Chebyshev, e.g., in >>> numpy.polynomial.chebyshev.Chebyshev.deriv, `chebder` is insufficient to >>> find numpy.polynomial.chebyshev.chebder (I had to use the full reference to >>> get the link to appear in the rendered docstring). I'll file a ticket, but >>> I want to refer to the feature properly and succinctly. Thanks! >>> >>> I don't think it's broken.Both pages have errors in the header (the ':' >> in Parameters, and '__init__' in the header respectively). Before you >> report a bug, please fix the markup errors reported by the wiki first. >> > > Thanks Ralf, what a PITA, sorry for the noise everyone. > > DG > But for the record, what do we call this feature? DG -------------- next part -------------- An HTML attachment was scrubbed... URL: From david at silveregg.co.jp Thu Apr 1 22:06:35 2010 From: david at silveregg.co.jp (David Cournapeau) Date: Fri, 02 Apr 2010 11:06:35 +0900 Subject: [SciPy-Dev] test output 0.7.2rc1 In-Reply-To: References: Message-ID: <4BB5512B.9090308@silveregg.co.jp> Ralf Gommers wrote: > Hi all, > > Here is the test output of the scipy 0.7.2rc1 for OS X. All tests pass with > numpy 1.3.0, two (harmless) failures with numpy 1.4.x branch. Outputs pasted > below. The questions I have are: > 1. during compilation, is it normal for sparsetools to take forever and use > all available cpu cycles? That's as normal as c++ can be :) Sparsetools relies on SWIG + templates, which are both performance killer as far as compilation is concerned. Sparsetools currently accounts for ~ 50 % of the whole scipy build time. > 2. why am I warned about using fblas instead of cblas? I don't know, those have always confused me. AFAICS, those are reliques from old scipy code, I don't think they matter (I think we should remove them). > 3. There seems to be a problem with the N_GSYM symbol, any idea what that > complaint is about (see partial build log at the bottom of this mail)? This one is new to me, I have never seen it before. Looks like a problem with gfortran on mac os x. We should first see if the issue stays with the following issue: > Built with > $ export CC=/usr/bin/gcc-4.0 > $ export CXX=/usr/bin/c++-4.0 I think whatever issue happens with the actual gcc version should be fixed - we should not rely on gcc 4.0 on Snow Leopard, and this is not needed (the -mlong-branch warning is linked to this). cheers, David From ralf.gommers at googlemail.com Thu Apr 1 22:21:43 2010 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Fri, 2 Apr 2010 10:21:43 +0800 Subject: [SciPy-Dev] test output 0.7.2rc1 In-Reply-To: <4BB5512B.9090308@silveregg.co.jp> References: <4BB5512B.9090308@silveregg.co.jp> Message-ID: On Fri, Apr 2, 2010 at 10:06 AM, David Cournapeau wrote: > Ralf Gommers wrote: > > > 2. why am I warned about using fblas instead of cblas? > > I don't know, those have always confused me. AFAICS, those are reliques > from old scipy code, I don't think they matter (I think we should remove > them). > > Okay, will ignore this for now then and come back to it later. > > 3. There seems to be a problem with the N_GSYM symbol, any idea what that > > complaint is about (see partial build log at the bottom of this mail)? > > This one is new to me, I have never seen it before. Looks like a problem > with gfortran on mac os x. We should first see if the issue stays with > the following issue: > > > Built with > > $ export CC=/usr/bin/gcc-4.0 > > $ export CXX=/usr/bin/c++-4.0 > > I think whatever issue happens with the actual gcc version should be > fixed - we should not rely on gcc 4.0 on Snow Leopard, and this is not > needed (the -mlong-branch warning is linked to this). > Default gcc on Snow Leopard is 4.2, which does not work with the 10.4 SDK. When we discussed this before you thought that my SDK was broken, but that is not the case. It is linked to http://bugs.python.org/issue6957. That issue was closed but not actually resolved - just ignored because python itself is still built on OS X 10.5. There are bug reports and threads for many python extensions about this issue. The "$ export CC=/usr/bin/gcc-4.0" is unnecessary by the way (gcc-4.0 is picked up by default cause that's what python is built with), but "$ export CXX=/usr/bin/c++-4.0" is needed. c++-4.2 and 10.4SDK are not compatible. Unless I'm misunderstanding the problem, we can either: - decide the N_GSYM thing is not an issue - build against 10.5 or 10.6 SDK, which requires changes to distutils. - build the binaries on 10.5 (Leopard). But I don't have that available. Cheers, Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From warren.weckesser at enthought.com Thu Apr 1 22:37:28 2010 From: warren.weckesser at enthought.com (Warren Weckesser) Date: Thu, 01 Apr 2010 21:37:28 -0500 Subject: [SciPy-Dev] Questions about docs Message-ID: <4BB55868.3060202@enthought.com> Each package has the file "info.py" (e.g. scipy/linalg/info.py) that contains a docstring. For linalg, roughly the same information is in doc/source/linalg.rst. Which is the file that is currently maintained, and which can we get rid of? Running "make html" in doc/ uses the .rst file, but the corresponding web page at docs.scipy.org (http://docs.scipy.org/scipy/docs/scipy.linalg/) appears to be from the file info.py. More basic question: when I have the trunk checked out, what is "the way" to build the docs? From david at silveregg.co.jp Fri Apr 2 00:33:02 2010 From: david at silveregg.co.jp (David Cournapeau) Date: Fri, 02 Apr 2010 13:33:02 +0900 Subject: [SciPy-Dev] test output 0.7.2rc1 In-Reply-To: References: <4BB5512B.9090308@silveregg.co.jp> Message-ID: <4BB5737E.4070606@silveregg.co.jp> Ralf Gommers wrote: > > Default gcc on Snow Leopard is 4.2, which does not work with the 10.4 SDK. > When we discussed this before you thought that my SDK was broken, but that > is not the case. It is linked to http://bugs.python.org/issue6957. That > issue was closed but not actually resolved - just ignored because python > itself is still built on OS X 10.5. There are bug reports and threads for > many python extensions about this issue. I seem to remember that installing the 10.4 SDK fixed the issue. Maybe I had CC defined to gcc 4.0. I will have to check at home on my macbook. > But I don't have that available. At worst, you could install a 10.4 chroot somewhere if you have access to a 10.4 (http://www.kwm-web.info/macos_x_chroot_howto) but that is kinda overkill (although quite useful for testing), David From david at silveregg.co.jp Fri Apr 2 00:41:28 2010 From: david at silveregg.co.jp (David Cournapeau) Date: Fri, 02 Apr 2010 13:41:28 +0900 Subject: [SciPy-Dev] Questions about docs In-Reply-To: <4BB55868.3060202@enthought.com> References: <4BB55868.3060202@enthought.com> Message-ID: <4BB57578.20307@silveregg.co.jp> Warren Weckesser wrote: > Each package has the file "info.py" (e.g. scipy/linalg/info.py) that > contains a docstring. For linalg, roughly the same information is in > doc/source/linalg.rst. Which is the file that is currently maintained, > and which can we get rid of? Running "make html" in doc/ uses the .rst > file, but the corresponding web page at docs.scipy.org > (http://docs.scipy.org/scipy/docs/scipy.linalg/) appears to be from the > file info.py. > > More basic question: when I have the trunk checked out, what is "the > way" to build the docs? If you want to build the doc for the scipy you have in your trunk, you need to build and install scipy first (so that the docstrings can be extracted). The way I do it when generating the scipy binaries is: - create a virtual env and activate it - install scipy through python setupsconsegg.py install (or setupegg.py - I prefer using scons because I can build scipy very quickly on a multicore machine) - then build the doc (cd doc && make html) cheers, David From d.l.goldsmith at gmail.com Fri Apr 2 01:54:15 2010 From: d.l.goldsmith at gmail.com (David Goldsmith) Date: Thu, 1 Apr 2010 22:54:15 -0700 Subject: [SciPy-Dev] Questions about docs In-Reply-To: <4BB57578.20307@silveregg.co.jp> References: <4BB55868.3060202@enthought.com> <4BB57578.20307@silveregg.co.jp> Message-ID: On Thu, Apr 1, 2010 at 9:41 PM, David Cournapeau wrote: > Warren Weckesser wrote: > > Each package has the file "info.py" (e.g. scipy/linalg/info.py) that > > contains a docstring. For linalg, roughly the same information is in > > doc/source/linalg.rst. Which is the file that is currently maintained, > > and which can we get rid of? Running "make html" in doc/ uses the .rst > > file, but the corresponding web page at docs.scipy.org > > (http://docs.scipy.org/scipy/docs/scipy.linalg/) appears to be from the > > file info.py. > IIRC, this has come up before, but I don't recall the resolution (if there was any) and GMANE doesn't search for periods so there appears to be no efficient way to search the list for info.py AND .rst ("info.py" returned occurrences of .py) - does anyone recall and/or know where/how to find that thread? DG > > > > More basic question: when I have the trunk checked out, what is "the > > way" to build the docs? > > If you want to build the doc for the scipy you have in your trunk, you > need to build and install scipy first (so that the docstrings can be > extracted). > > The way I do it when generating the scipy binaries is: > - create a virtual env and activate it > - install scipy through python setupsconsegg.py install (or > setupegg.py > - I prefer using scons because I can build scipy very quickly on a > multicore machine) > - then build the doc (cd doc && make html) > > cheers, > > David > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev > -- Mathematician: noun, someone who disavows certainty when their uncertainty set is non-empty, even if that set has measure zero. -------------- next part -------------- An HTML attachment was scrubbed... URL: From warren.weckesser at enthought.com Fri Apr 2 02:17:51 2010 From: warren.weckesser at enthought.com (Warren Weckesser) Date: Fri, 02 Apr 2010 01:17:51 -0500 Subject: [SciPy-Dev] Questions about docs In-Reply-To: <4BB57578.20307@silveregg.co.jp> References: <4BB55868.3060202@enthought.com> <4BB57578.20307@silveregg.co.jp> Message-ID: <4BB58C0F.4090905@enthought.com> David Cournapeau wrote: > Warren Weckesser wrote: > >> Each package has the file "info.py" (e.g. scipy/linalg/info.py) that >> contains a docstring. For linalg, roughly the same information is in >> doc/source/linalg.rst. Which is the file that is currently maintained, >> and which can we get rid of? Running "make html" in doc/ uses the .rst >> file, but the corresponding web page at docs.scipy.org >> (http://docs.scipy.org/scipy/docs/scipy.linalg/) appears to be from the >> file info.py. >> >> More basic question: when I have the trunk checked out, what is "the >> way" to build the docs? >> > > If you want to build the doc for the scipy you have in your trunk, you > need to build and install scipy first (so that the docstrings can be > extracted). > > The way I do it when generating the scipy binaries is: > - create a virtual env and activate it > - install scipy through python setupsconsegg.py install (or setupegg.py > - I prefer using scons because I can build scipy very quickly on a > multicore machine) > - then build the doc (cd doc && make html) > > Thanks. I've just been doing "python setup.py build", and then setting PYTHONPATH to the "lib..." subdirectory of build/ when I want to switch to the trunk version of scipy. So, the HTML documentation for, say, linalg, comes from doc/source/linalg.rst, but the actual docstring associated with scipy.linalg comes from info.py. The format of the two files is different--the .rst file uses a lot more sphinx automation goodness--so I guess they both have to be maintained. But it sure would be nice if, say, the .rst file could be generated from the docstring in info.py. Warren > cheers, > > David > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev > From d.l.goldsmith at gmail.com Fri Apr 2 02:53:29 2010 From: d.l.goldsmith at gmail.com (David Goldsmith) Date: Thu, 1 Apr 2010 23:53:29 -0700 Subject: [SciPy-Dev] Questions about docs In-Reply-To: <4BB58C0F.4090905@enthought.com> References: <4BB55868.3060202@enthought.com> <4BB57578.20307@silveregg.co.jp> <4BB58C0F.4090905@enthought.com> Message-ID: On Thu, Apr 1, 2010 at 11:17 PM, Warren Weckesser < warren.weckesser at enthought.com> wrote: > David Cournapeau wrote: > > Warren Weckesser wrote: > > > >> Each package has the file "info.py" (e.g. scipy/linalg/info.py) that > >> contains a docstring. For linalg, roughly the same information is in > >> doc/source/linalg.rst. Which is the file that is currently maintained, > >> and which can we get rid of? Running "make html" in doc/ uses the .rst > >> file, but the corresponding web page at docs.scipy.org > >> (http://docs.scipy.org/scipy/docs/scipy.linalg/) appears to be from the > >> file info.py. > >> > >> More basic question: when I have the trunk checked out, what is "the > >> way" to build the docs? > >> > > > > If you want to build the doc for the scipy you have in your trunk, you > > need to build and install scipy first (so that the docstrings can be > > extracted). > > > > The way I do it when generating the scipy binaries is: > > - create a virtual env and activate it > > - install scipy through python setupsconsegg.py install (or > setupegg.py > > - I prefer using scons because I can build scipy very quickly on a > > multicore machine) > > - then build the doc (cd doc && make html) > > > > > > > Thanks. I've just been doing "python setup.py build", and then setting > PYTHONPATH to the "lib..." subdirectory of build/ when I want to switch > to the trunk version of scipy. > > So, the HTML documentation for, say, linalg, comes from > doc/source/linalg.rst, but the actual docstring associated with > scipy.linalg comes from info.py. The format of the two files is > different--the .rst file uses a lot more sphinx automation goodness--so > I guess they both have to be maintained. But it sure would be nice if, > say, the .rst file could be generated from the docstring in info.py. > This rings a bell vis-a-vis the previous conclusion; I'll check to see if anyone opened a ticket asking for such an enhancement. DG > > Warren > > > cheers > > > > David > > _______________________________________________ > > SciPy-Dev mailing list > > SciPy-Dev at scipy.org > > http://mail.scipy.org/mailman/listinfo/scipy-dev > > > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev > -- Mathematician: noun, someone who disavows certainty when their uncertainty set is non-empty, even if that set has measure zero. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gombiuda at gmail.com Fri Apr 2 05:27:17 2010 From: gombiuda at gmail.com (gombiuda JHL) Date: Fri, 2 Apr 2010 17:27:17 +0800 Subject: [SciPy-Dev] About GSoC porting SciPy or NumPy Message-ID: Hi all. I want to know how many students is needed to finish the porting job in GSoC period. Thanks. -- Sincerely, Gombiuda Jiang -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.gommers at googlemail.com Fri Apr 2 05:50:32 2010 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Fri, 2 Apr 2010 17:50:32 +0800 Subject: [SciPy-Dev] test output 0.7.2rc1 In-Reply-To: <4BB5737E.4070606@silveregg.co.jp> References: <4BB5512B.9090308@silveregg.co.jp> <4BB5737E.4070606@silveregg.co.jp> Message-ID: On Fri, Apr 2, 2010 at 12:33 PM, David Cournapeau wrote: > Ralf Gommers wrote: > > > > > Default gcc on Snow Leopard is 4.2, which does not work with the 10.4 > SDK. > > When we discussed this before you thought that my SDK was broken, but > that > > is not the case. It is linked to http://bugs.python.org/issue6957. That > > issue was closed but not actually resolved - just ignored because python > > itself is still built on OS X 10.5. There are bug reports and threads for > > many python extensions about this issue. > > I seem to remember that installing the 10.4 SDK fixed the issue. Maybe I > had CC defined to gcc 4.0. I will have to check at home on my macbook. > > You probably had CXX defined to 4.0? If not, then I'm interested to see your build log for c++ files. > > But I don't have that available. > > At worst, you could install a 10.4 chroot somewhere if you have access > to a 10.4 (http://www.kwm-web.info/macos_x_chroot_howto) but that is > kinda overkill (although quite useful for testing), > > I still have the 10.4 disks so yes I can try that. Actually, for real overkill I will probably go for virtualbox. It's not a permanent solution of course. Cheers, Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From david at silveregg.co.jp Fri Apr 2 05:58:37 2010 From: david at silveregg.co.jp (David Cournapeau) Date: Fri, 02 Apr 2010 18:58:37 +0900 Subject: [SciPy-Dev] test output 0.7.2rc1 In-Reply-To: References: <4BB5512B.9090308@silveregg.co.jp> <4BB5737E.4070606@silveregg.co.jp> Message-ID: <4BB5BFCD.9020105@silveregg.co.jp> Ralf Gommers wrote: >> >> I still have the 10.4 disks so yes I can try that. Actually, for real > overkill I will probably go for virtualbox. It's not a permanent solution of > course. I think installing mac os x into virtualbox may be painful. The good think with a chroot is that it is quite fast to set up once you have a template .dmg - and is much more reliable than using all those tricks with -sysroot ? DEPLOYMENT_TARGET / etc... which frankly don't work well (it seems every micro version of python changes things there), especially when distutils goes in the way. cheers, David From josef.pktd at gmail.com Fri Apr 2 07:36:40 2010 From: josef.pktd at gmail.com (josef.pktd at gmail.com) Date: Fri, 2 Apr 2010 07:36:40 -0400 Subject: [SciPy-Dev] Questions about docs In-Reply-To: References: <4BB55868.3060202@enthought.com> <4BB57578.20307@silveregg.co.jp> <4BB58C0F.4090905@enthought.com> Message-ID: On Fri, Apr 2, 2010 at 2:53 AM, David Goldsmith wrote: > On Thu, Apr 1, 2010 at 11:17 PM, Warren Weckesser > wrote: >> >> David Cournapeau wrote: >> > Warren Weckesser wrote: >> > >> >> Each package has the file "info.py" (e.g. scipy/linalg/info.py) that >> >> contains a docstring. ?For linalg, roughly the same information is in >> >> doc/source/linalg.rst. ?Which is the file that is currently maintained, >> >> and which can we get rid of? ?Running "make html" in doc/ uses the .rst >> >> file, but the corresponding web page at docs.scipy.org >> >> (http://docs.scipy.org/scipy/docs/scipy.linalg/) appears to be from the >> >> file info.py. >> >> >> >> More basic question: ?when I have the trunk checked out, what is "the >> >> way" to build the docs? >> >> >> > >> > If you want to build the doc for the scipy you have in your trunk, you >> > need to build and install scipy first (so that the docstrings can be >> > extracted). >> > >> > The way I do it when generating the scipy binaries is: >> > ? ? ? - create a virtual env and activate it >> > ? ? ? - install scipy through python setupsconsegg.py install (or >> > setupegg.py >> > - I prefer using scons because I can build scipy very quickly on a >> > multicore machine) >> > ? ? ? - then build the doc (cd doc && make html) >> > >> > >> >> >> Thanks. ?I've just been doing "python setup.py build", and then setting >> PYTHONPATH to the "lib..." subdirectory of build/ when I want to switch >> to the trunk version of scipy. >> >> So, the HTML documentation for, say, linalg, comes from >> doc/source/linalg.rst, but the actual docstring associated with >> scipy.linalg comes from info.py. ?The format of the two files is >> different--the .rst file uses a lot more sphinx automation goodness--so >> I guess they both have to be maintained. ?But it sure would be nice if, >> say, the .rst file could be generated from the docstring in info.py. > > This rings a bell vis-a-vis the previous conclusion; I'll check to see if > anyone opened a ticket asking for such an enhancement. my search only shows a brief discussion for module docstrings mainly for numpy [SciPy-dev] "module docstrings" September-October 2009 Josef > > DG > >> >> Warren >> >> > cheers >> > >> > David >> > _______________________________________________ >> > SciPy-Dev mailing list >> > SciPy-Dev at scipy.org >> > http://mail.scipy.org/mailman/listinfo/scipy-dev >> > >> >> _______________________________________________ >> SciPy-Dev mailing list >> SciPy-Dev at scipy.org >> http://mail.scipy.org/mailman/listinfo/scipy-dev > > > > -- > Mathematician: noun, someone who disavows certainty when their uncertainty > set is non-empty, even if that set has measure zero. > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev > > From ralf.gommers at googlemail.com Fri Apr 2 11:01:33 2010 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Fri, 2 Apr 2010 23:01:33 +0800 Subject: [SciPy-Dev] test output 0.7.2rc1 In-Reply-To: <4BB5512B.9090308@silveregg.co.jp> References: <4BB5512B.9090308@silveregg.co.jp> Message-ID: On Fri, Apr 2, 2010 at 10:06 AM, David Cournapeau wrote: > Ralf Gommers wrote: > > 3. There seems to be a problem with the N_GSYM symbol, any idea what that > > complaint is about (see partial build log at the bottom of this mail)? > > This one is new to me, I have never seen it before. Looks like a problem > with gfortran on mac os x. It is: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34719. The problem seems to be some non-existing debug symbol being referenced. The solution is to pass -gdwarf-2 to gfortran instead of -g. Is there an easy way to accomplish this in distutils? If it's not easy to fix, does it actually hurt us? I do have a working binary with all tests passing after all. Cheers, Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.gommers at googlemail.com Mon Apr 5 13:47:40 2010 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Tue, 6 Apr 2010 01:47:40 +0800 Subject: [SciPy-Dev] request for testing: SciPy 0.7.2 RC1 + NumPy 1.4.1 RC1 Message-ID: Hi everyone, The first release candidate of both Scipy 0.7.2 and NumPy 1.4.1 is ready, and I want to ask for some help with testing. I'm interested to hear about both installs where everything is OK and where there is a problem. SciPy 0.7.2 should work with both NumPy 1.3.0 and 1.4.1. Also, reports on whether these binaries work with matplotlib/pygame/ will be very useful. For scipy 0.7.2 there are no new features compared to 0.7.1, the one change is that all cython sources have been regenerated with cython 0.12 so the resulting binary works with numpy 1.4.1. Numpy 1.4.1 has important bug fixes that should have solved the incompatibilities with scipy and other packages that were introduced with numpy 1.4.0. Windows binaries: http://www.filefactory.com/file/b0ghb9e/n/numpy-1.4.1rc1-win32-superpack-python2.6.exe http://filefactory.com/file/b0ghce6/n/scipy-0.7.2rc1-win32-superpack-python2.6.exe OS X binaries: http://www.filefactory.com/file/b0gh5h1/n/numpy-1.4.1rc1-py2.6-python.org.dmg http://www.filefactory.com/file/b0gh638/n/scipy-0.7.2rc1-py2.6-python.org.dmg I have not yet received the keys to the sourceforge site, so the above temporary hosting will have to do for rc1 (apologies for the flashy ads and download delay). Bandwidth is 150MB/hr so if the download is slow or not working please try again a bit later. Known issues: - there are failing datetime tests in numpy, they should probably be marked as knownfail or removed from the 1.4.x branch. - the numpy OS X installer still needs artwork. Cheers, Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists at onerussian.com Mon Apr 5 15:29:25 2010 From: lists at onerussian.com (Yaroslav Halchenko) Date: Mon, 5 Apr 2010 15:29:25 -0400 Subject: [SciPy-Dev] few patches for your consideration In-Reply-To: <20100312144202.GN8332@onerussian.com> References: <20100312144202.GN8332@onerussian.com> Message-ID: <20100405192925.GX8332@onerussian.com> Dear all, since my humble attempt to provide patches via mailing list has failed (noone followed) I've tried to open a ticket on trac but got: Oops? Trac detected an internal error: OperationalError: database is locked There was an internal error in Trac. It is recommended that you inform your local Trac administrator and give him all the information he needs to reproduce the issue. To that end, you could ==== How to Reproduce ==== While doing a POST operation on `/newticket`, Trac issued an internal error. ''(please provide additional details here)'' Request parameters: {{{ {'__FORM_TOKEN': u'ac193bbb6eeef1400267b402', 'attachment': u'on', 'field_cc': u'', 'field_component': u'Other', 'field_description': u"String formatting is errorneous while raising exceptions in those files. Also those messages better be more informative. Thus I am providing a bugfix patch + enhancement patch for those.\r\n\r\nThey are also available from my git clone:\r\n\r\nhttp://github.com/yarikoptic/scipy3/commit/0cef22c0342faf8e70d84dd4008dc5ee44f365d4\r\nBUG: use correct string formatting in raising depending on info from lapack\r\n\r\nhttp://github.com/yarikoptic/scipy3/commit/4feb14edcb9d6efdb307fc14c351aab41bad69f4\r\nENH: a bit more of information upon failure in LinAlgError's from lapack\r\n", 'field_keywords': u'', 'field_milestone': u'0.8.0', 'field_priority': u'normal', 'field_status': u'new', 'field_summary': u'fix "unsupported format character" while raising exceptions in scipy/linalg/basic.py scipy/linalg/decomp.py', 'field_type': u'defect', 'field_version': u'0.7.0', 'submit': u'Create ticket'} }}} User Agent was: `Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.8) Gecko/20100308 Iceweasel/3.5.8 (like Firefox/3.5.8)` ==== System Information ==== || '''Trac''' || `0.11.3` || || '''Python''' || `2.4.3 (#1, Jan 21 2009, 01:11:33) ` [[br]] `[GCC 4.1.2 20071124 (Red Hat 4.1.2-42)]` || || '''setuptools''' || `0.6c7` || || '''SQLite''' || `3.3.6` || || '''pysqlite''' || `2.3.3` || || '''Genshi''' || `0.5.1` || || '''Subversion''' || `1.4.6 (r28521)` || || '''jQuery:''' || `1.2.6` || ==== Python Traceback ==== {{{ Traceback (most recent call last): File "/srv/scipy/python-packages/lib/python2.4/site-packages/Trac-0.11.3-py2.4.egg/trac/web/main.py", line 435, in _dispatch_request dispatcher.dispatch(req) File "/srv/scipy/python-packages/lib/python2.4/site-packages/Trac-0.11.3-py2.4.egg/trac/web/main.py", line 205, in dispatch resp = chosen_handler.process_request(req) File "/srv/scipy/python-packages/lib/python2.4/site-packages/Trac-0.11.3-py2.4.egg/trac/ticket/web_ui.py", line 183, in process_request return self._process_newticket_request(req) File "/srv/scipy/python-packages/lib/python2.4/site-packages/Trac-0.11.3-py2.4.egg/trac/ticket/web_ui.py", line 394, in _process_newticket_request self._do_create(req, ticket) # (redirected if successful) File "/srv/scipy/python-packages/lib/python2.4/site-packages/Trac-0.11.3-py2.4.egg/trac/ticket/web_ui.py", line 981, in _do_create ticket.insert() File "/srv/scipy/python-packages/lib/python2.4/site-packages/Trac-0.11.3-py2.4.egg/trac/ticket/model.py", line 204, in insert db.commit() OperationalError: database is locked }}} a ticket. The action that triggered the error was: POST: /newticket Obviously I couldnt' file a bug report against this issue for the same reason. is there possibly a 3rd way to submit patches (mail be via snail mail)? Cheers, Yarik On Fri, 12 Mar 2010, Yaroslav Halchenko wrote: > Hi Everyone, > Being lazy and git spoiled I am exposing tentative BUG: and ENH: > commits upon your consideration: > http://github.com/yarikoptic/scipy3/commit/0cef22c0342faf8e70d84dd4008dc5ee44f365d4 > BUG: use correct string formatting in raising depending on info from lapack > http://github.com/yarikoptic/scipy3/commit/4feb14edcb9d6efdb307fc14c351aab41bad69f4 > ENH: a bit more of information upon failure in LinAlgError's from lapack > P.S. If I get a RW commit to SVN I would be happy to dcommit, or if you > instruct so I could file 'Pull request' into David's github clone, but since it > is just git-svned, not sure if it wouldn't create more problems than would > provide benefits. -- .-. =------------------------------ /v\ ----------------------------= Keep in touch // \\ (yoh@|www.)onerussian.com Yaroslav Halchenko /( )\ ICQ#: 60653192 Linux User ^^-^^ [175555] From warren.weckesser at enthought.com Mon Apr 5 15:42:44 2010 From: warren.weckesser at enthought.com (Warren Weckesser) Date: Mon, 05 Apr 2010 14:42:44 -0500 Subject: [SciPy-Dev] few patches for your consideration In-Reply-To: <20100405192925.GX8332@onerussian.com> References: <20100312144202.GN8332@onerussian.com> <20100405192925.GX8332@onerussian.com> Message-ID: <4BBA3D34.6040807@enthought.com> Yaroslav Halchenko wrote: > Dear all, > > since my humble attempt to provide patches via mailing list has > failed (noone followed) I've tried to open a ticket on trac but got: > > Oops? > Trac detected an internal error: > > OperationalError: database is locked > I've been getting that error a lot lately. I've reported it to our IT guy, Aaron, but I don't know if he's had time to look at it or what conclusion he's reached if he has looked at it. I usually just try again--eventually it works. Warren > There was an internal error in Trac. It is recommended that you inform your local Trac administrator and give him all the information he needs to reproduce the issue. > > To that end, you could ==== How to Reproduce ==== While doing a POST operation on `/newticket`, Trac issued an internal error. ''(please provide additional details here)'' Request parameters: {{{ {'__FORM_TOKEN': u'ac193bbb6eeef1400267b402', 'attachment': u'on', 'field_cc': u'', 'field_component': u'Other', 'field_description': u"String formatting is errorneous while raising exceptions in those files. Also those messages better be more informative. Thus I am providing a bugfix patch + enhancement patch for those.\r\n\r\nThey are also available from my git clone:\r\n\r\nhttp://github.com/yarikoptic/scipy3/commit/0cef22c0342faf8e70d84dd4008dc5ee44f365d4\r\nBUG: use correct string formatting in raising depending on info from lapack\r\n\r\nhttp://github.com/yarikoptic/scipy3/commit/4feb14edcb9d6efdb307fc14c351aab41bad69f4\r\nENH: a bit more of information upon failure in LinAlgError's from lapack\r\n", 'field_keywords': u'', 'field_milestone': u'0.8.0', 'field_priority': u'normal', 'field_status': u'new', 'field_summary': u'fix "unsupported format character" while raising exceptions in scipy/linalg/basic.py scipy/linalg/decomp.py', 'field_type': u'defect', 'field_version': u'0.7.0', 'submit': u'Create ticket'} }}} User Agent was: `Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.8) Gecko/20100308 Iceweasel/3.5.8 (like Firefox/3.5.8)` ==== System Information ==== || '''Trac''' || `0.11.3` || || '''Python''' || `2.4.3 (#1, Jan 21 2009, 01:11:33) ` [[br]] `[GCC 4.1.2 20071124 (Red Hat 4.1.2-42)]` || || '''setuptools''' || `0.6c7` || || '''SQLite''' || `3.3.6` || || '''pysqlite''' || `2.3.3` || || '''Genshi''' || `0.5.1` || || '''Subversion''' || `1.4.6 (r28521)` || || '''jQuery:''' || `1.2.6` || ==== Python Traceback ==== {{{ Traceback (most recent call last): File "/srv/scipy/python-packages/lib/python2.4/site-packages/Trac-0.11.3-py2.4.egg/trac/web/main.py", line 435, in _dispatch_request dispatcher.dispatch(req) File "/srv/scipy/python-packages/lib/python2.4/site-packages/Trac-0.11.3-py2.4.egg/trac/web/main.py", line 205, in dispatch resp = chosen_handler.process_request(req) File "/srv/scipy/python-packages/lib/python2.4/site-packages/Trac-0.11.3-py2.4.egg/trac/ticket/web_ui.py", line 183, in process_request return self._process_newticket_request(req) File "/srv/scipy/python-packages/lib/python2.4/site-packages/Trac-0.11.3-py2.4.egg/trac/ticket/web_ui.py", line 394, in _process_newticket_request self._do_create(req, ticket) # (redirected if successful) File "/srv/scipy/python-packages/lib/python2.4/site-packages/Trac-0.11.3-py2.4.egg/trac/ticket/web_ui.py", line 981, in _do_create ticket.insert() File "/srv/scipy/python-packages/lib/python2.4/site-packages/Trac-0.11.3-py2.4.egg/trac/ticket/model.py", line 204, in insert db.commit() OperationalError: database is locked }}} a ticket. > > The action that triggered the error was: > > POST: /newticket > > Obviously I couldnt' file a bug report against this issue for the same reason. > > is there possibly a 3rd way to submit patches (mail be via snail mail)? > > Cheers, > Yarik > On Fri, 12 Mar 2010, Yaroslav Halchenko wrote: > > >> Hi Everyone, >> > > >> Being lazy and git spoiled I am exposing tentative BUG: and ENH: >> commits upon your consideration: >> > > >> http://github.com/yarikoptic/scipy3/commit/0cef22c0342faf8e70d84dd4008dc5ee44f365d4 >> BUG: use correct string formatting in raising depending on info from lapack >> > > >> http://github.com/yarikoptic/scipy3/commit/4feb14edcb9d6efdb307fc14c351aab41bad69f4 >> ENH: a bit more of information upon failure in LinAlgError's from lapack >> > > >> P.S. If I get a RW commit to SVN I would be happy to dcommit, or if you >> instruct so I could file 'Pull request' into David's github clone, but since it >> is just git-svned, not sure if it wouldn't create more problems than would >> provide benefits. >> From bsouthey at gmail.com Mon Apr 5 22:10:43 2010 From: bsouthey at gmail.com (Bruce Southey) Date: Mon, 5 Apr 2010 21:10:43 -0500 Subject: [SciPy-Dev] request for testing: SciPy 0.7.2 RC1 + NumPy 1.4.1 RC1 In-Reply-To: References: Message-ID: On Mon, Apr 5, 2010 at 12:47 PM, Ralf Gommers wrote: > Hi everyone, > > The first release candidate of both Scipy 0.7.2 and NumPy 1.4.1 is ready, > and I want to ask for some help with testing. I'm interested to hear about > both installs where everything is OK and where there is a problem. SciPy > 0.7.2 should work with both NumPy 1.3.0 and 1.4.1. Also, reports on whether > these binaries work with matplotlib/pygame/ will > be very useful. > > For scipy 0.7.2 there are no new features compared to 0.7.1, the one change > is that all cython sources have been regenerated with cython 0.12 so the > resulting binary works with numpy 1.4.1. Numpy 1.4.1 has important bug fixes > that should have solved the incompatibilities with scipy and other packages > that were introduced with numpy 1.4.0. > > Windows binaries: > http://www.filefactory.com/file/b0ghb9e/n/numpy-1.4.1rc1-win32-superpack-python2.6.exe > http://filefactory.com/file/b0ghce6/n/scipy-0.7.2rc1-win32-superpack-python2.6.exe > > OS X binaries: > http://www.filefactory.com/file/b0gh5h1/n/numpy-1.4.1rc1-py2.6-python.org.dmg > http://www.filefactory.com/file/b0gh638/n/scipy-0.7.2rc1-py2.6-python.org.dmg > > I have not yet received the keys to the sourceforge site, so the above > temporary hosting will have to do for rc1 (apologies for the flashy ads and > download delay). Bandwidth is 150MB/hr so if the download is slow or not > working please try again a bit later. > > Known issues: > - there are failing datetime tests in numpy, they should probably be marked > as knownfail or removed from the 1.4.x branch. > - the numpy OS X installer still needs artwork. > > Cheers, > Ralf > > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev > > Hi, Numpy installed okay under Win7 32bit python but got one failure for the tests. Scipy next. Bruce Python 2.6.3 (r263rc1:75186, Oct 2 2009, 20:40:30) [MSC v.1500 32 bit (Intel)] on win32 Type "copyright", "credits" or "license()" for more information. **************************************************************** Personal firewall software may warn about the connection IDLE makes to its subprocess using this computer's internal loopback interface. This connection is not visible on any external interface and no data is sent to or received from the Internet. **************************************************************** IDLE 2.6.3 >>> import numpy >>> numpy.__version__ '1.4.1rc1' >>> numpy.test() Running unit tests for numpy NumPy version 1.4.1rc1 NumPy is installed in E:\Python26\lib\site-packages\numpy Python version 2.6.3 (r263rc1:75186, Oct 2 2009, 20:40:30) [MSC v.1500 32 bit (Intel)] nose version 0.11.1 ..................................................................................................... .............. ====================================================================== FAIL: test_special_values (test_umath_complex.TestClog) ---------------------------------------------------------------------- Traceback (most recent call last): File "E:\Python26\lib\site-packages\numpy\core\tests\test_umath_complex.py", line 179, in test_special_values assert_almost_equal(np.log(x), y) File "E:\Python26\lib\site-packages\numpy\testing\utils.py", line 437, in assert_almost_equal "DESIRED: %s\n" % (str(actual), str(desired))) AssertionError: Items are not equal: ACTUAL: [ NaN+2.35619449j] DESIRED: (inf+2.35619449019j) ---------------------------------------------------------------------- Ran 2334 tests in 30.130s FAILED (KNOWNFAIL=7, SKIP=1, failures=1) From bsouthey at gmail.com Mon Apr 5 22:19:26 2010 From: bsouthey at gmail.com (Bruce Southey) Date: Mon, 5 Apr 2010 21:19:26 -0500 Subject: [SciPy-Dev] request for testing: SciPy 0.7.2 RC1 + NumPy 1.4.1 RC1 In-Reply-To: References: Message-ID: On Mon, Apr 5, 2010 at 12:47 PM, Ralf Gommers wrote: > Hi everyone, > > The first release candidate of both Scipy 0.7.2 and NumPy 1.4.1 is ready, > and I want to ask for some help with testing. I'm interested to hear about > both installs where everything is OK and where there is a problem. SciPy > 0.7.2 should work with both NumPy 1.3.0 and 1.4.1. Also, reports on whether > these binaries work with matplotlib/pygame/ will > be very useful. > > For scipy 0.7.2 there are no new features compared to 0.7.1, the one change > is that all cython sources have been regenerated with cython 0.12 so the > resulting binary works with numpy 1.4.1. Numpy 1.4.1 has important bug fixes > that should have solved the incompatibilities with scipy and other packages > that were introduced with numpy 1.4.0. > > Windows binaries: > http://www.filefactory.com/file/b0ghb9e/n/numpy-1.4.1rc1-win32-superpack-python2.6.exe > http://filefactory.com/file/b0ghce6/n/scipy-0.7.2rc1-win32-superpack-python2.6.exe > > OS X binaries: > http://www.filefactory.com/file/b0gh5h1/n/numpy-1.4.1rc1-py2.6-python.org.dmg > http://www.filefactory.com/file/b0gh638/n/scipy-0.7.2rc1-py2.6-python.org.dmg > > I have not yet received the keys to the sourceforge site, so the above > temporary hosting will have to do for rc1 (apologies for the flashy ads and > download delay). Bandwidth is 150MB/hr so if the download is slow or not > working please try again a bit later. > > Known issues: > - there are failing datetime tests in numpy, they should probably be marked > as knownfail or removed from the 1.4.x branch. > - the numpy OS X installer still needs artwork. > > Cheers, > Ralf > > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev > > HI, Scipy installed okay on Win7 pro 32 bit Python 2.6 but the tests were interesting. Several times during the scipy.test() windows came and went. There are also warnings indicating some incompatibility. Why is the histogram warning here? It does say removal in Numpy 1.4 so should be gone. Also, shouldn't some of the other stats functions also be removed? While not your fault, we should not have these "FutureWarning" coming from the tests such as: Warning (from warnings module): File "E:\Python26\lib\site-packages\scipy\io\matlab\mio.py", line 165 oned_as=oned_as) FutureWarning: Using oned_as default value ('column') This will change to 'row' in future versions Bruce Python 2.6.3 (r263rc1:75186, Oct 2 2009, 20:40:30) [MSC v.1500 32 bit (Intel)] on win32 Type "copyright", "credits" or "license()" for more information. **************************************************************** Personal firewall software may warn about the connection IDLE makes to its subprocess using this computer's internal loopback interface. This connection is not visible on any external interface and no data is sent to or received from the Internet. **************************************************************** IDLE 2.6.3 >>> import scipy >>> scipy.__version__ '0.7.2rc1' >>> scipy.test() Running unit tests for scipy NumPy version 1.4.1rc1 NumPy is installed in E:\Python26\lib\site-packages\numpy SciPy version 0.7.2rc1 SciPy is installed in E:\Python26\lib\site-packages\scipy Python version 2.6.3 (r263rc1:75186, Oct 2 2009, 20:40:30) [MSC v.1500 32 bit (Intel)] nose version 0.11.1 Warning (from warnings module): File "E:\Python26\lib\site-packages\scipy\spatial\__init__.py", line 7 from ckdtree import * RuntimeWarning: numpy.dtype size changed, may indicate binary incompatibility Warning (from warnings module): File "E:\Python26\lib\site-packages\scipy\spatial\__init__.py", line 7 from ckdtree import * RuntimeWarning: numpy.flatiter size changed, may indicate binary incompatibility Warning (from warnings module): File "E:\Python26\lib\site-packages\scipy\linsolve\__init__.py", line 4 warn('scipy.linsolve has moved to scipy.sparse.linalg.dsolve', DeprecationWarning) DeprecationWarning: scipy.linsolve has moved to scipy.sparse.linalg.dsolve Warning (from warnings module): File "E:\Python26\lib\site-packages\scipy\stats\distributions.py", line 27 import vonmises_cython RuntimeWarning: numpy.dtype size changed, may indicate binary incompatibility Warning (from warnings module): File "E:\Python26\lib\site-packages\scipy\stats\distributions.py", line 27 import vonmises_cython RuntimeWarning: numpy.flatiter size changed, may indicate binary incompatibility ...................................................................................................................................................... Warning (from warnings module): File "E:\Python26\lib\site-packages\scipy\cluster\vq.py", line 570 warnings.warn("One of the clusters is empty. " UserWarning: One of the clusters is empty. Re-run kmean with a different initialization. ....................................................................... Warning (from warnings module): File "E:\Python26\lib\site-packages\scipy\interpolate\fitpack2.py", line 498 warnings.warn(message) 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. ..... Warning (from warnings module): File "E:\Python26\lib\site-packages\scipy\interpolate\fitpack2.py", line 439 warnings.warn(message) 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. ...........................................K..K................................................................................................. Warning (from warnings module): File "E:\Python26\lib\site-packages\scipy\io\matlab\mio.py", line 111 matfile_dict = MR.get_variables() Warning: Unreadable variable "testfunc", because "Cannot read matlab functions" .......... Warning (from warnings module): File "E:\Python26\lib\site-packages\scipy\io\matlab\mio.py", line 165 oned_as=oned_as) FutureWarning: Using oned_as default value ('column') This will change to 'row' in future versions ......................... Warning (from warnings module): File "E:\Python26\lib\site-packages\scipy\io\matlab\tests\test_mio.py", line 438 mfw = MatFile5Writer(StringIO()) FutureWarning: Using oned_as default value ('column') This will change to 'row' in future versions ........ Warning (from warnings module): File "E:\Python26\lib\site-packages\scipy\io\matlab\mio.py", line 84 return MatFile5Reader(byte_stream, **kwargs) FutureWarning: Using struct_as_record default value (False) This will change to True in future versions ................................ Warning (from warnings module): File "E:\Python26\lib\site-packages\numpy\lib\utils.py", line 140 warnings.warn(depdoc, DeprecationWarning) DeprecationWarning: `write_array` is deprecated! This function is replaced by numpy.savetxt which allows the same functionality through a different syntax. Warning (from warnings module): File "E:\Python26\lib\site-packages\numpy\lib\utils.py", line 140 warnings.warn(depdoc, DeprecationWarning) DeprecationWarning: `read_array` is deprecated! The functionality of read_array is in numpy.loadtxt which allows the same functionality using different syntax. ....................... Warning (from warnings module): File "E:\Python26\lib\site-packages\numpy\lib\utils.py", line 140 warnings.warn(depdoc, DeprecationWarning) DeprecationWarning: `npfile` is deprecated! You can achieve the same effect as using npfile, using ndarray.tofile and numpy.fromfile. Even better you can use memory-mapped arrays and data-types to map out a file format for direct manipulation in NumPy. .........................................................................................................................................................SSSSSS......SSSSSS......SSSS.............................................................S..................................................... Warning (from warnings module): File "E:\Python26\lib\site-packages\scipy\linalg\decomp.py", line 1177 "the mode='economic' argument.", DeprecationWarning) DeprecationWarning: qr econ argument will be removed after scipy 0.7. The economy transform will then be available through the mode='economic' argument. .............................................................................................................................................................................................................................................................................................Result may be inaccurate, approximate err = 5.76591035582e-08 ...Result may be inaccurate, approximate err = 1.00314019744e-10 .....SSS..................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................SSSSSSSSSSS...........................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................K.K........................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................... Warning (from warnings module): File "E:\Python26\lib\site-packages\numpy\lib\function_base.py", line 185 """, Warning) Warning: The new semantics of histogram is now the default and the `new` keyword will be removed in NumPy 1.4. ....................................................................................S.................................................................................. Warning (from warnings module): File "E:\Python26\lib\site-packages\scipy\stats\stats.py", line 420 axis=0, ddof=1).""", DeprecationWarning) DeprecationWarning: scipy.stats.mean is deprecated; please update your code to use numpy.mean. Please note that: - numpy.mean axis argument defaults to None, not 0 - numpy.mean has a ddof argument to replace bias in a more general manner. scipy.stats.mean(a, bias=True) can be replaced by numpy.mean(x, axis=0, ddof=1). . Warning (from warnings module): File "E:\Python26\lib\site-packages\scipy\stats\stats.py", line 1329 ddof=1).""", DeprecationWarning) DeprecationWarning: scipy.stats.std is deprecated; please update your code to use numpy.std. Please note that: - numpy.std axis argument defaults to None, not 0 - numpy.std has a ddof argument to replace bias in a more general manner. scipy.stats.std(a, bias=True) can be replaced by numpy.std(x, axis=0, ddof=0), scipy.stats.std(a, bias=False) by numpy.std(x, axis=0, ddof=1). Warning (from warnings module): File "E:\Python26\lib\site-packages\scipy\stats\stats.py", line 1305 ddof=1).""", DeprecationWarning) DeprecationWarning: scipy.stats.var is deprecated; please update your code to use numpy.var. Please note that: - numpy.var axis argument defaults to None, not 0 - numpy.var has a ddof argument to replace bias in a more general manner. scipy.stats.var(a, bias=True) can be replaced by numpy.var(x, axis=0, ddof=0), scipy.stats.var(a, bias=False) by var(x, axis=0, ddof=1). . Warning (from warnings module): File "E:\Python26\lib\site-packages\scipy\stats\morestats.py", line 603 warnings.warn("Ties preclude use of exact statistic.") UserWarning: Ties preclude use of exact statistic. ...... Warning (from warnings module): File "E:\Python26\lib\site-packages\scipy\stats\stats.py", line 498 axis=0, ddof=1).""", DeprecationWarning) DeprecationWarning: scipy.stats.median is deprecated; please update your code to use numpy.median. Please note that: - numpy.median axis argument defaults to None, not 0 - numpy.median has a ddof argument to replace bias in a more general manner. scipy.stats.median(a, bias=True) can be replaced by numpy.median(x, axis=0, ddof=1). ....................................................................................................................................................................................................Warning: friedmanchisquare test using Chisquared aproximation ...............warning: specified build_dir '_bad_path_' does not exist or is not writable. Trying default locations .....warning: specified build_dir '_bad_path_' does not exist or is not writable. Trying default locations .............................error removing e:\users\me\appdata\local\temp\tmpumnxuucat_test: e:\users\me\appdata\local\temp\tmpumnxuucat_test: The directory is not empty ..building extensions here: e:\users\me\appdata\local\temp\Me\python26_compiled\m0 ................................................................................................ ---------------------------------------------------------------------- Ran 3488 tests in 65.938s OK (KNOWNFAIL=4, SKIP=32) >>> From aisaac at american.edu Mon Apr 5 22:57:37 2010 From: aisaac at american.edu (Alan G Isaac) Date: Mon, 05 Apr 2010 22:57:37 -0400 Subject: [SciPy-Dev] request for testing: SciPy 0.7.2 RC1 + NumPy 1.4.1 RC1 In-Reply-To: References: Message-ID: <4BBAA321.7080204@american.edu> Python 2.6.5 (32bit) under Vista (64bit). Alan Isaac ====================================================================== FAIL: test_special_values (test_umath_complex.TestClog) ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\Python26\lib\site-packages\numpy\core\tests\test_umath_complex.py", l ine 179, in test_special_values assert_almost_equal(np.log(x), y) File "C:\Python26\lib\site-packages\numpy\testing\utils.py", line 437, in asse rt_almost_equal "DESIRED: %s\n" % (str(actual), str(desired))) AssertionError: Items are not equal: ACTUAL: [ NaN+2.35619449j] DESIRED: (inf+2.35619449019j) ---------------------------------------------------------------------- Ran 2334 tests in 14.010s FAILED (KNOWNFAIL=7, SKIP=1, failures=1) From aisaac at american.edu Mon Apr 5 23:08:48 2010 From: aisaac at american.edu (Alan G Isaac) Date: Mon, 05 Apr 2010 23:08:48 -0400 Subject: [SciPy-Dev] request for testing: SciPy 0.7.2 RC1 + NumPy 1.4.1 RC1 In-Reply-To: References: Message-ID: <4BBAA5C0.1030601@american.edu> Python 2.6.5 (32bit) on Vista (64bit), no gcc. Alan Isaac c:\Python26\lib\site-packages\scipy\spatial\__init__.py:7: RuntimeWarning: numpy.dtype size changed, may indicate binary incompatibility from ckdtree import * c:\Python26\lib\site-packages\scipy\spatial\__init__.py:7: RuntimeWarning: numpy.flatiter size changed, may indicate binary incompatibility from ckdtree import * c:\Python26\lib\site-packages\scipy\linsolve\__init__.py:4: DeprecationWarning: scipy.linsolve has moved to scipy.sparse.linalg.dsolve warn('scipy.linsolve has moved to scipy.sparse.linalg.dsolve', DeprecationWarning) c:\Python26\lib\site-packages\scipy\stats\distributions.py:27: RuntimeWarning: numpy.dtype size changed, may indicate binary incompatibility import vonmises_cython c:\Python26\lib\site-packages\scipy\stats\distributions.py:27: RuntimeWarning: numpy.flatiter size changed, may indicate binary incompatibility import vonmises_cython .............................................................................................................................................................................................................................c:\Python26\lib\site-packages\scipy\interpolate\fitpack2.py:498: 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) .....c:\Python26\lib\site-packages\scipy\interpolate\fitpack2.py:439: 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.................................................................................................c:\Python26\lib\site-packages\scipy\io\matlab\mio.py:111: Warning: Unreadable variable "testfunc", because "Cannot read matlab functions" matfile_dict = MR.get_variables() ..........c:\Python26\lib\site-packages\scipy\io\matlab\mio.py:165: FutureWarning: Using oned_as default value ('column') This will change to 'row' in future versions oned_as=oned_as) .........................c:\Python26\lib\site-packages\scipy\io\matlab\tests\test_mio.py:438: FutureWarning: Using oned_as default value ('column') This will change to 'row' in future versions mfw = MatFile5Writer(StringIO()) ........c:\Python26\lib\site-packages\scipy\io\matlab\mio.py:84: FutureWarning: Using struct_as_record default value (False) This will change to True in future versions return MatFile5Reader(byte_stream, **kwargs) ...............................Warning: 1000000 bytes requested, 20 bytes read. .c:\Python26\lib\site-packages\numpy\lib\utils.py:140: DeprecationWarning: `write_array` is deprecated! This function is replaced by numpy.savetxt which allows the same functionality through a different syntax. warnings.warn(depdoc, DeprecationWarning) c:\Python26\lib\site-packages\numpy\lib\utils.py:140: DeprecationWarning: `read_array` is deprecated! The functionality of read_array is in numpy.loadtxt which allows the same functionality using different syntax. warnings.warn(depdoc, DeprecationWarning) .......................c:\Python26\lib\site-packages\numpy\lib\utils.py:140: DeprecationWarning: `npfile` is deprecated! You can achieve the same effect as using npfile, using ndarray.tofile and numpy.fromfile. Even better you can use memory-mapped arrays and data-types to map out a file format for direct manipulation in NumPy. warnings.warn(depdoc, DeprecationWarning) .........................................................................................................................................................SSSSSS......SSSSSS......SSSS.............................................................S.....................................................c:\Python26\lib\site-packages\scipy\linalg\decomp.py:1177: DeprecationWarning: qr econ argument will be removed after scipy 0.7. The economy transform will then be available through the mode='economic' argument. "the mode='economic' argument.", DeprecationWarning) .....................................................................................................................................................................................................................................................................................................SSS.......................................................................................................................................................................................................................................................................................................................................................................................................................................................E..........................................................SSSSSSSSSSS........................................................................................................................................................................................ ...................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................K.K........................................................................................................................................................................................................................................................................................................................................................................................................................................................ ...................................................................................................................................................................................................................................c:\Python26\lib\site-packages\numpy\lib\function_base.py:185: Warning: The new semantics of histogram is now the default and the `new` keyword will be removed in NumPy 1.4. """, Warning) ....................................................................................S..................................................................................c:\Python26\lib\site-packages\scipy\stats\stats.py:420: DeprecationWarning: scipy.stats.mean is deprecated; please update your code to use numpy.mean. Please note that: - numpy.mean axis argument defaults to None, not 0 - numpy.mean has a ddof argument to replace bias in a more general manner. scipy.stats.mean(a, bias=True) can be replaced by numpy.mean(x, axis=0, ddof=1). axis=0, ddof=1).""", DeprecationWarning) .c:\Python26\lib\site-packages\scipy\stats\stats.py:1329: DeprecationWarning: scipy.stats.std is deprecated; please update your code to use numpy.std. Please note that: - numpy.std axis argument defaults to None, not 0 - numpy.std has a ddof argument to replace bias in a more general manner. scipy.stats.std(a, bias=True) can be replaced by numpy.std(x, axis=0, ddof=0), scipy.stats.std(a, bias=False) by numpy.std(x, axis=0, ddof=1). ddof=1).""", DeprecationWarning) c:\Python26\lib\site-packages\scipy\stats\stats.py:1305: DeprecationWarning: scipy.stats.var is deprecated; please update your code to use numpy.var. Please note that: - numpy.var axis argument defaults to None, not 0 - numpy.var has a ddof argument to replace bias in a more general manner. scipy.stats.var(a, bias=True) can be replaced by numpy.var(x, axis=0, ddof=0), scipy.stats.var(a, bias=False) by var(x, axis=0, ddof=1). ddof=1).""", DeprecationWarning) .c:\Python26\lib\site-packages\scipy\stats\morestats.py:603: UserWarning: Ties preclude use of exact statistic. warnings.warn("Ties preclude use of exact statistic.") ......c:\Python26\lib\site-packages\scipy\stats\stats.py:498: DeprecationWarning: scipy.stats.median is deprecated; please update your code to use numpy.median. Please note that: - numpy.median axis argument defaults to None, not 0 - numpy.median has a ddof argument to replace bias in a more general manner. scipy.stats.median(a, bias=True) can be replaced by numpy.median(x, axis=0, ddof=1). axis=0, ddof=1).""", DeprecationWarning) ............................................................................................................................................................................................................................'gcc' is not recognized as an internal or external command, operable program or batch file. 'gcc' is not recognized as an internal or external command, operable program or batch file. 'gcc' is not recognized as an internal or external command, operable program or batch file. 'gcc' is not recognized as an internal or external command, operable program or batch file. 'gcc' is not recognized as an internal or external command, operable program or batch file. 'gcc' is not recognized as an internal or external command, operable program or batch file. 'gcc' is not recognized as an internal or external command, operable program or batch file. 'gcc' is not recognized as an internal or external command, operable program or batch file. 'gcc' is not recognized as an internal or external command, operable program or batch file. 'gcc' is not recognized as an internal or external command, operable program or batch file. 'gcc' is not recognized as an internal or external command, operable program or batch file. .........................Running unit tests for scipy NumPy version 1.4.1rc1 NumPy is installed in c:\Python26\lib\site-packages\numpy SciPy version 0.7.2rc1 SciPy is installed in c:\Python26\lib\site-packages\scipy Python version 2.6.5 (r265:79096, Mar 19 2010, 21:48:26) [MSC v.1500 32 bit (Intel)] nose version 0.11.0 Result may be inaccurate, approximate err = 1.32856435107e-08 Result may be inaccurate, approximate err = 1.00314019744e-10 Warning: friedmanchisquare test using Chisquared aproximation warning: specified build_dir '_bad_path_' does not exist or is not writable. Trying default locations warning: specified build_dir '_bad_path_' does not exist or is not writable. Trying default locations error removing c:\users\alanis~1\appdata\local\temp\tmpyqscdicat_test: c:\users\alanis~1\appdata\local\temp\tmpyqscdicat_test: The directory is not empty ...'gcc' is not recognized as an internal or external command, operable program or batch file. 'gcc' is not recognized as an internal or external command, operable program or batch file. ............................................................................................... ====================================================================== ERROR: line-search Newton conjugate gradient optimization routine ---------------------------------------------------------------------- Traceback (most recent call last): File "c:\Python26\lib\site-packages\scipy\optimize\tests\test_optimize.py", line 113, in test_ncg retall=False) File "c:\Python26\lib\site-packages\scipy\optimize\optimize.py", line 1088, in fmin_ncg alphak, fc, gc, old_fval = line_search_BFGS(f,xk,pk,gfk,old_fval) File "c:\Python26\lib\site-packages\scipy\optimize\optimize.py", line 591, in line_search_BFGS phi_a2 = f(*((xk+alpha2*pk,)+args)) File "c:\Python26\lib\site-packages\scipy\optimize\optimize.py", line 97, in function_wrapper return function(x, *args) File "c:\Python26\lib\site-packages\scipy\optimize\tests\test_optimize.py", line 39, in func raise RuntimeError, "too many iterations in optimization routine" RuntimeError: too many iterations in optimization routine ---------------------------------------------------------------------- Ran 3488 tests in 43.359s FAILED (KNOWNFAIL=4, SKIP=32, errors=1) building extensions here: c:\users\alanis~1\appdata\local\temp\Alan Isaac\python26_compiled\m2 ATLAS version 3.8.3 built by Administrator on Sun Nov 29 23:44:07 KST 2009: UNAME : CYGWIN_NT-5.1 david-70582ba55 1.5.25(0.156/4/2) 2008-06-12 19:34 i686 Cygwin INSTFLG : -1 0 -a 1 ARCHDEFS : -DATL_OS_WinNT -DATL_ARCH_Corei7 -DGCCWIN -DUseClock -DATL_SSE3 -DATL_SSE2 -DATL_SSE1 -DATL_GAS_x8632 F2CDEFS : -DAdd__ -DF77_INTEGER=int -DStringSunStyle CACHEEDGE: 524288 F77 : g77, version GNU Fortran (GCC) 3.4.4 (cygming special, gdc 0.12, using dmd 0.125) F77FLAGS : -O -m32 SMC : gcc, version gcc (GCC) 3.4.4 (cygming special, gdc 0.12, using dmd 0.125) SMCFLAGS : -fomit-frame-pointer -mfpmath=sse -msse3 -O2 -fno-schedule-insns2 -m32 SKC : gcc, version gcc (GCC) 3.4.4 (cygming special, gdc 0.12, using dmd 0.125) SKCFLAGS : -fomit-frame-pointer -mfpmath=sse -msse3 -O2 -fno-schedule-insns2 -m32 From ralf.gommers at googlemail.com Mon Apr 5 23:33:26 2010 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Tue, 6 Apr 2010 11:33:26 +0800 Subject: [SciPy-Dev] request for testing: SciPy 0.7.2 RC1 + NumPy 1.4.1 RC1 In-Reply-To: References: Message-ID: On Tue, Apr 6, 2010 at 10:19 AM, Bruce Southey wrote: > HI, > Scipy installed okay on Win7 pro 32 bit Python 2.6 but the tests were > interesting. Several times during the scipy.test() windows came and > went. There are also warnings indicating some incompatibility. > Windows should not be popping up, unless you're also running doctests with plot commands. Any idea what they are? If not, can you narrow it down by running tests for the individual modules? > Why is the histogram warning here? It does say removal in Numpy 1.4 so > should be gone. Also, shouldn't some of the other stats functions also > be removed? > These things should have been removed but weren't in 1.4.0, I just kept it that way. It can still be removed of course, but maybe this is better done (or already done) in trunk? > While not your fault, we should not have these "FutureWarning" coming > from the tests such as: > Warning (from warnings module): > File "E:\Python26\lib\site-packages\scipy\io\matlab\mio.py", line 165 > oned_as=oned_as) > FutureWarning: Using oned_as default value ('column') This will change > to 'row' in future versions > The test output is very chatty. Again, I wanted to keep things the same as 0.7.1 except for fixing the binary incompatibility issue. For 0.8 I think all these warnings should be cleaned up, but does it make sense to do that in this bug fix release? The same goes for the build output by the way, long lists of complaints about tab characters, unused variables, etc. Would be good to start cleaning that up for 0.8. Cheers, Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.gommers at googlemail.com Mon Apr 5 23:34:48 2010 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Tue, 6 Apr 2010 11:34:48 +0800 Subject: [SciPy-Dev] request for testing: SciPy 0.7.2 RC1 + NumPy 1.4.1 RC1 In-Reply-To: <4BBAA321.7080204@american.edu> References: <4BBAA321.7080204@american.edu> Message-ID: On Tue, Apr 6, 2010 at 10:57 AM, Alan G Isaac wrote: > Python 2.6.5 (32bit) under Vista (64bit). > Alan Isaac > > ====================================================================== > FAIL: test_special_values (test_umath_complex.TestClog) > ---------------------------------------------------------------------- > Traceback (most recent call last): > File > "C:\Python26\lib\site-packages\numpy\core\tests\test_umath_complex.py", l > ine 179, in test_special_values > assert_almost_equal(np.log(x), y) > File "C:\Python26\lib\site-packages\numpy\testing\utils.py", line 437, in > asse > rt_almost_equal > "DESIRED: %s\n" % (str(actual), str(desired))) > AssertionError: Items are not equal: > ACTUAL: [ NaN+2.35619449j] > DESIRED: (inf+2.35619449019j) > > This does not indicate a problem I suppose, but an outdated test. I'll have a look at it later. Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.gommers at googlemail.com Mon Apr 5 23:38:37 2010 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Tue, 6 Apr 2010 11:38:37 +0800 Subject: [SciPy-Dev] request for testing: SciPy 0.7.2 RC1 + NumPy 1.4.1 RC1 In-Reply-To: <4BBAA5C0.1030601@american.edu> References: <4BBAA5C0.1030601@american.edu> Message-ID: On Tue, Apr 6, 2010 at 11:08 AM, Alan G Isaac wrote: > Python 2.6.5 (32bit) on Vista (64bit), no gcc. > Alan Isaac > > c:\Python26\lib\site-packages\scipy\spatial\__init__.py:7: RuntimeWarning: > numpy.dtype size changed, may indicate binary incompatibility > from ckdtree import * > c:\Python26\lib\site-packages\scipy\spatial\__init__.py:7: RuntimeWarning: > numpy.flatiter size changed, may indicate binary incompatibility > from ckdtree import * > c:\Python26\lib\site-packages\scipy\linsolve\__init__.py:4: > DeprecationWarning: scipy.linsolve has moved to scipy.sparse.linalg.dsolve > warn('scipy.linsolve has moved to scipy.sparse.linalg.dsolve', > DeprecationWarning) > c:\Python26\lib\site-packages\scipy\stats\distributions.py:27: > RuntimeWarning: numpy.dtype size changed, may indicate binary > incompatibility > import vonmises_cython > c:\Python26\lib\site-packages\scipy\stats\distributions.py:27: > RuntimeWarning: numpy.flatiter size changed, may indicate binary > incompatibility > import vonmises_cython > > .................................................................................................................................................................................................................. > Can you please double check that it's not picking up some left-over from 1.4.0 on your system? This really should have been fixed. ............................................................................................... > ====================================================================== > ERROR: line-search Newton conjugate gradient optimization routine > ---------------------------------------------------------------------- > Traceback (most recent call last): > File > "c:\Python26\lib\site-packages\scipy\optimize\tests\test_optimize.py", line > 113, in test_ncg > retall=False) > File "c:\Python26\lib\site-packages\scipy\optimize\optimize.py", line > 1088, in fmin_ncg > alphak, fc, gc, old_fval = line_search_BFGS(f,xk,pk,gfk,old_fval) > File "c:\Python26\lib\site-packages\scipy\optimize\optimize.py", line > 591, in line_search_BFGS > phi_a2 = f(*((xk+alpha2*pk,)+args)) > File "c:\Python26\lib\site-packages\scipy\optimize\optimize.py", line 97, > in function_wrapper > return function(x, *args) > File > "c:\Python26\lib\site-packages\scipy\optimize\tests\test_optimize.py", line > 39, in func > raise RuntimeError, "too many iterations in optimization routine" > RuntimeError: too many iterations in optimization routine > > Not sure what this is about. Anyone have an idea? Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From josef.pktd at gmail.com Mon Apr 5 23:53:32 2010 From: josef.pktd at gmail.com (josef.pktd at gmail.com) Date: Mon, 5 Apr 2010 23:53:32 -0400 Subject: [SciPy-Dev] request for testing: SciPy 0.7.2 RC1 + NumPy 1.4.1 RC1 In-Reply-To: References: <4BBAA5C0.1030601@american.edu> Message-ID: On Mon, Apr 5, 2010 at 11:38 PM, Ralf Gommers wrote: > > > On Tue, Apr 6, 2010 at 11:08 AM, Alan G Isaac wrote: >> >> Python 2.6.5 (32bit) on Vista (64bit), no gcc. >> Alan Isaac >> >> c:\Python26\lib\site-packages\scipy\spatial\__init__.py:7: RuntimeWarning: >> numpy.dtype size changed, may indicate binary incompatibility >> ? from ckdtree import * >> c:\Python26\lib\site-packages\scipy\spatial\__init__.py:7: RuntimeWarning: >> numpy.flatiter size changed, may indicate binary incompatibility >> ? from ckdtree import * >> c:\Python26\lib\site-packages\scipy\linsolve\__init__.py:4: >> DeprecationWarning: scipy.linsolve has moved to scipy.sparse.linalg.dsolve >> ? warn('scipy.linsolve has moved to scipy.sparse.linalg.dsolve', >> DeprecationWarning) >> c:\Python26\lib\site-packages\scipy\stats\distributions.py:27: >> RuntimeWarning: numpy.dtype size changed, may indicate binary >> incompatibility >> ? import vonmises_cython >> c:\Python26\lib\site-packages\scipy\stats\distributions.py:27: >> RuntimeWarning: numpy.flatiter size changed, may indicate binary >> incompatibility >> ? import vonmises_cython >> >> .................................................................................................................................................................................................................. > > Can you please double check that it's not picking up some left-over from > 1.4.0 on your system? This really should have been fixed. > >> >> ............................................................................................... >> ====================================================================== >> ERROR: line-search Newton conjugate gradient optimization routine >> ---------------------------------------------------------------------- >> Traceback (most recent call last): >> ? File >> "c:\Python26\lib\site-packages\scipy\optimize\tests\test_optimize.py", line >> 113, in test_ncg >> ? ? retall=False) >> ? File "c:\Python26\lib\site-packages\scipy\optimize\optimize.py", line >> 1088, in fmin_ncg >> ? ? alphak, fc, gc, old_fval = line_search_BFGS(f,xk,pk,gfk,old_fval) >> ? File "c:\Python26\lib\site-packages\scipy\optimize\optimize.py", line >> 591, in line_search_BFGS >> ? ? phi_a2 = f(*((xk+alpha2*pk,)+args)) >> ? File "c:\Python26\lib\site-packages\scipy\optimize\optimize.py", line >> 97, in function_wrapper >> ? ? return function(x, *args) >> ? File >> "c:\Python26\lib\site-packages\scipy\optimize\tests\test_optimize.py", line >> 39, in func >> ? ? raise RuntimeError, "too many iterations in optimization routine" >> RuntimeError: too many iterations in optimization routine >> > Not sure what this is about. Anyone have an idea? I've never seen this before, the test specifically checks for less than 6000 function calls, fmin_ncg needs obviously more. I would have guessed on a problem with the convergence criteria in the 64/32bit combination but don't see anything suspicious. Alan, just checking, what is np.sqrt(np.finfo(float).eps) on your machine? Josef > > Ralf > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev > > From josef.pktd at gmail.com Tue Apr 6 00:10:42 2010 From: josef.pktd at gmail.com (josef.pktd at gmail.com) Date: Tue, 6 Apr 2010 00:10:42 -0400 Subject: [SciPy-Dev] request for testing: SciPy 0.7.2 RC1 + NumPy 1.4.1 RC1 In-Reply-To: References: <4BBAA5C0.1030601@american.edu> Message-ID: On Mon, Apr 5, 2010 at 11:38 PM, Ralf Gommers wrote: > > > On Tue, Apr 6, 2010 at 11:08 AM, Alan G Isaac wrote: >> >> Python 2.6.5 (32bit) on Vista (64bit), no gcc. >> Alan Isaac >> >> c:\Python26\lib\site-packages\scipy\spatial\__init__.py:7: RuntimeWarning: >> numpy.dtype size changed, may indicate binary incompatibility >> ? from ckdtree import * >> c:\Python26\lib\site-packages\scipy\spatial\__init__.py:7: RuntimeWarning: >> numpy.flatiter size changed, may indicate binary incompatibility >> ? from ckdtree import * >> c:\Python26\lib\site-packages\scipy\linsolve\__init__.py:4: >> DeprecationWarning: scipy.linsolve has moved to scipy.sparse.linalg.dsolve >> ? warn('scipy.linsolve has moved to scipy.sparse.linalg.dsolve', >> DeprecationWarning) >> c:\Python26\lib\site-packages\scipy\stats\distributions.py:27: >> RuntimeWarning: numpy.dtype size changed, may indicate binary >> incompatibility >> ? import vonmises_cython >> c:\Python26\lib\site-packages\scipy\stats\distributions.py:27: >> RuntimeWarning: numpy.flatiter size changed, may indicate binary >> incompatibility >> ? import vonmises_cython These are now just Warnings. My thought was that maybe the new version of cython raises a warning when it encounters the binary size mismatch instead of the exception that it raised before. (I think "from scipy import stats" or "from scipy import vonmises" (in a fresh interpreter session) should show whether the cython problem is solved.) Just a guess, (I will test tomorrow on XP) Josef >> .................................................................................................................................................................................................................. > > Can you please double check that it's not picking up some left-over from > 1.4.0 on your system? This really should have been fixed. > >> >> ............................................................................................... >> ====================================================================== >> ERROR: line-search Newton conjugate gradient optimization routine >> ---------------------------------------------------------------------- >> Traceback (most recent call last): >> ? File >> "c:\Python26\lib\site-packages\scipy\optimize\tests\test_optimize.py", line >> 113, in test_ncg >> ? ? retall=False) >> ? File "c:\Python26\lib\site-packages\scipy\optimize\optimize.py", line >> 1088, in fmin_ncg >> ? ? alphak, fc, gc, old_fval = line_search_BFGS(f,xk,pk,gfk,old_fval) >> ? File "c:\Python26\lib\site-packages\scipy\optimize\optimize.py", line >> 591, in line_search_BFGS >> ? ? phi_a2 = f(*((xk+alpha2*pk,)+args)) >> ? File "c:\Python26\lib\site-packages\scipy\optimize\optimize.py", line >> 97, in function_wrapper >> ? ? return function(x, *args) >> ? File >> "c:\Python26\lib\site-packages\scipy\optimize\tests\test_optimize.py", line >> 39, in func >> ? ? raise RuntimeError, "too many iterations in optimization routine" >> RuntimeError: too many iterations in optimization routine >> > Not sure what this is about. Anyone have an idea? > > Ralf > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev > > From warren.weckesser at enthought.com Tue Apr 6 01:13:10 2010 From: warren.weckesser at enthought.com (Warren Weckesser) Date: Tue, 06 Apr 2010 00:13:10 -0500 Subject: [SciPy-Dev] "Automatically adapted for scipy..." Message-ID: <4BBAC2E6.6060204@enthought.com> At or close to the top of many of the python files in scipy is a comment that says something like ## Automatically adapted for scipy Oct 18, 2005 by or ## Automatically adapted for scipy Oct 07, 2005 by convertcode.py Are these comments still meaningful? Is there any harm in removing them? Warren From josef.pktd at gmail.com Tue Apr 6 01:15:34 2010 From: josef.pktd at gmail.com (josef.pktd at gmail.com) Date: Tue, 6 Apr 2010 01:15:34 -0400 Subject: [SciPy-Dev] optimize ncg approx_fhess_p bug? Message-ID: is this a bug? why is there a `*p` in the approx_fhess def approx_fhess_p(x0,p,fprime,epsilon,*args): f2 = fprime(*((x0+epsilon*p,)+args)) f1 = fprime(*((x0,)+args)) return (f2 - f1)/epsilon from a quick search this function is only used in fmin_ncg, which has convergence problem if epsilon is small. convergence to solution looks ok when I set epsilon to 1e-4 or 1e-6. but with predefined epsilon the step in the approx hessian calculation looks to small: >>> t.grad(t.solution)*_epsilon array([ 0.00000000e+00, -7.71175966e-16, -6.94483304e-15]) non-convergence was a test failure reported by Alan with scipy 0.7.2 I'm not sure about this because I never looked at the optimize code before, and I only did some quick checking. dropping the p in the approx fhess, I get a very fast solution (full_output) of the test problem in optimize/tests/optimize.py (array([ 1.46693016e-07, -5.24869440e-01, 4.87527692e-01]), 1.55913216727411 23, 5, 18, 0, 0) Any ideas? Josef From aisaac at american.edu Tue Apr 6 08:28:43 2010 From: aisaac at american.edu (Alan G Isaac) Date: Tue, 06 Apr 2010 08:28:43 -0400 Subject: [SciPy-Dev] request for testing: SciPy 0.7.2 RC1 + NumPy 1.4.1 RC1 In-Reply-To: References: <4BBAA5C0.1030601@american.edu> Message-ID: <4BBB28FB.4050801@american.edu> >> Python 2.6.5 (32bit) on Vista (64bit), no gcc. >> >> c:\Python26\lib\site-packages\scipy\stats\distributions.py:27: >> RuntimeWarning: numpy.flatiter size changed, may indicate binary >> incompatibility >> import vonmises_cython On 4/5/2010 11:38 PM, Ralf Gommers wrote: > Can you please double check that it's not picking up some left-over from > 1.4.0 on your system? This really should have been fixed. Did you mena from NumPy, or from SciPy? (The above is the SciPy test.) As for NumPy, I do not think that I ever installed 1.4.0 on this machine. I uninstalled 1.3 usng the Windows uninstall facility and installed from the superpacks. The uninstall completely removes the old directory in site-packages. I'd need a suggestion for what else to do. Alan From aisaac at american.edu Tue Apr 6 08:31:50 2010 From: aisaac at american.edu (Alan G Isaac) Date: Tue, 06 Apr 2010 08:31:50 -0400 Subject: [SciPy-Dev] request for testing: SciPy 0.7.2 RC1 + NumPy 1.4.1 RC1 In-Reply-To: References: <4BBAA5C0.1030601@american.edu> Message-ID: <4BBB29B6.7060607@american.edu> On 4/5/2010 11:53 PM, josef.pktd at gmail.com wrote: > what is > np.sqrt(np.finfo(float).eps) > on your machine? >>> np.finfo(float).eps 2.2204460492503131e-16 >>> np.sqrt(np.finfo(float).eps) 1.4901161193847656e-08 Alan (Python 2.6.5 (32bit) under Vista (64bit)) From aisaac at american.edu Tue Apr 6 08:34:52 2010 From: aisaac at american.edu (Alan G Isaac) Date: Tue, 06 Apr 2010 08:34:52 -0400 Subject: [SciPy-Dev] request for testing: SciPy 0.7.2 RC1 + NumPy 1.4.1 RC1 In-Reply-To: References: <4BBAA5C0.1030601@american.edu> Message-ID: <4BBB2A6C.8040503@american.edu> On 4/6/2010 12:10 AM, josef.pktd at gmail.com wrote: > I think "from scipy import stats" or "from scipy import vonmises" (in > a fresh interpreter session) should show whether the cython problem is > solved. Python 2.6.5 (r265:79096, Mar 19 2010, 21:48:26) [MSC v.1500 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> from scipy import stats C:\Python26\lib\site-packages\scipy\stats\distributions.py:27: RuntimeWarning: numpy.dtype size changed, may indicate binary incompatibility import vonmises_cython C:\Python26\lib\site-packages\scipy\stats\distributions.py:27: RuntimeWarning: numpy.flatiter size changed, may indicate binary incompatibility import vonmises_cython >>> hth, Alan From josef.pktd at gmail.com Tue Apr 6 09:00:24 2010 From: josef.pktd at gmail.com (josef.pktd at gmail.com) Date: Tue, 6 Apr 2010 09:00:24 -0400 Subject: [SciPy-Dev] optimize ncg approx_fhess_p bug? In-Reply-To: References: Message-ID: On Tue, Apr 6, 2010 at 1:15 AM, wrote: > is this a bug? > > why is there a ?`*p` in the approx_fhess > > def approx_fhess_p(x0,p,fprime,epsilon,*args): > ? ?f2 = fprime(*((x0+epsilon*p,)+args)) > ? ?f1 = fprime(*((x0,)+args)) > ? ?return (f2 - f1)/epsilon > > from a quick search this function is only used in fmin_ncg, which has > convergence problem if epsilon is small. > convergence to solution looks ok when I set epsilon to 1e-4 or 1e-6. > > but with predefined epsilon the step in the approx hessian calculation > looks to small: > >>>> t.grad(t.solution)*_epsilon > array([ ?0.00000000e+00, ?-7.71175966e-16, ?-6.94483304e-15]) > > non-convergence was a test failure reported by Alan with scipy 0.7.2 > > I'm not sure about this because I never looked at the optimize code > before, and I only did some quick checking. > > dropping the p in the approx fhess, I get a very fast solution > (full_output) of the test problem in optimize/tests/optimize.py > (array([ ?1.46693016e-07, ?-5.24869440e-01, ? 4.87527692e-01]), 1.55913216727411 > 23, 5, 18, 0, 0) Correction I think we can ignore this, I made some mistakes with my changes (too late at night). The p is necessary to produce correct results, and I cannot reproduce the convergence failure on my computer today. Josef > > Any ideas? > > Josef > From bsouthey at gmail.com Tue Apr 6 09:36:05 2010 From: bsouthey at gmail.com (Bruce Southey) Date: Tue, 06 Apr 2010 08:36:05 -0500 Subject: [SciPy-Dev] request for testing: SciPy 0.7.2 RC1 + NumPy 1.4.1 RC1 In-Reply-To: References: Message-ID: <4BBB38C5.9020206@gmail.com> On 04/05/2010 10:33 PM, Ralf Gommers wrote: > > > On Tue, Apr 6, 2010 at 10:19 AM, Bruce Southey > wrote: > > HI, > Scipy installed okay on Win7 pro 32 bit Python 2.6 but the tests were > interesting. Several times during the scipy.test() windows came and > went. There are also warnings indicating some incompatibility. > > > Windows should not be popping up, unless you're also running doctests > with plot commands. Any idea what they are? If not, can you narrow it > down by running tests for the individual modules? All I did was 'import scipy' and then run 'scipy.test()' so I do did not tell it to run any doctests. > > > Why is the histogram warning here? It does say removal in Numpy 1.4 so > should be gone. Also, shouldn't some of the other stats functions also > be removed? > > > These things should have been removed but weren't in 1.4.0, I just > kept it that way. It can still be removed of course, but maybe this is > better done (or already done) in trunk? David Huard did bring the histogram issue up but apparently it was no addressed: http://mail.scipy.org/pipermail/numpy-discussion/2009-December/047389.html If it is not removed then can you please clarify what 'Numpy 1.4' means? > > While not your fault, we should not have these "FutureWarning" coming > from the tests such as: > Warning (from warnings module): > File "E:\Python26\lib\site-packages\scipy\io\matlab\mio.py", line 165 > oned_as=oned_as) > FutureWarning: Using oned_as default value ('column') This will change > to 'row' in future versions > > > The test output is very chatty. Again, I wanted to keep things the > same as 0.7.1 except for fixing the binary incompatibility issue. For > 0.8 I think all these warnings should be cleaned up, but does it make > sense to do that in this bug fix release? > > The same goes for the build output by the way, long lists of > complaints about tab characters, unused variables, etc. Would be good > to start cleaning that up for 0.8. > > Cheers, > Ralf > I understand this and know that there is a lot for scipy to improve on especially in updating the tests (in my view test should not trigger warnings). You have done a great job in getting a functional release for both numpy and scipy for windows. Do you have the source release for Linux? Bruce -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.gommers at googlemail.com Tue Apr 6 10:13:55 2010 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Tue, 6 Apr 2010 22:13:55 +0800 Subject: [SciPy-Dev] request for testing: SciPy 0.7.2 RC1 + NumPy 1.4.1 RC1 In-Reply-To: <4BBB28FB.4050801@american.edu> References: <4BBAA5C0.1030601@american.edu> <4BBB28FB.4050801@american.edu> Message-ID: On Tue, Apr 6, 2010 at 8:28 PM, Alan G Isaac wrote: > >> Python 2.6.5 (32bit) on Vista (64bit), no gcc. > >> > >> c:\Python26\lib\site-packages\scipy\stats\distributions.py:27: > >> RuntimeWarning: numpy.flatiter size changed, may indicate binary > >> incompatibility > >> import vonmises_cython > > On 4/5/2010 11:38 PM, Ralf Gommers wrote: > > Can you please double check that it's not picking up some left-over from > > 1.4.0 on your system? This really should have been fixed. > > > Did you mena from NumPy, or from SciPy? (The above is the SciPy test.) > I meant the regeneration of the C sources from cython files in scipy. The only reason to do this was to fix the binary incompatibility problem that existed between numpy 1.4.0 and scipy 0.7.x. But probably Josef is right, and the warning is not harmful. I just don't understand why you see it and Bruce and I don't. Maybe someone with a deeper understanding of the issue can weigh in here. > As for NumPy, I do not think that I ever installed 1.4.0 on this machine. > I uninstalled 1.3 usng the Windows uninstall facility > and installed from the superpacks. > > The uninstall completely removes the old directory in site-packages. > I'd need a suggestion for what else to do. > OK, thanks. Nothing else to do for now, unless David or another dev thinks this is a problem. Cheers, Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.kern at gmail.com Tue Apr 6 10:19:23 2010 From: robert.kern at gmail.com (Robert Kern) Date: Tue, 6 Apr 2010 09:19:23 -0500 Subject: [SciPy-Dev] "Automatically adapted for scipy..." In-Reply-To: <4BBAC2E6.6060204@enthought.com> References: <4BBAC2E6.6060204@enthought.com> Message-ID: On Tue, Apr 6, 2010 at 00:13, Warren Weckesser wrote: > At or close to the top of many of the python files in scipy is a comment > that says something like > > ## Automatically adapted for scipy Oct 18, 2005 by > > or > > ## Automatically adapted for scipy Oct 07, 2005 by convertcode.py > > Are these comments still meaningful? ?Is there any harm in removing them? No harm. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco From cournape at gmail.com Tue Apr 6 10:44:34 2010 From: cournape at gmail.com (David Cournapeau) Date: Tue, 6 Apr 2010 23:44:34 +0900 Subject: [SciPy-Dev] request for testing: SciPy 0.7.2 RC1 + NumPy 1.4.1 RC1 In-Reply-To: References: <4BBAA5C0.1030601@american.edu> Message-ID: On Tue, Apr 6, 2010 at 12:38 PM, Ralf Gommers wrote: > > > On Tue, Apr 6, 2010 at 11:08 AM, Alan G Isaac wrote: >> >> Python 2.6.5 (32bit) on Vista (64bit), no gcc. >> Alan Isaac >> >> c:\Python26\lib\site-packages\scipy\spatial\__init__.py:7: RuntimeWarning: >> numpy.dtype size changed, may indicate binary incompatibility >> ? from ckdtree import * >> c:\Python26\lib\site-packages\scipy\spatial\__init__.py:7: RuntimeWarning: >> numpy.flatiter size changed, may indicate binary incompatibility >> ? from ckdtree import * >> c:\Python26\lib\site-packages\scipy\linsolve\__init__.py:4: >> DeprecationWarning: scipy.linsolve has moved to scipy.sparse.linalg.dsolve >> ? warn('scipy.linsolve has moved to scipy.sparse.linalg.dsolve', >> DeprecationWarning) >> c:\Python26\lib\site-packages\scipy\stats\distributions.py:27: >> RuntimeWarning: numpy.dtype size changed, may indicate binary >> incompatibility >> ? import vonmises_cython >> c:\Python26\lib\site-packages\scipy\stats\distributions.py:27: >> RuntimeWarning: numpy.flatiter size changed, may indicate binary >> incompatibility >> ? import vonmises_cython >> >> .................................................................................................................................................................................................................. > > Can you please double check that it's not picking up some left-over from > 1.4.0 on your system? This really should have been fixed. The warnings are harmless, because we made sure the structures were compatible (after the datetime removal in 1.4.x). The flatiter struct was changed to support the neighborhood iterator, and the dtype still has the metadata pointer (which we could remove, but I don't think there is any point). We could remove the warning in the C code as a temporary workaround for 0.7.x, but it would be nice to be able to filter those warnings out, at least programmatically from python (by using a special warning class, for example). cheers, David From josef.pktd at gmail.com Tue Apr 6 10:56:57 2010 From: josef.pktd at gmail.com (josef.pktd at gmail.com) Date: Tue, 6 Apr 2010 10:56:57 -0400 Subject: [SciPy-Dev] optimize ncg approx_fhess_p bug? In-Reply-To: References: Message-ID: On Tue, Apr 6, 2010 at 9:00 AM, wrote: > On Tue, Apr 6, 2010 at 1:15 AM, ? wrote: >> is this a bug? >> >> why is there a ?`*p` in the approx_fhess >> >> def approx_fhess_p(x0,p,fprime,epsilon,*args): >> ? ?f2 = fprime(*((x0+epsilon*p,)+args)) >> ? ?f1 = fprime(*((x0,)+args)) >> ? ?return (f2 - f1)/epsilon >> >> from a quick search this function is only used in fmin_ncg, which has >> convergence problem if epsilon is small. >> convergence to solution looks ok when I set epsilon to 1e-4 or 1e-6. >> >> but with predefined epsilon the step in the approx hessian calculation >> looks to small: >> >>>>> t.grad(t.solution)*_epsilon >> array([ ?0.00000000e+00, ?-7.71175966e-16, ?-6.94483304e-15]) >> >> non-convergence was a test failure reported by Alan with scipy 0.7.2 >> >> I'm not sure about this because I never looked at the optimize code >> before, and I only did some quick checking. >> >> dropping the p in the approx fhess, I get a very fast solution >> (full_output) of the test problem in optimize/tests/optimize.py >> (array([ ?1.46693016e-07, ?-5.24869440e-01, ? 4.87527692e-01]), 1.55913216727411 >> 23, 5, 18, 0, 0) > > Correction > I think we can ignore this, I made some mistakes with my changes (too > late at night). > > The p is necessary to produce correct results, and I cannot reproduce > the convergence failure on my computer ?today. there is still something strange: I get the convergence failure when I use nosetests directly, but not when I run the testfile (which uses nosetests through numpy.testing) >nosetests --version nosetests-script.py version 0.11.1 C:\Josef\eclipsegworkspace\scipy-trunk-new\scipy\optimize\tests>test_optimize.py .......... ---------------------------------------------------------------------- Ran 10 tests in 0.047s OK C:\Josef\eclipsegworkspace\scipy-trunk-new\scipy\optimize\tests>nosetests test_o ptimize.py ......E... ====================================================================== ERROR: line-search Newton conjugate gradient optimization routine ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\Josef\eclipsegworkspace\scipy-trunk-new\scipy\optimize\tests\test_opt imize.py", line 114, in test_ncg retall=False) File "c:\josef\_progs\subversion\scipy-trunk_after\trunk\dist\scipy-0.8.0.dev6 156.win32\programs\python25\lib\site-packages\scipy\optimize\optimize.py", line 1095, in fmin_ncg alphak, fc, gc, old_fval = line_search_BFGS(f,xk,pk,gfk,old_fval) File "c:\josef\_progs\subversion\scipy-trunk_after\trunk\dist\scipy-0.8.0.dev6 156.win32\programs\python25\lib\site-packages\scipy\optimize\optimize.py", line 597, in line_search_BFGS phi_a2 = f(*((xk+alpha2*pk,)+args)) File "c:\josef\_progs\subversion\scipy-trunk_after\trunk\dist\scipy-0.8.0.dev6 156.win32\programs\python25\lib\site-packages\scipy\optimize\optimize.py", line 103, in function_wrapper return function(x, *args) File "C:\Josef\eclipsegworkspace\scipy-trunk-new\scipy\optimize\tests\test_opt imize.py", line 40, in func raise RuntimeError, "too many iterations in optimization routine" RuntimeError: too many iterations in optimization routine ---------------------------------------------------------------------- Ran 10 tests in 0.891s FAILED (errors=1) > > Josef > >> >> Any ideas? >> >> Josef >> > From ralf.gommers at googlemail.com Tue Apr 6 11:11:31 2010 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Tue, 6 Apr 2010 23:11:31 +0800 Subject: [SciPy-Dev] request for testing: SciPy 0.7.2 RC1 + NumPy 1.4.1 RC1 In-Reply-To: <4BBB38C5.9020206@gmail.com> References: <4BBB38C5.9020206@gmail.com> Message-ID: On Tue, Apr 6, 2010 at 9:36 PM, Bruce Southey wrote: > On 04/05/2010 10:33 PM, Ralf Gommers wrote: > > > > On Tue, Apr 6, 2010 at 10:19 AM, Bruce Southey wrote: > >> HI, >> Scipy installed okay on Win7 pro 32 bit Python 2.6 but the tests were >> interesting. Several times during the scipy.test() windows came and >> went. There are also warnings indicating some incompatibility. >> > > Windows should not be popping up, unless you're also running doctests with > plot commands. Any idea what they are? If not, can you narrow it down by > running tests for the individual modules? > > All I did was 'import scipy' and then run 'scipy.test()' so I do did not > tell it to run any doctests. > So can you run the module tests? >>> scipy.integrate.test() >>> scipy.optimize.test() etc. Then maybe you can find out where those windows are coming from. > > > >> Why is the histogram warning here? It does say removal in Numpy 1.4 so >> should be gone. Also, shouldn't some of the other stats functions also >> be removed? >> > > These things should have been removed but weren't in 1.4.0, I just kept it > that way. It can still be removed of course, but maybe this is better done > (or already done) in trunk? > > David Huard did bring the histogram issue up but apparently it was no addressed:http://mail.scipy.org/pipermail/numpy-discussion/2009-December/047389.html > > If it is not removed then can you please clarify what 'Numpy 1.4' means? > > > Well, even though the numpy 1.4.0 binary was removed from sourceforge, I regarded that as 'Numpy 1.4'. So I see 1.4.1 as a bug-fix release for 1.4.0, not the place to remove something. Updating the docstring like David H. suggested makes more sense to me. That said, I don't feel strongly about it either way. > >> While not your fault, we should not have these "FutureWarning" coming >> from the tests such as: >> Warning (from warnings module): >> File "E:\Python26\lib\site-packages\scipy\io\matlab\mio.py", line 165 >> oned_as=oned_as) >> FutureWarning: Using oned_as default value ('column') This will change >> to 'row' in future versions >> > > The test output is very chatty. Again, I wanted to keep things the same as > 0.7.1 except for fixing the binary incompatibility issue. For 0.8 I think > all these warnings should be cleaned up, but does it make sense to do that > in this bug fix release? > > The same goes for the build output by the way, long lists of complaints > about tab characters, unused variables, etc. Would be good to start cleaning > that up for 0.8. > > Cheers, > Ralf > > I understand this and know that there is a lot for scipy to improve on > especially in updating the tests (in my view test should not trigger > warnings). > Agreed, no warnings should be triggered. > > You have done a great job in getting a functional release for both numpy > and scipy for windows. > Thanks. Most of the credit has to go to David though for the good build infrastructure and helping me figure things out! > Do you have the source release for Linux? > > http://www.filefactory.com/file/b0h4fae/n/numpy-1.4.1rc1.tar.gz http://www.filefactory.com/file/b0h4f99/n/numpy-1.4.1rc1.zip http://www.filefactory.com/file/b0h4h16/n/scipy-0.7.2rc1.tar.gz http://www.filefactory.com/file/b0h4g9d/n/scipy-0.7.2rc1.zip The binaries for python 2.5 should still follow by the way. That requires me to duplicate my 2.6 build environment and may take a little bit of time. Cheers, Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From bsouthey at gmail.com Tue Apr 6 14:36:07 2010 From: bsouthey at gmail.com (Bruce Southey) Date: Tue, 06 Apr 2010 13:36:07 -0500 Subject: [SciPy-Dev] request for testing: SciPy 0.7.2 RC1 + NumPy 1.4.1 RC1 In-Reply-To: References: <4BBB38C5.9020206@gmail.com> Message-ID: <4BBB7F17.6060900@gmail.com> On 04/06/2010 10:11 AM, Ralf Gommers wrote: > > > On Tue, Apr 6, 2010 at 9:36 PM, Bruce Southey > wrote: > > On 04/05/2010 10:33 PM, Ralf Gommers wrote: >> >> >> On Tue, Apr 6, 2010 at 10:19 AM, Bruce Southey >> > wrote: >> >> HI, >> Scipy installed okay on Win7 pro 32 bit Python 2.6 but the >> tests were >> interesting. Several times during the scipy.test() windows >> came and >> went. There are also warnings indicating some incompatibility. >> >> >> Windows should not be popping up, unless you're also running >> doctests with plot commands. Any idea what they are? If not, can >> you narrow it down by running tests for the individual modules? > All I did was 'import scipy' and then run 'scipy.test()' so I do > did not tell it to run any doctests. > > > So can you run the module tests? > >>> scipy.integrate.test() > >>> scipy.optimize.test() > etc. Then maybe you can find out where those windows are coming from. > > >> >> >> Why is the histogram warning here? It does say removal in >> Numpy 1.4 so >> should be gone. Also, shouldn't some of the other stats >> functions also >> be removed? >> >> >> These things should have been removed but weren't in 1.4.0, I >> just kept it that way. It can still be removed of course, but >> maybe this is better done (or already done) in trunk? > > David Huard did bring the histogram issue up but apparently it was no addressed: > http://mail.scipy.org/pipermail/numpy-discussion/2009-December/047389.html > > If it is not removed then can you please clarify what 'Numpy 1.4' means? > > > > Well, even though the numpy 1.4.0 binary was removed from sourceforge, > I regarded that as 'Numpy 1.4'. So I see 1.4.1 as a bug-fix release > for 1.4.0, not the place to remove something. Updating the docstring > like David H. suggested makes more sense to me. > > That said, I don't feel strongly about it either way. In regards to scipy, this is the scipy ticket 1120: http://projects.scipy.org/scipy/ticket/1120 I think this ticket can be closed because the offending line has been fixed in the SVN. Bruce -------------- next part -------------- An HTML attachment was scrubbed... URL: From josef.pktd at gmail.com Tue Apr 6 14:43:35 2010 From: josef.pktd at gmail.com (josef.pktd at gmail.com) Date: Tue, 6 Apr 2010 14:43:35 -0400 Subject: [SciPy-Dev] request for testing: SciPy 0.7.2 RC1 + NumPy 1.4.1 RC1 In-Reply-To: <4BBB7F17.6060900@gmail.com> References: <4BBB38C5.9020206@gmail.com> <4BBB7F17.6060900@gmail.com> Message-ID: On Tue, Apr 6, 2010 at 2:36 PM, Bruce Southey wrote: > On 04/06/2010 10:11 AM, Ralf Gommers wrote: > > On Tue, Apr 6, 2010 at 9:36 PM, Bruce Southey wrote: >> >> On 04/05/2010 10:33 PM, Ralf Gommers wrote: >> >> On Tue, Apr 6, 2010 at 10:19 AM, Bruce Southey wrote: >>> >>> HI, >>> Scipy installed okay on Win7 pro 32 bit Python 2.6 but the tests were >>> interesting. ?Several times during the scipy.test() windows came and >>> went. There are also warnings indicating some incompatibility. >> >> Windows should not be popping up, unless you're also running doctests with >> plot commands. Any idea what they are? If not, can you narrow it down by >> running tests for the individual modules? >> >> All I did was 'import scipy' and then run 'scipy.test()' so I do did not >> tell it to run any doctests. > > So can you run the module tests? >>>> scipy.integrate.test() >>>> scipy.optimize.test() > etc. Then maybe you can find out where those windows are coming from. >> >> >>> >>> Why is the histogram warning here? It does say removal in Numpy 1.4 so >>> should be gone. Also, shouldn't some of the other stats functions also >>> be removed? >> >> These things should have been removed but weren't in 1.4.0, I just kept it >> that way. It can still be removed of course, but maybe this is better done >> (or already done) in trunk? >> >> David Huard did bring the histogram issue up but apparently it was no >> addressed: >> http://mail.scipy.org/pipermail/numpy-discussion/2009-December/047389.html >> >> If it is not removed then can you please clarify what 'Numpy 1.4' means? >> >> > > Well, even though the numpy 1.4.0 binary was removed from sourceforge, I > regarded that as 'Numpy 1.4'. So I see 1.4.1 as a bug-fix release for 1.4.0, > not the place to remove something. Updating the docstring like David H. > suggested makes more sense to me. > > That said, I don't feel strongly about it either way. > > In regards to scipy, this is the scipy ticket 1120: > http://projects.scipy.org/scipy/ticket/1120 > > I think this ticket can be closed because the offending line has been fixed > in the SVN. Thanks for pointing it out. I closed the ticket. Josef > > Bruce > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev > > From nmb at wartburg.edu Tue Apr 6 14:52:25 2010 From: nmb at wartburg.edu (Neil Martinsen-Burrell) Date: Tue, 6 Apr 2010 18:52:25 +0000 (UTC) Subject: [SciPy-Dev] request for testing: SciPy 0.7.2 RC1 + NumPy 1.4.1 RC1 References: Message-ID: Numpy works fine on Mac OS X 10.5.8, Python 2.6.5 (python.org): $ python -c "import numpy; numpy.test()" Running unit tests for numpy NumPy version 1.4.1rc1 NumPy is installed in /Library/Frameworks/Python.framework/Versions/2.6/lib/ python2.6/site-packages/numpy Python version 2.6.5 (r265:79359, Mar 24 2010, 01:32:55) [GCC 4.0.1 (Apple Inc. build 5493)] nose version 0.10.4 [...] --------------------------------------------- Ran 2482 tests in 14.702s OK (KNOWNFAIL=3, SKIP=1) Scipy has a couple of test failures: http://pastebin.com/8bZh5TEN -Neil From cgohlke at uci.edu Tue Apr 6 15:02:41 2010 From: cgohlke at uci.edu (Christoph Gohlke) Date: Tue, 06 Apr 2010 12:02:41 -0700 Subject: [SciPy-Dev] repository for NumPy 1.4.1 RC1 Message-ID: <4BBB8551.6020000@uci.edu> Dear numpy developers, is there a public svn/hg/git repository for NumPy 1.4.1 RC1? What is the revision number? is still at version 1.4.0 according to setup.py. Thank you, Christoph From bsouthey at gmail.com Tue Apr 6 15:04:39 2010 From: bsouthey at gmail.com (Bruce Southey) Date: Tue, 06 Apr 2010 14:04:39 -0500 Subject: [SciPy-Dev] How to remove depreciated stats functions? Message-ID: <4BBB85C7.8040900@gmail.com> Hi, Is there a formal policy to fully depreciate the following stats functions? mean median std var samplestd samplevar cov corrcoef stderr Really can we either remove them, say they will be gone in 0.8 or directly equate them to numpy version (ie 'mean=np.mean')? Bruce From josef.pktd at gmail.com Tue Apr 6 15:27:03 2010 From: josef.pktd at gmail.com (josef.pktd at gmail.com) Date: Tue, 6 Apr 2010 15:27:03 -0400 Subject: [SciPy-Dev] How to remove depreciated stats functions? In-Reply-To: <4BBB85C7.8040900@gmail.com> References: <4BBB85C7.8040900@gmail.com> Message-ID: On Tue, Apr 6, 2010 at 3:04 PM, Bruce Southey wrote: > Hi, > Is there a formal policy to fully depreciate the following stats functions? > mean > median > std > var > samplestd > samplevar > cov > corrcoef > stderr > > Really can we either remove them, say they will be gone in 0.8 or > directly equate them to numpy version (ie 'mean=np.mean')? Many of them are already gone and raise an exception (mean, var, std,..) some others are under depreciation warning during 0.8. cycle and I guess will be removed in 0.9 (samplestd, samplevar and I think corrcoef and stderr). I need to check, but I think all of them delegate to the numpy functions, but use the old scipy default options for backwards compatibility during depreciation. We should make sure that all function that we want to get rid of, have a depreciation warning when 0.8 is released so that we can remove them in 0.9 or so Josef > > > Bruce > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev > From bsouthey at gmail.com Tue Apr 6 15:44:58 2010 From: bsouthey at gmail.com (Bruce Southey) Date: Tue, 06 Apr 2010 14:44:58 -0500 Subject: [SciPy-Dev] request for testing: SciPy 0.7.2 RC1 + NumPy 1.4.1 RC1 In-Reply-To: References: <4BBB38C5.9020206@gmail.com> Message-ID: <4BBB8F3A.5010100@gmail.com> On 04/06/2010 10:11 AM, Ralf Gommers wrote: > > > On Tue, Apr 6, 2010 at 9:36 PM, Bruce Southey > wrote: > > On 04/05/2010 10:33 PM, Ralf Gommers wrote: >> >> >> On Tue, Apr 6, 2010 at 10:19 AM, Bruce Southey >> > wrote: >> >> HI, >> Scipy installed okay on Win7 pro 32 bit Python 2.6 but the >> tests were >> interesting. Several times during the scipy.test() windows >> came and >> went. There are also warnings indicating some incompatibility. >> >> >> Windows should not be popping up, unless you're also running >> doctests with plot commands. Any idea what they are? If not, can >> you narrow it down by running tests for the individual modules? > All I did was 'import scipy' and then run 'scipy.test()' so I do > did not tell it to run any doctests. > > > So can you run the module tests? > >>> scipy.integrate.test() > >>> scipy.optimize.test() > etc. Then maybe you can find out where those windows are coming from. > > >> >> >> Why is the histogram warning here? It does say removal in >> Numpy 1.4 so >> should be gone. Also, shouldn't some of the other stats >> functions also >> be removed? >> >> >> These things should have been removed but weren't in 1.4.0, I >> just kept it that way. It can still be removed of course, but >> maybe this is better done (or already done) in trunk? > > David Huard did bring the histogram issue up but apparently it was no addressed: > http://mail.scipy.org/pipermail/numpy-discussion/2009-December/047389.html > > If it is not removed then can you please clarify what 'Numpy 1.4' means? > > > > Well, even though the numpy 1.4.0 binary was removed from sourceforge, > I regarded that as 'Numpy 1.4'. So I see 1.4.1 as a bug-fix release > for 1.4.0, not the place to remove something. Updating the docstring > like David H. suggested makes more sense to me. > > That said, I don't feel strongly about it either way. > >> >> While not your fault, we should not have these >> "FutureWarning" coming >> from the tests such as: >> Warning (from warnings module): >> File "E:\Python26\lib\site-packages\scipy\io\matlab\mio.py", >> line 165 >> oned_as=oned_as) >> FutureWarning: Using oned_as default value ('column') This >> will change >> to 'row' in future versions >> >> >> The test output is very chatty. Again, I wanted to keep things >> the same as 0.7.1 except for fixing the binary incompatibility >> issue. For 0.8 I think all these warnings should be cleaned up, >> but does it make sense to do that in this bug fix release? >> >> The same goes for the build output by the way, long lists of >> complaints about tab characters, unused variables, etc. Would be >> good to start cleaning that up for 0.8. >> >> Cheers, >> Ralf >> > I understand this and know that there is a lot for scipy to > improve on especially in updating the tests (in my view test > should not trigger warnings). > > > Agreed, no warnings should be triggered. > > > You have done a great job in getting a functional release for both > numpy and scipy for windows. > > > Thanks. Most of the credit has to go to David though for the good > build infrastructure and helping me figure things out! > > Do you have the source release for Linux? > > http://www.filefactory.com/file/b0h4fae/n/numpy-1.4.1rc1.tar.gz > http://www.filefactory.com/file/b0h4f99/n/numpy-1.4.1rc1.zip > http://www.filefactory.com/file/b0h4h16/n/scipy-0.7.2rc1.tar.gz > http://www.filefactory.com/file/b0h4g9d/n/scipy-0.7.2rc1.zip > The binaries for python 2.5 should still follow by the way. That > requires me to duplicate my 2.6 build environment and may take a > little bit of time. > > Cheers, > Ralf > > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev > Hi, What scipy svn version was the release candidate obtained? The reason is that I tracked down the warning messages for some of the stats tests that were addressed 15 months ago by changeset 5396 (time stamp of '01/08/09 06:38:03'): http://projects.scipy.org/scipy/changeset/5396 Surely it should be based on a more recent svn version than that. Bruce -------------- next part -------------- An HTML attachment was scrubbed... URL: From josef.pktd at gmail.com Tue Apr 6 16:03:09 2010 From: josef.pktd at gmail.com (josef.pktd at gmail.com) Date: Tue, 6 Apr 2010 16:03:09 -0400 Subject: [SciPy-Dev] request for testing: SciPy 0.7.2 RC1 + NumPy 1.4.1 RC1 In-Reply-To: <4BBB8F3A.5010100@gmail.com> References: <4BBB38C5.9020206@gmail.com> <4BBB8F3A.5010100@gmail.com> Message-ID: On Tue, Apr 6, 2010 at 3:44 PM, Bruce Southey wrote: > On 04/06/2010 10:11 AM, Ralf Gommers wrote: > > On Tue, Apr 6, 2010 at 9:36 PM, Bruce Southey wrote: >> >> On 04/05/2010 10:33 PM, Ralf Gommers wrote: >> >> On Tue, Apr 6, 2010 at 10:19 AM, Bruce Southey wrote: >>> >>> HI, >>> Scipy installed okay on Win7 pro 32 bit Python 2.6 but the tests were >>> interesting. ?Several times during the scipy.test() windows came and >>> went. There are also warnings indicating some incompatibility. >> >> Windows should not be popping up, unless you're also running doctests with >> plot commands. Any idea what they are? If not, can you narrow it down by >> running tests for the individual modules? >> >> All I did was 'import scipy' and then run 'scipy.test()' so I do did not >> tell it to run any doctests. > > So can you run the module tests? >>>> scipy.integrate.test() >>>> scipy.optimize.test() > etc. Then maybe you can find out where those windows are coming from. >> >> >>> >>> Why is the histogram warning here? It does say removal in Numpy 1.4 so >>> should be gone. Also, shouldn't some of the other stats functions also >>> be removed? >> >> These things should have been removed but weren't in 1.4.0, I just kept it >> that way. It can still be removed of course, but maybe this is better done >> (or already done) in trunk? >> >> David Huard did bring the histogram issue up but apparently it was no >> addressed: >> http://mail.scipy.org/pipermail/numpy-discussion/2009-December/047389.html >> >> If it is not removed then can you please clarify what 'Numpy 1.4' means? >> >> > > Well, even though the numpy 1.4.0 binary was removed from sourceforge, I > regarded that as 'Numpy 1.4'. So I see 1.4.1 as a bug-fix release for 1.4.0, > not the place to remove something. Updating the docstring like David H. > suggested makes more sense to me. > > That said, I don't feel strongly about it either way. >>> >>> While not your fault, we should not have these "FutureWarning" coming >>> from the tests such as: >>> Warning (from warnings module): >>> ?File "E:\Python26\lib\site-packages\scipy\io\matlab\mio.py", line 165 >>> ? ?oned_as=oned_as) >>> FutureWarning: Using oned_as default value ('column') This will change >>> to 'row' in future versions >> >> The test output is very chatty. Again, I wanted to keep things the same as >> 0.7.1 except for fixing the binary incompatibility issue. For 0.8 I think >> all these warnings should be cleaned up, but does it make sense to do that >> in this bug fix release? >> >> The same goes for the build output by the way, long lists of complaints >> about tab characters, unused variables, etc. Would be good to start cleaning >> that up for 0.8. >> >> Cheers, >> Ralf >> >> I understand this and know that there is a lot for scipy to improve on >> especially in updating the tests (in my view test should not trigger >> warnings). > > Agreed, no warnings should be triggered. >> >> You have done a great job in getting a functional release for both numpy >> and scipy for windows. > > Thanks. Most of the credit has to go to David though for the good build > infrastructure and helping me figure things out! > >> >> Do you have the source release for Linux? >> > http://www.filefactory.com/file/b0h4fae/n/numpy-1.4.1rc1.tar.gz > http://www.filefactory.com/file/b0h4f99/n/numpy-1.4.1rc1.zip > http://www.filefactory.com/file/b0h4h16/n/scipy-0.7.2rc1.tar.gz > http://www.filefactory.com/file/b0h4g9d/n/scipy-0.7.2rc1.zip > > The binaries for python 2.5 should still follow by the way. That requires me > to duplicate my 2.6 build environment and may take a little bit of time. > > Cheers, > Ralf > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev > > > Hi, > What scipy svn version was the release candidate obtained? > > The reason is that I tracked down the warning messages for some of the stats > tests that were addressed 15 months ago by changeset 5396 (time stamp of > '01/08/09 06:38:03'): > http://projects.scipy.org/scipy/changeset/5396 Original branching of scipy 0.7.x was @5337 http://projects.scipy.org/scipy/log/branches/0.7.x?rev=5525 David started the cleanup in changeset/5396 soon after branching for 0.7 Josef > > Surely it should be based on a more recent svn version than that. > > Bruce > > > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev > > From bsouthey at gmail.com Tue Apr 6 16:10:53 2010 From: bsouthey at gmail.com (Bruce Southey) Date: Tue, 06 Apr 2010 15:10:53 -0500 Subject: [SciPy-Dev] How to remove depreciated stats functions? In-Reply-To: References: <4BBB85C7.8040900@gmail.com> Message-ID: <4BBB954D.7050602@gmail.com> On 04/06/2010 02:27 PM, josef.pktd at gmail.com wrote: > On Tue, Apr 6, 2010 at 3:04 PM, Bruce Southey wrote: > >> Hi, >> Is there a formal policy to fully depreciate the following stats functions? >> mean >> median >> std >> var >> samplestd >> samplevar >> cov >> corrcoef >> stderr >> >> Really can we either remove them, say they will be gone in 0.8 or >> directly equate them to numpy version (ie 'mean=np.mean')? >> > Many of them are already gone and raise an exception (mean, var, std,..) > > some others are under depreciation warning during 0.8. cycle and I > guess will be removed in 0.9 (samplestd, samplevar and I think > corrcoef and stderr). > I need to check, but I think all of them delegate to the numpy > functions, but use the old scipy default options for backwards > compatibility during depreciation. > > We should make sure that all function that we want to get rid of, have > a depreciation warning when 0.8 is released so that we can remove them > in 0.9 or so > > Josef > > Then for those stats functions (like stats.mean, stats.var) that just raise a warning these should state that these will be removed with scipy 0.8? I also think that the others like samplestd should go at the same time especially given the relatively 'slow' release of scipy. Also, there are a number of tests (eg test_std) that should also be removed because these are (or should be) addressed by numpy. Some of the warnings involve uncorrected tests (like test_stderr) that I should have followed up on. However, if these functions are going to get removed soon, it seems better to remove the test than patch it. Bruce From josef.pktd at gmail.com Tue Apr 6 16:31:51 2010 From: josef.pktd at gmail.com (josef.pktd at gmail.com) Date: Tue, 6 Apr 2010 16:31:51 -0400 Subject: [SciPy-Dev] How to remove depreciated stats functions? In-Reply-To: <4BBB954D.7050602@gmail.com> References: <4BBB85C7.8040900@gmail.com> <4BBB954D.7050602@gmail.com> Message-ID: On Tue, Apr 6, 2010 at 4:10 PM, Bruce Southey wrote: > On 04/06/2010 02:27 PM, josef.pktd at gmail.com wrote: >> On Tue, Apr 6, 2010 at 3:04 PM, Bruce Southey ?wrote: >> >>> Hi, >>> Is there a formal policy to fully depreciate the following stats functions? >>> mean >>> median >>> std >>> var >>> samplestd >>> samplevar >>> cov >>> corrcoef >>> stderr >>> >>> Really can we either remove them, say they will be gone in 0.8 or >>> directly equate them to numpy version (ie 'mean=np.mean')? >>> >> Many of them are already gone and raise an exception (mean, var, std,..) >> >> some others are under depreciation warning during 0.8. cycle and I >> guess will be removed in 0.9 (samplestd, samplevar and I think >> corrcoef and stderr). >> I need to check, but I think all of them delegate to the numpy >> functions, but use the old scipy default options for backwards >> compatibility during depreciation. >> >> We should make sure that all function that we want to get rid of, have >> a depreciation warning when 0.8 is released so that we can remove them >> in 0.9 or so >> >> Josef >> >> > Then for those stats functions ?(like stats.mean, stats.var) that just > raise a warning these should state that these will be removed with scipy > 0.8? I don't remember what the depreciation text was in 0.7, but in 0.8 they raise an exception "DeprecationWarning: scipy.stats.std is deprecated; please update your code to use numpy.std." > I also think that the others like samplestd should go at the same > time especially given the relatively 'slow' release of scipy. Not possible because samplestd and similar are only depreciated in svn, not in a release. If scipy follows the numpy policy, then we need a full major cycle of depreciation warning and the earliest release to remove them will be 0.9 > > Also, there are a number of tests (eg test_std) that should also be > removed because these are (or should be) addressed by numpy. Some of the > warnings involve uncorrected tests (like test_stderr) that I should have > followed up on. However, if these functions are going to get removed > soon, it seems better to remove the test than patch it. there is a patch attached to a ticket that will remove obsolete tests. Actually, stderr is depreciated because it is a duplicate of stats.sem. It is more like a t-statistic (standard error of an estimator) not a standard deviation. Josef > > Bruce > > > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev > From aisaac at american.edu Tue Apr 6 18:04:58 2010 From: aisaac at american.edu (Alan G Isaac) Date: Tue, 06 Apr 2010 18:04:58 -0400 Subject: [SciPy-Dev] How to remove depreciated stats functions? In-Reply-To: <4BBB954D.7050602@gmail.com> References: <4BBB85C7.8040900@gmail.com> <4BBB954D.7050602@gmail.com> Message-ID: <4BBBB00A.2060809@american.edu> On 4/6/2010 4:10 PM, Bruce Southey wrote: > Really can we either remove them, say they will be gone in 0.8 or > directly equate them to numpy version (ie 'mean=np.mean')? Was the second option given serious consideration? It seems to provide a large user convenience at low cost. fwiw, Alan Isaac From ralf.gommers at googlemail.com Tue Apr 6 20:27:47 2010 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Wed, 7 Apr 2010 08:27:47 +0800 Subject: [SciPy-Dev] repository for NumPy 1.4.1 RC1 In-Reply-To: <4BBB8551.6020000@uci.edu> References: <4BBB8551.6020000@uci.edu> Message-ID: Hi Christoph, On Wed, Apr 7, 2010 at 3:02 AM, Christoph Gohlke wrote: > Dear numpy developers, > > is there a public svn/hg/git repository for NumPy 1.4.1 RC1? What is the > revision number? > > is still at version > 1.4.0 according to setup.py. > > > I have it on github: http://github.com/rgommers/numpy and http://github.com/rgommers/scipy/tree/release7 Compared to svn there are only changes to pavement.py and setup.py. Cheers, Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From bsouthey at gmail.com Tue Apr 6 22:03:09 2010 From: bsouthey at gmail.com (Bruce Southey) Date: Tue, 6 Apr 2010 21:03:09 -0500 Subject: [SciPy-Dev] request for testing: SciPy 0.7.2 RC1 + NumPy 1.4.1 RC1 In-Reply-To: <4BBAA5C0.1030601@american.edu> References: <4BBAA5C0.1030601@american.edu> Message-ID: On Mon, Apr 5, 2010 at 10:08 PM, Alan G Isaac wrote: > Python 2.6.5 (32bit) on Vista (64bit), no gcc. > Alan Isaac > [snip] > ............................................................................................................................................................................................................................'gcc' is not recognized as an internal or external command, > operable program or batch file. > 'gcc' is not recognized as an internal or external command, > operable program or batch file. > 'gcc' is not recognized as an internal or external command, > operable program or batch file. > 'gcc' is not recognized as an internal or external command, > operable program or batch file. > 'gcc' is not recognized as an internal or external command, > operable program or batch file. > 'gcc' is not recognized as an internal or external command, > operable program or batch file. > 'gcc' is not recognized as an internal or external command, > operable program or batch file. > 'gcc' is not recognized as an internal or external command, > operable program or batch file. > 'gcc' is not recognized as an internal or external command, > operable program or batch file. > 'gcc' is not recognized as an internal or external command, > operable program or batch file. > 'gcc' is not recognized as an internal or external command, > operable program or batch file. These are from the weave tests from running ' scipy.weave.test()' with some of the message coming from the file test_numpy_scalar_spec.py I can reproduce the window on my system by running under IDLE: >>>from scipy.weave.build_tools import msvc_exists, gcc_exists There is no problem with >>> msvc_exists() 0 >>>gcc_exists() False >>> >From the command line it gives: >>>gcc_exists() 'gcc' is not recognized as an internal or external command, operable program or batch file. False Trying the associated code: >>> import subprocess >>> name='gcc' >>> cmd=[str(name), '-v'] >>> cmd ['gcc', '-v'] >>> subprocess.Popen(cmd, True, stdout=subprocess.PIPE, stderr=subprocess.STDOUT) Traceback (most recent call last): File "", line 1, in subprocess.Popen(cmd, True, stdout=subprocess.PIPE, stderr=subprocess.STDOUT) File "E:\Python26\lib\subprocess.py", line 621, in __init__ errread, errwrite) File "E:\Python26\lib\subprocess.py", line 830, in _execute_child startupinfo) WindowsError: [Error 2] The system cannot find the file specified >>> So apparently the exception is not being caught. Bruce From warren.weckesser at enthought.com Wed Apr 7 00:53:33 2010 From: warren.weckesser at enthought.com (Warren Weckesser) Date: Tue, 06 Apr 2010 23:53:33 -0500 Subject: [SciPy-Dev] linalg: cho_solve in basic.py and decomp.py Message-ID: <4BBC0FCD.9070905@enthought.com> I just noticed that the function cho_solve() is implemented in both basic.py and decomp.py in the linalg package. In __init__.py, decomp is imported after basic, so its implementation is used. Both are wrappers of the lapack function potrs, and they do almost exactly the same thing, but the implementation in basic.py handles an additional boolean keyword argument, 'overwrite_b'. Any objections if I merge the two into one implementation in basic.py (where the solvers seem to live), and keep the extra keyword argument? Warren From warren.weckesser at enthought.com Wed Apr 7 01:02:51 2010 From: warren.weckesser at enthought.com (Warren Weckesser) Date: Wed, 07 Apr 2010 00:02:51 -0500 Subject: [SciPy-Dev] linalg: cho_solve in basic.py and decomp.py In-Reply-To: <4BBC0FCD.9070905@enthought.com> References: <4BBC0FCD.9070905@enthought.com> Message-ID: <4BBC11FB.1060908@enthought.com> Warren Weckesser wrote: > I just noticed that the function cho_solve() is implemented in both > basic.py and decomp.py in the linalg package. In __init__.py, decomp is > imported after basic, so its implementation is used. Both are wrappers > of the lapack function potrs, and they do almost exactly the same > thing, but the implementation in basic.py handles an additional boolean > keyword argument, 'overwrite_b'. > > Any objections if I merge the two into one implementation in basic.py > (where the solvers seem to live), and keep the extra keyword argument? > > Minor change to that suggestion--I'd update the version in decomp.py, and remove it from basic.py. Warren From warren.weckesser at enthought.com Wed Apr 7 01:28:40 2010 From: warren.weckesser at enthought.com (Warren Weckesser) Date: Wed, 07 Apr 2010 00:28:40 -0500 Subject: [SciPy-Dev] linalg: cho_solve in basic.py and decomp.py In-Reply-To: <4BBC11FB.1060908@enthought.com> References: <4BBC0FCD.9070905@enthought.com> <4BBC11FB.1060908@enthought.com> Message-ID: <4BBC1808.6060006@enthought.com> Warren Weckesser wrote: > Warren Weckesser wrote: > >> I just noticed that the function cho_solve() is implemented in both >> basic.py and decomp.py in the linalg package. In __init__.py, decomp is >> imported after basic, so its implementation is used. Both are wrappers >> of the lapack function potrs, and they do almost exactly the same >> thing, but the implementation in basic.py handles an additional boolean >> keyword argument, 'overwrite_b'. >> >> Any objections if I merge the two into one implementation in basic.py >> (where the solvers seem to live), and keep the extra keyword argument? >> >> >> > > Minor change to that suggestion--I'd update the version in decomp.py, > and remove it from basic.py. > > Warren > > > lu_solve() is also implemented in both modules, but in this case, decomp.py doesn't include lu_solve in __all__. Go figure. I'll clean up both modules, and, while I'm at it, incorporate the patch that Yaroslav Halchenko recently reminded the list about. Warren From ralf.gommers at googlemail.com Wed Apr 7 10:40:24 2010 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Wed, 7 Apr 2010 22:40:24 +0800 Subject: [SciPy-Dev] request for testing: SciPy 0.7.2 RC1 + NumPy 1.4.1 RC1 In-Reply-To: References: <4BBAA5C0.1030601@american.edu> Message-ID: On Wed, Apr 7, 2010 at 10:03 AM, Bruce Southey wrote: > On Mon, Apr 5, 2010 at 10:08 PM, Alan G Isaac wrote: > > Python 2.6.5 (32bit) on Vista (64bit), no gcc. > > Alan Isaac > > > [snip] > > 'gcc' is not recognized as an internal or external command, > > operable program or batch file. > > These are from the weave tests from running ' scipy.weave.test()' with > some of the message coming from the file > test_numpy_scalar_spec.py > > I can reproduce the window on my system by running under IDLE: > >>>from scipy.weave.build_tools import msvc_exists, gcc_exists > > > There is no problem with > >>> msvc_exists() > 0 > > >>>gcc_exists() > False > >>> > >From the command line it gives: > >>>gcc_exists() > 'gcc' is not recognized as an internal or external command, > operable program or batch file. > False > > > Trying the associated code: > >>> import subprocess > >>> name='gcc' > >>> cmd=[str(name), '-v'] > >>> cmd > ['gcc', '-v'] > >>> subprocess.Popen(cmd, True, stdout=subprocess.PIPE, > stderr=subprocess.STDOUT) > > Traceback (most recent call last): > File "", line 1, in > subprocess.Popen(cmd, True, stdout=subprocess.PIPE, > stderr=subprocess.STDOUT) > File "E:\Python26\lib\subprocess.py", line 621, in __init__ > errread, errwrite) > File "E:\Python26\lib\subprocess.py", line 830, in _execute_child > startupinfo) > WindowsError: [Error 2] The system cannot find the file specified > >>> > > So apparently the exception is not being caught. > > Hmm, that is some ugly code. First of all it doesn't actually work: >>> gcc_exists() 0 >>> p = subprocess.Popen(cmd, True, stdout=subprocess.PIPE, stderr=subprocess.STDOUT) >>> str_result = p.stdout.read() >>> str_result 'Using built-in specs.\nTarget: i686-apple-darwin10\nConfigured with: /var/tmp/gcc/gcc-5646~6/src/configure --disable-checking --enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib --build=i686-apple-darwin10 --with-gxx-include-dir=/include/c++/4.2.1 --program-prefix=i686-apple-darwin10- --host=x86_64-apple-darwin10 --target=i686-apple-darwin10\nThread model: posix\ngcc version 4.2.1 (Apple Inc. build 5646)\n' >>> 'Reading specs' in str_result False Then, I assume the True argument is meant as shell=True, not bufsize=True. Can you specify shell=True and see if that fixes it? If not I think it must be a Python bug, a blanket except statement not catching an exception should be impossible. The quick and dirty way to fix it would be to reuse the os.system call, would fix both the exception and the function itself: def gcc_exists(name = 'gcc'): """ Test to make sure gcc is found.""" result = 0 cmd = [str(name), '-v'] result = not os.system(''.join(cmd)) return result Cheers, Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.gommers at googlemail.com Wed Apr 7 10:52:50 2010 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Wed, 7 Apr 2010 22:52:50 +0800 Subject: [SciPy-Dev] request for testing: SciPy 0.7.2 RC1 + NumPy 1.4.1 RC1 In-Reply-To: References: <4BBB38C5.9020206@gmail.com> <4BBB8F3A.5010100@gmail.com> Message-ID: On Wed, Apr 7, 2010 at 4:03 AM, wrote: > On Tue, Apr 6, 2010 at 3:44 PM, Bruce Southey wrote: > > > > Hi, > > What scipy svn version was the release candidate obtained? > > > > The reason is that I tracked down the warning messages for some of the > stats > > tests that were addressed 15 months ago by changeset 5396 (time stamp of > > '01/08/09 06:38:03'): > > http://projects.scipy.org/scipy/changeset/5396 > Thanks for tracking that down, I'll backport those changes. Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From josef.pktd at gmail.com Wed Apr 7 11:04:18 2010 From: josef.pktd at gmail.com (josef.pktd at gmail.com) Date: Wed, 7 Apr 2010 11:04:18 -0400 Subject: [SciPy-Dev] request for testing: SciPy 0.7.2 RC1 + NumPy 1.4.1 RC1 In-Reply-To: References: <4BBB38C5.9020206@gmail.com> <4BBB8F3A.5010100@gmail.com> Message-ID: On Wed, Apr 7, 2010 at 10:52 AM, Ralf Gommers wrote: > > > On Wed, Apr 7, 2010 at 4:03 AM, wrote: >> >> On Tue, Apr 6, 2010 at 3:44 PM, Bruce Southey wrote: >> > >> > Hi, >> > What scipy svn version was the release candidate obtained? >> > >> > The reason is that I tracked down the warning messages for some of the >> > stats >> > tests that were addressed 15 months ago by changeset 5396 (time stamp of >> > '01/08/09 06:38:03'): >> > http://projects.scipy.org/scipy/changeset/5396 > > > Thanks for tracking that down, I'll backport those changes. don't backport the *raising* of the DepreciationWarning, it's supposed to be a warning and not an exception in 0.7 It hasn't been backported intentionally. according to python help subprocess raises an exception when the command fails, which needs to be caught by the user, i.e. name='gcc2' cmd=[str(name), '-v'] try: ret = subprocess.call(cmd) print ret except OSError: print 'call failed', name Josef > > Ralf > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev > > From ralf.gommers at googlemail.com Wed Apr 7 12:31:05 2010 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Thu, 8 Apr 2010 00:31:05 +0800 Subject: [SciPy-Dev] request for testing: SciPy 0.7.2 RC1 + NumPy 1.4.1 RC1 In-Reply-To: References: <4BBB38C5.9020206@gmail.com> <4BBB8F3A.5010100@gmail.com> Message-ID: On Wed, Apr 7, 2010 at 11:04 PM, wrote: > On Wed, Apr 7, 2010 at 10:52 AM, Ralf Gommers > wrote: > > > > > > On Wed, Apr 7, 2010 at 4:03 AM, wrote: > >> > >> On Tue, Apr 6, 2010 at 3:44 PM, Bruce Southey > wrote: > >> > > >> > Hi, > >> > What scipy svn version was the release candidate obtained? > >> > > >> > The reason is that I tracked down the warning messages for some of the > >> > stats > >> > tests that were addressed 15 months ago by changeset 5396 (time stamp > of > >> > '01/08/09 06:38:03'): > >> > http://projects.scipy.org/scipy/changeset/5396 > > > > > > Thanks for tracking that down, I'll backport those changes. > > don't backport the *raising* of the DepreciationWarning, it's supposed > to be a warning and not an exception in 0.7 It hasn't been > backported intentionally. > OK. Everything else is okay though right? > > > according to python help subprocess raises an exception when the > command fails, which needs to be caught by the user, i.e. > > name='gcc2' > cmd=[str(name), '-v'] > > try: > ret = subprocess.call(cmd) > print ret > except OSError: > print 'call failed', name > > Yes, and the function tries that. I missed the fact that Bruce's example doesn't however. This still leaves the annoying warnings and the broken function itself. I found that specifying shell=True: >>> subprocess.Popen(cmd, shell=True, stdout=subprocess.PIPE, stderr=subprocess.STDOUT) does not raise a WindowsError, so I suspect it will also fix the warnings. This breaks things on OS X however: >>> subprocess.Popen(cmd, shell=True, stdout=subprocess.PIPE, ... stderr=subprocess.STDOUT).stdout.read() 'i686-apple-darwin10-gcc-4.2.1: no input files\n' >>> subprocess.Popen(cmd, shell=False, stdout=subprocess.PIPE, ... stderr=subprocess.STDOUT).stdout.read() 'Using built-in specs.\nTarget: i686-apple-darwin10\nConfigured with: /var/tmp/gcc/gcc-5646~6 So to fix the warnings, we can use shell=True on Windows and shell=False on other platforms. Ugly, I know, but does anyone mind? To fix the function, comparing str_result with 'spec' instead of 'Reading specs' fixes the issue for me and should work on windows as well. Cheers, Ralf Current code: def gcc_exists(name = 'gcc'): """ Test to make sure gcc is found Does this return correct value on win98??? """ result = 0 cmd = [str(name), '-v'] try: p = subprocess.Popen(cmd, True, stdout=subprocess.PIPE, stderr=subprocess.STDOUT) str_result = p.stdout.read() #print str_result if 'Reading specs' in str_result: result = 1 except: # This was needed because the msvc compiler messes with # the path variable. and will occasionlly mess things up # so much that gcc is lost in the path. (Occurs in test # scripts) result = not os.system(" ".join(cmd)) return result Fixed: def gcc_exists(name='gcc'): """ Test to make sure gcc is found.""" result = 0 cmd = [str(name), '-v'] try: if sys.platform == 'win32': p = subprocess.Popen(cmd, shell=True, stdout=subprocess.PIPE, stderr=subprocess.STDOUT) else: p = subprocess.Popen(cmd, stdout=subprocess.PIPE, stderr=subprocess.STDOUT) str_result = p.stdout.read() if 'specs' in str_result: result = 1 except: # This was needed because the msvc compiler messes with # the path variable. and will occasionlly mess things up # so much that gcc is lost in the path. (Occurs in test # scripts) result = not os.system(" ".join(cmd)) return result -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.gommers at googlemail.com Wed Apr 7 12:59:26 2010 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Thu, 8 Apr 2010 00:59:26 +0800 Subject: [SciPy-Dev] request for testing: SciPy 0.7.2 RC1 + NumPy 1.4.1 RC1 In-Reply-To: References: Message-ID: On Wed, Apr 7, 2010 at 2:52 AM, Neil Martinsen-Burrell wrote: > > Scipy has a couple of test failures: http://pastebin.com/8bZh5TEN > Thanks for testing. The failure is real, assert_equal(-0.0, 0.0) is supposed to fail. Now the question is whether the function or the test is wrong. Is cephes.nrdtrisd(0.5,0.5,0.5) supposed to return zero or minus zero? The error is a leftover from another scipy install - realtransforms.py is not present in the 0.7.x branch. Cheers, Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From josef.pktd at gmail.com Wed Apr 7 13:00:57 2010 From: josef.pktd at gmail.com (josef.pktd at gmail.com) Date: Wed, 7 Apr 2010 13:00:57 -0400 Subject: [SciPy-Dev] request for testing: SciPy 0.7.2 RC1 + NumPy 1.4.1 RC1 In-Reply-To: References: <4BBB38C5.9020206@gmail.com> <4BBB8F3A.5010100@gmail.com> Message-ID: On Wed, Apr 7, 2010 at 12:31 PM, Ralf Gommers wrote: > > > On Wed, Apr 7, 2010 at 11:04 PM, wrote: >> >> On Wed, Apr 7, 2010 at 10:52 AM, Ralf Gommers >> wrote: >> > >> > >> > On Wed, Apr 7, 2010 at 4:03 AM, wrote: >> >> >> >> On Tue, Apr 6, 2010 at 3:44 PM, Bruce Southey >> >> wrote: >> >> > >> >> > Hi, >> >> > What scipy svn version was the release candidate obtained? >> >> > >> >> > The reason is that I tracked down the warning messages for some of >> >> > the >> >> > stats >> >> > tests that were addressed 15 months ago by changeset 5396 (time stamp >> >> > of >> >> > '01/08/09 06:38:03'): >> >> > http://projects.scipy.org/scipy/changeset/5396 >> > >> > >> > Thanks for tracking that down, I'll backport those changes. >> >> don't backport the *raising* of the DepreciationWarning, it's supposed >> to be a warning and not an exception in 0.7 ? It hasn't been >> backported intentionally. > > OK. Everything else is okay though right? It looks ok, but I don't think it is a good idea to backport changes that are not really necessary. There is always a small chance that there was a mistake or incompatibility in the changeset that got changed later. I don't think that's the case, but I did several followup removal of calls to the depreciated/removed stats functions. At this stage, I would just release numpy and scipy (if they work) and leave cleaning up noisy output and warnings for the next release. (I don't have python 2.6, so I haven't tested it yet) >> >> >> according to python help subprocess raises an exception when the >> command fails, which needs to be caught by the user, i.e. >> >> name='gcc2' >> cmd=[str(name), '-v'] >> >> try: >> ? ?ret = subprocess.call(cmd) >> ? ?print ret >> except OSError: >> ? ?print 'call failed', name >> > Yes, and the function tries that. I missed the fact that Bruce's example > doesn't however. This still leaves the annoying warnings and the broken > function itself. > > I found that specifying shell=True: >>>> subprocess.Popen(cmd, shell=True, stdout=subprocess.PIPE, >>>> stderr=subprocess.STDOUT) > does not raise a WindowsError, so I suspect it will also fix the warnings. > This breaks things on OS X however: >>>> subprocess.Popen(cmd, shell=True, stdout=subprocess.PIPE, > ...???????? stderr=subprocess.STDOUT).stdout.read() > 'i686-apple-darwin10-gcc-4.2.1: no input files\n' >>>> subprocess.Popen(cmd, shell=False, stdout=subprocess.PIPE, > ...???????? stderr=subprocess.STDOUT).stdout.read() > 'Using built-in specs.\nTarget: i686-apple-darwin10\nConfigured with: > /var/tmp/gcc/gcc-5646~6 > > > So to fix the warnings, we can use shell=True on Windows and shell=False on > other platforms. Ugly, I know, but does anyone mind? > > To fix the function, comparing str_result with 'spec' instead of 'Reading > specs' fixes the issue for me and should work on windows as well. > > Cheers, > Ralf > > > Current code: > > def gcc_exists(name = 'gcc'): > ??? """ Test to make sure gcc is found > > ??????? Does this return correct value on win98??? > ??? """ > ??? result = 0 > ??? cmd = [str(name), '-v'] > ??? try: > ??????? p = subprocess.Popen(cmd, True, stdout=subprocess.PIPE, > ??????????????? stderr=subprocess.STDOUT) > ??????? str_result = p.stdout.read() > ??????? #print str_result > ??????? if 'Reading specs' in str_result: > ??????????? result = 1 > ??? except: > ??????? # This was needed because the msvc compiler messes with > ??????? # the path variable. and will occasionlly mess things up > ??????? # so much that gcc is lost in the path. (Occurs in test > ??????? # scripts) > ??????? result = not os.system(" ".join(cmd)) > ??? return result > > > Fixed: > > def gcc_exists(name='gcc'): > ??? """ Test to make sure gcc is found.""" > ??? result = 0 > ??? cmd = [str(name), '-v'] > ??? try: > ??????? if sys.platform == 'win32': > ??????????? p = subprocess.Popen(cmd, shell=True, stdout=subprocess.PIPE, > ???????????????????????????????? stderr=subprocess.STDOUT) > ??????? else: > ??????????? p = subprocess.Popen(cmd, stdout=subprocess.PIPE, > ???????????????????????????????? stderr=subprocess.STDOUT) > ??????? str_result = p.stdout.read() > ??????? if 'specs' in str_result: > ??????????? result = 1 > ??? except: > ??????? # This was needed because the msvc compiler messes with > ??????? # the path variable. and will occasionlly mess things up > ??????? # so much that gcc is lost in the path. (Occurs in test > ??????? # scripts) > ??????? result = not os.system(" ".join(cmd)) > ??? return result I'm not sure about this. My impression is that the except part result = not os.system(" ".join(cmd)) is doing the printing, not subprocess >>> os.system("gcc2 -v") 'gcc2' is not recognized as an internal or external command, operable program or batch file. 1 Josef > > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev > > From pav+sp at iki.fi Wed Apr 7 13:13:30 2010 From: pav+sp at iki.fi (Pauli Virtanen) Date: Wed, 7 Apr 2010 17:13:30 +0000 (UTC) Subject: [SciPy-Dev] request for testing: SciPy 0.7.2 RC1 + NumPy 1.4.1 RC1 References: Message-ID: Thu, 08 Apr 2010 00:59:26 +0800., Ralf Gommers wrote: > Thanks for testing. The failure is real, assert_equal(-0.0, 0.0) is > supposed to fail. Now the question is whether the function or the test > is wrong. Is cephes.nrdtrisd(0.5,0.5,0.5) supposed to return zero or > minus zero? Should be a positive zero, as the output is a standard deviation. But it's ye olde Fortran code, and I suppose no thought has been paid on this sort of floating point corner cases. Also, the sign of zero probably doesn't even matter except in pathological situations -- so one could just accept the return value as it is and add an abs() to the test. -- Pauli Virtanen From ralf.gommers at googlemail.com Wed Apr 7 13:13:56 2010 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Thu, 8 Apr 2010 01:13:56 +0800 Subject: [SciPy-Dev] request for testing: SciPy 0.7.2 RC1 + NumPy 1.4.1 RC1 In-Reply-To: References: <4BBB38C5.9020206@gmail.com> <4BBB8F3A.5010100@gmail.com> Message-ID: On Thu, Apr 8, 2010 at 1:00 AM, wrote: > On Wed, Apr 7, 2010 at 12:31 PM, Ralf Gommers > >> > >> don't backport the *raising* of the DepreciationWarning, it's supposed > >> to be a warning and not an exception in 0.7 It hasn't been > >> backported intentionally. > > > > OK. Everything else is okay though right? > > It looks ok, but I don't think it is a good idea to backport changes > that are not really necessary. There is always a small chance that > there was a mistake or incompatibility in the changeset that got > changed later. I don't think that's the case, but I did several > followup removal of calls to the depreciated/removed stats functions. > > At this stage, I would just release numpy and scipy (if they work) and > leave cleaning up noisy output and warnings for the next release. (I > don't have python 2.6, so I haven't tested it yet) > > Makes sense. I guess I can't make everyone happy here. > > > Fixed: > > > > def gcc_exists(name='gcc'): > > """ Test to make sure gcc is found.""" > > result = 0 > > cmd = [str(name), '-v'] > > try: > > if sys.platform == 'win32': > > p = subprocess.Popen(cmd, shell=True, stdout=subprocess.PIPE, > > stderr=subprocess.STDOUT) > > else: > > p = subprocess.Popen(cmd, stdout=subprocess.PIPE, > > stderr=subprocess.STDOUT) > > str_result = p.stdout.read() > > if 'specs' in str_result: > > result = 1 > > except: > > # This was needed because the msvc compiler messes with > > # the path variable. and will occasionlly mess things up > > # so much that gcc is lost in the path. (Occurs in test > > # scripts) > > result = not os.system(" ".join(cmd)) > > return result > > I'm not sure about this. My impression is that the except part > result = not os.system(" ".join(cmd)) > > is doing the printing, not subprocess > > >>> os.system("gcc2 -v") > 'gcc2' is not recognized as an internal or external command, > operable program or batch file. > 1 > > That's correct, but the fix in the subprocess call (shell=True) should ensure that no exception is thrown in the parent process: >>> subprocess.Popen('abc', shell=True, stdout=subprocess.PIPE, stderr=subprocess.STDOUT) >>> subprocess.Popen('abc', shell=False, stdout=subprocess.PIPE, stderr=subprocess.STDOUT) ...... OSError: [Errno 2] No such file or directory Cheers, Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From josef.pktd at gmail.com Wed Apr 7 13:29:21 2010 From: josef.pktd at gmail.com (josef.pktd at gmail.com) Date: Wed, 7 Apr 2010 13:29:21 -0400 Subject: [SciPy-Dev] request for testing: SciPy 0.7.2 RC1 + NumPy 1.4.1 RC1 In-Reply-To: References: <4BBB38C5.9020206@gmail.com> <4BBB8F3A.5010100@gmail.com> Message-ID: On Wed, Apr 7, 2010 at 1:13 PM, Ralf Gommers wrote: > > > On Thu, Apr 8, 2010 at 1:00 AM, wrote: >> >> On Wed, Apr 7, 2010 at 12:31 PM, Ralf Gommers >> >> >> >> don't backport the *raising* of the DepreciationWarning, it's supposed >> >> to be a warning and not an exception in 0.7 ? It hasn't been >> >> backported intentionally. >> > >> > OK. Everything else is okay though right? >> >> It looks ok, but I don't think it is a good idea to backport changes >> that are not really necessary. There is always a small chance that >> there was a mistake or incompatibility in the changeset that got >> changed later. I don't think that's the case, but I did several >> followup removal of calls to the depreciated/removed stats functions. >> >> At this stage, I would just release numpy and scipy (if they work) and >> leave cleaning up noisy output and warnings for the next release. (I >> don't have python 2.6, so I haven't tested it yet) >> > Makes sense. I guess I can't make everyone happy here. > >> >> > Fixed: >> > >> > def gcc_exists(name='gcc'): >> > ??? """ Test to make sure gcc is found.""" >> > ??? result = 0 >> > ??? cmd = [str(name), '-v'] >> > ??? try: >> > ??????? if sys.platform == 'win32': >> > ??????????? p = subprocess.Popen(cmd, shell=True, >> > stdout=subprocess.PIPE, >> > ???????????????????????????????? stderr=subprocess.STDOUT) >> > ??????? else: >> > ??????????? p = subprocess.Popen(cmd, stdout=subprocess.PIPE, >> > ???????????????????????????????? stderr=subprocess.STDOUT) >> > ??????? str_result = p.stdout.read() >> > ??????? if 'specs' in str_result: >> > ??????????? result = 1 >> > ??? except: >> > ??????? # This was needed because the msvc compiler messes with >> > ??????? # the path variable. and will occasionlly mess things up >> > ??????? # so much that gcc is lost in the path. (Occurs in test >> > ??????? # scripts) >> > ??????? result = not os.system(" ".join(cmd)) >> > ??? return result >> >> I'm not sure about this. My impression is that the except part >> result = not os.system(" ".join(cmd)) >> >> is doing the printing, not subprocess >> >> >>> os.system("gcc2 -v") >> 'gcc2' is not recognized as an internal or external command, >> operable program or batch file. >> 1 >> > That's correct, but the fix in the subprocess call (shell=True) should > ensure that no exception is thrown in the parent process: > >>>> subprocess.Popen('abc', shell=True, stdout=subprocess.PIPE, >>>> stderr=subprocess.STDOUT) > >>>> subprocess.Popen('abc', shell=False, stdout=subprocess.PIPE, >>>> stderr=subprocess.STDOUT) > ?...... > OSError: [Errno 2] No such file or directory Ok, I didn't see this before gcc_exists() and msvc_exists() differ in shell=True (I had only thought of a discussion on the python mailing list a long time ago, that shell=True is only necessary for builtin shell commands. ) Josef > > > Cheers, > Ralf > > > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev > > From josef.pktd at gmail.com Wed Apr 7 16:17:18 2010 From: josef.pktd at gmail.com (josef.pktd at gmail.com) Date: Wed, 7 Apr 2010 16:17:18 -0400 Subject: [SciPy-Dev] cephes/levnsn.c history ? Message-ID: I was digging in the documentation for special cephes to find a description of nrdtrisd but then I found that the description for /* Levnsn.c */ /* Levinson-Durbin LPC digging in the history, it has been deleted 8 years ago: http://projects.scipy.org/scipy/log/trunk/Lib/special/cephes/levnsn.c?rev=6310&mode=path_history It would have been nice to have this. Are there any reasons for not including it, or is it already ancient history? Josef From andreamilazzo at mancausoft.org Thu Apr 8 04:40:45 2010 From: andreamilazzo at mancausoft.org (Mancausoft) Date: Thu, 8 Apr 2010 10:40:45 +0200 Subject: [SciPy-Dev] info about GSOC on SciPy/Numpy 3k In-Reply-To: <20100408075628.GA5300@homer> References: <20100407211052.GA8234@homer> <20100408075628.GA5300@homer> Message-ID: <20100408084045.GD5300@homer> Hi, I'm interesting an gsoc about Scipy, in particular on Port SciPy to Python 3.0 (or continue finishing up the porting of NumPy). More info on a single task? I can propose this or similar task to gsoc? -- Mancausoft - http://www.mancausoft.org/ GPG key: B53F90F2 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From ralf.gommers at googlemail.com Thu Apr 8 07:17:44 2010 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Thu, 8 Apr 2010 19:17:44 +0800 Subject: [SciPy-Dev] optimize ncg approx_fhess_p bug? In-Reply-To: References: Message-ID: On Tue, Apr 6, 2010 at 10:56 PM, wrote: > On Tue, Apr 6, 2010 at 9:00 AM, wrote: > > there is still something strange: > I get the convergence failure when I use nosetests directly, but not > when I run the testfile (which uses nosetests through numpy.testing) > > I can't reproduce this on either XP or OS X. Alan was on Vista, what are you on? Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.gommers at googlemail.com Thu Apr 8 09:41:54 2010 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Thu, 8 Apr 2010 21:41:54 +0800 Subject: [SciPy-Dev] requesting commit rights In-Reply-To: References: Message-ID: On Sat, Mar 20, 2010 at 10:59 PM, Ralf Gommers wrote: > Hi, > > I would like to get commit rights for both scipy and numpy. The things I > want to work on and think I need them for: > 1. making releases (including related build issues and tests) > 2. docs (merging wiki edits, doc machinery for some scipy modules) > > Hi, I'll repeat my request. Can I get a yes or a no please? And who do I then ping to actually get access? Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From josef.pktd at gmail.com Thu Apr 8 10:12:12 2010 From: josef.pktd at gmail.com (josef.pktd at gmail.com) Date: Thu, 8 Apr 2010 10:12:12 -0400 Subject: [SciPy-Dev] optimize ncg approx_fhess_p bug? In-Reply-To: References: Message-ID: On Thu, Apr 8, 2010 at 7:17 AM, Ralf Gommers wrote: > > > On Tue, Apr 6, 2010 at 10:56 PM, wrote: >> >> On Tue, Apr 6, 2010 at 9:00 AM, ? wrote: > > >> >> there is still something strange: >> I get the convergence failure when I use nosetests directly, but not >> when I run the testfile (which uses nosetests through numpy.testing) >> > I can't reproduce this on either XP or OS X. Alan was on Vista, what are you > on? I'm also on XP. I wouldn't bother about this now if it cannot be consistently reproduced. I put a print statement into the function of the test and sometimes the arguments turn into nans, and in this case the optimization breaks down. I have no idea why this happens sometimes but not always, or why there should be an random element to the result. I think the default epsilon is too small for practical purposes, but that's a different issue, and the test seems to work correctly in general. However, I never get a failure with smaller epsilon. Josef > > Ralf > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev > > From josef.pktd at gmail.com Thu Apr 8 10:16:34 2010 From: josef.pktd at gmail.com (josef.pktd at gmail.com) Date: Thu, 8 Apr 2010 10:16:34 -0400 Subject: [SciPy-Dev] optimize ncg approx_fhess_p bug? In-Reply-To: References: Message-ID: On Thu, Apr 8, 2010 at 10:12 AM, wrote: > On Thu, Apr 8, 2010 at 7:17 AM, Ralf Gommers > wrote: >> >> >> On Tue, Apr 6, 2010 at 10:56 PM, wrote: >>> >>> On Tue, Apr 6, 2010 at 9:00 AM, ? wrote: >> >> >>> >>> there is still something strange: >>> I get the convergence failure when I use nosetests directly, but not >>> when I run the testfile (which uses nosetests through numpy.testing) >>> >> I can't reproduce this on either XP or OS X. Alan was on Vista, what are you >> on? > > I'm also on XP. > I wouldn't bother about this now if it cannot be consistently reproduced. > > I put a print statement into the function of the test and sometimes > the arguments turn into nans, and in this case the optimization breaks > down. I have no idea why this happens sometimes but not always, or why > there should be an random element to the result. > > I think the default epsilon is too small for practical purposes, but > that's a different issue, and the test seems to work correctly in > general. However, I never get a failure with smaller epsilon. with a larger epsilon (not smaller) Josef > > Josef > >> >> Ralf >> >> _______________________________________________ >> SciPy-Dev mailing list >> SciPy-Dev at scipy.org >> http://mail.scipy.org/mailman/listinfo/scipy-dev >> >> > From ralf.gommers at googlemail.com Thu Apr 8 10:57:54 2010 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Thu, 8 Apr 2010 22:57:54 +0800 Subject: [SciPy-Dev] optimize ncg approx_fhess_p bug? In-Reply-To: References: Message-ID: On Thu, Apr 8, 2010 at 10:16 PM, wrote: > On Thu, Apr 8, 2010 at 10:12 AM, wrote: > > On Thu, Apr 8, 2010 at 7:17 AM, Ralf Gommers > > wrote: > >> > >> > >> On Tue, Apr 6, 2010 at 10:56 PM, wrote: > >>> > >>> On Tue, Apr 6, 2010 at 9:00 AM, wrote: > >> > >> > >>> > >>> there is still something strange: > >>> I get the convergence failure when I use nosetests directly, but not > >>> when I run the testfile (which uses nosetests through numpy.testing) > >>> > >> I can't reproduce this on either XP or OS X. Alan was on Vista, what are > you > >> on? > > > > I'm also on XP. > > I wouldn't bother about this now if it cannot be consistently reproduced. > > > > I put a print statement into the function of the test and sometimes > > the arguments turn into nans, and in this case the optimization breaks > > down. I have no idea why this happens sometimes but not always, or why > > there should be an random element to the result. > > > > I think the default epsilon is too small for practical purposes, but > > that's a different issue, and the test seems to work correctly in > > general. However, I never get a failure with smaller epsilon. > > with a larger epsilon (not smaller) > > Okay, I will create a ticket to summarize the issue and leave it for now. Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From cournape at gmail.com Fri Apr 9 06:30:21 2010 From: cournape at gmail.com (David Cournapeau) Date: Fri, 9 Apr 2010 19:30:21 +0900 Subject: [SciPy-Dev] cephes/levnsn.c history ? In-Reply-To: References: Message-ID: On Thu, Apr 8, 2010 at 5:17 AM, wrote: > I was digging in the documentation for special cephes to find a > description of nrdtrisd > > but then I found that the description for > > /* ? ? ? ? ? ? ?Levnsn.c ? ? ? ? ? ? ? ?*/ > /* Levinson-Durbin LPC > > digging in the history, it has been deleted 8 years ago: > http://projects.scipy.org/scipy/log/trunk/Lib/special/cephes/levnsn.c?rev=6310&mode=path_history > > It would have been nice to have this. Yes, Levinson-Durbin and LPC would be nice. I have cython code for this in my talkbox scikits - I meant to update it for complex support now that cython has complex number syntax, maybe this could be included in scipy. cheers, David From josef.pktd at gmail.com Fri Apr 9 09:53:38 2010 From: josef.pktd at gmail.com (josef.pktd at gmail.com) Date: Fri, 9 Apr 2010 09:53:38 -0400 Subject: [SciPy-Dev] cephes/levnsn.c history ? In-Reply-To: References: Message-ID: On Fri, Apr 9, 2010 at 6:30 AM, David Cournapeau wrote: > On Thu, Apr 8, 2010 at 5:17 AM, ? wrote: >> I was digging in the documentation for special cephes to find a >> description of nrdtrisd >> >> but then I found that the description for >> >> /* ? ? ? ? ? ? ?Levnsn.c ? ? ? ? ? ? ? ?*/ >> /* Levinson-Durbin LPC >> >> digging in the history, it has been deleted 8 years ago: >> http://projects.scipy.org/scipy/log/trunk/Lib/special/cephes/levnsn.c?rev=6310&mode=path_history >> >> It would have been nice to have this. > > Yes, Levinson-Durbin and LPC would be nice. I have cython code for > this in my talkbox scikits - I meant to update it for complex support > now that cython has complex number syntax, maybe this could be > included in scipy. I would find it very useful, if it would go for example into scipy.signal. I looked at it in the talkbox but not very carefully, except for running a few examples. One part that I haven't figured out, is whether the reflection coefficients can be recovered as partial autocorrelation. It seems this way from some descriptions, but I didn't work my way through it enough to translate the different terminologies and definitions. Josef > > cheers, > > David > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev > From nwagner at iam.uni-stuttgart.de Fri Apr 9 11:08:54 2010 From: nwagner at iam.uni-stuttgart.de (Nils Wagner) Date: Fri, 09 Apr 2010 17:08:54 +0200 Subject: [SciPy-Dev] New test failures in 0.8.0.dev6317 Message-ID: ====================================================================== ERROR: Failure: SyntaxError (invalid syntax (decomp.py, line 1345)) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/nwagner/local/lib64/python2.6/site-packages/nose-0.11.2.dev-py2.6.egg/nose/loader.py", line 382, in loadTestsFromName addr.filename, addr.module) File "/home/nwagner/local/lib64/python2.6/site-packages/nose-0.11.2.dev-py2.6.egg/nose/importer.py", line 39, in importFromPath return self.importFromDir(dir_path, fqname) File "/home/nwagner/local/lib64/python2.6/site-packages/nose-0.11.2.dev-py2.6.egg/nose/importer.py", line 86, in importFromDir mod = load_module(part_fqname, fh, filename, desc) File "/home/nwagner/local/lib64/python2.6/site-packages/scipy/interpolate/__init__.py", line 13, in from rbf import Rbf File "/home/nwagner/local/lib64/python2.6/site-packages/scipy/interpolate/rbf.py", line 48, in from scipy import linalg File "/home/nwagner/local/lib64/python2.6/site-packages/scipy/linalg/__init__.py", line 8, in from basic import * File "/home/nwagner/local/lib64/python2.6/site-packages/scipy/linalg/basic.py", line 31, in import decomp File "/home/nwagner/local/lib64/python2.6/site-packages/scipy/linalg/decomp.py", line 1345 gemm, = get_blas_funcs(('gemm',),(rq,)) ^ SyntaxError: invalid syntax ====================================================================== ERROR: test_integer (test_array_import.TestReadArray) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/nwagner/local/lib64/python2.6/site-packages/scipy/io/tests/test_array_import.py", line 52, in test_integer from scipy import stats File "/home/nwagner/local/lib64/python2.6/site-packages/scipy/stats/__init__.py", line 7, in from stats import * File "/home/nwagner/local/lib64/python2.6/site-packages/scipy/stats/stats.py", line 203, in import scipy.linalg as linalg File "/home/nwagner/local/lib64/python2.6/site-packages/scipy/linalg/__init__.py", line 8, in from basic import * File "/home/nwagner/local/lib64/python2.6/site-packages/scipy/linalg/basic.py", line 30, in from scipy.linalg import calc_lwork ImportError: cannot import name calc_lwork From warren.weckesser at enthought.com Fri Apr 9 13:58:41 2010 From: warren.weckesser at enthought.com (Warren Weckesser) Date: Fri, 09 Apr 2010 12:58:41 -0500 Subject: [SciPy-Dev] New test failures in 0.8.0.dev6317 In-Reply-To: References: Message-ID: <4BBF6AD1.4090003@enthought.com> The syntax error is fixed in r6318. Warren Nils Wagner wrote: > ====================================================================== > ERROR: Failure: SyntaxError (invalid syntax (decomp.py, > line 1345)) > ---------------------------------------------------------------------- > Traceback (most recent call last): > File > "/home/nwagner/local/lib64/python2.6/site-packages/nose-0.11.2.dev-py2.6.egg/nose/loader.py", > line 382, in loadTestsFromName > addr.filename, addr.module) > File > "/home/nwagner/local/lib64/python2.6/site-packages/nose-0.11.2.dev-py2.6.egg/nose/importer.py", > line 39, in importFromPath > return self.importFromDir(dir_path, fqname) > File > "/home/nwagner/local/lib64/python2.6/site-packages/nose-0.11.2.dev-py2.6.egg/nose/importer.py", > line 86, in importFromDir > mod = load_module(part_fqname, fh, filename, desc) > File > "/home/nwagner/local/lib64/python2.6/site-packages/scipy/interpolate/__init__.py", > line 13, in > from rbf import Rbf > File > "/home/nwagner/local/lib64/python2.6/site-packages/scipy/interpolate/rbf.py", > line 48, in > from scipy import linalg > File > "/home/nwagner/local/lib64/python2.6/site-packages/scipy/linalg/__init__.py", > line 8, in > from basic import * > File > "/home/nwagner/local/lib64/python2.6/site-packages/scipy/linalg/basic.py", > line 31, in > import decomp > File > "/home/nwagner/local/lib64/python2.6/site-packages/scipy/linalg/decomp.py", > line 1345 > gemm, = get_blas_funcs(('gemm',),(rq,)) > ^ > SyntaxError: invalid syntax > > ====================================================================== > ERROR: test_integer (test_array_import.TestReadArray) > ---------------------------------------------------------------------- > Traceback (most recent call last): > File > "/home/nwagner/local/lib64/python2.6/site-packages/scipy/io/tests/test_array_import.py", > line 52, in test_integer > from scipy import stats > File > "/home/nwagner/local/lib64/python2.6/site-packages/scipy/stats/__init__.py", > line 7, in > from stats import * > File > "/home/nwagner/local/lib64/python2.6/site-packages/scipy/stats/stats.py", > line 203, in > import scipy.linalg as linalg > File > "/home/nwagner/local/lib64/python2.6/site-packages/scipy/linalg/__init__.py", > line 8, in > from basic import * > File > "/home/nwagner/local/lib64/python2.6/site-packages/scipy/linalg/basic.py", > line 30, in > from scipy.linalg import calc_lwork > ImportError: cannot import name calc_lwork > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev > From warren.weckesser at enthought.com Sat Apr 10 00:12:46 2010 From: warren.weckesser at enthought.com (Warren Weckesser) Date: Fri, 09 Apr 2010 23:12:46 -0500 Subject: [SciPy-Dev] Lapack alignment test in linalg failing Message-ID: <4BBFFABE.5070904@enthought.com> I am getting a failure of an alignment test in test_decomp.py in the linalg test suite. I just made several changes in linalg, but this failure has been occurring since before those changes. Here is the error message: ====================================================================== ERROR: test_decomp.test_lapack_misaligned(, (array([[ 1.73394741e-255, 8.18880997e-217, 4.02522535e-178, ---------------------------------------------------------------------- Traceback (most recent call last): File "/Library/Frameworks/Python.framework/Versions/6.1/lib/python2.6/site-packages/nose/case.py", line 183, in runTest self.test(*self.arg) File "/Users/warren/scipy_src_cho_solveh_banded/scipy/linalg/tests/test_decomp.py", line 1074, in check_lapack_misaligned func(*a,**kwargs) File "/Users/warren/scipy_src_cho_solveh_banded/build/lib.macosx-10.5-i386-2.6/scipy/linalg/basic.py", line 47, in solve a1, b1 = map(asarray_chkfinite,(a,b)) File "/Library/Frameworks/Python.framework/Versions/6.1/lib/python2.6/site-packages/numpy/lib/function_base.py", line 586, in asarray_chkfinite raise ValueError, "array must not contain infs or NaNs" ValueError: array must not contain infs or NaNs ---------------------------------------------------------------------- The file test_decomp.py in linalg/tests contains the following code: ----- def check_lapack_misaligned(func, args, kwargs): args = list(args) for i in range(len(args)): a = args[:] if isinstance(a[i],np.ndarray): # Try misaligning a[i] aa = np.zeros(a[i].size*a[i].dtype.itemsize+8, dtype=np.uint8) aa = np.frombuffer(aa.data, offset=4, count=a[i].size, dtype=a[i].dtype) aa.shape = a[i].shape aa[...] = a[i] a[i] = aa func(*a,**kwargs) if len(a[i].shape)>1: a[i] = a[i].T func(*a,**kwargs) def test_lapack_misaligned(): M = np.eye(10,dtype=float) R = np.arange(100) R.shape = 10,10 S = np.arange(20000,dtype=np.uint8) S = np.frombuffer(S.data, offset=4, count=100, dtype=np.float) S.shape = 10, 10 b = np.ones(10) v = np.ones(3,dtype=float) LU, piv = lu_factor(S) for (func, args, kwargs) in [ (eig,(S,),dict(overwrite_a=True)), # crash (eigvals,(S,),dict(overwrite_a=True)), # no crash (lu,(S,),dict(overwrite_a=True)), # no crash (lu_factor,(S,),dict(overwrite_a=True)), # no crash (lu_solve,((LU,piv),b),dict(overwrite_b=True)), (solve,(S,b),dict(overwrite_a=True,overwrite_b=True)), (svd,(M,),dict(overwrite_a=True)), # no crash (svd,(R,),dict(overwrite_a=True)), # no crash (svd,(S,),dict(overwrite_a=True)), # crash (svdvals,(S,),dict()), # no crash (svdvals,(S,),dict(overwrite_a=True)), #crash (cholesky,(M,),dict(overwrite_a=True)), # no crash (qr,(S,),dict(overwrite_a=True)), # crash (rq,(S,),dict(overwrite_a=True)), # crash (hessenberg,(S,),dict(overwrite_a=True)), # crash (schur,(S,),dict(overwrite_a=True)), # crash ]: yield check_lapack_misaligned, func, args, kwargs --- The error occurs when `solve` is called from within check_lapack_misaligned. Since `solve` has two array arguments, check_lapack_misaligned will try to call `solve` four times. The problem is that the first call results in NaNs in the arrays, which causes the next call to to `solve` to fail. Apparently the NaNs result from the data in the array being random junk with exponents ranging all over. If I add these lines after setting `S.shape` in test_lapack_misaligned, the error does not occur: S[...] = 0.0 S[range(10),range(10)] = 1.0 In other words, keep S misaligned, but make it the identity matrix. Is that a "saner" test? The error can also be avoided by setting the overwrite arguments to False. However, I don't know if the values of these arguments are an important part of the test. I don't really understand the logic in these two functions. test_lapack_misaligned misaligns `S`, but then check_lapack_misaligned further misaligns its arguments. Why do this twice? Warren From warren.weckesser at enthought.com Sat Apr 10 00:24:02 2010 From: warren.weckesser at enthought.com (Warren Weckesser) Date: Fri, 09 Apr 2010 23:24:02 -0500 Subject: [SciPy-Dev] Tickets to close Message-ID: <4BBFFD62.8040401@enthought.com> I think the following tickets can be closed: http://projects.scipy.org/scipy/ticket/676 http://projects.scipy.org/scipy/ticket/831 http://projects.scipy.org/scipy/ticket/1001 Warren From stefan at sun.ac.za Sat Apr 10 18:00:11 2010 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Sun, 11 Apr 2010 00:00:11 +0200 Subject: [SciPy-Dev] Tickets to close In-Reply-To: <4BBFFD62.8040401@enthought.com> References: <4BBFFD62.8040401@enthought.com> Message-ID: Hey Warren You should now have permission to modify tickets yourself. Regards St?fan On 10 April 2010 06:24, Warren Weckesser wrote: > I think the following tickets can be closed: > > http://projects.scipy.org/scipy/ticket/676 > http://projects.scipy.org/scipy/ticket/831 > http://projects.scipy.org/scipy/ticket/1001 > > > Warren > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev > From warren.weckesser at enthought.com Sat Apr 10 20:13:14 2010 From: warren.weckesser at enthought.com (Warren Weckesser) Date: Sat, 10 Apr 2010 19:13:14 -0500 Subject: [SciPy-Dev] Tickets to close In-Reply-To: References: <4BBFFD62.8040401@enthought.com> Message-ID: <4BC1141A.9070408@enthought.com> St?fan van der Walt wrote: > Hey Warren > > You should now have permission to modify tickets yourself. > > Great, thanks. Warren > Regards > St?fan > > On 10 April 2010 06:24, Warren Weckesser wrote: > >> I think the following tickets can be closed: >> >> http://projects.scipy.org/scipy/ticket/676 >> http://projects.scipy.org/scipy/ticket/831 >> http://projects.scipy.org/scipy/ticket/1001 >> >> >> Warren >> >> _______________________________________________ >> SciPy-Dev mailing list >> SciPy-Dev at scipy.org >> http://mail.scipy.org/mailman/listinfo/scipy-dev >> >> > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev > From ralf.gommers at googlemail.com Sun Apr 11 05:43:36 2010 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Sun, 11 Apr 2010 17:43:36 +0800 Subject: [SciPy-Dev] io -> npyio move: doc wiki update Message-ID: Hi, Here's a reminder that after the rename of numpy.io, the pages and history of all its objects in the doc wiki need to be carried over. Cheers, Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From charlesr.harris at gmail.com Sun Apr 11 11:19:22 2010 From: charlesr.harris at gmail.com (Charles R Harris) Date: Sun, 11 Apr 2010 09:19:22 -0600 Subject: [SciPy-Dev] requesting commit rights In-Reply-To: References: Message-ID: On Thu, Apr 8, 2010 at 7:41 AM, Ralf Gommers wrote: > > > On Sat, Mar 20, 2010 at 10:59 PM, Ralf Gommers < > ralf.gommers at googlemail.com> wrote: > >> Hi, >> >> I would like to get commit rights for both scipy and numpy. The things I >> want to work on and think I need them for: >> 1. making releases (including related build issues and tests) >> 2. docs (merging wiki edits, doc machinery for some scipy modules) >> >> > Hi, I'll repeat my request. Can I get a yes or a no please? And who do I > then ping to actually get access? > > Did you get rights yet? I think Jarrod is still handling this. Chuck -------------- next part -------------- An HTML attachment was scrubbed... URL: From nwagner at iam.uni-stuttgart.de Sun Apr 11 14:13:23 2010 From: nwagner at iam.uni-stuttgart.de (Nils Wagner) Date: Sun, 11 Apr 2010 20:13:23 +0200 Subject: [SciPy-Dev] make html Message-ID: Exception occurred: File "/home/nwagner/local/lib64/python2.6/site-packages/scipy/linalg/basic.py", line 31, in import decomp File "/home/nwagner/local/lib64/python2.6/site-packages/scipy/linalg/decomp.py", line 1345 gemm, = get_blas_funcs(('gemm',),(rq,)) ^ SyntaxError: invalid syntax The full traceback has been saved in /tmp/sphinx-err-OxhDiU.log, if you want to report the issue to the author. Please also report this if it was a user error, so that a better error message can be provided next time. Send reports to sphinx-dev at googlegroups.com. Thanks! make: *** [html] Fehler 1 From warren.weckesser at enthought.com Sun Apr 11 15:11:18 2010 From: warren.weckesser at enthought.com (Warren Weckesser) Date: Sun, 11 Apr 2010 14:11:18 -0500 Subject: [SciPy-Dev] make html In-Reply-To: References: Message-ID: <4BC21ED6.4060703@enthought.com> Nils, The syntax error in linalg/decomp.py was fixed yesterday (r6318). Warren Nils Wagner wrote: > Exception occurred: > File > "/home/nwagner/local/lib64/python2.6/site-packages/scipy/linalg/basic.py", > line 31, in > import decomp > File > "/home/nwagner/local/lib64/python2.6/site-packages/scipy/linalg/decomp.py", > line 1345 > gemm, = get_blas_funcs(('gemm',),(rq,)) > ^ > SyntaxError: invalid syntax > The full traceback has been saved in > /tmp/sphinx-err-OxhDiU.log, if you want to report the > issue to the author. > Please also report this if it was a user error, so that a > better error message can be provided next time. > Send reports to sphinx-dev at googlegroups.com. Thanks! > make: *** [html] Fehler 1 > > > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev > From ralf.gommers at googlemail.com Mon Apr 12 05:34:29 2010 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Mon, 12 Apr 2010 17:34:29 +0800 Subject: [SciPy-Dev] requesting commit rights In-Reply-To: References: Message-ID: On Sun, Apr 11, 2010 at 11:19 PM, Charles R Harris < charlesr.harris at gmail.com> wrote: > > > On Thu, Apr 8, 2010 at 7:41 AM, Ralf Gommers wrote: > >> >> >> On Sat, Mar 20, 2010 at 10:59 PM, Ralf Gommers < >> ralf.gommers at googlemail.com> wrote: >> >>> Hi, >>> >>> I would like to get commit rights for both scipy and numpy. The things I >>> want to work on and think I need them for: >>> 1. making releases (including related build issues and tests) >>> 2. docs (merging wiki edits, doc machinery for some scipy modules) >>> >>> >> Hi, I'll repeat my request. Can I get a yes or a no please? And who do I >> then ping to actually get access? >> >> > Did you get rights yet? I think Jarrod is still handling this. > > Not yet. I heard from Jarrod last month, but not since then. Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From warren.weckesser at enthought.com Mon Apr 12 12:22:08 2010 From: warren.weckesser at enthought.com (Warren Weckesser) Date: Mon, 12 Apr 2010 11:22:08 -0500 Subject: [SciPy-Dev] Lapack alignment test in linalg failing In-Reply-To: <4BBFFABE.5070904@enthought.com> References: <4BBFFABE.5070904@enthought.com> Message-ID: <4BC348B0.6000904@enthought.com> I created a ticket: http://projects.scipy.org/scipy/ticket/1152 If any of the original authors or editors of the code that tests misaligned arrays are still around, some feedback would be appreciated, especially about why the misalignment is being done twice. I'm not sure if that is intentional. Cheers, Warren Warren Weckesser wrote: > I am getting a failure of an alignment test in test_decomp.py in the linalg > test suite. I just made several changes in linalg, but this failure has > been occurring since before those changes. > > Here is the error message: > > ====================================================================== > ERROR: test_decomp.test_lapack_misaligned(, > (array([[ 1.73394741e-255, 8.18880997e-217, 4.02522535e-178, > ---------------------------------------------------------------------- > Traceback (most recent call last): > File > "/Library/Frameworks/Python.framework/Versions/6.1/lib/python2.6/site-packages/nose/case.py", > line 183, in runTest > self.test(*self.arg) > File > "/Users/warren/scipy_src_cho_solveh_banded/scipy/linalg/tests/test_decomp.py", > line 1074, in check_lapack_misaligned > func(*a,**kwargs) > File > "/Users/warren/scipy_src_cho_solveh_banded/build/lib.macosx-10.5-i386-2.6/scipy/linalg/basic.py", > line 47, in solve > a1, b1 = map(asarray_chkfinite,(a,b)) > File > "/Library/Frameworks/Python.framework/Versions/6.1/lib/python2.6/site-packages/numpy/lib/function_base.py", > line 586, in asarray_chkfinite > raise ValueError, "array must not contain infs or NaNs" > ValueError: array must not contain infs or NaNs > > ---------------------------------------------------------------------- > > The file test_decomp.py in linalg/tests contains the following code: > > ----- > def check_lapack_misaligned(func, args, kwargs): > args = list(args) > for i in range(len(args)): > a = args[:] > if isinstance(a[i],np.ndarray): > # Try misaligning a[i] > aa = np.zeros(a[i].size*a[i].dtype.itemsize+8, dtype=np.uint8) > aa = np.frombuffer(aa.data, offset=4, count=a[i].size, > dtype=a[i].dtype) > aa.shape = a[i].shape > aa[...] = a[i] > a[i] = aa > func(*a,**kwargs) > if len(a[i].shape)>1: > a[i] = a[i].T > func(*a,**kwargs) > > > def test_lapack_misaligned(): > M = np.eye(10,dtype=float) > R = np.arange(100) > R.shape = 10,10 > S = np.arange(20000,dtype=np.uint8) > S = np.frombuffer(S.data, offset=4, count=100, dtype=np.float) > S.shape = 10, 10 > b = np.ones(10) > v = np.ones(3,dtype=float) > LU, piv = lu_factor(S) > for (func, args, kwargs) in [ > (eig,(S,),dict(overwrite_a=True)), # crash > (eigvals,(S,),dict(overwrite_a=True)), # no crash > (lu,(S,),dict(overwrite_a=True)), # no crash > (lu_factor,(S,),dict(overwrite_a=True)), # no crash > (lu_solve,((LU,piv),b),dict(overwrite_b=True)), > (solve,(S,b),dict(overwrite_a=True,overwrite_b=True)), > (svd,(M,),dict(overwrite_a=True)), # no crash > (svd,(R,),dict(overwrite_a=True)), # no crash > (svd,(S,),dict(overwrite_a=True)), # crash > (svdvals,(S,),dict()), # no crash > (svdvals,(S,),dict(overwrite_a=True)), #crash > (cholesky,(M,),dict(overwrite_a=True)), # no crash > (qr,(S,),dict(overwrite_a=True)), # crash > (rq,(S,),dict(overwrite_a=True)), # crash > (hessenberg,(S,),dict(overwrite_a=True)), # crash > (schur,(S,),dict(overwrite_a=True)), # crash > ]: > yield check_lapack_misaligned, func, args, kwargs > --- > > The error occurs when `solve` is called from within > check_lapack_misaligned. Since `solve` has two array arguments, > check_lapack_misaligned will try to call `solve` four times. > The problem is that the first call results in NaNs in the arrays, > which causes the next call to to `solve` to fail. Apparently the NaNs > result from the data in the array being random junk with exponents > ranging all over. > > If I add these lines after setting `S.shape` in test_lapack_misaligned, > the error does not occur: > > S[...] = 0.0 > S[range(10),range(10)] = 1.0 > > In other words, keep S misaligned, but make it the identity matrix. > > Is that a "saner" test? > > The error can also be avoided by setting the overwrite arguments > to False. However, I don't know if the values of these arguments > are an important part of the test. > > I don't really understand the logic in these two functions. > test_lapack_misaligned misaligns `S`, but then check_lapack_misaligned > further misaligns its arguments. Why do this twice? > > Warren > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev > From charlesr.harris at gmail.com Mon Apr 12 12:31:00 2010 From: charlesr.harris at gmail.com (Charles R Harris) Date: Mon, 12 Apr 2010 10:31:00 -0600 Subject: [SciPy-Dev] requesting commit rights In-Reply-To: References: Message-ID: On Mon, Apr 12, 2010 at 3:34 AM, Ralf Gommers wrote: > > > On Sun, Apr 11, 2010 at 11:19 PM, Charles R Harris < > charlesr.harris at gmail.com> wrote: > >> >> >> On Thu, Apr 8, 2010 at 7:41 AM, Ralf Gommers > > wrote: >> >>> >>> >>> On Sat, Mar 20, 2010 at 10:59 PM, Ralf Gommers < >>> ralf.gommers at googlemail.com> wrote: >>> >>>> Hi, >>>> >>>> I would like to get commit rights for both scipy and numpy. The things I >>>> want to work on and think I need them for: >>>> 1. making releases (including related build issues and tests) >>>> 2. docs (merging wiki edits, doc machinery for some scipy modules) >>>> >>>> >>> Hi, I'll repeat my request. Can I get a yes or a no please? And who do I >>> then ping to actually get access? >>> >>> >> Did you get rights yet? I think Jarrod is still handling this. >> >> Not yet. I heard from Jarrod last month, but not since then. > > Best ping him then. Chuck -------------- next part -------------- An HTML attachment was scrubbed... URL: From peridot.faceted at gmail.com Mon Apr 12 15:19:56 2010 From: peridot.faceted at gmail.com (Anne Archibald) Date: Mon, 12 Apr 2010 15:19:56 -0400 Subject: [SciPy-Dev] Lapack alignment test in linalg failing In-Reply-To: <4BC348B0.6000904@enthought.com> References: <4BBFFABE.5070904@enthought.com> <4BC348B0.6000904@enthought.com> Message-ID: On 12 April 2010 12:22, Warren Weckesser wrote: > I created a ticket: http://projects.scipy.org/scipy/ticket/1152 > > If any of the original authors or editors of the code that tests > misaligned arrays are still around, some feedback would be appreciated, > especially about why the misalignment is being done twice. I'm not sure > if that is intentional. That code is my fault, and it's a mess. I think the correct way to handle this is to catch the "NaNs/Infs present" exception, or possibly to edit the misaligned arrays to remove any NaNs/Infs. Unfortunately the bug this was attempting to tickle is deep in the bowels of ATLAS, and is very difficult to trigger correctly; in particular, an identity matrix does not trigger the bug. This is the reason S is misaligned twice: it takes that kind of bizarre data to trigger the bug. Since the symptom of the bug is a segfault, raising a "no NaNs" error qualifies as a pass (though I'm a little surprised you got any NaNs - what platform are you using?) Anne > Cheers, > > Warren > > > Warren Weckesser wrote: >> I am getting a failure of an alignment test in test_decomp.py in the linalg >> test suite. I just made several changes in linalg, but this failure has >> been occurring since before those changes. >> >> Here is the error message: >> >> ====================================================================== >> ERROR: test_decomp.test_lapack_misaligned(, >> (array([[ 1.73394741e-255, 8.18880997e-217, 4.02522535e-178, >> ---------------------------------------------------------------------- >> Traceback (most recent call last): >> File >> "/Library/Frameworks/Python.framework/Versions/6.1/lib/python2.6/site-packages/nose/case.py", >> line 183, in runTest >> self.test(*self.arg) >> File >> "/Users/warren/scipy_src_cho_solveh_banded/scipy/linalg/tests/test_decomp.py", >> line 1074, in check_lapack_misaligned >> func(*a,**kwargs) >> File >> "/Users/warren/scipy_src_cho_solveh_banded/build/lib.macosx-10.5-i386-2.6/scipy/linalg/basic.py", >> line 47, in solve >> a1, b1 = map(asarray_chkfinite,(a,b)) >> File >> "/Library/Frameworks/Python.framework/Versions/6.1/lib/python2.6/site-packages/numpy/lib/function_base.py", >> line 586, in asarray_chkfinite >> raise ValueError, "array must not contain infs or NaNs" >> ValueError: array must not contain infs or NaNs >> >> ---------------------------------------------------------------------- >> >> The file test_decomp.py in linalg/tests contains the following code: >> >> ----- >> def check_lapack_misaligned(func, args, kwargs): >> args = list(args) >> for i in range(len(args)): >> a = args[:] >> if isinstance(a[i],np.ndarray): >> # Try misaligning a[i] >> aa = np.zeros(a[i].size*a[i].dtype.itemsize+8, dtype=np.uint8) >> aa = np.frombuffer(aa.data, offset=4, count=a[i].size, >> dtype=a[i].dtype) >> aa.shape = a[i].shape >> aa[...] = a[i] >> a[i] = aa >> func(*a,**kwargs) >> if len(a[i].shape)>1: >> a[i] = a[i].T >> func(*a,**kwargs) >> >> >> def test_lapack_misaligned(): >> M = np.eye(10,dtype=float) >> R = np.arange(100) >> R.shape = 10,10 >> S = np.arange(20000,dtype=np.uint8) >> S = np.frombuffer(S.data, offset=4, count=100, dtype=np.float) >> S.shape = 10, 10 >> b = np.ones(10) >> v = np.ones(3,dtype=float) >> LU, piv = lu_factor(S) >> for (func, args, kwargs) in [ >> (eig,(S,),dict(overwrite_a=True)), # crash >> (eigvals,(S,),dict(overwrite_a=True)), # no crash >> (lu,(S,),dict(overwrite_a=True)), # no crash >> (lu_factor,(S,),dict(overwrite_a=True)), # no crash >> (lu_solve,((LU,piv),b),dict(overwrite_b=True)), >> (solve,(S,b),dict(overwrite_a=True,overwrite_b=True)), >> (svd,(M,),dict(overwrite_a=True)), # no crash >> (svd,(R,),dict(overwrite_a=True)), # no crash >> (svd,(S,),dict(overwrite_a=True)), # crash >> (svdvals,(S,),dict()), # no crash >> (svdvals,(S,),dict(overwrite_a=True)), #crash >> (cholesky,(M,),dict(overwrite_a=True)), # no crash >> (qr,(S,),dict(overwrite_a=True)), # crash >> (rq,(S,),dict(overwrite_a=True)), # crash >> (hessenberg,(S,),dict(overwrite_a=True)), # crash >> (schur,(S,),dict(overwrite_a=True)), # crash >> ]: >> yield check_lapack_misaligned, func, args, kwargs >> --- >> >> The error occurs when `solve` is called from within >> check_lapack_misaligned. Since `solve` has two array arguments, >> check_lapack_misaligned will try to call `solve` four times. >> The problem is that the first call results in NaNs in the arrays, >> which causes the next call to to `solve` to fail. Apparently the NaNs >> result from the data in the array being random junk with exponents >> ranging all over. >> >> If I add these lines after setting `S.shape` in test_lapack_misaligned, >> the error does not occur: >> >> S[...] = 0.0 >> S[range(10),range(10)] = 1.0 >> >> In other words, keep S misaligned, but make it the identity matrix. >> >> Is that a "saner" test? >> >> The error can also be avoided by setting the overwrite arguments >> to False. However, I don't know if the values of these arguments >> are an important part of the test. >> >> I don't really understand the logic in these two functions. >> test_lapack_misaligned misaligns `S`, but then check_lapack_misaligned >> further misaligns its arguments. Why do this twice? >> >> Warren >> >> _______________________________________________ >> SciPy-Dev mailing list >> SciPy-Dev at scipy.org >> http://mail.scipy.org/mailman/listinfo/scipy-dev >> > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev > From warren.weckesser at enthought.com Mon Apr 12 16:34:28 2010 From: warren.weckesser at enthought.com (Warren Weckesser) Date: Mon, 12 Apr 2010 15:34:28 -0500 Subject: [SciPy-Dev] Lapack alignment test in linalg failing In-Reply-To: References: <4BBFFABE.5070904@enthought.com> <4BC348B0.6000904@enthought.com> Message-ID: <4BC383D4.3030201@enthought.com> Anne Archibald wrote: > On 12 April 2010 12:22, Warren Weckesser wrote: > >> I created a ticket: http://projects.scipy.org/scipy/ticket/1152 >> >> If any of the original authors or editors of the code that tests >> misaligned arrays are still around, some feedback would be appreciated, >> especially about why the misalignment is being done twice. I'm not sure >> if that is intentional. >> > > That code is my fault, and it's a mess. I think the correct way to > handle this is to catch the "NaNs/Infs present" exception, or possibly > to edit the misaligned arrays to remove any NaNs/Infs. Unfortunately > the bug this was attempting to tickle is deep in the bowels of ATLAS, > and is very difficult to trigger correctly; in particular, an identity > matrix does not trigger the bug. This is the reason S is misaligned > twice: it takes that kind of bizarre data to trigger the bug. Since > the symptom of the bug is a segfault, raising a "no NaNs" error > qualifies as a pass (though I'm a little surprised you got any NaNs - > what platform are you using?) > > Using scipy 0.8.0 r6120 or later, I get the same error on Mac OSX, Linux (RH 64 bit), and Windows XP. Does the test really need to reuse the output of the first call of solve() as the input to the second call? That is, does it really need overwrite enabled? If so, then catching the exception and calling that a "pass" doesn't seem right, because that prevents the underlying lapack routine from being called the second time. Warren > Anne > > >> Cheers, >> >> Warren >> >> >> Warren Weckesser wrote: >> >>> I am getting a failure of an alignment test in test_decomp.py in the linalg >>> test suite. I just made several changes in linalg, but this failure has >>> been occurring since before those changes. >>> >>> Here is the error message: >>> >>> ====================================================================== >>> ERROR: test_decomp.test_lapack_misaligned(, >>> (array([[ 1.73394741e-255, 8.18880997e-217, 4.02522535e-178, >>> ---------------------------------------------------------------------- >>> Traceback (most recent call last): >>> File >>> "/Library/Frameworks/Python.framework/Versions/6.1/lib/python2.6/site-packages/nose/case.py", >>> line 183, in runTest >>> self.test(*self.arg) >>> File >>> "/Users/warren/scipy_src_cho_solveh_banded/scipy/linalg/tests/test_decomp.py", >>> line 1074, in check_lapack_misaligned >>> func(*a,**kwargs) >>> File >>> "/Users/warren/scipy_src_cho_solveh_banded/build/lib.macosx-10.5-i386-2.6/scipy/linalg/basic.py", >>> line 47, in solve >>> a1, b1 = map(asarray_chkfinite,(a,b)) >>> File >>> "/Library/Frameworks/Python.framework/Versions/6.1/lib/python2.6/site-packages/numpy/lib/function_base.py", >>> line 586, in asarray_chkfinite >>> raise ValueError, "array must not contain infs or NaNs" >>> ValueError: array must not contain infs or NaNs >>> >>> ---------------------------------------------------------------------- >>> >>> The file test_decomp.py in linalg/tests contains the following code: >>> >>> ----- >>> def check_lapack_misaligned(func, args, kwargs): >>> args = list(args) >>> for i in range(len(args)): >>> a = args[:] >>> if isinstance(a[i],np.ndarray): >>> # Try misaligning a[i] >>> aa = np.zeros(a[i].size*a[i].dtype.itemsize+8, dtype=np.uint8) >>> aa = np.frombuffer(aa.data, offset=4, count=a[i].size, >>> dtype=a[i].dtype) >>> aa.shape = a[i].shape >>> aa[...] = a[i] >>> a[i] = aa >>> func(*a,**kwargs) >>> if len(a[i].shape)>1: >>> a[i] = a[i].T >>> func(*a,**kwargs) >>> >>> >>> def test_lapack_misaligned(): >>> M = np.eye(10,dtype=float) >>> R = np.arange(100) >>> R.shape = 10,10 >>> S = np.arange(20000,dtype=np.uint8) >>> S = np.frombuffer(S.data, offset=4, count=100, dtype=np.float) >>> S.shape = 10, 10 >>> b = np.ones(10) >>> v = np.ones(3,dtype=float) >>> LU, piv = lu_factor(S) >>> for (func, args, kwargs) in [ >>> (eig,(S,),dict(overwrite_a=True)), # crash >>> (eigvals,(S,),dict(overwrite_a=True)), # no crash >>> (lu,(S,),dict(overwrite_a=True)), # no crash >>> (lu_factor,(S,),dict(overwrite_a=True)), # no crash >>> (lu_solve,((LU,piv),b),dict(overwrite_b=True)), >>> (solve,(S,b),dict(overwrite_a=True,overwrite_b=True)), >>> (svd,(M,),dict(overwrite_a=True)), # no crash >>> (svd,(R,),dict(overwrite_a=True)), # no crash >>> (svd,(S,),dict(overwrite_a=True)), # crash >>> (svdvals,(S,),dict()), # no crash >>> (svdvals,(S,),dict(overwrite_a=True)), #crash >>> (cholesky,(M,),dict(overwrite_a=True)), # no crash >>> (qr,(S,),dict(overwrite_a=True)), # crash >>> (rq,(S,),dict(overwrite_a=True)), # crash >>> (hessenberg,(S,),dict(overwrite_a=True)), # crash >>> (schur,(S,),dict(overwrite_a=True)), # crash >>> ]: >>> yield check_lapack_misaligned, func, args, kwargs >>> --- >>> >>> The error occurs when `solve` is called from within >>> check_lapack_misaligned. Since `solve` has two array arguments, >>> check_lapack_misaligned will try to call `solve` four times. >>> The problem is that the first call results in NaNs in the arrays, >>> which causes the next call to to `solve` to fail. Apparently the NaNs >>> result from the data in the array being random junk with exponents >>> ranging all over. >>> >>> If I add these lines after setting `S.shape` in test_lapack_misaligned, >>> the error does not occur: >>> >>> S[...] = 0.0 >>> S[range(10),range(10)] = 1.0 >>> >>> In other words, keep S misaligned, but make it the identity matrix. >>> >>> Is that a "saner" test? >>> >>> The error can also be avoided by setting the overwrite arguments >>> to False. However, I don't know if the values of these arguments >>> are an important part of the test. >>> >>> I don't really understand the logic in these two functions. >>> test_lapack_misaligned misaligns `S`, but then check_lapack_misaligned >>> further misaligns its arguments. Why do this twice? >>> >>> Warren >>> >>> _______________________________________________ >>> SciPy-Dev mailing list >>> SciPy-Dev at scipy.org >>> http://mail.scipy.org/mailman/listinfo/scipy-dev >>> >>> >> _______________________________________________ >> SciPy-Dev mailing list >> SciPy-Dev at scipy.org >> http://mail.scipy.org/mailman/listinfo/scipy-dev >> >> > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev > From peridot.faceted at gmail.com Mon Apr 12 16:56:51 2010 From: peridot.faceted at gmail.com (Anne Archibald) Date: Mon, 12 Apr 2010 16:56:51 -0400 Subject: [SciPy-Dev] Lapack alignment test in linalg failing In-Reply-To: <4BC383D4.3030201@enthought.com> References: <4BBFFABE.5070904@enthought.com> <4BC348B0.6000904@enthought.com> <4BC383D4.3030201@enthought.com> Message-ID: On 12 April 2010 16:34, Warren Weckesser wrote: > Anne Archibald wrote: >> On 12 April 2010 12:22, Warren Weckesser wrote: >> >>> I created a ticket: http://projects.scipy.org/scipy/ticket/1152 >>> >>> If any of the original authors or editors of the code that tests >>> misaligned arrays are still around, some feedback would be appreciated, >>> especially about why the misalignment is being done twice. I'm not sure >>> if that is intentional. >>> >> >> That code is my fault, and it's a mess. I think the correct way to >> handle this is to catch the "NaNs/Infs present" exception, or possibly >> to edit the misaligned arrays to remove any NaNs/Infs. Unfortunately >> the bug this was attempting to tickle is deep in the bowels of ATLAS, >> and is very difficult to trigger correctly; in particular, an identity >> matrix does not trigger the bug. This is the reason S is misaligned >> twice: it takes that kind of bizarre data to trigger the bug. Since >> the symptom of the bug is a segfault, raising a "no NaNs" error >> qualifies as a pass (though I'm a little surprised you got any NaNs - >> what platform are you using?) >> >> > > Using scipy 0.8.0 r6120 or later, I get the same error on Mac OSX, Linux > (RH 64 bit), and Windows XP. That is disturbing. I'll try to take a look at this version when I get home and see if I trigger the bug. > Does the test really need to reuse the output of the first call of > solve() as the input to the second call? That is, does it really need > overwrite enabled? If so, then catching the exception and calling that > a "pass" doesn't seem right, because that prevents the underlying lapack > routine from being called the second time. The bug is only triggered when overwrite is enabled, but the code does not actually reuse any argument arrays. I should at least rearrange the code so that the different offsets are different tests (so that all get run even if one fails), but I had in mind catching the exception on one call of the LAPACK function but then passing on to the others. Anne > Warren > > >> Anne >> >> >>> Cheers, >>> >>> Warren >>> >>> >>> Warren Weckesser wrote: >>> >>>> I am getting a failure of an alignment test in test_decomp.py in the linalg >>>> test suite. I just made several changes in linalg, but this failure has >>>> been occurring since before those changes. >>>> >>>> Here is the error message: >>>> >>>> ====================================================================== >>>> ERROR: test_decomp.test_lapack_misaligned(, >>>> (array([[ 1.73394741e-255, 8.18880997e-217, 4.02522535e-178, >>>> ---------------------------------------------------------------------- >>>> Traceback (most recent call last): >>>> File >>>> "/Library/Frameworks/Python.framework/Versions/6.1/lib/python2.6/site-packages/nose/case.py", >>>> line 183, in runTest >>>> self.test(*self.arg) >>>> File >>>> "/Users/warren/scipy_src_cho_solveh_banded/scipy/linalg/tests/test_decomp.py", >>>> line 1074, in check_lapack_misaligned >>>> func(*a,**kwargs) >>>> File >>>> "/Users/warren/scipy_src_cho_solveh_banded/build/lib.macosx-10.5-i386-2.6/scipy/linalg/basic.py", >>>> line 47, in solve >>>> a1, b1 = map(asarray_chkfinite,(a,b)) >>>> File >>>> "/Library/Frameworks/Python.framework/Versions/6.1/lib/python2.6/site-packages/numpy/lib/function_base.py", >>>> line 586, in asarray_chkfinite >>>> raise ValueError, "array must not contain infs or NaNs" >>>> ValueError: array must not contain infs or NaNs >>>> >>>> ---------------------------------------------------------------------- >>>> >>>> The file test_decomp.py in linalg/tests contains the following code: >>>> >>>> ----- >>>> def check_lapack_misaligned(func, args, kwargs): >>>> args = list(args) >>>> for i in range(len(args)): >>>> a = args[:] >>>> if isinstance(a[i],np.ndarray): >>>> # Try misaligning a[i] >>>> aa = np.zeros(a[i].size*a[i].dtype.itemsize+8, dtype=np.uint8) >>>> aa = np.frombuffer(aa.data, offset=4, count=a[i].size, >>>> dtype=a[i].dtype) >>>> aa.shape = a[i].shape >>>> aa[...] = a[i] >>>> a[i] = aa >>>> func(*a,**kwargs) >>>> if len(a[i].shape)>1: >>>> a[i] = a[i].T >>>> func(*a,**kwargs) >>>> >>>> >>>> def test_lapack_misaligned(): >>>> M = np.eye(10,dtype=float) >>>> R = np.arange(100) >>>> R.shape = 10,10 >>>> S = np.arange(20000,dtype=np.uint8) >>>> S = np.frombuffer(S.data, offset=4, count=100, dtype=np.float) >>>> S.shape = 10, 10 >>>> b = np.ones(10) >>>> v = np.ones(3,dtype=float) >>>> LU, piv = lu_factor(S) >>>> for (func, args, kwargs) in [ >>>> (eig,(S,),dict(overwrite_a=True)), # crash >>>> (eigvals,(S,),dict(overwrite_a=True)), # no crash >>>> (lu,(S,),dict(overwrite_a=True)), # no crash >>>> (lu_factor,(S,),dict(overwrite_a=True)), # no crash >>>> (lu_solve,((LU,piv),b),dict(overwrite_b=True)), >>>> (solve,(S,b),dict(overwrite_a=True,overwrite_b=True)), >>>> (svd,(M,),dict(overwrite_a=True)), # no crash >>>> (svd,(R,),dict(overwrite_a=True)), # no crash >>>> (svd,(S,),dict(overwrite_a=True)), # crash >>>> (svdvals,(S,),dict()), # no crash >>>> (svdvals,(S,),dict(overwrite_a=True)), #crash >>>> (cholesky,(M,),dict(overwrite_a=True)), # no crash >>>> (qr,(S,),dict(overwrite_a=True)), # crash >>>> (rq,(S,),dict(overwrite_a=True)), # crash >>>> (hessenberg,(S,),dict(overwrite_a=True)), # crash >>>> (schur,(S,),dict(overwrite_a=True)), # crash >>>> ]: >>>> yield check_lapack_misaligned, func, args, kwargs >>>> --- >>>> >>>> The error occurs when `solve` is called from within >>>> check_lapack_misaligned. Since `solve` has two array arguments, >>>> check_lapack_misaligned will try to call `solve` four times. >>>> The problem is that the first call results in NaNs in the arrays, >>>> which causes the next call to to `solve` to fail. Apparently the NaNs >>>> result from the data in the array being random junk with exponents >>>> ranging all over. >>>> >>>> If I add these lines after setting `S.shape` in test_lapack_misaligned, >>>> the error does not occur: >>>> >>>> S[...] = 0.0 >>>> S[range(10),range(10)] = 1.0 >>>> >>>> In other words, keep S misaligned, but make it the identity matrix. >>>> >>>> Is that a "saner" test? >>>> >>>> The error can also be avoided by setting the overwrite arguments >>>> to False. However, I don't know if the values of these arguments >>>> are an important part of the test. >>>> >>>> I don't really understand the logic in these two functions. >>>> test_lapack_misaligned misaligns `S`, but then check_lapack_misaligned >>>> further misaligns its arguments. Why do this twice? >>>> >>>> Warren >>>> >>>> _______________________________________________ >>>> SciPy-Dev mailing list >>>> SciPy-Dev at scipy.org >>>> http://mail.scipy.org/mailman/listinfo/scipy-dev >>>> >>>> >>> _______________________________________________ >>> SciPy-Dev mailing list >>> SciPy-Dev at scipy.org >>> http://mail.scipy.org/mailman/listinfo/scipy-dev >>> >>> >> _______________________________________________ >> SciPy-Dev mailing list >> SciPy-Dev at scipy.org >> http://mail.scipy.org/mailman/listinfo/scipy-dev >> > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev > From warren.weckesser at enthought.com Mon Apr 12 18:12:03 2010 From: warren.weckesser at enthought.com (Warren Weckesser) Date: Mon, 12 Apr 2010 17:12:03 -0500 Subject: [SciPy-Dev] Lapack alignment test in linalg failing In-Reply-To: References: <4BBFFABE.5070904@enthought.com> <4BC348B0.6000904@enthought.com> <4BC383D4.3030201@enthought.com> Message-ID: <4BC39AB3.40001@enthought.com> Anne Archibald wrote: > On 12 April 2010 16:34, Warren Weckesser wrote: > >> Anne Archibald wrote: >> >>> On 12 April 2010 12:22, Warren Weckesser wrote: >>> >>> >>>> I created a ticket: http://projects.scipy.org/scipy/ticket/1152 >>>> >>>> If any of the original authors or editors of the code that tests >>>> misaligned arrays are still around, some feedback would be appreciated, >>>> especially about why the misalignment is being done twice. I'm not sure >>>> if that is intentional. >>>> >>>> >>> That code is my fault, and it's a mess. I think the correct way to >>> handle this is to catch the "NaNs/Infs present" exception, or possibly >>> to edit the misaligned arrays to remove any NaNs/Infs. Unfortunately >>> the bug this was attempting to tickle is deep in the bowels of ATLAS, >>> and is very difficult to trigger correctly; in particular, an identity >>> matrix does not trigger the bug. This is the reason S is misaligned >>> twice: it takes that kind of bizarre data to trigger the bug. Since >>> the symptom of the bug is a segfault, raising a "no NaNs" error >>> qualifies as a pass (though I'm a little surprised you got any NaNs - >>> what platform are you using?) >>> >>> >>> >> Using scipy 0.8.0 r6120 or later, I get the same error on Mac OSX, Linux >> (RH 64 bit), and Windows XP. >> > > That is disturbing. I'll try to take a look at this version when I get > home and see if I trigger the bug. > > >> Does the test really need to reuse the output of the first call of >> solve() as the input to the second call? That is, does it really need >> overwrite enabled? If so, then catching the exception and calling that >> a "pass" doesn't seem right, because that prevents the underlying lapack >> routine from being called the second time. >> > > The bug is only triggered when overwrite is enabled, but the code does > not actually reuse any argument arrays. The arrays are reused in check_lapack_misaligned(); this is what is causing the error. When func=solve, args=(S,b) and kwargs={overwrite_a:True, overwrite_b:True}, and when i=0, 'solve' is called once on line 1071 (referring to rev 6321), and again on line 1074. In the second call, a[i] is a transposed view of the same data as the previous call, and b is the same array. The error occurs when the first call results in NaNs in the arrays. Warren > I should at least rearrange > the code so that the different offsets are different tests (so that > all get run even if one fails), but I had in mind catching the > exception on one call of the LAPACK function but then passing on to > the others. > > Anne > > >> Warren >> >> >> >>> Anne >>> >>> >>> >>>> Cheers, >>>> >>>> Warren >>>> >>>> >>>> Warren Weckesser wrote: >>>> >>>> >>>>> I am getting a failure of an alignment test in test_decomp.py in the linalg >>>>> test suite. I just made several changes in linalg, but this failure has >>>>> been occurring since before those changes. >>>>> >>>>> Here is the error message: >>>>> >>>>> ====================================================================== >>>>> ERROR: test_decomp.test_lapack_misaligned(, >>>>> (array([[ 1.73394741e-255, 8.18880997e-217, 4.02522535e-178, >>>>> ---------------------------------------------------------------------- >>>>> Traceback (most recent call last): >>>>> File >>>>> "/Library/Frameworks/Python.framework/Versions/6.1/lib/python2.6/site-packages/nose/case.py", >>>>> line 183, in runTest >>>>> self.test(*self.arg) >>>>> File >>>>> "/Users/warren/scipy_src_cho_solveh_banded/scipy/linalg/tests/test_decomp.py", >>>>> line 1074, in check_lapack_misaligned >>>>> func(*a,**kwargs) >>>>> File >>>>> "/Users/warren/scipy_src_cho_solveh_banded/build/lib.macosx-10.5-i386-2.6/scipy/linalg/basic.py", >>>>> line 47, in solve >>>>> a1, b1 = map(asarray_chkfinite,(a,b)) >>>>> File >>>>> "/Library/Frameworks/Python.framework/Versions/6.1/lib/python2.6/site-packages/numpy/lib/function_base.py", >>>>> line 586, in asarray_chkfinite >>>>> raise ValueError, "array must not contain infs or NaNs" >>>>> ValueError: array must not contain infs or NaNs >>>>> >>>>> ---------------------------------------------------------------------- >>>>> >>>>> The file test_decomp.py in linalg/tests contains the following code: >>>>> >>>>> ----- >>>>> def check_lapack_misaligned(func, args, kwargs): >>>>> args = list(args) >>>>> for i in range(len(args)): >>>>> a = args[:] >>>>> if isinstance(a[i],np.ndarray): >>>>> # Try misaligning a[i] >>>>> aa = np.zeros(a[i].size*a[i].dtype.itemsize+8, dtype=np.uint8) >>>>> aa = np.frombuffer(aa.data, offset=4, count=a[i].size, >>>>> dtype=a[i].dtype) >>>>> aa.shape = a[i].shape >>>>> aa[...] = a[i] >>>>> a[i] = aa >>>>> func(*a,**kwargs) >>>>> if len(a[i].shape)>1: >>>>> a[i] = a[i].T >>>>> func(*a,**kwargs) >>>>> >>>>> >>>>> def test_lapack_misaligned(): >>>>> M = np.eye(10,dtype=float) >>>>> R = np.arange(100) >>>>> R.shape = 10,10 >>>>> S = np.arange(20000,dtype=np.uint8) >>>>> S = np.frombuffer(S.data, offset=4, count=100, dtype=np.float) >>>>> S.shape = 10, 10 >>>>> b = np.ones(10) >>>>> v = np.ones(3,dtype=float) >>>>> LU, piv = lu_factor(S) >>>>> for (func, args, kwargs) in [ >>>>> (eig,(S,),dict(overwrite_a=True)), # crash >>>>> (eigvals,(S,),dict(overwrite_a=True)), # no crash >>>>> (lu,(S,),dict(overwrite_a=True)), # no crash >>>>> (lu_factor,(S,),dict(overwrite_a=True)), # no crash >>>>> (lu_solve,((LU,piv),b),dict(overwrite_b=True)), >>>>> (solve,(S,b),dict(overwrite_a=True,overwrite_b=True)), >>>>> (svd,(M,),dict(overwrite_a=True)), # no crash >>>>> (svd,(R,),dict(overwrite_a=True)), # no crash >>>>> (svd,(S,),dict(overwrite_a=True)), # crash >>>>> (svdvals,(S,),dict()), # no crash >>>>> (svdvals,(S,),dict(overwrite_a=True)), #crash >>>>> (cholesky,(M,),dict(overwrite_a=True)), # no crash >>>>> (qr,(S,),dict(overwrite_a=True)), # crash >>>>> (rq,(S,),dict(overwrite_a=True)), # crash >>>>> (hessenberg,(S,),dict(overwrite_a=True)), # crash >>>>> (schur,(S,),dict(overwrite_a=True)), # crash >>>>> ]: >>>>> yield check_lapack_misaligned, func, args, kwargs >>>>> --- >>>>> >>>>> The error occurs when `solve` is called from within >>>>> check_lapack_misaligned. Since `solve` has two array arguments, >>>>> check_lapack_misaligned will try to call `solve` four times. >>>>> The problem is that the first call results in NaNs in the arrays, >>>>> which causes the next call to to `solve` to fail. Apparently the NaNs >>>>> result from the data in the array being random junk with exponents >>>>> ranging all over. >>>>> >>>>> If I add these lines after setting `S.shape` in test_lapack_misaligned, >>>>> the error does not occur: >>>>> >>>>> S[...] = 0.0 >>>>> S[range(10),range(10)] = 1.0 >>>>> >>>>> In other words, keep S misaligned, but make it the identity matrix. >>>>> >>>>> Is that a "saner" test? >>>>> >>>>> The error can also be avoided by setting the overwrite arguments >>>>> to False. However, I don't know if the values of these arguments >>>>> are an important part of the test. >>>>> >>>>> I don't really understand the logic in these two functions. >>>>> test_lapack_misaligned misaligns `S`, but then check_lapack_misaligned >>>>> further misaligns its arguments. Why do this twice? >>>>> >>>>> Warren >>>>> >>>>> _______________________________________________ >>>>> SciPy-Dev mailing list >>>>> SciPy-Dev at scipy.org >>>>> http://mail.scipy.org/mailman/listinfo/scipy-dev >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> SciPy-Dev mailing list >>>> SciPy-Dev at scipy.org >>>> http://mail.scipy.org/mailman/listinfo/scipy-dev >>>> >>>> >>>> >>> _______________________________________________ >>> SciPy-Dev mailing list >>> SciPy-Dev at scipy.org >>> http://mail.scipy.org/mailman/listinfo/scipy-dev >>> >>> >> _______________________________________________ >> SciPy-Dev mailing list >> SciPy-Dev at scipy.org >> http://mail.scipy.org/mailman/listinfo/scipy-dev >> >> > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev > From d.l.goldsmith at gmail.com Mon Apr 12 22:15:50 2010 From: d.l.goldsmith at gmail.com (David Goldsmith) Date: Mon, 12 Apr 2010 19:15:50 -0700 Subject: [SciPy-Dev] pydocweb exposes data attributes Message-ID: E.g., http://docs.scipy.org/numpy/docs/ lists polynomial.chebyshev.Chebyshev.domain even though domain is a data attribute. "Bug" or "feature" (of pydocweb)? DG -- Mathematician: noun, someone who disavows certainty when their uncertainty set is non-empty, even if that set has measure zero. -------------- next part -------------- An HTML attachment was scrubbed... URL: From charlesr.harris at gmail.com Mon Apr 12 23:40:26 2010 From: charlesr.harris at gmail.com (Charles R Harris) Date: Mon, 12 Apr 2010 21:40:26 -0600 Subject: [SciPy-Dev] pydocweb exposes data attributes In-Reply-To: References: Message-ID: On Mon, Apr 12, 2010 at 8:15 PM, David Goldsmith wrote: > E.g., http://docs.scipy.org/numpy/docs/ lists > polynomial.chebyshev.Chebyshev.domain even though domain is a data > attribute. "Bug" or "feature" (of pydocweb)? > > In the chebyshev case I left domain as a public attribute in case someone wanted to play dangerous games. Are private attributes also exposed? Chuck -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.gommers at googlemail.com Tue Apr 13 00:05:16 2010 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Tue, 13 Apr 2010 12:05:16 +0800 Subject: [SciPy-Dev] pydocweb exposes data attributes In-Reply-To: References: Message-ID: On Tue, Apr 13, 2010 at 11:40 AM, Charles R Harris < charlesr.harris at gmail.com> wrote: > > > On Mon, Apr 12, 2010 at 8:15 PM, David Goldsmith wrote: > >> E.g., http://docs.scipy.org/numpy/docs/ lists >> polynomial.chebyshev.Chebyshev.domain even though domain is a data >> attribute. "Bug" or "feature" (of pydocweb)? >> >> > feature > In the chebyshev case I left domain as a public attribute in case someone > wanted to play dangerous games. Are private attributes also exposed? > > no Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From cournape at gmail.com Tue Apr 13 08:45:48 2010 From: cournape at gmail.com (David Cournapeau) Date: Tue, 13 Apr 2010 21:45:48 +0900 Subject: [SciPy-Dev] [ANN] toydist version 0.0.2 Message-ID: Hi, I am glad to announce the first release of toydist, the 0.0.2 release: http://github.com/cournape/toydist/downloads Toydist is a pythonic, no-nonsense packaging solution for python softwares. The main highlights of this first public release are: * Package description grammar formalized through PLY, the python Lex-yacc package (included in toydist for the time being) * Toymaker, the command line interface to toydist, can install itself Although still very much in infancy, I have succesfully used the conversion procedure on sphinx, jinja and a few python-only Enthought packages. How to help ? ------------- Toydist is experimental, and should not be used for anything production-worthy at this point. There are two main reasons why I have released such a preliminary version: * To get suggestions/comments on the current file format. I believe the current syntax strikes a good balance for human readers/writers, but it cannot be parsed with just regular expressions, which means syntax highlithing may be difficult (the difficulty is to be able to parse arbitary rest for some metadata). The easiest way to get a feeling of the format is to convert your favorite python package, assuming it is simple enough. * The API for package description is still regularly changed, and the command-line interface has no sane API yet, but I certainly welcome suggestions from people interested in writing debian or other builders. I have started documenting toydist, an up-to-date version can be found on http://cournape.github.com/toydist. Example of simple commands may be found in toydist/commands (sdist and install are particularly simple). The focus for 0.0.3 is hook support - the goal is to have an API robust enough so that future toydist code will be based on hooks, as well a basic support for waf or scons-based C builds. cheers, David From d.l.goldsmith at gmail.com Tue Apr 13 12:28:31 2010 From: d.l.goldsmith at gmail.com (David Goldsmith) Date: Tue, 13 Apr 2010 09:28:31 -0700 Subject: [SciPy-Dev] pydocweb exposes data attributes In-Reply-To: References: Message-ID: On Mon, Apr 12, 2010 at 9:05 PM, Ralf Gommers wrote: > > On Tue, Apr 13, 2010 at 11:40 AM, Charles R Harris < > charlesr.harris at gmail.com> wrote: > >> >> On Mon, Apr 12, 2010 at 8:15 PM, David Goldsmith > > wrote: >> >>> E.g., http://docs.scipy.org/numpy/docs/ lists >>> polynomial.chebyshev.Chebyshev.domain even though domain is a data >>> attribute. "Bug" or "feature" (of pydocweb)? >>> >>> >> feature > > >> In the chebyshev case I left domain as a public attribute in case someone >> wanted to play dangerous games. Are private attributes also exposed? >> >> no > > Ralf > OK. DG -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.gommers at googlemail.com Wed Apr 14 11:47:27 2010 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Wed, 14 Apr 2010 23:47:27 +0800 Subject: [SciPy-Dev] Release candidate 2 for NumPy 1.4.1 and SciPy 0.7.2 Message-ID: Hi, I am pleased to announce the second release candidate of both Scipy 0.7.2 and NumPy 1.4.1. Please test, and report any problems on the NumPy or SciPy list. I also want to specifically ask you to report success/failure with other libraries (Matplotlib, Pygame, ) based on NumPy or SciPy. Binaries, sources and release notes can be found at https://sourceforge.net/projects/numpy/files/ https://sourceforge.net/projects/scipy/files/ NumPy 1.4.1 ========== The main change over 1.4.0 is that datetime support has been removed. This fixes the binary incompatibility issues between NumPy and other libraries like SciPy and Matplotlib. There are also a number of other bug fixes, and no new features. Binaries for Python 2.5 and 2.6 are available for both Windows and OS X. SciPy 0.7.2 ========= The only change compared to 0.7.1 is that the C sources for Cython code have been regenerated with Cython 0.12.1. This ensures that SciPy 0.7.2 will work with NumPy 1.4.1, while also retaining backwards compatibility with NumPy 1.3.0. Note that the 0.7.x branch was created in January 2009, so a lot of fixes and new functionality in current trunk is not present in this release. Binaries for Python 2.6 are available for both Windows and OS X. Due to the age of the code no binaries for Python 2.5 are available. On behalf of the NumPy and SciPy developers, Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From jakevdp at gmail.com Wed Apr 14 12:55:45 2010 From: jakevdp at gmail.com (Jake VanderPlas) Date: Wed, 14 Apr 2010 12:55:45 -0400 Subject: [SciPy-Dev] Iterative Least Squares for Sparse Systems Message-ID: Hello, I've noticed a trunk project at http://projects.scipy.org/scipy/browser/trunk/scipy/sparse/linalg/isolve/lsqr.py This looks like a very useful piece of code - anybody know the status of including it in a scipy release? I ask because I need to find a solution of a very large over-determined sparse linear system. I suppose I could just use scipy.optimize.leastsq on a function which returns the residual, but that seems a bit hacked. Is there a better way to do this at present? -Jake From njs at pobox.com Wed Apr 14 13:17:02 2010 From: njs at pobox.com (Nathaniel Smith) Date: Wed, 14 Apr 2010 10:17:02 -0700 Subject: [SciPy-Dev] Iterative Least Squares for Sparse Systems In-Reply-To: References: Message-ID: On Wed, Apr 14, 2010 at 9:55 AM, Jake VanderPlas wrote: > Hello, > I've noticed a trunk project at > ?http://projects.scipy.org/scipy/browser/trunk/scipy/sparse/linalg/isolve/lsqr.py > This looks like a very useful piece of code - anybody know the status > of including it in a scipy release? > I ask because I need to find a solution of a very large > over-determined sparse linear system. ?I suppose I could just use > scipy.optimize.leastsq on a function which returns the residual, but > that seems a bit hacked. ?Is there a better way to do this at present? I guess it depends on the details of your problem, but you might find scikits.sparse.cholmod useful: http://packages.python.org/scikits.sparse/cholmod.html#quickstart -- Nathaniel From aisaac at american.edu Wed Apr 14 14:28:27 2010 From: aisaac at american.edu (Alan G Isaac) Date: Wed, 14 Apr 2010 14:28:27 -0400 Subject: [SciPy-Dev] Release candidate 2 for NumPy 1.4.1 and SciPy 0.7.2 In-Reply-To: References: Message-ID: <4BC6094B.9090302@american.edu> The NumPy tests still produce one assertion error. Matplotlib seems to work fine. Alan Isaac (Python 2.6.5, Vista 64 bit) ====================================================================== FAIL: test_special_values (test_umath_complex.TestClog) ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\Python26\lib\site-packages\numpy\core\tests\test_umath_complex.py", l ine 179, in test_special_values assert_almost_equal(np.log(x), y) File "C:\Python26\lib\site-packages\numpy\testing\utils.py", line 437, in asse rt_almost_equal "DESIRED: %s\n" % (str(actual), str(desired))) AssertionError: Items are not equal: ACTUAL: [ NaN+2.35619449j] DESIRED: (inf+2.35619449019j) ---------------------------------------------------------------------- Ran 2335 tests in 13.177s FAILED (KNOWNFAIL=7, SKIP=1, failures=1) From aisaac at american.edu Wed Apr 14 14:41:18 2010 From: aisaac at american.edu (Alan G Isaac) Date: Wed, 14 Apr 2010 14:41:18 -0400 Subject: [SciPy-Dev] Release candidate 2 for NumPy 1.4.1 and SciPy 0.7.2 In-Reply-To: References: Message-ID: <4BC60C4E.5080805@american.edu> SciPy tests: OK (KNOWNFAIL=4, SKIP=32) Alan Isaac (Python 2.6.5, Vista 64bit) c:\Python26\lib\site-packages\scipy\spatial\__init__.py:7: RuntimeWarning: numpy.dtype size changed, may indicate binary incompatibility from ckdtree import * c:\Python26\lib\site-packages\scipy\spatial\__init__.py:7: RuntimeWarning: numpy.flatiter size changed, may indicate binary incompatibility from ckdtree import * c:\Python26\lib\site-packages\scipy\linsolve\__init__.py:4: DeprecationWarning: scipy.linsolve has moved to scipy.sparse.linalg.dsolve warn('scipy.linsolve has moved to scipy.sparse.linalg.dsolve', DeprecationWarning) c:\Python26\lib\site-packages\scipy\stats\distributions.py:27: RuntimeWarning: numpy.dtype size changed, may indicate binary incompatibility import vonmises_cython c:\Python26\lib\site-packages\scipy\stats\distributions.py:27: RuntimeWarning: numpy.flatiter size changed, may indicate binary incompatibility import vonmises_cython .............................................................................................................................................................................................................................c:\Python26\lib\site-packages\scipy\interpolate\fitpack2.py:498: 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) .....c:\Python26\lib\site-packages\scipy\interpolate\fitpack2.py:439: 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.................................................................................................c:\Python26\lib\site-packages\scipy\io\matlab\mio.py:111: Warning: Unreadable variable "testfunc", because "Cannot read matlab functions" matfile_dict = MR.get_variables() ..........c:\Python26\lib\site-packages\scipy\io\matlab\mio.py:165: FutureWarning: Using oned_as default value ('column') This will change to 'row' in future versions oned_as=oned_as) .........................c:\Python26\lib\site-packages\scipy\io\matlab\tests\test_mio.py:438: FutureWarning: Using oned_as default value ('column') This will change to 'row' in future versions mfw = MatFile5Writer(StringIO()) ........c:\Python26\lib\site-packages\scipy\io\matlab\mio.py:84: FutureWarning: Using struct_as_record default value (False) This will change to True in future versions return MatFile5Reader(byte_stream, **kwargs) ...............................Warning: 1000000 bytes requested, 20 bytes read. .c:\Python26\lib\site-packages\numpy\lib\utils.py:140: DeprecationWarning: `write_array` is deprecated! This function is replaced by numpy.savetxt which allows the same functionality through a different syntax. warnings.warn(depdoc, DeprecationWarning) c:\Python26\lib\site-packages\numpy\lib\utils.py:140: DeprecationWarning: `read_array` is deprecated! The functionality of read_array is in numpy.loadtxt which allows the same functionality using different syntax. warnings.warn(depdoc, DeprecationWarning) .......................c:\Python26\lib\site-packages\numpy\lib\utils.py:140: DeprecationWarning: `npfile` is deprecated! You can achieve the same effect as using npfile, using ndarray.tofile and numpy.fromfile. Even better you can use memory-mapped arrays and data-types to map out a file format for direct manipulation in NumPy. warnings.warn(depdoc, DeprecationWarning) .........................................................................................................................................................SSSSSS......SSSSSS......SSSS.............................................................S.....................................................c:\Python26\lib\site-packages\scipy\linalg\decomp.py:1177: DeprecationWarning: qr econ argument will be removed after scipy 0.7. The economy transform will then be available through the mode='economic' argument. "the mode='economic' argument.", DeprecationWarning) .....................................................................................................................................................................................................................................................................................................SSS..................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................SSSSSSSSSSS........................................................................................................................................................................................ ...................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................K.K........................................................................................................................................................................................................................................................................................................................................................................................................................................................ ...................................................................................................................................................................................................................................c:\Python26\lib\site-packages\numpy\lib\function_base.py:185: Warning: The new semantics of histogram is now the default and the `new` keyword will be removed in NumPy 2.0. """, Warning) ....................................................................................S..................................................................................c:\Python26\lib\site-packages\scipy\stats\stats.py:420: DeprecationWarning: scipy.stats.mean is deprecated; please update your code to use numpy.mean. Please note that: - numpy.mean axis argument defaults to None, not 0 - numpy.mean has a ddof argument to replace bias in a more general manner. scipy.stats.mean(a, bias=True) can be replaced by numpy.mean(x, axis=0, ddof=1). axis=0, ddof=1).""", DeprecationWarning) .c:\Python26\lib\site-packages\scipy\stats\stats.py:1329: DeprecationWarning: scipy.stats.std is deprecated; please update your code to use numpy.std. Please note that: - numpy.std axis argument defaults to None, not 0 - numpy.std has a ddof argument to replace bias in a more general manner. scipy.stats.std(a, bias=True) can be replaced by numpy.std(x, axis=0, ddof=0), scipy.stats.std(a, bias=False) by numpy.std(x, axis=0, ddof=1). ddof=1).""", DeprecationWarning) c:\Python26\lib\site-packages\scipy\stats\stats.py:1305: DeprecationWarning: scipy.stats.var is deprecated; please update your code to use numpy.var. Please note that: - numpy.var axis argument defaults to None, not 0 - numpy.var has a ddof argument to replace bias in a more general manner. scipy.stats.var(a, bias=True) can be replaced by numpy.var(x, axis=0, ddof=0), scipy.stats.var(a, bias=False) by var(x, axis=0, ddof=1). ddof=1).""", DeprecationWarning) .c:\Python26\lib\site-packages\scipy\stats\morestats.py:603: UserWarning: Ties preclude use of exact statistic. warnings.warn("Ties preclude use of exact statistic.") ......c:\Python26\lib\site-packages\scipy\stats\stats.py:498: DeprecationWarning: scipy.stats.median is deprecated; please update your code to use numpy.median. Please note that: - numpy.median axis argument defaults to None, not 0 - numpy.median has a ddof argument to replace bias in a more general manner. scipy.stats.median(a, bias=True) can be replaced by numpy.median(x, axis=0, ddof=1). axis=0, ddof=1).""", DeprecationWarning) .....................................................................................................................................................................................................................................................Running unit tests for scipy NumPy version 1.4.1rc2 NumPy is installed in c:\Python26\lib\site-packages\numpy SciPy version 0.7.2rc2 SciPy is installed in c:\Python26\lib\site-packages\scipy Python version 2.6.5 (r265:79096, Mar 19 2010, 21:48:26) [MSC v.1500 32 bit (Intel)] nose version 0.11.0 Result may be inaccurate, approximate err = 5.76591035582e-08 Result may be inaccurate, approximate err = 1.00314019744e-10 Warning: friedmanchisquare test using Chisquared aproximation warning: specified build_dir '_bad_path_' does not exist or is not writable. Trying default locations warning: specified build_dir '_bad_path_' does not exist or is not writable. Trying default locations error removing c:\users\alanis~1\appdata\local\temp\tmpal53skcat_test: c:\users\alanis~1\appdata\local\temp\tmpal53skcat_test: The directory is not empty .................................................................................................. ---------------------------------------------------------------------- Ran 3488 tests in 45.053s OK (KNOWNFAIL=4, SKIP=32) building extensions here: c:\users\alanis~1\appdata\local\temp\Alan Isaac\python26_compiled\m3 ATLAS version 3.8.3 built by Administrator on Sun Nov 29 23:44:07 KST 2009: UNAME : CYGWIN_NT-5.1 david-70582ba55 1.5.25(0.156/4/2) 2008-06-12 19:34 i686 Cygwin INSTFLG : -1 0 -a 1 ARCHDEFS : -DATL_OS_WinNT -DATL_ARCH_Corei7 -DGCCWIN -DUseClock -DATL_SSE3 -DATL_SSE2 -DATL_SSE1 -DATL_GAS_x8632 F2CDEFS : -DAdd__ -DF77_INTEGER=int -DStringSunStyle CACHEEDGE: 524288 F77 : g77, version GNU Fortran (GCC) 3.4.4 (cygming special, gdc 0.12, using dmd 0.125) F77FLAGS : -O -m32 SMC : gcc, version gcc (GCC) 3.4.4 (cygming special, gdc 0.12, using dmd 0.125) SMCFLAGS : -fomit-frame-pointer -mfpmath=sse -msse3 -O2 -fno-schedule-insns2 -m32 SKC : gcc, version gcc (GCC) 3.4.4 (cygming special, gdc 0.12, using dmd 0.125) SKCFLAGS : -fomit-frame-pointer -mfpmath=sse -msse3 -O2 -fno-schedule-insns2 -m32 From PHobson at Geosyntec.com Wed Apr 14 14:56:02 2010 From: PHobson at Geosyntec.com (PHobson at Geosyntec.com) Date: Wed, 14 Apr 2010 14:56:02 -0400 Subject: [SciPy-Dev] Release candidate 2 for NumPy 1.4.1 and SciPy 0.7.2 In-Reply-To: References: Message-ID: Thanks for all the hard work on this. One minor error on imports. Doesn't appear to affect anything though. Python 2.6.2 (r262:71605, Apr 14 2009, 22:40:02) [MSC v.1500 32 bit (Intel)] Type "copyright", "credits" or "license" for more information. IPython 0.10 -- An enhanced Interactive Python. ? -> Introduction and overview of IPython's features. %quickref -> Quick reference. help -> Python's own help system. object? -> Details about 'object'. ?object also works, ?? prints more. In [2]: import numpy as np In [3]: np.__version__ Out[3]: '1.4.1rc2' In [4]: import scipy as sp In [5]: sp.__version__ Out[5]: '0.7.2rc2' In [6]: import scipy.stats as st C:\Python26\lib\site-packages\rpdb2.py:13502: RuntimeWarning: numpy.dtype size changed, may indicate binary incompatibility m = g_import(*args, **kwargs) C:\Python26\lib\site-packages\rpdb2.py:13502: RuntimeWarning: numpy.flatiter size changed, may indicate binary incompatibility m = g_import(*args, **kwargs) From: scipy-dev-bounces at scipy.org [mailto:scipy-dev-bounces at scipy.org] On Behalf Of Ralf Gommers Sent: Wednesday, April 14, 2010 8:47 AM To: Discussion of Numerical Python; SciPy Developers List; matplotlib-devel at lists.sourceforge.net; pygame-users at seul.org Subject: [SciPy-Dev] Release candidate 2 for NumPy 1.4.1 and SciPy 0.7.2 Hi, I am pleased to announce the second release candidate of both Scipy 0.7.2 and NumPy 1.4.1. Please test, and report any problems on the NumPy or SciPy list. I also want to specifically ask you to report success/failure with other libraries (Matplotlib, Pygame, ) based on NumPy or SciPy. Binaries, sources and release notes can be found at https://sourceforge.net/projects/numpy/files/ https://sourceforge.net/projects/scipy/files/ NumPy 1.4.1 ========== The main change over 1.4.0 is that datetime support has been removed. This fixes the binary incompatibility issues between NumPy and other libraries like SciPy and Matplotlib. There are also a number of other bug fixes, and no new features. Binaries for Python 2.5 and 2.6 are available for both Windows and OS X. SciPy 0.7.2 ========= The only change compared to 0.7.1 is that the C sources for Cython code have been regenerated with Cython 0.12.1. This ensures that SciPy 0.7.2 will work with NumPy 1.4.1, while also retaining backwards compatibility with NumPy 1.3.0. Note that the 0.7.x branch was created in January 2009, so a lot of fixes and new functionality in current trunk is not present in this release. Binaries for Python 2.6 are available for both Windows and OS X. Due to the age of the code no binaries for Python 2.5 are available. -------------- next part -------------- An HTML attachment was scrubbed... URL: From aisaac at american.edu Wed Apr 14 15:14:52 2010 From: aisaac at american.edu (Alan G Isaac) Date: Wed, 14 Apr 2010 15:14:52 -0400 Subject: [SciPy-Dev] Release candidate 2 for NumPy 1.4.1 and SciPy 0.7.2 In-Reply-To: <4BC60C4E.5080805@american.edu> References: <4BC60C4E.5080805@american.edu> Message-ID: <4BC6142C.9070109@american.edu> Shouldn't numpy.cov accept the ddof keyword for this release? (I think `bias` is to be deprecated.) Alan Isaac From ralf.gommers at googlemail.com Thu Apr 15 06:15:27 2010 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Thu, 15 Apr 2010 18:15:27 +0800 Subject: [SciPy-Dev] Release candidate 2 for NumPy 1.4.1 and SciPy 0.7.2 In-Reply-To: References: Message-ID: On Thu, Apr 15, 2010 at 2:56 AM, wrote: > Thanks for all the hard work on this. One minor error on imports. Doesn?t > appear to affect anything though. > These warnings are a known problem, coming from Cython code. They're annoying but harmless, and not easy to turn off. So for this release it looks like it'll stay this way. Cheers, Ralf > > In [6]: import scipy.stats as st > > C:\Python26\lib\site-packages\rpdb2.py:13502: RuntimeWarning: numpy.dtype > size changed, may indicate binary incompatibility > > m = g_import(*args, **kwargs) > > C:\Python26\lib\site-packages\rpdb2.py:13502: RuntimeWarning: > numpy.flatiter size changed, may indicate binary incompatibility > > m = g_import(*args, **kwargs) > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.gommers at googlemail.com Thu Apr 15 06:33:01 2010 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Thu, 15 Apr 2010 18:33:01 +0800 Subject: [SciPy-Dev] Release candidate 2 for NumPy 1.4.1 and SciPy 0.7.2 In-Reply-To: <4BC6094B.9090302@american.edu> References: <4BC6094B.9090302@american.edu> Message-ID: On Thu, Apr 15, 2010 at 2:28 AM, Alan G Isaac wrote: > The NumPy tests still produce one assertion error. > Hmm, missed that one. Josef said that it's been failing for a long time on Windows. Anyone want to confirm that it's OK to mark this as knownfail for this release? I'll open a ticket for it. For the record, this is the test: # clog(- inf + i inf) returns +inf + i3pi /4. x = np.array([complex(-np.inf, np.inf)], dtype=np.complex) y = np.complex(np.inf, 0.75 * np.pi) assert_almost_equal(np.log(x), y) On OS X it does work fine. Matplotlib seems to work fine. > Good to know, thanks for testing. Ralf > Alan Isaac > (Python 2.6.5, Vista 64 bit) > > > ====================================================================== > FAIL: test_special_values (test_umath_complex.TestClog) > ---------------------------------------------------------------------- > Traceback (most recent call last): > File > "C:\Python26\lib\site-packages\numpy\core\tests\test_umath_complex.py", l > ine 179, in test_special_values > assert_almost_equal(np.log(x), y) > File "C:\Python26\lib\site-packages\numpy\testing\utils.py", line 437, in > asse > rt_almost_equal > "DESIRED: %s\n" % (str(actual), str(desired))) > AssertionError: Items are not equal: > ACTUAL: [ NaN+2.35619449j] > DESIRED: (inf+2.35619449019j) > > > ---------------------------------------------------------------------- > Ran 2335 tests in 13.177s > > FAILED (KNOWNFAIL=7, SKIP=1, failures=1) > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dagss at student.matnat.uio.no Thu Apr 15 06:37:13 2010 From: dagss at student.matnat.uio.no (Dag Sverre Seljebotn) Date: Thu, 15 Apr 2010 12:37:13 +0200 Subject: [SciPy-Dev] Release candidate 2 for NumPy 1.4.1 and SciPy 0.7.2 In-Reply-To: References: Message-ID: <4BC6EC59.1090400@student.matnat.uio.no> Ralf Gommers wrote: > > > On Thu, Apr 15, 2010 at 2:56 AM, > wrote: > > Thanks for all the hard work on this. One minor error on imports. > Doesn?t appear to affect anything though. > > > These warnings are a known problem, coming from Cython code. They're > annoying but harmless, and not easy to turn off. So for this release > it looks like it'll stay this way. Actually, you can use the warnings module to set up a filter on the Cython warnings in the main SciPy import. Dag Sverre From ralf.gommers at googlemail.com Thu Apr 15 07:06:27 2010 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Thu, 15 Apr 2010 19:06:27 +0800 Subject: [SciPy-Dev] Release candidate 2 for NumPy 1.4.1 and SciPy 0.7.2 In-Reply-To: <4BC6EC59.1090400@student.matnat.uio.no> References: <4BC6EC59.1090400@student.matnat.uio.no> Message-ID: On Thu, Apr 15, 2010 at 6:37 PM, Dag Sverre Seljebotn < dagss at student.matnat.uio.no> wrote: > Ralf Gommers wrote: > > > > These warnings are a known problem, coming from Cython code. They're > > annoying but harmless, and not easy to turn off. So for this release > > it looks like it'll stay this way. > > Actually, you can use the warnings module to set up a filter on the > Cython warnings in the main SciPy import. > > Thanks Dag, that's quite straightforward. This works: warnings.filterwarnings(action='ignore', message='.*numpy.dtype size changed.*') warnings.filterwarnings(action='ignore', message='.*numpy.flatiter size changed.*') Cheers, Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From david at silveregg.co.jp Thu Apr 15 21:00:30 2010 From: david at silveregg.co.jp (David) Date: Fri, 16 Apr 2010 10:00:30 +0900 Subject: [SciPy-Dev] Release candidate 2 for NumPy 1.4.1 and SciPy 0.7.2 In-Reply-To: References: <4BC6EC59.1090400@student.matnat.uio.no> Message-ID: <4BC7B6AE.205@silveregg.co.jp> On 04/15/2010 08:06 PM, Ralf Gommers wrote: > > > On Thu, Apr 15, 2010 at 6:37 PM, Dag Sverre Seljebotn > > wrote: > > Ralf Gommers wrote: > > > > These warnings are a known problem, coming from Cython code. They're > > annoying but harmless, and not easy to turn off. So for this release > > it looks like it'll stay this way. > > Actually, you can use the warnings module to set up a filter on the > Cython warnings in the main SciPy import. > > Thanks Dag, that's quite straightforward. This works: > > warnings.filterwarnings(action='ignore', message='.*numpy.dtype size > changed.*') > warnings.filterwarnings(action='ignore', message='.*numpy.flatiter size > changed.*') I think it is ok to keep the filters for the release, but I think we should be let them on otherwise (for non-released versions), the warnings may be helpful in some situations. IOW, I would rather not set the filters in the trunk, only in 1.4.x for the release, thanks for the great work, Ralf, David From ralf.gommers at googlemail.com Fri Apr 16 10:43:31 2010 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Fri, 16 Apr 2010 22:43:31 +0800 Subject: [SciPy-Dev] Release candidate 2 for NumPy 1.4.1 and SciPy 0.7.2 In-Reply-To: <4BC7B6AE.205@silveregg.co.jp> References: <4BC6EC59.1090400@student.matnat.uio.no> <4BC7B6AE.205@silveregg.co.jp> Message-ID: On Fri, Apr 16, 2010 at 9:00 AM, David wrote: > On 04/15/2010 08:06 PM, Ralf Gommers wrote: > > > > > > On Thu, Apr 15, 2010 at 6:37 PM, Dag Sverre Seljebotn > > > > wrote: > > > > Ralf Gommers wrote: > > > > > > These warnings are a known problem, coming from Cython code. > They're > > > annoying but harmless, and not easy to turn off. So for this > release > > > it looks like it'll stay this way. > > > > Actually, you can use the warnings module to set up a filter on the > > Cython warnings in the main SciPy import. > > > > Thanks Dag, that's quite straightforward. This works: > > > > warnings.filterwarnings(action='ignore', message='.*numpy.dtype size > > changed.*') > > warnings.filterwarnings(action='ignore', message='.*numpy.flatiter size > > changed.*') > > I think it is ok to keep the filters for the release, but I think we > should be let them on otherwise (for non-released versions), the > warnings may be helpful in some situations. IOW, I would rather not set > the filters in the trunk, only in 1.4.x for the release, > > Sure, I agree, will only put them in 1.4.x. Cheers, Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.gommers at googlemail.com Fri Apr 16 10:54:30 2010 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Fri, 16 Apr 2010 22:54:30 +0800 Subject: [SciPy-Dev] Release candidate 2 for NumPy 1.4.1 and SciPy 0.7.2 In-Reply-To: <4BC6142C.9070109@american.edu> References: <4BC60C4E.5080805@american.edu> <4BC6142C.9070109@american.edu> Message-ID: On Thu, Apr 15, 2010 at 3:14 AM, Alan G Isaac wrote: > Shouldn't numpy.cov accept the ddof keyword for this release? > (I think `bias` is to be deprecated.) > > Maybe, but I can't find it in either the code or the tracker. I'm sure it's buried in the mailing list somewhere though. There should be a better way to keep track of this kind of thing. Since it's not a critical issue, at this point I think it's best to ignore this (like histogram) and get the final release out the door. Cheers, Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From aisaac at american.edu Fri Apr 16 11:42:30 2010 From: aisaac at american.edu (Alan G Isaac) Date: Fri, 16 Apr 2010 11:42:30 -0400 Subject: [SciPy-Dev] Release candidate 2 for NumPy 1.4.1 and SciPy 0.7.2 In-Reply-To: References: <4BC60C4E.5080805@american.edu> <4BC6142C.9070109@american.edu> Message-ID: <4BC88566.6030208@american.edu> > On Thu, Apr 15, 2010 at 3:14 AM, Alan G Isaac > wrote: > > Shouldn't numpy.cov accept the ddof keyword for this release? > (I think `bias` is to be deprecated.) On 4/16/2010 10:54 AM, Ralf Gommers wrote: > Maybe, but I can't find it in either the code or the tracker. I'm sure > it's buried in the mailing list somewhere though. There should be a > better way to keep track of this kind of thing. > > Since it's not a critical issue, at this point I think it's best to > ignore this (like histogram) and get the final release out the door. I have a vague memory that Josef was fixing this. (?) Alan From josef.pktd at gmail.com Fri Apr 16 11:48:13 2010 From: josef.pktd at gmail.com (josef.pktd at gmail.com) Date: Fri, 16 Apr 2010 11:48:13 -0400 Subject: [SciPy-Dev] Release candidate 2 for NumPy 1.4.1 and SciPy 0.7.2 In-Reply-To: <4BC88566.6030208@american.edu> References: <4BC60C4E.5080805@american.edu> <4BC6142C.9070109@american.edu> <4BC88566.6030208@american.edu> Message-ID: On Fri, Apr 16, 2010 at 11:42 AM, Alan G Isaac wrote: >> On Thu, Apr 15, 2010 at 3:14 AM, Alan G Isaac > > wrote: >> >> ? ? Shouldn't numpy.cov accept the ddof keyword for this release? >> ? ? (I think `bias` is to be deprecated.) > > > On 4/16/2010 10:54 AM, Ralf Gommers wrote: >> Maybe, but I can't find it in either the code or the tracker. I'm sure >> it's buried in the mailing list somewhere though. There should be a >> better way to keep track of this kind of thing. >> >> Since it's not a critical issue, at this point I think it's best to >> ignore this (like histogram) and get the final release out the door. > > > I have a vague memory that Josef was fixing this. (?) I'm not a numpy developer, I can only file tickets which I didn't do in this case. Josef > > Alan > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev > From aisaac at american.edu Fri Apr 16 15:28:23 2010 From: aisaac at american.edu (Alan G Isaac) Date: Fri, 16 Apr 2010 15:28:23 -0400 Subject: [SciPy-Dev] Release candidate 2 for NumPy 1.4.1 and SciPy 0.7.2 In-Reply-To: References: <4BC60C4E.5080805@american.edu> <4BC6142C.9070109@american.edu> <4BC88566.6030208@american.edu> Message-ID: <4BC8BA57.1010200@american.edu> >>> On Thu, Apr 15, 2010 at 3:14 AM, Alan G Isaac>> > wrote: >>> >>> Shouldn't numpy.cov accept the ddof keyword for this release? >>> (I think `bias` is to be deprecated.) >> On 4/16/2010 10:54 AM, Ralf Gommers wrote: >>> Maybe, but I can't find it in either the code or the tracker. I'm sure >>> it's buried in the mailing list somewhere though. There should be a >>> better way to keep track of this kind of thing. >>> >>> Since it's not a critical issue, at this point I think it's best to >>> ignore this (like histogram) and get the final release out the door. > On Fri, Apr 16, 2010 at 11:42 AM, Alan G Isaac wrote: >> I have a vague memory that Josef was fixing this. (?) On 4/16/2010 11:48 AM, josef.pktd at gmail.com wrote: > I'm not a numpy developer, I can only file tickets which I didn't do > in this case. OK, I filed a ticket: http://projects.scipy.org/numpy/ticket/1455 Alan From ralf.gommers at googlemail.com Mon Apr 19 00:25:07 2010 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Mon, 19 Apr 2010 12:25:07 +0800 Subject: [SciPy-Dev] Release candidate 3 for NumPy 1.4.1 and SciPy 0.7.2 Message-ID: Hi, I am pleased to announce the third release candidate of both Scipy 0.7.2 and NumPy 1.4.1. Please test, and report any problems on the NumPy or SciPy list. Binaries, sources and release notes can be found at https://sourceforge.net/projects/numpy/files/ https://sourceforge.net/projects/scipy/files/ Changes from RC2 ============== SciPy: warnings about possible binary incompatibilities with numpy have been suppressed NumPy: - fixed compatibility with Python 2.7b1 - marked test for complex log as a known failure NumPy 1.4.1 ========== The main change over 1.4.0 is that datetime support has been removed. This fixes the binary incompatibility issues between NumPy and other libraries like SciPy and Matplotlib. There are also a number of other bug fixes, and no new features. Binaries for Python 2.5 and 2.6 are available for both Windows and OS X. SciPy 0.7.2 ========= The only change compared to 0.7.1 is that the C sources for Cython code have been regenerated with Cython 0.12.1. This ensures that SciPy 0.7.2 will work with NumPy 1.4.1, while also retaining backwards compatibility with NumPy 1.3.0. Note that the 0.7.x branch was created in January 2009, so a lot of fixes and new functionality in current trunk is not present in this release. Binaries for Python 2.6 are available for both Windows and OS X. Due to the age of the code no binaries for Python 2.5 are available. On behalf of the NumPy and SciPy developers, Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan at sun.ac.za Mon Apr 19 00:59:48 2010 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Mon, 19 Apr 2010 06:59:48 +0200 Subject: [SciPy-Dev] Iterative Least Squares for Sparse Systems In-Reply-To: References: Message-ID: Hi Jake Lsqr will be included in the next release, but in the meantime you may download lsqr.py and import it as a stand-alone module. Lsqr is aimed at solving large, sparse, over-determined systems such as yours. Regards Stefan On Apr 14, 2010 6:58 PM, "Jake VanderPlas" wrote: Hello, I've noticed a trunk project at http://projects.scipy.org/scipy/browser/trunk/scipy/sparse/linalg/isolve/lsqr.py This looks like a very useful piece of code - anybody know the status of including it in a scipy release? I ask because I need to find a solution of a very large over-determined sparse linear system. I suppose I could just use scipy.optimize.leastsq on a function which returns the residual, but that seems a bit hacked. Is there a better way to do this at present? -Jake _______________________________________________ SciPy-Dev mailing list SciPy-Dev at scipy.org http://mail.scipy.org/mailman/listinfo/scipy-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From josef.pktd at gmail.com Mon Apr 19 01:07:56 2010 From: josef.pktd at gmail.com (josef.pktd at gmail.com) Date: Mon, 19 Apr 2010 01:07:56 -0400 Subject: [SciPy-Dev] Iterative Least Squares for Sparse Systems In-Reply-To: References: Message-ID: 2010/4/19 St?fan van der Walt : > Hi Jake > > Lsqr will be included in the next release, but in the meantime you may > download lsqr.py and import it as a stand-alone module. > > Lsqr is aimed at solving large, sparse, over-determined systems such as > yours. In case anyone is interested in the "Official successor", I recently saw LSMR: An iterative algorithm for least-squares problems 07 Apr 2010 (Updated 14 Apr 2010) Code covered by the BSD License Official successor to the LSQR algorithm, developed by David Fong and Michael Saunders. http://www.mathworks.com/matlabcentral/fileexchange/27183-lsmr-an-iterative-algorithm-for-least-squares-problems comment by John D'Errico : (The reduction in time was typically in the 10-50% range over lsqr in my tests on some random matrices.) Josef > > Regards > Stefan > > On Apr 14, 2010 6:58 PM, "Jake VanderPlas" wrote: > > Hello, > I've noticed a trunk project at > ?http://projects.scipy.org/scipy/browser/trunk/scipy/sparse/linalg/isolve/lsqr.py > This looks like a very useful piece of code - anybody know the status > of including it in a scipy release? > I ask because I need to find a solution of a very large > over-determined sparse linear system. ?I suppose I could just use > scipy.optimize.leastsq on a function which returns the residual, but > that seems a bit hacked. ?Is there a better way to do this at present? > ? -Jake > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev > > From ralf.gommers at googlemail.com Mon Apr 19 04:21:45 2010 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Mon, 19 Apr 2010 16:21:45 +0800 Subject: [SciPy-Dev] [Numpy-discussion] Release candidate 3 for NumPy 1.4.1 and SciPy 0.7.2 In-Reply-To: References: Message-ID: On Mon, Apr 19, 2010 at 3:35 PM, Sebastian Haase wrote: > Hi, > Congratulations. I might be unnecessarily dense - but what SciPy am I > supposed to use with the new numpy 1.4.1 for Python 2.5? I'm surprised > that there are no SciPy 0.7.2 binaries for Python 2.5 - is that > technically not possible ? > > You're not being dense, there are no 2.5 scipy binaries. I did not succeed in building them. The scipy 0.7 branch is so old (from Jan 2009) that it has never been compiled on OS X 10.6, and I did not yet find a way to get it to work. For Windows I also had problems, there it should be compiled against numpy 1.2 while the 2.6 binaries are compiled against numpy 1.3. The variations in numpy, python and OS just added up to make it unworkable. I can give it another try after the final release, but first priority is to finally release. Cheers, Ralf > On Mon, Apr 19, 2010 at 6:25 AM, Ralf Gommers > wrote: > > Hi, > > > > I am pleased to announce the third release candidate of both Scipy 0.7.2 > and > > NumPy 1.4.1. Please test, and report any problems on the NumPy or SciPy > > list. > > > > Binaries, sources and release notes can be found at > > https://sourceforge.net/projects/numpy/files/ > > https://sourceforge.net/projects/scipy/files/ > > > > > > Changes from RC2 > > ============== > > SciPy: warnings about possible binary incompatibilities with numpy have > been > > suppressed > > NumPy: - fixed compatibility with Python 2.7b1 > > - marked test for complex log as a known failure > > > > > > NumPy 1.4.1 > > ========== > > The main change over 1.4.0 is that datetime support has been removed. > This > > fixes the binary incompatibility issues between NumPy and other libraries > > like SciPy and Matplotlib. > > > > There are also a number of other bug fixes, and no new features. > > > > Binaries for Python 2.5 and 2.6 are available for both Windows and OS X. > > > > > > SciPy 0.7.2 > > ========= > > The only change compared to 0.7.1 is that the C sources for Cython code > have > > been regenerated with Cython 0.12.1. This ensures that SciPy 0.7.2 will > work > > with NumPy 1.4.1, while also retaining backwards compatibility with NumPy > > 1.3.0. > > > > Note that the 0.7.x branch was created in January 2009, so a lot of fixes > > and new functionality in current trunk is not present in this release. > > > > Binaries for Python 2.6 are available for both Windows and OS X. Due to > the > > age of the code no binaries for Python 2.5 are available. > > > > > > On behalf of the NumPy and SciPy developers, > > Ralf > > > > _______________________________________________ > > NumPy-Discussion mailing list > > NumPy-Discussion at scipy.org > > http://mail.scipy.org/mailman/listinfo/numpy-discussion > > > > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.gommers at googlemail.com Mon Apr 19 09:19:21 2010 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Mon, 19 Apr 2010 21:19:21 +0800 Subject: [SciPy-Dev] [Numpy-discussion] Release candidate 3 for NumPy 1.4.1 and SciPy 0.7.2 In-Reply-To: References: Message-ID: On Mon, Apr 19, 2010 at 4:21 PM, Ralf Gommers wrote: > > > On Mon, Apr 19, 2010 at 3:35 PM, Sebastian Haase wrote: > >> Hi, >> Congratulations. I might be unnecessarily dense - but what SciPy am I >> supposed to use with the new numpy 1.4.1 for Python 2.5? I'm surprised >> that there are no SciPy 0.7.2 binaries for Python 2.5 - is that >> technically not possible ? >> >> You're not being dense, there are no 2.5 scipy binaries. I did not succeed > in building them. The scipy 0.7 branch is so old (from Jan 2009) that it has > never been compiled on OS X 10.6, and I did not yet find a way to get it to > work. For Windows I also had problems, there it should be compiled against > numpy 1.2 while the 2.6 binaries are compiled against numpy 1.3. The > variations in numpy, python and OS just added up to make it unworkable. > > I can give it another try after the final release, but first priority is to > finally release. > To remind myself of the issue I tried building it again, and managed to build a 2.5 binary against numpy 1.3 on OS X at least. Can anyone tell me why 2.5 binaries are supposed to be built against numpy 1.2 and 2.6 binaries against numpy 1.3? Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.gommers at googlemail.com Mon Apr 19 20:23:43 2010 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Tue, 20 Apr 2010 08:23:43 +0800 Subject: [SciPy-Dev] [Numpy-discussion] Release candidate 3 for NumPy 1.4.1 and SciPy 0.7.2 In-Reply-To: References: Message-ID: On Mon, Apr 19, 2010 at 9:19 PM, Ralf Gommers wrote: > > > On Mon, Apr 19, 2010 at 4:21 PM, Ralf Gommers > wrote: > >> >> >> On Mon, Apr 19, 2010 at 3:35 PM, Sebastian Haase wrote: >> >>> Hi, >>> Congratulations. I might be unnecessarily dense - but what SciPy am I >>> supposed to use with the new numpy 1.4.1 for Python 2.5? I'm surprised >>> that there are no SciPy 0.7.2 binaries for Python 2.5 - is that >>> technically not possible ? >>> >>> You're not being dense, there are no 2.5 scipy binaries. I did not >> succeed in building them. The scipy 0.7 branch is so old (from Jan 2009) >> that it has never been compiled on OS X 10.6, and I did not yet find a way >> to get it to work. For Windows I also had problems, there it should be >> compiled against numpy 1.2 while the 2.6 binaries are compiled against numpy >> 1.3. The variations in numpy, python and OS just added up to make it >> unworkable. >> >> I can give it another try after the final release, but first priority is >> to finally release. >> > > To remind myself of the issue I tried building it again, and managed to > build a 2.5 binary against numpy 1.3 on OS X at least. Can anyone tell me > why 2.5 binaries are supposed to be built against numpy 1.2 and 2.6 binaries > against numpy 1.3? > > > It seems I've crawled a bit further up the learning curve since last time I tried. Scipy binaries for python 2.5 (built against numpy 1.2) are now on Sourceforge, please test them. Cheers, Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From david at silveregg.co.jp Mon Apr 19 20:57:43 2010 From: david at silveregg.co.jp (David) Date: Tue, 20 Apr 2010 09:57:43 +0900 Subject: [SciPy-Dev] [Numpy-discussion] Release candidate 3 for NumPy 1.4.1 and SciPy 0.7.2 In-Reply-To: References: Message-ID: <4BCCFC07.7010501@silveregg.co.jp> On 04/19/2010 10:19 PM, Ralf Gommers wrote: > > To remind myself of the issue I tried building it again, and managed to > build a 2.5 binary against numpy 1.3 on OS X at least. Can anyone tell > me why 2.5 binaries are supposed to be built against numpy 1.2 and 2.6 > binaries against numpy 1.3? I think the idea was that numpy 1.3 was required to build numpy on python 2.6, but numpy 1.2 was enough on python 2.5. What problems do you have exactly with python 2.5 and numpy 1.2 ? cheers, David From Ralf.Juengling at synopsys.com Tue Apr 20 11:40:08 2010 From: Ralf.Juengling at synopsys.com (Ralf Juengling) Date: Tue, 20 Apr 2010 08:40:08 -0700 Subject: [SciPy-Dev] missing documentation for optimize.line_search Message-ID: Hi, Two arguments to optimize.line_search, old_fval, and old_old_fval are not documented. Could anyone please fill in the blanks? Thanks, Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.gommers at googlemail.com Tue Apr 20 20:12:29 2010 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Wed, 21 Apr 2010 08:12:29 +0800 Subject: [SciPy-Dev] [Numpy-discussion] Release candidate 3 for NumPy 1.4.1 and SciPy 0.7.2 In-Reply-To: <4BCCFC07.7010501@silveregg.co.jp> References: <4BCCFC07.7010501@silveregg.co.jp> Message-ID: On Tue, Apr 20, 2010 at 8:57 AM, David wrote: > On 04/19/2010 10:19 PM, Ralf Gommers wrote: > > > > > To remind myself of the issue I tried building it again, and managed to > > build a 2.5 binary against numpy 1.3 on OS X at least. Can anyone tell > > me why 2.5 binaries are supposed to be built against numpy 1.2 and 2.6 > > binaries against numpy 1.3? > > I think the idea was that numpy 1.3 was required to build numpy on > python 2.6, but numpy 1.2 was enough on python 2.5. What problems do you > have exactly with python 2.5 and numpy 1.2 ? > > None anymore. Last time I tried I think it was the 10.4SDK thing. Cheers, Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From kwgoodman at gmail.com Wed Apr 21 20:58:53 2010 From: kwgoodman at gmail.com (Keith Goodman) Date: Wed, 21 Apr 2010 17:58:53 -0700 Subject: [SciPy-Dev] nanstd chokes on negative axis Message-ID: nanstd chokes on negative axis because of these two lines: shape = np.arange(x.ndim).tolist() shape.remove(axis) Example: >> from scipy.stats import nanstd >> x = np.array([1,2,3]) >> nanstd(x) # <--- good 1.0 >> nanstd(x, axis=0) # <--- good 1.0 >> nanstd(x, axis=-1) # <--- BAD --------------------------------------------------------------------------- ValueError: list.remove(x): x not in list Suggested fix: shape = range(x.ndim) shape.remove(shape[axis]) Ticket: http://projects.scipy.org/scipy/ticket/1161 From dwf at cs.toronto.edu Wed Apr 21 23:12:23 2010 From: dwf at cs.toronto.edu (David Warde-Farley) Date: Wed, 21 Apr 2010 23:12:23 -0400 Subject: [SciPy-Dev] linalg: cho_solve in basic.py and decomp.py In-Reply-To: <4BBC1808.6060006@enthought.com> References: <4BBC0FCD.9070905@enthought.com> <4BBC11FB.1060908@enthought.com> <4BBC1808.6060006@enthought.com> Message-ID: <4BCFBE97.10000@cs.toronto.edu> Warren Weckesser wrote: > Warren Weckesser wrote: > >> Warren Weckesser wrote: >> >> >>> I just noticed that the function cho_solve() is implemented in both >>> basic.py and decomp.py in the linalg package. In __init__.py, decomp is >>> imported after basic, so its implementation is used. Both are wrappers >>> of the lapack function potrs, and they do almost exactly the same >>> thing, but the implementation in basic.py handles an additional boolean >>> keyword argument, 'overwrite_b'. >>> >>> Any objections if I merge the two into one implementation in basic.py >>> (where the solvers seem to live), and keep the extra keyword argument? >>> >>> >>> >>> >> Minor change to that suggestion--I'd update the version in decomp.py, >> and remove it from basic.py. >> >> Warren >> >> >> >> > > lu_solve() is also implemented in both modules, but in this case, > decomp.py doesn't include lu_solve in __all__. Go figure. > > I'll clean up both modules, and, while I'm at it, incorporate the patch > that Yaroslav Halchenko recently reminded the list about > I'm way behind on my mailing list mail but +1 ahoy. David From stefan at sun.ac.za Thu Apr 22 10:53:29 2010 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Thu, 22 Apr 2010 16:53:29 +0200 Subject: [SciPy-Dev] Keyword name for GMRES Message-ID: Hi all, Would anybody object if I changed the "restrt" keyword of GMRES to "restart"? No sane human can remember which vowel to neglect if only one is removed! Regards St?fan From stefan at sun.ac.za Thu Apr 22 11:36:13 2010 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Thu, 22 Apr 2010 17:36:13 +0200 Subject: [SciPy-Dev] Keyword name for GMRES In-Reply-To: References: Message-ID: 2010/4/22 St?fan van der Walt : > Hi all, > > Would anybody object if I changed the "restrt" keyword of GMRES to > "restart"? ?No sane human can remember which vowel to neglect if only > one is removed! Another confusing parameter is the preconditioner "M". Usually, M is specified such that M^-1 A approximates identity. In our syntax, M*A approximates the identity---rather unconventional. We could change the parameter name to MI or Mi to indicate that it is the *inverse* of the preconditioner. Regards St?fan From ralf.gommers at googlemail.com Thu Apr 22 19:58:51 2010 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Fri, 23 Apr 2010 07:58:51 +0800 Subject: [SciPy-Dev] [ANN] SciPy 0.7.2 Message-ID: Hi, I am pleased to announce the release of SciPy 0.7.2. This maintenance release is made to keep SciPy compatible with NumPy 1.4.1. Binaries, sources and release notes can be found at https://sourceforge.net/projects/scipy/files/ Thank you to everyone who contributed to this release; developers, users who reported bugs, documentation writers, etc... Enjoy! The SciPy developers -------------- next part -------------- An HTML attachment was scrubbed... URL: From chanley at stsci.edu Thu Apr 22 21:31:55 2010 From: chanley at stsci.edu (Christopher Hanley) Date: Thu, 22 Apr 2010 21:31:55 -0400 Subject: [SciPy-Dev] ndimage and from __future__ import division Message-ID: Hi, As many of you likely know STScI forks the scipy version of ndimage for distribution with our code when we make STSCI_PYTHON releases. We do this for ease of installation reasons since some of our code still depends on ndimage from the days when if was distributed with numarray. In preparation for our next release we are preparing to support Python 2.6 with __future__ division. Since I was one of the last STScI folks to touch scipy I was tasked with looking into how ndimage would work with "from __future__ import division" added. All of the existing tests pass with the exception of 2: [redcedar:~] chanley% python Python 2.5.4 (r254:67916, Nov 5 2009, 16:32:32) [GCC 4.0.1 (Apple Inc. build 5465)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import ndimage >>> ndimage.test() .....................................................................................................................................................................................................F............F...................................................................................................................../Users/chanley/dev/ssb/site-packages/lib/python/ndimage/interpolation.py:429: DeprecationWarning: integer argument expected, got float for ii in range(size): ................................................................. ====================================================================== FAIL: generic filter 1 ---------------------------------------------------------------------- Traceback (most recent call last): File "/Users/chanley/dev/ssb/site-packages/lib/python/ndimage/test/test_ndimage.py", line 1154, in test_generic_filter01 self.failUnless(diff(r1, r2) < eps) AssertionError ====================================================================== FAIL: geometric transform 13 ---------------------------------------------------------------------- Traceback (most recent call last): File "/Users/chanley/dev/ssb/site-packages/lib/python/ndimage/test/test_ndimage.py", line 1628, in test_geometric_transform13 self.failUnless(diff(out, [1, 1, 1, 1]) < eps) AssertionError ---------------------------------------------------------------------- Ran 393 tests in 0.729s FAILED (failures=2) >>> I am actively looking into this issue and will happily add any fixes I come up with back to the scipy.ndimage code base. Since I am not too familiar with all of the algorithms being used in ndimage it is not readily clear to me which functions are assuming integer division. If any ndimage experts out there can look at these tests and instantly know which functions are implicitly assuming integer division please let me know. Otherwise I will keep plugging away on my own. I was just hoping this might be obvious to someone. Thank you for your time and help, Chris -- Christopher Hanley Senior Systems Software Engineer Space Telescope Science Institute 3700 San Martin Drive Baltimore MD, 21218 (410) 338-4338 From nwerneck at gmail.com Fri Apr 23 12:57:36 2010 From: nwerneck at gmail.com (Nicolau Werneck) Date: Fri, 23 Apr 2010 13:57:36 -0300 Subject: [SciPy-Dev] Problem running weave, getting KeyError: 0 for anything Message-ID: <20100423165736.GA24792@pathfinder.pcs.usp.br> Hello. I am trying to install weave in my machine, but the is something wrong. I can't run any examples, whatever I do I get a KeyError: 0 message. For instance: $ python Python 2.6.5 (r265:79063, Mar 23 2010, 11:04:30) [GCC 4.3.2] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import scipy.weave >>> a = 1 >>> scipy.weave.inline('return_val=a+2',['a']) Traceback (most recent call last): File "", line 1, in File "/usr/local/lib/python2.6/site-packages/scipy/weave/inline_tools.py", line 321, in inline results = attempt_function_call(code,local_dict,global_dict) File "/usr/local/lib/python2.6/site-packages/scipy/weave/inline_tools.py", line 389, in attempt_function_call function_list = function_catalog.get_functions(code,module_dir) File "/usr/local/lib/python2.6/site-packages/scipy/weave/catalog.py", line 612, in get_functions function_list = self.get_cataloged_functions(code) File "/usr/local/lib/python2.6/site-packages/scipy/weave/catalog.py", line 526, in get_cataloged_functions if cat is not None and code in cat: File "/usr/local/lib/python2.6/shelve.py", line 110, in __contains__ return key in self.dict File "/usr/local/lib/python2.6/site-packages/scipy/io/dumbdbm_patched.py", line 73, in __getitem__ pos, siz = self._index[key] # may raise KeyError KeyError: 0 >>> I get this same error regardless of the code string, BTW. I gat the exact same message even if I put a ocmplete garbage in it. Any thoughts?... thanks, ++nicolau -- Nicolau Werneck 1AAB 4050 1999 BDFF 4862 http://www.lti.pcs.usp.br/~nwerneck 4A33 D2B5 648B 4789 0327 Linux user #460716 "The great end of life is not knowledge but action." -- Thomas Huxley From pav+sp at iki.fi Sun Apr 25 05:59:03 2010 From: pav+sp at iki.fi (Pauli Virtanen) Date: Sun, 25 Apr 2010 09:59:03 +0000 (UTC) Subject: [SciPy-Dev] Keyword name for GMRES References: Message-ID: Thu, 22 Apr 2010 17:36:13 +0200, St?fan van der Walt wrote: > 2010/4/22 St?fan van der Walt : >> Would anybody object if I changed the "restrt" keyword of GMRES to >> "restart"? ?No sane human can remember which vowel to neglect if only >> one is removed! If you add a new keyword argument "restart" and leave the old one behind for backward compatibility, I don't think there will be many complaints. > Another confusing parameter is the preconditioner "M". Usually, M is > specified such that > M^-1 A approximates identity. In our syntax, M*A approximates the > identity---rather unconventional. We could change the parameter name to > MI or Mi to indicate that it is the *inverse* of the preconditioner. That might break everyone's code -- and every routine in scipy.sparse.linalg would need to make the same change. Pauli From ralf.gommers at googlemail.com Sun Apr 25 07:05:27 2010 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Sun, 25 Apr 2010 19:05:27 +0800 Subject: [SciPy-Dev] preparing for scipy 0.8 release Message-ID: Hi all, Now that scipy 0.7.2 and numpy 1.4.1 are out the door, it's time to look at what needs to be done for scipy 0.8. Some questions - What needs to be done and what do you all want included that's not in trunk yet in terms of features / new code / code cleanups? - Right now scipy trunk needs to be built against numpy trunk. Is it feasible to build against numpy 1.3 still, to get one backwards-compatible release? If not, 0.8 should be released in parallel with numpy 2.0. - Time line: do we want a release before SciPy2010 (end of June)? If so, there's only a month left before a freeze. If not, we could just provide snapshot binaries in June. Here's some things that I personally think should be done: - clean up tests so nothing is printed when they are run (deprecation warnings etc) - clean up build warnings as far as possible - create a little bit of order in Trac Cheers, Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From cournape at gmail.com Sun Apr 25 08:17:49 2010 From: cournape at gmail.com (David Cournapeau) Date: Sun, 25 Apr 2010 21:17:49 +0900 Subject: [SciPy-Dev] preparing for scipy 0.8 release In-Reply-To: References: Message-ID: On Sun, Apr 25, 2010 at 8:05 PM, Ralf Gommers wrote: > Hi all, > > Now that scipy 0.7.2 and numpy 1.4.1 are out the door, it's time to look at > what needs to be done for scipy 0.8. > > Some questions > - What needs to be done and what do you all want included that's not in > trunk yet in terms of features / new code / code cleanups? > - Right now scipy trunk needs to be built against numpy trunk. Is it > feasible to build against numpy 1.3 still, to get one backwards-compatible > release? If not, 0.8 should be released in parallel with numpy 2.0. You meant 1.4.0, right ? The trunk requires numpy 1.4.0 for quite a while, and making it supporting 1.3.0 is out of the question (because we use the npymath library support, which could not be reused in numpy 1.3.0). Although I would prefer making scipy 0.8.0 support numpy 1.4.0, it seems that supporting python 3.x in scipy would be easier if we made it depend on numpy 2.0 (so that we can add things in numpy to help). If people think making scipy 0.8.0 python 3.x worths it, it is doable in a short amount of time (that is it won't postpone scipy 0.8.0 release). > - Time line: do we want a release before SciPy2010 (end of June)? If so, > there's only a month left before a freeze. I think this is a good timeline. There has been a lot of new features in scipy, some quite useful (stats, sparse SVD, etc...). cheers, David From gael.varoquaux at normalesup.org Sun Apr 25 08:21:23 2010 From: gael.varoquaux at normalesup.org (Gael Varoquaux) Date: Sun, 25 Apr 2010 14:21:23 +0200 Subject: [SciPy-Dev] preparing for scipy 0.8 release In-Reply-To: References: Message-ID: <20100425122123.GB7299@phare.normalesup.org> On Sun, Apr 25, 2010 at 09:17:49PM +0900, David Cournapeau wrote: > If people think making scipy 0.8.0 python 3.x worths it, it is doable > in a short amount of time (that is it won't postpone scipy 0.8.0 > release). > > - Time line: do we want a release before SciPy2010 (end of June)? If so, > > there's only a month left before a freeze. > I think this is a good timeline. There has been a lot of new features > in scipy, some quite useful (stats, sparse SVD, etc...). That last line makes me think that it would be great if it could depend on numpy 1.4 rather than numpy 2. My 2 cents, Ga?l From josef.pktd at gmail.com Sun Apr 25 08:53:32 2010 From: josef.pktd at gmail.com (josef.pktd at gmail.com) Date: Sun, 25 Apr 2010 08:53:32 -0400 Subject: [SciPy-Dev] preparing for scipy 0.8 release In-Reply-To: <20100425122123.GB7299@phare.normalesup.org> References: <20100425122123.GB7299@phare.normalesup.org> Message-ID: On Sun, Apr 25, 2010 at 8:21 AM, Gael Varoquaux wrote: > On Sun, Apr 25, 2010 at 09:17:49PM +0900, David Cournapeau wrote: >> If people think making scipy 0.8.0 python 3.x worths it, it is doable >> in a short amount of time (that is it won't postpone scipy 0.8.0 >> release). > >> > - Time line: do we want a release before SciPy2010 (end of June)? If so, >> > there's only a month left before a freeze. > >> I think this is a good timeline. There has been a lot of new features >> in scipy, some quite useful (stats, sparse SVD, etc...). especially also signal (Warren has been very active) > > That last line makes me think that it would be great if it could depend > on numpy 1.4 rather than numpy 2. Is it possible to release scipy 0.8 for numpy 1.4, and right after a scipy 0.9 for numpy 2.0 with the python 3 code merged in ? What's going to be the version number after 0.9 ? 0.10 or 1. My cents, Josef > > My 2 cents, > > Ga?l > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev > From cournape at gmail.com Sun Apr 25 09:39:58 2010 From: cournape at gmail.com (David Cournapeau) Date: Sun, 25 Apr 2010 22:39:58 +0900 Subject: [SciPy-Dev] preparing for scipy 0.8 release In-Reply-To: References: <20100425122123.GB7299@phare.normalesup.org> Message-ID: On Sunday, April 25, 2010, wrote: > On Sun, Apr 25, 2010 at 8:21 AM, Gael Varoquaux > wrote: >> On Sun, Apr 25, 2010 at 09:17:49PM +0900, David Cournapeau wrote: >>> If people think making scipy 0.8.0 python 3.x worths it, it is doable >>> in a short amount of time (that is it won't postpone scipy 0.8.0 >>> release). >> >>> > - Time line: do we want a release before SciPy2010 (end of June)? If so, >>> > there's only a month left before a freeze. >> >>> I think this is a good timeline. There has been a lot of new features >>> in scipy, some quite useful (stats, sparse SVD, etc...). > > especially also signal (Warren has been very active) > >> >> That last line makes me think that it would be great if it could depend >> on numpy 1.4 rather than numpy 2. > > Is it possible to release scipy 0.8 for numpy 1.4, and right after a > scipy 0.9 for numpy 2.0 with the python 3 code merged in ? It is of course possible. But it would mean tha scipy compatible With python 3 would come much later, at least at the current pace (1 release per year) i don't care much for one or the other. David > > What's going to be the version number after 0.9 ? 0.10 or 1. > > My cents, > > Josef > >> >> My 2 cents, >> >> Ga?l >> _______________________________________________ >> SciPy-Dev mailing list >> SciPy-Dev at scipy.org >> http://mail.scipy.org/mailman/listinfo/scipy-dev >> > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev > From ralf.gommers at googlemail.com Sun Apr 25 11:09:47 2010 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Sun, 25 Apr 2010 23:09:47 +0800 Subject: [SciPy-Dev] preparing for scipy 0.8 release In-Reply-To: References: <20100425122123.GB7299@phare.normalesup.org> Message-ID: On Sun, Apr 25, 2010 at 9:39 PM, David Cournapeau wrote: > On Sunday, April 25, 2010, wrote: > > On Sun, Apr 25, 2010 at 8:21 AM, Gael Varoquaux > > wrote: > >> On Sun, Apr 25, 2010 at 09:17:49PM +0900, David Cournapeau wrote: > >>> If people think making scipy 0.8.0 python 3.x worths it, it is doable > >>> in a short amount of time (that is it won't postpone scipy 0.8.0 > >>> release). > >> > >>> > - Time line: do we want a release before SciPy2010 (end of June)? If > so, > >>> > there's only a month left before a freeze. > >> > >>> I think this is a good timeline. There has been a lot of new features > >>> in scipy, some quite useful (stats, sparse SVD, etc...). > > > > especially also signal (Warren has been very active) > > > >> > >> That last line makes me think that it would be great if it could depend > >> on numpy 1.4 rather than numpy 2. > > > > Is it possible to release scipy 0.8 for numpy 1.4, and right after a > > scipy 0.9 for numpy 2.0 with the python 3 code merged in ? > > It is of course possible. But it would mean tha scipy compatible With > python 3 would come much later, at least at the current pace (1 > release per year) > > That pace will go up a bit I hope. If you think that python 3 support could be added before June, then it's also possible to do a release without it in June, and then 0.9 with it in August or September. Even without new features, I think doing two releases (0.8 <-> 1.4.1 and 0.9 <-> 2.0) is useful. Otherwise there will probably a lot of people who can't go to 2.0 yet because they need other libraries/programs that depend on numpy 1.4.1, and therefore are stuck with scipy 0.7.2. Cheers, Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From josef.pktd at gmail.com Sun Apr 25 11:16:36 2010 From: josef.pktd at gmail.com (josef.pktd at gmail.com) Date: Sun, 25 Apr 2010 11:16:36 -0400 Subject: [SciPy-Dev] preparing for scipy 0.8 release In-Reply-To: References: <20100425122123.GB7299@phare.normalesup.org> Message-ID: On Sun, Apr 25, 2010 at 11:09 AM, Ralf Gommers wrote: > > > On Sun, Apr 25, 2010 at 9:39 PM, David Cournapeau > wrote: >> >> On Sunday, April 25, 2010, ? wrote: >> > On Sun, Apr 25, 2010 at 8:21 AM, Gael Varoquaux >> > wrote: >> >> On Sun, Apr 25, 2010 at 09:17:49PM +0900, David Cournapeau wrote: >> >>> If people think making scipy 0.8.0 python 3.x worths it, it is doable >> >>> in a short amount of time (that is it won't postpone scipy 0.8.0 >> >>> release). >> >> >> >>> > - Time line: do we want a release before SciPy2010 (end of June)? If >> >>> > so, >> >>> > there's only a month left before a freeze. >> >> >> >>> I think this is a good timeline. There has been a lot of new features >> >>> in scipy, some quite useful (stats, sparse SVD, etc...). >> > >> > especially also signal (Warren has been very active) >> > >> >> >> >> That last line makes me think that it would be great if it could depend >> >> on numpy 1.4 rather than numpy 2. >> > >> > Is it possible to release scipy 0.8 for numpy 1.4, and right after a >> > scipy 0.9 for numpy 2.0 with the python 3 code merged in ? >> >> It is of course possible. But it would mean tha scipy compatible With >> python 3 would come much later, at least at the current pace (1 >> release per year) >> > That pace will go up a bit I hope. If you think that python 3 support could > be added before June, then it's also possible to do a release without it in > June, and then 0.9 with it in August or September. If you manage to do this, I think this will be very useful. Josef > > Even without new features, I think doing two releases (0.8 <-> 1.4.1 and 0.9 > <-> 2.0) is useful. Otherwise there will probably a lot of people who can't > go to 2.0 yet because they need other libraries/programs that depend on > numpy 1.4.1, and therefore are stuck with scipy 0.7.2. > > Cheers, > Ralf > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev > > From charlesr.harris at gmail.com Sun Apr 25 12:32:54 2010 From: charlesr.harris at gmail.com (Charles R Harris) Date: Sun, 25 Apr 2010 10:32:54 -0600 Subject: [SciPy-Dev] preparing for scipy 0.8 release In-Reply-To: References: Message-ID: On Sun, Apr 25, 2010 at 5:05 AM, Ralf Gommers wrote: > Hi all, > > Now that scipy 0.7.2 and numpy 1.4.1 are out the door, it's time to look at > what needs to be done for scipy 0.8. > > But first, you should announce the releases on the scipy homepage with some links ;) If a tree falls in the forest... Chuck -------------- next part -------------- An HTML attachment was scrubbed... URL: From chanley at stsci.edu Sun Apr 25 12:49:39 2010 From: chanley at stsci.edu (Christopher Hanley) Date: Sun, 25 Apr 2010 12:49:39 -0400 Subject: [SciPy-Dev] ndimage and from __future__ import division Message-ID: Hi, As many of you likely know STScI forks the scipy version of ndimage for distribution with our code when we make STSCI_PYTHON releases. We do this for ease of installation reasons since some of our code still depends on ndimage from the days when if was distributed with numarray. In preparation for our next release we are preparing to support Python 2.6 with __future__ division. Since I was one of the last STScI folks to touch scipy I was tasked with looking into how ndimage would work with "from __future__ import division" added. All of the existing tests pass with the exception of 2: [redcedar:~] chanley% python Python 2.5.4 (r254:67916, Nov 5 2009, 16:32:32) [GCC 4.0.1 (Apple Inc. build 5465)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import ndimage >>> ndimage.test() .....................................................................................................................................................................................................F............F...................................................................................................................../Users/chanley/dev/ssb/site-packages/lib/python/ndimage/interpolation.py:429: DeprecationWarning: integer argument expected, got float for ii in range(size): ................................................................. ====================================================================== FAIL: generic filter 1 ---------------------------------------------------------------------- Traceback (most recent call last): File "/Users/chanley/dev/ssb/site-packages/lib/python/ndimage/test/test_ndimage.py", line 1154, in test_generic_filter01 self.failUnless(diff(r1, r2) < eps) AssertionError ====================================================================== FAIL: geometric transform 13 ---------------------------------------------------------------------- Traceback (most recent call last): File "/Users/chanley/dev/ssb/site-packages/lib/python/ndimage/test/test_ndimage.py", line 1628, in test_geometric_transform13 self.failUnless(diff(out, [1, 1, 1, 1]) < eps) AssertionError ---------------------------------------------------------------------- Ran 393 tests in 0.729s FAILED (failures=2) >>> I am actively looking into this issue and will happily add any fixes I come up with back to the scipy.ndimage code base. Since I am not too familiar with all of the algorithms being used in ndimage it is not readily clear to me which functions are assuming integer division. If any ndimage experts out there can look at these tests and instantly know which functions are implicitly assuming integer division please let me know. Otherwise I will keep plugging away on my own. I was just hoping this might be obvious to someone. Thank you for your time and help, Chris -- Christopher Hanley Senior Systems Software Engineer Space Telescope Science Institute 3700 San Martin Drive Baltimore MD, 21218 (410) 338-4338 From pav+sp at iki.fi Sun Apr 25 18:44:42 2010 From: pav+sp at iki.fi (Pauli Virtanen) Date: Sun, 25 Apr 2010 22:44:42 +0000 (UTC) Subject: [SciPy-Dev] preparing for scipy 0.8 release References: Message-ID: Sun, 25 Apr 2010 19:05:27 +0800, Ralf Gommers wrote: > Now that scipy 0.7.2 and numpy 1.4.1 are out the door, it's time to look > at what needs to be done for scipy 0.8. > > Some questions > - What needs to be done and what do you all want included that's not in > trunk yet in terms of features / new code / code cleanups? I have these on my platter: * http://github.com/pv/scipy-work/tree/superlu-update SuperLU 4.0, which includes support for incomplete LU decompositions, which at least I've been really missing in Scipy. New feature: scipy.sparse.linalg.spilu Needs just some tests, otherwise done. So if someone wants to test it or write some tests exercising splu and spilu, that'd be helpful! * http://github.com/pv/scipy-work/tree/ticket/791-optimize-nonlin-rewrite New feature: scipy.optimize.nonlin rewrite Quite done, and with tests. However, scipy.optimize line searches take a ~20% performance hit because of the way I refactored them. If this doesn't sound good, I can try to rework it still more. * Might be also nice to fix the remaining most serious scipy.special bugs. > - Right now scipy trunk needs to be built against numpy trunk. Is it > feasible to build against numpy 1.3 still, to get one > backwards-compatible release? > If not, 0.8 should be released in parallel with numpy 2.0. - Time line: > do we want a release before SciPy2010 (end of June)? If so, there's only > a month left before a freeze. If not, we could just provide snapshot > binaries in June. As David said, we'll need at least Numpy >= 1.4, due to use of npymath. It might be difficult to go for Python 3 support if we want to have backwards compatibility with Numpy 1.4, unless we go really ugly and start duplicating some of the utility functions inside Scipy. But from a maintenance POV that might be less of a burden than having to maintain 0.8.x and 0.9.x simultaneously... Pauli From ralf.gommers at googlemail.com Sun Apr 25 20:11:08 2010 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Mon, 26 Apr 2010 08:11:08 +0800 Subject: [SciPy-Dev] preparing for scipy 0.8 release In-Reply-To: References: Message-ID: On Mon, Apr 26, 2010 at 12:32 AM, Charles R Harris < charlesr.harris at gmail.com> wrote: > > > On Sun, Apr 25, 2010 at 5:05 AM, Ralf Gommers > wrote: > >> Hi all, >> >> Now that scipy 0.7.2 and numpy 1.4.1 are out the door, it's time to look >> at what needs to be done for scipy 0.8. >> >> > But first, you should announce the releases on the scipy homepage with some > links ;) If a tree falls in the forest... > > Thanks, missed that one. Done. Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From charlesr.harris at gmail.com Sun Apr 25 21:22:45 2010 From: charlesr.harris at gmail.com (Charles R Harris) Date: Sun, 25 Apr 2010 19:22:45 -0600 Subject: [SciPy-Dev] preparing for scipy 0.8 release In-Reply-To: References: Message-ID: On Sun, Apr 25, 2010 at 5:05 AM, Ralf Gommers wrote: > Hi all, > > Now that scipy 0.7.2 and numpy 1.4.1 are out the door, it's time to look at > what needs to be done for scipy 0.8. > > Some questions > - What needs to be done and what do you all want included that's not in > trunk yet in terms of features / new code / code cleanups? > - Right now scipy trunk needs to be built against numpy trunk. Is it > feasible to build against numpy 1.3 still, to get one backwards-compatible > release? If not, 0.8 should be released in parallel with numpy 2.0. > - Time line: do we want a release before SciPy2010 (end of June)? If so, > there's only a month left before a freeze. If not, we could just provide > snapshot binaries in June. > > Here's some things that I personally think should be done: > - clean up tests so nothing is printed when they are run (deprecation > warnings etc) > - clean up build warnings as far as possible > - create a little bit of order in Trac > > I also have a cremez module that can be used to design equi-ripple filters with complex Hermitean coefficients. It is like the current remez in signal but more general. It uses the fft for interpolation, is written in cython and can also be used for L_inf fitting of functions on an interval with the coefficients naturally returned as a Chebyshev series. I don't know how much time I will have to polish it up, nor do I know the best place to put it, although I've been thinking scipy.optimise would be a good spot. Chuck -------------- next part -------------- An HTML attachment was scrubbed... URL: From d.l.goldsmith at gmail.com Mon Apr 26 03:29:10 2010 From: d.l.goldsmith at gmail.com (David Goldsmith) Date: Mon, 26 Apr 2010 00:29:10 -0700 Subject: [SciPy-Dev] missing documentation for optimize.line_search In-Reply-To: References: Message-ID: On Tue, Apr 20, 2010 at 8:40 AM, Ralf Juengling wrote: > Hi, > > Two arguments to optimize.line_search, old_fval, and old_old_fval are not > documented. Could anyone please fill in the blanks? > Thanks, > Ralf > > line_search uses minpack2.dcsrch to do its heavy lifting; old_fval and old_old_fval go into defining dcsrch's first two arguments, alpha1 = pymin(1.0,1.01*2*(phi0-old_old_fval)/derphi0) and phi0 = old_fval. Over on the dcsrch side, according to http://ftp.mcs.anl.gov/pub/MINPACK-2/csrch/dcsrch.f (which would appear to be the correct source for optimize/minpack2.pyd), the first two arguments are stp and f; dcsrch.f has this to say about these two arguments: "On entry stp is the current estimate of a satisfactory step [in the search direction]. On initial entry, a positive initial estimate must be provided." and "On initial entry f is the value of the function at 0. On subsequent entries f is the value of the function at stp." For more info on the mathematical & algorithmic significance of these parameters, I'll refer you to the reference already in the docstring. HTH. (I'll add this info - in a more "narrative" style - to the docstring soon.) DG -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.gommers at googlemail.com Mon Apr 26 07:41:07 2010 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Mon, 26 Apr 2010 19:41:07 +0800 Subject: [SciPy-Dev] preparing for scipy 0.8 release In-Reply-To: References: Message-ID: On Mon, Apr 26, 2010 at 6:44 AM, Pauli Virtanen > wrote: > Sun, 25 Apr 2010 19:05:27 +0800, Ralf Gommers wrote: > > Now that scipy 0.7.2 and numpy 1.4.1 are out the door, it's time to look > > at what needs to be done for scipy 0.8. > > > > Some questions > > - What needs to be done and what do you all want included that's not in > > trunk yet in terms of features / new code / code cleanups? > > I have these on my platter: > > * http://github.com/pv/scipy-work/tree/superlu-update > > SuperLU 4.0, which includes support for incomplete LU decompositions, > which at least I've been really missing in Scipy. > > New feature: scipy.sparse.linalg.spilu > > Needs just some tests, otherwise done. So if someone wants to test it > or write some tests exercising splu and spilu, that'd be helpful! > > * http://github.com/pv/scipy-work/tree/ticket/791-optimize-nonlin-rewrite > > New feature: scipy.optimize.nonlin rewrite > > Quite done, and with tests. However, scipy.optimize line searches take > a ~20% performance hit because of the way I refactored them. If this > doesn't sound good, I can try to rework it still more. > > * Might be also nice to fix the remaining most serious scipy.special > bugs. > So merging/fixing this in the next month is feasible for you? > > - Right now scipy trunk needs to be built against numpy trunk. Is it > > feasible to build against numpy 1.3 still, to get one > > backwards-compatible release? > > If not, 0.8 should be released in parallel with numpy 2.0. - Time line: > > do we want a release before SciPy2010 (end of June)? If so, there's only > > a month left before a freeze. If not, we could just provide snapshot > > binaries in June. > > As David said, we'll need at least Numpy >= 1.4, due to use of npymath. > > It might be difficult to go for Python 3 support if we want to have > backwards compatibility with Numpy 1.4, unless we go really ugly and > start duplicating some of the utility functions inside Scipy. But from a > maintenance POV that might be less of a burden than having to maintain > 0.8.x and 0.9.x simultaneously... > > The number of fixes in the 0.7 series is small, so I'm not sure if the maintenance burden is really that high (besides possibly having to do an extra maintenance release). It depends on how long you'd want to keep compatibility with numpy 1.4. Anyway, both options sound better than having no compatible release at all. Cheers, Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.gommers at googlemail.com Mon Apr 26 07:45:21 2010 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Mon, 26 Apr 2010 19:45:21 +0800 Subject: [SciPy-Dev] preparing for scipy 0.8 release In-Reply-To: References: Message-ID: On Mon, Apr 26, 2010 at 9:22 AM, Charles R Harris wrote: > > > On Sun, Apr 25, 2010 at 5:05 AM, Ralf Gommers > wrote: > >> >> > I also have a cremez module that can be used to design equi-ripple filters > with complex Hermitean coefficients. It is like the current remez in signal > but more general. It uses the fft for interpolation, is written in cython > and can also be used for L_inf fitting of functions on an interval with the > coefficients naturally returned as a Chebyshev series. I don't know how much > time I will have to polish it up, nor do I know the best place to put it, > although I've been thinking scipy.optimise would be a good spot. > > Sounds useful. If you would run out of time and we do two releases, you could put it only in 0.9. Cheers, Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From ndbecker2 at gmail.com Mon Apr 26 09:06:07 2010 From: ndbecker2 at gmail.com (Neal Becker) Date: Mon, 26 Apr 2010 09:06:07 -0400 Subject: [SciPy-Dev] preparing for scipy 0.8 release References: Message-ID: Charles R Harris wrote: > On Sun, Apr 25, 2010 at 5:05 AM, Ralf Gommers > wrote: > >> Hi all, >> >> Now that scipy 0.7.2 and numpy 1.4.1 are out the door, it's time to look >> at what needs to be done for scipy 0.8. >> >> Some questions >> - What needs to be done and what do you all want included that's not in >> trunk yet in terms of features / new code / code cleanups? >> - Right now scipy trunk needs to be built against numpy trunk. Is it >> feasible to build against numpy 1.3 still, to get one >> backwards-compatible release? If not, 0.8 should be released in parallel >> with numpy 2.0. - Time line: do we want a release before SciPy2010 (end >> of June)? If so, there's only a month left before a freeze. If not, we >> could just provide snapshot binaries in June. >> >> Here's some things that I personally think should be done: >> - clean up tests so nothing is printed when they are run (deprecation >> warnings etc) >> - clean up build warnings as far as possible >> - create a little bit of order in Trac >> >> > I also have a cremez module that can be used to design equi-ripple filters > with complex Hermitean coefficients. It is like the current remez in > signal but more general. It uses the fft for interpolation, is written in > cython and can also be used for L_inf fitting of functions on an interval > with the coefficients naturally returned as a Chebyshev series. I don't > know how much time I will have to polish it up, nor do I know the best > place to put it, although I've been thinking scipy.optimise would be a > good spot. > > Chuck FANTASTIC! I'd love to try this out. From ralf.gommers at googlemail.com Mon Apr 26 09:29:35 2010 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Mon, 26 Apr 2010 21:29:35 +0800 Subject: [SciPy-Dev] Fortran cleanup advice? Message-ID: Hi, I'm trying to make a start cleaning up the build warnings. One of the reasons it took me a while to get going with building scipy was the huge amount of harmless(?) warnings that hide the actually significant ones. Most warnings are from Fortran code, I count six types (examples at end of mail): 1. Nonconforming tab character. This one's straightforward, change tabs to spaces. 2. Unused variable. 3. Obsolete ASSIGN statement. 4. Label defined but not used. 5. Obsolete assigned GOTO statement 6. ' uninitialized. For 2-6, is there a good way to fix these without hiding actual bugs? For example 2 can be fixed by assigning to variable at top of subroutine with a comment saying what's going on there, but I'm not sure it is a good idea. Ralf Warning: Nonconforming tab character in column 1 of line 510 build/scons/scipy/integrate/dop/dop853.f:364.42: & SOLOUT,IOUT,IDID,NMAX,UROUND,METH,NSTIFF,SAFE,BETA,FAC1,FAC2, 1 Warning: Unused variable meth declared at (1) build/scons/scipy/optimize/slsqp/slsqp_optmz.f:1933.72: 10 assign 30 to next 1 Warning: Obsolete: ASSIGN statement at (1) build/scons/scipy/sparse/linalg/eigen/arpack/ARPACK/SRC/znaup2.f:322.5: 10 continue 1 Warning: Label 10 at (1) defined but not used build/scons/scipy/special/cdflib/dinvr.f:346.18: GO TO i99999 1 Warning: Obsolete: Assigned GOTO statement at (1) build/scons/scipy/special/specfun/specfun.f:6598: warning: ' may be used uninitialized in this function 'REALPART_EXPR build/scons/scipy/special/specfun/specfun.f:6598: warning: ' may be used uninitialized in this function -------------- next part -------------- An HTML attachment was scrubbed... URL: From pav+sp at iki.fi Mon Apr 26 14:01:12 2010 From: pav+sp at iki.fi (Pauli Virtanen) Date: Mon, 26 Apr 2010 18:01:12 +0000 (UTC) Subject: [SciPy-Dev] Fortran cleanup advice? References: Message-ID: Mon, 26 Apr 2010 21:29:35 +0800, Ralf Gommers wrote: > Most warnings are from Fortran code, I count six types (examples at end > of mail): > 1. Nonconforming tab character. This one's straightforward, change tabs > to spaces. > 2. Unused variable. > 3. Obsolete ASSIGN statement. > 4. Label defined but not used. > 5. Obsolete assigned GOTO statement > 6. 'foo' uninitialized. I'm not sure whether fixing these warnings pays off: a) I doubt fixing these warnings will help us spot any bugs. Most of the offending code is likely upstream code (= ancient Fortran libraries), and for the most part, they are solid. At least the warnings (3) and (5) are spurious. Computed gotos are not an obsolete feature in Fortran-77... b) In the worst case, stylistic fixes such as the above can cause errors. c) Moreover, such changes clutter up "svn/git blame" needlessly. Sometimes, it is useful to want to know what functional Scipy-specific modifications (= bug-fixes) have been made. d) If it ain't broke, don't fix it. Because of these, I would avoid doing purely stylistic fixes to upstream code. Scipy-specific code is of course a different matter -- warnings from code written by Scipy authors should be fixed. -- Pauli Virtanen From ralf.gommers at googlemail.com Tue Apr 27 09:30:15 2010 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Tue, 27 Apr 2010 21:30:15 +0800 Subject: [SciPy-Dev] preparing for scipy 0.8 release In-Reply-To: References: Message-ID: On Mon, Apr 26, 2010 at 7:41 PM, Ralf Gommers wrote: > > On Mon, Apr 26, 2010 at 6:44 AM, Pauli Virtanen > > wrote: > >> Sun, 25 Apr 2010 19:05:27 +0800, Ralf Gommers wrote: >> >> As David said, we'll need at least Numpy >= 1.4, due to use of npymath. >> >> It might be difficult to go for Python 3 support if we want to have >> backwards compatibility with Numpy 1.4, unless we go really ugly and >> start duplicating some of the utility functions inside Scipy. But from a >> maintenance POV that might be less of a burden than having to maintain >> 0.8.x and 0.9.x simultaneously... >> >> > The number of fixes in the 0.7 series is small, so I'm not sure if the > maintenance burden is really that high (besides possibly having to do an > extra maintenance release). It depends on how long you'd want to keep > compatibility with numpy 1.4. Anyway, both options sound better than having > no compatible release at all. > I thought about it some more, and a backwards compatible release with numpy 1.4.1 that is also compatible with numpy 2.0 is not even possible. And compatibility with 1.4.0 is not nearly as useful. So two releases would really make sense: 0.8 built against numpy 1.4.1 and 0.9 against numpy 2.0 with py3k compatibility. Here's a proposal for the release schedule: 30/05: create 0.8.x branch, beta available, trunk open to add py3k compatibility 11/06: 0.8 release candidate 1 22/06: 0.8 release 15/08: create 0.9.x branch, first beta 22/08: 0.9 release candidate 1 01/09: 0.9 release How does this sound? Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan at sun.ac.za Tue Apr 27 10:30:12 2010 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Tue, 27 Apr 2010 16:30:12 +0200 Subject: [SciPy-Dev] ndimage and from __future__ import division In-Reply-To: References: Message-ID: Hi Chris On 23 April 2010 03:31, Christopher Hanley wrote: > In preparation for our next release we are preparing to support Python > 2.6 with __future__ division. ?Since I was one of the last STScI folks > to touch scipy I was tasked with looking into how ndimage would work > with "from __future__ import division" added. ? All of the existing > tests pass with the exception of 2: I looked through all the division operators in ndimage, and it seems Peter consistently used "//" for integer division. Since the C code is not influenced, you should be safe. The only case I wasn't sure about is this line from morphology.py: pos = [ni * (structure.shape[ii] / 2) for ii in range(len(shape))] Since you now get two errors, I suspect the problem might be with the way the unit tests are constructed (I haven't checked how they used division). Regards St?fan From nwagner at iam.uni-stuttgart.de Tue Apr 27 14:39:32 2010 From: nwagner at iam.uni-stuttgart.de (Nils Wagner) Date: Tue, 27 Apr 2010 20:39:32 +0200 Subject: [SciPy-Dev] scipy.test failures in r6342 Message-ID: ====================================================================== ERROR: test_callback (test_iterative.TestGMRES) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/nwagner/local/lib64/python2.6/site-packages/scipy/sparse/linalg/isolve/tests/test_iterative.py", line 195, in test_callback x,flag = gmres(A, b, x0=zeros(A.shape[0]), tol=1e-16, maxiter=maxiter, callback=callback) File "/home/nwagner/local/lib64/python2.6/site-packages/scipy/sparse/linalg/isolve/iterative.py", line 387, in gmres work = np.zeros((6+restrt)*n,dtype=x.dtype) TypeError: unsupported operand type(s) for +: 'int' and 'NoneType' ====================================================================== ERROR: test whether all methods converge ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/nwagner/local/lib64/python2.6/site-packages/scipy/sparse/linalg/isolve/tests/test_iterative.py", line 99, in test_convergence x, info = solver(A, b, x0=x0, tol=tol) File "/home/nwagner/local/lib64/python2.6/site-packages/scipy/sparse/linalg/isolve/iterative.py", line 387, in gmres work = np.zeros((6+restrt)*n,dtype=x.dtype) TypeError: unsupported operand type(s) for +: 'int' and 'NoneType' ====================================================================== ERROR: test whether maxiter is respected ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/nwagner/local/lib64/python2.6/site-packages/scipy/sparse/linalg/isolve/tests/test_iterative.py", line 81, in test_maxiter x, info = solver(A, b, x0=x0, tol=tol, maxiter=3, callback=callback) File "/home/nwagner/local/lib64/python2.6/site-packages/scipy/sparse/linalg/isolve/iterative.py", line 387, in gmres work = np.zeros((6+restrt)*n,dtype=x.dtype) TypeError: unsupported operand type(s) for +: 'int' and 'NoneType' ====================================================================== ERROR: test whether all methods accept a trivial preconditioner ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/nwagner/local/lib64/python2.6/site-packages/scipy/sparse/linalg/isolve/tests/test_iterative.py", line 132, in test_precond x, info = solver(A, b, M=precond, x0=x0, tol=tol) File "/home/nwagner/local/lib64/python2.6/site-packages/scipy/sparse/linalg/isolve/iterative.py", line 387, in gmres work = np.zeros((6+restrt)*n,dtype=x.dtype) TypeError: unsupported operand type(s) for +: 'int' and 'NoneType' From pav+sp at iki.fi Tue Apr 27 18:07:21 2010 From: pav+sp at iki.fi (Pauli Virtanen) Date: Tue, 27 Apr 2010 22:07:21 +0000 (UTC) Subject: [SciPy-Dev] SuperLU 4.0 References: Message-ID: Mon, 26 Apr 2010 19:41:07 +0800, Ralf Gommers wrote: > On Mon, Apr 26, 2010 at 6:44 AM, Pauli Virtanen [clip] >> * http://github.com/pv/scipy-work/tree/superlu-update >> >> SuperLU 4.0, which includes support for incomplete LU decompositions, >> which at least I've been really missing in Scipy. >> >> New feature: scipy.sparse.linalg.spilu >> >> Needs just some tests, otherwise done. So if someone wants to test it >> or write some tests exercising splu and spilu, that'd be helpful! This thing is in SVN now, r6344 - r6358. Should be stable. Pauli From pav at iki.fi Tue Apr 27 18:22:19 2010 From: pav at iki.fi (Pauli Virtanen) Date: Tue, 27 Apr 2010 22:22:19 +0000 (UTC) Subject: [SciPy-Dev] SuperLU 4.0 References: Message-ID: Mon, 26 Apr 2010 19:41:07 +0800, Ralf Gommers wrote: [clip] >> * http://github.com/pv/scipy-work/tree/superlu-update >> >> SuperLU 4.0, which includes support for incomplete LU decompositions, >> which at least I've been really missing in Scipy. >> >> New feature: scipy.sparse.linalg.spilu >> >> Needs just some tests, otherwise done. So if someone wants to test it >> or write some tests exercising splu and spilu, that'd be helpful! This is now in SVN. Should be stable. Pauli From pav at iki.fi Tue Apr 27 18:32:47 2010 From: pav at iki.fi (Pauli Virtanen) Date: Wed, 28 Apr 2010 00:32:47 +0200 Subject: [SciPy-Dev] SuperLU 4.0 Message-ID: <1272407568.2129.1.camel@talisman> [clip] > * http://github.com/pv/scipy-work/tree/superlu-update > > SuperLU 4.0, which includes support for incomplete LU decompositions, > which at least I've been really missing in Scipy. > > New feature: scipy.sparse.linalg.spilu > > Needs just some tests, otherwise done. So if someone wants to test it > or write some tests exercising splu and spilu, that'd be helpful! This is now in SVN. Should be stable. Pauli From warren.weckesser at enthought.com Tue Apr 27 19:29:47 2010 From: warren.weckesser at enthought.com (Warren Weckesser) Date: Tue, 27 Apr 2010 18:29:47 -0500 Subject: [SciPy-Dev] preparing for scipy 0.8 release In-Reply-To: References: Message-ID: <4BD7736B.3060206@enthought.com> Ralf Gommers wrote: > Hi all, > > Now that scipy 0.7.2 and numpy 1.4.1 are out the door, it's time to > look at what needs to be done for scipy 0.8. > > Some questions > - What needs to be done and what do you all want included that's not > in trunk yet in terms of features / new code / code cleanups? > - Right now scipy trunk needs to be built against numpy trunk. Is it > feasible to build against numpy 1.3 still, to get one > backwards-compatible release? If not, 0.8 should be released in > parallel with numpy 2.0. > - Time line: do we want a release before SciPy2010 (end of June)? If > so, there's only a month left before a freeze. How about freeze on May 25, and final release a week before the conference (say June 21)? Warren > If not, we could just provide snapshot binaries in June. > > Here's some things that I personally think should be done: > - clean up tests so nothing is printed when they are run (deprecation > warnings etc) > - clean up build warnings as far as possible > - create a little bit of order in Trac > > Cheers, > Ralf > ------------------------------------------------------------------------ > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev > From d.l.goldsmith at gmail.com Tue Apr 27 21:57:43 2010 From: d.l.goldsmith at gmail.com (David Goldsmith) Date: Tue, 27 Apr 2010 18:57:43 -0700 Subject: [SciPy-Dev] Baffled by type_check.datetime_data Message-ID: >>> np.version.version '1.4.0' >>> from numpy.lib.type_check import datetime_data as dtd >>> help(dtd) Help on function datetime_data in module numpy.lib.type_check: datetime_data(dtype) Return (unit, numerator, denominator, events) from a datetime dtype >>> np.dtype(np.datetime_) dtype('datetime64[us]') >>> dtd(np.datetime_) Traceback (most recent call last): File "", line 1, in File "C:\Python26\lib\site-packages\numpy\lib\type_check.py", line 611, in dat etime_data if dtype.kind not in ['m','M']: AttributeError: type object 'numpy.datetime64' has no attribute 'kind' >>> for key in np.sctypes.keys(): ... for val in np.sctypes[key]: ... if 'kind' in dir(val): ... print np.sctype[key][val] ... >>> Bug, or failure to understand usage? (If the latter, someone please explain.) DG -- Mathematician: noun, someone who disavows certainty when their uncertainty set is non-empty, even if that set has measure zero. -------------- next part -------------- An HTML attachment was scrubbed... URL: From d.l.goldsmith at gmail.com Tue Apr 27 22:50:27 2010 From: d.l.goldsmith at gmail.com (David Goldsmith) Date: Tue, 27 Apr 2010 19:50:27 -0700 Subject: [SciPy-Dev] Is lib.npyio presently only available via SVN? Message-ID: Just did a fresh install of http://www.lfd.uci.edu/%7Egohlke/pythonlibs/numpy-1.4.1.win-amd64-py2.6.exe. Trying to import npyio I get: C:\Users\Fermat>python Python 2.6.5 (r265:79096, Mar 19 2010, 18:02:59) [MSC v.1500 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import numpy as np >>> np.version.version '1.4.1' >>> import numpy.lib.npyio Traceback (most recent call last): File "", line 1, in ImportError: No module named npyio ??? DG -- Mathematician: noun, someone who disavows certainty when their uncertainty set is non-empty, even if that set has measure zero. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pav at iki.fi Wed Apr 28 06:43:34 2010 From: pav at iki.fi (Pauli Virtanen) Date: Wed, 28 Apr 2010 12:43:34 +0200 Subject: [SciPy-Dev] SuperLU 4.0 Message-ID: <1272451414.1985.7.camel@talisman> (Sorry about spamming this message many times -- it seems there is some problem in mail delivery, at least for me...) [clip] > * http://github.com/pv/scipy-work/tree/superlu-update > > SuperLU 4.0, which includes support for incomplete LU decompositions, > which at least I've been really missing in Scipy. > > New feature: scipy.sparse.linalg.spilu > > Needs just some tests, otherwise done. So if someone wants to test it > or write some tests exercising splu and spilu, that'd be helpful! This is now in SVN. Should be stable. Pauli From ralf.gommers at googlemail.com Wed Apr 28 09:04:50 2010 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Wed, 28 Apr 2010 21:04:50 +0800 Subject: [SciPy-Dev] preparing for scipy 0.8 release In-Reply-To: References: Message-ID: On Mon, Apr 26, 2010 at 7:41 PM, Ralf Gommers wrote: > > > On Mon, Apr 26, 2010 at 6:44 AM, Pauli Virtanen > > wrote: > >> Sun, 25 Apr 2010 19:05:27 +0800, Ralf Gommers wrote: >> > Now that scipy 0.7.2 and numpy 1.4.1 are out the door, it's time to look >> > at what needs to be done for scipy 0.8. >> > >> > Some questions >> > - What needs to be done and what do you all want included that's not in >> > trunk yet in terms of features / new code / code cleanups? >> >> I have these on my platter: >> >> * http://github.com/pv/scipy-work/tree/superlu-update >> >> SuperLU 4.0, which includes support for incomplete LU decompositions, >> which at least I've been really missing in Scipy. >> >> New feature: scipy.sparse.linalg.spilu >> >> Needs just some tests, otherwise done. So if someone wants to test it >> or write some tests exercising splu and spilu, that'd be helpful! >> >> * http://github.com/pv/scipy-work/tree/ticket/791-optimize-nonlin-rewrite >> >> New feature: scipy.optimize.nonlin rewrite >> >> Quite done, and with tests. However, scipy.optimize line searches take >> a ~20% performance hit because of the way I refactored them. If this >> doesn't sound good, I can try to rework it still more. >> >> * Might be also nice to fix the remaining most serious scipy.special >> bugs. >> > > So merging/fixing this in the next month is feasible for you? > > >> > - Right now scipy trunk needs to be built against numpy trunk. Is it >> > feasible to build against numpy 1.3 still, to get one >> > backwards-compatible release? >> > If not, 0.8 should be released in parallel with numpy 2.0. - Time line: >> > do we want a release before SciPy2010 (end of June)? If so, there's only >> > a month left before a freeze. If not, we could just provide snapshot >> > binaries in June. >> >> As David said, we'll need at least Numpy >= 1.4, due to use of npymath. >> >> It might be difficult to go for Python 3 support if we want to have >> backwards compatibility with Numpy 1.4, unless we go really ugly and >> start duplicating some of the utility functions inside Scipy. But from a >> maintenance POV that might be less of a burden than having to maintain >> 0.8.x and 0.9.x simultaneously... >> >> > The number of fixes in the 0.7 series is small, so I'm not sure if the > maintenance burden is really that high (besides possibly having to do an > extra maintenance release). It depends on how long you'd want to keep > compatibility with numpy 1.4. Anyway, both options sound better than having > no compatible release at all. > > I thought about it some more, and a backwards compatible release with numpy 1.4.1 that is also compatible with numpy 2.0 is not even possible. And compatibility with 1.4.0 is not nearly as useful. So two releases would really make sense: 0.8 built against numpy 1.4.1 and 0.9 against numpy 2.0 with py3k compatibility. Here's a proposal for the release schedule: 30/05: create 0.8.x branch, beta available, trunk open to add py3k compatibility 11/06: 0.8 release candidate 1 22/06: 0.8 release 15/08: create 0.9.x branch, first beta 22/08: 0.9 release candidate 1 01/09: 0.9 release How does this sound? Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.kern at gmail.com Wed Apr 28 11:57:30 2010 From: robert.kern at gmail.com (Robert Kern) Date: Wed, 28 Apr 2010 10:57:30 -0500 Subject: [SciPy-Dev] Baffled by type_check.datetime_data In-Reply-To: References: Message-ID: On Tue, Apr 27, 2010 at 20:57, David Goldsmith wrote: >>>> np.version.version > '1.4.0' >>>> from numpy.lib.type_check import datetime_data as dtd >>>> help(dtd) > Help on function datetime_data in module numpy.lib.type_check: > > datetime_data(dtype) > ??? Return (unit, numerator, denominator, events) from a datetime dtype > >>>> np.dtype(np.datetime_) > dtype('datetime64[us]') >>>> dtd(np.datetime_) datatime_data() takes a dtype, not a scalar type. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco From bsouthey at gmail.com Wed Apr 28 12:08:21 2010 From: bsouthey at gmail.com (Bruce Southey) Date: Wed, 28 Apr 2010 11:08:21 -0500 Subject: [SciPy-Dev] preparing for scipy 0.8 release In-Reply-To: References: Message-ID: <4BD85D75.3020304@gmail.com> On 04/28/2010 08:04 AM, Ralf Gommers wrote: > time. apologies if you get it twice.> > > > On Mon, Apr 26, 2010 at 7:41 PM, Ralf Gommers > > wrote: > > > > On Mon, Apr 26, 2010 at 6:44 AM, Pauli Virtanen > wrote: > > Sun, 25 Apr 2010 19:05:27 +0800, Ralf Gommers wrote: > > Now that scipy 0.7.2 and numpy 1.4.1 are out the door, it's > time to look > > at what needs to be done for scipy 0.8. > > > > Some questions > > - What needs to be done and what do you all want included > that's not in > > trunk yet in terms of features / new code / code cleanups? > > I have these on my platter: > > * http://github.com/pv/scipy-work/tree/superlu-update > > SuperLU 4.0, which includes support for incomplete LU > decompositions, > which at least I've been really missing in Scipy. > > New feature: scipy.sparse.linalg.spilu > > Needs just some tests, otherwise done. So if someone wants to > test it > or write some tests exercising splu and spilu, that'd be helpful! > > * > http://github.com/pv/scipy-work/tree/ticket/791-optimize-nonlin-rewrite > > New feature: scipy.optimize.nonlin rewrite > > Quite done, and with tests. However, scipy.optimize line > searches take > a ~20% performance hit because of the way I refactored them. > If this > doesn't sound good, I can try to rework it still more. > > * Might be also nice to fix the remaining most serious > scipy.special > bugs. > > > So merging/fixing this in the next month is feasible for you? > > > - Right now scipy trunk needs to be built against numpy > trunk. Is it > > feasible to build against numpy 1.3 still, to get one > > backwards-compatible release? > > If not, 0.8 should be released in parallel with numpy 2.0. - > Time line: > > do we want a release before SciPy2010 (end of June)? If so, > there's only > > a month left before a freeze. If not, we could just provide > snapshot > > binaries in June. > > As David said, we'll need at least Numpy >= 1.4, due to use of > npymath. > > It might be difficult to go for Python 3 support if we want to > have > backwards compatibility with Numpy 1.4, unless we go really > ugly and > start duplicating some of the utility functions inside Scipy. > But from a > maintenance POV that might be less of a burden than having to > maintain > 0.8.x and 0.9.x simultaneously... > > The number of fixes in the 0.7 series is small, so I'm not sure if > the maintenance burden is really that high (besides possibly > having to do an extra maintenance release). It depends on how long > you'd want to keep compatibility with numpy 1.4. Anyway, both > options sound better than having no compatible release at all. > > I thought about it some more, and a backwards compatible release with > numpy 1.4.1 that is also compatible with numpy 2.0 is not even > possible. And compatibility with 1.4.0 is not nearly as useful. So two > releases would really make sense: 0.8 built against numpy 1.4.1 and > 0.9 against numpy 2.0 with py3k compatibility. > > Here's a proposal for the release schedule: > 30/05: create 0.8.x branch, beta available, trunk open to add py3k > compatibility > 11/06: 0.8 release candidate 1 > 22/06: 0.8 release > > 15/08: create 0.9.x branch, first beta > 22/08: 0.9 release candidate 1 > 01/09: 0.9 release > > How does this sound? > > Ralf > > Why so slow for the 0.8 branch? I would say create the branch now or as soon as possible once you identify what features need to go into it. I think it is important to have a numpy 1.4 compatible build available so that we minimize bug reports that we know are fixed. Bruce -------------- next part -------------- An HTML attachment was scrubbed... URL: From warren.weckesser at enthought.com Wed Apr 28 12:21:58 2010 From: warren.weckesser at enthought.com (Warren Weckesser) Date: Wed, 28 Apr 2010 11:21:58 -0500 Subject: [SciPy-Dev] preparing for scipy 0.8 release In-Reply-To: References: Message-ID: <4BD860A6.40705@enthought.com> Ralf Gommers wrote: > time. apologies if you get it twice.> > It looks like the mail server was "stuck" for a while. > > On Mon, Apr 26, 2010 at 7:41 PM, Ralf Gommers > > wrote: > > > > On Mon, Apr 26, 2010 at 6:44 AM, Pauli Virtanen > wrote: > > Sun, 25 Apr 2010 19:05:27 +0800, Ralf Gommers wrote: > > Now that scipy 0.7.2 and numpy 1.4.1 are out the door, it's > time to look > > at what needs to be done for scipy 0.8. > > > > Some questions > > - What needs to be done and what do you all want included > that's not in > > trunk yet in terms of features / new code / code cleanups? > > I have these on my platter: > > * http://github.com/pv/scipy-work/tree/superlu-update > > SuperLU 4.0, which includes support for incomplete LU > decompositions, > which at least I've been really missing in Scipy. > > New feature: scipy.sparse.linalg.spilu > > Needs just some tests, otherwise done. So if someone wants to > test it > or write some tests exercising splu and spilu, that'd be helpful! > > * > http://github.com/pv/scipy-work/tree/ticket/791-optimize-nonlin-rewrite > > New feature: scipy.optimize.nonlin rewrite > > Quite done, and with tests. However, scipy.optimize line > searches take > a ~20% performance hit because of the way I refactored them. > If this > doesn't sound good, I can try to rework it still more. > > * Might be also nice to fix the remaining most serious > scipy.special > bugs. > > > So merging/fixing this in the next month is feasible for you? > > > > - Right now scipy trunk needs to be built against numpy > trunk. Is it > > feasible to build against numpy 1.3 still, to get one > > backwards-compatible release? > > If not, 0.8 should be released in parallel with numpy 2.0. - > Time line: > > do we want a release before SciPy2010 (end of June)? If so, > there's only > > a month left before a freeze. If not, we could just provide > snapshot > > binaries in June. > > As David said, we'll need at least Numpy >= 1.4, due to use of > npymath. > > It might be difficult to go for Python 3 support if we want to > have > backwards compatibility with Numpy 1.4, unless we go really > ugly and > start duplicating some of the utility functions inside Scipy. > But from a > maintenance POV that might be less of a burden than having to > maintain > 0.8.x and 0.9.x simultaneously... > > > The number of fixes in the 0.7 series is small, so I'm not sure if > the maintenance burden is really that high (besides possibly > having to do an extra maintenance release). It depends on how long > you'd want to keep compatibility with numpy 1.4. Anyway, both > options sound better than having no compatible release at all. > > I thought about it some more, and a backwards compatible release with > numpy 1.4.1 that is also compatible with numpy 2.0 is not even > possible. And compatibility with 1.4.0 is not nearly as useful. So two > releases would really make sense: 0.8 built against numpy 1.4.1 and > 0.9 against numpy 2.0 with py3k compatibility. > > Here's a proposal for the release schedule: > 30/05: create 0.8.x branch, beta available, trunk open to add py3k > compatibility > 11/06: 0.8 release candidate 1 > 22/06: 0.8 release > Looks good to me. > 15/08: create 0.9.x branch, first beta > 22/08: 0.9 release candidate 1 > 01/09: 0.9 release > > How does this sound? > > Ralf > > ------------------------------------------------------------------------ > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev > From d.l.goldsmith at gmail.com Wed Apr 28 12:41:40 2010 From: d.l.goldsmith at gmail.com (David Goldsmith) Date: Wed, 28 Apr 2010 09:41:40 -0700 Subject: [SciPy-Dev] Baffled by type_check.datetime_data In-Reply-To: References: Message-ID: On Wed, Apr 28, 2010 at 8:57 AM, Robert Kern wrote: > On Tue, Apr 27, 2010 at 20:57, David Goldsmith > wrote: > >>>> np.version.version > > '1.4.0' > >>>> from numpy.lib.type_check import datetime_data as dtd > >>>> help(dtd) > > Help on function datetime_data in module numpy.lib.type_check: > > > > datetime_data(dtype) > > Return (unit, numerator, denominator, events) from a datetime dtype > > > >>>> np.dtype(np.datetime_) > > dtype('datetime64[us]') > >>>> dtd(np.datetime_) > > datatime_data() takes a dtype, not a scalar type. > > -- > Robert Kern > How is np.datetime_ not a dtype, and how is >>> np.dtype(np.datetime_) dtype('datetime64[us]') _not_ an indication that it isn't a dtype? How do I create a dtype object that datetime_data will recognize? DG > > "I have come to believe that the whole world is an enigma, a harmless > enigma that is made terrible by our own mad attempt to interpret it as > though it had an underlying truth." > -- Umberto Eco > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev > -- Mathematician: noun, someone who disavows certainty when their uncertainty set is non-empty, even if that set has measure zero. -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.kern at gmail.com Wed Apr 28 12:44:56 2010 From: robert.kern at gmail.com (Robert Kern) Date: Wed, 28 Apr 2010 11:44:56 -0500 Subject: [SciPy-Dev] Baffled by type_check.datetime_data In-Reply-To: References: Message-ID: On Wed, Apr 28, 2010 at 11:41, David Goldsmith wrote: > On Wed, Apr 28, 2010 at 8:57 AM, Robert Kern wrote: >> >> On Tue, Apr 27, 2010 at 20:57, David Goldsmith >> wrote: >> >>>> np.version.version >> > '1.4.0' >> >>>> from numpy.lib.type_check import datetime_data as dtd >> >>>> help(dtd) >> > Help on function datetime_data in module numpy.lib.type_check: >> > >> > datetime_data(dtype) >> > ??? Return (unit, numerator, denominator, events) from a datetime dtype >> > >> >>>> np.dtype(np.datetime_) >> > dtype('datetime64[us]') >> >>>> dtd(np.datetime_) >> >> datatime_data() takes a dtype, not a scalar type. >> >> -- >> Robert Kern > > How is np.datetime_ not a dtype, and how is > >>>> np.dtype(np.datetime_) > dtype('datetime64[us]') > > _not_ an indication that it isn't a dtype? How *is* it an indication that it is a dtype? The scalar types can be coerced to dtypes, but they are not dtype objects themselves, just like strings like '>i4' are str objects, not dtype objects but they can be coerced to dtype objects. > How do I create a dtype object > that datetime_data will recognize? You just did it! np.dtype(np.datetime_) -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco From d.l.goldsmith at gmail.com Wed Apr 28 13:11:20 2010 From: d.l.goldsmith at gmail.com (David Goldsmith) Date: Wed, 28 Apr 2010 10:11:20 -0700 Subject: [SciPy-Dev] Baffled by type_check.datetime_data In-Reply-To: References: Message-ID: OK, I get it. DG On Wed, Apr 28, 2010 at 9:44 AM, Robert Kern wrote: > On Wed, Apr 28, 2010 at 11:41, David Goldsmith > wrote: > > On Wed, Apr 28, 2010 at 8:57 AM, Robert Kern > wrote: > >> > >> On Tue, Apr 27, 2010 at 20:57, David Goldsmith > > >> wrote: > >> >>>> np.version.version > >> > '1.4.0' > >> >>>> from numpy.lib.type_check import datetime_data as dtd > >> >>>> help(dtd) > >> > Help on function datetime_data in module numpy.lib.type_check: > >> > > >> > datetime_data(dtype) > >> > Return (unit, numerator, denominator, events) from a datetime > dtype > >> > > >> >>>> np.dtype(np.datetime_) > >> > dtype('datetime64[us]') > >> >>>> dtd(np.datetime_) > >> > >> datatime_data() takes a dtype, not a scalar type. > >> > >> -- > >> Robert Kern > > > > How is np.datetime_ not a dtype, and how is > > > >>>> np.dtype(np.datetime_) > > dtype('datetime64[us]') > > > > _not_ an indication that it isn't a dtype? > > How *is* it an indication that it is a dtype? The scalar types can be > coerced to dtypes, but they are not dtype objects themselves, just > like strings like '>i4' are str objects, not dtype objects but they > can be coerced to dtype objects. > > > How do I create a dtype object > > that datetime_data will recognize? > > You just did it! > > np.dtype(np.datetime_) > > -- > Robert Kern > > "I have come to believe that the whole world is an enigma, a harmless > enigma that is made terrible by our own mad attempt to interpret it as > though it had an underlying truth." > -- Umberto Eco > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev > -- Mathematician: noun, someone who disavows certainty when their uncertainty set is non-empty, even if that set has measure zero. -------------- next part -------------- An HTML attachment was scrubbed... URL: From chanley at stsci.edu Wed Apr 28 13:32:43 2010 From: chanley at stsci.edu (Christopher Hanley) Date: Wed, 28 Apr 2010 13:32:43 -0400 Subject: [SciPy-Dev] ndimage and from __future__ import division In-Reply-To: References: Message-ID: On Tuesday, April 27, 2010, St?fan van der Walt wrote: > Hi Chris > > On 23 April 2010 03:31, Christopher Hanley wrote: >> In preparation for our next release we are preparing to support Python >> 2.6 with __future__ division. ?Since I was one of the last STScI folks >> to touch scipy I was tasked with looking into how ndimage would work >> with "from __future__ import division" added. ? All of the existing >> tests pass with the exception of 2: > > I looked through all the division operators in ndimage, and it seems > Peter consistently used "//" for integer division. ?Since the C code > is not influenced, you should be safe. > > The only case I wasn't sure about is this line from morphology.py: > > ? ?pos = [ni * (structure.shape[ii] / 2) for ii in range(len(shape))] > > Since you now get two errors, I suspect the problem might be with the > way the unit tests are constructed (I haven't checked how they used > division). Hi Stefan, I believe you are correct. I've already corrected one of the tests that was an obvious example. I still need the time to work on the second. I will commit my fixes to the scipy.ndimage unit tests when finished. Thank you for looking into this for me and validating my perception. Cheers, Chris > > Regards > St?fan > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev > -- Christopher Hanley Senior Systems Software Engineer Space Telescope Science Institute 3700 San Martin Drive Baltimore MD, 21218 (410) 338-4338 From pav at iki.fi Wed Apr 28 14:04:13 2010 From: pav at iki.fi (Pauli Virtanen) Date: Wed, 28 Apr 2010 18:04:13 +0000 (UTC) Subject: [SciPy-Dev] scipy.test failures in r6342 References: Message-ID: Tue, 27 Apr 2010 20:39:32 +0200, Nils Wagner wrote: > ====================================================================== > ERROR: test_callback (test_iterative.TestGMRES) > ---------------------------------------------------------------------- Those were fixed in a later commit. Cheers, Pauli From nwagner at iam.uni-stuttgart.de Wed Apr 28 14:27:03 2010 From: nwagner at iam.uni-stuttgart.de (Nils Wagner) Date: Wed, 28 Apr 2010 20:27:03 +0200 Subject: [SciPy-Dev] scipy.test failures in r6342 In-Reply-To: References: Message-ID: On Wed, 28 Apr 2010 18:04:13 +0000 (UTC) Pauli Virtanen wrote: > Tue, 27 Apr 2010 20:39:32 +0200, Nils Wagner wrote: >> ====================================================================== >> ERROR: test_callback (test_iterative.TestGMRES) >> ---------------------------------------------------------------------- > > Those were fixed in a later commit. > > Cheers, > Pauli > And how about that ====================================================================== ERROR: test_linsolve.TestSplu.test_splu_perm ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/nwagner/local/lib64/python2.6/site-packages/nose-0.11.2.dev-py2.6.egg/nose/case.py", line 183, in runTest self.test(*self.arg) File "/home/nwagner/local/lib64/python2.6/site-packages/scipy/sparse/linalg/dsolve/tests/test_linsolve.py", line 103, in test_splu_perm assert_(all(perm > -1)) MemoryError Cheers, Nils From pav at iki.fi Wed Apr 28 17:17:06 2010 From: pav at iki.fi (Pauli Virtanen) Date: Wed, 28 Apr 2010 21:17:06 +0000 (UTC) Subject: [SciPy-Dev] scipy.test failures in r6342 References: Message-ID: Wed, 28 Apr 2010 20:27:03 +0200, Nils Wagner wrote: [clip] > ====================================================================== > ERROR: test_linsolve.TestSplu.test_splu_perm > ---------------------------------------------------------------------- > Traceback (most recent call last): > File > "/home/nwagner/local/lib64/python2.6/site-packages/nose-0.11.2.dev- py2.6.egg/nose/case.py", > line 183, in runTest > self.test(*self.arg) > File > "/home/nwagner/local/lib64/python2.6/site-packages/scipy/sparse/linalg/ dsolve/tests/test_linsolve.py", > line 103, in test_splu_perm > assert_(all(perm > -1)) > MemoryError I don't see that. What's your platform? Pauli From ralf.gommers at googlemail.com Wed Apr 28 20:03:16 2010 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Thu, 29 Apr 2010 08:03:16 +0800 Subject: [SciPy-Dev] preparing for scipy 0.8 release In-Reply-To: <4BD85D75.3020304@gmail.com> References: <4BD85D75.3020304@gmail.com> Message-ID: On Thu, Apr 29, 2010 at 12:08 AM, Bruce Southey wrote: > On 04/28/2010 08:04 AM, Ralf Gommers wrote: > > I thought about it some more, and a backwards compatible release with > numpy 1.4.1 that is also compatible with numpy 2.0 is not even possible. And > compatibility with 1.4.0 is not nearly as useful. So two releases would > really make sense: 0.8 built against numpy 1.4.1 and 0.9 against numpy 2.0 > with py3k compatibility. > > Here's a proposal for the release schedule: > 30/05: create 0.8.x branch, beta available, trunk open to add py3k > compatibility > 11/06: 0.8 release candidate 1 > 22/06: 0.8 release > > 15/08: create 0.9.x branch, first beta > 22/08: 0.9 release candidate 1 > 01/09: 0.9 release > > How does this sound? > > Ralf > > > > Why so slow for the 0.8 branch? > I would say create the branch now or as soon as possible once you identify > what features need to go into it. I think it is important to have a numpy > 1.4 compatible build available so that we minimize bug reports that we know > are fixed. > > Bruce > > Trunk already builds correctly against 1.4.1 (at least on my machine), so there's not much to gain by doing this. On the other hand, all fixes and new features added after branching would have to be applied twice... Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.gommers at googlemail.com Wed Apr 28 20:13:14 2010 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Thu, 29 Apr 2010 08:13:14 +0800 Subject: [SciPy-Dev] Fortran cleanup advice? In-Reply-To: References: Message-ID: On Tue, Apr 27, 2010 at 2:01 AM, Pauli Virtanen > wrote: > Mon, 26 Apr 2010 21:29:35 +0800, Ralf Gommers wrote: > > Most warnings are from Fortran code, I count six types (examples at end > > of mail): > > 1. Nonconforming tab character. This one's straightforward, change tabs > > to spaces. > > 2. Unused variable. > > 3. Obsolete ASSIGN statement. > > 4. Label defined but not used. > > 5. Obsolete assigned GOTO statement > > 6. 'foo' uninitialized. > > I'm not sure whether fixing these warnings pays off: > > a) I doubt fixing these warnings will help us spot any bugs. Most of the > offending code is likely upstream code (= ancient Fortran libraries), > and for the most part, they are solid. > > At least the warnings (3) and (5) are spurious. Computed gotos are > not an obsolete feature in Fortran-77... > > b) In the worst case, stylistic fixes such as the above can cause errors. > > c) Moreover, such changes clutter up "svn/git blame" needlessly. > Sometimes, it is useful to want to know what functional Scipy-specific > modifications (= bug-fixes) have been made. > > d) If it ain't broke, don't fix it. > > Because of these, I would avoid doing purely stylistic fixes to upstream > code. > Points taken. > > Scipy-specific code is of course a different matter -- warnings from code > written by Scipy authors should be fixed. > That was kind of my problem - those get lost in the noise now. Cheers, Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From d.l.goldsmith at gmail.com Thu Apr 29 02:24:36 2010 From: d.l.goldsmith at gmail.com (David Goldsmith) Date: Wed, 28 Apr 2010 23:24:36 -0700 Subject: [SciPy-Dev] Update on the "Needs editing" numpy docstrings Message-ID: Hi, all! I've been working on the remaining "Needs editing" status numpy docstrings, of which there are presently 74. I've compiled two lists: those I think might be classifiable as "Unimportant," and those I think might require somewhat lengthy docstrings (the latter list is meant to try to recruit helpers). ;-) Here are those lists: List of potentially "Unimportant"s timeinteger (autogenerated subclass of signedinteger) timedelta64 (autogenerated subclass of timeinteger) polytemplate.rel_import Everything in distutils that still has status "Needs editing" linalg (docstring - which consists of tables of objects - auto-generated?) lib.shape_base.get_array_wrap f2py.diagnose and its "Needs editing" status attributes numpy.lib._iotools.StringConverter.iterupgrade dtype.base and dtype.metadata List of potentially "long" ones All "Needs editing" status doc.* core.umath, core.shape_base, core.function_base numpy-docs/* If you have opinions on these (or if you look at the whole list of remaining "Needs editing" docstrings and feel that I've left some off the "Unimportant" list) please do chime in. Thanks, DG -- Mathematician: noun, someone who disavows certainty when their uncertainty set is non-empty, even if that set has measure zero. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cournape at gmail.com Thu Apr 29 06:23:42 2010 From: cournape at gmail.com (David Cournapeau) Date: Thu, 29 Apr 2010 19:23:42 +0900 Subject: [SciPy-Dev] Fortran cleanup advice? In-Reply-To: References: Message-ID: On Tue, Apr 27, 2010 at 3:01 AM, Pauli Virtanen wrote: > Mon, 26 Apr 2010 21:29:35 +0800, Ralf Gommers wrote: >> Most warnings are from Fortran code, I count six types (examples at end >> of mail): >> 1. Nonconforming tab character. This one's straightforward, change tabs >> to spaces. >> 2. Unused variable. >> 3. Obsolete ASSIGN statement. >> 4. Label defined but not used. >> 5. Obsolete assigned GOTO statement >> 6. 'foo' uninitialized. > > I'm not sure whether fixing these warnings pays off: agreed - although I think removing the warnings is by itself a worthy goal, as it effectively renders warnings useless ATM (since there are so many false alarms). The solution is to compile those fortran libraries differently - adding maybe an option to build_clib to disable warnings or something. > > a) I doubt fixing these warnings will help us spot any bugs. Most of the > ? offending code is likely upstream code (= ancient Fortran libraries), > ? and for the most part, they are solid. I think ralf's point is that when you have many false alarms, the legitimate ones are ignored. David From doutriaux1 at llnl.gov Thu Apr 29 12:17:38 2010 From: doutriaux1 at llnl.gov (=?utf-8?Q?Charles_=D8=B3=D9=85=D9=8A=D8=B1_Doutriaux?=) Date: Thu, 29 Apr 2010 09:17:38 -0700 Subject: [SciPy-Dev] numpy 1.4.1 f2py on Snow Leopard. Message-ID: Hello, I jsut built numpy 1.4.1 on my mac (64bit only no universal) Now f2py fails building any fortran code... my python: 2.6.5 meryem /svn/cdat/trunk >gcc --version i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5646) (dot 1) Copyright (C) 2007 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. meryem /svn/cdat/trunk >gfortran --version GNU Fortran (GCC) 4.5.0 20100107 (experimental) Copyright (C) 2009 Free Software Foundation, Inc. GNU Fortran comes with NO WARRANTY, to the extent permitted by law. You may redistribute copies of GNU Fortran under the terms of the GNU General Public License. For more information about these matters, see the file named COPYING I'm also attaching bzipped logs of my numpy and scipy (as an example that would be familiar to you guys) installs. scipy obviously fails because the f2py doesn't work. Thx, C. -------------- next part -------------- A non-text attachment was scrubbed... Name: scipy.LOG.bz2 Type: application/x-bzip2 Size: 24220 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: numpy-1.4.1.tar.gz.LOG.bz2 Type: application/x-bzip2 Size: 10228 bytes Desc: not available URL: From nwagner at iam.uni-stuttgart.de Thu Apr 29 14:55:27 2010 From: nwagner at iam.uni-stuttgart.de (Nils Wagner) Date: Thu, 29 Apr 2010 20:55:27 +0200 Subject: [SciPy-Dev] scipy.test failures in r6342 In-Reply-To: References: Message-ID: On Wed, 28 Apr 2010 21:17:06 +0000 (UTC) Pauli Virtanen wrote: > Wed, 28 Apr 2010 20:27:03 +0200, Nils Wagner wrote: > [clip] >> ====================================================================== >> ERROR: test_linsolve.TestSplu.test_splu_perm >> ---------------------------------------------------------------------- >> Traceback (most recent call last): >> File >> "/home/nwagner/local/lib64/python2.6/site-packages/nose-0.11.2.dev- > py2.6.egg/nose/case.py", >> line 183, in runTest >> self.test(*self.arg) >> File >> "/home/nwagner/local/lib64/python2.6/site-packages/scipy/sparse/linalg/ > dsolve/tests/test_linsolve.py", >> line 103, in test_splu_perm >> assert_(all(perm > -1)) >> MemoryError > > I don't see that. What's your platform? > Linux linux-mogv 2.6.31.12-0.2-default #1 SMP 2010-03-16 21:25:39 +0100 x86_64 x86_64 x86_64 GNU/Linux cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Pentium(R) Dual CPU T3200 @ 2.00GHz stepping : 13 cpu MHz : 1000.000 cache size : 1024 KB physical id : 0 siblings : 2 core id : 0 cpu cores : 2 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good pni dtes64 monitor ds_cpl est tm2 ssse3 cx16 xtpr pdcm lahf_lm bogomips : 3997.24 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: processor : 1 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Pentium(R) Dual CPU T3200 @ 2.00GHz stepping : 13 cpu MHz : 1000.000 cache size : 1024 KB physical id : 0 siblings : 2 core id : 1 cpu cores : 2 apicid : 1 initial apicid : 1 fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good pni dtes64 monitor ds_cpl est tm2 ssse3 cx16 xtpr pdcm lahf_lm bogomips : 3996.82 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: cat /proc/meminfo MemTotal: 1793140 kB MemFree: 569796 kB Buffers: 82048 kB Cached: 717552 kB SwapCached: 0 kB Active: 497276 kB Inactive: 617368 kB Active(anon): 316256 kB Inactive(anon): 0 kB Active(file): 181020 kB Inactive(file): 617368 kB Unevictable: 0 kB Mlocked: 0 kB SwapTotal: 2104472 kB SwapFree: 2104472 kB Dirty: 28616 kB Writeback: 0 kB AnonPages: 315044 kB Mapped: 118772 kB Slab: 72820 kB SReclaimable: 55088 kB SUnreclaim: 17732 kB PageTables: 15756 kB NFS_Unstable: 0 kB Bounce: 0 kB WritebackTmp: 0 kB CommitLimit: 3001040 kB Committed_AS: 915588 kB VmallocTotal: 34359738367 kB VmallocUsed: 18864 kB VmallocChunk: 34359712463 kB HugePages_Total: 0 HugePages_Free: 0 HugePages_Rsvd: 0 HugePages_Surp: 0 Hugepagesize: 2048 kB DirectMap4k: 9792 kB DirectMap2M: 1822720 kB Nils From pav at iki.fi Thu Apr 29 15:39:06 2010 From: pav at iki.fi (Pauli Virtanen) Date: Thu, 29 Apr 2010 19:39:06 +0000 (UTC) Subject: [SciPy-Dev] Fortran cleanup advice? References: Message-ID: Thu, 29 Apr 2010 08:13:14 +0800, Ralf Gommers wrote: > On Tue, Apr 27, 2010 at 2:01 AM, Pauli Virtanen > >> wrote: [clip] >> Scipy-specific code is of course a different matter -- warnings from >> code written by Scipy authors should be fixed. > > That was kind of my problem - those get lost in the noise now. Ok, that's a valid point. I'm not sure how to implement passing the correct flags to Fortran compilers here. Sounds like it may require some changes to numpy.distutils.fcompiler, unless the silencing flags are already listed there. Cheers, Pauli From d.l.goldsmith at gmail.com Thu Apr 29 15:58:23 2010 From: d.l.goldsmith at gmail.com (David Goldsmith) Date: Thu, 29 Apr 2010 12:58:23 -0700 Subject: [SciPy-Dev] datetime re-introduction? Message-ID: Mea culpa: I stopped paying attention to the whole datetime removal discussion when it got bogged down in debating the numbering of releases - what was the conclusion vis-a-vis when/if datetime support will be re-introduced? Assuming it's when, not if, is it to have the same API (not ABI) as in 1.4.0? Thanks! DG -------------- next part -------------- An HTML attachment was scrubbed... URL: From guyer at nist.gov Thu Apr 29 19:52:30 2010 From: guyer at nist.gov (Jonathan Guyer) Date: Thu, 29 Apr 2010 19:52:30 -0400 Subject: [SciPy-Dev] numpy 1.4.1 f2py on Snow Leopard. In-Reply-To: References: Message-ID: <02693440-C4EB-496D-BB04-005B95A8EB92@nist.gov> On Apr 29, 2010, at 12:17 PM, Charles ???? Doutriaux wrote: > I jsut built numpy 1.4.1 on my mac (64bit only no universal) > Now f2py fails building any fortran code... > meryem /svn/cdat/trunk >gfortran --version > GNU Fortran (GCC) 4.5.0 20100107 (experimental) > Copyright (C) 2009 Free Software Foundation, Inc. I've recently been writing up instructions for building FiPy's prerequisites on Snow Leopard http://matforge.org/fipy/wiki/SnowLeopardSourceBuild, largely based on this blog posting: http://blog.hyperjeff.net/?p=160 There seem to be issues with gfortran 4.5.0, whereas gfortran 4.2.3 has worked for me and others. From charlesr.harris at gmail.com Thu Apr 29 21:06:13 2010 From: charlesr.harris at gmail.com (Charles R Harris) Date: Thu, 29 Apr 2010 19:06:13 -0600 Subject: [SciPy-Dev] datetime re-introduction? In-Reply-To: References: Message-ID: On Thu, Apr 29, 2010 at 1:58 PM, David Goldsmith wrote: > Mea culpa: I stopped paying attention to the whole datetime removal > discussion when it got bogged down in debating the numbering of releases - > what was the conclusion vis-a-vis when/if datetime support will be > re-introduced? Assuming it's when, not if, is it to have the same API (not > ABI) as in 1.4.0? Thanks! > > It will be in 2.0.0, it was never removed from the trunk. Chuck -------------- next part -------------- An HTML attachment was scrubbed... URL: From cournape at gmail.com Thu Apr 29 23:08:28 2010 From: cournape at gmail.com (David Cournapeau) Date: Fri, 30 Apr 2010 12:08:28 +0900 Subject: [SciPy-Dev] preparing for scipy 0.8 release In-Reply-To: References: Message-ID: On Tue, Apr 27, 2010 at 10:30 PM, Ralf Gommers wrote: > > > On Mon, Apr 26, 2010 at 7:41 PM, Ralf Gommers > wrote: >> >> On Mon, Apr 26, 2010 at 6:44 AM, Pauli Virtanen wrote: >>> >>> Sun, 25 Apr 2010 19:05:27 +0800, Ralf Gommers wrote: >>> >>> As David said, we'll need at least Numpy >= 1.4, due to use of npymath. >>> >>> It might be difficult to go for Python 3 support if we want to have >>> backwards compatibility with Numpy 1.4, unless we go really ugly and >>> start duplicating some of the utility functions inside Scipy. But from a >>> maintenance POV that might be less of a burden than having to maintain >>> 0.8.x and 0.9.x simultaneously... >>> >> >> The number of fixes in the 0.7 series is small, so I'm not sure if the >> maintenance burden is really that high (besides possibly having to do an >> extra maintenance release). It depends on how long you'd want to keep >> compatibility with numpy 1.4. Anyway, both options sound better than having >> no compatible release at all. > > I thought about it some more, and a backwards compatible release with numpy > 1.4.1 that is also compatible with numpy 2.0 is not even possible. And > compatibility with 1.4.0 is not nearly as useful. So two releases would > really make sense: 0.8 built against numpy 1.4.1 and 0.9 against numpy 2.0 > with py3k compatibility. > > Here's a proposal for the release schedule: > 30/05: create 0.8.x branch, beta available, trunk open to add py3k > compatibility > 11/06: 0.8 release candidate 1 > 22/06: 0.8 release > > 15/08: create 0.9.x branch, first beta > 22/08: 0.9 release candidate 1 > 01/09: 0.9 release > > How does this sound? Sounds good to me, but it means numpy 2.0 has to be out soon too (its release schedule should be earlier than scipy, the earlier the better), cheers, David From gisxperts at web.de Fri Apr 30 02:43:39 2010 From: gisxperts at web.de (hannes) Date: Fri, 30 Apr 2010 08:43:39 +0200 Subject: [SciPy-Dev] scipy.test bails with segmentation error Message-ID: <1272609819.29912.50.camel@hirubu> Dear List, I installed numpy and scipy from svn source as of yesterday (30 of april), however get an segmentation fault in the scipy.test().. Running unit tests for scipy NumPy version 1.4.1 NumPy is installed in /usr/local/lib/python2.6/dist-packages/numpy SciPy version 0.8.0.dev6362 SciPy is installed in /usr/local/lib/python2.6/dist-packages/scipy Python version 2.6.2 (release26-maint, Apr 19 2009, 01:58:18) [GCC 4.3.3] nose version 0.10.4 ...... ..saxpy:n=3 ....scopy:n=4 ..scopy:n=3 .............sscal:n=4 ....sswap:n=4 ..sswap:n=3 .....zaxpy:n=4 ..zaxpy:n=3 ....zcopy:n=4 ..zcopy:n=3 .............zscal:n=4 ....zswap:n=4 ..zswap:n=3 .......Result may be inaccurate, approximate err = 6.98199990784e-09 ...Result may be inaccurate, approximate err = 1.25504040833e-10 ..................................................................................................................... ...................................................................................................................... ......................................................................................................................... ........................................................................................................................ ..............ESSSSSSSSSSS.......Segmentation fault Anyone can shed some light ? python -c 'import os,sys;print os.name,sys.platform' posix linux2 uname -a Linux hirubu 2.6.28-18-generic #60-Ubuntu SMP Fri Mar 12 04:26:47 UTC 2010 x86_64 GNU/Linux hannes at hirubu:~$ gcc -v Using built-in specs. Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.3.3-5ubuntu4' --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.3.3 (Ubuntu 4.3.3-5ubuntu4) hannes at hirubu:~$ g77 --version bash: g77: command not found hannes at hirubu:~$ python -c 'import sys;print sys.version' 2.6.2 (release26-maint, Apr 19 2009, 01:58:18) [GCC 4.3.3] for point 5 cd scipy/Lib/linalg python setup_atlas_version.py build_ext --inplace --force python -c 'import atlas_version' i cant give any information as the scipy dir does not contain any directory lib for python /usr/lib/python2.6/site-packages/numpy/distutils/system_info.py lapack_info: libraries lapack not found in /usr/local/lib FOUND: libraries = ['lapack'] library_dirs = ['/usr/lib'] language = f77 lapack_opt_info: lapack_mkl_info: mkl_info: libraries mkl,vml,guide not found in /usr/local/lib libraries mkl,vml,guide not found in /usr/lib NOT AVAILABLE NOT AVAILABLE atlas_threads_info: Setting PTATLAS=ATLAS libraries ptf77blas,ptcblas,atlas not found in /usr/local/lib libraries lapack_atlas not found in /usr/local/lib libraries ptf77blas,ptcblas,atlas not found in /usr/lib/atlas libraries lapack_atlas not found in /usr/lib/atlas libraries ptf77blas,ptcblas,atlas not found in /usr/lib __main__.atlas_threads_info NOT AVAILABLE atlas_info: libraries f77blas,cblas,atlas not found in /usr/local/lib libraries lapack_atlas not found in /usr/local/lib libraries f77blas,cblas,atlas not found in /usr/lib/atlas libraries lapack_atlas not found in /usr/lib/atlas __main__.atlas_info FOUND: libraries = ['lapack', 'f77blas', 'cblas', 'atlas'] library_dirs = ['/usr/lib'] language = f77 include_dirs = ['/usr/include'] /usr/local/lib/python2.6/dist-packages/numpy/distutils/command/config.py:394: DeprecationWarning: +++++++++++++++++++++++++++++++++++++++++++++++++ Usage of get_output is deprecated: please do not use it anymore, and avoid configuration checks involving running executable on the target machine. +++++++++++++++++++++++++++++++++++++++++++++++++ DeprecationWarning) customize GnuFCompiler Could not locate executable g77 Found executable /usr/bin/f77 gnu: no Fortran 90 compiler found gnu: no Fortran 90 compiler found customize IntelFCompiler Could not locate executable ifort Could not locate executable ifc customize LaheyFCompiler Could not locate executable lf95 customize PGroupFCompiler Could not locate executable pgf90 Could not locate executable pgf77 customize AbsoftFCompiler Could not locate executable f90 absoft: no Fortran 90 compiler found absoft: no Fortran 90 compiler found absoft: no Fortran 90 compiler found absoft: no Fortran 90 compiler found absoft: no Fortran 90 compiler found absoft: no Fortran 90 compiler found customize NAGFCompiler Found executable /usr/bin/f95 customize VastFCompiler customize GnuFCompiler gnu: no Fortran 90 compiler found gnu: no Fortran 90 compiler found customize CompaqFCompiler Could not locate executable fort customize IntelItaniumFCompiler Could not locate executable efort Could not locate executable efc customize IntelEM64TFCompiler customize Gnu95FCompiler Found executable /usr/bin/gfortran customize Gnu95FCompiler customize Gnu95FCompiler using config FOUND: libraries = ['lapack', 'f77blas', 'cblas', 'atlas'] library_dirs = ['/usr/lib'] language = f77 define_macros = [('ATLAS_INFO', '"\\"?.?.?\\""')] include_dirs = ['/usr/include'] wx_info: Found executable /usr/bin/wx-config FOUND: libraries = ['wx_baseu_xml-2.8', 'wx_baseu_net-2.8', 'wx_baseu-2.8'] extra_link_args = ['-pthread', '-Wl,-Bsymbolic-functions'] define_macros = [('WX_INFO', '"\\"2.8.9\\""'), ('WX_VERSION_2_8_9', None), ('WX_RELEASE_2_8', None), ('_FILE_OFFSET_BITS', '64'), ('_LARGE_FILES', None), ('wxUSE_GUI', '0')] extra_compile_args = ['-pthread'] include_dirs = ['/usr/lib/wx/include/base-unicode-release-2.8', '/usr/include/wx-2.8'] lapack_atlas_info: libraries lapack_atlas,f77blas,cblas,atlas not found in /usr/local/lib libraries lapack_atlas not found in /usr/local/lib libraries lapack_atlas,f77blas,cblas,atlas not found in /usr/lib/atlas libraries lapack_atlas not found in /usr/lib/atlas __main__.lapack_atlas_info FOUND: libraries = ['lapack', 'lapack_atlas', 'f77blas', 'cblas', 'atlas'] library_dirs = ['/usr/lib'] language = f77 include_dirs = ['/usr/include'] umfpack_info: libraries umfpack not found in /usr/local/lib libraries umfpack not found in /usr/lib NOT AVAILABLE _pkg_config_info: Found executable /usr/bin/pkg-config NOT AVAILABLE lapack_atlas_threads_info: Setting PTATLAS=ATLAS libraries lapack_atlas,ptf77blas,ptcblas,atlas not found in /usr/local/lib libraries lapack_atlas not found in /usr/local/lib libraries lapack_atlas,ptf77blas,ptcblas,atlas not found in /usr/lib/atlas libraries lapack_atlas not found in /usr/lib/atlas libraries lapack_atlas,ptf77blas,ptcblas,atlas not found in /usr/lib __main__.lapack_atlas_threads_info NOT AVAILABLE x11_info: libraries X11 not found in /usr/local/lib FOUND: libraries = ['X11'] library_dirs = ['/usr/lib'] include_dirs = ['/usr/include'] blas_info: libraries blas not found in /usr/local/lib FOUND: libraries = ['blas'] library_dirs = ['/usr/lib'] language = f77 fftw_info: libraries fftw3 not found in /usr/local/lib libraries fftw3 not found in /usr/lib fftw3 not found libraries rfftw,fftw not found in /usr/local/lib libraries rfftw,fftw not found in /usr/lib fftw2 not found NOT AVAILABLE f2py_info: FOUND: sources = ['/usr/local/lib/python2.6/dist-packages/numpy/f2py/src/fortranobject.c'] include_dirs = ['/usr/local/lib/python2.6/dist-packages/numpy/f2py/src'] gdk_pixbuf_xlib_2_info: NOT AVAILABLE dfftw_threads_info: libraries drfftw_threads,dfftw_threads not found in /usr/local/lib libraries drfftw_threads,dfftw_threads not found in /usr/lib dfftw threads not found NOT AVAILABLE atlas_blas_info: libraries f77blas,cblas,atlas not found in /usr/local/lib libraries f77blas,cblas,atlas not found in /usr/lib/atlas FOUND: libraries = ['f77blas', 'cblas', 'atlas'] library_dirs = ['/usr/lib'] language = c include_dirs = ['/usr/include'] fftw3_info: libraries fftw3 not found in /usr/local/lib libraries fftw3 not found in /usr/lib fftw3 not found NOT AVAILABLE blas_opt_info: blas_mkl_info: libraries mkl,vml,guide not found in /usr/local/lib libraries mkl,vml,guide not found in /usr/lib NOT AVAILABLE atlas_blas_threads_info: Setting PTATLAS=ATLAS libraries ptf77blas,ptcblas,atlas not found in /usr/local/lib libraries ptf77blas,ptcblas,atlas not found in /usr/lib/atlas libraries ptf77blas,ptcblas,atlas not found in /usr/lib NOT AVAILABLE customize GnuFCompiler gnu: no Fortran 90 compiler found gnu: no Fortran 90 compiler found customize IntelFCompiler customize LaheyFCompiler customize PGroupFCompiler customize AbsoftFCompiler absoft: no Fortran 90 compiler found absoft: no Fortran 90 compiler found absoft: no Fortran 90 compiler found absoft: no Fortran 90 compiler found absoft: no Fortran 90 compiler found absoft: no Fortran 90 compiler found customize NAGFCompiler customize VastFCompiler customize GnuFCompiler gnu: no Fortran 90 compiler found gnu: no Fortran 90 compiler found customize CompaqFCompiler customize IntelItaniumFCompiler customize IntelEM64TFCompiler customize Gnu95FCompiler customize Gnu95FCompiler customize Gnu95FCompiler using config FOUND: libraries = ['f77blas', 'cblas', 'atlas'] library_dirs = ['/usr/lib'] language = c define_macros = [('ATLAS_INFO', '"\\"?.?.?\\""')] include_dirs = ['/usr/include'] sfftw_info: libraries srfftw,sfftw not found in /usr/local/lib libraries srfftw,sfftw not found in /usr/lib sfftw not found NOT AVAILABLE xft_info: FOUND: libraries = ['Xft'] define_macros = [('XFT_INFO', '"\\"2.1.13\\""'), ('XFT_VERSION_2_1_13', None)] include_dirs = ['/usr/include/freetype2'] fft_opt_info: fftw2_info: libraries rfftw,fftw not found in /usr/local/lib libraries rfftw,fftw not found in /usr/lib fftw2 not found NOT AVAILABLE dfftw_info: libraries drfftw,dfftw not found in /usr/local/lib libraries drfftw,dfftw not found in /usr/lib dfftw not found NOT AVAILABLE djbfft_info: NOT AVAILABLE NOT AVAILABLE gdk_x11_2_info: NOT AVAILABLE agg2_info: NOT AVAILABLE numarray_info: NOT AVAILABLE blas_src_info: NOT AVAILABLE fftw_threads_info: libraries rfftw_threads,fftw_threads not found in /usr/local/lib libraries rfftw_threads,fftw_threads not found in /usr/lib fftw threads not found NOT AVAILABLE _numpy_info: FOUND: define_macros = [('NUMERIC_VERSION', '"\\"24.2\\""'), ('NUMERIC', None)] gdk_info: NOT AVAILABLE gtkp_x11_2_info: NOT AVAILABLE sfftw_threads_info: libraries srfftw_threads,sfftw_threads not found in /usr/local/lib libraries srfftw_threads,sfftw_threads not found in /usr/lib sfftw threads not found NOT AVAILABLE boost_python_info: NOT AVAILABLE freetype2_info: FOUND: libraries = ['freetype'] define_macros = [('FREETYPE2_INFO', '"\\"9.20.3\\""'), ('FREETYPE2_VERSION_9_20_3', None)] include_dirs = ['/usr/include/freetype2'] gdk_2_info: NOT AVAILABLE lapack_src_info: NOT AVAILABLE gtkp_2_info: NOT AVAILABLE gdk_pixbuf_2_info: NOT AVAILABLE amd_info: libraries amd not found in /usr/local/lib libraries amd not found in /usr/lib NOT AVAILABLE Numeric_info: FOUND: define_macros = [('NUMERIC_VERSION', '"\\"24.2\\""'), ('NUMERIC', None)] numerix_info: numpy_info: FOUND: define_macros = [('NUMPY_VERSION', '"\\"1.4.1\\""'), ('NUMPY', None)] FOUND: define_macros = [('NUMPY_VERSION', '"\\"1.4.1\\""'), ('NUMPY', None)] From pav at iki.fi Fri Apr 30 04:26:51 2010 From: pav at iki.fi (Pauli Virtanen) Date: Fri, 30 Apr 2010 08:26:51 +0000 (UTC) Subject: [SciPy-Dev] scipy.test bails with segmentation error References: <1272609819.29912.50.camel@hirubu> Message-ID: Fri, 30 Apr 2010 08:43:39 +0200, hannes wrote: > I installed numpy and scipy from svn source as of yesterday (30 of > april), however get an segmentation fault in the scipy.test().. Please run "scipy.test(verbose=2)" so that we can see which test causes the problem. From d.l.goldsmith at gmail.com Fri Apr 30 04:47:33 2010 From: d.l.goldsmith at gmail.com (David Goldsmith) Date: Fri, 30 Apr 2010 01:47:33 -0700 Subject: [SciPy-Dev] datetime re-introduction? In-Reply-To: References: Message-ID: On Thu, Apr 29, 2010 at 6:06 PM, Charles R Harris wrote: > > > On Thu, Apr 29, 2010 at 1:58 PM, David Goldsmith wrote: > >> Mea culpa: I stopped paying attention to the whole datetime removal >> discussion when it got bogged down in debating the numbering of releases - >> what was the conclusion vis-a-vis when/if datetime support will be >> re-introduced? Assuming it's when, not if, is it to have the same API (not >> ABI) as in 1.4.0? Thanks! >> > > It will be in 2.0.0, it was never removed from the trunk. > And it will have the same API as in 1.4.0? DG > > Chuck > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev > > -- Mathematician: noun, someone who disavows certainty when their uncertainty set is non-empty, even if that set has measure zero. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gisxperts at web.de Fri Apr 30 08:20:40 2010 From: gisxperts at web.de (hannes) Date: Fri, 30 Apr 2010 14:20:40 +0200 Subject: [SciPy-Dev] scipy.test bails with segmentation error In-Reply-To: References: <1272609819.29912.50.camel@hirubu> Message-ID: <1272630040.10687.1.camel@hirubu> Dear Pauli, below the results. getting factors of real matrix ... SKIP: Skipping test: test_real_lu UMFPACK appears not to be compiled Prefactorize (with UMFPACK) matrix for solving with multiple rhs ... SKIP: Skipping test: test_factorized_umfpack UMFPACK appears not to be compiled Prefactorize matrix for solving with multiple rhs ... SKIP: Skipping test: test_factorized_without_umfpack UMFPACK appears not to be compiled Solve with UMFPACK: double precision complex ... SKIP: Skipping test: test_solve_complex_umfpack UMFPACK appears not to be compiled Solve: single precision complex ... SKIP: Skipping test: test_solve_complex_without_umfpack UMFPACK appears not to be compiled Solve with UMFPACK: double precision, sparse rhs ... SKIP: Skipping test: test_solve_sparse_rhs UMFPACK appears not to be compiled Solve with UMFPACK: double precision ... SKIP: Skipping test: test_solve_umfpack UMFPACK appears not to be compiled Solve: single precision ... SKIP: Skipping test: test_solve_without_umfpack UMFPACK appears not to be compiled test_singular (test_linsolve.TestLinsolve) ... ok test_twodiags (test_linsolve.TestLinsolve) ... ok test_linsolve.TestSplu.test_lu_refcount ... ok test_linsolve.TestSplu.test_spilu_nnz0 ... ok test_linsolve.TestSplu.test_spilu_smoketest ... ok test_linsolve.TestSplu.test_splu_basic ... ok test_linsolve.TestSplu.test_splu_nnz0 ... ok test_linsolve.TestSplu.test_splu_perm ... Segmentation fault Hannes On Fri, 2010-04-30 at 08:26 +0000, Pauli Virtanen wrote: > scipy.test(verbose=2) From charlesr.harris at gmail.com Fri Apr 30 09:22:39 2010 From: charlesr.harris at gmail.com (Charles R Harris) Date: Fri, 30 Apr 2010 07:22:39 -0600 Subject: [SciPy-Dev] datetime re-introduction? In-Reply-To: References: Message-ID: On Fri, Apr 30, 2010 at 2:47 AM, David Goldsmith wrote: > On Thu, Apr 29, 2010 at 6:06 PM, Charles R Harris < > charlesr.harris at gmail.com> wrote: > >> >> >> On Thu, Apr 29, 2010 at 1:58 PM, David Goldsmith > > wrote: >> >>> Mea culpa: I stopped paying attention to the whole datetime removal >>> discussion when it got bogged down in debating the numbering of releases - >>> what was the conclusion vis-a-vis when/if datetime support will be >>> re-introduced? Assuming it's when, not if, is it to have the same API (not >>> ABI) as in 1.4.0? Thanks! >>> >> >> It will be in 2.0.0, it was never removed from the trunk. >> > > And it will have the same API as in 1.4.0? > > I don't recall any changes, so probably yes. Chuck -------------- next part -------------- An HTML attachment was scrubbed... URL: From bsouthey at gmail.com Fri Apr 30 10:23:18 2010 From: bsouthey at gmail.com (Bruce Southey) Date: Fri, 30 Apr 2010 09:23:18 -0500 Subject: [SciPy-Dev] scipy.test bails with segmentation error In-Reply-To: <1272630040.10687.1.camel@hirubu> References: <1272609819.29912.50.camel@hirubu> <1272630040.10687.1.camel@hirubu> Message-ID: <4BDAE7D6.7010605@gmail.com> On 04/30/2010 07:20 AM, hannes wrote: > Dear Pauli, below the results. > > getting factors of real matrix ... SKIP: Skipping test: test_real_lu > UMFPACK appears not to be compiled > Prefactorize (with UMFPACK) matrix for solving with multiple rhs ... > SKIP: Skipping test: test_factorized_umfpack > UMFPACK appears not to be compiled > Prefactorize matrix for solving with multiple rhs ... SKIP: Skipping > test: test_factorized_without_umfpack > UMFPACK appears not to be compiled > Solve with UMFPACK: double precision complex ... SKIP: Skipping test: > test_solve_complex_umfpack > UMFPACK appears not to be compiled > Solve: single precision complex ... SKIP: Skipping test: > test_solve_complex_without_umfpack > UMFPACK appears not to be compiled > Solve with UMFPACK: double precision, sparse rhs ... SKIP: Skipping > test: test_solve_sparse_rhs > UMFPACK appears not to be compiled > Solve with UMFPACK: double precision ... SKIP: Skipping test: > test_solve_umfpack > UMFPACK appears not to be compiled > Solve: single precision ... SKIP: Skipping test: > test_solve_without_umfpack > UMFPACK appears not to be compiled > test_singular (test_linsolve.TestLinsolve) ... ok > test_twodiags (test_linsolve.TestLinsolve) ... ok > test_linsolve.TestSplu.test_lu_refcount ... ok > test_linsolve.TestSplu.test_spilu_nnz0 ... ok > test_linsolve.TestSplu.test_spilu_smoketest ... ok > test_linsolve.TestSplu.test_splu_basic ... ok > test_linsolve.TestSplu.test_splu_nnz0 ... ok > test_linsolve.TestSplu.test_splu_perm ... Segmentation fault > > > Hannes > > > > > > > > On Fri, 2010-04-30 at 08:26 +0000, Pauli Virtanen wrote: > >> scipy.test(verbose=2) >> > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev > Hi, I am also seeing this on Linux python 2.6 64-bit. In the tests/test_linsolve.py, what should be: lu.perm_r and lu.perm_c? Where is the splu() of a csc_matrix? lu = splu(a_) the type is But I get a segmentation fault (given below) if I try to print one of them. The nnz and shape print okay. I get the same crash if I do: print getattr(lu,'perm_r') Bruce >>> import numpy.random as random >>> from numpy.testing import * >>> >>> from scipy.linalg import norm, inv >>> from scipy.sparse import spdiags, SparseEfficiencyWarning, csc_matrix >>> from scipy.sparse.linalg.dsolve import spsolve, use_solver, splu, spilu >>> n = 30 >>> a = random.random((n, n)) >>> a[a < 0.95] = 0 >>> a += 4*eye(n) >>> a_ = csc_matrix(a) >>> lu = splu(a_) >>> print lu.shape (30, 30) >>> type(lu.perm_c) >>> print lu.perm_c Program received signal SIGSEGV, Segmentation fault. 0x000000306a286b85 in memcpy () from /lib64/libc.so.6 (gdb) bt #0 0x000000306a286b85 in memcpy () from /lib64/libc.so.6 #1 0x00007ffff1cf66bd in PyArray_Concatenate (op=0x0, axis=) at /usr/include/bits/string3.h:52 #2 0x00007ffff1cf67d2 in array_concatenate (__NPY_UNUSED_TAGGEDdummy=, args=, kwds=) at numpy/core/src/multiarray/multiarraymodule.c:1811 #3 0x00000030808dd9dc in PyEval_EvalFrameEx () from /usr/lib64/libpython2.6.so.1.0 #4 0x00000030808de204 in PyEval_EvalFrameEx () from /usr/lib64/libpython2.6.so.1.0 #5 0x00000030808df3dd in PyEval_EvalCodeEx () from /usr/lib64/libpython2.6.so.1.0 #6 0x00000030808dd78c in PyEval_EvalFrameEx () from /usr/lib64/libpython2.6.so.1.0 #7 0x00000030808df3dd in PyEval_EvalCodeEx () from /usr/lib64/libpython2.6.so.1.0 #8 0x00000030808dd78c in PyEval_EvalFrameEx () from /usr/lib64/libpython2.6.so.1.0 #9 0x00000030808df3dd in PyEval_EvalCodeEx () from /usr/lib64/libpython2.6.so.1.0 #10 0x000000308086dfef in ?? () from /usr/lib64/libpython2.6.so.1.0 #11 0x0000003080843e93 in PyObject_Call () from /usr/lib64/libpython2.6.so.1.0 #12 0x00000030808d7a03 in PyEval_CallObjectWithKeywords () from /usr/lib64/libpython2.6.so.1.0 #13 0x00007ffff1cba234 in array_str (self=) at numpy/core/src/multiarray/arrayobject.c:393 #14 0x000000308088489b in _PyObject_Str () from /usr/lib64/libpython2.6.so.1.0 #15 0x000000308088498a in PyObject_Str () from /usr/lib64/libpython2.6.so.1.0 #16 0x0000003080884b22 in ?? () from /usr/lib64/libpython2.6.so.1.0 #17 0x0000003080867278 in PyFile_WriteObject () from /usr/lib64/libpython2.6.so.1.0 #18 0x00000030808dbe6b in PyEval_EvalFrameEx () from /usr/lib64/libpython2.6.so.1.0 #19 0x00000030808df3dd in PyEval_EvalCodeEx () from /usr/lib64/libpython2.6.so.1.0 #20 0x00000030808df4b2 in PyEval_EvalCode () from /usr/lib64/libpython2.6.so.1.0 #21 0x00000030808fa55c in ?? () from /usr/lib64/libpython2.6.so.1.0 #22 0x00000030808fbefe in PyRun_InteractiveOneFlags () from /usr/lib64/libpython2.6.so.1.0 #23 0x00000030808fc0fe in PyRun_InteractiveLoopFlags () from /usr/lib64/libpython2.6.so.1.0 #24 0x00000030808fc20c in PyRun_AnyFileExFlags () from /usr/lib64/libpython2.6.so.1.0 #25 0x000000308090833d in Py_Main () from /usr/lib64/libpython2.6.so.1.0 #26 0x000000306a21ed2d in __libc_start_main () from /lib64/libc.so.6 #27 0x0000000000400649 in _start () (gdb) From pav at iki.fi Fri Apr 30 10:26:39 2010 From: pav at iki.fi (Pauli Virtanen) Date: Fri, 30 Apr 2010 14:26:39 +0000 (UTC) Subject: [SciPy-Dev] scipy.test bails with segmentation error References: <1272609819.29912.50.camel@hirubu> <1272630040.10687.1.camel@hirubu> <4BDAE7D6.7010605@gmail.com> Message-ID: Fri, 30 Apr 2010 09:23:18 -0500, Bruce Southey wrote: [clip] > I am also seeing this on Linux python 2.6 64-bit. Sounds like 32 vs 64-bits integer size issue then (I have 32). I'll have to check that the data types match what SuperLU gives out. Pauli From doutriaux1 at llnl.gov Fri Apr 30 12:10:08 2010 From: doutriaux1 at llnl.gov (=?UTF-8?Q?Charles_=D8=B3=D9=85=D9=8A=D8=B1_Doutriaux?=) Date: Fri, 30 Apr 2010 09:10:08 -0700 Subject: [SciPy-Dev] numpy 1.4.1 f2py on Snow Leopard. In-Reply-To: <02693440-C4EB-496D-BB04-005B95A8EB92@nist.gov> References: <02693440-C4EB-496D-BB04-005B95A8EB92@nist.gov> Message-ID: <5215080B-91A3-4E71-A075-B4DF828E5D29@llnl.gov> Ok, It seems to be totally unrelated. Even using your suggested gfortran. On a 32bit machine. I still get the same error. Since scipy is HUGE I'm sending a REALLY simple example that fails for me. omar /git/cdat >gfortran --version GNU Fortran (GCC) 4.2.3 Copyright (C) 2007 Free Software Foundation, Inc. GNU Fortran comes with NO WARRANTY, to the extent permitted by law. You may redistribute copies of GNU Fortran under the terms of the GNU General Public License. For more information about these matters, see the file named COPYING omar /git/cdat >gcc --version i686-apple-darwin9-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5574) Copyright (C) 2007 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. omar /git/cdat >uname -a Darwin omar 9.8.0 Darwin Kernel Version 9.8.0: Wed Jul 15 16:55:01 PDT 2009; root:xnu-1228.15.4~1/RELEASE_I386 i386 -------------- next part -------------- A non-text attachment was scrubbed... Name: ort.LOG Type: application/octet-stream Size: 19469 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: setup.py Type: text/x-python-script Size: 927 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: reado.f Type: application/octet-stream Size: 5263 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ortreader.pyf Type: application/octet-stream Size: 649 bytes Desc: not available URL: -------------- next part -------------- On Apr 29, 2010, at 4:52 PM, Jonathan Guyer wrote: > On Apr 29, 2010, at 12:17 PM, Charles ???? Doutriaux wrote: > >> I jsut built numpy 1.4.1 on my mac (64bit only no universal) >> Now f2py fails building any fortran code... > > >> meryem /svn/cdat/trunk >gfortran --version >> GNU Fortran (GCC) 4.5.0 20100107 (experimental) >> Copyright (C) 2009 Free Software Foundation, Inc. > > I've recently been writing up instructions for building FiPy's > prerequisites on Snow Leopard http://*matforge.org/fipy/wiki/ > SnowLeopardSourceBuild, largely based on this blog posting: http:// > *blog.hyperjeff.net/?p=160 > > There seem to be issues with gfortran 4.5.0, whereas gfortran 4.2.3 > has worked for me and others. > > > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://*mail.scipy.org/mailman/listinfo/scipy-dev From pav at iki.fi Fri Apr 30 12:38:59 2010 From: pav at iki.fi (Pauli Virtanen) Date: Fri, 30 Apr 2010 16:38:59 +0000 (UTC) Subject: [SciPy-Dev] scipy.test bails with segmentation error References: <1272609819.29912.50.camel@hirubu> <1272630040.10687.1.camel@hirubu> <4BDAE7D6.7010605@gmail.com> Message-ID: Fri, 30 Apr 2010 14:26:39 +0000, Pauli Virtanen wrote: > Fri, 30 Apr 2010 09:23:18 -0500, Bruce Southey wrote: [clip] >> I am also seeing this on Linux python 2.6 64-bit. > > Sounds like 32 vs 64-bits integer size issue then (I have 32). I'll have > to check that the data types match what SuperLU gives out. Should be fixed in r6364. Pauli From bsouthey at gmail.com Fri Apr 30 12:46:26 2010 From: bsouthey at gmail.com (Bruce Southey) Date: Fri, 30 Apr 2010 11:46:26 -0500 Subject: [SciPy-Dev] scipy.test bails with segmentation error In-Reply-To: References: <1272609819.29912.50.camel@hirubu> <1272630040.10687.1.camel@hirubu> <4BDAE7D6.7010605@gmail.com> Message-ID: <4BDB0962.9070107@gmail.com> On 04/30/2010 11:38 AM, Pauli Virtanen wrote: > Fri, 30 Apr 2010 14:26:39 +0000, Pauli Virtanen wrote: > >> Fri, 30 Apr 2010 09:23:18 -0500, Bruce Southey wrote: [clip] >> >>> I am also seeing this on Linux python 2.6 64-bit. >>> >> Sounds like 32 vs 64-bits integer size issue then (I have 32). I'll have >> to check that the data types match what SuperLU gives out. >> > Should be fixed in r6364. > > Pauli > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev > Excellent, That test passes for me. Bruce From cgohlke at uci.edu Fri Apr 30 14:29:03 2010 From: cgohlke at uci.edu (Christoph Gohlke) Date: Fri, 30 Apr 2010 11:29:03 -0700 Subject: [SciPy-Dev] Failure to build superlumodule using scons, rev 6364 Message-ID: <4BDB216F.9000001@uci.edu> Dear Scipy developers, scipy svn trunk rev 6364, specifically the superlumodule extension, fails to build for me on Windows/Python2.6.5/numpy1.4.1/numscons-0.12.0dev/msvc9/ifort11.1/mkl using the setupscons script: python setupscons.py scons -b --fcompiler=ifort --compiler=msvc bdist_wininst --user-access-control=auto scons: *** [build\scons\scipy\sparse\linalg\dsolve\_csuperlumodule.obj] Source `build\scons\scipy\sparse\linalg\dsolve\_csuperlumodule.c' not found, needed by target `build\scons\scipy\sparse\linalg\dsolve\_csuperlumodule.obj'. scons: building terminated because of errors. Thank you, Christoph