Mailman 3 September 2001 - SciPy-User

sfftw problem during build
by John Hunter 24 Sep '01

24 Sep '01

I am trying to install SciPy-0.1 from source on an i386 linux distro with python 2.1. I installed fftw per the instructions with : # configure --enable-i386-hacks --enable-threads # make install # make clean # configure --enable-threads --enable-float --enable-i386-hacks # make install and have the following in /usr/local/lib: /usr/local/lib/libfftw.la /usr/local/lib/librfftw.la /usr/local/lib/libfftw_threads.a /usr/local/lib/librfftw_threads.a /usr/local/lib/libfftw_threads.la /usr/local/lib/librfftw_threads.la During the build process for SciPy, I get a compiler error looking for -lsfftw_threads. I am assuming the sfft libs are the SWIG wrappers for the fftw libs. But in any case, I have no libsfft* anwhere on my system, and can't find anyway to build them Suggestions? Here is the command that bombed during the make and the compiler (gcc-2.95.2) output: gcc -shared build/temp.linux-i686-2.1/sfftw_wrap.o -L/root/lib -L/usr/local/lib/ gcc-lib/i686-pc-linux-gnu/2.95.2/specs -L/usr/local/lib/gcc-lib/i686-pc-linux-gn u/2.95.2/specs -Lbuild/temp.linux-i686-2.1 -Lbuild/temp.linux-i686-2.1 -lsfftw_t hreads -lsrfftw_threads -lsfftw -lsrfftw -lpthread -lamos -ltoms -lfitpack -lmin pack -lquadpack -lodepack -llinpack_lite -lblas -lmach -lg2c -lgist -lc_misc -lc ephes -o build/lib.linux-i686-2.1/scipy/fft/sfftw.so /usr/bin/ld: cannot open -lsfftw_threads: No such file or directory collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1

3 3

SciPy build problem SWIG?
by Hartley, Ed 21 Sep '01

21 Sep '01

Hi I'm trying to build SciPy on Red Hat Linux 7.1 with Python 2.1 I have built and installed fftw and the threading extension. The SciPy build fails at the point it's trying to build scipy.fft.sfftw extension when linking fft/sfftw.so I believe these are dependent on SWIG if so is there a restriction on the SWIG revision? Regards Ed Hartley Distributed Multimedia Research Group Computing Department Lancaster University Lancaster UK LA1 4YR Phone +44 (0) 1524 593675 Fax +44 (0) 1524 593608

3 2

Documentation.
by H Jansen 19 Sep '01

19 Sep '01

>From where can the html documentation be downloaded as a chunk (i.e. tar or zip-ball)? Thanks, Henk

1 0

Re: PEP proposal for round(x,n) enhancement
by Christopher Smith 15 Sep '01

15 Sep '01

