From have at nice.day Thu Jan 2 19:29:34 2003 From: have at nice.day (John Williams) Date: Thu, 2 Jan 2003 19:29:34 Subject: [SciPy-dev] MeteoWeather Message-ID: <20030102174807.CB0453EA03@www.scipy.com> Hello, Do you want a FREE weather report on your website? We have just launched http://MeteoWeather.com FREE worldwide weather reports --- With best regards, John Williams From datafeed at SoftHome.net Thu Jan 2 23:55:52 2003 From: datafeed at SoftHome.net (M. Evans) Date: Thu, 2 Jan 2003 21:55:52 -0700 Subject: [SciPy-dev] Grace Message-ID: <19335581683.20030102215552@SoftHome.net> SciPy, How does SciPy compare to these two projects? Opinions? http://plasma-gate.weizmann.ac.il/Grace/ http://scigraphica.sourceforge.net/ Regards. Mark From datafeed at SoftHome.net Thu Jan 2 23:57:25 2003 From: datafeed at SoftHome.net (M. Evans) Date: Thu, 2 Jan 2003 21:57:25 -0700 Subject: [SciPy-dev] Re: Grace In-Reply-To: <19335581683.20030102215552@SoftHome.net> References: <19335581683.20030102215552@SoftHome.net> Message-ID: <18135674737.20030102215725@SoftHome.net> Or for that matter, http://gerard.vermeulen.free.fr/ which is based on Python and Qt? Just curious mainly about design philosophies and objectives. Mark From eric at enthought.com Fri Jan 3 11:22:27 2003 From: eric at enthought.com (eric jones) Date: Fri, 3 Jan 2003 10:22:27 -0600 Subject: [SciPy-dev] Grace In-Reply-To: <19335581683.20030102215552@SoftHome.net> Message-ID: <000001c2b344$51744e80$8901a8c0@ERICDESKTOP> SciPy is a general purpose library for scientific computing. All of these are principally graphing tools. You're probably looking for the difference between them and Chaco. Generally, they are similar in that they all attack the problem of scientific plotting. The two main differences are that: (a) Chaco is designed to be platform independent so that it doesn't rely on a specific windowing toolkit. (b) Chaco is designed to be used from within Python either from the command line, from scripts, or embedded as a widget in a GUI application. All the apps you mention are different in at least one respect from Chaco. Grace and SciGraphica are both extremely powerful stand-alone graphing tools. We adopted the tree view for property dialogs idea after looking at scigraphica. I haven't looked at PyQwt very closely. At some point I believe SciGraphica will actually be built as python modules that can be used in the same way as Chaco for users on a platform that supports GTK. That will be a nice feature. eric ---------------------------------------------- eric jones 515 Congress Ave www.enthought.com Suite 1614 512 536-1057 Austin, Tx 78701 > -----Original Message----- > From: scipy-dev-admin at scipy.net [mailto:scipy-dev-admin at scipy.net] On > Behalf Of M. Evans > Sent: Thursday, January 02, 2003 10:56 PM > To: SciPy > Subject: [SciPy-dev] Grace > > SciPy, > > How does SciPy compare to these two projects? Opinions? > > http://plasma-gate.weizmann.ac.il/Grace/ > http://scigraphica.sourceforge.net/ > > Regards. > Mark > > _______________________________________________ > Scipy-dev mailing list > Scipy-dev at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-dev From rdafe at latinmail.com Mon Jan 6 07:51:46 2003 From: rdafe at latinmail.com (richard dafe) Date: Mon, 6 Jan 2003 07:51:46 -0500 Subject: [SciPy-dev] INHERITANCE Message-ID: <20030106125142.E5FE918B73@smtp.latinmail.com> Dr. Richard Dafe Branch Manager EcoBank International. Idumota Branch Lagos Nigeria. I am Dr. Richard Dafe The Branch Manager of EcoBank International,Idumota Branch,Lagos Nigeria. I have an urgent and very confidential business proposition for you. On December, 1997, a Taiwanese Oil consultant/contractor with the Nigerian National Petroleum Corporation, Mr. Boris Chen made a numbered time (Fixed) Deposit for Twenty-Four calendar months, valued at US$25,000,000.00 (Twenty- five Million Dollars) in my branch. Upon maturity, I sent a routine notification to his forwarding address but got no reply. After some months, we sent a reminder and finally we discovered from his contract employers, the Nigerian National Petroleum Corporation that Mr. Boris Chen died from an airplane crash ( Singapore Airlines). On further investigation, I found out that he died without making a WILL,and all attempts to trace his next of kin was fruitless. I therefore made further investigation and discovered that Mr. Boris Chen did not declare any kin or relations in all his official documents, including his Bank Deposit paperwork in my Bank. This sum of US$25,000,000.00 is still sitting in my Bank and the interest is being rolled over with the principal sum at the end of each year. No one has ever come forward to claim it. According to Nigerian Law, at the expiration of 5 (five) years, the money will revert to the ownership of the Nigerian Government if nobody applies to claim the fund. Consequently, my proposal is that I will like you to stand in as the next of kin to Mr.Boris Chen so that the fruits of this old man's labour will not get into the hands of some corrupt government officials. This is simple, I will like you to provide immediately your full names and address so that the Attorney will prepare the necessary documents and affidavits which will put you in place as the next of kin. We shall employ the services of two Attorney for drafting and notarization of the WILL and to obtain the necessary documents and letter of probate/administration in your favour for the transfer. A bank account in any part of the world which you will provide will then facilitate the transfer of this money to you as the beneficiary/next of kin. The money will be paid into your account for us to share in the ratio of 70or me and 25or you and 5% be used in settling taxation and all local and foreign expenses.There is no risk at all as all the paperwork for this transaction will be done by the Attorney and my position as the Branch Manager guarantees the successful execution of this transaction. If you are interested, please reply immediately via the private email address below. Upon your response, I shall then provide you with more details and relevant documents that will help you understand the transaction. Please observe utmost confidentiality, and be rest assured that this transaction would be most profitable for both of us because I shall require your assistance to invest my share in your country. I can be reached through this email address. I do urgently await your response or reach me through my confidential and private fax 234-9-272-1684. Best regards, Dr. Richard Dafe _________________________________________________________ http://www.latinmail.com. Gratuito, latino y en espa?ol. From eric at enthought.com Mon Jan 6 18:47:57 2003 From: eric at enthought.com (eric jones) Date: Mon, 6 Jan 2003 17:47:57 -0600 Subject: [SciPy-dev] RE: [Scipy-cvs] world/scipy/scipy_distutils/command build_flib.py,1.51,1.52 cpuinfo.py,1.6,1.7 In-Reply-To: <20030106234042.3C6303EA03@www.scipy.com> Message-ID: <000001c2b5de$0cf69910$8901a8c0@ERICDESKTOP> > > Update of /home/cvsroot/world/scipy/scipy_distutils/command > In directory shaft:/tmp/cvs-serv4764/command > > Modified Files: > build_flib.py cpuinfo.py > Log Message: > Impl. cpuinfo for darwin platform. Fixed gnu compiler support > on darwin (no need for -lg2c) and impl. optimization hooks > for this platform. Clean up code. A > note: currently Fortran > compilers are used with architecture/machine dependent > optimization flags. We need a switch that turns off > architecture/machine dependent optimization flags (but > keeping generic optimization flags) when building > distributable scipy binaries. I agree that this is going to be important -- especially when creating the versions for download on the website. eric From oliphant at ee.byu.edu Mon Jan 13 19:44:44 2003 From: oliphant at ee.byu.edu (Travis Oliphant) Date: Mon, 13 Jan 2003 17:44:44 -0700 (MST) Subject: [SciPy-dev] SciPy 0.2 Message-ID: We really need to get SciPy 0.2 done, right. What has left to be done. Should I spend time writing more docs, or writing more tests? Probably both, right? Are packaging issues all that remain. There are stable ATLAS binaries that work for many cases, now, so everybody doesn't have to compile ATLAS. Are we waiting for Chaco to mature, more? What needs to be done to complete the 0.2 cycle? -Travis O. -- Travis Oliphant Assistant Professor 459 CB Electrical and Computer Engineering Brigham Young University Provo, UT 84602 Tel: (801) 422-3108 oliphant.travis at ieee.org From pearu at cens.ioc.ee Tue Jan 14 10:55:31 2003 From: pearu at cens.ioc.ee (Pearu Peterson) Date: Tue, 14 Jan 2003 17:55:31 +0200 (EET) Subject: [SciPy-dev] SciPy 0.2 In-Reply-To: Message-ID: On Mon, 13 Jan 2003, Travis Oliphant wrote: > We really need to get SciPy 0.2 done, right. > > What has left to be done. > > Should I spend time writing more docs, or writing more tests? Probably > both, right? Double-right. > Are packaging issues all that remain. There are stable ATLAS binaries > that work for many cases, now, so everybody doesn't have to compile ATLAS. > > Are we waiting for Chaco to mature, more? > > What needs to be done to complete the 0.2 cycle? I think that the current CVS SciPy is ready for 0.2 release, but what we are lacking is a robust framework for making SciPy releases. This framework should include: * generating SciPy tar-balls, rpm, deb, etc. packages * exposing them at SciPy web or ftp sites * verifying that they are complete and work with various systems and setups --- autotesting. * updating scipy web site: instructions for download, installation, usage, bug reports, etc. I am currently (re)working with SciPy autotesting support that Eric, David, and Skip started earlier. Pearu From futures at casstel.net Fri Jan 17 09:27:22 2003 From: futures at casstel.net (Trump Trading Report) Date: Fri, 17 Jan 2003 08:27:22 -0600 Subject: [SciPy-dev] "Lifestyle Trades" Message-ID: <20030117144456.0863D3EB09@www.scipy.com> "Im talking about a trade so big, so perfect, so incredible that it could singlehandedly change your entire lifestyle..." Trump Trading Report Searching for the "Big One" I have been educating and helping individuals make insightful and strategic investment decisions for many years. Along with this brief introduction I have included some of the recent big moves that I have predicted, and their results. I have worked on these strategies for several years now trying to unlock the secrets that only the markets know. Coming to only one simple conclusion, I have found that everyone whom I have seen make it big, I mean really big seemed to hit that one home run, they had that one trade that just seemed to make them a fortune. These so called "Big Ones" have fascinated me for as long as I can remember. Their elusiveness and mystique simply send chills down my spine. I'm not the only one, people everywhere seem to want the opportunity to hit it big just once. On the floor, we used to call it a "lifestyle trade", a trade so big, so perfect, so incredible that it could singlehandedly change your entire lifestyle. These are the opportunities I am talking about, these are the opportunities that are out there. Don't let people tell you they are not. I have seen them, I have felt them, I have watched them over the past several years change peoples lives. I have watched them buy exotic cars, build million dollar getaways, pay for college tuition's...All you have to do is find the right wave and ride it out. The money is there..., the markets are there..., it is all just sitting there waiting for you...,can you pick the right one??? Recent "Big Ones" Coffee (1999) $25,000 into $217,875.....Corn (2002) $5,000 into $47,000.....S&P 500 (1998) $24,000 into $1,025,750.....Crude Oil (2002) Gains of over $16,000 per contract.....Sugar (2000) $6,400 into $82,200.....Soybeans (2002) $12,000 into $125,400.....Silver (2002) $10,000 into $44,800.....Orange Juice (2001) $11,000 to $72,000.....Gold (1999) $8,500 into $148,400.....Lean Hogs (2002) $14,000 into $179,600.....Unleaded Gas (2002) $25,000 into $194,040 All for only $20 month You will receive In-depth Market Analysis, the latest Industry Breaking News, Detailed Trading Strategies and Comprehensive Professional Commentary all for only $20 per month. "I have subscribed to hundreds of so called investment newsletters, but none give me the real inside scoop or hot tips on the big moves like the Trump Trading Report ." Dr. Davenport, Missouri "If I had to recommend just one man to follow, or one newsletter to read, this would be the one. These strategies and reports could make you an absolute fortune." Lance J. Holbrook, Texas "Absolutely the best, finally something everyone can understand, a must for anyone trading in today's markets." John Noblit, Arizona "The information is fantastic, its as if I am right there looking over his shoulder." Larry Rains, California No Risk Money Back Guarantee If at any time you are not completely satisfied with the Trump Trading Report or its content we will refund 100% of your monthly cost. No Questions Asked!!! Sign Me Up Today Call Toll Free 1-800-357-5249 for Master Card and Visa Send Personal Checks to: PO Box 481934, Kansas City, MO 64148 Questions and additional Information: kvt at casstel.net or visit www.trumptrading.com If you have received this email in error we appologize, this leter is being sent to pre-qualified addresses whom have indicated investment interest. To be removed please reply to this email with remove in the subject area. From eric at enthought.com Fri Jan 24 01:56:30 2003 From: eric at enthought.com (eric jones) Date: Fri, 24 Jan 2003 00:56:30 -0600 Subject: [SciPy-dev] still getting undefined symbols on scipy builds on SunOS Message-ID: <010401c2c375$bc471440$8901a8c0@ERICDESKTOP> Hey Pearu, I've added the mvec library to the SunOS compiler, and that, along with your additions, solved my build problems on an f90 project that we discussed a week or so ago. But, I just noticed scipy doesn't all link correctly on sun now -- at least the linalg library doesn't on my machine when building with Forte f90. I get undefined symbols for s_stop and s_copy on calc_lwork and _flinalg. I expect the others have similar problems. bash-2.05$ nm calc_lwork.so | grep s_copy [236] | 0| 0|NOTY |GLOB |0 |UNDEF |s_copy When looking at the object file, I don't see this symbol anywhere, which means it is coming from some other library? bash-2.05$ nm -A calc_lwork.o | grep s_copy bash-2.05$ I added f77_compat which has: bash-2.05$ cd /opt/SUNWspro/lib bash-2.05$ nm -A *.so | grep s_copy libf77compat.so: [1800] | 109760| 292|FUNC |GLOB |0 |9 |__s_copy libf77compat.so: [900] | 0| 0|FILE |LOCL |0 |ABS |s_copy.c libfsu.so: [3657] | 121972| 492|FUNC |GLOB |0 |9 |__f90_s_copy libfsu.so: [1168] | 0| 0|FILE |LOCL |0 |ABS |f90s_copy.c Do you think there is some name mangling issues occurring here, or is it that I need to add a different library? Oooo. I think I figured it out. I bet my version of atlas was built with g77. Yep: bash-2.05$ cd /usr/lib bash-2.05$ nm liblapack.a | grep s_copy [6] | 0| 0|NOTY |GLOB |0 |UNDEF |s_copy So, adding -L/opt/sfw/lib/gcc-lib/sparc-sun-solaris2.8/2.95.3 -lg2c to the link line gets everything to compile. So, should atlas_info try and go a step further and check what compiler was used to build lapack and friends? If it sees g77, it could add the library g2c and the appropriate library directory to the path. The combinations are endless, but, since ATLAS is usually built with gcc, the given case is probably pretty common. I'd like to hear your ideas (or anyone elses), as I might have missed an easier approach. Thanks, eric ---------------------------------------------- eric jones 515 Congress Ave www.enthought.com Suite 1614 512 536-1057 Austin, Tx 78701 From pearu at cens.ioc.ee Fri Jan 24 03:23:21 2003 From: pearu at cens.ioc.ee (Pearu Peterson) Date: Fri, 24 Jan 2003 10:23:21 +0200 (EET) Subject: [SciPy-dev] still getting undefined symbols on scipy builds on SunOS In-Reply-To: <010401c2c375$bc471440$8901a8c0@ERICDESKTOP> Message-ID: On Fri, 24 Jan 2003, eric jones wrote: > But, I just noticed scipy doesn't all link correctly on sun now -- at > least the linalg library doesn't on my machine when building with Forte > f90. I get undefined symbols for s_stop and s_copy on calc_lwork and > _flinalg. I expect the others have similar problems. > > bash-2.05$ nm calc_lwork.so | grep s_copy > [236] | 0| 0|NOTY |GLOB |0 |UNDEF |s_copy > > When looking at the object file, I don't see this symbol anywhere, which > means it is coming from some other library? > > bash-2.05$ nm -A calc_lwork.o | grep s_copy > bash-2.05$ > > I added f77_compat which has: > > bash-2.05$ cd /opt/SUNWspro/lib > bash-2.05$ nm -A *.so | grep s_copy > libf77compat.so: [1800] | 109760| 292|FUNC |GLOB |0 |9 |__s_copy > libf77compat.so: [900] | 0| 0|FILE |LOCL |0 |ABS |s_copy.c > libfsu.so: [3657] | 121972| 492|FUNC |GLOB |0 |9 |__f90_s_copy > libfsu.so: [1168] | 0| 0|FILE |LOCL |0 |ABS |f90s_copy.c > > Do you think there is some name mangling issues occurring here, or is it > that I need to add a different library? > > Oooo. I think I figured it out. I bet my version of atlas was built > with g77. Yep: > > bash-2.05$ cd /usr/lib > bash-2.05$ nm liblapack.a | grep s_copy > [6] | 0| 0|NOTY |GLOB |0 |UNDEF |s_copy > > So, adding > > -L/opt/sfw/lib/gcc-lib/sparc-sun-solaris2.8/2.95.3 -lg2c > > to the link line gets everything to compile. > > So, should atlas_info try and go a step further and check what compiler > was used to build lapack and friends? I hope not. Instead, various user-specific mixing of compilers/libraries should be done in site.cfg level. But see below. > If it sees g77, it could add the library g2c and the appropriate > library directory to the path. The combinations are endless, but, > since ATLAS is usually built with gcc, the given case is probably > pretty common. Indeed, ATLAS is often built with gcc but it does not use g77 for building its libraries (g77 is used only when running tests). So, adding g77 specific -lg2c to non-g77 specific atlas_info is not a proper solution. The missing symbols s_copy,.. come from the g77 built lapack library. IMO, the right solution is to recompiler lapack library with Forte f90 compiler if you are using the same compiler in scipy.linalg (this also means that you have to redo lapack/atlas connection). Then there should be no need to use -lg2c when linking. I have included setup_lapack.py file at the end of this message. This might ease building lapack libraries with Forte f90 (not that it would be so difficult) using FC_VENDOR=Sun LAPACK_SRC=/path/to/LAPACK setup.py \ build_flib --build-flib=/path/to/where/you/want/liblapack.a/ Pearu #-------- setup_lapack.py ------------ from scipy_distutils.system_info import get_info,LapackSrcNotFoundError from scipy_distutils.misc_util import fortran_library_item def configuration(parent_package=''): # Use LAPACK_SRC environment variable to indicate the location # of LAPACK sources. lapack_src_info = get_info('lapack_src') if not lapack_src_info: raise LapackSrcNotFoundError config = {} config['fortran_libraries'] = [\ fortran_library_item('lapack',lapack_src_info['sources']) ] return config if __name__ == '__main__': from scipy_distutils.core import setup setup(**configuration()) #-------------------------------------- From otttr440 at student.liu.se Fri Jan 24 09:28:13 2003 From: otttr440 at student.liu.se (Otto Tronarp) Date: 24 Jan 2003 15:28:13 +0100 Subject: [SciPy-dev] Problem with stats.distributions.randint Message-ID: <1043418492.1848.29.camel@mathcore2> Hi, I'm having problem with stats.distributions.randint, I get the following traceback: >>> ri = scipy.stats.distributions.randint(0,5) Traceback (most recent call last): File "", line 1, in ? File "/home/zzap/sandbox/py-lib/lib/python2.2/site-packages/scipy/stats/distri butions.py", line 2727, in __call__ U = rv.random(size=self._size) AttributeError: 'module' object has no attribute 'random' So I took a look in rv.py and I couldn't find any there. By the look of the cvslog it seems like a lot of functionality was moved from rv to distributions about 2 month ago and by the look of it random was moved so I tried to change that line to U = random(size=self._size) But now I get: ri=scipy.stats.distributions.randint(0,5) Traceback (most recent call last): File "", line 1, in ? File "/home/zzap/sandbox/py-lib/lib/python2.2/site-packages/scipy/stats/distributions.py", line 2727, in __call__ U = random(size=self._size) AttributeError: randint_gen instance has no attribute '_size' Poking around in the source a little more it seem like the only place where self._size is set is in rv_discrete.rvs and that one is called from rvc_discrete.__call__, but since randint_gen overides the __call__ method it's never set. Am I correct in my analysis? If so is the attached patch the correct cure? Regards, Otto -------------- next part -------------- A non-text attachment was scrubbed... Name: randintfix.patch Type: text/x-patch Size: 1205 bytes Desc: not available URL: From otttr440 at student.liu.se Fri Jan 24 11:49:38 2003 From: otttr440 at student.liu.se (Otto Tronarp) Date: 24 Jan 2003 17:49:38 +0100 Subject: [SciPy-dev] Problem with stats.distributions.randint In-Reply-To: <1043418492.1848.29.camel@mathcore2> References: <1043418492.1848.29.camel@mathcore2> Message-ID: <1043426976.2497.3.camel@mathcore2> On Fri, 2003-01-24 at 15:28, Otto Tronarp wrote: > Hi, > > I'm having problem with stats.distributions.randint, I get the following > traceback: > There seems to be even more problems with randint_gen. I think there is a missing 'return fact' in the _pdf method. The attached patch fixes that along with the other problems. Regards, Otto -------------- next part -------------- A non-text attachment was scrubbed... Name: randintfix2.patch Type: text/x-patch Size: 1438 bytes Desc: not available URL: From otttr440 at student.liu.se Fri Jan 24 12:46:58 2003 From: otttr440 at student.liu.se (Otto Tronarp) Date: 24 Jan 2003 18:46:58 +0100 Subject: [SciPy-dev] Problem with stats.distributions.randint In-Reply-To: <1043426976.2497.3.camel@mathcore2> References: <1043418492.1848.29.camel@mathcore2> <1043426976.2497.3.camel@mathcore2> Message-ID: <1043430417.2492.25.camel@mathcore2> More problems, the __call__ method of rv_discrete has wrong indentation so it's actually a local function in the moment method. This is beginning to be a little scary, as far as I can see the code has looked like this for 2 month. Doesn't anyone use these? Have someone ever checked that they generate correct results or at least results that look correct? The attached patch tries to fix all of the problems reported in this thread. Regards, Otto On Fri, 2003-01-24 at 17:49, Otto Tronarp wrote: > On Fri, 2003-01-24 at 15:28, Otto Tronarp wrote: > > Hi, > > > > I'm having problem with stats.distributions.randint, I get the following > > traceback: > > > > There seems to be even more problems with randint_gen. I think there is > a missing 'return fact' in the _pdf method. The attached patch fixes > that along with the other problems. > > Regards, > Otto -------------- next part -------------- A non-text attachment was scrubbed... Name: fixdiscrete_dists.patch Type: text/x-patch Size: 1703 bytes Desc: not available URL: From oliphant.travis at ieee.org Fri Jan 24 13:15:43 2003 From: oliphant.travis at ieee.org (Travis Oliphant) Date: 24 Jan 2003 11:15:43 -0700 Subject: [SciPy-dev] Problem with stats.distributions.randint In-Reply-To: <1043418492.1848.29.camel@mathcore2> References: <1043418492.1848.29.camel@mathcore2> Message-ID: <1043432144.31066.6.camel@travis.local.net> On Fri, 2003-01-24 at 07:28, Otto Tronarp wrote: > Hi, > > I'm having problem with stats.distributions.randint, I get the following > traceback: Could be, thanks for the pointers. I will look into it. Incidentally, you shouldn't have to call scipy.stats.distributions.randint. scipy.stats.randint should be fine -teo From oliphant.travis at ieee.org Fri Jan 24 13:35:58 2003 From: oliphant.travis at ieee.org (Travis Oliphant) Date: 24 Jan 2003 11:35:58 -0700 Subject: [SciPy-dev] Problem with stats.distributions.randint In-Reply-To: <1043430417.2492.25.camel@mathcore2> References: <1043418492.1848.29.camel@mathcore2> <1043426976.2497.3.camel@mathcore2> <1043430417.2492.25.camel@mathcore2> Message-ID: <1043433359.30952.10.camel@travis.local.net> On Fri, 2003-01-24 at 10:46, Otto Tronarp wrote: > More problems, the __call__ method of rv_discrete has wrong indentation > so it's actually a local function in the moment method. This is > beginning to be a little scary, as far as I can see the code has looked > like this for 2 month. Doesn't anyone use these? Have someone ever > checked that they generate correct results or at least results that look > correct? The discrete random number generators have not been well tested. The continuous number generators have been well tested. Thank you for helping us fix these errors. -Travis O. From oliphant.travis at ieee.org Fri Jan 24 18:37:02 2003 From: oliphant.travis at ieee.org (Travis Oliphant) Date: 24 Jan 2003 16:37:02 -0700 Subject: [SciPy-dev] Problem with stats.distributions.randint In-Reply-To: <1043430417.2492.25.camel@mathcore2> References: <1043418492.1848.29.camel@mathcore2> <1043426976.2497.3.camel@mathcore2> <1043430417.2492.25.camel@mathcore2> Message-ID: <1043451424.14771.4.camel@travis.local.net> > More problems, the __call__ method of rv_discrete has wrong indentation > so it's actually a local function in the moment method. This is > beginning to be a little scary, as far as I can see the code has looked > like this for 2 month. Doesn't anyone use these? Have someone ever > checked that they generate correct results or at least results that look > correct? Otto, Thanks for your help. These problems have been corrected and are now in the CVS version of SciPy. If you would like to contribute tests for the remainder of the discrete distributions, your help would be appreciated. Thanks again, -Travis O. From otttr440 at student.liu.se Sat Jan 25 06:02:51 2003 From: otttr440 at student.liu.se (Otto Tronarp) Date: 25 Jan 2003 12:02:51 +0100 Subject: [SciPy-dev] Problem with stats.distributions.randint In-Reply-To: <1043451424.14771.4.camel@travis.local.net> References: <1043418492.1848.29.camel@mathcore2> <1043430417.2492.25.camel@mathcore2> <1043451424.14771.4.camel@travis.local.net> Message-ID: <1043492571.1010.10.camel@mathcore2> On Sat, 2003-01-25 at 00:37, Travis Oliphant wrote: > > Otto, > > Thanks for your help. These problems have been corrected and are now in > the CVS version of SciPy. > Ok, great. > If you would like to contribute tests for the remainder of the discrete > distributions, your help would be appreciated. > I might do that when I have some free time, but it won't happen any time soon at earliest in the end of februari. > Thanks again, > > -Travis O. > No problem, I'm just glad I could help. Is there a TODO list or similar that I could pick tasks from if I ever find my self with any excess free time (yea like that would really happen) ? Regards, Otto From otttr440 at student.liu.se Sat Jan 25 15:06:36 2003 From: otttr440 at student.liu.se (Otto Tronarp) Date: 25 Jan 2003 21:06:36 +0100 Subject: [SciPy-dev] Inconsisten return type from discrete dists. Message-ID: <1043525196.1012.74.camel@mathcore2> Hello, I started looking on writing some unit tests anyway. While doing that I discovered that the return type from discrete distributions where inconsistent or rather they all seems to return floats except for randint. Further, some of them also returns a array of length 1 when called without size argument while others return a simple number. For the first issue I feel that it is more natural for them to return ints, the attached patch, return_ints.pathc, fixes that. For the second issue I think that it is more convenient if they always returns an array. I have no patch for that, but I can fix it if that is the consensus. While I wrote the unit tests I also found more bugs. There seem to be a missing function in rv.py, namley _check_shape. By the look of how it's used it should do something like this: def _check_shape(size): if isinstance(size, tuple): Ns = reduce(operator.mul, size) else: Ns = size return (size, Ns) Attached patch, missing_check_shape.patch, fixes that. I also have a couple of question on coding guide lines. 1 - What is the correct way to check if a array is of integer type? 2 - What is the correct way to call things from Numeric? i.e. scipy.shape(a) or Numeric.shape(a)? Regards, Otto -------------- next part -------------- A non-text attachment was scrubbed... Name: missing_check_shape.patch Type: text/x-patch Size: 950 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: return_ints.patch Type: text/x-patch Size: 668 bytes Desc: not available URL: From oliphant.travis at ieee.org Sat Jan 25 17:03:12 2003 From: oliphant.travis at ieee.org (Travis Oliphant) Date: 25 Jan 2003 15:03:12 -0700 Subject: [SciPy-dev] Inconsisten return type from discrete dists. In-Reply-To: <1043525196.1012.74.camel@mathcore2> References: <1043525196.1012.74.camel@mathcore2> Message-ID: <1043532194.28335.2.camel@travis.local.net> On Sat, 2003-01-25 at 13:06, Otto Tronarp wrote: > Hello, > > I started looking on writing some unit tests anyway. While doing that I > discovered that the return type from discrete distributions where > inconsistent or rather they all seems to return floats except for > randint. Further, some of them also returns a array of length 1 when > called without size argument while others return a simple number. > Great, thanks for looking at this. > For the first issue I feel that it is more natural for them to return > ints, the attached patch, return_ints.pathc, fixes that. > Yes, I agree with you. > For the second issue I think that it is more convenient if they always > returns an array. I have no patch for that, but I can fix it if that is > the consensus. > > While I wrote the unit tests I also found more bugs. There seem to be a > missing function in rv.py, namley _check_shape. By the look of how it's > used it should do something like this: > > def _check_shape(size): > if isinstance(size, tuple): > Ns = reduce(operator.mul, size) > else: > Ns = size > return (size, Ns) > > Attached patch, missing_check_shape.patch, fixes that. > > I also have a couple of question on coding guide lines. > > 1 - What is the correct way to check if a array is of integer type? > 2 - What is the correct way to call things from Numeric? i.e. > scipy.shape(a) or Numeric.shape(a)? > It's not completely consistent, but I think scipy.shape is better as it will make a transition to numarray easier if and when that happens. Travis O. From otttr440 at student.liu.se Sun Jan 26 10:47:35 2003 From: otttr440 at student.liu.se (Otto Tronarp) Date: 26 Jan 2003 16:47:35 +0100 Subject: [SciPy-dev] Error in stats/discrete.lyx Message-ID: <1043596054.1023.24.camel@mathcore2> While writing the unit tests for the discrete distributions I looked a little in discrete.lyx to fresh up my memory on some of the distributions. And there seems to be an error in the section on negative binomial distribution. It says "..can be defined as the number of independent trials required to accumulate a total of n successes" which gives a valid range for k as k>=n. However, I always thought it was the number of failures before reaching n success and hence k>=0. The result from stats.nbinom seems to agree with me, it seldom generates numbers larger than n. I don't have a patch for this since the docs seems to be written with an old version of lyx that I don't have. Regards, Otto From eric at enthought.com Sun Jan 26 16:28:32 2003 From: eric at enthought.com (eric jones) Date: Sun, 26 Jan 2003 15:28:32 -0600 Subject: [SciPy-dev] Inconsisten return type from discrete dists. In-Reply-To: <1043525196.1012.74.camel@mathcore2> Message-ID: <017b01c2c581$e33d8cb0$8901a8c0@ERICDESKTOP> Hey Otto, Thanks for the help. Unit tests are sorely needed in a number of locations. I'm actually amazed at how many SciPy has (800+ when weave is included), but I find the quantity still needed daunting. > > I started looking on writing some unit tests anyway. While doing that I > discovered that the return type from discrete distributions where > inconsistent or rather they all seems to return floats except for > randint. Further, some of them also returns a array of length 1 when > called without size argument while others return a simple number. > > For the first issue I feel that it is more natural for them to return > ints, the attached patch, return_ints.pathc, fixes that. So you're saying that everything continues to return floats except for randint which returns ints? If so, then I agree. > > For the second issue I think that it is more convenient if they always > returns an array. I have no patch for that, but I can fix it if that is > the consensus. Yes, this sounds appropriate. > > While I wrote the unit tests I also found more bugs. There seem to be a > missing function in rv.py, namley _check_shape. By the look of how it's > used it should do something like this: > > def _check_shape(size): > if isinstance(size, tuple): > Ns = reduce(operator.mul, size) > else: > Ns = size > return (size, Ns) > > Attached patch, missing_check_shape.patch, fixes that. > > I also have a couple of question on coding guide lines. > > 1 - What is the correct way to check if a array is of integer type? > 2 - What is the correct way to call things from Numeric? i.e. > scipy.shape(a) or Numeric.shape(a)? Pretty much the entire code base assumes that Numeric (scipy_base actually) is part of the standard set of functions needed for scientific work. So, the following is used: from scipy_base import * It may occasionally show up as from Numeric import * from scipy_base.fastumath import * I think we should standardize on the first. You can use shape() without qualifying it with a module. Otto, if you would like CVS access to add your tests, let me know. Thanks, Eric From southey at ux1.cso.uiuc.edu Mon Jan 27 10:44:45 2003 From: southey at ux1.cso.uiuc.edu (southey at ux1.cso.uiuc.edu) Date: Mon, 27 Jan 2003 09:44:45 -0600 (CST) Subject: [SciPy-dev] Problem with stats.distributions.randint In-Reply-To: <1043492571.1010.10.camel@mathcore2> Message-ID: Hi, > > No problem, I'm just glad I could help. Is there a TODO list or similar > that I could pick tasks from if I ever find my self with any excess free > time (yea like that would really happen) ? > I would be interested in this aspect as well because I am interested in becoming involved with the stats module. If not can we set one up? Regards Bruce Southey From oliphant at ee.byu.edu Mon Jan 27 11:37:12 2003 From: oliphant at ee.byu.edu (Travis Oliphant) Date: Mon, 27 Jan 2003 09:37:12 -0700 (MST) Subject: [SciPy-dev] Error in stats/discrete.lyx In-Reply-To: <1043596054.1023.24.camel@mathcore2> Message-ID: > > While writing the unit tests for the discrete distributions I looked a > little in discrete.lyx to fresh up my memory on some of the > distributions. And there seems to be an error in the section on negative > binomial distribution. It says "..can be defined as the number of > independent trials required to accumulate a total of n successes" which > gives a valid range for k as k>=n. However, I always thought it was the > number of failures before reaching n success and hence k>=0. The result > from stats.nbinom seems to agree with me, it seldom generates numbers > larger than n. I don't have a patch for this since the docs seems to be > written with an old version of lyx that I don't have. Thanks, I'll check on this. I thought I was using the latest lyx version (1.2.1) Perhaps you meant a newer version of lyx? Incidentally, the .lyx file is a text file with mathematics written using standard LaTeX style. So, you can edit the ascii file directly, if you'd like as well. -Travis From oliphant at ee.byu.edu Mon Jan 27 11:44:22 2003 From: oliphant at ee.byu.edu (Travis Oliphant) Date: Mon, 27 Jan 2003 09:44:22 -0700 (MST) Subject: [SciPy-dev] Problem with stats.distributions.randint In-Reply-To: Message-ID: > I would be interested in this aspect as well because I am interested in > becoming involved with the stats module. > > If not can we set one up? > Absolutely, If you have ideas please list them. Later today, I will think up my own list. -Travis O. =================== Travis Oliphant Assistant Professor 459 CB Electrical and Computer Engineering Brigham Young University Provo, UT 84602 Tel: (801) 422-3108 oliphant.travis at ieee.org From otttr440 at student.liu.se Mon Jan 27 15:36:22 2003 From: otttr440 at student.liu.se (Otto Tronarp) Date: 27 Jan 2003 21:36:22 +0100 Subject: [SciPy-dev] Error in stats/discrete.lyx In-Reply-To: References: Message-ID: <1043699781.1472.7.camel@mathcore2> On Mon, 2003-01-27 at 17:37, Travis Oliphant wrote: [snip] > Thanks, I'll check on this. I thought I was using the latest lyx version > (1.2.1) Perhaps you meant a newer version of lyx? > You are indeed right, for all that matters 1.2.1 is the newest (they have actually released 1.2.3 but that's just minor bug fixes). I'm using the cvs version of lyx, but now they have a converter for old lyx files so I should be able to read old lyx files with it. But somehow it doesn't seem to like the \boldsymbol\theta constructs. It mangles them to something that LaTeX doesn't like. I don't know what the problem is, maybe a change in how the math parser works. Regards, Otto From otttr440 at student.liu.se Mon Jan 27 15:56:53 2003 From: otttr440 at student.liu.se (Otto Tronarp) Date: 27 Jan 2003 21:56:53 +0100 Subject: [SciPy-dev] Inconsisten return type from discrete dists. In-Reply-To: <017b01c2c581$e33d8cb0$8901a8c0@ERICDESKTOP> References: <017b01c2c581$e33d8cb0$8901a8c0@ERICDESKTOP> Message-ID: <1043701012.1475.27.camel@mathcore2> On Sun, 2003-01-26 at 22:28, eric jones wrote: [snip] > > discovered that the return type from discrete distributions where > > inconsistent or rather they all seems to return floats except for > > randint. Further, some of them also returns a array of length 1 when > > called without size argument while others return a simple number. > > > > For the first issue I feel that it is more natural for them to return > > ints, the attached patch, return_ints.pathc, fixes that. > > So you're saying that everything continues to return floats except for > randint which returns ints? If so, then I agree. > I don't quite understand what you mean. (My English isn't the best..) Before it was like this: More than one of the discrete distributions returned floats (I did only test a couple of them) and at least one (randint) return integers. I want them all to return integers and that's what my patch is doing. That is what I would expect them to do, but maybe there are other applications where floats are more sensible that I don't see. If I understand you correctly you want to keep it like it was before, or? > > > > For the second issue I think that it is more convenient if they always > > returns an array. I have no patch for that, but I can fix it if that > is > > the consensus. > > Yes, this sounds appropriate. > Ok, I'll prepare a patch for this then. [snip] > Otto, if you would like CVS access to add your tests, let me know. > As long as I'm just doing smal patches I'm perfectly fine with sending patches to the list. But I would like do more substantial contributions in the future and then it would be nice with CVS access. I'll need to finish my master thesis first though and I'm going on vacation later in the week so I won't have any time to do any real work before the end of Februari. Concerning the unit tests, I have written tests for the rsv's now that check's that the result is in the right domain and of right type/size. I then plan to move on with tests for the pdf and cdf. I haven't yet decided on how to them, but I was thinking of calculating them with a "known good" implementation of them and compare to that. Any other suggestions? Regards, Otto From southey at ux1.cso.uiuc.edu Mon Jan 27 15:54:09 2003 From: southey at ux1.cso.uiuc.edu (southey at ux1.cso.uiuc.edu) Date: Mon, 27 Jan 2003 14:54:09 -0600 (CST) Subject: [SciPy-dev] Stats module (was Problem with stats.distributions.randint) In-Reply-To: Message-ID: Hi, General linear model is probably the most important since things like regression and analysis of (co)variance can be fitted in this framework. The current option is rather limited. There needs to be some general consensus on how this would work and the resulting output. I see three parts: a) A model stage that defines the terms in the model - mainly to provide the design matrix X. b) The engine that sets the system of equations and solves it. The easy approach is find inverse of X'X and solve b=inv(X'X)X'Y. Alternatively use a sweep function. c) The output that contains the requested outputs - provides standard errors, reduction in sum of squares, contrasts, estimates, residuals. The following build upon general linear models: 1) Mixed models 2) Generalized linear models - fits distributions like binomial and poisson. 3) Non-linear models Regards Bruce On Mon, 27 Jan 2003, Travis Oliphant wrote: > > I would be interested in this aspect as well because I am interested in > > becoming involved with the stats module. > > > > If not can we set one up? > > > > Absolutely, If you have ideas please list them. Later today, I will > think up my own list. > > -Travis O. > > > =================== > Travis Oliphant > Assistant Professor > 459 CB > Electrical and Computer Engineering > Brigham Young University > Provo, UT 84602 > Tel: (801) 422-3108 > oliphant.travis at ieee.org > > _______________________________________________ > Scipy-dev mailing list > Scipy-dev at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-dev > From otttr440 at student.liu.se Mon Jan 27 16:00:15 2003 From: otttr440 at student.liu.se (Otto Tronarp) Date: 27 Jan 2003 22:00:15 +0100 Subject: [SciPy-dev] Problem with stats.distributions.randint In-Reply-To: References: Message-ID: <1043701214.1475.31.camel@mathcore2> On Mon, 2003-01-27 at 17:44, Travis Oliphant wrote: > > I would be interested in this aspect as well because I am interested in > > becoming involved with the stats module. > > > > If not can we set one up? > > > > Absolutely, If you have ideas please list them. Later today, I will > think up my own list. > > -Travis O. I have no direct plans on what I want to do, I was just looking for something interesting and fun to do that's why I asked for a to do list. However, I plan to finish the unit tests for the discrete distributions. Regards, Otto From eric at enthought.com Mon Jan 27 17:51:39 2003 From: eric at enthought.com (eric jones) Date: Mon, 27 Jan 2003 16:51:39 -0600 Subject: [SciPy-dev] Inconsisten return type from discrete dists. In-Reply-To: <1043701012.1475.27.camel@mathcore2> Message-ID: <01d901c2c656$aa404120$8901a8c0@ERICDESKTOP> > > On Sun, 2003-01-26 at 22:28, eric jones wrote: > [snip] > > > discovered that the return type from discrete distributions where > > > inconsistent or rather they all seems to return floats except for > > > randint. Further, some of them also returns a array of length 1 when > > > called without size argument while others return a simple number. > > > > > > For the first issue I feel that it is more natural for them to return > > > ints, the attached patch, return_ints.pathc, fixes that. > > > > So you're saying that everything continues to return floats except for > > randint which returns ints? If so, then I agree. > > > > I don't quite understand what you mean. (My English isn't the best..) Neither is mine, but I'm betting you have a better excuse than I do...:-) > > Before it was like this: More than one of the discrete distributions > returned floats (I did only test a couple of them) and at least one > (randint) return integers. > > I want them all to return integers and that's what my patch is doing. > That is what I would expect them to do, but maybe there are other > applications where floats are more sensible that I don't see. I was thinking about continuous distributions also -- not just discrete ones, so it was my misunderstanding. The behavior you are asking for sounds right to me. > > If I understand you correctly you want to keep it like it was before, > or? > > > > > > > For the second issue I think that it is more convenient if they always > > > returns an array. I have no patch for that, but I can fix it if that > > is > > > the consensus. > > > > Yes, this sounds appropriate. > > > > Ok, I'll prepare a patch for this then. > > [snip] > > > Otto, if you would like CVS access to add your tests, let me know. > > > > As long as I'm just doing smal patches I'm perfectly fine with sending > patches to the list. But I would like do more substantial contributions > in the future and then it would be nice with CVS access. I'll need to > finish my master thesis first though and I'm going on vacation later in > the week so I won't have any time to do any real work before the end of > Februari. > > Concerning the unit tests, I have written tests for the rsv's now that > check's that the result is in the right domain and of right type/size. I > then plan to move on with tests for the pdf and cdf. I haven't yet > decided on how to them, but I was thinking of calculating them with a > "known good" implementation of them and compare to that. Any other > suggestions? Ok. We'll add access when you're ready. See ya, eric From otttr440 at student.liu.se Mon Jan 27 20:41:09 2003 From: otttr440 at student.liu.se (Otto Tronarp) Date: 28 Jan 2003 02:41:09 +0100 Subject: [SciPy-dev] Inconsisten return type from discrete dists. In-Reply-To: <01d901c2c656$aa404120$8901a8c0@ERICDESKTOP> References: <01d901c2c656$aa404120$8901a8c0@ERICDESKTOP> Message-ID: <1043718069.2021.11.camel@mathcore2> On Mon, 2003-01-27 at 23:51, eric jones wrote: > > > > Ona Sun, 2003-01-26 at 22:28, eric jones wrote: > > [snip] > > > I don't quite understand what you mean. (My English isn't the best..) > > Neither is mine, but I'm betting you have a better excuse than I > do...:-) > > > > Before it was like this: More than one of the discrete distributions > > returned floats (I did only test a couple of them) and at least one > > (randint) return integers. > > > > I want them all to return integers and that's what my patch is doing. > > That is what I would expect them to do, but maybe there are other > > applications where floats are more sensible that I don't see. > > I was thinking about continuous distributions also -- not just discrete > ones, so it was my misunderstanding. The behavior you are asking for > sounds right to me. > Ahh ok, then you're statement makes more sense to me. I see that travo (Travis?) already has checked in this in the cvs. > > > > If I understand you correctly you want to keep it like it was before, > > or? > > > > > > > > > > For the second issue I think that it is more convenient if they > always > > > > returns an array. I have no patch for that, but I can fix it if > that > > > is > > > > the consensus. > > > > > > Yes, this sounds appropriate. > > > > > > > Ok, I'll prepare a patch for this then. > > The tiny attached patch (randin_asarry.patch) fixes that, since randint seems to be the only one the deviates from that. I also attached the current state of my patch for the unit tests so you can have look at it. I won't have any time to continue working on it for the nearest weeks. They will probably fail for a lot of the distributions if you don't check in my patch that fixes the missing _check_shape in rv.py. They currently check that the result are of correct size, in the right domain, that it is ints and that they return an array even for size=1. I stayed consistent with neighbouring code for calling Numeric. Maybe when all the unit tests are in place some one could go over the code to stream line it to the recommended way. Regards, Otto -------------- next part -------------- A non-text attachment was scrubbed... Name: randint_asarry.patch Type: text/x-patch Size: 595 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: discrete_rsv_tests.patch Type: text/x-patch Size: 5990 bytes Desc: not available URL: From simon.saubern at molsci.csiro.au Wed Jan 29 20:34:11 2003 From: simon.saubern at molsci.csiro.au (Simon Saubern) Date: Thu, 30 Jan 2003 12:34:11 +1100 Subject: [SciPy-dev] cow: 'Connection reset by peer' timeout problem? Message-ID: I'm re-posting this message here as I didn't get any replies on the scipy-users list: I've been using cow to try out some distributed calculations. Everything works fine if I use a subset of my data, but when I use the full set I get "error: (10054, 'Connection reset by peer')" messages on the master unit (see below for full output). I can operate on larger and larger subsets until I get to the point where if the slaves take more than about 4 minutes to complete a task, the above error appears at the master. That is, connections are established (confirmed using netstat), processing occurs on the slaves and keeps going, but the master times out after about 4min. Is this a 'keep alive' problem? If so, how can I extend the time out period? The setup: 10 x slave + master, all Win2K SP-3 Python 2.2.2 latest scipy binary for Win cowname['data']=data # a list 35000 long. lendata=range(7000) # just use a subset bessy=None while not bessy: bessy=cowname.loop_code('do something;do something;calc=function(data[x])',loop_var='x',inputs={'x':lendata},returns=['calc']) bessy gets processed here 'data' is quite large and takes a while to transfer over the network. But by doing it once and looping over the index, I minimize network movements. The 'python' process on each slave uses about 85MB. Increasing 'lendata' eventually causes the 'Connection reset by peer' message to appear. Any pointers welcomed. ---------------error output File "C:\PROGRA~1\Python22\Lib\site-packages\scipy\cow\cow.py", line 823, in loop_code return self.loop_send_recv(package,loop_data,loop_var) File "C:\PROGRA~1\Python22\Lib\site-packages\scipy\cow\cow.py", line 847, in loop_send_recv results = self._send_recv(package,addendums) File "C:\PROGRA~1\Python22\Lib\site-packages\scipy\cow\cow.py", line 345, in _send_recv self.last_results = self._recv() File "C:\PROGRA~1\Python22\Lib\site-packages\scipy\cow\cow.py", line 303, in _recv results.append(worker.recv()) File "C:\PROGRA~1\Python22\Lib\site-packages\scipy\cow\sync_cluster.py", line 404, in recv package = self.channel.read() File "C:\PROGRA~1\Python22\Lib\site-packages\scipy\cow\sync_cluster.py", line 164, in read x = self.rfile.read() File "c:\Program Files\Python22\lib\socket.py", line 228, in read new = self._sock.recv(k) error: (10054, 'Connection reset by peer') >>> ------------ -- Cheers, Simon From roybryant at seventwentyfour.com Thu Jan 30 02:24:24 2003 From: roybryant at seventwentyfour.com (Roy at SEVENtwentyfour Inc.) Date: Thu, 30 Jan 2003 02:24:24 -0500 Subject: [SciPy-dev] Broken link in www.scipy.org Message-ID: <20030130074437.A67B53EB09@www.scipy.com> An embedded and charset-unspecified text was scrubbed... Name: not available URL: From sartout at math.u-strasbg.fr Thu Jan 30 05:15:54 2003 From: sartout at math.u-strasbg.fr (Alain Sartout) Date: Thu, 30 Jan 2003 11:15:54 +0100 (MET) Subject: [SciPy-dev] referenced symbol not found Message-ID: <200301301015.h0UAFsT25135@math.u-strasbg.fr> Hello, I have problems for a scipy installation on Sun solaris8. I have try a lot compilation for all software list (pyhon, lapack, atlas etc...) whith SunCC, gcc for different version of python etc... It never works! Here the output from python when I try to import scipy : ----------------------- irmasrv3 [290] > python Python 2.2.2 (#5, Jan 29 2003, 14:13:36) [GCC 3.2] on sunos5 Type "help", "copyright", "credits" or "license" for more information. >>> import scipy Traceback (most recent call last): File "", line 1, in ? File "/usr/local/lib/python2.2/site-packages/scipy/__init__.py", line 49, in ? import special, io, linalg, stats, fftpack File "/usr/local/lib/python2.2/site-packages/scipy/special/__init__.py", line 326, in ? from special import * File "/usr/local/lib/python2.2/site-packages/scipy/special/special.py", line 5, in ? from cephes import * ImportError: ld.so.1: python: fatal: relocation error: file /usr/local/lib/python2.2/site-packages/scipy/special/cephes.so: symbol __sincos: referenced symbol not found ----------------------- Here, somme informations about software versions : irmasrv3 [291] > python -c 'import os,sys;print os.name,sys.platform' posix sunos5 irmasrv3 [292] > uname -a SunOS irmasrv3 5.8 Generic_108528-12 sun4u sparc SUNW,Sun-Fire irmasrv3 [293] > gcc -v Reading specs from /usr/local/lib/gcc-lib/sparc-sun-solaris2.8/3.2/specs Configured with: ../configure --with-as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/ld --disable-nls Thread model: posix gcc version 3.2 irmasrv3 [294] > g77 --version GNU Fortran (GCC 3.2) 3.2 20020814 (release) Copyright (C) 2002 Free Software Foundation, Inc. irmasrv3 [295] > python -c 'import sys;print sys.version' 2.2.2 (#5, Jan 29 2003, 14:13:36) [GCC 3.2] irmasrv3 [296] > python -c 'import Numeric;print Numeric.__version__' 22.0 irmasrv3 [297] > f2py -v 2.32.225-1419 irmasrv3 [467] # cd /usr/local/lib/python2.2/site-packages/scipy/linalg irmasrv3 [468] # python setup_atlas_version.py build_ext --inplace --force atlas_info: FOUND: libraries = ['lapack', 'f77blas', 'cblas', 'atlas'] library_dirs = ['/usr/local/lib/atlas'] include_dirs = ['/usr/local/include'] running build_ext building 'atlas_version' extension creating build creating build/temp.solaris-2.8-sun4u-2.2 gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -I/usr/local/include/python2.2 -c /usr/local/lib/python2.2/site-packages/scipy/linalg/atlas_version.c -o build/temp.solaris-2.8-sun4u-2.2/atlas_version.o gcc: /usr/local/lib/python2.2/site-packages/scipy/linalg/atlas_version.c: No such file or directory gcc: no input files error: command 'gcc' failed with exit status 1 irmasrv3 [472] # python scipy_distutils/system_info.py atlas_info: FOUND: libraries = ['lapack', 'f77blas', 'cblas', 'atlas'] library_dirs = ['/usr/local/lib/atlas'] include_dirs = ['/usr/local/include'] blas_info: NOT AVAILABLE blas_src_info: NOT AVAILABLE dfftw_info: FOUND: libraries = ['drfftw', 'dfftw'] library_dirs = ['/usr/local/lib'] define_macros = [('SCIPY_DFFTW_H', None)] include_dirs = ['/usr/local/include'] dfftw_threads_info: FOUND: libraries = ['drfftw_threads', 'dfftw_threads'] library_dirs = ['/usr/local/lib'] define_macros = [('SCIPY_DFFTW_THREADS_H', None)] include_dirs = ['/usr/local/include'] djbfft_info: NOT AVAILABLE fftw_info: FOUND: libraries = ['fftw', 'rfftw'] library_dirs = ['/usr/local/lib'] define_macros = [('SCIPY_FFTW_H', None)] include_dirs = ['/usr/local/include'] fftw_threads_info: NOT AVAILABLE lapack_info: FOUND: libraries = ['lapack'] library_dirs = ['/usr/local/lib'] lapack_src_info: NOT AVAILABLE sfftw_info: NOT AVAILABLE sfftw_threads_info: NOT AVAILABLE x11_info: NOT AVAILABLE Thanks for your help Alain. ------Alain SARTOUT---------------------------------------------------------- office : IRMA - CNRS UMR 7501, 7 rue Rene Descartes F-67084 STRASBOURG phone : (33) [0]3 90 24 01 72 fax: (33) [0]3 90 24 03 28 e-mail : Alain.Sartout at math.u-strasbg.fr WWW : http://www-irma.u-strasbg.fr ----------------------------------------------------------------------------- From pearu at cens.ioc.ee Thu Jan 30 05:39:37 2003 From: pearu at cens.ioc.ee (Pearu Peterson) Date: Thu, 30 Jan 2003 12:39:37 +0200 (EET) Subject: [SciPy-dev] referenced symbol not found In-Reply-To: <200301301015.h0UAFsT25135@math.u-strasbg.fr> Message-ID: On Thu, 30 Jan 2003, Alain Sartout wrote: > Hello, > > I have problems for a scipy installation on Sun solaris8. I have try a lot > compilation for all software list (pyhon, lapack, atlas etc...) whith SunCC, gcc > for different version of python etc... It never works! Same here.. I am stuck with atlas when using gcc-2.95.3 compiler (I am getting /tmp/pp_atlas/bin/SunOS_Gnu2.95.3_SunUS2_2/ATLrun.sh \ /tmp/pp_atlas/tune/blas/gemm/SunOS_Gnu2.95.3_SunUS2_2 xdfc \ res/dNCNB20_1000 dNB=20, ld=1000,20,20, mu=2, nu=3, ku=12, lat=4: time=1.320, mflop=166.97 dNB=20, ld=1000,20,20, mu=2, nu=3, ku=12, lat=4: time=1.300, mflop=169.54 dNB=20, ld=1000,20,20, mu=2, nu=3, ku=12, lat=4: time=1.290, mflop=170.85 *** Signal 10 - core dumped when running 'make install arch=SunOS_Gnu2.95.3_SunUS2_2' but direct execution of /tmp/pp_atlas/bin/SunOS_Gnu2.95.3_SunUS2_2/ATLrun.sh \ /tmp/pp_atlas/tune/blas/gemm/SunOS_Gnu2.95.3_SunUS2_2 xdfc \ res/dNCNB20_1000 always succeeds. Any hints are appreciated about what could be going on here.). Could you share your experience with building atlas libraries on SunOS? The contents of ATLAS/Make. would be very helpful. > Here the output from python when I try to import scipy : > > ----------------------- > irmasrv3 [290] > python > Python 2.2.2 (#5, Jan 29 2003, 14:13:36) > [GCC 3.2] on sunos5 > Type "help", "copyright", "credits" or "license" for more information. > >>> import scipy > Traceback (most recent call last): > File "", line 1, in ? > File "/usr/local/lib/python2.2/site-packages/scipy/__init__.py", line 49, in ? > import special, io, linalg, stats, fftpack > File "/usr/local/lib/python2.2/site-packages/scipy/special/__init__.py", line > 326, in ? > from special import * > File "/usr/local/lib/python2.2/site-packages/scipy/special/special.py", line > 5, in ? > from cephes import * > ImportError: ld.so.1: python: fatal: relocation error: file > /usr/local/lib/python2.2/site-packages/scipy/special/cephes.so: symbol __sincos: > referenced symbol not found > ----------------------- Can you determine in which (system) library this symbol __sincos is defined? > irmasrv3 [467] # cd /usr/local/lib/python2.2/site-packages/scipy/linalg One should never try building python packages containing extension modules in their installation directories such as /usr/local/lib/python2.2/site-packages/... ! It will never work because sources are not installed. So, try cd cvs/scipy/linalg python setup_atlas_version.py build_ext --inplace --force instead. > irmasrv3 [468] # python setup_atlas_version.py build_ext --inplace --force > gcc: /usr/local/lib/python2.2/site-packages/scipy/linalg/atlas_version.c: No > such file or directory > gcc: no input files Can you import other extension modules? Try cd /usr/local/lib/python2.2/site-packages/scipy/ ls *.so and import any *.so modules that is listed directly to python. Pearu From sartout at math.u-strasbg.fr Thu Jan 30 07:52:49 2003 From: sartout at math.u-strasbg.fr (Alain Sartout) Date: Thu, 30 Jan 2003 13:52:49 +0100 (MET) Subject: [SciPy-dev] referenced symbol not found Message-ID: <200301301252.h0UCqnT12579@math.u-strasbg.fr> Hello Pearu, Thanks for help... > >Same here.. I am stuck with atlas when using gcc-2.95.3 compiler >(I am getting > >/tmp/pp_atlas/bin/SunOS_Gnu2.95.3_SunUS2_2/ATLrun.sh \ >/tmp/pp_atlas/tune/blas/gemm/SunOS_Gnu2.95.3_SunUS2_2 xdfc \ >res/dNCNB20_1000 >dNB=20, ld=1000,20,20, mu=2, nu=3, ku=12, lat=4: time=1.320, mflop=166.97 >dNB=20, ld=1000,20,20, mu=2, nu=3, ku=12, lat=4: time=1.300, mflop=169.54 >dNB=20, ld=1000,20,20, mu=2, nu=3, ku=12, lat=4: time=1.290, mflop=170.85 >*** Signal 10 - core dumped > >when running 'make install arch=SunOS_Gnu2.95.3_SunUS2_2' but >direct execution of > >/tmp/pp_atlas/bin/SunOS_Gnu2.95.3_SunUS2_2/ATLrun.sh \ >/tmp/pp_atlas/tune/blas/gemm/SunOS_Gnu2.95.3_SunUS2_2 xdfc \ >res/dNCNB20_1000 > >always succeeds. Any hints are appreciated about what could be >going on here.). > >Could you share your experience with building atlas libraries on SunOS? >The contents of ATLAS/Make. would be very helpful. trace running : ./ATLrun.sh /src/solaris8/ATLAS/tune/blas/gemm/SunOS_UNKNOWN_12/xdfc dNB=60, ld=24,24,60, mu=5, nu=3, ku=24, lat=5: time=0.830, mflop=1219.80 dNB=60, ld=24,24,60, mu=5, nu=3, ku=24, lat=5: time=0.830, mflop=1219.80 dNB=60, ld=24,24,60, mu=5, nu=3, ku=24, lat=5: time=0.820, mflop=1234.68 You will find in attachement Make.SunOS_UNKNOW_12 ATLAS was compiled using both gcc ans SUN forte6 suite (SUN CC and F77) >Can you determine in which (system) library this symbol __sincos is >defined? No...! >One should never try building python packages containing extension >modules in their installation directories such as > /usr/local/lib/python2.2/site-packages/... >! It will never work because sources are not installed. >So, try > > cd cvs/scipy/linalg > python setup_atlas_version.py build_ext --inplace --force trying that in source dir : python setup_atlas_version.py build_ext --inplace --force atlas_info: FOUND: libraries = ['lapack', 'f77blas', 'cblas', 'atlas'] library_dirs = ['/usr/local/lib/atlas'] include_dirs = ['/usr/local/include'] running build_ext building 'atlas_version' extension gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -I/usr/local/include/python2.2 -c /src/solaris8/SciPy-0.2.0_alpha_144.4350/linalg/atlas_version.c -o build/temp.solaris-2.8-sun4u-2.2/atlas_version.o gcc: /src/solaris8/SciPy-0.2.0_alpha_144.4350/linalg/atlas_version.c: No such file or directory gcc: no input files error: command 'gcc' failed with exit status 1 >Can you import other extension modules? Try > > cd /usr/local/lib/python2.2/site-packages/scipy/ > ls *.so > for example "import clapack" in linalg module works (or Numeric also...) imports are OK Alain. ------Alain SARTOUT---------------------------------------------------------- office : IRMA - CNRS UMR 7501, 7 rue Rene Descartes F-67084 STRASBOURG phone : (33) [0]3 90 24 01 72 fax: (33) [0]3 90 24 03 28 e-mail : Alain.Sartout at math.u-strasbg.fr WWW : http://www-irma.u-strasbg.fr ----------------------------------------------------------------------------- -------------- next part -------------- # ---------------------------------- # Make sure we get the correct shell # ---------------------------------- SHELL = /bin/sh # ------------------------------------------------- # Name indicating the platform to configure BLAS to # ------------------------------------------------- ARCH = SunOS_UNKNOWN_12 # ------------------- # Various directories # ------------------- TOPdir = /src/solaris8/ATLAS INCdir = $(TOPdir)/include/$(ARCH) SYSdir = $(TOPdir)/tune/sysinfo/$(ARCH) GMMdir = $(TOPdir)/src/blas/gemm/$(ARCH) UMMdir = $(GMMdir) GMVdir = $(TOPdir)/src/blas/gemv/$(ARCH) GR1dir = $(TOPdir)/src/blas/ger/$(ARCH) L1Bdir = $(TOPdir)/src/blas/level1/$(ARCH) L2Bdir = $(TOPdir)/src/blas/level2/$(ARCH) L3Bdir = $(TOPdir)/src/blas/level3/$(ARCH) TSTdir = $(TOPdir)/src/testing/$(ARCH) AUXdir = $(TOPdir)/src/auxil/$(ARCH) CBLdir = $(TOPdir)/interfaces/blas/C/src/$(ARCH) FBLdir = $(TOPdir)/interfaces/blas/F77/src/$(ARCH) BINdir = $(TOPdir)/bin/$(ARCH) LIBdir = $(TOPdir)/lib/$(ARCH) PTSdir = $(TOPdir)/src/pthreads MMTdir = $(TOPdir)/tune/blas/gemm/$(ARCH) MVTdir = $(TOPdir)/tune/blas/gemv/$(ARCH) R1Tdir = $(TOPdir)/tune/blas/ger/$(ARCH) L1Tdir = $(TOPdir)/tune/blas/level1/$(ARCH) L3Tdir = $(TOPdir)/tune/blas/level3/$(ARCH) # --------------------------------------------------------------------- # Name and location of scripts for running executables during tuning # --------------------------------------------------------------------- ATLRUN = $(BINdir)/ATLrun.sh ATLFWAIT = $(BINdir)/xatlas_waitfile # --------------------- # Libraries to be built # --------------------- ATLASlib = $(LIBdir)/libatlas.a CBLASlib = $(LIBdir)/libcblas.a F77BLASlib = $(LIBdir)/libf77blas.a PTCBLASlib = $(LIBdir)/libptcblas.a PTF77BLASlib = $(LIBdir)/libptf77blas.a LAPACKlib = $(LIBdir)/liblapack.a TESTlib = $(LIBdir)/libtstatlas.a # ------------------------------------------- # Upper bound on largest cache size, in bytes # ------------------------------------------- L2SIZE = -DL2SIZE=4194304 # --------------------------------------- # Command setting up correct include path # --------------------------------------- INCLUDES = -I$(TOPdir)/include -I$(TOPdir)/include/$(ARCH) \ -I$(TOPdir)/include/contrib # ------------------------------------------- # Defines for setting up F77/C interoperation # ------------------------------------------- F2CDEFS = # -------------------------------------- # Special defines for user-supplied GEMM # -------------------------------------- UMMDEFS = # ------------------------------ # Architecture identifying flags # ------------------------------ ARCHDEFS = -DATL_OS_SunOS # ------------------------------------------------------------------- # NM is the flag required to name a compiled object/executable # OJ is the flag required to compile to object rather than executable # These flags are used by all compilers. # ------------------------------------------------------------------- NM = -o OJ = -c # --------------------------------------------------------------------------- # Fortran 77 compiler and the flags to use. Presently, ATLAS does not itself # use any Fortran 77, but vendor BLAS are typically written for Fortran, so # any links that include non-ATLAS BLAS will use FLINKER instead of CLINKER # --------------------------------------------------------------------------- F77 = /opt/SUNWspro/bin/f77 F77FLAGS = -dalign -native -xO5 -mt FLINKER = $(F77) FLINKFLAGS = $(F77FLAGS) FCLINKFLAGS = $(FLINKFLAGS) # --------------------------------------------------------------------------- # Various C compilers, and the linker to be used when we are not linking in # non-ATLAS BLAS (which usually necessitate using the Fortran linker). # The C compilers recognized by ATLAS are: # CC : Compiler to use to compile regular, non-generated code # MCC : Compiler to use to compile generated, highly-optimized code # XCC : Compiler to be used on the compile engine of a cross-compiler # These will typically all be the same. An example of where this is not # the case would be DEC ALPHA 21164, where you want to use gcc for MCC, # because DEC's cc does not allow the programmer access to all 32 floating # point registers. However, on normal C code, DEC's cc produces much faster # code than gcc, so you CC set to cc. Of course, any system where you are # cross-compiling, you will need to set XCC differently than CC & MCC. # --------------------------------------------------------------------------- CDEFS = $(L2SIZE) $(INCLUDES) $(F2CDEFS) $(ARCHDEFS) -DATL_NCPU=12 GOODGCC = /usr/local/bin/gcc CC = /opt/SUNWspro/bin/cc CCFLAG0 = -dalign -fsingle -xO5 -native -mt CCFLAGS = $(CDEFS) $(CCFLAG0) MCC = /opt/SUNWspro/bin/cc MMFLAGS = -dalign -fsingle -xO2 -native -mt XCC = /opt/SUNWspro/bin/cc XCCFLAGS = $(CDEFS) -dalign -fsingle -xO5 -native -mt CLINKER = $(CC) CLINKFLAGS = $(CCFLAGS) BC = $(CC) BCFLAGS = $(CCFLAGS) ARCHIVER = ar ARFLAGS = r RANLIB = echo # ------------------------------------- # tar, gzip, gunzip, and parallel make # ------------------------------------- TAR = /usr/bin/tar GZIP = /usr/bin/gzip GUNZIP = /usr/bin/gunzip PMAKE = $(MAKE) # ------------------------------------ # Reference and system libraries # ------------------------------------ BLASlib = -xlic_lib=sunperf FBLASlib = FLAPACKlib = LIBS = -lpthread -lm # ---------------------------------------------------------- # ATLAS install resources (include arch default directories) # ---------------------------------------------------------- ARCHDEF = MMDEF = INSTFLAGS = # --------------------------------------- # Generic targets needed by all makefiles # --------------------------------------- waitfile: