Mailman 3 August 2004 - SciPy-User

ADF tests for time series econometrics
by Alan G Isaac Aug. 11, 2004

Aug. 11, 2004

I've posted simple ADF test code at http://www.american.edu/econ/pytrix/unitroot.py Cheers, Alan Isaac

1 0

Problems building SciPy-0.3 on OS X
by Tom Loredo Aug. 11, 2004

Aug. 11, 2004

> Try using the old re module in check_re.py. For that replace > > import re > > with > > import pre as re > > in check_re.py. What happens? That works! I didn't even know the pre module existed (it's not in the lib docs). So far only two people on pymac-sig have tried the script; it works for them but none of them are using 2.3.3 on 10.2.8. One is using 2.3.4, so I'll try updating to that. I have to build it from source so it'll have to wait till I can transfer the source archive from my linux box (with a broadband connection). Pearu, thanks for your help with this! -Tom

1 0

Weave problems
by Bob.Cowdery＠CGI-Europe.com Aug. 11, 2004

Aug. 11, 2004

Hi all, I have a serious problem with Weave. I raised it before - the last time I put some in-line code in but managed to work round it by compiling outside the main application. I have now put some more in-line code in and I am back to the same problem and can't seem to shake it off this time. When I try to run my application two things happen. I get a stream of exceptions - Exception exceptions.RuntimeError: 'maximum recursion depth exceeded' in <bound method module.__del__ of <win32 module '__eq__' (0 functions)>> ignored and then have to terminate my application with task manager. Having done that I am left with wgnuplot.exe and gnuplot_helper.exe between them taking 100% CPU and I have to kill those off as well. I don't use either of those programs, so where on earth are they coming from. I don't even know where to start looking for this one and would really appreciate some help. Thanks Bob Bob Cowdery CGI Senior Technical Architect +44(0)1438 791517 Mobile: +44(0)7771 532138 bob.cowdery(a)cgi-europe.com <mailto:bob.cowdery@cgi-europe.com> *** Confidentiality Notice *** Proprietary/Confidential Information belonging to CGI Group Inc. and its affiliates may be contained in this message. If you are not a recipient indicated or intended in this message (or responsible for delivery of this message to such person), or you think for any reason that this message may have been addressed to you in error, you may not use or copy or deliver this message to anyone else. In such case, you should destroy this message and are asked to notify the sender by reply email.

2 1

Problems building SciPy-0.3 on OS X
by Tom Loredo Aug. 11, 2004

Aug. 11, 2004

> Also try saving "interface" string to a file, then from a fresh Python > session load the string, and apply subroutine_exp.findall to it. Will > Python crash also then? Thanks for the suggestion. Here is the interface string, and a Python script that does the check: http://www.museweb.com/interface.txt http://www.museweb.com/check_re.py Running the script with MacPy 2.3.3 on 10.2.8 gives a segfault. Running it with /usr/bin/python works fine. I've also tried it on a Sun machine with python2.2.2 and a linux machine with 2.3.3 and it works fine on those, too. It appears this is a MacPy 2.3.3 bug (presumably in the re module). I will copy this info to Pythonmac-Sig in the hopes that Jack or someone else there can help. I posted the original problem there with no response yet. If anyone out there is running Jaguar, I'd appreciate it if you'd download the script and text and run it, and let us know if you get a segfault. Thanks, Tom

2 1

Problems building SciPy-0.3 on OS X
by Tom Loredo Aug. 10, 2004

Aug. 10, 2004

Hi Pearu- Thanks for the help. > Hmm, the segfault appears while executing pure Python code. Yes. By the admittedly crude approach of inserting lots of print statements, I've determined that it happens in "all_subroutines" in Lib/linalg/interface_gen.py: def all_subroutines(interface_in): # remove comments comment_block_exp = re.compile(r'/\*(?:\s|.)*?\*/') subroutine_exp = re.compile(r'subroutine (?:\s|.)*?end subroutine.*') function_exp = re.compile(r'function (?:\s|.)*?end function.*') print '***** Compiled regexps...' print '***** stripping comments...' interface = comment_block_exp.sub('',interface_in) print '***** finding subrs...' print interface subroutine_list = subroutine_exp.findall(interface) print '***** finding functions...' function_list = function_exp.findall(interface) print '***** concatenating...' subroutine_list = subroutine_list + function_list print '***** stripping...' subroutine_list = map(lambda x: string.strip(x),subroutine_list) return subroutine_list The fault occurs while finding the subroutines via "subroutine_exp.findall(interface)". I've printed out "interface" (too long to post here) and there is nothing obvious wrong with it, but I don't really know what to expect. In years of using Python, this is the first segfault I've seen running a builtin or library module! > Also, I'd suggest using CVS version of scipy Yes, I was afraid you'd suggest this. I'm developing a public package, and a frequent comment from potential users is that they don't want to have to deal with CVS---they would ideally just want an RPM, though I think they'll live with a setup.py. The CVS barrier is admittedly small in scipy's case, but every barrier cuts off another layer of possible users. The latest "official" build really should build on all the major platforms. My own obstacle is that at work I'm on a linux machine; the Mac is at home on a dialup connection. So CVS stuff is slow. But in this case I copied the linux machine's scipy directory via a flash drive to the Mac, and then did a CVS to update it (thus avoiding checking out the whole thing via my modem). The exact same errors happen using today's version on CVS. > I would disable building xplt for now. To do that, add 'xplt' to the > ignore_packages list at the end of setup.py file. And then try 'python > setup.py build' again. I tried that with the CVS version. No go, same problem: building extension "scipy.linalg.cblas" sources adding 'build/src/scipy/linalg/cblas.pyf' to sources. adding 'build/src/fortranobject.c' to sources. adding 'build/src' to include_dirs. building extension "scipy.linalg.flapack" sources generating flapack interface Segmentation fault I've again inserted print statements and verified that the segfault is happening in the same place (using the subroutine_exp regexp). This regexp works fine on earlier modules. Is the earlier error (AttributeError: 'NoneType' object has no attribute 'rfind') perhaps a clue I'm overlooking (i.e., something is not getting set up on that first build attempt, and is getting overlooked on the 2nd attempt)? Help! -Tom

3 2

Problems building SciPy-0.3 on OS X
by Tom Loredo Aug. 10, 2004

Aug. 10, 2004

Hi folks- I'm trying to build SciPy-0.3 on a G4 (and on a G3 laptop) running 10.2.8 and MacPy 2.3.3, but with no luck---the build halts with a segfault. I've followed Chris's instructions on the scipy web site, with the exception of not installing Gnuplot & AquaTerm. The one possible complication is that I have some fink stuff installed (not python, though), including f77, but I've renamed it f77-fink, and verified that there is no f77 in my path (the g77 install doesn't install one, so I was worried scipy or f2py might find Fink's f77 rather than using g77). On every first install attempt, I get an error compiling _configtest.c, from code in the included file fputest.c. If I merely restart the build after the error, the build proceeds through this part successfully, but perhaps this is an important symptom. Here's the output from the first build attempt: compiling '_configtest.c': #define FPU_DIGITAL #define CONFIG_SCRIPT #include "fputest.c" gcc options: '-fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd -fno-common -dynamic -DNDEBUG -g -O3 -Wall -Wstrict-prototypes' compile options: '-I/Users/loredo/Python/SciPy_complete-0.3/build/temp.darwin-6.8-Power_Macintosh-2.3/config_pygist -I/Users/loredo/Python/SciPy_complete-0.3/Lib/xplt/src/play -c' gcc: _configtest.c In file included from fputest.c:10, from _configtest.c:3: fpuset.c:27:27: machine/fpu.h: No such file or directory In file included from fputest.c:10, from _configtest.c:3: fpuset.c: In function `u_fpu_setup': fpuset.c:45: warning: implicit declaration of function `ieee_set_fp_control' fpuset.c:45: `IEEE_TRAP_ENABLE_INV' undeclared (first use in this function) fpuset.c:45: (Each undeclared identifier is reported only once fpuset.c:45: for each function it appears in.) fpuset.c:45: `IEEE_TRAP_ENABLE_DZE' undeclared (first use in this function) fpuset.c:46: `IEEE_TRAP_ENABLE_OVF' undeclared (first use in this function) [snip many lines] removing: _configtest.c _configtest.o compiling '_configtest.c': #define FPU_SUN4 #define CONFIG_SCRIPT #include "fputest.c" gcc options: '-fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd -fno-common -dynamic -DNDEBUG -g -O3 -Wall -Wstrict-prototypes' compile options: '-I/Users/loredo/Python/SciPy_complete-0.3/build/temp.darwin-6.8-Power_Macintosh-2.3/config_pygist -I/Users/loredo/Python/SciPy_complete-0.3/Lib/xplt/src/play -c' gcc: _configtest.c In file included from fputest.c:10, from _configtest.c:3: fpuset.c: In function `u_fpu_setup': fpuset.c:133: warning: implicit declaration of function `nonstandard_arithmetic' fpuset.c:134: warning: implicit declaration of function `ieee_handler' Traceback (most recent call last): File "setup.py", line 110, in ? setup_package(ignore_packages) File "setup.py", line 83, in setup_package ignore_packages = ignore_packages) File "scipy_core/scipy_distutils/misc_util.py", line 459, in get_subpackages config = setup_module.configuration(*args) File "/Users/loredo/Python/SciPy_complete-0.3/Lib/xplt/setup_xplt.py", line 210, in configuration conf.run() File "/Users/loredo/Python/SciPy_complete-0.3/Lib/xplt/config_pygist.py", line 64, in run self.config_unix() File "/Users/loredo/Python/SciPy_complete-0.3/Lib/xplt/config_pygist.py", line 193, in config_unix self.find_sigfpe(configfile) File "/Users/loredo/Python/SciPy_complete-0.3/Lib/xplt/config_pygist.py", line 311, in find_sigfpe include_dirs=self.unix_include_dirs): File "/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/distutils/command/config.py", line 260, in try_link libraries, library_dirs, lang) File "/Users/loredo/Python/SciPy_complete-0.3/Lib/xplt/config_pygist.py", line 28, in _link library_dirs=library_dirs) File "/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/distutils/ccompiler.py", line 860, in link_executable debug, extra_preargs, extra_postargs, None, target_lang) File "/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/distutils/unixccompiler.py", line 153, in link libraries) File "/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/distutils/ccompiler.py", line 1249, in gen_lib_options (lib_dir, lib_name) = os.path.split (lib) File "/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/posixpath.py", line 77, in split i = p.rfind('/') + 1 AttributeError: 'NoneType' object has no attribute 'rfind' As I said, merely running "python setup.py build" again continues the build without complaint, starting: fftw_info: FOUND: libraries = ['rfftw', 'fftw'] library_dirs = ['/usr/local/lib'] define_macros = [('SCIPY_FFTW_H', None)] include_dirs = ['/usr/local/include'] etc.. But it eventually halts with a segfault working on cblas: f2py: build/src/cblas.pyf Reading fortran codes... Reading file 'build/src/cblas.pyf' Post-processing... Block: cblas Block: empty_module Building modules... Building module "cblas"... Constructing wrapper function "empty_module"... empty_module() Wrote C/API module "cblas" to file "build/src/build/src/cblasmodule.c" adding 'build/src/fortranobject.c' to sources. adding 'build/src' to include_dirs. building extension "scipy.linalg.flapack" sources generating flapack interface Segmentation fault Any help anyone can offer on how to diagnose this would be appreciated. Thanks, Tom

2 1

scipy crashing on
by David Grant Aug. 9, 2004

Aug. 9, 2004

Has there been any progress made on fixing the following bugs? Which are all basically dupes as far as I can tell: http://www.scipy.net/roundup/scipy/issue178 http://www.scipy.net/roundup/scipy/issue163 http://www.scipy.net/roundup/scipy/issue138 I'm really desperate for any workaround...or any possible reasons (specific to my system) which may be the culprit. Thanks, David

2 1

pyPlot.py vs. Gnuplot.py
by Alan G Isaac Aug. 6, 2004

Aug. 6, 2004

As a new SciPy user, I am interested in understanding the relationship between the scipy.gplt module and the Gnuplot.py project. What considerations influence which was chosen, and which a new user should choose? This is especially important to me as I am planning to use one of these in a teaching setting. Thank you, Alan Isaac

3 2

pyGAUSS
by Alan G Isaac Aug. 6, 2004

Aug. 6, 2004

Those familiar with the GAUSS programming language may find this useful. (Requires SciPy.) http://www.american.edu/econ/pytrix/pyGAUSS.py It's just a few of my most often used GAUSS commands at this point, but I plan to add to the list. Not that sumc, cumsumc, prodc, and cumprodc always have axis=0. (So those reading this list can guess why I wrote them ;). Comments and contributions welcome. fwiw, Alan Isaac

1 0

scipy choice of defaults for matrix manipulation
by Alan G Isaac Aug. 6, 2004

Aug. 6, 2004

The SciPy documentation says: To begin with, all of the Numeric functions have been subsumed into the scipy namespace so that all of those functions are available without additionally importing Numeric. It was therefore unsettling to find that SciPy's function_base defines def cumsum(m,axis=-1): """Returns the cumulative sum of the elements along the given axis """ if axis is None: m = ravel(m) axis = 0 else: m = _asarray1d(m) return add.accumulate(m,axis) This changes the default axis of Numeric and numarray. Bug or feature?? Example: >>> x=[[1,2],[3,4]] >>> from scipy import * >>> print cumsum(x) [[1,3] [3,7]] >>> print Numeric.cumsum(x) [[1,2] [4,6]] I believe this should be considered a serious bug, either in implementation or documentation. Since SciPy is likely to be attracting Numeric and numarray users, I believe it should be considered an implementation bug. Naturally cumprod has the same problem. (I did not try to review the whole list, so there may be others.) There is even a certain schizophrenia: sum and prod choose different axes! It is clear that this has been thought about at some point, since SciPy's sum definition includes a note suggesting that the axis might change in the future (to *conflict* with the choice in Numeric and numarray!!). This is likely to generate great user confusion. It cost me some time. Thank you, Alan Isaac

3 5