To Chris and others interested, Would you mind giving me an opinion here? I think you made the best argument for not using the name "round" since floating n is already accepted by round and changing how n is interpreted would break anyone's code who passed in n with a non-zero decimal portion. Sigfig or chop is an alternative but I really don't like the name "chop" since it's not descriptive of the rounding that takes place. Sigfig is ok, but I am proposing a round function (below) that offers more than just sigfigs. So...how about "round2" which has precedence in the atan2() function. The two sorts of roundings that can be done with round2() are 1) rounding to a specified number of significant figures or 2) rounding to the nearest "x". The latter is useful if you are making a histogram, for example, where experimental data values may all be distinct but when the deviation of values is considered it makes sense to round the observations to a specified uncertainty, e.g. if two values differ by less than sigma then they could be considered to be part of the same "bin". The script is below. Thanks for any input, /c #### from math import floor,log10 def round2(x,n=0,sigs4n=1): '''Return x rounded to the specified number of significant digits, n, as counted from the first non-zero digit. If n=0 (the default value for round2) then the magnitude of the number will be returned (e.g. round2(12) returns 10.0). If n<0 then x will be rounded to the nearest multiple of n which, by default, will be rounded to 1 digit (e.g. round2(1.23,-.28) will round 1.23 to the nearest multiple of 0.3. Regardless of n, if x=0, 0 will be returned.''' if x==0: return x if n<0: n=round2(-n,sigs4n) return n*int(x/n+.5) if n==0: return 10.**(int(floor(log10(abs(x))))) return round(x,int(n)-1-int(floor(log10(abs(x))))) ####

1 0

A proposal for a round(x,n) enhancement
by Christopher Smith 15 Sep '01

15 Sep '01

Hello, I would like to see an addition to the round(x,n) function syntax that would allow one to specify that x should be rounded to the nth significant digit as opposed to the nth digit to the left or right of the 1's digit. I am testing the waters right now on python-list and have not yet submitted a PEP. Some there have suggested that it be called a different function. Someone else has suggested that perhaps it could be added into SciPy or Numeric as a function there. I prefer the name round because it describes what you are doing. Someone suggested that MATLAB has a function called chop that does what I am proposing and at http://www.math.colostate.edu/~tavener/M561/lab5/lab5.pdf the document says that the "MATLAB function chop(x,n) rounds (not chops!) the number x to n significant digits." If this new function was called "chop" then any previous MATLAB users would know what to expect. (But why call it chop if you are actually rounding?) What I think would be nice is to modify round so it can round to a given number of sig. figs. Here is a def called Round that simulates what I am proposing: from math import floor,log10 def Round(x,n=0): if n%1: d=int(10*n) return round(x,d-1-int(floor(log10(abs(x))))) else: return round(x,n) print Round(1.23456,2) #returns 1.23 print Round(1.23456,0.2) #returns 1.2 The way that I have enhanced round's syntax is to have it check to see if there is a non-zero decimal part to n. If there is, n is multiplied by 10 and the resulting value is used to compute which digit to round x to. n=0.1 will round to the first significant digit while n=0.4 and n=1.1 will round to the 4th and 11th, respectively. I don't believe you will run into any numerical issues since even though something like .3 may be represented internally as 0.29999999999999999, multiplying it by 10 gets you back to 3 and this value is what is used in the call to round() I am open to comments about implementation and function name. /c

2 1

SciPy on FreeBSD
by Rob 15 Sep '01

15 Sep '01

I'm trying to modify setup.py to compile on FreeBSD. It can't seem to find various /usr/X11R6/include files, even though I modified the file to show the right locations. If I figure this out, I'll mail it to the list. I am very eager to try this package out on some EM simulators. Rob. -- The Numeric Python EM Project www.members.home.net/europax

2 2

unexpected behavior in odeint
by Chris Myers 07 Sep '01

07 Sep '01

I have a question about the intended behavior of the scipy.integrate.odeint function. The documented process for constructing an ODE solution using the odeint() function is to pass a sequence (NumPy array) of times t at which a solution y(t) is desired. Looking into the underlying lsoda subroutine, and the __odepack.h wrapper, however, I see that this multiple time-step interface is provided in the Python wrapper; that is, lsoda would appear to be constructed to execute a single time step (over and over again), and the multiple time stepping is a convenience provided in the Python overlayer. The problem I am having is that lsoda does not take a time step exactly as requested, but instead takes a step to ensure that the current time is at least as large as the requested time value. As a result, in the process of feeding an array of requested time points, lsoda can "outrun" the driver and produce multiple steps with the same value of the time tcur. For example, I may request a solution at times t=arange(0., 10., 0.1). odeint guarantees that each step will be at least as large as the requested time, but in some cases it would appear that the current time actually already exceeds the requested time. In a particular example of mine, I find: t = t_requested[65:68] = array([ 6.5, 6.6, 6.7]) tcur = t_actual[65:68] = array([ 6.56972519, 6.70778359, 6.70778359]) What we see is that on step 66, odeint has incremented itself to a time which exceeds the requested value for step 67, so that it does not step to a larger time during step 67. odeint does, however, return a different function value at steps 66 and 67, so that the result function y(t) is multivalued for some t (which is not especially appealing to me). Am I misusing this multiple time-step feature of odeint? Is the behavior that I have describe intended? Should I be exercising caution in the construction of time-sequences to pass to odeint? An alternate strategy would be to take the current time returned by lsoda, and set the next requested time based on that (but in such a case, one might get fewer time slices than originally requested). Any insight here would be appreciated. Chris ========================================================================== Chris Myers Cornell Theory Center -------------------------------------------------------------------------- 636 Rhodes Hall email: myers(a)tc.cornell.edu Cornell University phone: (607) 255-5894 / fax: (607) 254-8888 Ithaca, NY 14853 http://www.tc.cornell.edu/~myers -------------------------------------------------------------------------- "To thine own self be blue." - Polonious Funk ==========================================================================

2 2

problems with plt on Win2K
by M Russo 04 Sep '01

04 Sep '01

Hello: I installed SciPy on my Win2K box. I've tested a few functions that seem to work well. But, the wxPython version of plt won't run. Here is what I get... C:\Python21\SciPy\plt>python wxplt.py Traceback (most recent call last): File "wxplt.py", line 7, in ? from plot_utility import * File "plot_utility.py", line 38, in ? import scipy.limits, scipy.misc SystemError: NULL result without error in call_object C:\Python21\SciPy\plt> This works fine on my Win98 box. Any thoughts? Thanks. Mark _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

1 0