From james2000 at etang.com Sun Sep 1 10:31:32 2002 From: james2000 at etang.com (james2000 at etang.com) Date: Sun, 1 Sep 2002 22:31:32 +0800 Subject: [SciPy-dev] ADV: Harvest lots of E-mail addresses quickly ! Message-ID: <20020901143942.60A5C3EAD3@www.scipy.com> An HTML attachment was scrubbed... URL: From cjf at fonnesbeck.net Sun Sep 1 11:36:21 2002 From: cjf at fonnesbeck.net (Christopher Fonnesbeck) Date: 01 Sep 2002 11:36:21 -0400 Subject: [SciPy-dev] undefined symbol: clapack_sgesv Message-ID: <1030894581.1749.4.camel@dirichlet.forestry.uga.edu> I saw some postings back in april related to getting a message similar to the following: >>> import scipy exceptions.ImportError: /usr/lib/python2.2/site-packages/scipy/linalg/clapack.so: undefined symbol: clapack_sgesv This, despite the fact that clapack_sgesv is defined. Has there been any progress solving this bug? I compiles scipy (including ATLAS) on a RH machine using gcc3.2. cjf -- Christopher J. Fonnesbeck Georgia Cooperative Fish & Wildlife Research Unit University of Georgia Athens, GA 30602 cjf {at} fonnesbeck.net Absent, adj.: Exposed to the attacks of friends and acquaintances; defamed; slandered. From pearu at cens.ioc.ee Sun Sep 1 12:52:05 2002 From: pearu at cens.ioc.ee (Pearu Peterson) Date: Sun, 1 Sep 2002 19:52:05 +0300 (EEST) Subject: [SciPy-dev] undefined symbol: clapack_sgesv In-Reply-To: <1030894581.1749.4.camel@dirichlet.forestry.uga.edu> Message-ID: On 1 Sep 2002, Christopher Fonnesbeck wrote: > I saw some postings back in april related to getting a message similar > to the following: > > >>> import scipy > exceptions.ImportError: > /usr/lib/python2.2/site-packages/scipy/linalg/clapack.so: undefined > symbol: clapack_sgesv > > This, despite the fact that clapack_sgesv is defined. Has there been > any progress solving this bug? I compiles scipy (including ATLAS) on a > RH machine using gcc3.2. What is the output of python scipy_distutils/system_info.py ? What SciPy version are you using? The error that you get is related to Eric's findings in http://www.scipy.org/site_content/remap?rmurl=http%3A//66.106.86.196/pipermail/scipy-dev/2002-April/000836.html However, with the latest SciPy from CVS this issue should be resolved automatically. If you are using it already then please submit full bug report (see at the end of scipy/INSTALL.txt for details). Pearu From cjf at fonnesbeck.net Sun Sep 1 14:28:56 2002 From: cjf at fonnesbeck.net (Christopher Fonnesbeck) Date: 01 Sep 2002 14:28:56 -0400 Subject: [SciPy-dev] undefined symbol: clapack_sgesv In-Reply-To: References: Message-ID: <1030904936.1885.0.camel@dirichlet.forestry.uga.edu> I'm using scipy 0.2 ... never tried the cvs version, but perhaps I should. Thanks, cjf On Sun, 2002-09-01 at 12:52, Pearu Peterson wrote: > > On 1 Sep 2002, Christopher Fonnesbeck wrote: > > > I saw some postings back in april related to getting a message similar > > to the following: > > > > >>> import scipy > > exceptions.ImportError: > > /usr/lib/python2.2/site-packages/scipy/linalg/clapack.so: undefined > > symbol: clapack_sgesv > > > > This, despite the fact that clapack_sgesv is defined. Has there been > > any progress solving this bug? I compiles scipy (including ATLAS) on a > > RH machine using gcc3.2. > > What is the output of > python scipy_distutils/system_info.py > ? > What SciPy version are you using? > > The error that you get is related to Eric's findings in > > http://www.scipy.org/site_content/remap?rmurl=http%3A//66.106.86.196/pipermail/scipy-dev/2002-April/000836.html > > However, with the latest SciPy from CVS this issue should be resolved > automatically. If you are using it already then please submit full bug > report (see at the end of scipy/INSTALL.txt for details). > > Pearu > > _______________________________________________ > Scipy-dev mailing list > Scipy-dev at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-dev > -- Christopher J. Fonnesbeck Georgia Cooperative Fish & Wildlife Research Unit University of Georgia Athens, GA 30602 cjf {at} fonnesbeck.net Absent, adj.: Exposed to the attacks of friends and acquaintances; defamed; slandered. From cjf at fonnesbeck.net Sun Sep 1 16:18:54 2002 From: cjf at fonnesbeck.net (Christopher Fonnesbeck) Date: 01 Sep 2002 16:18:54 -0400 Subject: [SciPy-dev] implicit typename warnings in weave Message-ID: <1030911534.1213.5.camel@dirichlet.forestry.uga.edu> I am now having problems with weave (0.2.3). Though the install of the package goes smoothly, the tests fail miserably, with the error messages punctuated with "implicit typename is deprecated" warnings. I am using gcc 3.2 nowadays, so I wonder if this could be related? A typical selection of errors looks as follows: /usr/include/c++/3.2/backward/backward_warning.h:32:2: warning: #warning This file includes at least one deprecated or antiquated header. Please consider using one of the 32 headers found in section 17.4.1.2 of the C++ standard. Examples include substituting the header for the header for C++ includes, or instead of the deprecated header . To disable this warning use -Wno-deprecated. In file included from /tmp/test_files/sc_058975d6fda30b79a63e0e6ecfeb90e60.cpp:5: /usr/share/downloads/weave-0.2.3/weave/CXX/Objects.hxx:1143: no class template named `random_access_iterator' in `std' /usr/share/downloads/weave-0.2.3/weave/CXX/Objects.hxx:1279: no class template named `random_access_iterator' in `std' /usr/share/downloads/weave-0.2.3/weave/CXX/Objects.hxx:1409: warning: `typename Py::SeqBase::iterator' is implicitly a typename /usr/share/downloads/weave-0.2.3/weave/CXX/Objects.hxx:1409: warning: implicit typename is deprecated, please see the documentation for details /usr/share/downloads/weave-0.2.3/weave/CXX/Objects.hxx:1409: warning: `typename Py::SeqBase::iterator' is implicitly a typename /usr/share/downloads/weave-0.2.3/weave/CXX/Objects.hxx:1409: warning: implicit typename is deprecated, please see the documentation for details /usr/share/downloads/weave-0.2.3/weave/CXX/Objects.hxx:1410: warning: `typename Py::SeqBase::iterator' is implicitly a typename /usr/share/downloads/weave-0.2.3/weave/CXX/Objects.hxx:1410: warning: implicit typename is deprecated, please see the documentation for details /usr/share/downloads/weave-0.2.3/weave/CXX/Objects.hxx:1410: warning: `typename Py::SeqBase::iterator' is implicitly a typename etc. Anyone had similar problems? cjf -- Christopher J. Fonnesbeck Georgia Cooperative Fish & Wildlife Research Unit University of Georgia Athens, GA 30602 cjf {at} fonnesbeck.net Absent, adj.: Exposed to the attacks of friends and acquaintances; defamed; slandered. From pearu at cens.ioc.ee Sun Sep 1 16:39:47 2002 From: pearu at cens.ioc.ee (Pearu Peterson) Date: Sun, 1 Sep 2002 23:39:47 +0300 (EEST) Subject: [SciPy-dev] implicit typename warnings in weave In-Reply-To: <1030911534.1213.5.camel@dirichlet.forestry.uga.edu> Message-ID: On 1 Sep 2002, Christopher Fonnesbeck wrote: > I am now having problems with weave (0.2.3). Though the install of the > package goes smoothly, the tests fail miserably, with the error messages > punctuated with "implicit typename is deprecated" warnings. I am using > gcc 3.2 nowadays, so I wonder if this could be related? A typical > selection of errors looks as follows: > Anyone had similar problems? Yes. See the thread http://www.scipy.org/site_content/mailman?fn=scipy-user/2002-August/000607.html I am guessing that the weave will not by usable with gcc 3.x at least for the next few weeks. Pearu From steven.robbins at videotron.ca Sun Sep 1 16:42:31 2002 From: steven.robbins at videotron.ca (Steve M. Robbins) Date: Sun, 01 Sep 2002 16:42:31 -0400 Subject: [SciPy-dev] implicit typename warnings in weave In-Reply-To: <1030911534.1213.5.camel@dirichlet.forestry.uga.edu> References: <1030911534.1213.5.camel@dirichlet.forestry.uga.edu> Message-ID: <20020901204230.GN4580@nyongwa.montreal.qc.ca> On Sun, Sep 01, 2002 at 04:18:54PM -0400, Christopher Fonnesbeck wrote: > I am now having problems with weave (0.2.3). Though the install of the > package goes smoothly, the tests fail miserably, with the error messages > punctuated with "implicit typename is deprecated" warnings. I am using > gcc 3.2 nowadays, so I wonder if this could be related? Yes, they are related. I had similar problems last week http://www.scipy.org/site_content/mailman?fn=scipy-user/2002-August/000607.html I haven't completely resolved this -- for the moment, I gave up and went back to GCC 2.95 -- but I did manage to get rid of many errors. Here are the changes (relative to CVS, but probably applicable to 0.2.3). Cheers, -Steve Index: weave/CXX/Objects.hxx =================================================================== RCS file: /home/cvsroot/world/scipy/weave/CXX/Objects.hxx,v retrieving revision 1.5 diff -u -b -B -r1.5 Objects.hxx --- weave/CXX/Objects.hxx 17 Jan 2002 18:28:41 -0000 1.5 +++ weave/CXX/Objects.hxx 1 Sep 2002 20:43:04 -0000 @@ -1406,19 +1406,19 @@ // Here's an important typedef you might miss if reading too fast... typedef SeqBase Sequence; - template bool operator==(const SeqBase::iterator& left, const SeqBase::iterator& right); - template bool operator!=(const SeqBase::iterator& left, const SeqBase::iterator& right); - template bool operator< (const SeqBase::iterator& left, const SeqBase::iterator& right); - template bool operator> (const SeqBase::iterator& left, const SeqBase::iterator& right); - template bool operator<=(const SeqBase::iterator& left, const SeqBase::iterator& right); - template bool operator>=(const SeqBase::iterator& left, const SeqBase::iterator& right); - - template bool operator==(const SeqBase::const_iterator& left, const SeqBase::const_iterator& right); - template bool operator!=(const SeqBase::const_iterator& left, const SeqBase::const_iterator& right); - template bool operator< (const SeqBase::const_iterator& left, const SeqBase::const_iterator& right); - template bool operator> (const SeqBase::const_iterator& left, const SeqBase::const_iterator& right); - template bool operator<=(const SeqBase::const_iterator& left, const SeqBase::const_iterator& right); - template bool operator>=(const SeqBase::const_iterator& left, const SeqBase::const_iterator& right); + template bool operator==(const typename SeqBase::iterator& left, const typename SeqBase::iterator& right); + template bool operator!=(const typename SeqBase::iterator& left, const typename SeqBase::iterator& right); + template bool operator< (const typename SeqBase::iterator& left, const typename SeqBase::iterator& right); + template bool operator> (const typename SeqBase::iterator& left, const typename SeqBase::iterator& right); + template bool operator<=(const typename SeqBase::iterator& left, const typename SeqBase::iterator& right); + template bool operator>=(const typename SeqBase::iterator& left, const typename SeqBase::iterator& right); + + template bool operator==(const typename SeqBase::const_iterator& left, const typename SeqBase::const_iterator& right); + template bool operator!=(const typename SeqBase::const_iterator& left, const typename SeqBase::const_iterator& right); + template bool operator< (const typename SeqBase::const_iterator& left, const typename SeqBase::const_iterator& right); + template bool operator> (const typename SeqBase::const_iterator& left, const typename SeqBase::const_iterator& right); + template bool operator<=(const typename SeqBase::const_iterator& left, const typename SeqBase::const_iterator& right); + template bool operator>=(const typename SeqBase::const_iterator& left, const typename SeqBase::const_iterator& right); extern bool operator==(const Sequence::iterator& left, const Sequence::iterator& right); @@ -2345,10 +2345,10 @@ typedef MapBase Mapping; - template bool operator==(const MapBase::iterator& left, const MapBase::iterator& right); - template bool operator!=(const MapBase::iterator& left, const MapBase::iterator& right); - template bool operator==(const MapBase::const_iterator& left, const MapBase::const_iterator& right); - template bool operator!=(const MapBase::const_iterator& left, const MapBase::const_iterator& right); + template bool operator==(const typename MapBase::iterator& left, const typename MapBase::iterator& right); + template bool operator!=(const typename MapBase::iterator& left, const typename MapBase::iterator& right); + template bool operator==(const typename MapBase::const_iterator& left, const typename MapBase::const_iterator& right); + template bool operator!=(const typename MapBase::const_iterator& left, const typename MapBase::const_iterator& right); extern bool operator==(const Mapping::iterator& left, const Mapping::iterator& right); extern bool operator!=(const Mapping::iterator& left, const Mapping::iterator& right); From jingw51 at hotmail.com Mon Sep 2 10:05:31 2002 From: jingw51 at hotmail.com (wu jing) Date: Mon, 02 Sep 2002 22:05:31 +0800 Subject: [SciPy-dev] (no subject) Message-ID: An HTML attachment was scrubbed... URL: From cjf at fonnesbeck.net Tue Sep 3 09:10:49 2002 From: cjf at fonnesbeck.net (Christopher Fonnesbeck) Date: 03 Sep 2002 09:10:49 -0400 Subject: [SciPy-dev] special.cdflib questions Message-ID: <1031013643.4203.5.camel@dirichlet.forestry.uga.edu> I am curious about the cdflib fortran modules in the special subdirectory of scipy: Why are there so many arguments for each distribution? For example, if I want to call cdfbin to calculate a parameter of a binomial distribution, I should not need to supply BOTH p and q=1-p ... also, the status and bound arguments seem like something you would have returned to you, rather than passed to the function. How would I know the status of the calculation before its calculated? Finally, none of the cdf's seem to return any values, despite what the inline comments say. I am obviously way confused about this code, so I am hoping someone out there can set me straight. Thanks, cjf -- Christopher J. Fonnesbeck Georgia Cooperative Fish & Wildlife Research Unit University of Georgia Athens, GA 30602 cjf {at} fonnesbeck.net Absent, adj.: Exposed to the attacks of friends and acquaintances; defamed; slandered. From oliphant at ee.byu.edu Tue Sep 3 12:17:13 2002 From: oliphant at ee.byu.edu (Travis Oliphant) Date: Tue, 3 Sep 2002 10:17:13 -0600 (MDT) Subject: [SciPy-dev] special.cdflib questions In-Reply-To: <1031013643.4203.5.camel@dirichlet.forestry.uga.edu> Message-ID: > I am curious about the cdflib fortran modules in the special > subdirectory of scipy: Why are there so many arguments for each > distribution? For example, if I want to call cdfbin to calculate a > parameter of a binomial distribution, I should not need to supply BOTH p > and q=1-p ... also, the status and bound arguments seem like something > you would have returned to you, rather than passed to the function. How > would I know the status of the calculation before its calculated? > Finally, none of the cdf's seem to return any values, despite what the > inline comments say. I am obviously way confused about this code, so I > am hoping someone out there can set me straight. > First, if you are interested in the cdflib library itself it is available on the net. It is not SciPy-written code. We have a particular interface to the cdflib library tailored for SciPy. Is there a particular reason you need to use the fortran interface? Most of the cdflib functions are written as subroutines where you can obtain any of the arguments given all the other arguments. Thus, for example, the same subroutine is used to calculate the cdf and the inverse of the cdf. Good luck, -Travis From cjf at fonnesbeck.net Tue Sep 3 15:05:23 2002 From: cjf at fonnesbeck.net (Christopher Fonnesbeck) Date: 03 Sep 2002 15:05:23 -0400 Subject: [SciPy-dev] special.cdflib questions In-Reply-To: References: Message-ID: <1031079923.7032.5.camel@dirichlet.forestry.uga.edu> Thanks for the reply, I was looking to use that code from python to generate rv's, but without the rest of Scipy (havent been able to get the whole thing to work). I have successfully compiled them with f2py, but was confused about the arguments. It seems to want ALL of the arguments, as well as seemingly redundant ones (e.g. q=1-p as well as p), and doesnt return values. This is what has me confused. Thanks, chris On Tue, 2002-09-03 at 12:17, Travis Oliphant wrote: > > > I am curious about the cdflib fortran modules in the special > > subdirectory of scipy: Why are there so many arguments for each > > distribution? For example, if I want to call cdfbin to calculate a > > parameter of a binomial distribution, I should not need to supply BOTH p > > and q=1-p ... also, the status and bound arguments seem like something > > you would have returned to you, rather than passed to the function. How > > would I know the status of the calculation before its calculated? > > Finally, none of the cdf's seem to return any values, despite what the > > inline comments say. I am obviously way confused about this code, so I > > am hoping someone out there can set me straight. > > > > First, if you are interested in the cdflib library itself it is available > on the net. It is not SciPy-written code. We have a particular interface > to the cdflib library tailored for SciPy. > > Is there a particular reason you need to use the fortran interface? > > > Most of the cdflib functions are written as subroutines where you can > obtain any of the arguments given all the other arguments. Thus, for > example, the same subroutine is used to calculate the cdf and the inverse > of the cdf. > > Good luck, > > -Travis > > _______________________________________________ > Scipy-dev mailing list > Scipy-dev at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-dev > -- Christopher J. Fonnesbeck Georgia Cooperative Fish & Wildlife Research Unit University of Georgia Athens, GA 30602 cjf {at} fonnesbeck.net Absent, adj.: Exposed to the attacks of friends and acquaintances; defamed; slandered. From oliphant at ee.byu.edu Tue Sep 3 18:28:19 2002 From: oliphant at ee.byu.edu (Travis Oliphant) Date: Tue, 3 Sep 2002 16:28:19 -0600 (MDT) Subject: [SciPy-dev] special.cdflib questions In-Reply-To: <1031079923.7032.5.camel@dirichlet.forestry.uga.edu> Message-ID: > Thanks for the reply, > > I was looking to use that code from python to generate rv's, but without > the rest of Scipy (havent been able to get the whole thing to work). I > have successfully compiled them with f2py, but was confused about the > arguments. It seems to want ALL of the arguments, as well as seemingly > redundant ones (e.g. q=1-p as well as p), and doesnt return values. > This is what has me confused. I see, It is a little confusing. I guess it was done that way so that you could get out any argument given the rest of them as inputs. I think this was more common with Fortran some years ago. The redundant ones are there so that you could solve for them (using perhaps a different algorithm) if they weren't supplied. Good luck, -Travis From skip at pobox.com Wed Sep 4 17:05:03 2002 From: skip at pobox.com (Skip Montanaro) Date: Wed, 4 Sep 2002 16:05:03 -0500 Subject: [SciPy-dev] cluster/src/vq_wrap.cpp not being compiled with C++ Message-ID: <15734.30079.263927.777968@12-248-11-90.client.attbi.com> I'm trying to build SciPy on a Solaris system (sunos 5.8) using Sun's C, C++ and Fortran compilers. I've fiddled and faddled 'til it got down to compiling .../scipy/cluster. It goes to compile the vq_wrap.cpp file and tries compiling it with 'cc' instead of 'CC'. Distutils generates this command: cc -DNDEBUG -O -I/home/skip/local/SunOS/include/python2.2 -c cluster/src/vq_wrap.cpp -o build/temp.solaris-2.8-sun4u-2.2/vq_wrap.o which generates this message: cc: No input file specified, no output generated If I simply change 'cc' to 'CC' it compiles fine. I would have thought distutils would recognize the need to use 'CC' if the file extension was '.cpp'. If I try running python setup.py build_ext --compiler=CC distutils raises a PlatformError: don't know how to compile C/C++ code on platform 'posix' with 'CC' compiler I don't see anything like a command/build_cpplib.py file which might tell how to build C++ extensions. Where should I be looking for clues? Thx, -- Skip Montanaro skip at pobox.com From pearu at cens.ioc.ee Wed Sep 4 17:25:54 2002 From: pearu at cens.ioc.ee (Pearu Peterson) Date: Thu, 5 Sep 2002 00:25:54 +0300 (EEST) Subject: [SciPy-dev] cluster/src/vq_wrap.cpp not being compiled with C++ In-Reply-To: <15734.30079.263927.777968@12-248-11-90.client.attbi.com> Message-ID: On Wed, 4 Sep 2002, Skip Montanaro wrote: > I'm trying to build SciPy on a Solaris system (sunos 5.8) using Sun's C, C++ > and Fortran compilers. I've fiddled and faddled 'til it got down to > compiling .../scipy/cluster. It goes to compile the vq_wrap.cpp file and > tries compiling it with 'cc' instead of 'CC'. Distutils generates this > command: > > cc -DNDEBUG -O -I/home/skip/local/SunOS/include/python2.2 -c > cluster/src/vq_wrap.cpp -o build/temp.solaris-2.8-sun4u-2.2/vq_wrap.o > > which generates this message: > > cc: No input file specified, no output generated > > If I simply change 'cc' to 'CC' it compiles fine. I would have thought > distutils would recognize the need to use 'CC' if the file extension was > '.cpp'. If I try running > > python setup.py build_ext --compiler=CC > > distutils raises a PlatformError: > > don't know how to compile C/C++ code on platform 'posix' with 'CC' > compiler > > I don't see anything like a command/build_cpplib.py file which might tell > how to build C++ extensions. > > Where should I be looking for clues? This is a known problem with distutils that for compiling C++ extensions certain hacks are needed. Here are some solutions that people have suggested: 1) Build Python with C++ compiler 2) Edit python2.2/config/Makefile by changing CC variable and do something with libpython2.2.a --- what exactly, I don't remember now, but I think it is described in wxPython installation notes. 3) I use the following codelet in my C++ extension setup.py files that you could modify to your needs easily: #+++HACK: replace linker gcc with g++ +++++++++++ gpp_exe = 'g++' gcc_exe = 'gcc' from distutils import sysconfig save_init_posix = sysconfig._init_posix def my_init_posix(): save_init_posix() g = sysconfig._config_vars for n,r in [('LDSHARED',gpp_exe),('CC',gcc_exe)]: if g[n][:3]=='gcc': print 'my_init_posix: changing %s = %r'%(n,g[n]), g[n] = r+g[n][3:] print 'to',`g[n]` sysconfig._init_posix = my_init_posix #++++++++++++++++++++++++++++++++++++++++++++++++ I like this hack because one does not need to mess with Python defaults that would be not always desired or possible. HTH, Pearu From Marketinges at eyou.com Sat Sep 7 01:32:24 2002 From: Marketinges at eyou.com (Mailserver) Date: Sat, 7 Sep 2002 13:32:24 +0800 Subject: [SciPy-dev] Emissionsreport Message-ID: <20020907054037.6BC163EACE@www.scipy.com> An HTML attachment was scrubbed... URL: From lmk2g at mail.com Sat Sep 7 10:23:45 2002 From: lmk2g at mail.com (LAURENT MPETI KABILA) Date: Sat, 7 Sep 2002 16:23:45 +0200 Subject: [SciPy-dev] please kindly get back to me Message-ID: <20020907143203.39E7D3EACE@www.scipy.com> REQUEST FOR URGENT BUSINESS ASSISTANCE -------------------------------------- Your contact was availed to me by the chamber of commerce. It was given to me because of my diplomatic status as I did not disclose the actual reasons for which I sought your contact. But I was assured That you are reputable and trustworthy if you will be of assistance. I am Laurent Mpeti Kabila (Jnr) the second son of Late President LAURENT DESIRE KABILA the immediate Past president of the DEMOCRATIC REPUBLIC OF CONGO in Africa who was murdered by his opposition through his personal bodyguards in his bedroom on Tuesday 16th January, 2001. I have the privilege of being mandated by my father colleagues to seek your immediate and urgent co-operation to receive into your bank account the sum of US $25m.(twenty-five million Dollars) and some thousands carats of Diamond. This money and treasures was lodged in a vault with a security firm in Europe and South-Africa. SOURCES OF DIAMONDS AND FUND In August 2000, my father as a defence minister and president has a meeting with his cabinet and armychief about the defence budget for 2000 to 2001 which was US $700m. so he directed one of his best friend. Frederic Kibasa Maliba who was a minister of mines and a political party leader known as the Union Sacree de, I opposition radicale et ses allies (USORAL) to buy arms with US $200m on 5th January 2001; for him to finalized the arms deal, my father was murdered. f.K. Maliba (FKM) and I have decided to keep the money with a foreigner after which he will use it to contest for the political election. Inspite of all this we have resolved to present your or your company for the firm to pay it into your nominated account the above sum and diamonds. This transaction should be finalized within seven (7) working days and for your co-operation and partnership, we have unanimously agreed that you will be entitled to 5.5% of the money when successfully receive it in your account. The nature of your business is not relevant to the successful execution of this transaction what we require is your total co-operation and commitment to ensure 100% risk-free transaction at both ends and to protect the persons involved in this transaction, strict confidence and utmost secrecy is required even after the successful conclusion of this transaction. If this proposal is acceptable to you, kindly provide me with your personal telephone and fax through my E-mail box for immediate commencement of the transaction. All correspondence is for the attention of my counsel:cliff roberts, I count on your honour to keep my secret, SECRET. Looking forward for your urgent reply Thanks. Best Regards MPETI L. KABILA (Jnr) From skip at pobox.com Wed Sep 11 16:11:57 2002 From: skip at pobox.com (Skip Montanaro) Date: Wed, 11 Sep 2002 15:11:57 -0500 Subject: [SciPy-dev] test error on Solaris using Sun's compilers Message-ID: <15743.41869.430994.232264@12-248-11-90.client.attbi.com> I installed SciPy on a Solaris machine using Sun's C and Fortran compilers (hint for the unwary: this was *not* a straightforward exercise). During the test run I got a single failure (this is reproducible, not an anomaly due to different random inputs): FAIL: check_basic (test_morestats.test_shapiro) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/skip/local/SunOS/lib/python2.2/site-packages/scipy/stats/tests/test_morestats.py", line 30, in check_basic assert_almost_equal(w,0.90047299861907959,8) File "/home/skip/local/SunOS/lib/python2.2/site-packages/scipy_base/testing.py", line 283, in assert_almost_equal assert round(abs(desired - actual),decimal) == 0, msg AssertionError: Items are not equal: DESIRED: 0.900472998619 ACTUAL: 0.900472760201 After a little bit of debugging, I concluded the problem is most likely in the Fortran code. Using the first input list in the test: x1 = [0.11,7.87,4.61,10.14,7.95,3.14,0.46, 4.43,0.21,4.75,0.71,1.52,3.24, 0.93,0.42,4.97,9.53,4.55,0.47,6.66] I manually executed the code in scipy.stats.morestats.shapiro, and got different results from the statlib.swilk call. On the Sun I got: >>> scipy.stats.statlib.swilk(y,a[:N/2],init) (array([ 0.47337097, 0.32174039, 0.25566325, 0.20829722, 0.16863985, 0.13358422, 0.10147439, 0.07128929, 0.04232321, 0.01403512],'f'), 0.90047276020050049, 0.042089268565177917, 0) On Linux I got: >>> scipy.stats.statlib.swilk(y,a[:N/2],init) (array([ 0.47337109, 0.32174024, 0.25566328, 0.20829724, 0.16863985, 0.13358422, 0.1014744 , 0.0712893 , 0.04232322, 0.01403512],'f'), 0.90047299861907959, 0.042089745402336121, 0) I can try compiling the underlying Fortran file with different flags (no optimization for instance). What else could/should I try? Thanks, -- Skip Montanaro skip at pobox.com consulting: http://manatee.mojam.com/~skip/resume.html From pearu at cens.ioc.ee Wed Sep 11 16:31:08 2002 From: pearu at cens.ioc.ee (Pearu Peterson) Date: Wed, 11 Sep 2002 23:31:08 +0300 (EEST) Subject: [SciPy-dev] test error on Solaris using Sun's compilers In-Reply-To: <15743.41869.430994.232264@12-248-11-90.client.attbi.com> Message-ID: Hi, On Wed, 11 Sep 2002, Skip Montanaro wrote: > I installed SciPy on a Solaris machine using Sun's C and Fortran compilers > (hint for the unwary: this was *not* a straightforward exercise). (I hope that you will contribute your solutions also to scipy.) > I manually executed the code in scipy.stats.morestats.shapiro, and got > different results from the statlib.swilk call. On the Sun I got: > > >>> scipy.stats.statlib.swilk(y,a[:N/2],init) > (array([ 0.47337097, 0.32174039, 0.25566325, 0.20829722, 0.16863985, 0.13358422, > 0.10147439, 0.07128929, 0.04232321, 0.01403512],'f'), 0.90047276020050049, 0.042089268565177917, 0) > > On Linux I got: > > >>> scipy.stats.statlib.swilk(y,a[:N/2],init) > (array([ 0.47337109, 0.32174024, 0.25566328, 0.20829724, 0.16863985, 0.13358422, > 0.1014744 , 0.0712893 , 0.04232322, 0.01403512],'f'), 0.90047299861907959, 0.042089745402336121, 0) > > I can try compiling the underlying Fortran file with different flags (no > optimization for instance). What else could/should I try? No need. Note that swilk uses single precision floats and upto that precision the results are identical. The difference in last relevant bits of floats may be due to the difference how float operations are performed under Sun and Linux. If I remember correctly, then with gcc double-double operations are carried out with extra precision. The similar usage of extra precision may be true for float-float operations. It looks like the test codes need a fix, maybe decimal-=1. Pearu From skip at pobox.com Wed Sep 11 16:44:58 2002 From: skip at pobox.com (Skip Montanaro) Date: Wed, 11 Sep 2002 15:44:58 -0500 Subject: [SciPy-dev] test error on Solaris using Sun's compilers In-Reply-To: References: <15743.41869.430994.232264@12-248-11-90.client.attbi.com> Message-ID: <15743.43850.453906.450111@12-248-11-90.client.attbi.com> >> I installed SciPy on a Solaris machine using Sun's C and Fortran >> compilers (hint for the unwary: this was *not* a straightforward >> exercise). Pearu> (I hope that you will contribute your solutions also to scipy.) I'm still trying to figure out just what I've done. ;-) Note, though that I'm doing this work for Enthought, so there is a fairly good chance anything I manage to fix will get folded back into SciPy. ;-) >> I manually executed the code in scipy.stats.morestats.shapiro, and got >> different results from the statlib.swilk call. On the Sun I got: ... Pearu> It looks like the test codes need a fix, maybe decimal-=1. I will submit a patch. Skip From eric at enthought.com Wed Sep 11 17:03:27 2002 From: eric at enthought.com (eric jones) Date: Wed, 11 Sep 2002 16:03:27 -0500 Subject: [SciPy-dev] test error on Solaris using Sun's compilers In-Reply-To: <15743.43850.453906.450111@12-248-11-90.client.attbi.com> Message-ID: <000001c259d6$ad280630$6b01a8c0@ericlaptop> > -----Original Message----- > From: scipy-dev-admin at scipy.net [mailto:scipy-dev-admin at scipy.net] On > Behalf Of Skip Montanaro > Sent: Wednesday, September 11, 2002 3:45 PM > To: scipy-dev at scipy.net > Subject: Re: [SciPy-dev] test error on Solaris using Sun's compilers > > > >> I installed SciPy on a Solaris machine using Sun's C and Fortran > >> compilers (hint for the unwary: this was *not* a straightforward > >> exercise). > > Pearu> (I hope that you will contribute your solutions also to scipy.) > > I'm still trying to figure out just what I've done. ;-) Note, though that > I'm doing this work for Enthought, so there is a fairly good chance > anything > I manage to fix will get folded back into SciPy. ;-) You can read this as "will get folded back in." Skip has cvs access and will be checking in any necessary changes that don't need review by the "numeric geeks." > > >> I manually executed the code in scipy.stats.morestats.shapiro, and > got > >> different results from the statlib.swilk call. On the Sun I got: > ... > Pearu> It looks like the test codes need a fix, maybe decimal-=1. > > I will submit a patch. Things like this we'll need to help out with to make sure they make numerical sense. eric From oliphant at ee.byu.edu Wed Sep 11 18:15:52 2002 From: oliphant at ee.byu.edu (Travis Oliphant) Date: Wed, 11 Sep 2002 16:15:52 -0600 (MDT) Subject: [SciPy-dev] test error on Solaris using Sun's compilers In-Reply-To: <000001c259d6$ad280630$6b01a8c0@ericlaptop> Message-ID: > > >> I manually executed the code in scipy.stats.morestats.shapiro, > and > > got > > >> different results from the statlib.swilk call. On the Sun I > got: > > ... > > Pearu> It looks like the test codes need a fix, maybe decimal-=1. > > > > I will submit a patch. > > Things like this we'll need to help out with to make sure they make > numerical sense. This is just a test issue. Only single precision is used in the Fortran code and so the test should not be expecting more precision than about 6 or 7 digits. -Travis From skip at pobox.com Wed Sep 11 19:55:53 2002 From: skip at pobox.com (Skip Montanaro) Date: Wed, 11 Sep 2002 18:55:53 -0500 Subject: [SciPy-dev] test error on Solaris using Sun's compilers In-Reply-To: References: <000001c259d6$ad280630$6b01a8c0@ericlaptop> Message-ID: <15743.55305.988380.477334@12-248-11-90.client.attbi.com> Travis> This is just a test issue. Only single precision is used in the Travis> Fortran code and so the test should not be expecting more Travis> precision than about 6 or 7 digits. I tried dropping decimal to 7 and then 6. It now passes the first three assert_almost_equal calls in test_shapiro, but fails during the fourth: ====================================================================== FAIL: check_basic (test_morestats.test_shapiro) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/skip/local/SunOS/lib/python2.2/site-packages/scipy/stats/tests/test_morestats.py", line 37, in check_basic assert_almost_equal(pw,0.52459925413131714,6) File "/home/skip/local/SunOS/lib/python2.2/site-packages/scipy_base/testing.py", line 304, in assert_almost_equal assert round(abs(desired - actual),decimal) == 0, msg AssertionError: Items are not equal: DESIRED: 0.524599254131 ACTUAL: 0.524600028992 Seems sort of like more than round-off error to my naive eyes. Where do the constants used in those comparisons come from? Presumably some independent source and not the output of a run on another system (e.g., the Linux/GCC combo). Skip From eric at enthought.com Thu Sep 12 03:10:22 2002 From: eric at enthought.com (eric jones) Date: Thu, 12 Sep 2002 02:10:22 -0500 Subject: [SciPy-dev] Major CVS changes to weave Message-ID: <000601c25a2b$7614e690$777ba8c0@ericlaptop> Hey group, I've just checked a new version of weave into the CVS. It has major changes in it which are highlighted below. The good news is there are some big improvements and the code should be more portable. The bad news is that it introduced some backward incompatibility. Sorry about that. I'm getting pretty happy with the interface and code generation now, so we're close to a stage where backward compatibility will be maintained in future releases. The docs and maybe a few examples still need updating. I'll try to get these and the web pages cleaned up tomorrow and the next day and then make packaged release of weave when it is done. This big change was needed even if new things weren't coming, but the real reason I've checked this in now is in preparation of adding the *really* cool stuff that Pat Miller is doing to optimize standard python code and Numeric expressions. His stuff is still way experimental, but has huge potential. We'll be working over the next month or so to get it up and running so that it is ready for public consumption. Regards, eric Changes: 0. The underlying library code is significantly re-factored and simpler. There used to be a xxx_spec.py and xxx_info.py file for every group of type conversion classes. The spec file held the python code that handled the conversion and the info file had most of the C code templates that were generated. This proved pretty confusing in practice, so the two files have mostly been merged into the spec file. Also, there was quite a bit of code duplication running around. The re-factoring was able to trim the standard conversion code base (excluding blitz and accelerate stuff) by about 40%. This should be a huge maintainability and extensibility win. 1. With multiple months of using Numeric arrays, I've found some of weave's "magic variable" names unwieldy and want to change them. The following are the old declarations for an array x of Float32 type: PyArrayObject* x = convert_to_numpy(...); float* x_data = (float*) x->data; int* _Nx = x->dimensions; int* _Sx = x->strides; int _Dx = x->nd; The new declaration looks like this: PyArrayObject* x_array = convert_to_numpy(...); float* x = (float*) x->data; int* Nx = x->dimensions; int* Sx = x->strides; int Dx = x->nd; This is obviously not backward compatible, and will break some code (including a lot of mine). It also makes inline() code more readable and natural to write. 2. I've switched from CXX to Gordon McMillan's SCXX for list, tuples, and dictionaries. I like CXX pretty well, but its use of advanced C++ (templates, etc.) caused some portability problems. The SCXX library is similar to CXX but doesn't use templates at all. This, like (1) is not an API compatible change and requires repairing existing code. I have also thought about boost python, but it also makes heavy use of templates. Moving to SCXX gets rid of almost all template usage for the standard type converters which should help portability. std::complex and std::string from the STL are the only templates left. Of course blitz still uses templates in a major way so weave.blitz will continue to be hard on compilers. I've actually considered scrapping the C++ classes for list, tuples, and dictionaries, and just fall back to the standard Python C API because the classes are waaay slower than the raw API in many cases. They are also more convenient and less error prone in many cases, so I've decided to stick with them. The PyObject variable will always be made available for variable "x" under the name "py_x" for more speedy operations. You'll definitely want to use these for anything that needs to be speedy. 3. strings are converted to std::string now. I found this to be the most useful type in for strings in my code. Py::String was used previously. 4. There are a number of reference count "errors" in some of the less tested conversion codes such as instance, module, etc. I've cleaned most of these up. I put errors in quotes here because I'm actually not positive that objects passed into "inline" really need reference counting applied to them. The dictionaries passed in by inline() hold references to these objects so it doesn't seem that they could ever be garbage collected inadvertently. Variables used by ext_tools, though, definitely need the reference counting done. I don't think this is a major cost in speed, so it probably isn't worth getting rid of the ref count code. 5. Unicode objects are now supported. This was necessary to support rendering Unicode strings in the freetype wrappers for Chaco. 6. blitz++ was upgraded to the latest CVS. It compiles about twice as fast as the old blitz and looks like it supports a large number of compilers (including SGI, Steve) though only gcc 2.95.3 (2.96 on Linux) is tested. Compile times now take about 9 seconds on my 850 MHz PIII laptop. From mailstop at melcon-c.com Thu Sep 12 05:42:49 2002 From: mailstop at melcon-c.com (mailstop at melcon-c.com) Date: Thu, 12 Sep 2002 18:42:49 +0900 Subject: [SciPy-dev] =?ISO-2022-JP?B?GyRCTCQ+NUJ6OS05cCIoJEEkZyRDJEgbKEI=?= H=?ISO-2022-JP?B?GyRCJEpOeD9NGyhC?= GET=?ISO-2022-JP?B?GyRCISohKhsoQg==?= Message-ID: <20020912094249.OMDQ6810.mta3p@n8g0f1> <$B;v6H(B>$B-k%(%/%7%9(B<$BAw?.$B-k%(%/%7%9(B<$BAw?.$B!!(Bhttp://plaza15.mbn.or.jp/~1234/ $B$3$N(B???$B$O9-9p$G$9!#G[?.ITMW$NJ}$O(B mailstop at melcon-c.com $BKx$4O"Mm2<$5$$!#G[?.$rDd;_CW$7$^$9(B($BI,$:G[?.Dd;_$9$k%"%I%l%9$G$4JV?.2<$5$$!K(B H$B$J=w$N;R5^A}Cf!*:#$,%A%c%s%9!*(B http://www.melcon-c.com $BB(%"%]B3=P!*(B http://www.melcon-c.com $B$^$:$OEPO?$7$F$M!*(B http://www.melcon-c.com From steven.robbins at videotron.ca Thu Sep 12 13:08:57 2002 From: steven.robbins at videotron.ca (Steve M. Robbins) Date: Thu, 12 Sep 2002 13:08:57 -0400 Subject: [SciPy-dev] Major CVS changes to weave In-Reply-To: <000601c25a2b$7614e690$777ba8c0@ericlaptop> References: <000601c25a2b$7614e690$777ba8c0@ericlaptop> Message-ID: <20020912170856.GA15231@nyongwa.montreal.qc.ca> Hi Eric, On Thu, Sep 12, 2002 at 02:10:22AM -0500, eric jones wrote: > 2. > I've switched from CXX to Gordon McMillan's SCXX for list, tuples, and > dictionaries. I like CXX pretty well, but its use of advanced C++ > (templates, etc.) caused some portability problems. The SCXX library is > similar to CXX but doesn't use templates at all. This, like (1) is not an > API compatible change and requires repairing existing code. > > I have also thought about boost python, but it also makes heavy use of > templates. Moving to SCXX gets rid of almost all template usage for the > standard type converters which should help portability. I don't mean to second-guess your decision, especially since I know nothing of the details of SCXX nor of boost python. However, portability is probably one of the stronger reasons to switch TO boost. Those guys are absolutely rabid about supporting a wide variety of compiler/platform pairs. Boost is heavily templated throughout, but they still manage to build on a number of disparate compilers, so I figure they have the portable use of templates down to a science by now. > 6. > blitz++ was upgraded to the latest CVS. It compiles about twice as fast > as the old blitz and looks like it supports a large number of compilers > (including SGI, Steve) Woohoo! Sounds good. Cheers, -Steve From eric at enthought.com Thu Sep 12 16:34:02 2002 From: eric at enthought.com (eric jones) Date: Thu, 12 Sep 2002 15:34:02 -0500 Subject: [SciPy-dev] Major CVS changes to weave In-Reply-To: <20020912170856.GA15231@nyongwa.montreal.qc.ca> Message-ID: <000001c25a9b$c77eec90$6b01a8c0@ericlaptop> > Hi Eric, > > > On Thu, Sep 12, 2002 at 02:10:22AM -0500, eric jones wrote: > > > 2. > > I've switched from CXX to Gordon McMillan's SCXX for list, tuples, and > > dictionaries. I like CXX pretty well, but its use of advanced C++ > > (templates, etc.) caused some portability problems. The SCXX library is > > similar to CXX but doesn't use templates at all. This, like (1) is not > an > > API compatible change and requires repairing existing code. > > > > I have also thought about boost python, but it also makes heavy use of > > templates. Moving to SCXX gets rid of almost all template usage for the > > standard type converters which should help portability. > > I don't mean to second-guess your decision, especially since I know > nothing > of the details of SCXX nor of boost python. However, portability is > probably one of the stronger reasons to switch TO boost. Those guys are > absolutely rabid about supporting a wide variety of compiler/platform > pairs. Boost is heavily templated throughout, but they still manage > to build on a number of disparate compilers, so I figure they have > the portable use of templates down to a science by now. Well, this decision isn't cast in stone so I welcome other thoughts. The main selling points of SCXX is that it is *tiny* (less than 900 lines), simple, and doesn't require templates. These are all good things. It isn't quite as easy to use as CXX, but perhaps minor modifications to clean up these "deficiencies". The other possibility is that the deficiency is actually on my part in that I lack a complete understanding of its usage. I'll know more about this as I use it more. As far as boost, it is very enticing because it is the most actively developed C++/Python project and David is extremely responsive. On the other hand, it is large and has a the broad scope of generating wrapper modules from existing C++ libraries. This requires a lot of machinery and complexity. All we need for weave are C++ class that mimic lists, tuples, and dictionaries nicely. Using boost for this looked like overkill. Currently the only templates used for non-blitz weave stuff is std::string and std::complex. By now, these guys *should* be supported everywhere without issue. The third option is just to forego the attempt to make lists, dicts, and tuples look nice with C++ wrappers and just expose the raw PyObject*. I think people who have written extension modules before would prefer this while people unfamiliar with the Python API would not. I tend to try and design for the new user and provide a workaround for expert. In this case, py_xxx always provides the raw PyObject* version of variable xxx while xxx is a "nicer" version of the same object. My current opinion remains that SCXX is the best fit for what weave needs. I'd be interested, though, if a boost expert can chime in on what they think is required to extract the list, tuple, dictionary stuff from boost and whether it is appropriate. > > 6. > > blitz++ was upgraded to the latest CVS. It compiles about twice as fast > > as the old blitz and looks like it supports a large number of compilers > > (including SGI, Steve) > > Woohoo! Sounds good. Thought you might like that. It looks like the effort to get this working will be setting up a blitz++ config.h file with #ifdefs that switch in the appropriate settings for a particular platform's compiler instead of just including the gcc settings. See ya, eric From patmiller at llnl.gov Thu Sep 12 17:48:22 2002 From: patmiller at llnl.gov (Pat Miller) Date: Thu, 12 Sep 2002 14:48:22 -0700 Subject: [SciPy-dev] Major CVS changes to weave References: <000601c25a2b$7614e690$777ba8c0@ericlaptop> <20020912170856.GA15231@nyongwa.montreal.qc.ca> Message-ID: <3D810BA6.EBC7A6E@llnl.gov> "Steve M. Robbins" wrote: > I don't mean to second-guess your decision, especially since I know nothing > of the details of SCXX nor of boost python. However, portability is > probably one of the stronger reasons to switch TO boost. Those guys are > absolutely rabid about supporting a wide variety of compiler/platform Yes, but it seems like overkill for what Eric needs for weave (me too!). It also (currently) has issues with symbol table size and speed. >> blitz++ was upgraded to the latest CVS. It compiles about twice as fast >> as the old blitz and looks like it supports a large number of compilers > Woohoo! Sounds good My work that Eric was alluding to was a compiled alternative to the blitz++ module that works like: from compilation.numeric import compiler ... compiler() a = b + c*d - 3 end_compiler() ... instead of weave.blitz('a = b+c*d-3',[a]) Rather than using C++ expression templates, this recreates the Python AST for the code between the compiler "pragmas" (special functions, really) and builds a C (not C++) equivalent with a maximum of 1 heap allocation per assignment (tests at runtime to see if the left hand side is assignable and uses it if possible). This is wicked fast (both in terms of compilation time < 1 sec and runtime). For Pearu's LaPlace example, I get 900-1800X speedup over the original Python with Numeric arrays --- equivalent to hand-written C. Pat -- Patrick Miller | (925) 423-0309 | http://www.llnl.gov/CASC/people/pmiller Work is of two kinds: first, altering the position of matter at or near the earth's surface relative to other matter; second, telling other people to do so. The first is unpleasant and ill-paid; the second is pleasant and highly paid. -- Bertrand Russell, philosopher, mathematician, and author (1872-1970) From fperez at pizero.colorado.edu Fri Sep 13 12:57:27 2002 From: fperez at pizero.colorado.edu (Fernando Perez) Date: Fri, 13 Sep 2002 10:57:27 -0600 (MDT) Subject: [SciPy-dev] Major CVS changes to weave In-Reply-To: <3D810BA6.EBC7A6E@llnl.gov> Message-ID: On Thu, 12 Sep 2002, Pat Miller wrote: > My work that Eric was alluding to was a compiled alternative to the > blitz++ > module that works like: > > from compilation.numeric import compiler > > ... > compiler() > a = b + c*d - 3 > end_compiler() > ... > > instead of weave.blitz('a = b+c*d-3',[a]) [snip] > This is wicked fast (both in terms of compilation time < 1 sec and > runtime). > > For Pearu's LaPlace example, I get 900-1800X speedup over the original > Python with Numeric arrays --- equivalent to hand-written C. And we will have access to this when? Please oh please :) I'm supposed to do some C/Fortran/Python benchmarking to convince my boss that we _can_ use python for most of our new code (fast algorithms development) --at least for the prototyping and the higher level logic, of course. I'm kind of holding back and keeping under his radar b/c I'd like to have access to these improvements before I do the testing. I _really_ don't want to have to end up writing fortran code. So you would have at least one eternally grateful user out there if this makes it into the wild. cheers, f. From lists at UltimateG.com Fri Sep 13 15:00:31 2002 From: lists at UltimateG.com (Mark Evans) Date: Fri, 13 Sep 2002 12:00:31 -0700 Subject: [SciPy-dev] Boost vs CXX and SCXX Message-ID: <1851978134.20020913120031@UltimateG.com> > My current opinion remains that SCXX is the best fit for what weave > needs. I'd be interested, though, if a boost expert can chime in on > what they think is required to extract the list, tuple, dictionary stuff > from boost and whether it is appropriate. A couple years ago my company tasked me with an assignment. I was to evaluate C++ interfacing libraries for Python. At that time Boost was still in alpha stages, but after using it, I considered myself very fortunate to have found it. Prior to that, my company and I had sunk a lot of effort into CXX. Even in its alpha stages, Boost was a dream compared to CXX, the C API, or any other toolkit. My particular project involved an ActiveX chart control interfaced to wxPython, and a Python interface to both Mathematica and Numerical Python. We were creating a technical workspace environment with Python as the front end and Numpy / Mathematica as cooperating back ends. I can't tell you what relief I felt after I switched from CXX to Boost. Boost has a lot of complexity so that your C++ code can remain simple. It minimizes the impact of Python interfacing on C++ code. Wrapping your existing C++ code is trivially simple. Not so with CXX and kin. CXX has a different philosophy, which is to make C++ code read like Python code. About all it really does is to define some C++ objects that behave like Python atoms. That's fine as far as it goes but offers nowhere near the power of Boost. Boost does not prohibit writing code like that, but does not force it on you. Compared to Boost, CXX is pretty dumbed-down, and SCXX even more so. I would hate to see SciPy standardize on either one of them especially after my personal experiences "crawling out from under" them. http://www.boost.org/libs/python/doc/comparisons.html After two years of development Boost has taken the lead and I would consider it folly to adopt any other toolkit for C++ interfacing to Python. (In specialized cases I might use SWIG but otherwise Boost all the way.) The Boost development is very active whereas CXX and kin are as stale as old bread. If your Windows compiler is having problems with templates, then try the free Digital Mars compiler (DigitalMars.com). Mark From skip at pobox.com Fri Sep 13 15:08:16 2002 From: skip at pobox.com (Skip Montanaro) Date: Fri, 13 Sep 2002 14:08:16 -0500 Subject: [SciPy-dev] Boost vs CXX and SCXX In-Reply-To: <1851978134.20020913120031@UltimateG.com> References: <1851978134.20020913120031@UltimateG.com> Message-ID: <15746.14240.976556.460885@12-248-11-90.client.attbi.com> Mark> Compared to Boost, CXX is pretty dumbed-down, and SCXX even more Mark> so. I would hate to see SciPy standardize on either one of them Mark> especially after my personal experiences "crawling out from under" Mark> them. http://www.boost.org/libs/python/doc/comparisons.html I'm coming a bit late to this discussion, but isn't the issue of Boost vs. CXX vs. SCXX here related to what weave uses under the covers? I doubt weave's use of SCXX will prevent people from using Boost for their own extension modules, will it? -- Skip Montanaro skip at pobox.com consulting: http://manatee.mojam.com/~skip/resume.html From fperez at pizero.colorado.edu Fri Sep 13 15:10:36 2002 From: fperez at pizero.colorado.edu (Fernando Perez) Date: Fri, 13 Sep 2002 13:10:36 -0600 (MDT) Subject: [SciPy-dev] Boost vs CXX and SCXX In-Reply-To: <1851978134.20020913120031@UltimateG.com> Message-ID: On Fri, 13 Sep 2002, Mark Evans wrote: > My particular project involved an ActiveX chart control interfaced to > wxPython, and a Python interface to both Mathematica and Numerical Python. > We were creating a technical workspace environment with Python as the > front end and Numpy / Mathematica as cooperating back ends. > I can't tell you what relief I felt after I switched from CXX to Boost. That sounds very interesting. Did this project ever make it to the public? Here in my group we use Mathematica a _lot_ and I'm pushing python hard for the numerical parts (as a replacement for matlab, trying to only write C/Fortran when absolutely necessary). But being able to have the python and mathematica parts talk would be great. Could you provide a bit more info on this? Since it's a bit off the original thread topic, feel free to either respond privately or start a new thread. Cheers, f. From eric at enthought.com Fri Sep 13 15:53:26 2002 From: eric at enthought.com (eric jones) Date: Fri, 13 Sep 2002 14:53:26 -0500 Subject: [SciPy-dev] Boost vs CXX and SCXX In-Reply-To: <1851978134.20020913120031@UltimateG.com> Message-ID: <000001c25b5f$39b8fa80$6b01a8c0@ericlaptop> Hey Mark, Like you, I'd pick boost or SWIG (which has made *huge* leaps in the last year for C++ stuff) for wrapping a C++ library. But that isn't what we're choosing here. Weave allows you to inline C++ code within Python. It is nice to have a representation of Python objects in the C++ code that look Pythonic. C++ classes allow this sort of thing. CXX wrappers allowed this sort of thing: >>> import weave >>> a= [1,2] >>> weave.inline('a[0] = Py::Int(3)',['a']) >>> a[0] [3, 2] Now with SCXX, we have: >>> import weave >>> a = [1,2] >>> weave.inline('a[0] = PWONumber(3);',['a']) >>> a [3, 2] I doubt boost would be much different or superior to either of these in terms of readability or use. As I said before, most of the tools boost provides help with wrapping code and aren't beneficial in the context of weave. All we're looking for is a few measly classes for wrapping lists, dicts, and tuples -- although callable objects, files, and modules are other potential targets. If we can extract these easily from boost, they compile easily on everything, and they offer some benefits over these other two approachs *in the context of weave*, then its worth considering a change. I'm happy to look at an experimental patch. :-) eric > -----Original Message----- > From: scipy-dev-admin at scipy.net [mailto:scipy-dev-admin at scipy.net] On > Behalf Of Mark Evans > Sent: Friday, September 13, 2002 2:01 PM > To: scipy-dev at scipy.net > Subject: [SciPy-dev] Boost vs CXX and SCXX > > > My current opinion remains that SCXX is the best fit for what weave > > needs. I'd be interested, though, if a boost expert can chime in on > > what they think is required to extract the list, tuple, dictionary stuff > > from boost and whether it is appropriate. > > A couple years ago my company tasked me with an assignment. I was to > evaluate C++ interfacing libraries for Python. At that time Boost was > still in alpha stages, but after using it, I considered myself very > fortunate to have found it. Prior to that, my company and I had sunk a > lot of effort into CXX. > > Even in its alpha stages, Boost was a dream compared to CXX, the C API, > or any other toolkit. > > My particular project involved an ActiveX chart control interfaced to > wxPython, and a Python interface to both Mathematica and Numerical Python. > We were creating a technical workspace environment with Python as the > front end and Numpy / Mathematica as cooperating back ends. > I can't tell you what relief I felt after I switched from CXX to Boost. > > Boost has a lot of complexity so that your C++ code can remain simple. It > minimizes the impact of Python interfacing on C++ code. Wrapping your > existing C++ code is trivially simple. Not so with CXX and kin. > > CXX has a different philosophy, which is to make C++ code read > like Python code. About all it really does is to define some C++ > objects that behave like Python atoms. That's fine as far as it goes > but offers nowhere near the power of Boost. Boost does not prohibit > writing code like that, but does not force it on you. > > Compared to Boost, CXX is pretty dumbed-down, and SCXX even > more so. I would hate to see SciPy standardize on either one of them > especially after my personal experiences "crawling out from under" > them. http://www.boost.org/libs/python/doc/comparisons.html > > After two years of development Boost has taken the lead and I would > consider it folly to adopt any other toolkit for C++ interfacing to > Python. (In specialized cases I might use SWIG but otherwise Boost all > the way.) The Boost development is very active whereas CXX and > kin are as stale as old bread. > > If your Windows compiler is having problems with templates, then try > the free Digital Mars compiler (DigitalMars.com). > > Mark > > _______________________________________________ > Scipy-dev mailing list > Scipy-dev at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-dev From patmiller at llnl.gov Fri Sep 13 16:19:16 2002 From: patmiller at llnl.gov (Pat Miller) Date: Fri, 13 Sep 2002 13:19:16 -0700 Subject: [SciPy-dev] Boost vs CXX and SCXX References: <000001c25b5f$39b8fa80$6b01a8c0@ericlaptop> Message-ID: <3D824844.7750819A@llnl.gov> SXX has the advantage (for weave) of having a _very_ small source footprint. Again, this isn't looking to interface general C++ classes, but rather to avoid reference count issues. Pat -- Patrick Miller | (925) 423-0309 | http://www.llnl.gov/CASC/people/pmiller All the world's a stage, / And the men and women merely players: / They have their exits and their entrances; / And one man in his time plays many parts. -- William Shakespeare From falted at openlc.org Fri Sep 13 18:40:11 2002 From: falted at openlc.org (Francesc Alted) Date: Sat, 14 Sep 2002 00:40:11 +0200 Subject: [SciPy-dev] Boost vs CXX and SCXX In-Reply-To: <3D824844.7750819A@llnl.gov> References: <000001c25b5f$39b8fa80$6b01a8c0@ericlaptop> <3D824844.7750819A@llnl.gov> Message-ID: <20020913224011.GA1393@openlc.org> After seeing this debate about interfaces between Python and C++, maybe you want to have a look at Pyrex (http://www.cosc.canterbury.ac.nz/~greg/python/Pyrex/). I've been working for a while in a wrapper for HDF5 format in Python and I'm using Pyrex. No worries about reference counts and allows you to use almost Python syntax in the wrappers. Killer!. Cheers, On Fri, Sep 13, 2002 at 01:19:16PM -0700, Pat Miller wrote: > SXX has the advantage (for weave) of having a _very_ small source > footprint. Again, this isn't looking to interface general C++ > classes, but rather to avoid reference count issues. > > Pat > > -- > Patrick Miller | (925) 423-0309 | > http://www.llnl.gov/CASC/people/pmiller > > All the world's a stage, / And the men and women merely players: / They > have their exits and their entrances; / And one man in his time plays > many parts. -- William Shakespeare > _______________________________________________ > Scipy-dev mailing list > Scipy-dev at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-dev > > > -- Francesc Alted PGP KeyID: 0x61C8C11F OpenLC microkernel benchmarking project: http://www.openlc.org Public PGP key available: http://www.openlc.org/falted_at_openlc.asc Key fingerprint = 1518 38FE 3A3D 8BE8 24A0 3E5B 1328 32CC 61C8 C11F From Chuck.Harris at sdl.usu.edu Fri Sep 13 18:49:47 2002 From: Chuck.Harris at sdl.usu.edu (Chuck Harris) Date: Fri, 13 Sep 2002 16:49:47 -0600 Subject: [SciPy-dev] Boost vs CXX and SCXX Message-ID: Hi, > -----Original Message----- > From: Francesc Alted [mailto:falted at openlc.org] > Sent: Friday, September 13, 2002 4:40 PM > To: scipy-dev at scipy.net > Subject: Re: [SciPy-dev] Boost vs CXX and SCXX > > > After seeing this debate about interfaces between Python and > C++, maybe you > want to have a look at Pyrex > (http://www.cosc.canterbury.ac.nz/~greg/python/Pyrex/). > > I've been working for a while in a wrapper for HDF5 format in > Python and I'm I would be very interested in that. How far along are you? Chuck From falted at openlc.org Sat Sep 14 05:58:21 2002 From: falted at openlc.org (Francesc Alted) Date: Sat, 14 Sep 2002 11:58:21 +0200 Subject: [SciPy-dev] Boost vs CXX and SCXX In-Reply-To: References: Message-ID: <20020914095821.GA1236@openlc.org> On Fri, Sep 13, 2002 at 04:49:47PM -0600, Chuck Harris wrote: > > > > I've been working for a while in a wrapper for HDF5 format in > > Python and I'm > > I would be very interested in that. How far along are you? Good!. At the moment I'm mainly interested in implementing tables based on compound types (C structs). The package (probably I'll call it PyTables, but that's still unsure) can do now: - Create tables and feed them with an unlimited number of records - Supports data buffering (can make writes and reads orders of magnitude faster) - Read the record tables from objects acting as iterators - Create a hierarchical structure with the tables In the next week I plan to support also Numeric arrays, and document a bit the package. If I have time I'll include some tests. Hopefully, in the end of September, I'll make available an alpha release package for public evaluation. I want to release early the code in order to get feedback from the scientific community. Here you have a small example of what can be done right now: from H5File import * from Numeric import * totalrows = 10 file = H5File(filename = 'h5_table.h5') # Create a new HDF5 file b = file.make_instance() # Read the file metadata # Create a table b.tuple1 = c = H5Table(varnames = ('var1', 'var2', 'var3'), fmt = '3sid', tableTitle = "Table 1", compress = 0, expectedrows = totalrows) # Fill the table for i in xrange(totalrows): c.commitBuffered(str(i), i, 12.1e40) c.flush() # Flush the buffer table b.direcname = d = H5Dir() # Create a new directory on file # Create another table in the new directory d.tuple1 = c = H5Table(varnames = ('var1', 'var2', 'var3', 'var4'), fmt = '3sidd', tableTitle = "Table 1", compress = 0, expectedrows = totalrows) # Fill the second table for i in xrange(totalrows): c.commitBuffered(str(i), i, 12.1e40, 12.1e40 * i) c.flush() # Flush the buffer table # Example of tuple selection numarray = array([ tupla[1] for tupla in c.readAllTable() if tupla[1] < 20 ]) print "Total selected records ==> ", len(numarray) # Close the HDF5 file file.close() The h5ls output over this file can be seen here: $ h5ls -rd h5_table.h5 /h5_table.h5/direcname Group /h5_table.h5/direcname/tuple1 Dataset {10/Inf} Data: (0) {"0", 0, 1.21e+41, 0}, {"1", 1, 1.21e+41, 1.21e+41}, (2) {"2", 2, 1.21e+41, 2.42e+41}, {"3", 3, 1.21e+41, 3.63e+41}, (4) {"4", 4, 1.21e+41, 4.84e+41}, {"5", 5, 1.21e+41, 6.05e+41}, (6) {"6", 6, 1.21e+41, 7.26e+41}, {"7", 7, 1.21e+41, 8.47e+41}, (8) {"8", 8, 1.21e+41, 9.68e+41}, {"9", 9, 1.21e+41, 1.089e+42} /h5_table.h5/tuple1 Dataset {10/Inf} Data: (0) {"0", 0, 1.21e+41}, {"1", 1, 1.21e+41}, {"2", 2, 1.21e+41}, (3) {"3", 3, 1.21e+41}, {"4", 4, 1.21e+41}, {"5", 5, 1.21e+41}, (6) {"6", 6, 1.21e+41}, {"7", 7, 1.21e+41}, {"8", 8, 1.21e+41}, (9) {"9", 9, 1.21e+41} As always, suggestions or support of any kind is welcomed. -- Francesc Alted PGP KeyID: 0x61C8C11F OpenLC microkernel benchmarking project: http://www.openlc.org Public PGP key available: http://www.openlc.org/falted_at_openlc.asc Key fingerprint = 1518 38FE 3A3D 8BE8 24A0 3E5B 1328 32CC 61C8 C11F From prabhu at aero.iitm.ernet.in Fri Sep 13 22:52:42 2002 From: prabhu at aero.iitm.ernet.in (Prabhu Ramachandran) Date: Sat, 14 Sep 2002 08:22:42 +0530 Subject: [SciPy-dev] Boost vs CXX and SCXX In-Reply-To: <000001c25b5f$39b8fa80$6b01a8c0@ericlaptop> References: <1851978134.20020913120031@UltimateG.com> <000001c25b5f$39b8fa80$6b01a8c0@ericlaptop> Message-ID: <15746.42106.427325.416770@monster.linux.in> >>>>> "EJ" == eric jones writes: EJ> Hey Mark, Like you, I'd pick boost or SWIG (which has made EJ> *huge* leaps in the last year for C++ stuff) for wrapping a EJ> C++ library. But that isn't what we're choosing here. Weave This is totally OT but I just took a look at SWIG (http://www.swig.org) again and yes it has made *huge* improvements since I used it last. AFAIK, the only big features that BPL has over it is that BPL allows one to implement "virtual methods in the target language", i.e. you can derive a class from a wrapped C++ class in Python and expect the wrapped library to be able to call your Python subclass. Also, as mentioned in SWIG's features page the trouble with nested classes. However given the current state of features almost everything else is supported very nicely. AFAIK, this should do for *many* situations. The nice things about SWIG are: 1. Its so easy to wrap thanks to SWIG's parser/compiler. This is something that BPL does not have. It is incredibly easy to wrap a library without having to learn another C++ API. 2. Documentation. 3. Ease of use for the truly lazy. :) Actually the SWIG features page talks about all this in better detail than I've done here. I also noticed that the SWIG folks are unhappy about lots of the negative publicity they got way back (including some silly comments from me) due to lack of various features. This is understandable. This is not a comparison between SWIG and BPL. BPL is very cool too and is developed almost single handedly by David who is an amazing programmer. SWIG has been around for *very* long and has many more developers. Its nice to know that SWIG is still under active development and that it has had enough steam to get to where it is. :) I think SWIG has a great future. Better still it looks like C/C++->Python interfacing has a great future with all these new wrapper generation tools and with Pearu's f2py Fortran->Python also has a great future. Its a huge win for Python. :) Thanks Eric for pointing this out. cheers, prabhu From eric at enthought.com Mon Sep 16 13:53:16 2002 From: eric at enthought.com (eric jones) Date: Mon, 16 Sep 2002 12:53:16 -0500 Subject: [SciPy-dev] movement of testing.py to scipy_distutils Message-ID: <000001c25da9$f0060de0$6b01a8c0@ericlaptop> Does anyone have any objections to moving testing.py from scipy_base to scipy_distutils? It would make distribution of weave and other potential modules have one less dependency package. Besides the blitz() stuff, weave doesn't rely on anything in scipy_base. And, other than scipy_base it doesn't have any extension module dependencies. I like to keep it that way. Hmmm. I guess testing.py could become its own package (or stand alone module) like scipy_base and scipy_distutils also. I think it actually was at one point...? Anyway, opinions and suggestions welcome. I'd like to get a version of the weave stuff packaged up and ready for people to test (although docs are still not updated) by the end of the day. eric From skip at pobox.com Mon Sep 16 16:40:12 2002 From: skip at pobox.com (Skip Montanaro) Date: Mon, 16 Sep 2002 15:40:12 -0500 Subject: [SciPy-dev] two scipy test failures... Message-ID: <15750.16812.618194.640439@12-248-11-90.client.attbi.com> Just passing these along to make sure they stay on someone's radar screen (should I be submitting bugs somewhere else?). I still get a couple precision errors when running scipy.test(). This is on Solaris using Sun's compilers: FAIL: check_basic (test_morestats.test_shapiro) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/skip/local/SunOS/lib/python2.2/site-packages/scipy/stats/tests/test_morestats.py", line 37, in check_basic assert_almost_equal(pw,0.52459925413131714,6) File "/home/skip/local/SunOS/lib/python2.2/site-packages/scipy_base/testing.py", line 304, in assert_almost_equal assert round(abs(desired - actual),decimal) == 0, msg AssertionError: Items are not equal: DESIRED: 0.524599254131 ACTUAL: 0.524600028992 Note that I have dialed back the decimal arg from 8 to 6. On Linux I get a different precision error: FAIL: check_mean (test_common.test_rand) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/skip/local/Linux/lib/python2.2/site-packages/scipy/tests/test_common.py", line 27, in check_mean assert_almost_equal(mn,0.5,2) File "/home/skip/local/Linux/lib/python2.2/site-packages/scipy_base/testing.py", line 304, in assert_almost_equal assert round(abs(desired - actual),decimal) == 0, msg AssertionError: Items are not equal: DESIRED: 0.5 ACTUAL: 0.505251432072 Skip From skip at pobox.com Mon Sep 16 16:48:07 2002 From: skip at pobox.com (Skip Montanaro) Date: Mon, 16 Sep 2002 15:48:07 -0500 Subject: [SciPy-dev] Re: [Scipy-cvs] CVS update: world/scipy/weave In-Reply-To: <20020916202252.7A2693EAD2@www.scipy.com> References: <20020916202252.7A2693EAD2@www.scipy.com> Message-ID: <15750.17287.909713.116868@12-248-11-90.client.attbi.com> Dunno who is in charge of scipy-cvs, but I think it would be helpful if it was jiggered to include the context diff of the checkin. This allows people to quickly scan the checkin for obvious problems and will probably increase the feedback people get on their checkins. If this is not something which is a standard part of CVS, you might check with Barry Warsaw or one of the other Python SF project admins to see what scripts they needed to modify to get the python-checkins list to display context diffs. Skip From pearu at cens.ioc.ee Mon Sep 16 17:21:24 2002 From: pearu at cens.ioc.ee (Pearu Peterson) Date: Tue, 17 Sep 2002 00:21:24 +0300 (EEST) Subject: [SciPy-dev] movement of testing.py to scipy_distutils In-Reply-To: <000001c25da9$f0060de0$6b01a8c0@ericlaptop> Message-ID: On Mon, 16 Sep 2002, eric jones wrote: > Does anyone have any objections to moving testing.py from scipy_base to > scipy_distutils? It would make distribution of weave and other > potential modules have one less dependency package. Besides the blitz() > stuff, weave doesn't rely on anything in scipy_base. And, other than > scipy_base it doesn't have any extension module dependencies. I like to > keep it that way. +0.9 The only doubt that I have is that if the long term goal is to move stuff from scipy_distutils to distutils, then ideally, scipy_distutils package should become obsolete. But testing.py as well as auto_test.py and logging.py do not fit into distutils purpose list... > Hmmm. I guess testing.py could become its own package (or stand alone > module) like scipy_base and scipy_distutils also. I think it actually > was at one point...? Currently it is only one file. Are there any extension plans for testing.py so that at some point this package would consist of more than just one file? May be auto_test.py and logging.py? > Anyway, opinions and suggestions welcome. I'd like to get a version of > the weave stuff packaged up and ready for people to test (although docs > are still not updated) by the end of the day. In fact, since testing.py was in scipy_base, I did not use it in f2py testing site --- a threshold for adding one dependency more was too high. If testing.py is moved to scipy_distutils, this threshold vanishes... Other issues: Note that testing.py uses fastumath from scipy_base. Is replacing fastumath with math cause any problems, in particularly, with Inf/NaN stuff? (I guess it is easy to check this out.) Pearu From pearu at cens.ioc.ee Mon Sep 16 17:37:32 2002 From: pearu at cens.ioc.ee (Pearu Peterson) Date: Tue, 17 Sep 2002 00:37:32 +0300 (EEST) Subject: [SciPy-dev] movement of testing.py to scipy_distutils In-Reply-To: <000001c25da9$f0060de0$6b01a8c0@ericlaptop> Message-ID: On Mon, 16 Sep 2002, eric jones wrote: > Anyway, opinions and suggestions welcome. I'd like to get a version of > the weave stuff packaged up and ready for people to test (although docs > are still not updated) by the end of the day. Would it make sense to move also lib2def.py to scipy_distutils? Namely, Windows users of f2py need that, and currently I just copy lib2def.py to scipy_distutils when making a snapshot of f2py. But this results in two copies of lib2def.py lying around when also scipy is used. Pearu From pearu at cens.ioc.ee Mon Sep 16 18:22:28 2002 From: pearu at cens.ioc.ee (Pearu Peterson) Date: Tue, 17 Sep 2002 01:22:28 +0300 (EEST) Subject: [SciPy-dev] Re: [Scipy-cvs] CVS update: world/scipy/weave In-Reply-To: <15750.17287.909713.116868@12-248-11-90.client.attbi.com> Message-ID: On Mon, 16 Sep 2002, Skip Montanaro wrote: > > Dunno who is in charge of scipy-cvs, but I think it would be helpful if it > was jiggered to include the context diff of the checkin. This allows people > to quickly scan the checkin for obvious problems and will probably increase > the feedback people get on their checkins. If this is not something which > is a standard part of CVS, you might check with Barry Warsaw or one of the > other Python SF project admins to see what scripts they needed to modify to > get the python-checkins list to display context diffs. I agree, context diff would be very useful. The following link explains how to set this up: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/CVSROOT/syncmail?rev=3.21&content-type=text/vnd.viewcvs-markup Pearu From oliphant at ee.byu.edu Mon Sep 16 18:42:51 2002 From: oliphant at ee.byu.edu (Travis Oliphant) Date: Mon, 16 Sep 2002 16:42:51 -0600 (MDT) Subject: [SciPy-dev] movement of testing.py to scipy_distutils In-Reply-To: <000001c25da9$f0060de0$6b01a8c0@ericlaptop> Message-ID: > > Hmmm. I guess testing.py could become its own package (or stand alone > module) like scipy_base and scipy_distutils also. I think it actually > was at one point...? > I think it's o.k to put it in scipy_distutils, though perhaps a scipy_testing would be cleaner...except for proliferating the number of packages if that matters. -Travis O. From oliphant at ee.byu.edu Mon Sep 16 18:42:51 2002 From: oliphant at ee.byu.edu (Travis Oliphant) Date: Mon, 16 Sep 2002 16:42:51 -0600 (MDT) Subject: [SciPy-dev] movement of testing.py to scipy_distutils In-Reply-To: <000001c25da9$f0060de0$6b01a8c0@ericlaptop> Message-ID: > > Hmmm. I guess testing.py could become its own package (or stand alone > module) like scipy_base and scipy_distutils also. I think it actually > was at one point...? > I think it's o.k to put it in scipy_distutils, though perhaps a scipy_testing would be cleaner...except for proliferating the number of packages if that matters. -Travis O. From eric at enthought.com Mon Sep 16 19:03:34 2002 From: eric at enthought.com (eric jones) Date: Mon, 16 Sep 2002 18:03:34 -0500 Subject: [SciPy-dev] movement of testing.py to scipy_distutils In-Reply-To: Message-ID: <000101c25dd5$483a9050$6b01a8c0@ericlaptop> > -----Original Message----- > From: scipy-dev-admin at scipy.net [mailto:scipy-dev-admin at scipy.net] On > Behalf Of Pearu Peterson > Sent: Monday, September 16, 2002 4:38 PM > To: scipy-dev at scipy.net > Subject: Re: [SciPy-dev] movement of testing.py to scipy_distutils > > > On Mon, 16 Sep 2002, eric jones wrote: > > > Anyway, opinions and suggestions welcome. I'd like to get a version of > > the weave stuff packaged up and ready for people to test (although docs > > are still not updated) by the end of the day. > > Would it make sense to move also lib2def.py to scipy_distutils? > > Namely, Windows users of f2py need that, and currently I just copy > lib2def.py to scipy_distutils when making a snapshot of f2py. > But this results in two copies of lib2def.py lying around when also scipy > is used. +1 I'll do that when I move the other over tonight. Thanks for the feedback. eric From eric at enthought.com Mon Sep 16 22:15:14 2002 From: eric at enthought.com (eric jones) Date: Mon, 16 Sep 2002 21:15:14 -0500 Subject: [SciPy-dev] RE: [Scipy-cvs] CVS update: world/scipy/scipy_distutils/command In-Reply-To: <20020917012557.011673EAD4@www.scipy.com> Message-ID: <000301c25df0$0f88e840$6b01a8c0@ericlaptop> That is probably true. I remember that the changes Pearu added based on another user's Sun setup broke the Sun compiler on Duke's machines. I never looked into it very far, but I bet that Duke had an older compiler. Please re-factor/re-organize the code to what you believe is the minimal setup necessary for the Forte compiler on heatmizer. Thanks, eric > -----Original Message----- > From: scipy-cvs-admin at scipy.org [mailto:scipy-cvs-admin at scipy.org] On > Behalf Of skip at scipy.com > Sent: Monday, September 16, 2002 8:26 PM > To: scipy-cvs at scipy.org > Subject: [Scipy-cvs] CVS update: world/scipy/scipy_distutils/command > > > Date: Monday September 16, 2002 @ 20:25 > Author: skip > > Update of /home/cvsroot/world/scipy/scipy_distutils/command > In directory shaft:/tmp/cvs-serv11200 > > Modified Files: > build_flib.py > Log Message: > changes to get SciPy to build with Sun's Forte Fortran compilers. I > suspect there may be more changes in the near future. The > sun_fortran_compiler class seems a bit too complex to me. In fact, it > seems like it declares info for two or four compilers. Should it be > split into two or more classes? > > =================================================================== > File: build_flib.py Status: Up-to-date > > Working revision: 1.36 Tue Sep 17 01:25:57 2002 > Repository revision: 1.36 > /home/cvsroot/world/scipy/scipy_distutils/command/build_flib.py,v > > Existing Tags: > Daily_Snapshot_01-11-2002 (revision: 1.8) > pre_compiler_removal (revision: 1.5) > > _______________________________________________ > Scipy-cvs mailing list > Scipy-cvs at scipy.org > http://scipy.net/mailman/listinfo/scipy-cvs From pearu at cens.ioc.ee Tue Sep 17 09:22:27 2002 From: pearu at cens.ioc.ee (Pearu Peterson) Date: Tue, 17 Sep 2002 16:22:27 +0300 (EEST) Subject: [SciPy-dev] Re: [Scipy-cvs] CVS update: world/scipy/scipy_distutils/command In-Reply-To: <20020917125215.5BC953EAD4@www.scipy.com> Message-ID: Hi Skip, Few comments about Sun compiler support: 1) Does anyone have idea how many different Sun Fortran are there available? If there are many, then it is fine to introduce new compiler classes, may be something like the following: sun_generic_fortran_compiler sun_forte_fortran_compiler sun_studio_fortran_compiler that have appropiate ver_match strings and *different* vendor attributes. 2) f90 should not have -fixed option specified as scipy_distutils should be able to compile also Fortran 90 free format sources, even if currently there are any F90 sources in Scipy. Note that there are f2py users that wrap F90 free format codes to Python. If your system does not have f77 command (that under Sun should be kinda "alias" to `f90 -fixed`) then specify fc = 'f90 -fixed' (though, I doubt that there is a real need for that). 3) Did you check that calling self.find_lib_dir() is really necessary? Usually, using f77 or f90 as a linker will take care of specifying proper library directories. The same comment goes to items in self.libraries list. Thanks, Pearu From skip at pobox.com Tue Sep 17 10:58:12 2002 From: skip at pobox.com (Skip Montanaro) Date: Tue, 17 Sep 2002 09:58:12 -0500 Subject: [SciPy-dev] Re: [Scipy-cvs] CVS update: world/scipy/scipy_distutils/command In-Reply-To: References: <20020917125215.5BC953EAD4@www.scipy.com> Message-ID: <15751.17156.334036.898863@12-248-11-90.client.attbi.com> Pearu> Few comments about Sun compiler support: Pearu> 1) Does anyone have idea how many different Sun Fortran are there Pearu> available? If there are many, then it is fine to introduce new Pearu> compiler classes, may be something like the following: Agreed, I suppose. The problem is getting enough heads together to figure everything out. I don't think there is a "generic" Fortran compiler for Suns. I think it's always been an add-on. Pearu> 2) f90 should not have -fixed option specified as scipy_distutils Pearu> should be able to compile also Fortran 90 free format sources, Pearu> even if currently there are any F90 sources in Scipy. Note Pearu> that there are f2py users that wrap F90 free format codes to Pearu> Python. I only changed the comment from "why fixed?" to explain to someone without the compiler man page available just what the -fixed flag is. Pearu> If your system does not have f77 command (that under Sun should Pearu> be kinda "alias" to `f90 -fixed`) then specify fc = 'f90 -fixed' Pearu> (though, I doubt that there is a real need for that). I believe "f77" on Suns really runs f90 with appropriate flags. Pearu> 3) Did you check that calling self.find_lib_dir() is really Pearu> necessary? After reading the info about the -R flag in the f90 man page I'm not sure, although I think I tried getting rid of it, but that failed. I tweaked what is there a little. It didn't handle the case where LD_RUN_PATH was not defined. I'll try disabling it again and see what happens. Skip From skip at pobox.com Tue Sep 17 11:13:41 2002 From: skip at pobox.com (Skip Montanaro) Date: Tue, 17 Sep 2002 10:13:41 -0500 Subject: [SciPy-dev] RE: [Scipy-cvs] CVS update: world/scipy/scipy_distutils/command In-Reply-To: <000301c25df0$0f88e840$6b01a8c0@ericlaptop> References: <20020917012557.011673EAD4@www.scipy.com> <000301c25df0$0f88e840$6b01a8c0@ericlaptop> Message-ID: <15751.18085.386955.658881@12-248-11-90.client.attbi.com> eric> Please re-factor/re-organize the code to what you believe is the eric> minimal setup necessary for the Forte compiler on heatmizer. Will do. Should we assume that's the minimum (e.g., that whatever the "minimal setup necessary for the Forte compiler" is should be precisely what the sun_fortran_compiler class implements)? In other words, whatever ancient compiler was running at Duke no longer counts so won't be supported? Anybody using a Sun compiler other than Forte? Please speak up. Thx, Skip From skip at pobox.com Tue Sep 17 11:13:41 2002 From: skip at pobox.com (Skip Montanaro) Date: Tue, 17 Sep 2002 10:13:41 -0500 Subject: [SciPy-dev] RE: [Scipy-cvs] CVS update: world/scipy/scipy_distutils/command In-Reply-To: <000301c25df0$0f88e840$6b01a8c0@ericlaptop> References: <20020917012557.011673EAD4@www.scipy.com> <000301c25df0$0f88e840$6b01a8c0@ericlaptop> Message-ID: <15751.18085.386955.658881@12-248-11-90.client.attbi.com> eric> Please re-factor/re-organize the code to what you believe is the eric> minimal setup necessary for the Forte compiler on heatmizer. Will do. Should we assume that's the minimum (e.g., that whatever the "minimal setup necessary for the Forte compiler" is should be precisely what the sun_fortran_compiler class implements)? In other words, whatever ancient compiler was running at Duke no longer counts so won't be supported? Anybody using a Sun compiler other than Forte? Please speak up. Thx, Skip From pearu at cens.ioc.ee Tue Sep 17 11:20:08 2002 From: pearu at cens.ioc.ee (Pearu Peterson) Date: Tue, 17 Sep 2002 18:20:08 +0300 (EEST) Subject: [SciPy-dev] Re: [Scipy-cvs] CVS update: world/scipy/scipy_distutils/command In-Reply-To: <15751.17156.334036.898863@12-248-11-90.client.attbi.com> Message-ID: On Tue, 17 Sep 2002, Skip Montanaro wrote: > > Pearu> Few comments about Sun compiler support: > > Pearu> 1) Does anyone have idea how many different Sun Fortran are there > Pearu> available? If there are many, then it is fine to introduce new > Pearu> compiler classes, may be something like the following: > > Agreed, I suppose. The problem is getting enough heads together to figure > everything out. I don't think there is a "generic" Fortran compiler for > Suns. I think it's always been an add-on. Could we make a list of questions for Sun users and send it to scipy-user list? Right now I have the following questions in mind: 0) What Fortran 77 and Fortran 90 compiler is in your system? Are there Internet links to compiler manual pages available? 1) What is the output of the following commands? f77 -V f90 -V Use appropiate command name if it differs from f77 or f90. 2) Do you have the following libraries in your system?: fsu, F77, M77, sunmath, F77_mt, sunmath_mt, mvec, f77compat, f90 Give also their locations. 3) For expert users: what are desired optimization flags for the Fortran compilers? > Pearu> 2) f90 should not have -fixed option specified as scipy_distutils > Pearu> should be able to compile also Fortran 90 free format sources, > Pearu> even if currently there are any F90 sources in Scipy. Note > Pearu> that there are f2py users that wrap F90 free format codes to > Pearu> Python. > > I only changed the comment from "why fixed?" to explain to someone without > the compiler man page available just what the -fixed flag is. This was my comment that has stayed there for ages already. I was hoping that someone who produced this code would fix this, or at least explain the reasons for its need. But now I am pretty sure that this option will cause problems if someone tries to compiler F90 free format sources. > Pearu> If your system does not have f77 command (that under Sun should > Pearu> be kinda "alias" to `f90 -fixed`) then specify fc = 'f90 -fixed' > Pearu> (though, I doubt that there is a real need for that). > > I believe "f77" on Suns really runs f90 with appropriate flags. Yes, at least Forte and I guess newer compilers do that. Not sure about older compilers. Pearu From skip at pobox.com Tue Sep 17 12:03:18 2002 From: skip at pobox.com (Skip Montanaro) Date: Tue, 17 Sep 2002 11:03:18 -0500 Subject: [SciPy-dev] Re: [Scipy-cvs] CVS update: world/scipy/scipy_distutils/command In-Reply-To: References: <15751.17156.334036.898863@12-248-11-90.client.attbi.com> Message-ID: <15751.21062.620593.369529@12-248-11-90.client.attbi.com> Pearu> 2) f90 should not have -fixed option specified as scipy_distutils Pearu> should be able to compile also Fortran 90 free format sources, Pearu> even if currently there are any F90 sources in Scipy. Note Pearu> that there are f2py users that wrap F90 free format codes to Pearu> Python. >> I only changed the comment from "why fixed?" to explain to someone >> without the compiler man page available just what the -fixed flag is. Pearu> This was my comment that has stayed there for ages already. I Pearu> was hoping that someone who produced this code would fix this, or Pearu> at least explain the reasons for its need. But now I am pretty Pearu> sure that this option will cause problems if someone tries to Pearu> compiler F90 free format sources. It does appear that Sun's intention is that the source file suffix is the way you get specific behavior. ".f" should probably always be interpreted as Fortran-77. Do other compilers have the same (or similar) conventions? Skip From pearu at cens.ioc.ee Tue Sep 17 12:23:39 2002 From: pearu at cens.ioc.ee (Pearu Peterson) Date: Tue, 17 Sep 2002 19:23:39 +0300 (EEST) Subject: [SciPy-dev] Re: [Scipy-cvs] CVS update: world/scipy/scipy_distutils/command In-Reply-To: <15751.21062.620593.369529@12-248-11-90.client.attbi.com> Message-ID: On Tue, 17 Sep 2002, Skip Montanaro wrote: > It does appear that Sun's intention is that the source file suffix is the > way you get specific behavior. ".f" should probably always be interpreted as > Fortran-77. Do other compilers have the same (or similar) conventions? Yes, almost.. gcc has this convention. Intel Fortran compiler interprets ".f" as fixed format Fortran source (not necessarily Fortran 77). MIPSpro Fortran compilers have separate f77 and f90. E.g. f77 compiles f90 source but warns that f77 linker is used. Anyway, ".f" is interpreted as fixed format Fortran source again. Pearu From eric at enthought.com Tue Sep 17 16:30:47 2002 From: eric at enthought.com (eric jones) Date: Tue, 17 Sep 2002 15:30:47 -0500 Subject: [SciPy-dev] RE: [Scipy-cvs] CVS update: world/scipy/weave In-Reply-To: <20020917183805.7A4263EAD4@www.scipy.com> Message-ID: <000001c25e89$1b482a80$6b01a8c0@ericlaptop> Hey Pearu, That is a weird thing to be breaking the tests. I made the change in preparation of weave being installed as a separate package. That change will also be made today to the __init__.py file. At that point will need to change this to Import weave But this will work for now. Thanks for tracking it down. Eric > -----Original Message----- > From: scipy-cvs-admin at scipy.org [mailto:scipy-cvs-admin at scipy.org] On > Behalf Of Pearu Peterson > Sent: Tuesday, September 17, 2002 1:38 PM > To: scipy-cvs at scipy.org > Subject: [Scipy-cvs] CVS update: world/scipy/weave > > > Date: Tuesday September 17, 2002 @ 13:38 > Author: pearu > > Update of /home/cvsroot/world/scipy/weave > In directory shaft:/tmp/cvs-serv25714 > > Modified Files: > __init__.py > Log Message: > This fixes infinite loop when testing weave > > =================================================================== > File: __init__.py Status: Up-to-date > > Working revision: 1.10 Tue Sep 17 18:38:05 2002 > Repository revision: 1.10 > /home/cvsroot/world/scipy/weave/__init__.py,v > > Existing Tags: > pre_classify_conversion (revision: 1.3) > Daily_Snapshot_01-11-2002 (revision: 1.2) > pre_compiler_removal (revision: 1.2) > release_0_2_0 (revision: 1.2) > > _______________________________________________ > Scipy-cvs mailing list > Scipy-cvs at scipy.org > http://scipy.net/mailman/listinfo/scipy-cvs From patmiller at llnl.gov Tue Sep 17 16:49:50 2002 From: patmiller at llnl.gov (Pat Miller) Date: Tue, 17 Sep 2002 13:49:50 -0700 Subject: [SciPy-dev] RE: [Scipy-cvs] CVS update: world/scipy/scipy_distutils/command References: <000301c25df0$0f88e840$6b01a8c0@ericlaptop> Message-ID: <3D87956E.5B78B2B@llnl.gov> Our compilers are organized to compile .F and .F90 as F77 and F90 with preprocessing -- Patrick Miller | (925) 423-0309 | http://www.llnl.gov/CASC/people/pmiller Work is of two kinds: first, altering the position of matter at or near the earth's surface relative to other matter; second, telling other people to do so. The first is unpleasant and ill-paid; the second is pleasant and highly paid. -- Bertrand Russell, philosopher, mathematician, and author (1872-1970) From eric at enthought.com Wed Sep 18 17:28:54 2002 From: eric at enthought.com (eric jones) Date: Wed, 18 Sep 2002 16:28:54 -0500 Subject: [SciPy-dev] scipy status Message-ID: <000001c25f5a$643a8f90$6b01a8c0@ericlaptop> Hey group, I have a few days coming up here to work on getting a SciPy 0.2 out the door. It looks like it is buiding and passing all test on windows, and I think it is doing OK on Linux. Sun is close or finished (Skip?). What I'd like to know is if there are any other known issues that we need to solve before pushing 0.2 out? FFT Pearu, how are things on the fft changes? I never heard back from djb on the license issue. I think we are in the clear to use his code, but he also seems to get quite exserised with people who cross him: http://cr.yp.to/distributors.html We are statically linking his code so the comments here about installing it in the correct places doesn't seem to apply -- they look to be aimed at his executables not library files. My vote is to move ahead with using them and then remove them later if he does not like what we are doing. We can back off again to fftpack with the same functionality and also the fftw wrappers are still around for those wanting to use it and not constrained by the GPL. Does this sound like a reasonable plan for 0.2? LINALG How is linalg? This is by far the biggest build headache, but it does seem to be working against atlas on windows and linux and against LAPACK and BLAS on Sun. Any other specific packages that need mentioning? Thanks, eric From pearu at cens.ioc.ee Wed Sep 18 19:28:51 2002 From: pearu at cens.ioc.ee (Pearu Peterson) Date: Thu, 19 Sep 2002 02:28:51 +0300 (EEST) Subject: [SciPy-dev] scipy status In-Reply-To: <000001c25f5a$643a8f90$6b01a8c0@ericlaptop> Message-ID: On Wed, 18 Sep 2002, eric jones wrote: > Hey group, > > I have a few days coming up here to work on getting a SciPy 0.2 out the > door. It looks like it is buiding and passing all test on windows, and > I think it is doing OK on Linux. Sun is close or finished (Skip?). > > What I'd like to know is if there are any other known issues that we > need to solve before pushing 0.2 out? > > FFT > Pearu, how are things on the fft changes? I never heard back from djb > on the license issue. I think we are in the clear to use his code, but > he also seems to get quite exserised with people who cross him: > http://cr.yp.to/distributors.html > > We are statically linking his code so the comments here about installing > it in the correct places doesn't seem to apply -- they look to be aimed > at his executables not library files. > > My vote is to move ahead with using them and then remove them later if > he does not like what we are doing. We can back off again to fftpack > with the same functionality and also the fftw wrappers are still around > for those wanting to use it and not constrained by the GPL. fftpack2 is almost complete in the sense that wrappers to C/Fortran libraries are finished, there are rather complete tests, and high-level functions are documented. Right now I am fine-tuning differentiation transform that can be sensitive to numerical noise from FFT algorithm if the signal is very long (in my application I need the numerical noise level to be absolutely minimal and that depends on accuracy properties of fft libraries. Btw, djbfft turns out to be also the most accurate fft library compared to FFTPACK and FFTW). Anyway, fftpack2 is designed to use optimal FFT library combination for different jobs. Currently, FFTPACK, FFTW, and DJBFFT libraries are supported. Last two are optional and used only if system_info.py detects them. It turns out that DJBFFT is fastest for power-of-two 1-D transforms and FFTW is superior for N-D transforms and non-power-of-two transforms. Some of the timings are included at the end of this message. What fftpack2 is missing? I haven't implemented yet some of convenience functions such as fft2, hfft, fftshift, fftfreq, cont_ft, zeropad. They all are Python functions and can be copied from the current fftpack. In addition, these functions need unittests. I think I can finish fftpack2 by this weekend so that it would be ready for review first as a stand alone package and if you are satisfied then it can be committed to scipy. About djbfft and scipy. djbfft builds from its makefile. This is fine under unix but I have no idea if this will be an issue for Windows. Could someone try it out on Windows? If it builds, then also test whether system_info.py can detect it and may be adjust it accordingly? > LINALG > How is linalg? This is by far the biggest build headache, but it does > seem to be working against atlas on windows and linux and against LAPACK > and BLAS on Sun. linalg builds fine provided that ATLAS or LAPACK/BLAS are the latest, built/installed properly, and preferably there are no other atlas or lapack libraries installed on the system. I think a detailed SciPy build HOWTO would be very useful to reduce the build headache. INSTALL.txt should be a starting point but there are still some obsolete instructions at the scipy site that people probably try out first and get into problems. > Any other specific packages that need mentioning? I would mention packages that lack more or less complete unittests. Btw, I just noticed that importing scipy assumes that wxPython is installed and DISPLAY must be working. When trying to import scipy from a different computer without X connection, I get: >>> import scipy Gtk-WARNING **: cannot open display: and python quits. Any idea how to fix this? Pearu Fast Fourier Transform ======================================================== | real input | complex input -------------------------------------------------------- size |fftpack2| FFT | scipy |fftpack2| FFT | scipy -------------------------------------------------------- 100 | 0.38 | 0.41 | 0.37 | 0.46 | 0.41 | 0.37 secs 7000 calls 1000 | 0.30 | 0.68 | 0.54 | 0.68 | 0.68 | 0.54 secs 2000 256 | 0.59 | 0.89 | 0.62 | 0.67 | 0.89 | 0.63 secs 10000 512 | 0.76 | 1.59 | 0.97 | 0.96 | 1.63 | 1.01 secs 10000 1024 | 0.12 | 0.32 | 0.17 | 0.16 | 0.33 | 0.18 secs 1000 2048 | 0.20 | 0.71 | 0.34 | 0.30 | 0.77 | 0.37 secs 1000 4096 | 0.27 | 0.84 | 0.46 | 0.45 | 0.94 | 0.59 secs 500 8192 | 0.81 | 3.21 | 2.36 | 1.36 | 3.23 | 2.46 secs 500 Inverse Fast Fourier Transform ======================================================== | real input | complex input -------------------------------------------------------- size |fftpack2| FFT | scipy |fftpack2| FFT | scipy -------------------------------------------------------- 100 | 0.38 | 0.87 | 0.81 | 0.52 | 0.87 | 0.82 secs 7000 calls 1000 | 0.31 | 1.19 | 1.07 | 0.85 | 1.20 | 1.06 secs 2000 256 | 0.61 | 1.71 | 1.47 | 0.71 | 1.76 | 1.50 secs 10000 512 | 0.80 | 2.85 | 2.24 | 1.05 | 2.84 | 2.22 secs 10000 1024 | 0.12 | 0.54 | 0.39 | 0.18 | 0.54 | 0.39 secs 1000 2048 | 0.22 | 1.28 | 0.85 | 0.36 | 1.24 | 0.90 secs 1000 4096 | 0.30 | 1.45 | 1.26 | 0.52 | 1.50 | 1.22 secs 500 8192 | 0.84 | 4.51 | 3.73 | 1.71 | 4.39 | 3.85 secs 500 Multi-dimensional Fast Fourier Transform ======================================================== | real input | complex input -------------------------------------------------------- size |fftpack2| FFT | scipy |fftpack2| FFT | scipy -------------------------------------------------------- 100x100 | 0.37 | 0.76 | 0.61 | 0.41 | 0.74 | 0.64 secs 100calls 1000x100 | 0.45 | 0.64 | 0.53 | 0.49 | 0.65 | 0.55 secs 7 256x256 | 0.44 | 0.62 | 0.55 | 0.43 | 0.63 | 0.46 secs 10 512x512 | 0.62 | 0.83 | 0.64 | 0.63 | 0.83 | 0.60 secs 3 Differentiation of periodic functions ===================================== size | optimized | naive ------------------------------------- 100 | 0.25 | 1.56 (secs for 1500 calls) 1000 | 0.19 | 1.69 (secs for 300 calls) 256 | 0.34 | 2.53 (secs for 1500 calls) 512 | 0.36 | 2.88 (secs for 1000 calls) 1024 | 0.31 | 2.75 (secs for 500 calls) 2048 | 0.24 | 2.34 (secs for 200 calls) 4096 | 0.27 | 2.32 (secs for 100 calls) 8192 | 0.31 | 2.46 (secs for 50 calls) Tilbert transform of periodic functions ========================================= size | optimized | naive ----------------------------------------- 100 | 0.22 | 1.44 (secs for 1500 calls) 1000 | 0.15 | 1.27 (secs for 300 calls) 256 | 0.28 | 2.05 (secs for 1500 calls) 512 | 0.27 | 2.20 (secs for 1000 calls) 1024 | 0.21 | 2.06 (secs for 500 calls) 2048 | 0.16 | 1.67 (secs for 200 calls) 4096 | 0.20 | 1.64 (secs for 100 calls) 8192 | 0.24 | 1.70 (secs for 50 calls) Hilbert transform of periodic functions ========================================= size | optimized | naive ----------------------------------------- 100 | 0.22 | 1.33 (secs for 1500 calls) 1000 | 0.13 | 1.09 (secs for 300 calls) 256 | 0.26 | 1.84 (secs for 1500 calls) 512 | 0.26 | 1.88 (secs for 1000 calls) 1024 | 0.21 | 1.74 (secs for 500 calls) 2048 | 0.17 | 1.41 (secs for 200 calls) 4096 | 0.19 | 1.47 (secs for 100 calls) 8192 | 0.21 | 1.44 (secs for 50 calls) From oliphant at ee.byu.edu Wed Sep 18 19:47:12 2002 From: oliphant at ee.byu.edu (Travis Oliphant) Date: Wed, 18 Sep 2002 17:47:12 -0600 (MDT) Subject: [SciPy-dev] scipy status In-Reply-To: <000001c25f5a$643a8f90$6b01a8c0@ericlaptop> Message-ID: > > Any other specific packages that need mentioning? There's a couple of bugs on the bug-tracker that haven't been cleared yet. One is the special.ellipeinc error which I agree with (it doesn't match the definition checked with integrate.quad). I'll look into the cephes source... Who can assign bugs on the sourceforge site? -Travis From eric at enthought.com Wed Sep 18 22:43:56 2002 From: eric at enthought.com (eric jones) Date: Wed, 18 Sep 2002 21:43:56 -0500 Subject: [SciPy-dev] scipy status In-Reply-To: Message-ID: <000001c25f86$6655ca70$6b01a8c0@ericlaptop> Also, we are working on getting Roundup running before the release so that we'll an on-site bug tracker for scipy, chaco and weave. This is the same one that the python development team will be moving to in the future. Hopefully it will work well for us. As far as who can assign bugs, I'm not sure. I haven't used sourceforge in a while and don't even remember my login... Maybe travis V. can. Eric > -----Original Message----- > From: scipy-dev-admin at scipy.net [mailto:scipy-dev-admin at scipy.net] On > Behalf Of Travis Oliphant > Sent: Wednesday, September 18, 2002 6:47 PM > To: scipy-dev at scipy.net > Subject: Re: [SciPy-dev] scipy status > > > > > > Any other specific packages that need mentioning? > > There's a couple of bugs on the bug-tracker that haven't been cleared yet. > > One is the special.ellipeinc error which I agree with (it doesn't match > the definition checked with integrate.quad). I'll look into the cephes > source... > > Who can assign bugs on the sourceforge site? > > > -Travis > > _______________________________________________ > Scipy-dev mailing list > Scipy-dev at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-dev From eric at enthought.com Thu Sep 19 03:04:58 2002 From: eric at enthought.com (eric jones) Date: Thu, 19 Sep 2002 02:04:58 -0500 Subject: [SciPy-dev] mingw2.0 (gcc 3.2) troubles with weave Message-ID: <000001c25faa$de26f7d0$6b01a8c0@ericlaptop> Travis V. saw that the new mingw tool set with gcc 3.2 was out for MS windows, so I tried it out with weave. The results aren't that great. The biggest problem is that exception handling is causing seg faults. Dag. This junk again. Exceptions must be really tricky to get right/compatible-with-other-compilers in C++ because it seems to cause weave the most grief. I'm not sure at the moment if it is because I am using an MSVC compiled version of python and then loading gcc 3.2 compiled modules into it, or if it is a more general problem with mingw2.0's exception handling. I will need to compile a mingw version of python to find out (not done and maybe not worth it since 2.95.3 works). The other thing that might be an issue is the dllwrap linker flags in weave. The good news is that blitz is now compatible with gcc3.2. The bad news is, with the current compiler settings, it compiles slower and produces slower code than 2.95.3. Add that 2.95.3 doesn't have the problem with exceptions, and the picture ain't so purty. Here are the timings for gcc 2.95.3 on a median filter for float32: Compile time (sec) 11.8870 Exec time(sec): 0.0800 And gcc 3.2 Compile time (sec): 18.1960 Exec time: 0.0900 While the exec time is not really long enough to be reliable, it has been consistent across runs. Dog. And the night started out so promising... Oh, I would like to here if anyone gets a chance to test the most recent weave (from CVS) against gcc 3.x on Linux. And for other platforms, it should just require a jiggering of the blitz-20001213/blitz/config.h file to reflect your platform (cut and paste from the config-.h file in the same directory). See ya, eric From eric at enthought.com Thu Sep 19 03:46:30 2002 From: eric at enthought.com (eric jones) Date: Thu, 19 Sep 2002 02:46:30 -0500 Subject: [SciPy-dev] scipy status In-Reply-To: Message-ID: <000101c25fb0$aaeff2d0$6b01a8c0@ericlaptop> Hey Pearu, > On Wed, 18 Sep 2002, eric jones wrote: > > > Hey group, > > > > I have a few days coming up here to work on getting a SciPy 0.2 out the > > door. It looks like it is buiding and passing all test on windows, and > > I think it is doing OK on Linux. Sun is close or finished (Skip?). > > > > What I'd like to know is if there are any other known issues that we > > need to solve before pushing 0.2 out? > > > > FFT > > Pearu, how are things on the fft changes? I never heard back from djb > > on the license issue. I think we are in the clear to use his code, but > > he also seems to get quite exserised with people who cross him: > > http://cr.yp.to/distributors.html > > > > We are statically linking his code so the comments here about installing > > it in the correct places doesn't seem to apply -- they look to be aimed > > at his executables not library files. > > > > My vote is to move ahead with using them and then remove them later if > > he does not like what we are doing. We can back off again to fftpack > > with the same functionality and also the fftw wrappers are still around > > for those wanting to use it and not constrained by the GPL. > > fftpack2 is almost complete in the sense that wrappers to C/Fortran > libraries are finished, there are rather complete tests, and high-level > functions are documented. Right now I am fine-tuning differentiation > transform that can be sensitive to numerical noise from FFT > algorithm if the signal is very long (in my application I need the > numerical noise level to be absolutely minimal and that depends on > accuracy properties of fft libraries. Btw, djbfft turns out to be > also the most accurate fft library compared to FFTPACK and FFTW). > > Anyway, fftpack2 is designed to use optimal FFT library combination for > different jobs. Currently, FFTPACK, FFTW, and DJBFFT libraries are > supported. Last two are optional and used only if system_info.py detects > them. It turns out that DJBFFT is fastest for power-of-two 1-D transforms > and FFTW is superior for N-D transforms and non-power-of-two > transforms. Some of the timings are included at the end of this message. It looks like you've done some very good work here. There are some very big wins over the current code. I'm excited about getting it into scipy. > > What fftpack2 is missing? I haven't implemented yet some of > convenience functions such as fft2, hfft, fftshift, fftfreq, cont_ft, > zeropad. They all are Python functions and can be copied from the current > fftpack. In addition, these functions need unittests. > > I think I can finish fftpack2 by this weekend so that it would be ready > for review first as a stand alone package and if you are satisfied then > it can be committed to scipy. Sounds good. > > About djbfft and scipy. > djbfft builds from its makefile. This is fine under unix but I have no > idea if this will be an issue for Windows. Could someone try it out on > Windows? If it builds, then also test whether system_info.py can detect it > and may be adjust it accordingly? Is it possible to dump the source into the tree and let distutils build it? That would be my preferred solution. > > > LINALG > > How is linalg? This is by far the biggest build headache, but it does > > seem to be working against atlas on windows and linux and against LAPACK > > and BLAS on Sun. > > linalg builds fine provided that ATLAS or LAPACK/BLAS are the latest, > built/installed properly, and preferably there are no other atlas or > lapack libraries installed on the system. I think a detailed SciPy build > HOWTO would be very useful to reduce the build headache. > INSTALL.txt should be a starting point but there are still some obsolete > instructions at the scipy site that people probably try out first and get > into problems. > > > Any other specific packages that need mentioning? > > I would mention packages that lack more or less complete unittests. Yes. > > > Btw, I just noticed that importing scipy assumes that wxPython is > installed and DISPLAY must be working. When trying to import scipy from a > different computer without X connection, I get: > > >>> import scipy > > Gtk-WARNING **: cannot open display: > > and python quits. Any idea how to fix this? I removed plt from the _pkgs list in __init__.py. This should fix it. I had to do the same for gplt on windows. I guess I need to check for DISPLAY in gui_thread or wxplt or somewhere like that for the *real* solution. We'll mess with this in Chaco instead of here. I think Dave is about to pull the trigger on its release. Within a few weeks, it should do everything plt does and pretty much replace it. I think gplt and xplt will have to stick around for a while because they have quite a bit more functionality still. See ya, Eric From oliphant at ee.byu.edu Thu Sep 19 21:01:00 2002 From: oliphant at ee.byu.edu (Travis Oliphant) Date: Thu, 19 Sep 2002 19:01:00 -0600 (MDT) Subject: [SciPy-dev] Installing chaco Message-ID: I was trying to install Chaco and I get the error. python setup.py install Traceback (most recent call last): File "setup.py", line 102, in ? scipy_base_config = get_package_config( 'scipy_base' ) File "setup.py", line 37, in get_package_config mod = __import__( 'setup_' + name ) ImportError: No module named setup_scipy_base Am I missing something? -Travis O. From eric at enthought.com Fri Sep 20 03:09:25 2002 From: eric at enthought.com (eric jones) Date: Fri, 20 Sep 2002 02:09:25 -0500 Subject: [SciPy-dev] Installing chaco In-Reply-To: Message-ID: <000b01c26074$a78db4f0$6b01a8c0@ericlaptop> Dave was working through distutils stuff with this today. It was non-trivial to get it to include scipy_base in the distribution, and I think he ended up requiring a specific directory structure. One of the problems was getting distutils to pick up the fastumath_*.inc files. Could we rename these to .c files? Then distutils would handle them automatically. Hopefully dave can shed some light on your import issue. Eric > -----Original Message----- > From: scipy-dev-admin at scipy.net [mailto:scipy-dev-admin at scipy.net] On > Behalf Of Travis Oliphant > Sent: Thursday, September 19, 2002 8:01 PM > To: scipy-dev at scipy.org > Subject: [SciPy-dev] Installing chaco > > > I was trying to install Chaco and I get the error. > > python setup.py install > Traceback (most recent call last): > File "setup.py", line 102, in ? > scipy_base_config = get_package_config( 'scipy_base' ) > File "setup.py", line 37, in get_package_config > mod = __import__( 'setup_' + name ) > ImportError: No module named setup_scipy_base > > Am I missing something? > > -Travis O. > > > > _______________________________________________ > Scipy-dev mailing list > Scipy-dev at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-dev From pearu at cens.ioc.ee Fri Sep 20 03:18:00 2002 From: pearu at cens.ioc.ee (Pearu Peterson) Date: Fri, 20 Sep 2002 10:18:00 +0300 (EEST) Subject: [SciPy-dev] Installing chaco In-Reply-To: <000b01c26074$a78db4f0$6b01a8c0@ericlaptop> Message-ID: On Fri, 20 Sep 2002, eric jones wrote: > Dave was working through distutils stuff with this today. It was > non-trivial to get it to include scipy_base in the distribution, and I > think he ended up requiring a specific directory structure. I don't know what these problems would have been but in f2py I just grab scipy_distutils directly from CVS when building distribution. See f2py setup.py file for details. > One of the problems was getting distutils to pick up the fastumath_*.inc > files. Could we rename these to .c files? Then distutils would handle > them automatically. Hmm, did you try to use MANIFEST.in? Sometimes when adding new (non standard) files to it, you need to remove the generated MANIFEST before hitting 'setup.py sdist' Pearu From skip at pobox.com Fri Sep 20 09:04:53 2002 From: skip at pobox.com (Skip Montanaro) Date: Fri, 20 Sep 2002 08:04:53 -0500 Subject: [SciPy-dev] core dump during weave tests on Solaris Message-ID: <15755.7413.931684.795291@12-248-11-90.client.attbi.com> I'm now getting a Python core dump on Solaris if I run scipy.test(5). Running scipy.test(1) succeeds though still with a failure in test_shapiro. Here's the output of scipy.weave.test(): creating test suite for: weave.ast_tools creating test suite for: weave.standard_array_spec No test suite found for weave.accelerate_tools No test suite found for weave.base_info No test suite found for weave.base_spec No test suite found for weave.blitz_spec creating test suite for: weave.blitz_tools creating test suite for: weave.build_tools No test suite found for weave.bytecodecompiler creating test suite for: weave.c_spec creating test suite for: weave.catalog No test suite found for weave.common_info No test suite found for weave.converters No test suite found for weave.dumb_shelve No test suite found for weave.dumbdbm_patched creating test suite for: weave.ext_tools building extensions here: /home/skip/.python21_compiled/146290 building extensions here: /home/skip/.python21_compiled/146291 creating test suite for: weave.inline_tools creating test suite for: weave.size_check creating test suite for: weave.slice_handler No test suite found for weave.vtk_spec No test suite found for weave.wx_spec ...... Expression: result[1:-1,1:-1] = (b[1:-1,1:-1] + b[2:,1:-1] + b[:-2,1:-1]+ b[1:-1,2:] + b[1:-1,:-2]) / 5. Run: (10, 10) f "/home/skip/tmp/sunos5/2.1/lib/python2.1/site-packages/weave/blitz-20001213/blitz/tinyvec.h", line 488: Error: Unable to parse field declaration in class template: skipping field. "/home/skip/tmp/sunos5/2.1/lib/python2.1/site-packages/weave/blitz-20001213/blitz/array/storage.h", line 279: Where: While specializing "blitz::GeneralArrayStorage<1>". "/home/skip/tmp/sunos5/2.1/lib/python2.1/site-packages/weave/blitz-20001213/blitz/array/storage.h", line 279: Where: Specialized in non-template code. "/home/skip/tmp/sunos5/2.1/lib/python2.1/site-packages/weave/blitz-20001213/blitz/array/storage.h", line 237: Error: The type "blitz::TinyVector" is incomplete. "/home/skip/tmp/sunos5/2.1/lib/python2.1/site-packages/weave/blitz-20001213/blitz/array/storage.h", line 279: Where: While specializing "blitz::GeneralArrayStorage<1>". "/home/skip/tmp/sunos5/2.1/lib/python2.1/site-packages/weave/blitz-20001213/blitz/array/storage.h", line 279: Where: Specialized in non-template code. "/home/skip/tmp/sunos5/2.1/lib/python2.1/site-packages/weave/blitz-20001213/blitz/tinyvec.h", line 488: Error: Unable to parse field declaration in class template: skipping field. "/home/skip/tmp/sunos5/2.1/lib/python2.1/site-packages/weave/blitz-20001213/blitz/array/storage.h", line 279: Where: While specializing "blitz::GeneralArrayStorage<1>". "/home/skip/tmp/sunos5/2.1/lib/python2.1/site-packages/weave/blitz-20001213/blitz/array/storage.h", line 279: Where: Specialized in non-template code. "/home/skip/tmp/sunos5/2.1/lib/python2.1/site-packages/weave/blitz-20001213/blitz/array/storage.h", line 238: Error: The type "blitz::TinyVector" is incomplete. "/home/skip/tmp/sunos5/2.1/lib/python2.1/site-packages/weave/blitz-20001213/blitz/array/storage.h", line 279: Where: While specializing "blitz::GeneralArrayStorage<1>". "/home/skip/tmp/sunos5/2.1/lib/python2.1/site-packages/weave/blitz-20001213/blitz/array/storage.h", line 279: Where: Specialized in non-template code. "/home/skip/tmp/sunos5/2.1/lib/python2.1/site-packages/weave/blitz-20001213/blitz/tinyvec.h", line 488: Error: Unable to parse field declaration in class template: skipping field. "/home/skip/tmp/sunos5/2.1/lib/python2.1/site-packages/weave/blitz-20001213/blitz/array/storage.h", line 279: Where: While specializing "blitz::GeneralArrayStorage<1>". "/home/skip/tmp/sunos5/2.1/lib/python2.1/site-packages/weave/blitz-20001213/blitz/array/storage.h", line 279: Where: Specialized in non-template code. "/home/skip/tmp/sunos5/2.1/lib/python2.1/site-packages/weave/blitz-20001213/blitz/array/storage.h", line 239: Error: The type "blitz::TinyVector" is incomplete. "/home/skip/tmp/sunos5/2.1/lib/python2.1/site-packages/weave/blitz-20001213/blitz/array/storage.h", line 279: Where: While specializing "blitz::GeneralArrayStorage<1>". "/home/skip/tmp/sunos5/2.1/lib/python2.1/site-packages/weave/blitz-20001213/blitz/array/storage.h", line 279: Where: Specialized in non-template code. "/home/skip/tmp/sunos5/2.1/lib/python2.1/site-packages/weave/blitz-20001213/blitz/array/storage.h", line 254: Error: blitz::GeneralArrayStorage<1>::ordering_ is not accessible from blitz::FortranArray<1>. "/home/skip/tmp/sunos5/2.1/lib/python2.1/site-packages/weave/blitz-20001213/blitz/array/storage.h", line 279: Where: While specializing "blitz::FortranArray<1>". "/home/skip/tmp/sunos5/2.1/lib/python2.1/site-packages/weave/blitz-20001213/blitz/array/storage.h", line 279: Where: Specialized in non-template code. "/home/skip/tmp/sunos5/2.1/lib/python2.1/site-packages/weave/blitz-20001213/blitz/array/storage.h", line 255: Error: blitz::GeneralArrayStorage<1>::ascendingFlag_ is not accessible from blitz::FortranArray<1>. "/home/skip/tmp/sunos5/2.1/lib/python2.1/site-packages/weave/blitz-20001213/blitz/array/storage.h", line 279: Where: While specializing "blitz::FortranArray<1>". "/home/skip/tmp/sunos5/2.1/lib/python2.1/site-packages/weave/blitz-20001213/blitz/array/storage.h", line 279: Where: Specialized in non-template code. "/home/skip/tmp/sunos5/2.1/lib/python2.1/site-packages/weave/blitz-20001213/blitz/array/storage.h", line 256: Error: blitz::GeneralArrayStorage<1>::base_ is not accessible from blitz::FortranArray<1>. "/home/skip/tmp/sunos5/2.1/lib/python2.1/site-packages/weave/blitz-20001213/blitz/array/storage.h", line 279: Where: While specializing "blitz::FortranArray<1>". "/home/skip/tmp/sunos5/2.1/lib/python2.1/site-packages/weave/blitz-20001213/blitz/array/storage.h", line 279: Where: Specialized in non-template code. "/home/skip/tmp/sunos5/2.1/lib/python2.1/site-packages/weave/blitz-20001213/blitz/tinyvec.h", line 488: Error: Unable to parse field declaration in class template: skipping field. "/home/skip/tmp/sunos5/2.1/lib/python2.1/site-packages/weave/blitz-20001213/blitz/tinyvec.h", line 488: Error: Unable to parse field declaration in class template: skipping field. "/home/skip/tmp/sunos5/2.1/lib/python2.1/site-packages/weave/blitz-20001213/blitz/tinyvec.h", line 488: Error: Unable to parse field declaration in class template: skipping field. "/home/skip/tmp/sunos5/2.1/lib/python2.1/site-packages/weave/blitz-20001213/blitz/tinyvec.h", line 488: Error: Unable to parse field declaration in class template: skipping field. "/home/skip/tmp/sunos5/2.1/lib/python2.1/site-packages/weave/blitz-20001213/blitz/tinyvec.h", line 488: Error: Unable to parse field declaration in class template: skipping field. "/home/skip/tmp/sunos5/2.1/lib/python2.1/site-packages/weave/blitz-20001213/blitz/tinyvec.h", line 488: Error: Unable to parse field declaration in class template: skipping field. "/home/skip/tmp/sunos5/2.1/lib/python2.1/site-packages/weave/blitz-20001213/blitz/tinyvec.h", line 488: Error: Unable to parse field declaration in class template: skipping field. "/home/skip/tmp/sunos5/2.1/lib/python2.1/site-packages/weave/blitz-20001213/blitz/tinyvec.h", line 488: Error: Unable to parse field declaration in class template: skipping field. "/home/skip/tmp/sunos5/2.1/lib/python2.1/site-packages/weave/blitz-20001213/blitz/tinyvec.h", line 488: Error: Unable to parse field declaration in class template: skipping field. "/home/skip/tmp/sunos5/2.1/lib/python2.1/site-packages/weave/blitz-20001213/blitz/tinyvec.h", line 488: Error: Unable to parse field declaration in class template: skipping field. "/home/skip/tmp/sunos5/2.1/lib/python2.1/site-packages/weave/blitz-20001213/blitz/tinyvec.h", line 488: Error: Unable to parse field declaration in class template: skipping field. "/home/skip/tmp/sunos5/2.1/lib/python2.1/site-packages/weave/blitz-20001213/blitz/tinyvec.h", line 488: Error: Unable to parse field declaration in class template: skipping field. "/home/skip/tmp/sunos5/2.1/lib/python2.1/site-packages/weave/blitz-20001213/blitz/tinyvec.h", line 488: Error: Unable to parse field declaration in class template: skipping field. "/home/skip/tmp/sunos5/2.1/lib/python2.1/site-packages/weave/blitz-20001213/blitz/tinyvec.h", line 488: Error: Unable to parse field declaration in class template: skipping field. "/home/skip/tmp/sunos5/2.1/lib/python2.1/site-packages/weave/blitz-20001213/blitz/tinyvec.h", line 488: Error: Unable to parse field declaration in class template: skipping field. "/home/skip/tmp/sunos5/2.1/lib/python2.1/site-packages/weave/blitz-20001213/blitz/tinyvec.h", line 488: Error: Unable to parse field declaration in class template: skipping field. "/home/skip/tmp/sunos5/2.1/lib/python2.1/site-packages/weave/blitz-20001213/blitz/array/storage.h", line 282: Where: While specializing "blitz::GeneralArrayStorage<2>". "/home/skip/tmp/sunos5/2.1/lib/python2.1/site-packages/weave/blitz-20001213/blitz/array/storage.h", line 282: Where: Specialized in non-template code. Compilation aborted, too many Error messages. Ewarning: specified build_dir '_bad_path_' does not exist or is not writable. Trying default locations ...warning: specified build_dir '..' does not exist or is not writable. Trying default locations .warning: specified build_dir '_bad_path_' does not exist or is not writable. Trying default locations ...warning: specified build_dir '..' does not exist or is not writable. Trying default locations ...Abort (core dumped) and here's a gdb backtrace (currently without symbols - let me know if you need me to recompile with -g): #0 0xff259b0c in __sigprocmask () from /usr/lib/libthread.so.1 #1 0xff24e544 in _resetsig () from /usr/lib/libthread.so.1 #2 0xff24dc34 in _sigon () from /usr/lib/libthread.so.1 #3 0xff250da8 in _thrp_kill () from /usr/lib/libthread.so.1 #4 0xfef4ae68 in raise () from /usr/lib/libc.so.1 #5 0xfef35644 in abort () from /usr/lib/libc.so.1 #6 0xff1d466c in __1cH__CimplMex_terminate6F_v_ () from /usr/lib/libCrun.so.1 #7 0xff1d59ac in __1cG__CrunIex_throw6Fpvpkn0AQstatic_type_info_pF1_v_v_ () from /usr/lib/libCrun.so.1 #8 0xfd4d2fd0 in __1cLthrow_error6FpnH_object_pkc_v_ () from /home/skip/.python21_compiled/sc_d41d8cd98f00b204e9800998ecf8427e0.so #9 0xfd4d31cc in __1cZhandle_variable_not_found6Fpc_v_ () from /home/skip/.python21_compiled/sc_d41d8cd98f00b204e9800998ecf8427e0.so #10 0xfd4d3214 in __1cMget_variable6FpcpnH_object_2_2_ () from /home/skip/.python21_compiled/sc_d41d8cd98f00b204e9800998ecf8427e0.so #11 0xfd4d32cc in __1cNcompiled_func6FpnH_object_1_1_ () from /home/skip/.python21_compiled/sc_d41d8cd98f00b204e9800998ecf8427e0.so #12 0x23c88 in call_object () #13 0x23a54 in PyEval_CallObjectWithKeywords () #14 0x7b6a4 in builtin_apply () #15 0x21bfc in eval_code2 () #16 0x242bc in fast_function () #17 0x21d4c in eval_code2 () #18 0x242bc in fast_function () #19 0x21d4c in eval_code2 () #20 0x24184 in call_eval_code2 () #21 0x23c58 in call_object () #22 0x2400c in call_method () #23 0x23c28 in call_object () #24 0x23e90 in call_instance () #25 0x23ce8 in call_object () #26 0x24660 in do_call () #27 0x21d68 in eval_code2 () #28 0x24184 in call_eval_code2 () #29 0x23c58 in call_object () #30 0x2400c in call_method () #31 0x23c28 in call_object () #32 0x23e90 in call_instance () #33 0x23ce8 in call_object () #34 0x24660 in do_call () #35 0x21d68 in eval_code2 () #36 0x24184 in call_eval_code2 () #37 0x23c58 in call_object () #38 0x2400c in call_method () #39 0x23c28 in call_object () #40 0x23e90 in call_instance () #41 0x23ce8 in call_object () #42 0x24660 in do_call () #43 0x21d68 in eval_code2 () #44 0x24184 in call_eval_code2 () #45 0x23c58 in call_object () #46 0x2400c in call_method () #47 0x23c28 in call_object () #48 0x23e90 in call_instance () #49 0x23ce8 in call_object () #50 0x24660 in do_call () #51 0x21d68 in eval_code2 () #52 0x242bc in fast_function () #53 0x21d4c in eval_code2 () #54 0x242bc in fast_function () #55 0x21d4c in eval_code2 () #56 0x1db1c in PyEval_EvalCode () #57 0x3d258 in run_node () #58 0x3c120 in PyRun_InteractiveOneFlags () #59 0x3bf14 in PyRun_InteractiveLoopFlags () #60 0x3bde4 in PyRun_AnyFileExFlags () #61 0x19e08 in Py_Main () (I tried setting the language to c++ but it still didn't demangle the C++ names.) Skip From skip at pobox.com Fri Sep 20 13:55:52 2002 From: skip at pobox.com (Skip Montanaro) Date: Fri, 20 Sep 2002 12:55:52 -0500 Subject: [SciPy-dev] zeta domain error? Message-ID: <15755.24872.107698.78032@12-248-11-90.client.attbi.com> I'm trying to narrow down the source of a Python core dump during scipy.test() under Solaris 8. When I import scipy I get /home/skip/tmp/sunos5/2.1/lib/python2.1/site-packages/scipy/linalg/lapack.py:24: UserWarning: exceptions.ImportError: No module named clapack warnings.warn(clapack.__doc__) exceptions.ImportError: No module named cblas zeta domain error I assume the cblas bit is due to not having atlas available. What is "zeta domain error"? Should it bother me? Skip From oliphant at ee.byu.edu Fri Sep 20 14:47:25 2002 From: oliphant at ee.byu.edu (Travis Oliphant) Date: Fri, 20 Sep 2002 12:47:25 -0600 (MDT) Subject: [SciPy-dev] zeta domain error? In-Reply-To: <15755.24872.107698.78032@12-248-11-90.client.attbi.com> Message-ID: On Fri, 20 Sep 2002, Skip Montanaro wrote: > > I'm trying to narrow down the source of a Python core dump during > scipy.test() under Solaris 8. When I import scipy I get > > /home/skip/tmp/sunos5/2.1/lib/python2.1/site-packages/scipy/linalg/lapack.py:24: UserWarning: exceptions.ImportError: No module named clapack > warnings.warn(clapack.__doc__) > exceptions.ImportError: No module named cblas > > zeta domain error > > I assume the cblas bit is due to not having atlas available. What is "zeta > domain error"? Should it bother me? Others have shown this error. I'm not sure exactly where it comes from, but I suspect it comes from stats/distributions.py where a constant is set _ZETA3 = special.zeta(3,1) on a module scope level (and therefore executed on import). Your zeta functions looks like it's behvaing erratically. You could try: special.zeta(3,1) to see what you get If it's not working, it will just mean that the zeta function doesn't work, which won't break all of scipy --- though I'd like to figure out why it's giving this error. -Travis O. From dmorrill at enthought.com Fri Sep 20 18:34:52 2002 From: dmorrill at enthought.com (David C. Morrill) Date: Fri, 20 Sep 2002 17:34:52 -0500 Subject: [SciPy-dev] Announce: First installable version of Chaco plotting toolkit is now available Message-ID: <001201c260f5$efcabb10$6501a8c0@Dave> We are pleased to announce that the first installable version of the Chaco plotting toolkit is now available for download at: http://www.scipy.org/site_content/chaco This package includes both the low-level Kiva drawing API as well as the high-level Chaco plotting toolkit (and demo). Its very early code with lots of features still missing; but it does work and there is a lot of function already available, so we would encourage anyone who has an interest to give it a try. We are now in the process of setting up an issue tracking system for Chaco. Anyone having trouble accessing or using the system should in the meantime feel free to use the scipy-chaco at scipy.org mailing list to report problems, make comments, request features, etc. Enjoy! -------------- next part -------------- An HTML attachment was scrubbed... URL: From fperez at pizero.colorado.edu Fri Sep 20 19:17:24 2002 From: fperez at pizero.colorado.edu (Fernando Perez) Date: Fri, 20 Sep 2002 17:17:24 -0600 (MDT) Subject: [SciPy-dev] Announce: First installable version of Chaco plotting toolkit is now available In-Reply-To: <001201c260f5$efcabb10$6501a8c0@Dave> Message-ID: On Fri, 20 Sep 2002, David C. Morrill wrote: > We are pleased to announce that the first installable version of the Chaco > plotting toolkit is now available for download at: > > http://www.scipy.org/site_content/chaco > > This package includes both the low-level Kiva drawing API as well as the > high-level Chaco plotting toolkit (and demo). > > Its very early code with lots of features still missing; but it does work > and there is a lot of function already available, so we would encourage > anyone who has an interest to give it a try. Well, the demo on the page looks beautiful and got me all excited. But... [~]> python /usr/lib/python2.2/site-packages/chaco/demo/wxdemo_plot.py Segmentation fault I get the help window to open and the plot window opens with the title "Chaco Plot Package Demonstration" and some plot areas. But these are blank areas, where only the red crosshairs appear (no plots at all). As soon as I left-click and the properties tab window pops up, it segfaults. Some system info in case anyone else sees the problem: [~]> uname -a Linux maqroll.colorado.edu 2.4.18-6mdk #1 Fri Mar 15 02:59:08 CET 2002 i686 unknown [~]> python Python 2.2 (#1, Feb 24 2002, 16:21:58) [GCC 2.96 20000731 (Mandrake Linux 8.2 2.96-0.76mdk)] on linux-i386 Type "help", "copyright", "credits" or "license" for more information I got the wxpython package from their site. Cheers, f. ps. Don't sweat this one. From past experience, getting wxpython to work is an absolute bear (at least for me). So I'm sure the problem isn't on your end but is wxwin/wxpython's fault. From travis at enthought.com Fri Sep 20 22:26:31 2002 From: travis at enthought.com (Travis N. Vaught) Date: Fri, 20 Sep 2002 21:26:31 -0500 Subject: [SciPy-dev] Announce: First installable version of Chaco plotting toolkit is now available In-Reply-To: Message-ID: Fernando, There was just a wxPython release (2.3.3.1) on the 16th, I believe, and that one broke chaco on my (windows) machine--so there are definitely some issues there. It does work nicely with a prior version, however, and I know David Morrill is looking into the issues with the new release. I downloaded 2.3.2.1 from sourceforge https://sourceforge.net/project/showfiles.php?group_id=10718 and it worked great (not the hybrid, but the regular version). Travis > -----Original Message----- > From: scipy-dev-admin at scipy.net [mailto:scipy-dev-admin at scipy.net]On > Behalf Of Fernando Perez > Sent: Friday, September 20, 2002 6:17 PM > To: scipy-dev at scipy.net > Subject: Re: [SciPy-dev] Announce: First installable version of Chaco > plotting toolkit is now available > > > On Fri, 20 Sep 2002, David C. Morrill wrote: > > > We are pleased to announce that the first installable version > of the Chaco > > plotting toolkit is now available for download at: > > > > http://www.scipy.org/site_content/chaco > > > > This package includes both the low-level Kiva drawing API as well as the > > high-level Chaco plotting toolkit (and demo). > > > > Its very early code with lots of features still missing; but it > does work > > and there is a lot of function already available, so we would encourage > > anyone who has an interest to give it a try. > > Well, the demo on the page looks beautiful and got me all excited. But... > > [~]> python /usr/lib/python2.2/site-packages/chaco/demo/wxdemo_plot.py > Segmentation fault > > I get the help window to open and the plot window opens with the > title "Chaco > Plot Package Demonstration" and some plot areas. But these are > blank areas, > where only the red crosshairs appear (no plots at all). As soon as I > left-click and the properties tab window pops up, it segfaults. > > Some system info in case anyone else sees the problem: > > [~]> uname -a > Linux maqroll.colorado.edu 2.4.18-6mdk #1 Fri Mar 15 02:59:08 CET > 2002 i686 > unknown > > [~]> python > Python 2.2 (#1, Feb 24 2002, 16:21:58) > [GCC 2.96 20000731 (Mandrake Linux 8.2 2.96-0.76mdk)] on linux-i386 > Type "help", "copyright", "credits" or "license" for more information > > I got the wxpython package from their site. > > Cheers, > > f. > > ps. Don't sweat this one. From past experience, getting wxpython > to work is an > absolute bear (at least for me). So I'm sure the problem isn't on > your end but > is wxwin/wxpython's fault. > > _______________________________________________ > Scipy-dev mailing list > Scipy-dev at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-dev > From fperez at pizero.colorado.edu Fri Sep 20 22:53:05 2002 From: fperez at pizero.colorado.edu (Fernando Perez) Date: Fri, 20 Sep 2002 20:53:05 -0600 (MDT) Subject: [SciPy-dev] Announce: First installable version of Chaco plotting toolkit is now available In-Reply-To: Message-ID: On Fri, 20 Sep 2002, Travis N. Vaught wrote: > Fernando, > > There was just a wxPython release (2.3.3.1) on the 16th, I believe, and that > one broke chaco on my (windows) machine--so there are definitely some issues > there. It does work nicely with a prior version, however, and I know David > Morrill is looking into the issues with the new release. > > I downloaded 2.3.2.1 from sourceforge > https://sourceforge.net/project/showfiles.php?group_id=10718 and it worked > great (not the hybrid, but the regular version). Thanks for the tip, but no cigar. I've put: root[wxwindows]# rpm -qa | grep wx wxPython-2.3.2.1-1 wxGTK-2.3.2-1 and made sure that no other wx-related files where anywhere on the system. Same symptoms/segfault I mentioned before. I'll give the wxPython 2.2 series a shot just to see what happens. Cheers, f From eric at enthought.com Fri Sep 20 23:35:44 2002 From: eric at enthought.com (eric jones) Date: Fri, 20 Sep 2002 22:35:44 -0500 Subject: [SciPy-dev] Announce: First installable version of Chaco plotting toolkit is now available In-Reply-To: Message-ID: <002701c2611f$f83ad1c0$6b01a8c0@ericlaptop> Dave got it working with 2.3.3.1 before he left the office today, so I don't think this is the issue. I think it has only been tested on Windows lately, though. I saw a version running on Sun about a month ago, but it hasn't been run there lately as far as I know. If you can get any more information about where it is failing, I'm sure Dave would appreciate it. eric > -----Original Message----- > From: scipy-dev-admin at scipy.net [mailto:scipy-dev-admin at scipy.net] On > Behalf Of Travis N. Vaught > Sent: Friday, September 20, 2002 9:27 PM > To: scipy-dev at scipy.net > Subject: RE: [SciPy-dev] Announce: First installable version of Chaco > plotting toolkit is now available > > Fernando, > > There was just a wxPython release (2.3.3.1) on the 16th, I believe, and > that > one broke chaco on my (windows) machine--so there are definitely some > issues > there. It does work nicely with a prior version, however, and I know > David > Morrill is looking into the issues with the new release. > > I downloaded 2.3.2.1 from sourceforge > https://sourceforge.net/project/showfiles.php?group_id=10718 and it worked > great (not the hybrid, but the regular version). > > > Travis > > > -----Original Message----- > > From: scipy-dev-admin at scipy.net [mailto:scipy-dev-admin at scipy.net]On > > Behalf Of Fernando Perez > > Sent: Friday, September 20, 2002 6:17 PM > > To: scipy-dev at scipy.net > > Subject: Re: [SciPy-dev] Announce: First installable version of Chaco > > plotting toolkit is now available > > > > > > On Fri, 20 Sep 2002, David C. Morrill wrote: > > > > > We are pleased to announce that the first installable version > > of the Chaco > > > plotting toolkit is now available for download at: > > > > > > http://www.scipy.org/site_content/chaco > > > > > > This package includes both the low-level Kiva drawing API as well as > the > > > high-level Chaco plotting toolkit (and demo). > > > > > > Its very early code with lots of features still missing; but it > > does work > > > and there is a lot of function already available, so we would > encourage > > > anyone who has an interest to give it a try. > > > > Well, the demo on the page looks beautiful and got me all excited. > But... > > > > [~]> python /usr/lib/python2.2/site-packages/chaco/demo/wxdemo_plot.py > > Segmentation fault > > > > I get the help window to open and the plot window opens with the > > title "Chaco > > Plot Package Demonstration" and some plot areas. But these are > > blank areas, > > where only the red crosshairs appear (no plots at all). As soon as I > > left-click and the properties tab window pops up, it segfaults. > > > > Some system info in case anyone else sees the problem: > > > > [~]> uname -a > > Linux maqroll.colorado.edu 2.4.18-6mdk #1 Fri Mar 15 02:59:08 CET > > 2002 i686 > > unknown > > > > [~]> python > > Python 2.2 (#1, Feb 24 2002, 16:21:58) > > [GCC 2.96 20000731 (Mandrake Linux 8.2 2.96-0.76mdk)] on linux-i386 > > Type "help", "copyright", "credits" or "license" for more information > > > > I got the wxpython package from their site. > > > > Cheers, > > > > f. > > > > ps. Don't sweat this one. From past experience, getting wxpython > > to work is an > > absolute bear (at least for me). So I'm sure the problem isn't on > > your end but > > is wxwin/wxpython's fault. > > > > _______________________________________________ > > Scipy-dev mailing list > > Scipy-dev at scipy.net > > http://www.scipy.net/mailman/listinfo/scipy-dev > > > > _______________________________________________ > Scipy-dev mailing list > Scipy-dev at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-dev From fperez at pizero.colorado.edu Fri Sep 20 23:42:57 2002 From: fperez at pizero.colorado.edu (Fernando Perez) Date: Fri, 20 Sep 2002 21:42:57 -0600 (MDT) Subject: [SciPy-dev] Announce: First installable version of Chaco plotting toolkit is now available In-Reply-To: <002701c2611f$f83ad1c0$6b01a8c0@ericlaptop> Message-ID: On Fri, 20 Sep 2002, eric jones wrote: > Dave got it working with 2.3.3.1 before he left the office today, so I > don't think this is the issue. I think it has only been tested on > Windows lately, though. I saw a version running on Sun about a month > ago, but it hasn't been run there lately as far as I know. > > If you can get any more information about where it is failing, I'm sure > Dave would appreciate it. > > eric Sorry Eric, but it's just a clean segfault with no output to stderr whatsoever. Hard to say if it's the python interpreter's fault or something in the wx-gtk-python libs. I tried rebuilding the 2.2.5 wxPython source rpm but it barfs early on. Since I was just a bit curious and right now I am frying bigger fish (of my own) I'll have to let go of this. Maybe someone else might be able to get it to work on a linux box. I simply have very little experience with wxpython (partly because every time I try to use it, the thing blows up at liftoff). Cheers, f. From prabhu at aero.iitm.ernet.in Fri Sep 20 22:00:08 2002 From: prabhu at aero.iitm.ernet.in (Prabhu Ramachandran) Date: Sat, 21 Sep 2002 07:30:08 +0530 Subject: [SciPy-dev] Re: [SciPy-user] Announce: First installable version of Chaco plotting toolkit is now available In-Reply-To: <001201c260f5$efcabb10$6501a8c0@Dave> References: <001201c260f5$efcabb10$6501a8c0@Dave> Message-ID: <15755.53928.150293.705989@monster.linux.in> >>>>> "DCM" == David C Morrill writes: DCM> We are pleased to announce that the first installable version DCM> of the Chaco plotting toolkit is now available for download DCM> at: http://www.scipy.org/site_content/chaco Wow! The demo looks so good. Great work! However, I am unable to run chaco on Linux. I am running wxPython 2.3.2.1. When I ran wxdemo_plot.py I got the basic screen but none of the plots were there. I also only saw one of the plots (the left one). None of the right ones appeared. anyway, the following debug.log file was produced. Traceback (most recent call last): File "/usr/local/lib/python2.1/site-packages/chaco/wxplot_window.py", line 927 , in _on_paint canvas._draw() File "/usr/local/lib/python2.1/site-packages/chaco/plot_canvas.py", line 2197, in _draw value_item.item._draw() File "/usr/local/lib/python2.1/site-packages/chaco/plot_canvas.py", line 734, in _draw axes_info._draw( ox, oy ) File "/usr/local/lib/python2.1/site-packages/chaco/plot_info.py", line 654, in _draw axis_info._draw( 0, oy ) File "/usr/local/lib/python2.1/site-packages/chaco/plot_info.py", line 1038, i n _draw gc.stroke_path() File "/usr/local/lib/python2.1/site-packages/kiva/basecore2d.py", line 946, in stroke_path self.draw_path(mode=STROKE) File "/usr/local/lib/python2.1/site-packages/kiva/basecore2d.py", line 986, in draw_path self.device_update_line_state() File "/usr/local/lib/python2.1/site-packages/kiva/wxcore2d.py", line 167, in device_update_line_state pen.SetDashes(list(pattern.astype(int))) ValueError: type must be either a 1-length string, or a python type object I receive several of these. Thanks. prabhu From roybryant at seventwentyfour.com Sat Sep 21 23:54:17 2002 From: roybryant at seventwentyfour.com (Roy at SEVENtwentyfour Inc.) Date: Sat, 21 Sep 2002 23:54:17 -0400 Subject: [SciPy-dev] Broken link in www.scipy.org Message-ID: <20020922035813.D9FD43EACE@www.scipy.com> An embedded and charset-unspecified text was scrubbed... Name: not available URL: From eric at enthought.com Sun Sep 22 02:57:14 2002 From: eric at enthought.com (eric jones) Date: Sun, 22 Sep 2002 01:57:14 -0500 Subject: [SciPy-dev] refcount strangeness when testing weave Message-ID: <000001c26205$48a81a10$777ba8c0@ericlaptop> I've made some modifications to the SCXX library to beautify code written in C++ and also to improve speed in some cases. I started adding unit tests that exercised some of this stuff and ran into an issue testing refcounts right off the bat. Testing that refcounts are handled correctly for a list passed into a weave function (that does absolutely nothing) gives me the expected results from the command line in the global namespace. >>> import weave >>> import sys >>> a = [] >>> print sys.getrefcount(a) 2 >>> weave.inline('',['a']) >>> print sys.getrefcount(a) 2 However, when doing the same in a function, I get different behavior: >>> def bub(): ... a=[] ... print sys.getrefcount(a) ... weave.inline('',['a']) ... print sys.getrefcount(a) ... weave.inline('',['a']) ... print sys.getrefcount(a) ... >>> bub() 2 3 3 After the first call to weave, it looks like a reference count that shouldn't be added to 'a' gets added. However, running the weave call again doesn't leak a ref count. Based, on this and the original command line result, I'm pretty sure refcounts are handled correctly. Can someone explain what is happening here that is causing the refcount to rise to 3 on the first call in bub() so that I can right accurate tests for weave and ref counts? Thanks, eric From skip at pobox.com Sun Sep 22 09:19:31 2002 From: skip at pobox.com (Skip Montanaro) Date: Sun, 22 Sep 2002 08:19:31 -0500 Subject: [SciPy-dev] Announce: First installable version of Chaco plotting toolkit is now available In-Reply-To: <001201c260f5$efcabb10$6501a8c0@Dave> References: <001201c260f5$efcabb10$6501a8c0@Dave> Message-ID: <15757.50019.436297.174799@12-248-11-90.client.attbi.com> Dave> We are pleased to announce that the first installable version of Dave> the Chaco plotting toolkit is now available for download at: Dave> http://www.scipy.org/site_content/chaco What versions of other stuff are required? I'm having trouble building wxPython and wxGTK on both Linux (using gcc/g++) and Solaris (using suncc/sunc++). Thx, Skip From skip at pobox.com Sun Sep 22 09:19:31 2002 From: skip at pobox.com (Skip Montanaro) Date: Sun, 22 Sep 2002 08:19:31 -0500 Subject: [SciPy-dev] Announce: First installable version of Chaco plotting toolkit is now available In-Reply-To: <001201c260f5$efcabb10$6501a8c0@Dave> References: <001201c260f5$efcabb10$6501a8c0@Dave> Message-ID: <15757.50019.436297.174799@12-248-11-90.client.attbi.com> Dave> We are pleased to announce that the first installable version of Dave> the Chaco plotting toolkit is now available for download at: Dave> http://www.scipy.org/site_content/chaco What versions of other stuff are required? I'm having trouble building wxPython and wxGTK on both Linux (using gcc/g++) and Solaris (using suncc/sunc++). Thx, Skip From eric at enthought.com Sun Sep 22 15:38:45 2002 From: eric at enthought.com (eric jones) Date: Sun, 22 Sep 2002 14:38:45 -0500 Subject: [SciPy-dev] Announce: First installable version of Chaco plotting toolkit is now available In-Reply-To: <15757.50019.436297.174799@12-248-11-90.client.attbi.com> Message-ID: <001501c2626f$aa92e240$777ba8c0@ericlaptop> > > Dave> We are pleased to announce that the first installable version of > Dave> the Chaco plotting toolkit is now available for download at: > > Dave> http://www.scipy.org/site_content/chaco > > What versions of other stuff are required? I'm having trouble building > wxPython and wxGTK on both Linux (using gcc/g++) and Solaris (using > suncc/sunc++). It should work with 2.3.2 and 2.3.3.1 (current). I think there are RPMs available for Linux at www.wxpython.org. Still, it is a little disturbing that you're having problems building. Can you post your issues on the wxPython list so they are aware of them. Also on the Solaris build, it sounds like Robin's instructions on this architecture need some modification for the latest version. You might get him in the loop on this one also. By the way, I think heatmizer had a (older) working install of wxPython that you could also try this stuff on. Note that chaco hasn't been tested on Linux, so we're happy your trying it here. eric From skip at pobox.com Sun Sep 22 16:10:01 2002 From: skip at pobox.com (Skip Montanaro) Date: Sun, 22 Sep 2002 15:10:01 -0500 Subject: [SciPy-dev] Announce: First installable version of Chaco plotting toolkit is now available In-Reply-To: <001501c2626f$aa92e240$777ba8c0@ericlaptop> References: <15757.50019.436297.174799@12-248-11-90.client.attbi.com> <001501c2626f$aa92e240$777ba8c0@ericlaptop> Message-ID: <15758.9113.807226.22409@12-248-11-90.client.attbi.com> skip> What versions of other stuff are required? I'm having trouble skip> building wxPython and wxGTK on both Linux (using gcc/g++) and skip> Solaris (using suncc/sunc++). eric> It should work with 2.3.2 and 2.3.3.1 (current). I think there eric> are RPMs available for Linux at www.wxpython.org. I'll hold off on Solaris for now, since that environment is a bit different. On Linux, I started with wxPythonSrc-2.3.3.1 and followed the directions at http://www.wxpython.org/README.1st.txt to build it. Specifically, I did this: mkdir build cd build export WXPREF=/usr/local ../configure --with-gtk --prefix=$WXPREF --enable-rpath=$WXPREF/lib \ --with-opengl --enable-optimise --enable-debug_flag \ --with-libjpeg=builtin --with-libpng=builtin --with-libtiff=builtin \ --with-zlib=builtin [There is a typo in the README.1st.txt file - the --with-libjpeg=builtin arg is missing a dash.] make cd ../locale make allmo cd ../build make install cd ../wxPython python setup.py \ IN_CVS_TREE=1 WX_CONFIG=$WXPREF/bin/wx-config \ build install I then went to the wxPython/demo directory and executed python demo.py which yielded: Traceback (most recent call last): File "demo.py", line 3, in ? import Main File "Main.py", line 15, in ? from wxPython.wx import * File "/usr/local/lib/python2.3/site-packages/wxPython/__init__.py", line 20, in ? import wxc ImportError: /usr/local/lib/python2.3/site-packages/wxPython/wxc.so: undefined symbol: __ti7wxEvent I poked around for "__ti7wxEvent". All I found were a couple undefined references: for f in `find . -name '*.so'` ; do n=`nm -p $f | egrep __ti7wxEvent | wc -l` if [ $n -gt 0 ] ; then echo $f nm -p $f | egrep __ti7wxEvent fi done ./python2.3/site-packages/wxPython/wxc.so U __ti7wxEvent ./python2.3/site-packages/wxPython/gizmosc.so U __ti7wxEvent I then went back to the wxPython build tree and scanned the .o files for that symbol using a for loop similar to the above. This yielded: ./wxPython/build/temp.linux-i686-2.3/helpers.o U __ti7wxEvent ./wxPython/build/temp.linux-i686-2.3/dynamicsash.o U __ti7wxEvent According to c++filt, that symbol corresponds to wxEvent type_info node My environment is Mandrake 8.1, Python from CVS (2.3a0-ish) built with gcc. -- Skip Montanaro - skip at pobox.com The need for gutters to be cleaned is directly proportional to how hard it happens to be raining at the moment. From ademilar at brturbo.com Sat Sep 21 22:17:12 2002 From: ademilar at brturbo.com (ademilar at brturbo.com) Date: Sun, 22 Sep 2002 23:17:12 2100 Subject: [SciPy-dev] Compare Consórcio de Imóveis x SFH Message-ID: <1032747432.248@brturbo.com> 1. CONS?RCIO ADEMILAR x SISTEMA FINANCEIRO DE HABITA??O -------------------------------------------------------------------------- | | CONS?RCIO | SFH (1) | CONS?RCIO | SFH (1) | | | ADEMILAR | | ADEMILAR | | -------------------------------------------------------------------------- | Valor do |R$ 50.000,00 | R$ 50.000,00 |R$ 50.000,00 | R$ 50.000,00 | | Cr?dito | | | | | -------------------------------------------------------------------------- | N?mero de | 100 | 100 | 180 | 180 | | Parcelas | Meses | Meses | Meses | Meses | -------------------------------------------------------------------------- | Presta??o | R$ 567,50 | R$ 1.125,00 | R$ 354,25 | R$ 755,86 | | | | | | | -------------------------------------------------------------------------- | Valor Total |R$ 57.650,00 | R$ 112.500,00 |R$ 63.765,00 | R$ 136.054,80 | | Saldo Devedor| | | | | | (2) | | | | | -------------------------------------------------------------------------- | Percentual do| 15,30 % | 125,00 % | 27,53 % | 172,10 % | | saldo devedor| | | | | | sobre cr?dito| | | | | -------------------------------------------------------------------------- | Corre??o | CUB Mensal | TR + | CUB Mensal | TR + | | | (3) | 1% / M?s (4) | (3) | 1% / M?s (4) | -------------------------------------------------------------------------- Observa??o: Os n?meros e valores deste demonstrativo s?o apenas um exemplo. (1) Caixa Econ?mica Federal, (2) Com base no valor da 1a. presta??o, antes da corre??o de cada alternativa (3) Varia??o mensal utilizada pelo cons?rcio, (4) Varia??o utilizada pela CEF 2. CONS?RCIO ADEMILAR a) A Ademilar se destaca no mercado por sua atua??o pioneira no Estado do Paran?, especialista no segmento de cons?rcio imobili?rio com o prop?sito de oferecer a melhor das alternativas ao mercado imobili?rio; b) Foi a primeira no Pa?s a obter autoriza??o junto ao Banco Central do Brasil para desenvolver suas atividades em regime de empresa Sociedade An?nima, com Certificado de Autoriza??o n? 92060028; c) Esta em as cinco maiores administradoras de cons?rcio de im?veis do Brasil e conta com a confian?a de mais de 3.000 fam?lias que receberam seus im?veis, num total de mais de R$ 100.000.000,00 em cr?ditos entregues. 3. VANTAGENS DO CONS?RCIO ADEMILAR a) Aquisi??o de im?veis Residenciais ou Comerciais (novos ou usados), Terrenos, Constru??o, Reforma e Amplia??o (im?vel pr?prio), na Cidade, Praia e Campo; b) Equipar ou modernizar a sua micro-empresa, escrit?rio ou consult?rio (im?vel pr?prio); c) Utilizar o FGTS como lance (Conforme normas da CEF); d) Quitar d?vida junto ao Sistema Financeiro de Habita??o; e) Sem necessidade de comprova??o de renda; f) Liberdade para aquisi??o de um ou mais cr?ditos mesmo possuindo outro im?vel, seja quitado ou financiado; g) As contempla??es s?o mensais, uma por Sorteio pela Loteria Federal e outra por Lance; h) Possu?mos v?rias cartas de Cr?ditos com prazos diversos adequando ao seu or?amento familiar. 4. VANTAGENS DO INVESTIMENTO EM IM?VEIS a) "Dinheiro na m?o ? vendaval", j? cantava Paulinho da Viola. O im?vel imp?e excelente disciplina de poupar ao investidor; b) Os alugu?is podem oferecer um bom complemento na aposentadoria. Reinvestir os alugu?is recebidos atrav?s do cons?rcio impulsiona novas aquisi??es e torna-se uma alternativa ?s aplica??es financeiras; c) ?tima prote??o contra a infla??o no m?dio e longo prazo; d) Viver no que ? seu ? algo que d? muito prazer; e) Comprar um im?vel proporciona uma sensa??o de vit?ria e tranq?ilidade para voc? e sua fam?lia. 5. CONTATO Marisa Gasparim Rosa Assessora Comercial ademilar at brturbo.com www.ademilar.brturbo.com (41) 353-2850 / (41) 9994-6590 Curitiba - Paran? From robin at alldunn.com Mon Sep 23 14:42:37 2002 From: robin at alldunn.com (Robin Dunn) Date: Mon, 23 Sep 2002 11:42:37 -0700 Subject: [wxPython] RE: [SciPy-dev] Announce: First installable version of Chaco plotting toolkit is now available References: <15757.50019.436297.174799@12-248-11-90.client.attbi.com> <001501c2626f$aa92e240$777ba8c0@ericlaptop> <15758.9113.807226.22409@12-248-11-90.client.attbi.com> Message-ID: <3D8F609D.5080402@alldunn.com> Skip Montanaro wrote: > I'll hold off on Solaris for now, since that environment is a bit different. > On Linux, I started with wxPythonSrc-2.3.3.1 and followed the directions at > http://www.wxpython.org/README.1st.txt to build it. Specifically, I did > this: > > mkdir build > cd build > export WXPREF=/usr/local > ../configure --with-gtk --prefix=$WXPREF --enable-rpath=$WXPREF/lib \ > --with-opengl --enable-optimise --enable-debug_flag \ > --with-libjpeg=builtin --with-libpng=builtin --with-libtiff=builtin \ > --with-zlib=builtin If you're going to install wxWindows into /usr/local then there's no real reason to follow the directions for the private wx, but it should still work like this... > [There is a typo in the README.1st.txt file - the --with-libjpeg=builtin arg > is missing a dash.] Thanks. I'll get this fixed. > > I then went to the wxPython/demo directory and executed > > python demo.py > > which yielded: > > Traceback (most recent call last): > File "demo.py", line 3, in ? > import Main > File "Main.py", line 15, in ? > from wxPython.wx import * > File "/usr/local/lib/python2.3/site-packages/wxPython/__init__.py", line 20, in ? > import wxc > ImportError: /usr/local/lib/python2.3/site-packages/wxPython/wxc.so: undefined symbol: __ti7wxEvent > > I poked around for "__ti7wxEvent". All I found were a couple undefined > references: [...] > ./wxPython/build/temp.linux-i686-2.3/helpers.o > U __ti7wxEvent > ./wxPython/build/temp.linux-i686-2.3/dynamicsash.o > U __ti7wxEvent > > According to c++filt, that symbol corresponds to > > wxEvent type_info node > > My environment is Mandrake 8.1, Python from CVS (2.3a0-ish) built with gcc. > I've just tried exactly what you did above on my Mandrake 8.2 system with Python 2.2 and it works fine. One possibility -- since the wxPython build gets its compiler flags and etc. from Python's build via distutils -- is that there is some flag conflicting with wxGTK's build that has changed with Python 2.3. I'd be interested in seeing a copy of a compile commandline for one of the sources from the wxGTK build and another one from the wxPython build. Another possibility is that it may be fixed simply by disabling rtti and/or exceptions in the wxGTK build. You can try adding the following flags and then rebuilding all of wxGTK and wxPython: --enable-no_rtti --enable-no_exceptions RTTI and exceptions are not needed by wxPython so I guess I should probably add them to the "Private wxGTK" instructions anyway as there should be a bit of a performance boost... -- Robin Dunn Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython! From skip at pobox.com Mon Sep 23 15:57:26 2002 From: skip at pobox.com (Skip Montanaro) Date: Mon, 23 Sep 2002 14:57:26 -0500 Subject: [wxPython] RE: [SciPy-dev] Announce: First installable version of Chaco plotting toolkit is now available In-Reply-To: <3D8F609D.5080402@alldunn.com> References: <15757.50019.436297.174799@12-248-11-90.client.attbi.com> <001501c2626f$aa92e240$777ba8c0@ericlaptop> <15758.9113.807226.22409@12-248-11-90.client.attbi.com> <3D8F609D.5080402@alldunn.com> Message-ID: <15759.29222.665584.905792@12-248-11-90.client.attbi.com> Skip> export WXPREF=/usr/local Skip> ../configure --with-gtk --prefix=$WXPREF --enable-rpath=$WXPREF/lib \ Skip> --with-opengl --enable-optimise --enable-debug_flag \ Skip> --with-libjpeg=builtin --with-libpng=builtin --with-libtiff=builtin \ Skip> --with-zlib=builtin Robin> If you're going to install wxWindows into /usr/local then there's Robin> no real reason to follow the directions for the private wx, but Robin> it should still work like this... That's what I figured, but I also figured it was marginally better to be pedantic in case WXPREF was used somewhere other than via the command line. Skip> I poked around for "__ti7wxEvent". All I found were a couple undefined Skip> references: Skip> ./wxPython/build/temp.linux-i686-2.3/helpers.o Skip> U __ti7wxEvent Skip> ./wxPython/build/temp.linux-i686-2.3/dynamicsash.o Skip> U __ti7wxEvent Robin> I've just tried exactly what you did above on my Mandrake 8.2 Robin> system with Python 2.2 and it works fine. What file defines wxEvent? You must surely have a .o file which defines it as an exportable symbol. Robin> One possibility -- since the wxPython build gets its compiler Robin> flags and etc. from Python's build via distutils -- is that there Robin> is some flag conflicting with wxGTK's build that has changed with Robin> Python 2.3. I'd be interested in seeing a copy of a compile Robin> commandline for one of the sources from the wxGTK build and Robin> another one from the wxPython build. An example from (wxPython's internal) wxGTK with the no_rtti and no_exceptions flags set: c++ -c -I./lib/wx/include/gtkd-2.3 -I../include -I../src/zlib \ -I../src/png -I../src/jpeg -I../src/tiff -I/usr/include/gtk-1.2 \ -I/usr/include/glib-1.2 -I/usr/lib/glib/include -D_REENTRANT \ -I/usr/X11R6/include -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES \ -D__WXGTK__ -D__WXDEBUG__ -fno-rtti -fno-exceptions -O2 -MMD -pthread \ -Wall -fPIC -o brush.o ../src/gtk/brush.cpp Here's one from wxPython: gcc -DNDEBUG -O3 -fPIC -DSWIG_GLOBAL -DHAVE_CONFIG_H -DWXP_USE_THREAD=1 \ -Isrc -I/usr/local/include/python2.3 -c contrib/dllwidget/dllwidget.cpp \ -o build/temp.linux-i686-2.3/dllwidget.o \ -I/usr/local/lib/wx/include/gtkd-2.3 -D__WXDEBUG__ -D__WXGTK__ \ -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -fno-rtti -fno-exceptions \ -I/usr/include/gtk-1.2 -I/usr/include/glib-1.2 -I/usr/lib/glib/include \ -I/usr/X11R6/include -UNDEBUG Robin> Another possibility is that it may be fixed simply by disabling Robin> rtti and/or exceptions in the wxGTK build. You can try adding Robin> the following flags and then rebuilding all of wxGTK and Robin> wxPython: Robin> --enable-no_rtti Robin> --enable-no_exceptions Just tried that. Running wxPython/demo/demo.py now yields: Traceback (most recent call last): File "demo.py", line 3, in ? import Main File "Main.py", line 15, in ? from wxPython.wx import * File "/usr/local/lib/python2.3/site-packages/wxPython/__init__.py", line 20, in ? import wxc ImportError: /usr/local/lib/python2.3/site-packages/wxPython/wxc.so: undefined symbol: Eof__C13wxInputStream which c++filt reports as wxInputStream::Eof(void) const The original __ti7wxEvent symbol is no longer to be found anywhere (defined or referenced). Eof__C13wxInputStream is referenced from ./wxPython/build/temp.linux-i686-2.3/helpers.o. Ah, wait a minute. I see a likely candidate for the screwup: % type c++ c++ is /usr/local/bin/c++ % c++ --version 3.0.4 % type gcc gcc is /usr/bin/gcc % gcc --version 2.96 Does mix-n-match across GCC versions strike you as a plausible reason for the errors? I am rebuilding while I await your reply... Skip From robin at alldunn.com Mon Sep 23 16:09:30 2002 From: robin at alldunn.com (Robin Dunn) Date: Mon, 23 Sep 2002 13:09:30 -0700 Subject: [wxPython] RE: [SciPy-dev] Announce: First installable version of Chaco plotting toolkit is now available References: <15757.50019.436297.174799@12-248-11-90.client.attbi.com> <001501c2626f$aa92e240$777ba8c0@ericlaptop> <15758.9113.807226.22409@12-248-11-90.client.attbi.com> <3D8F609D.5080402@alldunn.com> <15759.29222.665584.905792@12-248 Message-ID: <3D8F74FA.9080906@alldunn.com> Skip Montanaro wrote: > > Skip> I poked around for "__ti7wxEvent". All I found were a couple undefined > Skip> references: > Skip> ./wxPython/build/temp.linux-i686-2.3/helpers.o > Skip> U __ti7wxEvent > Skip> ./wxPython/build/temp.linux-i686-2.3/dynamicsash.o > Skip> U __ti7wxEvent > > Robin> I've just tried exactly what you did above on my Mandrake 8.2 > Robin> system with Python 2.2 and it works fine. > > What file defines wxEvent? You must surely have a .o file which defines it > as an exportable symbol. It should be in wxGTK in src/common/event.cpp (build/event.o). > Robin> One possibility -- since the wxPython build gets its compiler > Robin> flags and etc. from Python's build via distutils -- is that there > Robin> is some flag conflicting with wxGTK's build that has changed with > Robin> Python 2.3. I'd be interested in seeing a copy of a compile > Robin> commandline for one of the sources from the wxGTK build and > Robin> another one from the wxPython build. > > An example from (wxPython's internal) wxGTK with the no_rtti and > no_exceptions flags set: [...] These look okay. > Robin> Another possibility is that it may be fixed simply by disabling > Robin> rtti and/or exceptions in the wxGTK build. You can try adding > Robin> the following flags and then rebuilding all of wxGTK and > Robin> wxPython: > > Robin> --enable-no_rtti > Robin> --enable-no_exceptions > > Just tried that. Running wxPython/demo/demo.py now yields: > > Traceback (most recent call last): > File "demo.py", line 3, in ? > import Main > File "Main.py", line 15, in ? > from wxPython.wx import * > File "/usr/local/lib/python2.3/site-packages/wxPython/__init__.py", line 20, in ? > import wxc > ImportError: /usr/local/lib/python2.3/site-packages/wxPython/wxc.so: > undefined symbol: Eof__C13wxInputStream > > which c++filt reports as > > wxInputStream::Eof(void) const > > The original __ti7wxEvent symbol is no longer to be found anywhere (defined > or referenced). Right, it shouldn't be since you built without RTTI. > Eof__C13wxInputStream is referenced from > ./wxPython/build/temp.linux-i686-2.3/helpers.o. I don't see anyway that a whole method could get lost... > > Ah, wait a minute. I see a likely candidate for the screwup: > > % type c++ > c++ is /usr/local/bin/c++ > % c++ --version > 3.0.4 > % type gcc > gcc is /usr/bin/gcc > % gcc --version > 2.96 > > Does mix-n-match across GCC versions strike you as a plausible reason for > the errors? ...except for this. It's likely that the C++ symbol names are getting mangled differently by the different compiler versions and the one symbol reported by the import exception is just the first one found. -- Robin Dunn Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython! From skip at pobox.com Mon Sep 23 17:36:33 2002 From: skip at pobox.com (Skip Montanaro) Date: Mon, 23 Sep 2002 16:36:33 -0500 Subject: [wxPython] RE: [SciPy-dev] Announce: First installable version of Chaco plotting toolkit is now available In-Reply-To: <3D8F74FA.9080906@alldunn.com> References: <15757.50019.436297.174799@12-248-11-90.client.attbi.com> <001501c2626f$aa92e240$777ba8c0@ericlaptop> <15758.9113.807226.22409@12-248-11-90.client.attbi.com> <3D8F609D.5080402@alldunn.com> <15759.29222.665584.905792@12-248 <3D8F74FA.9080906@alldunn.com> Message-ID: <15759.35169.345097.543075@12-248-11-90.client.attbi.com> >> Does mix-n-match across GCC versions strike you as a plausible reason >> for the errors? Robin> ...except for this. It's likely that the C++ symbol names are Robin> getting mangled differently by the different compiler versions Robin> and the one symbol reported by the import exception is just the Robin> first one found. Thanks, that did the trick. Now to wage battle with the dragon named Solaris... Skip From dmorrill at enthought.com Mon Sep 23 18:16:14 2002 From: dmorrill at enthought.com (David C. Morrill) Date: Mon, 23 Sep 2002 17:16:14 -0500 Subject: [SciPy-dev] Progress being made on Chaco Linux problem Message-ID: <00bc01c2634e$d4dd7f80$6501a8c0@Dave> Just wanted to let everyone know that I have made some progress on the Chaco Linux problem that several people have reported. It appears that the Linux GTK-based version on wxPython does not implement the wxDC.SetDeviceOrigin and wxDC.SetAxisOrientation methods the same way as the Windows version does. The Kiva layer of Chaco is based on DisplayPDF and has its origin in the lower-left corner. Chaco uses the two calls just mentioned to properly orient the wxDC drawing methods. But in the Linux version, these calls are not behaving as I would expect. By commenting out the body of the 'right_side_up' method in wxplot_window.py in the chaco directory (which calls the two methods described), I was able to get the demo program to work (although all the plots are inverted!). I'm going to start looking at the wxPython source to see if I can figure out what's going wrong. But in the meantime I thought I would post what I had found so far. Dave Morrill -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmorrill at enthought.com Mon Sep 23 18:26:29 2002 From: dmorrill at enthought.com (David C. Morrill) Date: Mon, 23 Sep 2002 17:26:29 -0500 Subject: [SciPy-dev] Chaco discussion on scipy-chaco mailing list Message-ID: <00c501c26350$42ff0d20$6501a8c0@Dave> Just wanted to mention that Chaco has its own mailing list on scipy-chaco at scipy.org. To avoid unnecessary cross-posting on the other SciPy lists, hopefully future Chaco discussion will occur there. In particular, I just posted a note there on the progress I've made in fixing the Chaco Linux problem that has been reported by several people. See ya there... Dave Morrill -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmorrill at enthought.com Mon Sep 23 18:34:20 2002 From: dmorrill at enthought.com (David C. Morrill) Date: Mon, 23 Sep 2002 17:34:20 -0500 Subject: [SciPy-dev] Chaco discussion on scipy-chaco mailing list Message-ID: <00ee01c26351$5c11b3c0$6501a8c0@Dave> Just wanted to mention that Chaco has its own mailing list on scipy-chaco at scipy.org. To avoid unnecessary cross-posting on the other SciPy lists, hopefully future Chaco discussion will occur there. In particular, I just posted a note there on the progress I've made in fixing the Chaco Linux problem that has been reported by several people. See ya there... Dave Morrill -------------- next part -------------- An HTML attachment was scrubbed... URL: From prabhu at aero.iitm.ernet.in Mon Sep 23 21:42:30 2002 From: prabhu at aero.iitm.ernet.in (Prabhu Ramachandran) Date: Tue, 24 Sep 2002 07:12:30 +0530 Subject: [SciPy-dev] Progress being made on Chaco Linux problem In-Reply-To: <00bc01c2634e$d4dd7f80$6501a8c0@Dave> References: <00bc01c2634e$d4dd7f80$6501a8c0@Dave> Message-ID: <15759.49926.162201.317368@monster.linux.in> >>>>> "DCM" == David C Morrill writes: DCM> Just wanted to let everyone know that I have made some DCM> progress on the Chaco Linux problem that several people have DCM> reported. It appears that the Linux GTK-based version on DCM> wxPython does not implement the wxDC.SetDeviceOrigin and DCM> wxDC.SetAxisOrientation methods the same way as the Windows DCM> version does. Is that the same reason why I got the tracebacks that I sent to the list? File "/usr/local/lib/python2.1/site-packages/kiva/wxcore2d.py", line 167, in d evice_update_line_state pen.SetDashes(list(pattern.astype(int))) ValueError: type must be either a 1-length string, or a python type object Please let us know if you need us to checkout a CVS copy and play with a newer version. cheers, prabhu From dmorrill at enthought.com Tue Sep 24 11:41:16 2002 From: dmorrill at enthought.com (David C. Morrill) Date: Tue, 24 Sep 2002 10:41:16 -0500 Subject: [SciPy-dev] Progress being made on Chaco Linux problem References: <00bc01c2634e$d4dd7f80$6501a8c0@Dave> <15759.49926.162201.317368@monster.linux.in> Message-ID: <011201c263e0$d202faf0$6501a8c0@Dave> > Is that the same reason why I got the tracebacks that I sent to the > list? > > File "/usr/local/lib/python2.1/site-packages/kiva/wxcore2d.py", line 167, in d > evice_update_line_state > pen.SetDashes(list(pattern.astype(int))) > ValueError: type must be either a 1-length string, or a python type object I don't believe it is the same error, but I'm not sure. I have not seen this error yet myself when testing on Linux. > Please let us know if you need us to checkout a CVS copy and play with > a newer version. I haven't fixed or changed anything yet. Every change I've tried so far works just as poorly :-( But I will post once I've made any additional progress, include CVS updates... Dave Morrill From dmorrill at enthought.com Tue Sep 24 11:49:07 2002 From: dmorrill at enthought.com (David C. Morrill) Date: Tue, 24 Sep 2002 10:49:07 -0500 Subject: [SciPy-dev] Debugging tidbit Message-ID: <012801c263e1$eb0044d0$6501a8c0@Dave> Just thought I would mention that if anyone does encounter problems running the demo, try looking in the 'debug.log' file to see if there is any information (such as a traceback). If so, posting the contents of the debug.log file along with the problem description would be a big help. The 'debug.log' file is normally created in the current directory when the demo is run. Dave Morrill -------------- next part -------------- An HTML attachment was scrubbed... URL: From taketu at lapis.plala.or.jp Wed Sep 25 02:45:56 2002 From: taketu at lapis.plala.or.jp (=?ISO-2022-JP?B?GyRCJCo2YkJfJDckXiQ5GyhC?=) Date: Wed, 25 Sep 2002 15:45:56 +0900 (JST) Subject: [SciPy-dev] =?ISO-2022-JP?B?GyRCTCQ+NUJ6OS05cCIoNEpDMU07O3EbKEI=?= Message-ID: <200209250645.g8P6juO04384@mx0.sa.il24.net> $B!c;v6He$N(B $B%o%$%I%m!<%s(B $B$*Ld$$9g$;4?7^!*(B $B0lK\2=BP1~@_Dj!*Hf$Y$F(B $B$/$@$5$$Dc6bMx!*(B $B>\$7$/$O%U%j!<%@(B $B%$%d%k$G(B $B5.J}$N(B????????? $B-j(BKM?????? From skip at pobox.com Thu Sep 26 11:02:05 2002 From: skip at pobox.com (Skip Montanaro) Date: Thu, 26 Sep 2002 10:02:05 -0500 Subject: [SciPy-dev] What's this error mean? Message-ID: <15763.8557.843553.491846@12-248-11-90.client.attbi.com> I just tried a 'cvs up' in my scipy source directory and got this: cvs [server aborted]: could not find desired version 1.130.1506.4149 in /home/cvsroot/world/scipy/__cvs_version__.py,v I removed __cvs_version__.py and ran 'cvs up' again. It then worked. Can someone explain what that error means and what __cvs_version__.py is used for? Thanks, Skip From pearu at cens.ioc.ee Thu Sep 26 11:29:51 2002 From: pearu at cens.ioc.ee (Pearu Peterson) Date: Thu, 26 Sep 2002 18:29:51 +0300 (EEST) Subject: [SciPy-dev] What's this error mean? In-Reply-To: <15763.8557.843553.491846@12-248-11-90.client.attbi.com> Message-ID: On Thu, 26 Sep 2002, Skip Montanaro wrote: > I just tried a 'cvs up' in my scipy source directory and got this: > > cvs [server aborted]: could not find desired version 1.130.1506.4149 in /home/cvsroot/world/scipy/__cvs_version__.py,v > > I removed __cvs_version__.py and ran 'cvs up' again. It then worked. > > Can someone explain what that error means and what __cvs_version__.py is > used for? I am not sure why you recieved this error, may be __cvs_version__.py was modified in your side for some reasons... __cvs_version__.py is used for holding the CVS version information of SciPy. This version information is calculated at the CVS server side and it uses Revision numbers of the files in the repository. So, whenever any change is made to the CVS repository, the version information of SciPy will be updated automatically and the algorithm ensures that it will be always monotonically increasing, even if files are removed (so that some Revision are lost). This CVS version information is used also for setting the real SciPy version. For example, the last two bits of >>> scipy.__version__ '0.2.0_alpha_133.4175' come from __cvs_version__.py. This makes any SciPy checkout from CVS unique in the sense that if an user reports problems, then from these two number one can tell what CVS state this particular user was using. This information can be sometimes helpful for tracking down bugs. In addition, no brain power is wasted for setting the version string when making a snapshot of SciPy. Pearu From pearu at cens.ioc.ee Sat Sep 28 16:53:43 2002 From: pearu at cens.ioc.ee (Pearu Peterson) Date: Sat, 28 Sep 2002 23:53:43 +0300 (EEST) Subject: [SciPy-dev] fftpack2 for review Message-ID: Dear SciPy devels, Please find a scipy.fftpack replacement candidate fftpack2 from http://cens.ioc.ee/~pearu/misc/fftpack2-0.1.tar.gz for review. fftpack2 main features include: - Optional support for high-performance FFT libraries such as FFTW and DJBFFT libraries. By default, Fortran FFTPACK is used and other libraries are automatically detected by the scipy_distutils/system_info.py script. - Support for both real and complex DFT's and their inverse transforms. When used with FFTW and/or DJBFFT libraries then fftpack2 routines are considerably faster than Numeric.FFT and the current scipy.fftpack. Some comparison timings are included at the end of this message. - Implementation of differentiation and integration of periodic sequences, various pseudo-differential operators such as Tilbert transform, Hilbert transform, hyperbolic pseudo-differential operators, their inverses, etc. - Because different FFT libraries use different data storage convention, fftpack2 implements interface to these conventions so that users and developers need not to learn all these conventions, just one is enough. Namely, fftpack2 uses the same data storage specification as Fortran FFTPACK (also used by Numeric.FFT and Matlab, though with somewhat different formal definitions). - Generic convolution routines that allow quick and easy way of introducing new pseudo-differential operators with the same performance as core pseudo-differential operators. - All functions have complete documentation strings. - A rather complete testing site. Note that fftpack2 requires the latest F2PY that you can get from http://cens.ioc.ee/projects/f2py2e/2.x/F2PY-2-latest.tar.gz For testing, fftpack2 uses scipy_test from SciPy CVS repository. For building/testing instructions and for various notes, including open questions, see NOTES.txt file after unpacking fftpack2-0.1.tar.gz. As usual, comments, suggestions, and criticism are most welcome. Regards, Pearu ------------------------------- fftpack2 timing results: ------------------------------- Fast Fourier Transform ======================================================== | real input | complex input -------------------------------------------------------- size |fftpack2| FFT | scipy |fftpack2| FFT | scipy -------------------------------------------------------- 100 | 0.38 | 0.39 | 0.38 | 0.40 | 0.40 | 0.38 (secs for7000calls) 1000 | 0.31 | 0.63 | 0.60 | 0.54 | 0.64 | 0.61 (secs for 2000 256 | 0.60 | 0.75 | 0.62 | 0.71 | 0.78 | 0.66 (secs for 10000 512 | 0.77 | 1.30 | 1.00 | 0.95 | 1.30 | 1.01 (secs for 10000 1024 | 0.14 | 0.26 | 0.18 | 0.17 | 0.25 | 0.19 (secs for 1000 2048 | 0.21 | 0.51 | 0.36 | 0.34 | 0.65 | 0.54 (secs for 1000 4096 | 0.28 | 1.08 | 0.66 | 0.56 | 0.93 | 0.79 (secs for 500 8192 | 1.09 | 3.88 | 3.94 | 2.19 | 4.36 | 3.48 (secs for 500 Inverse Fast Fourier Transform ======================================================== | real input | complex input -------------------------------------------------------- size |fftpack2| FFT | scipy |fftpack2| FFT | scipy -------------------------------------------------------- 100 | 0.17 | 0.26 | 0.63 | 0.45 | 0.87 | 0.85 (secs for 7000 1000 | 0.34 | 1.24 | 1.25 | 0.72 | 1.29 | 1.29 (secs for 2000 256 | 0.62 | 1.57 | 1.44 | 0.69 | 1.62 | 1.47 (secs for 10000 512 | 0.80 | 2.69 | 2.30 | 1.00 | 2.62 | 2.20 (secs for 10000 1024 | 0.12 | 0.51 | 0.41 | 0.18 | 0.54 | 0.44 (secs for 1000 2048 | 0.23 | 1.16 | 1.09 | 0.40 | 1.33 | 1.27 (secs for 1000 4096 | 0.35 | 1.75 | 1.44 | 0.63 | 1.72 | 1.54 (secs for 500 8192 | 1.34 | 5.71 | 6.02 | 2.40 | 6.14 | 5.67 (secs for 500 Multi-dimensional Fast Fourier Transform ======================================================== | real input | complex input -------------------------------------------------------- size |fftpack2| FFT | scipy |fftpack2| FFT | scipy -------------------------------------------------------- 100x100 | 0.43 | 0.87 | 0.81 | 0.48 | 0.88 | 0.82 (secs for 100 1000x100 | 0.54 | 0.78 | 0.72 | 0.56 | 0.73 | 0.75 (secs for 7 256x256 | 0.69 | 0.72 | 0.62 | 0.67 | 0.72 | 0.64 (secs for 10 512x512 | 0.81 | 0.91 | 0.84 | 0.81 | 0.87 | 0.81 (secs for 3 Fast Fourier Transform (real data) ================================== size |fftpack2| FFT | scipy ---------------------------------- 100 | 0.36 | 0.47 | 0.47 (secs for 7000 calls) 1000 | 0.29 | 0.38 | 0.38 (secs for 2000 calls) 256 | 0.55 | 0.76 | 0.81 (secs for 10000 calls) 512 | 0.67 | 1.06 | 1.07 (secs for 10000 calls) 1024 | 0.10 | 0.18 | 0.17 (secs for 1000 calls) 2048 | 0.16 | 0.30 | 0.30 (secs for 1000 calls) 4096 | 0.20 | 0.37 | 0.32 (secs for 500 calls) 8192 | 0.75 | 1.29 | 1.26 (secs for 500 calls) Inverse Fast Fourier Transform (real data) ================================== size |fftpack2| FFT | scipy ---------------------------------- 100 | 0.39 | 0.90 | 0.92 (secs for 7000 calls) 1000 | 0.32 | 0.63 | 0.70 (secs for 2000 calls) 256 | 0.59 | 1.37 | 1.39 (secs for 10000 calls) 512 | 0.73 | 1.70 | 1.80 (secs for 10000 calls) 1024 | 0.11 | 0.27 | 0.27 (secs for 1000 calls) 2048 | 0.20 | 0.45 | 0.44 (secs for 1000 calls) 4096 | 0.24 | 0.65 | 0.68 (secs for 500 calls) 8192 | 0.73 | 1.98 | 2.06 (secs for 500 calls) Shifting periodic functions ============================== size | optimized | naive ------------------------------ 100 | 0.09 | 0.52 (secs for 1500 calls) 1000 | 0.06 | 0.66 (secs for 300 calls) 256 | 0.10 | 0.84 (secs for 1500 calls) 512 | 0.10 | 1.02 (secs for 1000 calls) 1024 | 0.07 | 1.07 (secs for 500 calls) 2048 | 0.06 | 0.80 (secs for 200 calls) 4096 | 0.00 | 0.86 (secs for 100 calls) 8192 | 0.13 | 1.23 (secs for 50 calls) Differentiation of periodic functions ===================================== size | convolve | naive ------------------------------------- 100 | 0.09 | 0.59 (secs for 1500 calls) 1000 | 0.06 | 0.75 (secs for 300 calls) 256 | 0.11 | 0.97 (secs for 1500 calls) 512 | 0.09 | 1.21 (secs for 1000 calls) 1024 | 0.08 | 1.19 (secs for 500 calls) 2048 | 0.06 | 1.11 (secs for 200 calls) 4096 | 0.09 | 1.19 (secs for 100 calls) 8192 | 0.14 | 1.48 (secs for 50 calls) Tilbert transform of periodic functions ========================================= size | optimized | naive ----------------------------------------- 100 | 0.09 | 0.54 (secs for 1500 calls) 1000 | 0.06 | 0.60 (secs for 300 calls) 256 | 0.10 | 0.77 (secs for 1500 calls) 512 | 0.09 | 0.89 (secs for 1000 calls) 1024 | 0.07 | 0.90 (secs for 500 calls) 2048 | 0.05 | 0.83 (secs for 200 calls) 4096 | 0.07 | 0.92 (secs for 100 calls) 8192 | 0.11 | 1.04 (secs for 50 calls) . Hilbert transform of periodic functions ========================================= size | optimized | naive ----------------------------------------- 100 | 0.09 | 0.47 (secs for 1500 calls) 1000 | 0.06 | 0.48 (secs for 300 calls) 256 | 0.10 | 0.68 (secs for 1500 calls) 512 | 0.09 | 0.77 (secs for 1000 calls) 1024 | 0.07 | 0.74 (secs for 500 calls) 2048 | 0.06 | 0.72 (secs for 200 calls) 4096 | 0.07 | 0.79 (secs for 100 calls) 8192 | 0.11 | 0.93 (secs for 50 calls) From sarah_benson at nomoreaccent.com Sun Sep 29 16:45:38 2002 From: sarah_benson at nomoreaccent.com (Sarah Benson) Date: Sun, 29 Sep 2002 15:45:38 -0500 Subject: [SciPy-dev] Q: DOES YOUR FOREIGN ACCENT SIMPLY GET IN THE WAY? Message-ID: <20020929205204.95E2E3EACE@www.scipy.com> Q: " Would you like to Lose Your Accent ? " - DO YOU FIND OTHERS HAVE A HARD TIME UNDERSTANDING WHAT YOU ARE TRYING TO CONVEY? - DO YOU FIND THE NEED TO REPEAT YOURSELF FOR OTHERS TO UNDERSTAND YOU CLEARLY? - DO YOU FEEL EMBARRASSED OR LESS CONFIDENT WHEN TALKING TO WORK COLLEAGUES? - DO YOU WISH TO COMMUNICATE YOUR THOUGHTS MORE EFFECTIVELY? - DOES YOUR FOREIGN ACCENT SIMPLY GET IN THE WAY? Introducing the Krieger Method, an innovative teaching system, designed to help you develop effective communication skills. Andy Krieger, inventor of this miracle product, originated this revolutionary idea whilst working with actors and their accents within the Hollywood film industry. Contact us to learn about the true benefits you can obtain to communicate with confidence!! "Make your accent simply disappear!" For Accent Reduction Empowerment, visit us on the web today at :- www.nomoreaccent.com Thank you for your time and interest... Sarah J. Benson Marketing Co-ordinator If you feel this is email is not of interest to you, then we sincerely apologize and guarantee you will not receive another email from us, unless you otherwise wish. From skip at pobox.com Mon Sep 30 09:46:50 2002 From: skip at pobox.com (Skip Montanaro) Date: Mon, 30 Sep 2002 08:46:50 -0500 Subject: [SciPy-dev] Switch to syncmail for checkins? Message-ID: <15768.21962.488940.883253@12-248-11-90.client.attbi.com> I *really* like seeing context diffs in the checkin mail (e.g. stuff sent to scipy-cvs at scipy.org). As a naive scipy developer it gives me a snippet of code to scan. As a potential code reviewer it makes it dead simple for me to quickly "desk check" the code being checked in. On the python-checkins list mail is sent on a fairly frequent basis (every couple weeks at least) of the sort, "did you mean X where you typed Y?" This catches a fair number of problems before they reach the wider world. The Python gang uses a script I believe Barry Warsaw wrote called syncmail. I'm not entirely sure how the CVS checkin process uses the CVSROOT/loginfo file, but I suspect only a single "ALL" entry is supported. A Perl script named log is already run during the commit process. It appends log info to $CVSROOT/CVSROOT/commitlog and sends the result to scipy-cvs at scipy.org (this is the typical scipy-cvs mail you get). Syncmail generates a more substantial message (includes the context diff I spoke of) but doesn't dump any output to the commitlog. Do people use the commitlog file? Neither the log script nor the commitlog file are checked into the CVS repository, so you have to login to scipy.org to view either of them. If people use the commitlog file I will make sure it continues to be generated, but otherwise would like to dump the current log script in favor of syncmail. Let me know your thoughts. -- Skip Montanaro - skip at pobox.com "Airplanes don't fly until the paperwork equals the weight of the aircraft. Same with i18N." - from the "Perl, Unicode and i18N FAQ" From skip at pobox.com Mon Sep 30 10:01:15 2002 From: skip at pobox.com (Skip Montanaro) Date: Mon, 30 Sep 2002 09:01:15 -0500 Subject: [SciPy-dev] setup.py traceback Message-ID: <15768.22827.596066.102006@12-248-11-90.client.attbi.com> I just cvsup'd and now get this traceback when executing setup.py (no matter which command I try): /usr/local/lib/python2.3/pre.py:94: DeprecationWarning: Please use the 're' module, not the 'pre' module DeprecationWarning) Traceback (most recent call last): File "setup.py", line 129, in ? install_package() File "setup.py", line 95, in install_package config.extend([get_package_config(x,parent_package)for x in standard_packages]) File "setup.py", line 45, in get_package_config config = mod.configuration(parent) File "linalg/setup_linalg.py", line 33, in configuration atlas_info = get_info('atlas') File "scipy_distutils/system_info.py", line 127, in get_info return cl().get_info() File "scipy_distutils/system_info.py", line 224, in __init__ assert type(self.search_static_first) is type(0) AssertionError Anyone else seeing this? I'm running on Mandrake 8.1 with Python CVS. Skip From pearu at cens.ioc.ee Mon Sep 30 10:22:16 2002 From: pearu at cens.ioc.ee (Pearu Peterson) Date: Mon, 30 Sep 2002 17:22:16 +0300 (EEST) Subject: [SciPy-dev] setup.py traceback In-Reply-To: <15768.22827.596066.102006@12-248-11-90.client.attbi.com> Message-ID: On Mon, 30 Sep 2002, Skip Montanaro wrote: > I just cvsup'd and now get this traceback when executing setup.py (no matter > which command I try): > > /usr/local/lib/python2.3/pre.py:94: DeprecationWarning: Please use the > 're' module, not the 'pre' module DeprecationWarning) > Traceback (most recent call last): > File "setup.py", line 129, in ? > install_package() > File "setup.py", line 95, in install_package > config.extend([get_package_config(x,parent_package)for x in standard_packages]) > File "setup.py", line 45, in get_package_config > config = mod.configuration(parent) > File "linalg/setup_linalg.py", line 33, in configuration > atlas_info = get_info('atlas') > File "scipy_distutils/system_info.py", line 127, in get_info > return cl().get_info() > File "scipy_distutils/system_info.py", line 224, in __init__ > assert type(self.search_static_first) is type(0) > AssertionError > > Anyone else seeing this? I'm running on Mandrake 8.1 with Python CVS. It must be related to the changes in ConfigParser of Python 2.3 compared to earlier Python versions. Note that it may not be safe to just remove this assertion. It really depends what is the output ConfigParser.getboolean. If it is int or bool, then change the assert statement to assert isinstance(self.search_static_first,int) But if it is a string, for example, '0' or '1', then removing the assert statement will lead to incorrect results because self.search_static_first is later used as if self.search_static_first: #do staff 1 else: #do staff 2 and #do staff 1 is executed even if self.search_static_first=='0'. Hmm, the result of ConfigParser.getboolean could be also None... So, could you check what is the type/value of self.search_static_first in your case? Pearu From pearu at cens.ioc.ee Mon Sep 30 12:07:11 2002 From: pearu at cens.ioc.ee (Pearu Peterson) Date: Mon, 30 Sep 2002 19:07:11 +0300 (EEST) Subject: [SciPy-dev] Switch to syncmail for checkins? In-Reply-To: <15768.21962.488940.883253@12-248-11-90.client.attbi.com> Message-ID: On Mon, 30 Sep 2002, Skip Montanaro wrote: > I *really* like seeing context diffs in the checkin mail ... Me too. > Do people use the commitlog file? Not me. And it also seems that others don't (nobody has referred to it, AFAIK). > If people use the commitlog file I will make sure > it continues to be generated, but otherwise would like to dump the current > log script in favor of syncmail. Do you know if viewcvs uses the commitlog file? (That's easy to check out after you commit your changes..) Pearu From skip at pobox.com Mon Sep 30 12:14:32 2002 From: skip at pobox.com (Skip Montanaro) Date: Mon, 30 Sep 2002 11:14:32 -0500 Subject: [SciPy-dev] Switch to syncmail for checkins? In-Reply-To: References: <15768.21962.488940.883253@12-248-11-90.client.attbi.com> Message-ID: <15768.30824.133585.922885@12-248-11-90.client.attbi.com> Pearu> Do you know if viewcvs uses the commitlog file? (That's easy to Pearu> check out after you commit your changes..) I don't think it does. SF uses viewcvs to browse code online, and Python's CVSROOT/loginfo doesn't reference anything which would update commitlog. I'll commit. If tragedy ensues I can always back it out. Skip From eric at enthought.com Mon Sep 30 17:48:24 2002 From: eric at enthought.com (eric jones) Date: Mon, 30 Sep 2002 16:48:24 -0500 Subject: [SciPy-dev] fftpack2 for review In-Reply-To: Message-ID: <001501c268cb$1a23f890$6b01a8c0@ericlaptop> Hey Pearu, I'll look at this tonight. Thanks, eric > -----Original Message----- > From: scipy-dev-admin at scipy.net [mailto:scipy-dev-admin at scipy.net] On > Behalf Of Pearu Peterson > Sent: Saturday, September 28, 2002 3:54 PM > To: scipy-dev at scipy.org > Subject: [SciPy-dev] fftpack2 for review > > > Dear SciPy devels, > > Please find a scipy.fftpack replacement candidate fftpack2 from > > http://cens.ioc.ee/~pearu/misc/fftpack2-0.1.tar.gz > > for review. fftpack2 main features include: > > - Optional support for high-performance FFT libraries such as FFTW and > DJBFFT libraries. By default, Fortran FFTPACK is used and other > libraries are automatically detected by > the scipy_distutils/system_info.py script. > > - Support for both real and complex DFT's and their inverse > transforms. When used with FFTW and/or DJBFFT libraries then fftpack2 > routines are considerably faster than Numeric.FFT and the current > scipy.fftpack. > Some comparison timings are included at the end of this message. > > - Implementation of differentiation and integration of periodic > sequences, various pseudo-differential operators such as Tilbert > transform, Hilbert transform, hyperbolic pseudo-differential > operators, their inverses, etc. > > - Because different FFT libraries use different data storage convention, > fftpack2 implements interface to these conventions so that users > and developers need not to learn all these conventions, just > one is enough. Namely, fftpack2 uses the same data storage > specification as Fortran FFTPACK (also used by Numeric.FFT and > Matlab, though with somewhat different formal definitions). > > - Generic convolution routines that allow quick and easy way of > introducing new pseudo-differential operators with the same > performance as core pseudo-differential operators. > > - All functions have complete documentation strings. > > - A rather complete testing site. > > Note that fftpack2 requires the latest F2PY that you can get from > > http://cens.ioc.ee/projects/f2py2e/2.x/F2PY-2-latest.tar.gz > > For testing, fftpack2 uses scipy_test from SciPy CVS repository. > > For building/testing instructions and for various notes, including open > questions, see NOTES.txt file after unpacking fftpack2-0.1.tar.gz. > > As usual, comments, suggestions, and criticism are most welcome. > > Regards, > Pearu > > ------------------------------- > fftpack2 timing results: > ------------------------------- > Fast Fourier Transform > ======================================================== > | real input | complex input > -------------------------------------------------------- > size |fftpack2| FFT | scipy |fftpack2| FFT | scipy > -------------------------------------------------------- > 100 | 0.38 | 0.39 | 0.38 | 0.40 | 0.40 | 0.38 (secs > for7000calls) > 1000 | 0.31 | 0.63 | 0.60 | 0.54 | 0.64 | 0.61 (secs for 2000 > 256 | 0.60 | 0.75 | 0.62 | 0.71 | 0.78 | 0.66 (secs for 10000 > 512 | 0.77 | 1.30 | 1.00 | 0.95 | 1.30 | 1.01 (secs for 10000 > 1024 | 0.14 | 0.26 | 0.18 | 0.17 | 0.25 | 0.19 (secs for 1000 > 2048 | 0.21 | 0.51 | 0.36 | 0.34 | 0.65 | 0.54 (secs for 1000 > 4096 | 0.28 | 1.08 | 0.66 | 0.56 | 0.93 | 0.79 (secs for 500 > 8192 | 1.09 | 3.88 | 3.94 | 2.19 | 4.36 | 3.48 (secs for 500 > > Inverse Fast Fourier Transform > ======================================================== > | real input | complex input > -------------------------------------------------------- > size |fftpack2| FFT | scipy |fftpack2| FFT | scipy > -------------------------------------------------------- > 100 | 0.17 | 0.26 | 0.63 | 0.45 | 0.87 | 0.85 (secs for 7000 > 1000 | 0.34 | 1.24 | 1.25 | 0.72 | 1.29 | 1.29 (secs for 2000 > 256 | 0.62 | 1.57 | 1.44 | 0.69 | 1.62 | 1.47 (secs for 10000 > 512 | 0.80 | 2.69 | 2.30 | 1.00 | 2.62 | 2.20 (secs for 10000 > 1024 | 0.12 | 0.51 | 0.41 | 0.18 | 0.54 | 0.44 (secs for 1000 > 2048 | 0.23 | 1.16 | 1.09 | 0.40 | 1.33 | 1.27 (secs for 1000 > 4096 | 0.35 | 1.75 | 1.44 | 0.63 | 1.72 | 1.54 (secs for 500 > 8192 | 1.34 | 5.71 | 6.02 | 2.40 | 6.14 | 5.67 (secs for 500 > > Multi-dimensional Fast Fourier Transform > ======================================================== > | real input | complex input > -------------------------------------------------------- > size |fftpack2| FFT | scipy |fftpack2| FFT | scipy > -------------------------------------------------------- > 100x100 | 0.43 | 0.87 | 0.81 | 0.48 | 0.88 | 0.82 (secs for 100 > 1000x100 | 0.54 | 0.78 | 0.72 | 0.56 | 0.73 | 0.75 (secs for 7 > 256x256 | 0.69 | 0.72 | 0.62 | 0.67 | 0.72 | 0.64 (secs for 10 > 512x512 | 0.81 | 0.91 | 0.84 | 0.81 | 0.87 | 0.81 (secs for 3 > > Fast Fourier Transform (real data) > ================================== > size |fftpack2| FFT | scipy > ---------------------------------- > 100 | 0.36 | 0.47 | 0.47 (secs for 7000 calls) > 1000 | 0.29 | 0.38 | 0.38 (secs for 2000 calls) > 256 | 0.55 | 0.76 | 0.81 (secs for 10000 calls) > 512 | 0.67 | 1.06 | 1.07 (secs for 10000 calls) > 1024 | 0.10 | 0.18 | 0.17 (secs for 1000 calls) > 2048 | 0.16 | 0.30 | 0.30 (secs for 1000 calls) > 4096 | 0.20 | 0.37 | 0.32 (secs for 500 calls) > 8192 | 0.75 | 1.29 | 1.26 (secs for 500 calls) > > Inverse Fast Fourier Transform (real data) > ================================== > size |fftpack2| FFT | scipy > ---------------------------------- > 100 | 0.39 | 0.90 | 0.92 (secs for 7000 calls) > 1000 | 0.32 | 0.63 | 0.70 (secs for 2000 calls) > 256 | 0.59 | 1.37 | 1.39 (secs for 10000 calls) > 512 | 0.73 | 1.70 | 1.80 (secs for 10000 calls) > 1024 | 0.11 | 0.27 | 0.27 (secs for 1000 calls) > 2048 | 0.20 | 0.45 | 0.44 (secs for 1000 calls) > 4096 | 0.24 | 0.65 | 0.68 (secs for 500 calls) > 8192 | 0.73 | 1.98 | 2.06 (secs for 500 calls) > > > Shifting periodic functions > ============================== > size | optimized | naive > ------------------------------ > 100 | 0.09 | 0.52 (secs for 1500 calls) > 1000 | 0.06 | 0.66 (secs for 300 calls) > 256 | 0.10 | 0.84 (secs for 1500 calls) > 512 | 0.10 | 1.02 (secs for 1000 calls) > 1024 | 0.07 | 1.07 (secs for 500 calls) > 2048 | 0.06 | 0.80 (secs for 200 calls) > 4096 | 0.00 | 0.86 (secs for 100 calls) > 8192 | 0.13 | 1.23 (secs for 50 calls) > > Differentiation of periodic functions > ===================================== > size | convolve | naive > ------------------------------------- > 100 | 0.09 | 0.59 (secs for 1500 calls) > 1000 | 0.06 | 0.75 (secs for 300 calls) > 256 | 0.11 | 0.97 (secs for 1500 calls) > 512 | 0.09 | 1.21 (secs for 1000 calls) > 1024 | 0.08 | 1.19 (secs for 500 calls) > 2048 | 0.06 | 1.11 (secs for 200 calls) > 4096 | 0.09 | 1.19 (secs for 100 calls) > 8192 | 0.14 | 1.48 (secs for 50 calls) > > Tilbert transform of periodic functions > ========================================= > size | optimized | naive > ----------------------------------------- > 100 | 0.09 | 0.54 (secs for 1500 calls) > 1000 | 0.06 | 0.60 (secs for 300 calls) > 256 | 0.10 | 0.77 (secs for 1500 calls) > 512 | 0.09 | 0.89 (secs for 1000 calls) > 1024 | 0.07 | 0.90 (secs for 500 calls) > 2048 | 0.05 | 0.83 (secs for 200 calls) > 4096 | 0.07 | 0.92 (secs for 100 calls) > 8192 | 0.11 | 1.04 (secs for 50 calls) > . > Hilbert transform of periodic functions > ========================================= > size | optimized | naive > ----------------------------------------- > 100 | 0.09 | 0.47 (secs for 1500 calls) > 1000 | 0.06 | 0.48 (secs for 300 calls) > 256 | 0.10 | 0.68 (secs for 1500 calls) > 512 | 0.09 | 0.77 (secs for 1000 calls) > 1024 | 0.07 | 0.74 (secs for 500 calls) > 2048 | 0.06 | 0.72 (secs for 200 calls) > 4096 | 0.07 | 0.79 (secs for 100 calls) > 8192 | 0.11 | 0.93 (secs for 50 calls) > > > _______________________________________________ > Scipy-dev mailing list > Scipy-dev at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-dev