From europax at home.com Sun Sep 2 16:44:45 2001 From: europax at home.com (Rob) Date: Sun, 02 Sep 2001 13:44:45 -0700 Subject: [SciPy-user] SciPy on FreeBSD Message-ID: <3B929A3D.987E1966@home.com> 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 From russomf at hotmail.com Mon Sep 3 23:07:30 2001 From: russomf at hotmail.com (M Russo) Date: Mon, 03 Sep 2001 23:07:30 -0400 Subject: [SciPy-user] problems with plt on Win2K Message-ID: 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 From myers at tc.cornell.edu Fri Sep 7 15:25:17 2001 From: myers at tc.cornell.edu (Chris Myers) Date: Fri, 7 Sep 2001 15:25:17 -0400 Subject: [SciPy-user] unexpected behavior in odeint Message-ID: <20010907152517.A14585@sowhat.tc.cornell.edu> 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 at 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 ========================================================================== From oliphant at ee.byu.edu Fri Sep 7 16:17:42 2001 From: oliphant at ee.byu.edu (Travis Oliphant) Date: Fri, 7 Sep 2001 14:17:42 -0600 (MDT) Subject: [SciPy-user] unexpected behavior in odeint In-Reply-To: <20010907152517.A14585@sowhat.tc.cornell.edu> Message-ID: > > 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. > This is true.... > 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). The problem that is happening is that I did not copy the array t before passing it to the _odepack.odeint C-interface. This interface hands the array t to the lsoda routine which causes your t array to be overwritten with possible overshot values for t0. My understanding, though is that lsoda uses interpolation to give the output value at the requested time. So, I think your y output vector corresponds to the correct values but your t vector may have been overwritten. What does t_original compared to the ouput look like? > > 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). I had not intended for the t vector to be overwritten (i don't think it is a problem all the time -- but you've uncovered a case). Is it possible for you to send an example fprime function, intial conditions and time-points so I could try to replicate this behavior. Thanks, -Travis From oliphant at ee.byu.edu Fri Sep 7 16:17:42 2001 From: oliphant at ee.byu.edu (Travis Oliphant) Date: Fri, 7 Sep 2001 14:17:42 -0600 (MDT) Subject: [SciPy-user] unexpected behavior in odeint In-Reply-To: <20010907152517.A14585@sowhat.tc.cornell.edu> Message-ID: > > 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. > This is true.... > 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). The problem that is happening is that I did not copy the array t before passing it to the _odepack.odeint C-interface. This interface hands the array t to the lsoda routine which causes your t array to be overwritten with possible overshot values for t0. My understanding, though is that lsoda uses interpolation to give the output value at the requested time. So, I think your y output vector corresponds to the correct values but your t vector may have been overwritten. What does t_original compared to the ouput look like? > > 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). I had not intended for the t vector to be overwritten (i don't think it is a problem all the time -- but you've uncovered a case). Is it possible for you to send an example fprime function, intial conditions and time-points so I could try to replicate this behavior. Thanks, -Travis From myers at tc.cornell.edu Fri Sep 7 16:37:43 2001 From: myers at tc.cornell.edu (Chris Myers) Date: Fri, 7 Sep 2001 16:37:43 -0400 Subject: [SciPy-user] unexpected behavior in odeint In-Reply-To: ; from oliphant@ee.byu.edu on Fri, Sep 07, 2001 at 02:17:42PM -0600 References: <20010907152517.A14585@sowhat.tc.cornell.edu> Message-ID: <20010907163743.A14698@sowhat.tc.cornell.edu> Travis, Included below is a very simple example demonstrating the problem I reported (although this is a different example than the specific one I described in my earlier email). The problem is actually more prevalent in this example. As an aside, it would be useful if the 'tcur' array returned in the infodict had the initial time value at the start of the array; as it is now, the array starts with the first successful time step, and therefore the length of the solution array is one longer than the tcur array (making it more awkward, e.g., to plot y(t) vs. t). Thanks, Chris # ------------------------------------------------------------------------- import Numeric from scipy.integrate import odeint y0 = 1. def f(y,t): return Numeric.exp(-0.01*y*t) t = Numeric.arange(0, 3.0, 0.1) y, yinfo = odeint(f, y0, t, full_output=1) # ------------------------------------------------------------------------- For this example, I find: yinfo['tcur'] = array([ 0.11397125, 0.20087814, 0.54850571, 0.54850571, 0.54850571, 0.83819534, 0.83819534, 0.83819534, 1.12788498, 1.12788498, 1.12788498, 1.41757461, 1.41757461, 1.41757461, 1.70726425, 1.70726425, 1.70726425, 1.99695389, 1.99695389, 2.38792355, 2.38792355, 2.38792355, 2.38792355, 2.77889321, 2.77889321, 2.77889321, 2.77889321, 3.16986287, 3.16986287]) y = array([[ 1. ], [ 1.09994666], [ 1.1997735 ], [ 1.29946076], [ 1.39898883], [ 1.49833825], [ 1.5974897 ], [ 1.69642407], [ 1.79512247], [ 1.89356621], [ 1.99173682], [ 2.08961611], [ 2.18718616], [ 2.28442932], [ 2.38132824], [ 2.47786589], [ 2.57402557], [ 2.66979092], [ 2.76514591], [ 2.8600749 ], [ 2.95456261], [ 3.04859415], [ 3.14215499], [ 3.23523105], [ 3.32780862], [ 3.41987444], [ 3.51141562], [ 3.60241973], [ 3.69287475], [ 3.7827691 ]]) On Fri, Sep 07, 2001 at 02:17:42PM -0600, Travis Oliphant wrote: > > > > > 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. > > > > This is true.... > > > 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). > > The problem that is happening is that I did not copy the array t before > passing it to the _odepack.odeint C-interface. This interface hands the > array t to the lsoda routine which causes your t array to be overwritten > with possible overshot values for t0. > > My understanding, though is that lsoda uses interpolation to give the > output value at the requested time. > > So, I think your y output vector corresponds to the correct values but > your t vector may have been overwritten. What does t_original compared to > the ouput look like? > > > > > 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). > > I had not intended for the t vector to be overwritten (i don't think it is > a problem all the time -- but you've uncovered a case). > > Is it possible for you to send an example fprime function, intial > conditions and time-points so I could try to replicate this behavior. > > Thanks, > > -Travis > > > _______________________________________________ > SciPy-user mailing list > SciPy-user at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-user > From csmith at blakeschool.org Wed Sep 12 17:07:45 2001 From: csmith at blakeschool.org (Christopher Smith) Date: Wed, 12 Sep 2001 16:07:45 -0500 Subject: [SciPy-user] A proposal for a round(x,n) enhancement Message-ID: 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 From oliphant at ee.byu.edu Fri Sep 14 17:17:37 2001 From: oliphant at ee.byu.edu (Travis Oliphant) Date: Fri, 14 Sep 2001 15:17:37 -0600 (MDT) Subject: [SciPy-user] SciPy on FreeBSD In-Reply-To: <3B929A3D.987E1966@home.com> Message-ID: > 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. Rob, Are you still having trouble building SciPy on FreeBSD. Please email me the errors you are getting and I will see if I can figure out what the trouble is. Has anyone else on the list been successful at building SciPy for FreeBSD? Thanks, -Travis O. From europax at home.com Fri Sep 14 20:15:50 2001 From: europax at home.com (Rob) Date: Fri, 14 Sep 2001 17:15:50 -0700 Subject: [SciPy-user] SciPy on FreeBSD References: Message-ID: <3BA29DB6.B1F07569@home.com> Travis Oliphant wrote: > > > 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. > > Rob, > > Are you still having trouble building SciPy on FreeBSD. Please email me > the errors you are getting and I will see if I can figure out what the > trouble is. > > Has anyone else on the list been successful at building SciPy for FreeBSD? > > Thanks, > > -Travis O. I haven't tried in a while. I will generate tonight some error reports with x=0 and with x=1. Neither builds. Rob. -- The Numeric Python EM Project www.members.home.net/europax From eric at scipy.org Fri Sep 14 22:37:34 2001 From: eric at scipy.org (eric jones) Date: Fri, 14 Sep 2001 22:37:34 -0400 Subject: [SciPy-user] A proposal for a round(x,n) enhancement References: Message-ID: <069201c13d8f$604d4960$04c20398@ericlaptop> I'm thinking a new function would be the best route for this. It could be argued that both the current behavior and the requested (signiciant digit rounding) behavior have equal claim to the name round(). However, since rounding to the nth digit left of the 1's got there first, I don't see a compelling reason to change. The significant digit behavior does sound useful though. How about naming it: significant(x,n) If interested, add the implementation to the scipy/misc.py module and submit a patch. thanks, eric ----- Original Message ----- From: "Christopher Smith" To: ; Sent: Wednesday, September 12, 2001 5:07 PM Subject: [SciPy-user] A proposal for a round(x,n) enhancement > 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 > > _______________________________________________ > SciPy-user mailing list > SciPy-user at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-user From csmith at blakeschool.org Sat Sep 15 16:27:29 2001 From: csmith at blakeschool.org (Christopher Smith) Date: Sat, 15 Sep 2001 15:27:29 -0500 Subject: [SciPy-user] Re: PEP proposal for round(x,n) enhancement Message-ID: 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))))) #### From h.jansen at fel.tno.nl Wed Sep 19 11:46:39 2001 From: h.jansen at fel.tno.nl (H Jansen) Date: Wed, 19 Sep 2001 17:46:39 +0200 Subject: [SciPy-user] Documentation. Message-ID: <3BA8BDDF.4334D3D2@fel.tno.nl> >From where can the html documentation be downloaded as a chunk (i.e. tar or zip-ball)? Thanks, Henk -------------- next part -------------- A non-text attachment was scrubbed... Name: h.jansen.vcf Type: text/x-vcard Size: 472 bytes Desc: Card for H Jansen URL: From e.hartley at lancaster.ac.uk Fri Sep 21 13:05:39 2001 From: e.hartley at lancaster.ac.uk (Hartley, Ed) Date: Fri, 21 Sep 2001 18:05:39 +0100 Subject: [SciPy-user] SciPy build problem SWIG? Message-ID: <7823222F821AD311844800204840353A07048458@exchange2.lancs.ac.uk> 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 From oliphant at ee.byu.edu Fri Sep 21 13:14:19 2001 From: oliphant at ee.byu.edu (Travis Oliphant) Date: Fri, 21 Sep 2001 11:14:19 -0600 (MDT) Subject: [SciPy-user] SciPy build problem SWIG? In-Reply-To: <7823222F821AD311844800204840353A07048458@exchange2.lancs.ac.uk> Message-ID: > 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 What is the nature of the failure? > I believe these are dependent on SWIG if so is there a restriction on the SWIG > revision? I don't believe that SWIG is even used during the build process. It was used to generate the interface file, but that is distributed with SciPy. I suspect the problem is not the SWIG revision but something else. -Travis From myers at tc.cornell.edu Fri Sep 21 13:43:33 2001 From: myers at tc.cornell.edu (Chris Myers) Date: Fri, 21 Sep 2001 13:43:33 -0400 Subject: [SciPy-user] SciPy build problem SWIG? In-Reply-To: <7823222F821AD311844800204840353A07048458@exchange2.lancs.ac.uk>; from e.hartley@lancaster.ac.uk on Fri, Sep 21, 2001 at 06:05:39PM +0100 References: <7823222F821AD311844800204840353A07048458@exchange2.lancs.ac.uk> Message-ID: <20010921134333.A9065@sowhat.tc.cornell.edu> I had problems with build SciPy (RH Linux 7.0, Python 2.1), arising from fftw. The problem I had was that libfftw.so (and all the variants, e.g., sfftw, fftw_threads, etc.) was not found correctly in the linking process. Instead, my system has version like libfftw.so.2.0.5, and I solved the problem by making symbolic links, e.g., ln -s libfftw.so.2.0.5 libfftw.so (and so on for all the lib*fftw* variants) I don't know if that's the problem that you are having, but you might give it a shot. Chris ========================================================================== Chris Myers Cornell Theory Center -------------------------------------------------------------------------- 636 Rhodes Hall email: myers at tc.cornell.edu Cornell University phone: (607) 255-5894 / fax: (607) 254-8888 Ithaca, NY 14853 http://www.tc.cornell.edu/~myers ========================================================================== On Fri, Sep 21, 2001 at 06:05:39PM +0100, Hartley, Ed wrote: > 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 > > _______________________________________________ > SciPy-user mailing list > SciPy-user at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-user > From jdhunter at ace.bsd.uchicago.edu Sun Sep 23 16:33:42 2001 From: jdhunter at ace.bsd.uchicago.edu (John Hunter) Date: 23 Sep 2001 15:33:42 -0500 Subject: [SciPy-user] sfftw problem during build Message-ID: <1r1ykx7il5.fsf@video.bsd.uchicago.edu> 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 From eric at scipy.org Sun Sep 23 18:14:03 2001 From: eric at scipy.org (eric jones) Date: Sun, 23 Sep 2001 18:14:03 -0400 Subject: [SciPy-user] sfftw problem during build References: <1r1ykx7il5.fsf@video.bsd.uchicago.edu> Message-ID: <02ba01c1447d$0e058c90$c400a8c0@ericlaptop> Hey John, The instructions on http://www.scipy.org/site_content/tutorials/build_instructions have slightly different configure commands than you used. The second "configure" step should be: [shell]$ ./configure --enable-threads --enable-float --enable-type-prefix The --enable-float command here forces the build to single precision and the --enable-type-prefix switch adds the "s" in front of fftw in the library names. I'd rebuild the entire fftw library based on the instructions on the above page because I'm afraid the double precision rfftw libraries were over written with a single precision version. Where did you find the given config instructions? If we have two versions of the instructions running around, let us know so we can get them in sync. thanks, eric ----- Original Message ----- From: "John Hunter" To: "SciPy Users" Sent: Sunday, September 23, 2001 4:33 PM Subject: [SciPy-user] sfftw problem during build > > 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-linu x-gn > u/2.95.2/specs -Lbuild/temp.linux-i686-2.1 -Lbuild/temp.linux-i686-2.1 -lsff tw_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 > _______________________________________________ > SciPy-user mailing list > SciPy-user at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-user From oliphant.travis at ieee.org Sun Sep 23 17:15:27 2001 From: oliphant.travis at ieee.org (Travis Oliphant) Date: Sun, 23 Sep 2001 21:15:27 +0000 Subject: [SciPy-user] sfftw problem during build In-Reply-To: <1r1ykx7il5.fsf@video.bsd.uchicago.edu> References: <1r1ykx7il5.fsf@video.bsd.uchicago.edu> Message-ID: <01092321152700.01896@travis> On Sun, 23 Sep 2001, you wrote: > 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 > The sfftw libraries are made by the fftw build process. The --enable-float should build them. I'm not sure why in your case it is not building them. Perhaps doing --enable-float first would work. > 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 No, the sfft libraries are the single-precision fftw libraries. SciPy expects you to have built them. Other users have reported successful builds with the commands: in .../src/fftw ./configure --enable-type-prefix make make install make clean ./configure --enable-float --enable-type-prefix make make install and it's the --enable-float that builds the single precision library Good luck, From jdhunter at ace.bsd.uchicago.edu Mon Sep 24 10:25:22 2001 From: jdhunter at ace.bsd.uchicago.edu (John Hunter) Date: 24 Sep 2001 09:25:22 -0500 Subject: [SciPy-user] sfftw problem during build In-Reply-To: <02ba01c1447d$0e058c90$c400a8c0@ericlaptop> References: <1r1ykx7il5.fsf@video.bsd.uchicago.edu> <02ba01c1447d$0e058c90$c400a8c0@ericlaptop> Message-ID: <1r7kuowtrh.fsf@video.bsd.uchicago.edu> >>>>> "eric" == eric jones writes: eric> The --enable-float command here forces the build to single eric> precision and the --enable-type-prefix switch adds the "s" eric> in front of fftw in the library names. I'd rebuild the eric> entire fftw library based on the instructions on the above eric> page because I'm afraid the double precision rfftw libraries eric> were over written with a single precision version. My bad, when I saw enable-type-prefix, I thought these were generic instructions telling you to indicate your architecture for platform dependent optimizations. That is why I substituted the '--enable-i386-hacks' in the place of '--enable-type-prefix' in my configure statement. Now when I configure with # configure --enable-threads --enable-float --enable-type-prefix --enable-i386-hacks I get the sfftw libs. Thanks for the help, JDH