From wjdandreta at att.net Thu Dec 1 01:06:35 2005 From: wjdandreta at att.net (Bill Dandreta) Date: Thu, 01 Dec 2005 01:06:35 -0500 Subject: [SciPy-user] (OT) Grouping of data points. In-Reply-To: <438E152B.6050804@csun.edu> References: <438DCA77.8070303@att.net> <438E152B.6050804@csun.edu> Message-ID: <438E92EB.9030106@att.net> Stephen Walton wrote: >You need graph theory. I just did a similar project (in MATLAB, but >anyway) having to do with sunspots. I needed to put sunspots into >groups by finding sunspots which were "close" in latitude and >longitude. The eventual algorithm looked like this: > >1. For each point i, compute its distance from point j. (This part of >the algorithm is n**2, unfortunately.) Set A[i,j] and A[j,i] to 1 if >the distance is less than some value, and 0 if it is greater. A is in >fact an adjacency graph in MATLAB-ese, where A[i,j] is nonzero if vertex >i of a graph is connected to vertex j by an edge. "Distance" here can >have any definition of course; it doesn't have to be Cartesian. > >2. Find the components in the resulting graph, defined as those sets of >vertices which are in fact connected. The algorithm for doing this is >at http://www.ececs.uc.edu/~gpurdy/lec20.html, in section 20.2. > >I also recommend the graph theory tutorial at >http://www.utm.edu/departments/math/graph. > Thanks Stephen, It looks like graph theory might fit the bill. The links look interesting but are over my head right now. It will take some studying for me to come up to speed. Bill From fonnesbeck at gmail.com Thu Dec 1 14:53:05 2005 From: fonnesbeck at gmail.com (Chris Fonnesbeck) Date: Thu, 1 Dec 2005 14:53:05 -0500 Subject: [SciPy-user] strange scipy.f2py error Message-ID: <723eb6930512011153jc8214eei1572c16f91a2a4c6@mail.gmail.com> For some reason, the fcompiler object gets set to "None" when building on a 10.3 machine. Using today's svn build of scipy_core and the IBM XLF compiler: compiling Fortran sources Traceback (most recent call last): File "setup.py", line 17, in ? ext_modules = [flib] File "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/scipy/distutils/core.py", line 91, in setup return old_setup(**new_attr) File "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/distutils/core.py", line 149, in setup dist.run_commands() File "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/distutils/dist.py", line 946, in run_commands self.run_command(cmd) File "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/distutils/dist.py", line 966, in run_command cmd_obj.run() File "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/distutils/command/build.py", line 112, in run self.run_command(cmd_name) File "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/distutils/cmd.py", line 333, in run_command self.distribution.run_command(command) File "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/distutils/dist.py", line 966, in run_command cmd_obj.run() File "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/scipy/distutils/command/build_ext.py", line 107, in run self.build_extensions() File "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/distutils/command/build_ext.py", line 405, in build_extensions self.build_extension(ext) File "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/scipy/distutils/command/build_ext.py", line 246, in build_extension f_objects += self.fcompiler.compile(f_sources, AttributeError: 'NoneType' object has no attribute 'compile' -- Chris Fonnesbeck Atlanta, GA From agn at noc.soton.ac.uk Thu Dec 1 19:38:31 2005 From: agn at noc.soton.ac.uk (George Nurser) Date: Fri, 2 Dec 2005 00:38:31 +0000 Subject: [SciPy-user] fortran compilers, f2py and scipy core. In-Reply-To: <20051201110322.19634.77031.Mailman@scipy.org> References: <20051201110322.19634.77031.Mailman@scipy.org> Message-ID: <721B8826-4801-4957-B722-6BADAB288566@noc.soton.ac.uk> This may be a stupid question, but ... I want to use f2py together with scipy core, and new scipy, on an Opteron. I am used to writing my fortran programs with ifort 9.0. Does this mean that I have to compile scipy, scipy core with ifort, or can a scipy core compiled with gcc coexist with fortran routines, compiled on ifort 9.0, linked into f2py? Problem is there don't seem to be options set for 64-bit emt ifort in scipy/distutils/fcompiler/ --George Nurser. From dkuhlman at cutter.rexx.com Thu Dec 1 20:27:47 2005 From: dkuhlman at cutter.rexx.com (Dave Kuhlman) Date: Thu, 1 Dec 2005 17:27:47 -0800 Subject: [SciPy-user] Version 0.3.2 or 0.4.3? Message-ID: <20051202012747.GA97291@cutter.rexx.com> At www.scipy.org I find SciPy_complete-0.3.2.tar.gz. At http://sourceforge.net/projects/scipy/, I find scipy-0.4.3.tar.gz. Are these two separate projects? They seem very different. Could someone tell me where I can find a description of the difference between these two and a guide on how I determine which I should be using. I'm sure this question must have been raised before, but I did some searching at www.scipy.org and in the FAQ and in the mail-list archives and could not find anything helpful. Thanks in advance for help. Dave -- Dave Kuhlman http://www.rexx.com/~dkuhlman From ryanlists at gmail.com Thu Dec 1 20:58:17 2005 From: ryanlists at gmail.com (Ryan Krauss) Date: Thu, 1 Dec 2005 20:58:17 -0500 Subject: [SciPy-user] Version 0.3.2 or 0.4.3? In-Reply-To: <20051202012747.GA97291@cutter.rexx.com> References: <20051202012747.GA97291@cutter.rexx.com> Message-ID: They are the same and yet different. 0.4.3 is "new scipy". You will find more on the list if you look for information about new scipy. You will probably get a more detailed answer from some one else later, but the biggest difference is that "old scipy" - i.e. <=0.3.2 depends on Numeric and/or numarray for matrices and arrays. Travis Oliphant has redesigned the matrix/array API for "new scipy". You can read about why he did this in the first chapter of a book he has written about new scipy. The first two chapters can be downloaded for free with a link on this page: http://www.tramy.us/guidetoscipy.html I don't have a good feel for how stable new scipy is and how many people are using it for their everyday work. I am actually using old scipy still myself. Ryan On 12/1/05, Dave Kuhlman wrote: > > At www.scipy.org I find SciPy_complete-0.3.2.tar.gz. > > At http://sourceforge.net/projects/scipy/, I find > scipy-0.4.3.tar.gz. > > Are these two separate projects? They seem very different. > > Could someone tell me where I can find a description of the > difference between these two and a guide on how I determine which > I should be using. > > I'm sure this question must have been raised before, but I did > some searching at www.scipy.org and in the FAQ and in the > mail-list archives and could not find anything helpful. > > Thanks in advance for help. > > Dave > > -- > Dave Kuhlman > http://www.rexx.com/~dkuhlman > > _______________________________________________ > SciPy-user mailing list > SciPy-user at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-user > From mkuemmel at eso.org Fri Dec 2 02:03:40 2005 From: mkuemmel at eso.org (Martin Kuemmel) Date: Fri, 2 Dec 2005 08:03:40 +0100 Subject: [SciPy-user] AstroAsciiData: first release! Message-ID: <200512020704.jB2747P03741@serapis.hq.eso.org> Dear all, this email is the announcement of the first release of the Python module AstroAsciiData. With this module it is possible to: * read ASCII tables; * access its elements for reading and writing; * save the ASCII table back to a file; * delete/add rows and columns; * convert columns to numarrays. To get a first impression on what this module does and how it works, please check the example below. More information, and of course the software itself and the manual, is available on the project webpages at: http://www.stecf.org/software/astroasciidata/ The software was developed as a contribution to the AstroLib project. Any kind of feedback can be posted on the AstroAsciiData wiki at http://www.scipy.org/wikis/topical_software/AstroAsciiData or sent by email to AstroAsciiData at stecf.org Please check on the webpage if the module could be useful for your work and give it a try! Cheers, Martin Kuemmel Jonas Haase ----------------------------------------------------------------------------- Example ======= What follows is an example of how the AstroAsciiData module might be used. With this example also some of the basic functionality of the module is explained. More example can be found in Section 3 of the User Manual. * Imagine you would like to work with the file "webexa.txt": # # Some objects on the sky # J02994.34+62.4844 189.2207323 62.2357983 231.9 521.8 26.87 0.1 J09234.54+62.9485 189.1408929 62.2376331 720.4 962.1 24.97 0.1 J09267.65+62.8293 189.1409453 62.1696844 927.1 327.9 25.30 0.1 J09738.55+62.4327 188.9014716 62.2037839 223.7 192.5 25.95 0.1 * To load this ASCII table, go into Python, load the AstroAsciiData module and read in the table with: >>> import asciidata >>> demo = asciidata.open('webexa.txt') >>> print demo # # Some objects on the sky # J02994.34+62.4844 189.2207323 62.2357983 231.9 521.8 26.87 0.1 J09234.54+62.9485 189.1408929 62.2376331 720.4 962.1 24.97 0.1 J09267.65+62.8293 189.1409453 62.1696844 927.1 327.9 25.30 0.1 J09738.55+62.4327 188.9014716 62.2037839 223.7 192.5 25.95 0.1 The print command at the end was just to confirm the correct reading of the file. * Let's assume that column4 and 5 contain object coordinates. You would like to compute and store the distance to the distances to the image center at (x,y)=(500.0,500.0): >>> import math >>> xcen=500.0 >>> ycen=500.0 >>> for index in range(demo.nrows): ... demo['distance'][index] = math.sqrt((demo[3][index]-xcen)**2+(demo[4][inde x]-ycen)**2) ... >>> print demo # # Some objects on the sky # J02994.34+62.4844 189.2207323 62.2357983 231.9 521.8 26.87 0.1 2.689849e+02 J09234.54+62.9485 189.1408929 62.2376331 720.4 962.1 24.97 0.1 5.119693e+02 J09267.65+62.8293 189.1409453 62.1696844 927.1 327.9 25.30 0.1 4.604702e+02 J09738.55+62.4327 188.9014716 62.2037839 223.7 192.5 25.95 0.1 4.133980e+02 As the print command reveals, there is now a new column with the computed values. * Now you would like to save the result: >>> demo.flush() >>> work>more webexa.txt # # Some objects on the sky # J02994.34+62.4844 189.2207323 62.2357983 231.9 521.8 26.87 0.1 2.689849e+02 J09234.54+62.9485 189.1408929 62.2376331 720.4 962.1 24.97 0.1 5.119693e+02 J09267.65+62.8293 189.1409453 62.1696844 927.1 327.9 25.30 0.1 4.604702e+02 J09738.55+62.4327 188.9014716 62.2037839 223.7 192.5 25.95 0.1 4.133980e+02 The new column was saved back to the file! From schofield at ftw.at Fri Dec 2 05:39:16 2005 From: schofield at ftw.at (Ed Schofield) Date: Fri, 2 Dec 2005 10:39:16 +0000 Subject: [SciPy-user] Version 0.3.2 or 0.4.3? In-Reply-To: <20051202012747.GA97291@cutter.rexx.com> References: <20051202012747.GA97291@cutter.rexx.com> Message-ID: On 02/12/2005, at 1:27 AM, Dave Kuhlman wrote: > > At www.scipy.org I find SciPy_complete-0.3.2.tar.gz. > > At http://sourceforge.net/projects/scipy/, I find > scipy-0.4.3.tar.gz. > > Are these two separate projects? They seem very different. > > Could someone tell me where I can find a description of the > difference between these two and a guide on how I determine which > I should be using. Hi Dave, I suggest you use the new scipy, version 0.4.3. The new scipy is already stable enough that 1360+ unit tests pass (usually all). It's also being continuously improved, so if you post any questions here you are likely to get a very fast response. Development of the old version has ceased. The procedure is to install scipy_core (from http:// numeric.scipy.org/), then scipy. Good luck, -- Ed From oliphant.travis at ieee.org Fri Dec 2 10:50:22 2005 From: oliphant.travis at ieee.org (Travis Oliphant) Date: Fri, 02 Dec 2005 08:50:22 -0700 Subject: [SciPy-user] [SciPy-dev] PyArray_New problem In-Reply-To: <4390128B.1090200@ntc.zcu.cz> References: <438EC8BF.9040402@ntc.zcu.cz> <438EE782.9090708@ntc.zcu.cz> <4390128B.1090200@ntc.zcu.cz> Message-ID: <43906D3E.4010109@ieee.org> Robert Cimrman wrote: >Could someone tell me what I am doing wrong? I would like to use a >function like the snippet below to create an array. > >PyArrayObject *helper_newCArrayObject_i32( int32 len, int32 *array ) { > intp plen[1]; > PyArrayObject *obj = 0; > > plen[0] = len; > printf( "11111 %d\n", PyArray_INT32 ); >/* obj = (PyArrayObject *) PyArray_SimpleNew( 1, plen, PyArray_INT32 ); */ > > obj = (PyArrayObject *) PyArray_New( &PyArray_Type, 1, plen, >PyArray_INT32, NULL, NULL, 0, CARRAY_FLAGS, NULL ); >.... > > First of all, don't pass in CARRAY_FLAGS when the data argument to PyArray_New is NULL. A non-zero flags entry tells the subroutine to create a FORTRAN strides array if no data is passed. Remember: DATA flags are only to describe already available memory. If you create the memory in PyArray_New, then the only thing to decide is FORTRAN or C- contiguous. So, in this routine, you are creating a Fortran array. Perhaps this is causing problems later. Also, you are not showing us the rest of the code. Your traceback is showing PyArray_ValidType being called which is not shown anywere... -Travis From josemaria.alkala at gmail.com Fri Dec 2 10:57:33 2005 From: josemaria.alkala at gmail.com (=?iso-8859-1?q?Jos=E9_Mar=EDa?=) Date: Fri, 2 Dec 2005 16:57:33 +0100 Subject: [SciPy-user] [Scipy installation] No admin account Message-ID: <200512021657.33568.josemaria.alkala@gmail.com> My name is Jos? Mar?a and this is my first post here. I have started this week learning both: python and scipy. I had no problem to install Scipy at windows and linux in my computer. I would like to use Scipy at work where we use windows 2000. The installation software tells me than i can't install Scipy because I don't have enough privilegies. There exist any alternative to install Scipy without an administrative account? Best regards from Spain (sorry my english, please), Jos? Mar?a From svetosch at gmx.net Fri Dec 2 11:53:16 2005 From: svetosch at gmx.net (Sven Schreiber) Date: Fri, 02 Dec 2005 17:53:16 +0100 Subject: [SciPy-user] how to get matplotlib working with new scipy? Message-ID: <43907BFC.7070005@gmx.net> Dear experienced scipy users, I apologize if this is not the best/correct list to ask, but I joined only recently and so here goes: I'd like to try matplotlib, and I have the new scipy (core & rest) installed on win32. After installation, the command "from pylab import *" fails with the message "ImportError: No module named Numeric". That's not too surprising, but I'm unsure about the best strategy to pursue. Is matplotlib supposed to work with new scipy (alone, without extra numeric or numarray)? If so, how do I have to set it up? If numeric or numarray is still needed, is there any danger of "double definitions" of arrays etc., such that scripts could get confused or, worse, produce wrong results? (In theory I guess everything should be fine, but I'd be glad to hear what's the actual status quo with respect to known bugs and such.) Thanks much for your help, Sven From mcantor at stanford.edu Fri Dec 2 16:05:55 2005 From: mcantor at stanford.edu (mike cantor) Date: Fri, 02 Dec 2005 13:05:55 -0800 Subject: [SciPy-user] passings arrays into C extension In-Reply-To: <438BD81D.3080503@ieee.org> References: <438BD81D.3080503@ieee.org> Message-ID: <6.0.1.1.2.20051202130016.01f02ce8@mcantor.pobox.stanford.edu> Hi, What is the blessed way to pass SciPy arrays into C extension code (that is, to convert Array PthonObjs into a C int* or other array type). This is probably in documentation that I couldn't find somewhere and if that's the case I just need a pointer to it. Thanks, -mike From oliphant.travis at ieee.org Fri Dec 2 16:15:36 2005 From: oliphant.travis at ieee.org (Travis Oliphant) Date: Fri, 02 Dec 2005 14:15:36 -0700 Subject: [SciPy-user] passings arrays into C extension In-Reply-To: <6.0.1.1.2.20051202130016.01f02ce8@mcantor.pobox.stanford.edu> References: <438BD81D.3080503@ieee.org> <6.0.1.1.2.20051202130016.01f02ce8@mcantor.pobox.stanford.edu> Message-ID: <4390B978.6080903@ieee.org> mike cantor wrote: >Hi, > >What is the blessed way to pass SciPy arrays into C extension code (that >is, to convert Array PthonObjs into a C int* or other array type). > > What would you like the equivalent of? You can access the data attribute (which is the pointer to raw memory as) dptr = ( *)PyArray_DATA(array) You should be aware of PyArray_FLAGS(array) however because the data might be unaligned, not in machine-byte order, or not writeable, or not contiguous in memory. If you need a contiguous chunk of "behaved memory" you can use: /* This doesn't make sure you have an integer array */ newarr = PyArray_From_OF(array, CARRAY_FLAGS); dptr = (int *)PyArray_DATA(newarr); /* code that uses dptr */ Py_DECREF(newarr); If you need the "misbehaved" memory to receive the updates after the copy is made use CARRAY_FLAGS | UPDATEIFCOPY in the PyArray_From_OF(...) macro then when newarr is DECREF'd it will update the contents of array. If you are talking about passing something to the ctypes module, then int(array.__array_data__[0],0) will give you an integer that is a pointer to your data. -Travis From strawman at astraw.com Fri Dec 2 16:17:02 2005 From: strawman at astraw.com (Andrew Straw) Date: Fri, 02 Dec 2005 13:17:02 -0800 Subject: [SciPy-user] passings arrays into C extension In-Reply-To: <6.0.1.1.2.20051202130016.01f02ce8@mcantor.pobox.stanford.edu> References: <438BD81D.3080503@ieee.org> <6.0.1.1.2.20051202130016.01f02ce8@mcantor.pobox.stanford.edu> Message-ID: <4390B9CE.2040600@astraw.com> The best way (IMO) is to use the __array_struct__ interface: it's pretty fast, it's portable across Numeric, numarray (will be, anyway), and scipy core. See http://numeric.scipy.org/array_interface.html for more information. mike cantor wrote: >Hi, > >What is the blessed way to pass SciPy arrays into C extension code (that >is, to convert Array PthonObjs into a C int* or other array type). > >This is probably in documentation that I couldn't find somewhere and if >that's the case I just need a pointer to it. > >Thanks, >-mike > > >_______________________________________________ >SciPy-user mailing list >SciPy-user at scipy.net >http://www.scipy.net/mailman/listinfo/scipy-user > > From oliphant.travis at ieee.org Fri Dec 2 16:24:36 2005 From: oliphant.travis at ieee.org (Travis Oliphant) Date: Fri, 02 Dec 2005 14:24:36 -0700 Subject: [SciPy-user] Warnings about incompatibilities ahead Message-ID: <4390BB94.5010409@ieee.org> This is a warning regarding changes to the C-API of scipy core I'm going to check in (hopefully by the end of the day). 1) PyArray_Typecode structure is going away --- I always hated it. All C-API interfaces that use it will instead take a pointer to PyArray_Descr *. If the C-API actually used the funny fortran member of the structure, a new argument called fortran will be placed in the calling sequence. 2) The itemsize member on the array is going back into the PyArray_Descr where it belongs. Note that PyArray_ITEMSIZE(self) will not be affected its just that 3) There will be a new attribute .descr that returns the PyArray_Descr object (it's now a real object). 4) New C-API calls will be added. These changes are being made to facilitated nested records, but I think they are good changes anyway and now is better than later. I'm the one who has to pay the biggest price by fixing all the code in scipy core to get rid of PyArray_Typecode, references to self->itemsize and to allow for dynamic PyArray_Descr * objects. I noticed people are starting to use the C-API, so this is a warning not to 1) use PyArray_Typecode and 2) use direct access to the itemsize member of an array. Thanks, -Travis From jdhunter at ace.bsd.uchicago.edu Fri Dec 2 16:25:12 2005 From: jdhunter at ace.bsd.uchicago.edu (John Hunter) Date: Fri, 02 Dec 2005 15:25:12 -0600 Subject: [SciPy-user] egg dependency? Message-ID: <87d5kfdwef.fsf@peds-pc311.bsd.uchicago.edu> I just tried to install the new scipy 0.6.1 on my ubuntu linux, and got hit with peds-pc311:~/python/src/scipy_core-0.6.1> spsi Running from scipy core source directory. Traceback (most recent call last): File "setup.py", line 38, in ? setup_package() File "setup.py", line 7, in setup_package from scipy.distutils.core import setup File "/home/jdhunter/python/src/scipy_core-0.6.1/scipy/distutils/core.py", line 42, in ? from setuptools.command import bdist_egg, develop, easy_install, egg_info ImportError: cannot import name bdist_egg If the goal is to make scipy core as easy to install as Numeric, is it wise to require an egg dependency? In my understanding, egg still has installation issues of it's own -- eg, it is not installed with the python2.4 in Ubuntu Hoary, which is only 6-7 months old. My apologies if I am missing something obvious, because I haven't been able to follow this list in detail in the last hectic month. JDH From robert.kern at gmail.com Fri Dec 2 16:43:42 2005 From: robert.kern at gmail.com (Robert Kern) Date: Fri, 02 Dec 2005 13:43:42 -0800 Subject: [SciPy-user] egg dependency? In-Reply-To: <87d5kfdwef.fsf@peds-pc311.bsd.uchicago.edu> References: <87d5kfdwef.fsf@peds-pc311.bsd.uchicago.edu> Message-ID: <4390C00E.80807@gmail.com> John Hunter wrote: > I just tried to install the new scipy 0.6.1 on my ubuntu linux, and > got hit with > > peds-pc311:~/python/src/scipy_core-0.6.1> spsi > Running from scipy core source directory. > Traceback (most recent call last): > File "setup.py", line 38, in ? > setup_package() > File "setup.py", line 7, in setup_package > from scipy.distutils.core import setup > File "/home/jdhunter/python/src/scipy_core-0.6.1/scipy/distutils/core.py", line 42, in ? > from setuptools.command import bdist_egg, develop, easy_install, egg_info > ImportError: cannot import name bdist_egg > > If the goal is to make scipy core as easy to install as Numeric, is it > wise to require an egg dependency? In my understanding, egg still has > installation issues of it's own -- eg, it is not installed with the > python2.4 in Ubuntu Hoary, which is only 6-7 months old. > > My apologies if I am missing something obvious, because I haven't been > able to follow this list in detail in the last hectic month. There is a test further up in the file: try: from setuptools import setup as old_setup have_setuptools = 1 except ImportError: from distutils.core import setup as old_setup have_setuptools = 0 Apparently, it thinks you do have setuptools installed. -- Robert Kern robert.kern at gmail.com "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter From loredo at astro.cornell.edu Fri Dec 2 16:44:01 2005 From: loredo at astro.cornell.edu (Tom Loredo) Date: Fri, 2 Dec 2005 16:44:01 -0500 (EST) Subject: [SciPy-user] how to get matplotlib working with new scipy? Message-ID: <200512022144.jB2Li1J05350@laplace.astro.cornell.edu> Hi Sven, I'm just starting with scipy_core, so I can't address all your issues, but Travis just helped me regarding mpl compatibility, so I'll pass on what he told me in case he hasn't answered yet. The issue of mpl compatibility was recently addressed on the scipy and mpl developer lists. A patch was checked in that enables you to use mpl with just scipy (no Numeric or numarray needed). You can't just download the patches and patch mpl 0.85; the files that are patched have changed since the release. So you need to use the CVS version of mpl. Instructions for downloading it are at the CVS link on the mpl SourceForge page. Basically, just execute these two CVS commands: # cvs -d:pserver:anonymous at cvs.sourceforge.net:/cvsroot/matplotlib login # cvs -z3 -d:pserver:anonymous at cvs.sourceforge.net:/cvsroot/matplotlib co -P matplotlib This will create a "matplotlib" directory in your current directory with the current CVS check-in. Go in there and install mpl as usual. When you're done, you'll need to edit your matplotlibrc file, setting numerix to "scipy". Then the few examples I just tried all work. Cheers, Tom From strawman at astraw.com Fri Dec 2 16:47:01 2005 From: strawman at astraw.com (Andrew Straw) Date: Fri, 02 Dec 2005 13:47:01 -0800 Subject: [SciPy-user] egg dependency? In-Reply-To: <87d5kfdwef.fsf@peds-pc311.bsd.uchicago.edu> References: <87d5kfdwef.fsf@peds-pc311.bsd.uchicago.edu> Message-ID: <4390C0D5.7020605@astraw.com> I'd like to ask another question regarding eggs -- is there an incantation to use for pkg_resources.require() to request only a certain version of scipy? This would be great. Cheers! Andrew John Hunter wrote: >I just tried to install the new scipy 0.6.1 on my ubuntu linux, and >got hit with > >peds-pc311:~/python/src/scipy_core-0.6.1> spsi >Running from scipy core source directory. >Traceback (most recent call last): > File "setup.py", line 38, in ? > setup_package() > File "setup.py", line 7, in setup_package > from scipy.distutils.core import setup > File "/home/jdhunter/python/src/scipy_core-0.6.1/scipy/distutils/core.py", line 42, in ? > from setuptools.command import bdist_egg, develop, easy_install, egg_info >ImportError: cannot import name bdist_egg > >If the goal is to make scipy core as easy to install as Numeric, is it >wise to require an egg dependency? In my understanding, egg still has >installation issues of it's own -- eg, it is not installed with the >python2.4 in Ubuntu Hoary, which is only 6-7 months old. > >My apologies if I am missing something obvious, because I haven't been >able to follow this list in detail in the last hectic month. > >JDH > >_______________________________________________ >SciPy-user mailing list >SciPy-user at scipy.net >http://www.scipy.net/mailman/listinfo/scipy-user > > From jdhunter at ace.bsd.uchicago.edu Fri Dec 2 16:40:56 2005 From: jdhunter at ace.bsd.uchicago.edu (John Hunter) Date: Fri, 02 Dec 2005 15:40:56 -0600 Subject: [SciPy-user] egg dependency? In-Reply-To: <4390C00E.80807@gmail.com> (Robert Kern's message of "Fri, 02 Dec 2005 13:43:42 -0800") References: <87d5kfdwef.fsf@peds-pc311.bsd.uchicago.edu> <4390C00E.80807@gmail.com> Message-ID: <87vey76utz.fsf@peds-pc311.bsd.uchicago.edu> >>>>> "Robert" == Robert Kern writes: Robert> Apparently, it thinks you do have setuptools installed. I do -- but my setuptools doesn't come with egg. Go figure. You may want something along these lines (worked for me) try: from setuptools import setup as old_setup from setuptools.command import bdist_egg have_setuptools = 1 except ImportError: from distutils.core import setup as old_setup have_setuptools = 0 Thanks for the help, JDH From robert.kern at gmail.com Fri Dec 2 16:52:53 2005 From: robert.kern at gmail.com (Robert Kern) Date: Fri, 02 Dec 2005 13:52:53 -0800 Subject: [SciPy-user] egg dependency? In-Reply-To: <4390C0D5.7020605@astraw.com> References: <87d5kfdwef.fsf@peds-pc311.bsd.uchicago.edu> <4390C0D5.7020605@astraw.com> Message-ID: <4390C235.5020106@gmail.com> Andrew Straw wrote: > I'd like to ask another question regarding eggs -- is there an > incantation to use for pkg_resources.require() to request only a certain > version of scipy? This would be great. If you have the old scipy installed as an egg, and scipy_core and the new scipy installed as eggs, too, then to select the old version: pkg_resources.require('scipy-complete') To select the new version: pkg_resources.require('scipy-core') pkg_resources.require('SciPy') We really should fix the capitalization in the full scipy setup.py . -- Robert Kern robert.kern at gmail.com "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter From jdhunter at ace.bsd.uchicago.edu Fri Dec 2 16:48:13 2005 From: jdhunter at ace.bsd.uchicago.edu (John Hunter) Date: Fri, 02 Dec 2005 15:48:13 -0600 Subject: [SciPy-user] egg dependency? In-Reply-To: <4390C00E.80807@gmail.com> (Robert Kern's message of "Fri, 02 Dec 2005 13:43:42 -0800") References: <87d5kfdwef.fsf@peds-pc311.bsd.uchicago.edu> <4390C00E.80807@gmail.com> Message-ID: <87lkz36uhu.fsf@peds-pc311.bsd.uchicago.edu> Hey Robert -- Trying to workout the scipy core integration with mpl using the Daishi patch. I just installed scipy_core-0.6.1. Daishi does from scipy.fftpack import which raises with In [1]: from scipy.fftpack import * ------------------------------------------------------------ Traceback (most recent call last): File "", line 1, in ? ImportError: No module named fftpack but scipy.fftpack is a module In [6]: import scipy In [7]: scipy.fftpack Out[7]: In [8]: import scipy.fftpack ------------------------------------------------------------ Traceback (most recent call last): File "", line 1, in ? ImportError: No module named fftpack ?? Please advise. JDH From cookedm at physics.mcmaster.ca Fri Dec 2 16:59:01 2005 From: cookedm at physics.mcmaster.ca (David M. Cooke) Date: Fri, 02 Dec 2005 16:59:01 -0500 Subject: [SciPy-user] egg dependency? In-Reply-To: <87d5kfdwef.fsf@peds-pc311.bsd.uchicago.edu> (John Hunter's message of "Fri, 02 Dec 2005 15:25:12 -0600") References: <87d5kfdwef.fsf@peds-pc311.bsd.uchicago.edu> Message-ID: John Hunter writes: > I just tried to install the new scipy 0.6.1 on my ubuntu linux, and > got hit with > > peds-pc311:~/python/src/scipy_core-0.6.1> spsi > Running from scipy core source directory. > Traceback (most recent call last): > File "setup.py", line 38, in ? > setup_package() > File "setup.py", line 7, in setup_package > from scipy.distutils.core import setup > File "/home/jdhunter/python/src/scipy_core-0.6.1/scipy/distutils/core.py", line 42, in ? > from setuptools.command import bdist_egg, develop, easy_install, egg_info > ImportError: cannot import name bdist_egg > > If the goal is to make scipy core as easy to install as Numeric, is it > wise to require an egg dependency? In my understanding, egg still has > installation issues of it's own -- eg, it is not installed with the > python2.4 in Ubuntu Hoary, which is only 6-7 months old. I snuck that in at some point, sorry. As Robert pointed, out there is a check at the top for setuptools. I think you have an old setuptools installed (bdist_egg was added in March: pre-0.3a2 at least!). I've committed a fix to svn that checks if bdist_egg can be found also. Oh, and the latest Numeric does the same thing (haven't fixed that yet). BTW, this doesn't mean that scipy is eggable yet :-) I think egging scipy.core is fine, but you can't add scipy full. I've got to figure out how to use setuptools' namespace feature, which is complicated by the fact that the scipy.__init__ included with scipy.core is (very much) not empty. -- |>|\/|< /--------------------------------------------------------------------------\ |David M. Cooke http://arbutus.physics.mcmaster.ca/dmc/ |cookedm at physics.mcmaster.ca From oliphant.travis at ieee.org Fri Dec 2 17:10:56 2005 From: oliphant.travis at ieee.org (Travis Oliphant) Date: Fri, 02 Dec 2005 15:10:56 -0700 Subject: [SciPy-user] egg dependency? In-Reply-To: <87lkz36uhu.fsf@peds-pc311.bsd.uchicago.edu> References: <87d5kfdwef.fsf@peds-pc311.bsd.uchicago.edu> <4390C00E.80807@gmail.com> <87lkz36uhu.fsf@peds-pc311.bsd.uchicago.edu> Message-ID: <4390C670.6070505@ieee.org> John Hunter wrote: >Hey Robert -- > >Trying to workout the scipy core integration with mpl using the Daishi >patch. I just installed scipy_core-0.6.1. Daishi does > >from scipy.fftpack import > > Apparently our magic is not working completely. The idea is to have something that works the same for both basic scipy and full scipy if and when it gets installed. scipy.fftpack is just an alias as you can see later to where the real functions are defined. I guess we actually need to install a simple fftpack sub-package that gives the correct behavior and do this for linalg as well. For now, you can't import all the variables like this. Access them underneath the scipy.fftpack namespace. But, some of the simpler things like fft are already under scipy. So from scipy import fft should work. -Travis From robert.kern at gmail.com Fri Dec 2 17:15:23 2005 From: robert.kern at gmail.com (Robert Kern) Date: Fri, 02 Dec 2005 14:15:23 -0800 Subject: [SciPy-user] egg dependency? In-Reply-To: References: <87d5kfdwef.fsf@peds-pc311.bsd.uchicago.edu> Message-ID: <4390C77B.2080000@gmail.com> David M. Cooke wrote: > BTW, this doesn't mean that scipy is eggable yet :-) I think egging > scipy.core is fine, but you can't add scipy full. I've got to figure > out how to use setuptools' namespace feature, which is complicated by > the fact that the scipy.__init__ included with scipy.core is (very > much) not empty. Actually, it is eggable. You need to add something like this to both __init__.py scripts. try: __import__('pkg_resources').declare_namespace(__name__) except ImportError: pass Note: the try: except: is only there for source compatibility with non-egg installs. -- Robert Kern robert.kern at gmail.com "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter From oliphant.travis at ieee.org Fri Dec 2 16:36:49 2005 From: oliphant.travis at ieee.org (Travis Oliphant) Date: Fri, 02 Dec 2005 14:36:49 -0700 Subject: [SciPy-user] egg dependency? In-Reply-To: <87d5kfdwef.fsf@peds-pc311.bsd.uchicago.edu> References: <87d5kfdwef.fsf@peds-pc311.bsd.uchicago.edu> Message-ID: <4390BE71.1080608@ieee.org> John Hunter wrote: >I just tried to install the new scipy 0.6.1 on my ubuntu linux, and >got hit with > >peds-pc311:~/python/src/scipy_core-0.6.1> spsi >Running from scipy core source directory. >Traceback (most recent call last): > File "setup.py", line 38, in ? > setup_package() > File "setup.py", line 7, in setup_package > from scipy.distutils.core import setup > File "/home/jdhunter/python/src/scipy_core-0.6.1/scipy/distutils/core.py", line 42, in ? > from setuptools.command import bdist_egg, develop, easy_install, egg_info >ImportError: cannot import name bdist_egg > >If the goal is to make scipy core as easy to install as Numeric, is it >wise to require an egg dependency? In my understanding, egg still has >installation issues of it's own -- eg, it is not installed with the >python2.4 in Ubuntu Hoary, which is only 6-7 months old. > > > This is a mistake. My understanding is that setuptools is "supported by not required." Any setuptools dependency should be handled more gracefully. I suspect the issue is that you have setuptools installed but an older version then expected, perhaps? I'm not sure, I didn't add this code. See if you can comment-out that line and continue. -Travis From mcantor at stanford.edu Fri Dec 2 17:29:01 2005 From: mcantor at stanford.edu (mike cantor) Date: Fri, 02 Dec 2005 14:29:01 -0800 Subject: [SciPy-user] passings arrays into C extension In-Reply-To: <4390B978.6080903@ieee.org> References: <438BD81D.3080503@ieee.org> <6.0.1.1.2.20051202130016.01f02ce8@mcantor.pobox.stanford.edu> <4390B978.6080903@ieee.org> Message-ID: <6.0.1.1.2.20051202141409.01f3f800@mcantor.pobox.stanford.edu> Thanks for the response newarr = PyArray_From_OF(array, CARRAY_FLAGS); dptr = (int *)PyArray_DATA(newarr); looks like it would do the trick. Is there a reason to use PyArray_From_OF vs PyArray_ContiguousFromObject? Thanks,-mike dptr = (int *)PyArray_DATA(newarr); At 01:15 PM 12/2/2005, you wrote: >mike cantor wrote: > > >Hi, > > > >What is the blessed way to pass SciPy arrays into C extension code (that > >is, to convert Array PthonObjs into a C int* or other array type). > > > > >What would you like the equivalent of? > >You can access the data attribute (which is the pointer to raw memory as) > >dptr = ( *)PyArray_DATA(array) > >You should be aware of PyArray_FLAGS(array) however because the data >might be unaligned, not in machine-byte order, or not writeable, or not >contiguous in memory. If you need a contiguous chunk of "behaved memory" >you can use: > >/* This doesn't make sure you have an integer array */ > >newarr = PyArray_From_OF(array, CARRAY_FLAGS); > >dptr = (int *)PyArray_DATA(newarr); > >/* code that uses dptr */ > >Py_DECREF(newarr); > > >If you need the "misbehaved" memory to receive the updates after the >copy is made use >CARRAY_FLAGS | UPDATEIFCOPY in the PyArray_From_OF(...) macro then when >newarr is DECREF'd it will update the contents of array. > > >If you are talking about passing something to the ctypes module, then > >int(array.__array_data__[0],0) > >will give you an integer that is a pointer to your data. > >-Travis > >_______________________________________________ >SciPy-user mailing list >SciPy-user at scipy.net >http://www.scipy.net/mailman/listinfo/scipy-user From pearu at scipy.org Fri Dec 2 16:31:09 2005 From: pearu at scipy.org (Pearu Peterson) Date: Fri, 2 Dec 2005 15:31:09 -0600 (CST) Subject: [SciPy-user] egg dependency? In-Reply-To: <4390BE71.1080608@ieee.org> References: <87d5kfdwef.fsf@peds-pc311.bsd.uchicago.edu> <4390BE71.1080608@ieee.org> Message-ID: On Fri, 2 Dec 2005, Travis Oliphant wrote: > John Hunter wrote: > >> I just tried to install the new scipy 0.6.1 on my ubuntu linux, and >> got hit with >> >> peds-pc311:~/python/src/scipy_core-0.6.1> spsi >> Running from scipy core source directory. >> Traceback (most recent call last): >> File "setup.py", line 38, in ? >> setup_package() >> File "setup.py", line 7, in setup_package >> from scipy.distutils.core import setup >> File "/home/jdhunter/python/src/scipy_core-0.6.1/scipy/distutils/core.py", line 42, in ? >> from setuptools.command import bdist_egg, develop, easy_install, egg_info >> ImportError: cannot import name bdist_egg >> >> If the goal is to make scipy core as easy to install as Numeric, is it >> wise to require an egg dependency? In my understanding, egg still has >> installation issues of it's own -- eg, it is not installed with the >> python2.4 in Ubuntu Hoary, which is only 6-7 months old. >> > This is a mistake. My understanding is that setuptools is "supported by > not required." Any setuptools dependency should be handled more > gracefully. I suspect the issue is that you have setuptools installed > but an older version then expected, perhaps? > > I'm not sure, I didn't add this code. See if you can comment-out that > line and continue. Without looking into details much, this demonstrates well the evilness of using `try: .. except: ..` blocks when checking the availability of packages. Sure, it's very convinient but there are always (or will be) cases where this sugar fails (or will so). Ahh, I find repeating myself again.. Pearu From cookedm at physics.mcmaster.ca Fri Dec 2 17:53:50 2005 From: cookedm at physics.mcmaster.ca (David M. Cooke) Date: Fri, 02 Dec 2005 17:53:50 -0500 Subject: [SciPy-user] egg dependency? In-Reply-To: (Pearu Peterson's message of "Fri, 2 Dec 2005 15:31:09 -0600 (CST)") References: <87d5kfdwef.fsf@peds-pc311.bsd.uchicago.edu> <4390BE71.1080608@ieee.org> Message-ID: Pearu Peterson writes: > On Fri, 2 Dec 2005, Travis Oliphant wrote: > >> John Hunter wrote: >> >>> I just tried to install the new scipy 0.6.1 on my ubuntu linux, and >>> got hit with >>> >>> peds-pc311:~/python/src/scipy_core-0.6.1> spsi >>> Running from scipy core source directory. >>> Traceback (most recent call last): >>> File "setup.py", line 38, in ? >>> setup_package() >>> File "setup.py", line 7, in setup_package >>> from scipy.distutils.core import setup >>> File "/home/jdhunter/python/src/scipy_core-0.6.1/scipy/distutils/core.py", line 42, in ? >>> from setuptools.command import bdist_egg, develop, easy_install, egg_info >>> ImportError: cannot import name bdist_egg >>> >>> If the goal is to make scipy core as easy to install as Numeric, is it >>> wise to require an egg dependency? In my understanding, egg still has >>> installation issues of it's own -- eg, it is not installed with the >>> python2.4 in Ubuntu Hoary, which is only 6-7 months old. >>> >> This is a mistake. My understanding is that setuptools is "supported by >> not required." Any setuptools dependency should be handled more >> gracefully. I suspect the issue is that you have setuptools installed >> but an older version then expected, perhaps? >> >> I'm not sure, I didn't add this code. See if you can comment-out that >> line and continue. > > Without looking into details much, this demonstrates well the evilness of > using `try: .. except: ..` blocks when checking the availability of > packages. Sure, it's very convinient but there are always (or will be) > cases where this sugar fails (or will so). Ahh, I find repeating myself again.. Which, coincidentally, is one of the problems that setuptools tries to solve :-) -- |>|\/|< /--------------------------------------------------------------------------\ |David M. Cooke http://arbutus.physics.mcmaster.ca/dmc/ |cookedm at physics.mcmaster.ca From aisaac at american.edu Fri Dec 2 18:00:18 2005 From: aisaac at american.edu (Alan G Isaac) Date: Fri, 2 Dec 2005 18:00:18 -0500 Subject: [SciPy-user] egg dependency? In-Reply-To: References: <87d5kfdwef.fsf@peds-pc311.bsd.uchicago.edu><4390BE71.1080608@ieee.org> Message-ID: On Fri, 2 Dec 2005, Pearu Peterson apparently wrote: > Without looking into details much, this demonstrates well > the evilness of using `try: .. except: ..` blocks when > checking the availability of packages. Sure, it's very > convinient but there are always (or will be) cases where > this sugar fails (or will so). What is the preferred approach? Thanks, Alan Isaac From oliphant.travis at ieee.org Fri Dec 2 18:19:33 2005 From: oliphant.travis at ieee.org (Travis Oliphant) Date: Fri, 02 Dec 2005 16:19:33 -0700 Subject: [SciPy-user] passings arrays into C extension In-Reply-To: <6.0.1.1.2.20051202141409.01f3f800@mcantor.pobox.stanford.edu> References: <438BD81D.3080503@ieee.org> <6.0.1.1.2.20051202130016.01f02ce8@mcantor.pobox.stanford.edu> <4390B978.6080903@ieee.org> <6.0.1.1.2.20051202141409.01f3f800@mcantor.pobox.stanford.edu> Message-ID: <4390D685.400@ieee.org> mike cantor wrote: >Thanks for the response > >newarr = PyArray_From_OF(array, CARRAY_FLAGS); >dptr = (int *)PyArray_DATA(newarr); > >looks like it would do the trick. Is there a reason to use PyArray_From_OF >vs PyArray_ContiguousFromObject? > > PyArray_ContiguousFromObject is a wrapper around the call I just gave you. So, I don't see any reason to use it as it doesn't support arbitrary type arrays. But, if you don't need those, then it would also work (at the price of one extra function call). -Travis From pearu at scipy.org Fri Dec 2 17:26:34 2005 From: pearu at scipy.org (Pearu Peterson) Date: Fri, 2 Dec 2005 16:26:34 -0600 (CST) Subject: [SciPy-user] egg dependency? In-Reply-To: References: <87d5kfdwef.fsf@peds-pc311.bsd.uchicago.edu><4390BE71.1080608@ieee.org> Message-ID: On Fri, 2 Dec 2005, Alan G Isaac wrote: > On Fri, 2 Dec 2005, Pearu Peterson apparently wrote: >> Without looking into details much, this demonstrates well >> the evilness of using `try: .. except: ..` blocks when >> checking the availability of packages. Sure, it's very >> convinient but there are always (or will be) cases where >> this sugar fails (or will so). > > What is the preferred approach? That's a good question and the answer will depend on a particular case. However, there are few suggestions that will minimize the risk of using try-except blocks: - the contents of try block should be minimal, even if then overall code will be more verbose. - except block should be as explicit as possible about what exceptions are expected, it should raise exception in all other cases. - and finally, don't use it when it is avoidable, it often is. In scipy.distutils.core case I see the following problems. First, the code try: from setuptools import setup as old_setup # very old setuptools don't have this from setuptools.command import bdist_egg have_setuptools = 1 except ImportError: from distutils.core import setup as old_setup have_setuptools = 0 has a pitfall in the case when `from setuptools import setup as old_setup` succeeds but `from setuptools.command import bdist_egg` fails -- old_setup may be polluted. So, I would write (not tested code follows) have_setuptools = False try: import setuptools try: import setuptools.command.bdist_egg have_setuptools = True except ImportError, msg: print 'setuptools too old:',msg,'Ignoring.' except ImportError, msg: print 'setuptools not available:',msg,'Ignoring.' if have_setuptools: from setuptools import setup as old_setup from setuptools.command import bdist_egg ... else: from distutils.core import setup as old_setup ... Second, it is not clear why the original code failed. It shouldn't have when reading the code. So I would investigate for possible reasons, and the code above might need some adjustments. Pearu From fonnesbeck at gmail.com Fri Dec 2 20:17:27 2005 From: fonnesbeck at gmail.com (Chris Fonnesbeck) Date: Fri, 2 Dec 2005 20:17:27 -0500 Subject: [SciPy-user] segfault in scipy.random.standard_normal Message-ID: <723eb6930512021717p31685f9cuc6a09777122f5df3@mail.gmail.com> Something is squirrely with the size argument in standard_normal: In [5]: random.standard_normal() Out[5]: 0.31727273308342824 In [6]: random.standard_normal(2) Segmentation fault I'm using a recent svn build from scipy_core. C. -- Chris Fonnesbeck Atlanta, GA From robert.kern at gmail.com Fri Dec 2 20:37:16 2005 From: robert.kern at gmail.com (Robert Kern) Date: Fri, 02 Dec 2005 17:37:16 -0800 Subject: [SciPy-user] segfault in scipy.random.standard_normal In-Reply-To: <723eb6930512021717p31685f9cuc6a09777122f5df3@mail.gmail.com> References: <723eb6930512021717p31685f9cuc6a09777122f5df3@mail.gmail.com> Message-ID: <4390F6CC.8080107@gmail.com> Chris Fonnesbeck wrote: > Something is squirrely with the size argument in standard_normal: > > In [5]: random.standard_normal() > Out[5]: 0.31727273308342824 > > In [6]: random.standard_normal(2) > Segmentation fault > > I'm using a recent svn build from scipy_core. Try cleaning out all of the generated files and rebuilding. I do not see this problem with the latest checkout (2 minutes ago). Nor do I see the similar (probably identical) problem that Andrew Jaffe pointed out on scipy-dev. >>> from scipy import random >>> random.standard_normal() -0.27409875254644911 >>> random.standard_normal(1) array([-1.56177532]) >>> random.standard_normal(2) array([-0.31837658, -0.97301873]) >>> random.standard_normal(3) array([-0.8761265 , -0.81597842, 0.23456039]) >>> random.standard_normal((3,4)) array([[-0.25311012, 0.64460605, -1.54209649, 1.2043136 ], [-0.04572192, 1.78949021, -1.05508314, -1.38847567], [ 0.52066447, 0.77373815, -0.00355181, -0.70754882]]) -- Robert Kern robert.kern at gmail.com "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter From aisaac at american.edu Fri Dec 2 20:59:27 2005 From: aisaac at american.edu (Alan G Isaac) Date: Fri, 2 Dec 2005 20:59:27 -0500 Subject: [SciPy-user] egg dependency? In-Reply-To: References: <87d5kfdwef.fsf@peds-pc311.bsd.uchicago.edu><4390BE71.1080608@ieee.org> Message-ID: >> On Fri, 2 Dec 2005, Pearu Peterson apparently wrote: >>> Without looking into details much, this demonstrates well >>> the evilness of using `try: .. except: ..` blocks when >>> checking the availability of packages. Sure, it's very >>> convinient but there are always (or will be) cases where >>> this sugar fails (or will so). > On Fri, 2 Dec 2005, Alan G Isaac wrote: >> What is the preferred approach? On Fri, 2 Dec 2005, Pearu Peterson apparently wrote: > That's a good question and the answer will depend on a particular case. > However, there are few suggestions that will minimize the risk of > using try-except blocks: > - the contents of try block should be minimal, even if then overall code > will be more verbose. > - except block should be as explicit as possible about what > exceptions are expected, it should raise exception in all other cases. > - and finally, don't use it when it is avoidable, it often is. > In scipy.distutils.core case I see the following problems. First, the code > try: > from setuptools import setup as old_setup > # very old setuptools don't have this > from setuptools.command import bdist_egg > have_setuptools = 1 > except ImportError: > from distutils.core import setup as old_setup > have_setuptools = 0 > has a pitfall in the case when `from setuptools import setup as > old_setup` succeeds but `from setuptools.command import bdist_egg` fails > -- old_setup may be polluted. > So, I would write (not tested code follows) > have_setuptools = False > try: > import setuptools > try: > import setuptools.command.bdist_egg > have_setuptools = True > except ImportError, msg: > print 'setuptools too old:',msg,'Ignoring.' > except ImportError, msg: > print 'setuptools not available:',msg,'Ignoring.' > if have_setuptools: > from setuptools import setup as old_setup > from setuptools.command import bdist_egg > ... > else: > from distutils.core import setup as old_setup > ... Thanks for this useful elaboration! Alan Isaac From robert.kern at gmail.com Fri Dec 2 21:15:48 2005 From: robert.kern at gmail.com (Robert Kern) Date: Fri, 02 Dec 2005 18:15:48 -0800 Subject: [SciPy-user] egg dependency? In-Reply-To: <87vey76utz.fsf@peds-pc311.bsd.uchicago.edu> References: <87d5kfdwef.fsf@peds-pc311.bsd.uchicago.edu> <4390C00E.80807@gmail.com> <87vey76utz.fsf@peds-pc311.bsd.uchicago.edu> Message-ID: <4390FFD4.2080900@gmail.com> John Hunter wrote: >>>>>>"Robert" == Robert Kern writes: > > Robert> Apparently, it thinks you do have setuptools installed. > > I do -- but my setuptools doesn't come with egg. Go figure. > > You may want something along these lines (worked for me) > > try: > from setuptools import setup as old_setup > from setuptools.command import bdist_egg > have_setuptools = 1 > except ImportError: > from distutils.core import setup as old_setup > have_setuptools = 0 Actually, we can drop the "from setuptools import setup as old_setup" line entirely since setuptools.setup is distutils.core.setup . Unlike scipy.distutils, setuptools doesn't change that function. I wish we could avoid it, too. -- Robert Kern robert.kern at gmail.com "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter From cookedm at physics.mcmaster.ca Sat Dec 3 00:30:44 2005 From: cookedm at physics.mcmaster.ca (David M. Cooke) Date: Sat, 03 Dec 2005 00:30:44 -0500 Subject: [SciPy-user] egg dependency? In-Reply-To: (Pearu Peterson's message of "Fri, 2 Dec 2005 16:26:34 -0600 (CST)") References: <87d5kfdwef.fsf@peds-pc311.bsd.uchicago.edu> <4390BE71.1080608@ieee.org> Message-ID: Pearu Peterson writes: > On Fri, 2 Dec 2005, Alan G Isaac wrote: > >> On Fri, 2 Dec 2005, Pearu Peterson apparently wrote: >>> Without looking into details much, this demonstrates well >>> the evilness of using `try: .. except: ..` blocks when >>> checking the availability of packages. Sure, it's very >>> convinient but there are always (or will be) cases where >>> this sugar fails (or will so). >> >> What is the preferred approach? > > That's a good question and the answer will depend on a particular case. > However, there are few suggestions that will minimize the risk of > using try-except blocks: > - the contents of try block should be minimal, even if then overall code > will be more verbose. > - except block should be as explicit as possible about what > exceptions are expected, it should raise exception in all other cases. > - and finally, don't use it when it is avoidable, it often is. > > In scipy.distutils.core case I see the following problems. First, the code > > try: > from setuptools import setup as old_setup > # very old setuptools don't have this > from setuptools.command import bdist_egg > have_setuptools = 1 > except ImportError: > from distutils.core import setup as old_setup > have_setuptools = 0 > > has a pitfall in the case when `from setuptools import setup as > old_setup` succeeds but `from setuptools.command import bdist_egg` fails > -- old_setup may be polluted. Assuming that if the imports fail that they fail with ImportError, the result is the same: have_setuptools is set to 0, and distutils.core.setup is imported as old_setup. How would old_setup be polluted? It's overwritten. Now, it *could* be possible that importing has side effects. This is where setuptools comes in handy, with its dependency checking that doesn't rely on imports, but on metadata in eggs. > So, I would write (not tested code follows) > > have_setuptools = False > try: > import setuptools > try: > import setuptools.command.bdist_egg > have_setuptools = True > except ImportError, msg: > print 'setuptools too old:',msg,'Ignoring.' > except ImportError, msg: > print 'setuptools not available:',msg,'Ignoring.' > > if have_setuptools: > from setuptools import setup as old_setup > from setuptools.command import bdist_egg > ... > else: > from distutils.core import setup as old_setup > ... Except for extra error messages, this is the same thing. > Second, it is not clear why the original code failed. It shouldn't have > when reading the code. So I would investigate for possible reasons, > and the code above might need some adjustments. Because the original code (which John Hunter was running) didn't have the bdist_egg import; I added that this afternoon. -- |>|\/|< /--------------------------------------------------------------------------\ |David M. Cooke http://arbutus.physics.mcmaster.ca/dmc/ |cookedm at physics.mcmaster.ca From pearu at scipy.org Sat Dec 3 02:49:44 2005 From: pearu at scipy.org (Pearu Peterson) Date: Sat, 3 Dec 2005 01:49:44 -0600 (CST) Subject: [SciPy-user] egg dependency? In-Reply-To: <4390FFD4.2080900@gmail.com> References: <87d5kfdwef.fsf@peds-pc311.bsd.uchicago.edu> <4390C00E.80807@gmail.com><4390FFD4.2080900@gmail.com> Message-ID: On Fri, 2 Dec 2005, Robert Kern wrote: > Actually, we can drop the "from setuptools import setup as old_setup" > line entirely since setuptools.setup is distutils.core.setup . Unlike > scipy.distutils, setuptools doesn't change that function. I wish we > could avoid it, too. I think we can. At least the parts that follow `updating cmdclass with scipy_cmdclass` part, can be moved to the corresponding Configuration methods. Pearu From gerard.vermeulen at grenoble.cnrs.fr Sat Dec 3 07:14:12 2005 From: gerard.vermeulen at grenoble.cnrs.fr (Gerard Vermeulen) Date: Sat, 3 Dec 2005 13:14:12 +0100 Subject: [SciPy-user] some benchmark data for numarray, Numeric and scipy-newcore Message-ID: <20051203131412.74250ba7.gerard.vermeulen@grenoble.cnrs.fr> I have benchmarked some array manipulations using the default Numeric and numarray on my Mandrake-10.2 and a recent snapshot of the new scipy core. I used the following script which takes two arguments: a string indicating which Numerical extension to use and an integer setting the size of the arrays. -- start script -- #!/usr/bin/env python import sys import time def klein(nu, nv, a): """Returns the figure-8 form of the Klein bottle u in [0, 2pi), v in [0, 2pi), and a > 2 http://mathworld.wolfram.com/KleinBottle.html """ assert(nu > 2) assert(nv > 2) assert(a > 2) ticks = [time.time()] # label i = arange(nu*nv) # 1 ticks.append(time.time()) u = i % nu # 2 ticks.append(time.time()) u %= nu-1 # 3 ticks.append(time.time()) u = 2*pi*u/(nu-1) # 4 ticks.append(time.time()) v = i / nu # 5 ticks.append(time.time()) v %= nv-1 # 6 ticks.append(time.time()) v = 2*pi*v/(nu-1) # 7 ticks.append(time.time()) xyzs = zeros((nu*nv, 3), Float) # 8 ticks.append(time.time()) xyzs[:,0] = (a+cos(u/2)*sin(v)-sin(u/2)*sin(2*v))*cos(u) # 9 ticks.append(time.time()) xyzs[:,1] = (a+cos(u/2)*sin(v)-sin(u/2)*sin(2*v))*sin(u) # 10 ticks.append(time.time()) xyzs[:,2] = sin(u/2)*sin(v)+cos(u/2)*sin(2*v) # 11 ticks.append(time.time()) print 'label time (s)' for i in range(1, len(ticks)): print '%5d %s' %(i, ticks[i] - ticks[i-1]) print 'TOTAL %s' % (ticks[-1] - ticks[0]) return xyzs # klein() def usage(): print 'Usage: python numpy size' print 'where numpy must be Numeric, numarray, or scipy' print 'and size an integer in [3, 13)' sys.exit(1) # usage() if __name__ == '__main__': if len(sys.argv) != 3: usage() if sys.argv[1] == 'Numeric': from Numeric import * import Numeric extension = 'Numeric-%s' % Numeric.__version__ elif sys.argv[1] == 'numarray': from numarray import * import numarray extension = 'numarray-%s' % numarray.__version__ elif sys.argv[1] == 'scipy': from scipy import * extension = 'scipy-%s' % core_version.version else: usage() # on my system: # numarray is slowest when size = 6 # numarray is fastest when size = 7 # memory errors occur when size = 13 try: size = int(sys.argv[2]) except: usage() if size < 3 or size >= 13: usage() print '%s: benchmark size = %s' % (extension, size) klein(2**size, 2**size, pi) # Local Variables: *** # mode: python *** # End: *** -- end script -- The results follow below, where the label column indicates the corresponding statement in the klein() function above: [packer at titan JUNK]$ ./bench.py Numeric 12 Numeric-23.1: benchmark size = 12 label time (s) 1 0.435407161713 2 0.267067909241 3 0.192448139191 4 1.01883888245 5 0.273994922638 6 0.202347040176 7 1.01867508888 8 0.650615930557 9 10.3847429752 10 10.4006090164 11 8.59523797035 TOTAL 33.4399850368 [packer at titan JUNK]$ ./bench.py scipy 12 Importing test to scipy Importing base to scipy Importing basic to scipy scipy-0.7.1.1526: benchmark size = 12 label time (s) 1 0.406187057495 2 0.515972852707 3 0.45333313942 4 2.09451985359 5 0.277112007141 6 0.50949215889 7 2.08596587181 8 0.456773996353 9 8.81630802155 10 8.83214116096 11 7.41638493538 TOTAL 31.8641910553 [packer at titan JUNK]$ ./bench.py numarray 12 numarray-1.2.3: benchmark size = 12 label time (s) 1 0.0770111083984 2 0.245344877243 3 0.186748027802 4 0.553218126297 5 0.245689868927 6 0.186288118362 7 0.626587867737 8 0.456372022629 9 7.61383700371 10 8.03238511086 11 6.3676469326 TOTAL 24.5911290646 [packer at titan JUNK]$ Conclusion: - the overal performance of numarray is 23 % better than scipy-newcore and 27 % better than Numeric. - numarray is consistently faster than the other packages. - scipy newcore is on average somewhat faster than Numeric3, but some operations are really slow in comparison with the other packages. In partical the statements labeled 2, 3, 4, 6 and 7 take 2 times more time using scipy-newcore than using Numeric. Gerard From elcorto at gmx.net Sat Dec 3 07:38:18 2005 From: elcorto at gmx.net (Steve Schmerler) Date: Sat, 03 Dec 2005 13:38:18 +0100 Subject: [SciPy-user] svn commands In-Reply-To: <438E92EB.9030106@att.net> References: <438DCA77.8070303@att.net> <438E152B.6050804@csun.edu> <438E92EB.9030106@att.net> Message-ID: <439191BA.5080403@gmx.net> Hi I haven't been following the list for a while. I'd like to try the current versions of scipy_core and scipy from svn. I found 2 svn commands on the list: core: a) svn co http://svn.scipy.org/svn/scipy_core/branches/newcore newcore b) svn co http://svn.scipy.org/svn/scipy_core/trunk core scipy: b) svn co http://svn.scipy.org/svn/scipy/trunk scipy What are the right commands? cheers, steve -- Should array indices start at 0 or 1? My compromise of 0.5 was rejected without, I thought, proper consideration. -- Stan Kelly-Bootle From pearu at scipy.org Sat Dec 3 06:42:43 2005 From: pearu at scipy.org (Pearu Peterson) Date: Sat, 3 Dec 2005 05:42:43 -0600 (CST) Subject: [SciPy-user] svn commands In-Reply-To: <439191BA.5080403@gmx.net> References: <438DCA77.8070303@att.net> <438E152B.6050804@csun.edu> <438E92EB.9030106@att.net> <439191BA.5080403@gmx.net> Message-ID: On Sat, 3 Dec 2005, Steve Schmerler wrote: > Hi > > I haven't been following the list for a while. I'd like to try the > current versions of scipy_core and scipy from svn. > I found 2 svn commands on the list: > > core: > a) svn co http://svn.scipy.org/svn/scipy_core/branches/newcore newcore > b) svn co http://svn.scipy.org/svn/scipy_core/trunk core > > scipy: > b) svn co http://svn.scipy.org/svn/scipy/trunk scipy > > What are the right commands? svn co http://svn.scipy.org/svn/scipy_core/trunk core cd core rm -rf build python setup.py install svn co http://svn.scipy.org/svn/scipy/trunk scipy cd ../scipy rm -rf build python setup.py install Removing old scipy installation tree before executing the above commands is recommended. Pearu From elcorto at gmx.net Sat Dec 3 12:49:53 2005 From: elcorto at gmx.net (Steve Schmerler) Date: Sat, 03 Dec 2005 18:49:53 +0100 Subject: [SciPy-user] svn commands In-Reply-To: References: <438DCA77.8070303@att.net> <438E152B.6050804@csun.edu> <438E92EB.9030106@att.net> <439191BA.5080403@gmx.net> Message-ID: <4391DAC1.1020706@gmx.net> Pearu Peterson wrote: > > On Sat, 3 Dec 2005, Steve Schmerler wrote: > > >>Hi >> >>I haven't been following the list for a while. I'd like to try the >>current versions of scipy_core and scipy from svn. >>I found 2 svn commands on the list: >> >>core: >>a) svn co http://svn.scipy.org/svn/scipy_core/branches/newcore newcore >>b) svn co http://svn.scipy.org/svn/scipy_core/trunk core >> >>scipy: >>b) svn co http://svn.scipy.org/svn/scipy/trunk scipy >> >>What are the right commands? > > > svn co http://svn.scipy.org/svn/scipy_core/trunk core > cd core > rm -rf build > python setup.py install > > svn co http://svn.scipy.org/svn/scipy/trunk scipy > cd ../scipy > rm -rf build > python setup.py install > > Removing old scipy installation tree before executing the above commands > is recommended. > > Pearu > > _______________________________________________ > SciPy-user mailing list > SciPy-user at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-user > > Thanx. I got the scipy and core sources, installed the prerequisites (debian packages) mentioned in scipy/INSTALL.txt (ATLAS, ...). When I run scipy.test() I get a floating point exception: ######################################################################################################################### elcorto at ramrod:~/Install/Python/SciPy/scipy$ ipython Python 2.3.5 (#2, Sep 4 2005, 22:01:42) Type "copyright", "credits" or "license" for more information. IPython 0.6.13 -- An enhanced Interactive Python. ? -> Introduction to IPython's features. %magic -> Information about IPython's 'magic' % functions. help -> Python's own help system. object? -> Details about 'object'. ?object also works, ?? prints more. In [1]: In [1]: In [1]: import scipy Importing test to scipy Importing base to scipy Importing basic to scipy Importing io to scipy Importing fftpack to scipy Importing special to scipy Importing cluster to scipy Importing sparse to scipy Importing utils to scipy Importing interpolate to scipy Importing lib to scipy Importing signal to scipy Importing integrate to scipy Importing optimize to scipy Importing linalg to scipy Importing stats to scipy In [2]: scipy.test() Found 4 tests for scipy.io.array_import Found 128 tests for scipy.linalg.fblas Found 2 tests for scipy.base.umath Found 10 tests for scipy.integrate.quadpack Found 92 tests for scipy.stats.stats Found 9 tests for scipy.base.twodim_base Found 36 tests for scipy.linalg.decomp Found 49 tests for scipy.sparse.sparse Found 20 tests for scipy.fftpack.pseudo_diffs Found 6 tests for scipy.optimize.optimize Found 5 tests for scipy.interpolate.fitpack Found 4 tests for scipy.base.index_tricks Found 70 tests for scipy.stats.distributions Found 12 tests for scipy.io.mmio Found 10 tests for scipy.stats.morestats Found 4 tests for scipy.linalg.lapack Found 24 tests for scipy.base.function_base Found 18 tests for scipy.fftpack.basic Found 1 tests for scipy.optimize.zeros Found 92 tests for scipy.stats Found 4 tests for scipy.fftpack.helper Found 6 tests for scipy.base.matrix Found 42 tests for scipy.lib.lapack Found 42 tests for scipy.base.type_check Found 339 tests for scipy.special.basic Found 128 tests for scipy.lib.blas.fblas Found 7 tests for scipy.linalg.matfuncs Found 41 tests for scipy.linalg.basic Found 1 tests for scipy.optimize.cobyla Found 14 tests for scipy.lib.blas Found 1 tests for scipy.integrate Found 14 tests for scipy.linalg.blas Found 17 tests for scipy.base.ma Found 3 tests for scipy.base.getlimits Found 6 tests for scipy.optimize Found 49 tests for scipy.sparse Found 44 tests for scipy.base.shape_base Found 3 tests for scipy.basic.helper Found 3 tests for scipy.signal.signaltools Found 0 tests for __main__ Don't worry about a warning regarding the number of bytes read. Warning: 1000000 bytes requested, 20 bytes read. .......caxpy:n=4 ..caxpy:n=3 ....ccopy:n=4 ..ccopy:n=3 .............cscal:n=4 ....cswap:n=4 ..cswap:n=3 .....daxpy:n=4 ..daxpy:n=3 ....dcopy:n=4 ..dcopy:n=3 .............dscal:n=4 ....dswap:n=4 ..dswap:n=3 .....saxpy:n=4 ..saxpy:n=3 ....scopy:n=4 ..scopy:n=3 .............sscal:n=4 ....sswap:n=4 ..sswap:n=3 .....zaxpy:n=4 ..zaxpy:n=3 ....zcopy:n=4 ..zcopy:n=3 .............zscal:n=4 ....zswap:n=4 ..zswap:n=3 .............................................................................. ............................................................................. ...................................................................... ../usr/lib/python2.3/site-packages/scipy/interpolate/fitpack2.py:410: UserWarning: The coefficients of the spline returned have been computed as the minimal norm least-squares solution of a (numerically) rank deficient system (deficiency=7). If deficiency is large, the results may be inaccurate. Deficiency may strongly depend on the value of eps. warnings.warn(message) .............................................................................................Ties preclude use of exact statistic. ..Ties preclude use of exact statistic. ....................................................TESTING CONVERGENCE zero should be 1 function f2 cc.bisect : 1.0000000000001952 cc.ridder : 1.0000000000004658 cc.brenth : 0.9999999999999997 cc.brentq : 0.9999999999999577 function f3 cc.bisect : 1.0000000000001952 cc.ridder : 1.0000000000000000 cc.brenth : 1.0000000000000009 cc.brentq : 1.0000000000000011 function f4 cc.bisect : 1.0000000000001952 cc.ridder : 1.0000000000001452 cc.brenth : 0.9999999999993339 cc.brentq : 0.9999999999993339 function f5 cc.bisect : 1.0000000000001952 cc.ridder : 1.0000000000004574 cc.brenth : 0.9999999999991442 cc.brentq : 0.9999999999991442 function f6 cc.bisect : 1.0000000000001952 cc.ridder : 1.0000000000004279 cc.brenth : 0.9999999999999446 cc.brentq : 1.0000000000006486 ......................................................................................................................... ......................................................................................................................... .............................Gleitkomma-Ausnahme elcorto at ramrod:~/Install/Python/SciPy/scipy$ ######################################################################################################################### -- Should array indices start at 0 or 1? My compromise of 0.5 was rejected without, I thought, proper consideration. -- Stan Kelly-Bootle From strawman at astraw.com Sat Dec 3 14:14:59 2005 From: strawman at astraw.com (Andrew Straw) Date: Sat, 03 Dec 2005 11:14:59 -0800 Subject: [SciPy-user] svn commands In-Reply-To: <4391DAC1.1020706@gmx.net> References: <438DCA77.8070303@att.net> <438E152B.6050804@csun.edu> <438E92EB.9030106@att.net> <439191BA.5080403@gmx.net> <4391DAC1.1020706@gmx.net> Message-ID: <4391EEB3.9030207@astraw.com> Steve Schmerler wrote: > scipy.test() > >I get a floating point exception: > >...................................................................................... >......................................................................................................................... >.............................Gleitkomma-Ausnahme > > Are you running Debian sarge on a machine with SSE? GNU libc version 2.3.2 has a bug[1] "feclearexcept() error on CPUs with SSE" (fixed in 2.3.3) which has been submitted to Debian[2] but not fixed in sarge. You can see my page about the issue, complete with patch[3]. [1] http://sources.redhat.com/bugzilla/show_bug.cgi?id=10 [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=279294 [3] http://www.its.caltech.edu/~astraw/coding.html#libc-patched-for-debian-sarge-to-fix-floating-point-exceptions-on-sse2 From oliphant.travis at ieee.org Sat Dec 3 15:25:01 2005 From: oliphant.travis at ieee.org (Travis Oliphant) Date: Sat, 03 Dec 2005 13:25:01 -0700 Subject: [SciPy-user] some benchmark data for numarray, Numeric and scipy-newcore In-Reply-To: <20051203131412.74250ba7.gerard.vermeulen@grenoble.cnrs.fr> References: <20051203131412.74250ba7.gerard.vermeulen@grenoble.cnrs.fr> Message-ID: <4391FF1D.9070500@ieee.org> Gerard Vermeulen wrote: >I have benchmarked some array manipulations using the default >Numeric and numarray on my Mandrake-10.2 and a recent snapshot >of the new scipy core. > > Thanks for the benchmarks. There definitely may be additional code-optimizations we can do. I would like to figure out why those specific lines you mention are taking longer --- it may be some simply thing. The other thing to keep in mind is the buffer size. SciPy core has a user-settable buffer size that determines when "mis-behaved" arrays (or type-cast-needed arrays) are copied and when they aren't. Playing with that size can make a difference on a per-platform basis. I just picked a default size that seemed reasonable. There are definitely some other optimizations that could be applied. Benchmarks like these can help us find them. If there is really something inherently slow in the ufunc algorithm then that needs to be fixed. -Travis From fonnesbeck at gmail.com Sat Dec 3 17:36:29 2005 From: fonnesbeck at gmail.com (Chris Fonnesbeck) Date: Sat, 3 Dec 2005 17:36:29 -0500 Subject: [SciPy-user] some benchmark data for numarray, Numeric and scipy-newcore In-Reply-To: <20051203131412.74250ba7.gerard.vermeulen@grenoble.cnrs.fr> References: <20051203131412.74250ba7.gerard.vermeulen@grenoble.cnrs.fr> Message-ID: <723eb6930512031436l74ec2fbfrc92cc4dc70bce5dd@mail.gmail.com> On 12/3/05, Gerard Vermeulen wrote: > > Conclusion: > - the overal performance of numarray is 23 % better than scipy-newcore and > 27 % better than Numeric. > - numarray is consistently faster than the other packages. > - scipy newcore is on average somewhat faster than Numeric3, but some operations > are really slow in comparison with the other packages. In partical the > statements labeled 2, 3, 4, 6 and 7 take 2 times more time using scipy-newcore > than using Numeric. > These results seem a little shocking to me. Has numarray made recent strides? As recent as a month ago, numarray was a dog, running orders of magnitude slower for almost everything, unless arrays were *huge*. What is up? -- Chris Fonnesbeck Atlanta, GA From oliphant.travis at ieee.org Sat Dec 3 17:57:06 2005 From: oliphant.travis at ieee.org (Travis Oliphant) Date: Sat, 03 Dec 2005 15:57:06 -0700 Subject: [SciPy-user] some benchmark data for numarray, Numeric and scipy-newcore In-Reply-To: <723eb6930512031436l74ec2fbfrc92cc4dc70bce5dd@mail.gmail.com> References: <20051203131412.74250ba7.gerard.vermeulen@grenoble.cnrs.fr> <723eb6930512031436l74ec2fbfrc92cc4dc70bce5dd@mail.gmail.com> Message-ID: <439222C2.90902@ieee.org> Chris Fonnesbeck wrote: >On 12/3/05, Gerard Vermeulen wrote: > > >>Conclusion: >>- the overal performance of numarray is 23 % better than scipy-newcore and >> 27 % better than Numeric. >>- numarray is consistently faster than the other packages. >>- scipy newcore is on average somewhat faster than Numeric3, but some operations >> are really slow in comparison with the other packages. In partical the >> statements labeled 2, 3, 4, 6 and 7 take 2 times more time using scipy-newcore >> than using Numeric. >> >> >> > >These results seem a little shocking to me. Has numarray made recent >strides? As recent as a month ago, numarray was a dog, running orders >of magnitude slower for almost everything, unless arrays were *huge*. >What is up? > > > I think that numarray is still faster for very large arrays in certain circumstances (I have test cases that show that scipy core is faster in basic operations). For small arrays, numarray is still slow. Based on what I've seen of your code, you use a lot of small arrays. Scipy core is still slower than Numeric on very small arrays too because of the increased ufunc overhead accompanying the added features. I'm hoping that some of this slowness will be alleviated once we give array scalars their own faster math (right now, array scalars go through the entire ufunc machinery for math --- definitely slower than what is possible). I would like to figure out if there are things Numarray is doing for ufuncs on large arrays, that scipy core is not doing. I would also like to figure out how numarray does such a quick arange (if the number shown in the benchmark is accurate). Benchmarks can be useful (because I'd like to get rid of unnecessary speed bumps in scipy which may still exist) but given the complexity of these code bases and the many paths through them, they can rarely be used as "X" is (always) faster than "Y". Best regards, -Travis From cookedm at physics.mcmaster.ca Sat Dec 3 20:31:10 2005 From: cookedm at physics.mcmaster.ca (David M. Cooke) Date: Sat, 3 Dec 2005 20:31:10 -0500 Subject: [SciPy-user] some benchmark data for numarray, Numeric and scipy-newcore In-Reply-To: <20051203131412.74250ba7.gerard.vermeulen@grenoble.cnrs.fr> References: <20051203131412.74250ba7.gerard.vermeulen@grenoble.cnrs.fr> Message-ID: On Dec 3, 2005, at 7:14 , Gerard Vermeulen wrote: > I have benchmarked some array manipulations using the default > Numeric and numarray on my Mandrake-10.2 and a recent snapshot > of the new scipy core. > > I used the following script which takes two arguments: a string > indicating which Numerical extension to use and an integer > setting the size of the arrays. > > > The results follow below, where the label column indicates the > corresponding > statement in the klein() function above: I've attached a version that runs all three packages at once, with results in columns. > [packer at titan JUNK]$ ./bench.py Numeric 12 > Numeric-23.1: benchmark size = 12 This is an old Numeric version; there were speedups made in 23.8. > numarray-1.2.3: benchmark size = 12 Also old. > Conclusion: > - the overal performance of numarray is 23 % better than scipy- > newcore and > 27 % better than Numeric. > - numarray is consistently faster than the other packages. > - scipy newcore is on average somewhat faster than Numeric3, but > some operations > are really slow in comparison with the other packages. In > partical the > statements labeled 2, 3, 4, 6 and 7 take 2 times more time using > scipy-newcore > than using Numeric. These are my numbers. They don't support the above conclusions :-) This is on an Athlon 64 3200+, running Debian. Numeric and numarray are from Debian unstable. cookedm at arbutus$ py bench.py 12 Numeric-24.2 numarray-1.4.0 scipy-core-0.7.4.1550 benchmark size = 12 (vectors of length 16777216) label Numeric numarray scipy.base 1 0.5642 1.086 0.541 2 1.044 1.952 0.8472 3 0.7367 0.7428 0.6201 4 1.965 0.8811 2.45 5 1.048 0.9061 0.9241 6 0.7419 0.7496 0.5371 7 1.972 1.293 2.412 8 1.222 0.94 0.9529 9 23.99 13.65 13.16 10 14.96 13.65 11.42 11 10.86 10.61 9.056 TOTAL 59.1 46.47 42.92 -- |>|\/|< /------------------------------------------------------------------\ |David M. Cooke http://arbutus.physics.mcmaster.ca/dmc/ |cookedm at physics.mcmaster.ca -------------- next part -------------- A non-text attachment was scrubbed... Name: bench.py Type: text/x-python-script Size: 3067 bytes Desc: not available URL: -------------- next part -------------- From oliphant.travis at ieee.org Sat Dec 3 22:07:58 2005 From: oliphant.travis at ieee.org (Travis Oliphant) Date: Sat, 03 Dec 2005 20:07:58 -0700 Subject: [SciPy-user] some benchmark data for numarray, Numeric and scipy-newcore In-Reply-To: References: <20051203131412.74250ba7.gerard.vermeulen@grenoble.cnrs.fr> Message-ID: <43925D8E.5040304@ieee.org> David M. Cooke wrote: > These are my numbers. They don't support the above conclusions :-) > This is on an Athlon 64 3200+, running Debian. Numeric and numarray > are from Debian unstable. > > cookedm at arbutus$ py bench.py 12 > Numeric-24.2 > numarray-1.4.0 > scipy-core-0.7.4.1550 > benchmark size = 12 (vectors of length 16777216) > label Numeric numarray scipy.base > 1 0.5642 1.086 0.541 > 2 1.044 1.952 0.8472 > 3 0.7367 0.7428 0.6201 > 4 1.965 0.8811 2.45 > 5 1.048 0.9061 0.9241 > 6 0.7419 0.7496 0.5371 > 7 1.972 1.293 2.412 > 8 1.222 0.94 0.9529 > 9 23.99 13.65 13.16 > 10 14.96 13.65 11.42 > 11 10.86 10.61 9.056 > TOTAL 59.1 46.47 42.92 I like your version better.... :-) But, seriously, it does still look like something is going on for lines 4 and 7 that could be improved in scipy core.... -Travis From dd55 at cornell.edu Sun Dec 4 00:07:50 2005 From: dd55 at cornell.edu (Darren Dale) Date: Sun, 4 Dec 2005 00:07:50 -0500 Subject: [SciPy-user] question about splines Message-ID: <200512040007.50634.dd55@cornell.edu> I have a question about the interpolate.splrep and interpolate.splev functions, which I am using to find the inflection point in some data. I am testing these functions with a sine curve, just finding the spline representations and then evaluating them: from scipy import * n=1000 xmin, xmax = 0,1 x = linspace(xmin,xmax,n) ymin, ymax = 0, 2*pi y = sin(linspace(ymin,ymax,n)) weights = ones(n)/0.00001 # 1/stdev for noisy data derivative = 2 print interpolate.splev(x,interpolate.splrep(x,y,s=n,w=weights),derivative).max() If I were using this tool correctly, the reported maximum would be very close to 1 for any derivative. derivative=0 does yield a good approximation. If derivative is not 0, the amplitude of the result can be off by orders of magnitude. The amplitude of the derivative curve is effected by the limits of x and y, which I don't understand. I must have overlooked something, does anyone have a suggestion? Thanks, Darren From gerard.vermeulen at grenoble.cnrs.fr Sun Dec 4 05:04:06 2005 From: gerard.vermeulen at grenoble.cnrs.fr (Gerard Vermeulen) Date: Sun, 4 Dec 2005 11:04:06 +0100 Subject: [SciPy-user] some benchmark data for numarray, Numeric and scipy-newcore In-Reply-To: References: <20051203131412.74250ba7.gerard.vermeulen@grenoble.cnrs.fr> Message-ID: <20051204110406.3e722799.gerard.vermeulen@grenoble.cnrs.fr> On Sat, 3 Dec 2005 20:31:10 -0500 "David M. Cooke" wrote: > These are my numbers. They don't support the above conclusions :-) > This is on an Athlon 64 3200+, running Debian. Numeric and numarray > are from Debian unstable. > > cookedm at arbutus$ py bench.py 12 > Numeric-24.2 > numarray-1.4.0 > scipy-core-0.7.4.1550 > benchmark size = 12 (vectors of length 16777216) > label Numeric numarray scipy.base > 1 0.5642 1.086 0.541 > 2 1.044 1.952 0.8472 > 3 0.7367 0.7428 0.6201 > 4 1.965 0.8811 2.45 > 5 1.048 0.9061 0.9241 > 6 0.7419 0.7496 0.5371 > 7 1.972 1.293 2.412 > 8 1.222 0.94 0.9529 > 9 23.99 13.65 13.16 > 10 14.96 13.65 11.42 > 11 10.86 10.61 9.056 > TOTAL 59.1 46.47 42.92 > OK, my system is: [packer at titan BUILD]$ uname -a Linux titan.rozan.fr 2.6.11-13mdksmp #1 SMP Mon Nov 28 12:22:08 MST 2005 i686 Intel(R) Pentium(R) 4 CPU 3.60GHz unknownGNU/Linux Attached you'll find modified bench.py to give a little bit more sysinfo, such as optimization flags. I have built a Python interpreter in my home to install the latest stuff and it makes things worse for scipy.base: [packer at titan BUILD]$ python bench.py 12 Importing test to scipy Importing base to scipy Importing basic to scipy Python 2.4.2 (#1, Dec 4 2005, 08:21:04) [GCC 3.4.3 (Mandrakelinux 10.2 3.4.3-7mdk)] Optimization flags: -DNDEBUG -O3 -march=i686 CPU info: getNCPUs=2 has_mmx has_sse has_sse2 is_32bit is_Intel is_Pentium is_PentiumIV Numeric-24.2 numarray-1.4.1 scipy-core-0.7.4.1560 benchmark size = 12 (vectors of length 16777216) label Numeric numarray scipy.base 1 0.4004 0.07397 0.3918 2 0.2715 0.2429 0.5111 3 0.1973 0.1738 0.4461 4 0.8764 0.5438 2.045 5 0.3005 0.2441 0.2861 6 0.1982 0.1726 0.4462 7 0.884 0.6183 2.047 8 0.6277 0.4362 0.425 9 9.515 7.626 8.76 10 9.556 8.057 8.768 11 7.865 6.319 7.336 TOTAL 30.69 24.51 31.46 Note that I have set -march=i686 to have comparable performance with Mandrake's default Python environment (Python's default flags result in a performance loss of about 50 %). I did not tweak any flags during the installation of the Numerical extensions. Conclusion: Comparing our numbers I would qualify Numeric and numarray as 32bit-friendly and scipy.base as 64bit-friendly. Interestingly, the first seven lines involve integer arrays and the overall worse performance of scipy.base with respect to Numeric is due to those seven lines (I tried to pass NX.Int32 into arange() to force an 'i' dtypechar but that made no difference). Gerard PS: for reference I summarize my results for my systems default Python, numararray and Numeric: [packer at titan ~]$ python bench.py 12 Importing test to scipy Importing base to scipy Importing basic to scipy Python 2.4 (#2, Feb 12 2005, 00:29:46) [GCC 3.4.3 (Mandrakelinux 10.2 3.4.3-3mdk)] Optimization flags: -DNDEBUG -O2 -fomit-frame-pointer -pipe -march=i586 -mtune=pentiumpro -g CPU info: getNCPUs=2 has_mmx has_sse has_sse2 is_32bit is_Intel is_Pentium is_PentiumIV Numeric-23.1 numarray-1.2.3 scipy-core-0.7.1.1526 benchmark size = 12 (vectors of length 16777216) label Numeric numarray scipy.base 1 0.4343 0.07348 0.4021 2 0.2653 0.2483 0.5149 3 0.192 0.1848 0.4531 4 1.01 0.5386 2.058 5 0.2721 0.2533 0.2669 6 0.1921 0.1865 0.4619 7 1.024 0.6261 2.067 8 0.6308 0.4323 0.4145 9 10.35 7.564 8.773 10 10.34 7.998 8.766 11 8.489 6.282 7.367 TOTAL 33.2 24.39 31.55 -------------- next part -------------- A non-text attachment was scrubbed... Name: bench.py Type: application/octet-stream Size: 3477 bytes Desc: not available URL: From svetosch at gmx.net Sun Dec 4 12:44:28 2005 From: svetosch at gmx.net (Sven Schreiber) Date: Sun, 04 Dec 2005 18:44:28 +0100 Subject: [SciPy-user] how to get matplotlib working with new scipy? In-Reply-To: <200512022144.jB2Li1J05350@laplace.astro.cornell.edu> References: <200512022144.jB2Li1J05350@laplace.astro.cornell.edu> Message-ID: <43932AFC.4020705@gmx.net> Tom, thanks for your informative reply! For the time being, however, I guess I'll try to see if new scipy can coexist with Numeric to get standard matplotlib working instead of trying to build a bleeding-edge version. (Btw, I would have searched the respective mail archives, but the search function doesn't work for me (seems to be broken?)). Thanks, Sven Tom Loredo wrote: >Hi Sven, > >I'm just starting with scipy_core, so I can't address all your >issues, but Travis just helped me regarding mpl compatibility, >so I'll pass on what he told me in case he hasn't answered yet. > >The issue of mpl compatibility was recently addressed on the >scipy and mpl developer lists. A patch was checked in that >enables you to use mpl with just scipy (no Numeric or numarray >needed). You can't just download the patches and patch >mpl 0.85; the files that are patched have changed since the >release. So you need to use the CVS version of mpl. >Instructions for downloading it are at the CVS link on the >mpl SourceForge page. Basically, just execute these two >CVS commands: > ># cvs -d:pserver:anonymous at cvs.sourceforge.net:/cvsroot/matplotlib login ># cvs -z3 -d:pserver:anonymous at cvs.sourceforge.net:/cvsroot/matplotlib co -P matplotlib > >This will create a "matplotlib" directory in your current >directory with the current CVS check-in. Go in there and >install mpl as usual. When you're done, you'll need to edit >your matplotlibrc file, setting numerix to "scipy". Then >the few examples I just tried all work. > >Cheers, >Tom > >_______________________________________________ >SciPy-user mailing list >SciPy-user at scipy.net >http://www.scipy.net/mailman/listinfo/scipy-user > > > > From ted.horst at earthlink.net Sun Dec 4 16:40:58 2005 From: ted.horst at earthlink.net (Ted Horst) Date: Sun, 4 Dec 2005 15:40:58 -0600 Subject: [SciPy-user] some benchmark data for numarray, Numeric and scipy-newcore In-Reply-To: <43925D8E.5040304@ieee.org> References: <20051203131412.74250ba7.gerard.vermeulen@grenoble.cnrs.fr> <43925D8E.5040304@ieee.org> Message-ID: I took a quick look at this in numarray and scipy (I don't have Numeric). It seems that numarray has separate lowest level functions for vector, vector multiplication and scalar, vector multiplication whereas scipy uses the same function for both. This results in an extra load double instruction being executed in scipy for the scalar, vector case. This is on a Powerbook G4, running OSX 10.3.9. Ted On Dec 3, 2005, at 21:07, Travis Oliphant wrote: > David M. Cooke wrote: > >> These are my numbers. They don't support the above conclusions :-) >> This is on an Athlon 64 3200+, running Debian. Numeric and numarray >> are from Debian unstable. >> >> cookedm at arbutus$ py bench.py 12 >> Numeric-24.2 >> numarray-1.4.0 >> scipy-core-0.7.4.1550 >> benchmark size = 12 (vectors of length 16777216) >> label Numeric numarray scipy.base >> 1 0.5642 1.086 0.541 >> 2 1.044 1.952 0.8472 >> 3 0.7367 0.7428 0.6201 >> 4 1.965 0.8811 2.45 >> 5 1.048 0.9061 0.9241 >> 6 0.7419 0.7496 0.5371 >> 7 1.972 1.293 2.412 >> 8 1.222 0.94 0.9529 >> 9 23.99 13.65 13.16 >> 10 14.96 13.65 11.42 >> 11 10.86 10.61 9.056 >> TOTAL 59.1 46.47 42.92 > > > I like your version better.... :-) But, seriously, it does still > look > like something is going on for lines 4 and 7 that could be improved in > scipy core.... > > -Travis > > _______________________________________________ > SciPy-user mailing list > SciPy-user at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-user > From gerard.vermeulen at grenoble.cnrs.fr Sun Dec 4 17:25:24 2005 From: gerard.vermeulen at grenoble.cnrs.fr (Gerard Vermeulen) Date: Sun, 4 Dec 2005 23:25:24 +0100 Subject: [SciPy-user] some benchmark data for numarray, Numeric and scipy-newcore In-Reply-To: References: <20051203131412.74250ba7.gerard.vermeulen@grenoble.cnrs.fr> <43925D8E.5040304@ieee.org> Message-ID: <20051204232524.654f752a.gerard.vermeulen@grenoble.cnrs.fr> I took a look at the difference between arange in numarray and scipy: in numarray arange is a Python function which dispatches the real work to a type dependent C function, whereas in scipy arange does all calculations in C doubles, which are cast to the requested type. This may explain why numarray's arange is 5 times faster than scipy's arange on my system (don't ask me why David's results for numarray are so slow). As a side effect, numarray's arange works for complex numbers contrary to scipy's arange. Gerard On Sun, 4 Dec 2005 15:40:58 -0600 Ted Horst wrote: > I took a quick look at this in numarray and scipy (I don't have > Numeric). > > It seems that numarray has separate lowest level functions for vector, > vector multiplication and scalar, vector multiplication whereas scipy > uses the same function for both. This results in an extra load double > instruction being executed in scipy for the scalar, vector case. > > This is on a Powerbook G4, running OSX 10.3.9. > > Ted > > On Dec 3, 2005, at 21:07, Travis Oliphant wrote: > > > David M. Cooke wrote: > > > >> These are my numbers. They don't support the above conclusions :-) > >> This is on an Athlon 64 3200+, running Debian. Numeric and numarray > >> are from Debian unstable. > >> > >> cookedm at arbutus$ py bench.py 12 > >> Numeric-24.2 > >> numarray-1.4.0 > >> scipy-core-0.7.4.1550 > >> benchmark size = 12 (vectors of length 16777216) > >> label Numeric numarray scipy.base > >> 1 0.5642 1.086 0.541 > >> 2 1.044 1.952 0.8472 > >> 3 0.7367 0.7428 0.6201 > >> 4 1.965 0.8811 2.45 > >> 5 1.048 0.9061 0.9241 > >> 6 0.7419 0.7496 0.5371 > >> 7 1.972 1.293 2.412 > >> 8 1.222 0.94 0.9529 > >> 9 23.99 13.65 13.16 > >> 10 14.96 13.65 11.42 > >> 11 10.86 10.61 9.056 > >> TOTAL 59.1 46.47 42.92 > > > > > > I like your version better.... :-) But, seriously, it does still > > look > > like something is going on for lines 4 and 7 that could be improved in > > scipy core.... > > > > -Travis > > > > _______________________________________________ > > SciPy-user mailing list > > SciPy-user at scipy.net > > http://www.scipy.net/mailman/listinfo/scipy-user > > > > _______________________________________________ > SciPy-user mailing list > SciPy-user at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-user > From oliphant.travis at ieee.org Sun Dec 4 17:57:05 2005 From: oliphant.travis at ieee.org (Travis Oliphant) Date: Sun, 04 Dec 2005 15:57:05 -0700 Subject: [SciPy-user] some benchmark data for numarray, Numeric and scipy-newcore In-Reply-To: <20051204232524.654f752a.gerard.vermeulen@grenoble.cnrs.fr> References: <20051203131412.74250ba7.gerard.vermeulen@grenoble.cnrs.fr> <43925D8E.5040304@ieee.org> <20051204232524.654f752a.gerard.vermeulen@grenoble.cnrs.fr> Message-ID: <43937441.4040303@ieee.org> Gerard Vermeulen wrote: >I took a look at the difference between arange in numarray and scipy: >in numarray arange is a Python function which dispatches the real work >to a type dependent C function, whereas in scipy arange does >all calculations in C doubles, which are cast to the requested type. > >This may explain why numarray's arange is 5 times faster than scipy's >arange on my system (don't ask me why David's results for numarray are >so slow). > > I looked into that last night and saw that one. We could very easily add a "fillarray" function to each data type if that optimization is seen as useful. I think something should definitely be done so that a cast is not done everytime. The Arange function could be made much faster, for sure. The other issue of vector-vector and vector-scalar operations, I'm less convinced about. Do we really need a whole other class of functions in the ufunc machinery. If so, I'm inclined to included them in the math operations for array-scalars, rather than the ufunc machinery. The major slow-down that does have me wondering whether an algorithm change (or optimization) is necessary is lines 4 and 7. These are mixed-type operations which I think are exercising the BUFFER_LOOP section of the general ufunc code. As the array sizes are larger than the buffer size (default is 80000 bytes and could be changed), no copy is made. In Numeric, a copy-cast is done on the entire array which is the main reason, I think, for its slower performance. In scipy core, currently, the cast is only done on a filled buffer. Right now, there are two things happening which could be optimized: 1) even if an array is not misbehaved it is still copied over into a buffer so that the inner loops are performed on the buffers. Technically, this is not necessary, but otherwise we would have to figure out a different way to signal that the inner loop should be called (right now its when the buffers are filled). Otherwise it would have to be some combination of filled buffer or the more complicated notion of (single-striding no longer possible for this array). 2) Items are copied over to the buffer 1 at a time. We should take advantage of contiguous chunks where we can. In short, numarray is doing a better job of handling the memory for the misbehaved cases and we could learn something from that. -Travis From aisaac at american.edu Sun Dec 4 22:37:28 2005 From: aisaac at american.edu (Alan G Isaac) Date: Sun, 4 Dec 2005 22:37:28 -0500 Subject: [SciPy-user] newbie float representation question Message-ID: >>> import scipy >>> 1/3. 0.33333333333333331 >>> scipy.array(1)/3. 0.33333333333333331 >>> scipy.array([1])/3. array([ 0.33333334], dtype=float32) Why is the last representation "rounded up"? Thanks, Alan Isaac From oliphant.travis at ieee.org Sun Dec 4 22:47:24 2005 From: oliphant.travis at ieee.org (Travis Oliphant) Date: Sun, 04 Dec 2005 20:47:24 -0700 Subject: [SciPy-user] newbie float representation question In-Reply-To: References: Message-ID: <4393B84C.2000509@ieee.org> Alan G Isaac wrote: >>>>import scipy >>>>1/3. >>>> >>>> >0.33333333333333331 > > >>>>scipy.array(1)/3. >>>> >>>> >0.33333333333333331 > > >>>>scipy.array([1])/3. >>>> >>>> >array([ 0.33333334], dtype=float32) > >Why is the last representation "rounded up"? > > Because the result is a float32: try scipy.array(1,dtype=float32)/3 This might be a problem with the scalar-vector coercion code. Basically scalars do not determine coercion in array-scalar operations unless the kind changes (like in this case). But, I don't think a float32 array is correct here, I would expect a float64. This is probably a bug. -Travis From abe.katsumi at jp.fujitsu.com Mon Dec 5 00:28:37 2005 From: abe.katsumi at jp.fujitsu.com (ABE Katsumi) Date: Mon, 05 Dec 2005 14:28:37 +0900 Subject: [SciPy-user] newbie argument handling question Message-ID: Hi, my apologies in advance for the newbie question and not adequate for scipy-ML. Is it allowed to use argument to get values like below in Python? jjj = self.datastorageObject.unitTestSetDataSubarray(Command[0],Division[0]) Here datastorageObject.unitTestSetDataSubarray is a CORBA object instantiated on another process. Command[0] is input. Division[0] is an argument for output and a struct. Our expect is that Division[0] can contain values set in datastorageObject.unitTestSetDataSubarray. Though we tried this code, we couldn't get values through Dividion[0]. On the other hand, we could get values through jjj[1].Mode where Mode is a member of the Division like below. print ' jjj[1].Mode = ', jjj[1].Mode Is it a right bevaviour of Python? Any suggestion would be helpful for us. Thanks, Katsumi From aisaac at american.edu Mon Dec 5 01:09:53 2005 From: aisaac at american.edu (Alan G Isaac) Date: Mon, 5 Dec 2005 01:09:53 -0500 Subject: [SciPy-user] linspace Message-ID: >>> S.linspace(0,1,2.5) array([ 0. , 0.66666667, 1.33333333]) >>> S.linspace(0,1,1) Traceback (most recent call last): File "", line 1, in ? File "C:\Python24\lib\site-packages\scipy\base\function_base.py", line 91, in linspace step = (stop-start)/float((num-1)) ZeroDivisionError: float division While this is just an abuse and a corner case, both of these are odd. Therefore I suggest a new definition: def linspace(start,stop,num=50,endpoint=True,retstep=False): """Evenly spaced numbers. Return an array of int(num) evenly spaced numbers from start to stop. If endpoint==True, then last sample is stop. If retstep==True, then also return the step value used. """ num = int(num) if num <= 0: return array([]) if endpoint: if num == 1: return array([stop]) step = (stop-start)/float(num-1) else: step = (stop-start)/float(num) y = _nx.arange(0,num) * step + start if retstep: return y, step else: return y Alan Isaac P.S. Here is the current definition: def linspace(start,stop,num=50,endpoint=1,retstep=0): """ Evenly spaced samples. Return num evenly spaced samples from start to stop. If endpoint=1 then last sample is stop. If retstep is 1 then return the step value used. """ if num <= 0: return array([]) if endpoint: step = (stop-start)/float((num-1)) y = _nx.arange(0,num) * step + start else: step = (stop-start)/float(num) y = _nx.arange(0,num) * step + start if retstep: return y, step else: return y From arnd.baecker at web.de Mon Dec 5 01:55:12 2005 From: arnd.baecker at web.de (Arnd Baecker) Date: Mon, 5 Dec 2005 07:55:12 +0100 (CET) Subject: [SciPy-user] [SciPy-dev] some benchmark data for numarray, Numeric and scipy-newcore In-Reply-To: <43937441.4040303@ieee.org> References: <20051203131412.74250ba7.gerard.vermeulen@grenoble.cnrs.fr> <43925D8E.5040304@ieee.org> <43937441.4040303@ieee.org> Message-ID: On Sun, 4 Dec 2005, Travis Oliphant wrote: [...] > The other issue of vector-vector and vector-scalar operations, I'm less > convinced about. Do we really need a whole other class of functions in > the ufunc machinery. If so, I'm inclined to included them in the math > operations for array-scalars, rather than the ufunc machinery. It seems that on some machines there are special math libraries available which specifically deal with such operations (havn't tried any of those yet, so take this comment with a bit of care). If there is a way to make use of them from scipy, that *could* give some further speed improvement ... And a (related) question: - installing scipy_core works without ATLAS - full scipy needs ATLAS - if a user installs ATLAS only in the second step, will the dot operation from scipy_core use dotblas, or not? (Also wondering about how eggs will handle such cases ...) Best, Arnd From ted.horst at earthlink.net Mon Dec 5 03:24:52 2005 From: ted.horst at earthlink.net (Ted Horst) Date: Mon, 5 Dec 2005 02:24:52 -0600 Subject: [SciPy-user] some benchmark data for numarray, Numeric and scipy-newcore In-Reply-To: <43937441.4040303@ieee.org> References: <20051203131412.74250ba7.gerard.vermeulen@grenoble.cnrs.fr> <43925D8E.5040304@ieee.org> <20051204232524.654f752a.gerard.vermeulen@grenoble.cnrs.fr> <43937441.4040303@ieee.org> Message-ID: <13c31abb97485f81699a3a63319d51a8@earthlink.net> On Dec 4, 2005, at 16:57, Travis Oliphant wrote: > The other issue of vector-vector and vector-scalar operations, I'm less > convinced about. Do we really need a whole other class of functions > in > the ufunc machinery. If so, I'm inclined to included them in the math > operations for array-scalars, rather than the ufunc machinery. The thing that led me to this was that scipy was spending a lot more time in DOUBLE_multiply than numarray was spending in multiply_ddxd_vvxv. Since the functions are equivalent, DOUBLE_multiply must be getting called more than multiply_ddxd_vvxv. My first guess was that this was because in numarray vetcor-scalar multiplies were going through multiply_ddxd_svxv. I tried to add a test for that by changing (the source to) DOUBLE_multiply to the following: /**begin repeat #TYP=FLOAT,DOUBLE,LONGDOUBLE# #typ=float,double,longdouble# */ static void @TYP at _multiply(char **args, intp *dimensions, intp *steps, void *func) { register intp i; intp is1=steps[0],is2=steps[1],os=steps[2], n=dimensions[0]; char *i1=args[0], *i2=args[1], *op=args[2]; /* fprintf(stderr, "Multiplying %d elements of type @typ@\n", n); fprintf(stderr, "args= %p, %p, %p\n", i1, i2, op); fprintf(stderr, "steps=%d, %d, %d\n", is1, is2, os); */ if (is1 == 0) { @typ@ temp = *(@typ@ *)i1; for(i=0; i References: <438DCA77.8070303@att.net> <438E152B.6050804@csun.edu> <438E92EB.9030106@att.net> <439191BA.5080403@gmx.net> <4391DAC1.1020706@gmx.net> <4391EEB3.9030207@astraw.com> Message-ID: <4394361C.3080901@gmx.net> Andrew Straw wrote: > Steve Schmerler wrote: > > >> scipy.test() >> >>I get a floating point exception: >> >>...................................................................................... >>......................................................................................................................... >>.............................Gleitkomma-Ausnahme >> >> > > > Are you running Debian sarge on a machine with SSE? Yes sarge. I'm running the latest kernel 2.6.14.3 (kernel.org) in case this info is of any importance. My CPU is a Athlon XP 2400+ so I shouldn't have SSE2 (says google). > > GNU libc version 2.3.2 has a bug[1] "feclearexcept() error on CPUs with > SSE" (fixed in 2.3.3) which has been submitted to Debian[2] but not > fixed in sarge. You can see my page about the issue, complete with patch[3]. > > [1] http://sources.redhat.com/bugzilla/show_bug.cgi?id=10 > [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=279294 > [3] > http://www.its.caltech.edu/~astraw/coding.html#libc-patched-for-debian-sarge-to-fix-floating-point-exceptions-on-sse2 > Since SSE seems not to be the problem, what else could it be? I get the same exception with the latest svn checkout of core and scipy as well as with the sources (core, scipy) from sourceforge. cheers, steve -- Should array indices start at 0 or 1? My compromise of 0.5 was rejected without, I thought, proper consideration. -- Stan Kelly-Bootle From cimrman3 at ntc.zcu.cz Mon Dec 5 08:55:57 2005 From: cimrman3 at ntc.zcu.cz (Robert Cimrman) Date: Mon, 05 Dec 2005 14:55:57 +0100 Subject: [SciPy-user] sparse matrix formats Message-ID: <439446ED.6070002@ntc.zcu.cz> Hi all, Is there a python module that can read (sparse) matrices in one of the formats listed at http://math.nist.gov/MatrixMarket/formats.html. I am especially interested in Harwell-Boeing format, which is used at http://www.cise.ufl.edu/research/sparse/matrices/. btw, the C (even in scipy: scipy/Lib/sparse/SuperLU/*readhb.c) or fortran (in UMFPACK package: UMFPACK/UMFPACK/Demo/readhb.f) functions are well available, just the wrappers I cannot find. I am going to swig'em myself because I need it - I posted this question in order to prevent (re)inventing wheels :) r. From david.huard at gmail.com Mon Dec 5 11:44:57 2005 From: david.huard at gmail.com (David Huard) Date: Mon, 5 Dec 2005 11:44:57 -0500 Subject: [SciPy-user] question about splines In-Reply-To: <200512040007.50634.dd55@cornell.edu> References: <200512040007.50634.dd55@cornell.edu> Message-ID: <91cf711d0512050844r2c4b9a50x3d0d1f4436010417@mail.gmail.com> Use x = linspace(0,2pi) y = sin(x) If you want to scale your function on (0,1), then you got to insert a factor 1/2/pi in the sinus function, and the derivative won't be 1 anymore. In the example you give, you artificially scale the sinus function by using an artificial x vector. David On 12/4/05, Darren Dale wrote: > > I have a question about the interpolate.splrep and interpolate.splev > functions, which I am using to find the inflection point in some data. > I am testing these functions with a sine curve, just finding the spline > representations and then evaluating them: > > from scipy import * > > n=1000 > xmin, xmax = 0,1 > x = linspace(xmin,xmax,n) > ymin, ymax = 0, 2*pi > y = sin(linspace(ymin,ymax,n)) > > weights = ones(n)/0.00001 # 1/stdev for noisy data > derivative = 2 > print interpolate.splev(x,interpolate.splrep > (x,y,s=n,w=weights),derivative).max() > > If I were using this tool correctly, the reported maximum would be > very close to 1 for any derivative. derivative=0 does yield a good > approximation. If derivative is not 0, the amplitude of the result can > be off by orders of magnitude. The amplitude of the derivative > curve is effected by the limits of x and y, which I don't understand. > > I must have overlooked something, does anyone have a suggestion? > > Thanks, > Darren > > _______________________________________________ > SciPy-user mailing list > SciPy-user at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: From oliphant.travis at ieee.org Mon Dec 5 17:06:57 2005 From: oliphant.travis at ieee.org (Travis Oliphant) Date: Mon, 05 Dec 2005 15:06:57 -0700 Subject: [SciPy-user] Data type change completed Message-ID: <4394BA01.20501@ieee.org> I've committed the data-type change discussed at the end of last week to the SVN repository. Now the concept of a data type for an array has been replaced with a "data-descriptor". This data-descriptor is flexible enough to handle an arbitrary record specification with fields that include records and arrays or arrays of records. While nesting may not be the best data-layout for a new design, when memory-mapping an arbitrary fixed-record-length file, this capability allows you to handle even the most obsure record file. While the basic core tests pass for me, there may be lurking problems and so testing of the SVN trunk of scipy core will be appreciated. I've bumped up the version number because the C-API has changed (a few new functions and some functions becoming macros). I'd like to make a release of the new version by the end of the week (as soon as Chris Hanley at STSCI and I get records.py working better), so please test. Recently some intel c-compiler tests were failing on a 64-bit platform. It would be nice to figure out why that is happening as well, but I will probably not have time for that this week. Thanks, -Travis From managan at llnl.gov Mon Dec 5 18:23:07 2005 From: managan at llnl.gov (Rob Managan) Date: Mon, 5 Dec 2005 15:23:07 -0800 Subject: [SciPy-user] Data type change completed In-Reply-To: <4394BA01.20501@ieee.org> References: <4394BA01.20501@ieee.org> Message-ID: The import scipy dies on Mac OS X 10.3.9. This was after updating core to revision 1569 and scipy to revision 1473. In both directories I did rm -rf build/ and a python setup.py install. It dies with Python 2.4.1 (#2, Mar 31 2005, 00:05:10) [GCC 3.3 20030304 (Apple Computer, Inc. build 1666)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import scipy Importing test to scipy Importing base to scipy Importing basic to scipy Importing io to scipy Importing fftpack to scipy Importing special to scipy Importing cluster to scipy Bus error At 3:06 PM -0700 12/5/05, Travis Oliphant wrote: >I've committed the data-type change discussed at the end of last week to >the SVN repository. Now the concept of a data type for an array has >been replaced with a "data-descriptor". This data-descriptor is >flexible enough to handle an arbitrary record specification with fields >that include records and arrays or arrays of records. While nesting may >not be the best data-layout for a new design, when memory-mapping an >arbitrary fixed-record-length file, this capability allows you to handle >even the most obsure record file. > >While the basic core tests pass for me, there may be lurking problems >and so testing of the SVN trunk of scipy core will be appreciated. I've >bumped up the version number because the C-API has changed (a few new >functions and some functions becoming macros). > >I'd like to make a release of the new version by the end of the week (as >soon as Chris Hanley at STSCI and I get records.py working better), so >please test. > >Recently some intel c-compiler tests were failing on a 64-bit platform. >It would be nice to figure out why that is happening as well, but I will >probably not have time for that this week. > >Thanks, > >-Travis > >_______________________________________________ >SciPy-user mailing list >SciPy-user at scipy.net >http://www.scipy.net/mailman/listinfo/scipy-user -- *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*- Rob Managan email managan at llnl.gov LLNL phone: 925-423-0903 P.O. Box 808, L-095 FAX: 925-422-3389 Livermore, CA 94551-0808 From oliphant.travis at ieee.org Mon Dec 5 18:46:50 2005 From: oliphant.travis at ieee.org (Travis Oliphant) Date: Mon, 05 Dec 2005 16:46:50 -0700 Subject: [SciPy-user] Data type change completed In-Reply-To: References: <4394BA01.20501@ieee.org> Message-ID: <4394D16A.5040009@ieee.org> Rob Managan wrote: >The import scipy dies on Mac OS X 10.3.9. > >This was after updating core to revision 1569 and scipy to revision >1473. In both directories I did rm -rf build/ and a python setup.py >install. > >It dies with > >Python 2.4.1 (#2, Mar 31 2005, 00:05:10) >[GCC 3.3 20030304 (Apple Computer, Inc. build 1666)] on darwin >Type "help", "copyright", "credits" or "license" for more information. > > >>>> import scipy >>>> >>>> >Importing test to scipy >Importing base to scipy >Importing basic to scipy >Importing io to scipy >Importing fftpack to scipy >Importing special to scipy >Importing cluster to scipy >Bus error > > I appreciate these reports, but I should make clear that I have not tested the changes against full scipy, yet. So, unless you are willing to help me track down possible remaining problems with the conversion, I would hold off on updating your SVN tree if you use full scipy. -Travis From gnchen at cortechs.net Mon Dec 5 21:33:11 2005 From: gnchen at cortechs.net (Gennan Chen) Date: Mon, 05 Dec 2005 18:33:11 -0800 Subject: [SciPy-user] Got complier error after updating to the newest scipy_core Message-ID: Hi! I just svn update core and installed it without a problem. But I ran into problems when I tried to compile scipy: /usr/include/sys/types.h:86: warning: `uint' previously declared here Lib/signal/sigtoolsmodule.c: In function `fill_buffer': Lib/signal/sigtoolsmodule.c:1410: error: structure has no member named `itemsize' Lib/signal/sigtoolsmodule.c: In function `Py_copy_info': Lib/signal/sigtoolsmodule.c:1624: error: structure has no member named `itemsize' Lib/signal/sigtoolsmodule.c: In function `Py_copy_info_vec': Lib/signal/sigtoolsmodule.c:1632: error: structure has no member named `itemsize' error: Command "gcc -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I/sw/lib/python2.4/site-packages/scipy/base/include -I/sw/include/python2.4 -c Lib/signal/sigtoolsmodule.c -o build/temp.darwin-8.3.0-Power_Macintosh-2.4/Lib/signal/sigtoolsmodule.o" failed with exit status 1 My OS is OSX 10.4.3 with fink?s python 2.4. No problem with previous version. -- Gen-Nan Chen, -------------- next part -------------- An HTML attachment was scrubbed... URL: From cookedm at physics.mcmaster.ca Mon Dec 5 21:43:00 2005 From: cookedm at physics.mcmaster.ca (David M. Cooke) Date: Mon, 05 Dec 2005 21:43:00 -0500 Subject: [SciPy-user] linspace In-Reply-To: (Alan G. Isaac's message of "Mon, 5 Dec 2005 01:09:53 -0500") References: Message-ID: Alan G Isaac writes: >>>> S.linspace(0,1,2.5) > array([ 0. , 0.66666667, 1.33333333]) >>>> S.linspace(0,1,1) > Traceback (most recent call last): > File "", line 1, in ? > File "C:\Python24\lib\site-packages\scipy\base\function_base.py", line 91, in > linspace > step = (stop-start)/float((num-1)) > ZeroDivisionError: float division > > While this is just an abuse and a corner case, both of these are odd. > Therefore I suggest a new definition: Maybe non-int values for num should throw a TypeError? > def linspace(start,stop,num=50,endpoint=True,retstep=False): > """Evenly spaced numbers. > > Return an array of int(num) evenly spaced numbers from start to stop. > If endpoint==True, then last sample is stop. > If retstep==True, then also return the step value used. > """ > num = int(num) > if num <= 0: > return array([]) > if endpoint: > if num == 1: > return array([stop]) > step = (stop-start)/float(num-1) > else: > step = (stop-start)/float(num) > y = _nx.arange(0,num) * step + start > if retstep: > return y, step > else: > return y This is good; I'll commit it. Once Travis fixes the tree so it builds... -- |>|\/|< /--------------------------------------------------------------------------\ |David M. Cooke http://arbutus.physics.mcmaster.ca/dmc/ |cookedm at physics.mcmaster.ca From cookedm at physics.mcmaster.ca Mon Dec 5 21:51:22 2005 From: cookedm at physics.mcmaster.ca (David M. Cooke) Date: Mon, 05 Dec 2005 21:51:22 -0500 Subject: [SciPy-user] linspace In-Reply-To: (Alan G. Isaac's message of "Mon, 5 Dec 2005 01:09:53 -0500") References: Message-ID: Alan G Isaac writes: >>>> S.linspace(0,1,2.5) > array([ 0. , 0.66666667, 1.33333333]) >>>> S.linspace(0,1,1) > Traceback (most recent call last): > File "", line 1, in ? > File "C:\Python24\lib\site-packages\scipy\base\function_base.py", line 91, in > linspace > step = (stop-start)/float((num-1)) > ZeroDivisionError: float division > > While this is just an abuse and a corner case, both of these are odd. > Therefore I suggest a new definition: > > def linspace(start,stop,num=50,endpoint=True,retstep=False): > """Evenly spaced numbers. > > Return an array of int(num) evenly spaced numbers from start to stop. > If endpoint==True, then last sample is stop. > If retstep==True, then also return the step value used. > """ > num = int(num) > if num <= 0: > return array([]) > if endpoint: > if num == 1: > return array([stop]) > step = (stop-start)/float(num-1) > else: > step = (stop-start)/float(num) > y = _nx.arange(0,num) * step + start > if retstep: > return y, step > else: > return y Actually, thinking about it: for linspace(0,1,1), do you want to return [0] or [1]? Every call to linspace returns an array starting with stop (0 here) regardless of endpoint, except for those that require 0 points, so this could be thought of an invariant. -- |>|\/|< /--------------------------------------------------------------------------\ |David M. Cooke http://arbutus.physics.mcmaster.ca/dmc/ |cookedm at physics.mcmaster.ca From oliphant.travis at ieee.org Mon Dec 5 23:36:03 2005 From: oliphant.travis at ieee.org (Travis Oliphant) Date: Mon, 05 Dec 2005 21:36:03 -0700 Subject: [SciPy-user] linspace In-Reply-To: References: Message-ID: <43951533.3030001@ieee.org> David M. Cooke wrote: >Alan G Isaac writes: > > > SciPy full now builds using the recent SVN version of scipy (a few missed changes still needed to be made to f2py). I'm getting only 1 error in check_odeint1 as well. So, I think the changes were reasonably successful (especially given how deep the surgery was --- PyArray_Typecode had spread its ugliness everywhere) Feel free to start relying on SVN again. -Travis From gnchen at cortechs.net Mon Dec 5 23:51:11 2005 From: gnchen at cortechs.net (Gennan Chen) Date: Mon, 05 Dec 2005 20:51:11 -0800 Subject: [SciPy-user] linspace In-Reply-To: <43951533.3030001@ieee.org> Message-ID: Hi! All, I am still stuck at Lib/signal/. The error messages are: In file included from Lib/signal/sigtools.h:2, from Lib/signal/sigtoolsmodule.c:8: /sw/lib/python2.4/site-packages/scipy/base/include/scipy/arrayobject.h:130: warning: redefinition of `ushort' /usr/include/sys/types.h:85: warning: `ushort' previously declared here /sw/lib/python2.4/site-packages/scipy/base/include/scipy/arrayobject.h:131: warning: redefinition of `uint' /usr/include/sys/types.h:86: warning: `uint' previously declared here Lib/signal/sigtoolsmodule.c: In function `fill_buffer': Lib/signal/sigtoolsmodule.c:1410: error: structure has no member named `itemsize' Lib/signal/sigtoolsmodule.c: In function `Py_copy_info': Lib/signal/sigtoolsmodule.c:1624: error: structure has no member named `itemsize' Lib/signal/sigtoolsmodule.c: In function `Py_copy_info_vec': Lib/signal/sigtoolsmodule.c:1632: error: structure has no member named `itemsize' In file included from Lib/signal/sigtools.h:2, from Lib/signal/sigtoolsmodule.c:8: /sw/lib/python2.4/site-packages/scipy/base/include/scipy/arrayobject.h:130: warning: redefinition of `ushort' /usr/include/sys/types.h:85: warning: `ushort' previously declared here /sw/lib/python2.4/site-packages/scipy/base/include/scipy/arrayobject.h:131: warning: redefinition of `uint' /usr/include/sys/types.h:86: warning: `uint' previously declared here Lib/signal/sigtoolsmodule.c: In function `fill_buffer': Lib/signal/sigtoolsmodule.c:1410: error: structure has no member named `itemsize' Lib/signal/sigtoolsmodule.c: In function `Py_copy_info': Lib/signal/sigtoolsmodule.c:1624: error: structure has no member named `itemsize' Lib/signal/sigtoolsmodule.c: In function `Py_copy_info_vec': Lib/signal/sigtoolsmodule.c:1632: error: structure has no member named `itemsize' error: Command "gcc -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I/sw/lib/python2.4/site-packages/scipy/base/include -I/sw/include/python2.4 -c Lib/signal/sigtoolsmodule.c -o build/temp.darwin-8.3.0-Power_Macintosh-2.4/Lib/signal/sigtoolsmodule.o" failed with exit status 1 removed Lib/__svn_version__.py removed Lib/__svn_version__.pyc I tried on Centos 4.2 and OS X 10.4.3. Both stuck at the same place. Gen On 12/5/05 8:36 PM, "Travis Oliphant" wrote: > David M. Cooke wrote: > >> Alan G Isaac writes: >> >> >> > SciPy full now builds using the recent SVN version of scipy (a few > missed changes still needed to be made to f2py). > > I'm getting only 1 error in check_odeint1 as well. So, I think the > changes were reasonably successful (especially given how deep the > surgery was --- PyArray_Typecode had spread its ugliness everywhere) > > Feel free to start relying on SVN again. > > -Travis > > > _______________________________________________ > SciPy-user mailing list > SciPy-user at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-user From gnchen at cortechs.net Tue Dec 6 00:17:50 2005 From: gnchen at cortechs.net (Gennan Chen) Date: Mon, 05 Dec 2005 21:17:50 -0800 Subject: [SciPy-user] linspace In-Reply-To: Message-ID: Travis, I just double check with the old scipy-0.6.1. It looks like itemsize field is not there in the new PyArrayObject structure. That is why the compilation failed. So, how do you pass it?? Gen On 12/5/05 8:51 PM, "Gennan Chen" wrote: > Hi! All, > > I am still stuck at Lib/signal/. The error messages are: > > In file included from Lib/signal/sigtools.h:2, > from Lib/signal/sigtoolsmodule.c:8: > /sw/lib/python2.4/site-packages/scipy/base/include/scipy/arrayobject.h:130: > warning: redefinition of `ushort' > /usr/include/sys/types.h:85: warning: `ushort' previously declared here > /sw/lib/python2.4/site-packages/scipy/base/include/scipy/arrayobject.h:131: > warning: redefinition of `uint' > /usr/include/sys/types.h:86: warning: `uint' previously declared here > Lib/signal/sigtoolsmodule.c: In function `fill_buffer': > Lib/signal/sigtoolsmodule.c:1410: error: structure has no member named > `itemsize' > Lib/signal/sigtoolsmodule.c: In function `Py_copy_info': > Lib/signal/sigtoolsmodule.c:1624: error: structure has no member named > `itemsize' > Lib/signal/sigtoolsmodule.c: In function `Py_copy_info_vec': > Lib/signal/sigtoolsmodule.c:1632: error: structure has no member named > `itemsize' > In file included from Lib/signal/sigtools.h:2, > from Lib/signal/sigtoolsmodule.c:8: > /sw/lib/python2.4/site-packages/scipy/base/include/scipy/arrayobject.h:130: > warning: redefinition of `ushort' > /usr/include/sys/types.h:85: warning: `ushort' previously declared here > /sw/lib/python2.4/site-packages/scipy/base/include/scipy/arrayobject.h:131: > warning: redefinition of `uint' > /usr/include/sys/types.h:86: warning: `uint' previously declared here > Lib/signal/sigtoolsmodule.c: In function `fill_buffer': > Lib/signal/sigtoolsmodule.c:1410: error: structure has no member named > `itemsize' > Lib/signal/sigtoolsmodule.c: In function `Py_copy_info': > Lib/signal/sigtoolsmodule.c:1624: error: structure has no member named > `itemsize' > Lib/signal/sigtoolsmodule.c: In function `Py_copy_info_vec': > Lib/signal/sigtoolsmodule.c:1632: error: structure has no member named > `itemsize' > error: Command "gcc -fno-strict-aliasing -Wno-long-double -no-cpp-precomp > -mno-fused-madd -DNDEBUG -g -O3 -Wall -Wstrict-prototypes > -I/sw/lib/python2.4/site-packages/scipy/base/include -I/sw/include/python2.4 > -c Lib/signal/sigtoolsmodule.c -o > build/temp.darwin-8.3.0-Power_Macintosh-2.4/Lib/signal/sigtoolsmodule.o" > failed with exit status 1 > removed Lib/__svn_version__.py > removed Lib/__svn_version__.pyc > > > I tried on Centos 4.2 and OS X 10.4.3. Both stuck at the same place. > > Gen > > > On 12/5/05 8:36 PM, "Travis Oliphant" wrote: > >> David M. Cooke wrote: >> >>> Alan G Isaac writes: >>> >>> >>> >> SciPy full now builds using the recent SVN version of scipy (a few >> missed changes still needed to be made to f2py). >> >> I'm getting only 1 error in check_odeint1 as well. So, I think the >> changes were reasonably successful (especially given how deep the >> surgery was --- PyArray_Typecode had spread its ugliness everywhere) >> >> Feel free to start relying on SVN again. >> >> -Travis >> >> >> _______________________________________________ >> SciPy-user mailing list >> SciPy-user at scipy.net >> http://www.scipy.net/mailman/listinfo/scipy-user > > > > _______________________________________________ > SciPy-user mailing list > SciPy-user at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-user From oliphant.travis at ieee.org Tue Dec 6 00:20:35 2005 From: oliphant.travis at ieee.org (Travis Oliphant) Date: Mon, 05 Dec 2005 22:20:35 -0700 Subject: [SciPy-user] linspace In-Reply-To: References: Message-ID: <43951FA3.30506@ieee.org> Gennan Chen wrote: >Hi! All, > >I am still stuck at Lib/signal/. The error messages are: > > Oops, forgot to do a commit. Sorry....Thanks for telling me. -Travis From cookedm at physics.mcmaster.ca Tue Dec 6 00:43:04 2005 From: cookedm at physics.mcmaster.ca (David M. Cooke) Date: Tue, 06 Dec 2005 00:43:04 -0500 Subject: [SciPy-user] [SciPy-dev] linspace In-Reply-To: <43951533.3030001@ieee.org> (Travis Oliphant's message of "Mon, 05 Dec 2005 21:36:03 -0700") References: <43951533.3030001@ieee.org> Message-ID: Travis Oliphant writes: > David M. Cooke wrote: > >>Alan G Isaac writes: >> >> >> > SciPy full now builds using the recent SVN version of scipy (a few > missed changes still needed to be made to f2py). > > I'm getting only 1 error in check_odeint1 as well. So, I think the > changes were reasonably successful (especially given how deep the > surgery was --- PyArray_Typecode had spread its ugliness everywhere) > > Feel free to start relying on SVN again. > > -Travis Isn't compiling for me: [00:39:39] [~/stuff/python/scipy/core] cookedm at arbutus$ svn update At revision 1575. [00:40:12] [~/stuff/python/scipy/core] cookedm at arbutus$ rm -rf build/ [00:40:21] [~/stuff/python/scipy/core] cookedm at arbutus$ python setup.py build [snip] building 'scipy.base.multiarray' extension compiling C sources gcc options: '-pthread -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC' creating build/temp.linux-x86_64-2.3/scipy creating build/temp.linux-x86_64-2.3/scipy/base creating build/temp.linux-x86_64-2.3/scipy/base/src compile options: '-Ibuild/src/scipy/base/src -Iscipy/base/include -Ibuild/src/scipy/base -Iscipy/base/src -I/usr/include/python2.3 -c' gcc: scipy/base/src/multiarraymodule.c In file included from scipy/base/src/multiarraymodule.c:44: scipy/base/src/arrayobject.c:3325: error: conflicting types for ?PyArray_NewFromDescr? build/src/scipy/base/__multiarray_api.h:135: error: previous declaration of ?PyArray_NewFromDescr? was here scipy/base/src/arrayobject.c: In function ?PyArray_NewFromDescr?: scipy/base/src/arrayobject.c:3343: warning: passing argument 4 of ?PyArray_NewFromDescr? from incompatible pointer type scipy/base/src/arrayobject.c:3343: warning: passing argument 5 of ?PyArray_NewFromDescr? from incompatible pointer type scipy/base/src/arrayobject.c:3399: warning: passing argument 2 of ?_array_fill_strides? from incompatible pointer type scipy/base/src/arrayobject.c: In function ?array_new?: scipy/base/src/arrayobject.c:3718: warning: passing argument 4 of ?PyArray_NewFromDescr? from incompatible pointer type scipy/base/src/arrayobject.c:3767: warning: passing argument 4 of ?PyArray_ (and more) I think the declarations in scipy/base/code_generators/generate_array_api.py are out of sync with current reality. I'm looking at making something that'll pull API declarations directly from the files (with some minimal markup) so that this doesn't happen. -- |>|\/|< /--------------------------------------------------------------------------\ |David M. Cooke http://arbutus.physics.mcmaster.ca/dmc/ |cookedm at physics.mcmaster.ca From msomers at mail.ie Tue Dec 6 04:14:56 2005 From: msomers at mail.ie (Martin Somers) Date: Tue, 6 Dec 2005 01:14:56 -0800 (PST) Subject: [SciPy-user] scipy 0.4.3 installation to python 2.4.2 Message-ID: <20051206011457.FBF0C636@dm20.mta.everyone.net> An HTML attachment was scrubbed... URL: From svetosch at gmx.net Tue Dec 6 06:01:40 2005 From: svetosch at gmx.net (Sven Schreiber) Date: Tue, 06 Dec 2005 12:01:40 +0100 Subject: [SciPy-user] scipy 0.4.3 installation to python 2.4.2 In-Reply-To: <20051206011457.FBF0C636@dm20.mta.everyone.net> References: <20051206011457.FBF0C636@dm20.mta.everyone.net> Message-ID: <43956F94.8080604@gmx.net> Hi Martin, I'm a newbie myself and so others may have more accurate answers, but it seems you need to install scipy-core before scipy and instead of numeric. Check out numeric.scipy.org for that, despite the name. I was also confused by this state of affairs, and the existence of quite a few (semi-?) official websites dealing with various incarnations of numeric/scipy contributed at least to my personal confusion. (No offense intended, just mho.) This is especially sad given that I think scipy is great -- I'm sure many other newbies never started using scipy because of that, instead of subscribing to the mailing list like martin and myself. To be a little more constructive: I think it would already help if some of the webpages were converted into pointers to the "one and only" numeric/old scipy/new scipy etc. page. (Again, only mho.) -sven Martin Somers schrieb: > Downloaded the windows binaries and have being trying in vein to install > have also tried compiling from source Process install python 2.4.2 -- > "python-2.4.2.msi" install numeric 24.2 -- > "Numeric-24.2.win32-py2.4.exe" install scipy -- > "scipy-0.4.3.win32-py2.4.exe" on importing scypi no module found > modified the sys.path to include the scipy directory but still the same > have tried python setup.py install resulting File "setup.py", line 24, > in ? from scipy.distutil.core import setup ImportError: No module named > scipy.distutils.core Any suggestions what i might be able to try tks M > > ------------------------------------------------------------------------ > Sign up for Private, FREE email from Mail.ie at http://www.mail.ie > > > ------------------------------------------------------------------------ > > _______________________________________________ > SciPy-user mailing list > SciPy-user at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-user From msomers at mail.ie Tue Dec 6 06:07:46 2005 From: msomers at mail.ie (Martin Somers) Date: Tue, 6 Dec 2005 03:07:46 -0800 (PST) Subject: [SciPy-user] scipy 0.4.3 installation to python 2.4.2 Message-ID: <20051206030746.FBF04766@dm22.mta.everyone.net> An HTML attachment was scrubbed... URL: From oliphant.travis at ieee.org Tue Dec 6 04:28:08 2005 From: oliphant.travis at ieee.org (Travis Oliphant) Date: Tue, 06 Dec 2005 02:28:08 -0700 Subject: [SciPy-user] scipy 0.4.3 installation to python 2.4.2 In-Reply-To: <20051206011457.FBF0C636@dm20.mta.everyone.net> References: <20051206011457.FBF0C636@dm20.mta.everyone.net> Message-ID: <439559A8.4080000@ieee.org> Martin Somers wrote: > Downloaded the windows binaries and have being trying in vein to > install have also tried compiling from source Process install python > 2.4.2 -- "python-2.4.2.msi" install numeric 24.2 -- > "Numeric-24.2.win32-py2.4.exe" install scipy -- > "scipy-0.4.3.win32-py2.4.exe" on importing scypi no module found > modified the sys.path to include the scipy directory but still the > same have tried python setup.py install resulting File "setup.py", > line 24, in ? from scipy.distutil.core import setup ImportError: No > module named scipy.distutils.core Any suggestions what i might be able > to try tks M > scipy 0.4.3 requires scipy_core (not Numeric) as a pre-requisite. You can get scipy_core from the Numeric sourceforge site. scipy_core is the replacement for Numeric which is obsolete but kept around for legacy code. -Travis From elcorto at gmx.net Tue Dec 6 07:31:29 2005 From: elcorto at gmx.net (Steve Schmerler) Date: Tue, 06 Dec 2005 13:31:29 +0100 Subject: [SciPy-user] scipy.test() floating point exception [old: svn commands] In-Reply-To: <4394361C.3080901@gmx.net> References: <438DCA77.8070303@att.net> <438E152B.6050804@csun.edu> <438E92EB.9030106@att.net> <439191BA.5080403@gmx.net> <4391DAC1.1020706@gmx.net> <4391EEB3.9030207@astraw.com> <4394361C.3080901@gmx.net> Message-ID: <439584A1.9010904@gmx.net> Hi with the latest svn versions I get: ########################################################################################## scipy.test(verbostiy=2) [...] check_fdtridfd (scipy.special.basic.test_basic.test_cephes) ... ok check_fresnel (scipy.special.basic.test_basic.test_cephes) ... ok check_gamma (scipy.special.basic.test_basic.test_cephes) ... ok check_gammainc (scipy.special.basic.test_basic.test_cephes) ... ok check_gammaincc (scipy.special.basic.test_basic.test_cephes) ... ok check_gammainccinv (scipy.special.basic.test_basic.test_cephes) ... ok check_gammaln (scipy.special.basic.test_basic.test_cephes) ... ok check_gdtr (scipy.special.basic.test_basic.test_cephes) ... ok check_gdtrc (scipy.special.basic.test_basic.test_cephes) ... ok check_gdtria (scipy.special.basic.test_basic.test_cephes) ... ok check_gdtrib (scipy.special.basic.test_basic.test_cephes) ... ok check_gdtrix (scipy.special.basic.test_basic.test_cephes) ... ok check_hankel1 (scipy.special.basic.test_basic.test_cephes)Gleitkomma-Ausnahme ########################################################################################## The test runs fine and crashes when the hankel1 function is called. Calls to the other hankel function (defined in the _cephes module) also end up in float exceptions: scipy.special._cephes.hankel1(1,1) scipy.special._cephes.hankel1e(1,1) scipy.special._cephes.hankel2(1,1) scipy.special._cephes.hankel2e(1,1) Outcommenting the tests of these functions in special/tests/test_basic.py makes place for more exceptions when calling other functions (i0e, i1e, ive, jve, k0, and probably many more), all from the _cephes module. Any ideas? cheers, steve -- Should array indices start at 0 or 1? My compromise of 0.5 was rejected without, I thought, proper consideration. -- Stan Kelly-Bootle From aisaac at american.edu Tue Dec 6 09:10:32 2005 From: aisaac at american.edu (Alan G Isaac) Date: Tue, 6 Dec 2005 09:10:32 -0500 Subject: [SciPy-user] linspace In-Reply-To: References: Message-ID: On Mon, 05 Dec 2005, cookedm at physics.mcmaster.ca (David M. Cooke) apparently wrote: > Actually, thinking about it: for linspace(0,1,1), do you > want to return [0] or [1]? Every call to linspace returns > an array starting with stop (0 here) regardless of > endpoint, except for those that require 0 points, so this > could be thought of an invariant. I do not have a strong opinion. I was just matching the documentation: If endpoint==True, then last sample is stop. It seems right to keep this. Cheers, Alan Isaac From stefan at sun.ac.za Tue Dec 6 10:46:09 2005 From: stefan at sun.ac.za (Stefan van der Walt) Date: Tue, 6 Dec 2005 17:46:09 +0200 Subject: [SciPy-user] converting from scipy.ndarray to Numeric array Message-ID: <20051206154609.GA27365@alpha> What is the preferred way of converting between scipy arrays and numarray/Numeric arrays? I need this in order to display images using mpl (the images are converted to scipy.ndarray using scipy.utils.pilutil.fromimage). Thanks in advance. St?fan From aisaac at american.edu Tue Dec 6 20:32:35 2005 From: aisaac at american.edu (Alan G Isaac) Date: Tue, 6 Dec 2005 20:32:35 -0500 Subject: [SciPy-user] logspace In-Reply-To: References: Message-ID: Proposed redefinition of logspace: def logspace(start,stop,num=50,endpoint=True,base=10.0): """Evenly spaced numbers on a logarithmic scale. Computes int(num) evenly spaced exponents from start to stop. If endpoint=True, then last exponent is stop. Returns base**exponents. """ y = linspace(start,stop,num=int(num),endpoint=endpoint) return _nx.power(base,y) Alan Isaac PS The current defintion follows: def logspace(start,stop,num=50,endpoint=1): """ Evenly spaced samples on a logarithmic scale. Return num evenly spaced samples from 10**start to 10**stop. If endpoint=1 then last sample is 10**stop. """ if num <= 0: return array([]) if endpoint: step = (stop-start)/float((num-1)) y = _nx.arange(0,num) * step + start else: step = (stop-start)/float(num) y = _nx.arange(0,num) * step + start return _nx.power(10.0,y) From aarre at pair.com Tue Dec 6 20:59:28 2005 From: aarre at pair.com (Aarre Laakso) Date: Tue, 06 Dec 2005 20:59:28 -0500 Subject: [SciPy-user] repmat Message-ID: <43964200.409@pair.com> Hi, Can anyone give me a clue about how I might implement a fast workalike for MATLAB's repmat function? http://www.mathworks.com/access/helpdesk/help/techdoc/ref/repmat.html The simple use case B = repmat(A,m,n) where A is an array and m,n are positive integers would be sufficient for my needs. I have pasted below my own attempt, which obviously involves way too much copying, because it takes a couple of minutes to replicate a 50-element row vector roughly 5000 times. It seems like repeat with some tricky slicing might work, but I can't figure out how to do it. Or maybe there's a better way? Thanks for any help you can offer. -- Aarre Laakso http://www.laakshmi.com/aarre/ def repmat(A, *args): """ Replicate and tile an array. """ result = A new_size = args for axis in range(0, len(new_size)): copy_value = result num_copies = new_size[axis] for curr_copy in range(1, num_copies): result = concatenate((result, copy_value), axis) return result From aisaac at american.edu Tue Dec 6 22:07:47 2005 From: aisaac at american.edu (Alan G Isaac) Date: Tue, 6 Dec 2005 22:07:47 -0500 Subject: [SciPy-user] repmat In-Reply-To: <43964200.409@pair.com> References: <43964200.409@pair.com> Message-ID: On Tue, 06 Dec 2005, Aarre Laakso apparently wrote: > Can anyone give me a clue about how I might implement a fast workalike > for MATLAB's repmat function? > http://www.mathworks.com/access/helpdesk/help/techdoc/ref/repmat.html > The simple use case B = repmat(A,m,n) where A is an array and m,n are > positive integers would be sufficient for my needs. > I have pasted below my own attempt, which obviously involves way too > much copying, because it takes a couple of minutes to replicate a > 50-element row vector roughly 5000 times. It seems like repeat with some > tricky slicing might work, but I can't figure out how to do it. Or maybe > there's a better way? > Thanks for any help you can offer. > def repmat(A, *args): > """ Replicate and tile an array. """ > result = A > new_size = args > for axis in range(0, len(new_size)): > copy_value = result > num_copies = new_size[axis] > for curr_copy in range(1, num_copies): > result = concatenate((result, copy_value), axis) What you really want is not a matrix like this---much too costly!---but rather an instance of a repmat class (which would keep only one copy of the data)! In the meantime, you can try a Kronecker product for your purpose. (Below.) Cheers, Alan Isaac def kroneckerproduct(a,b): '''Compute a otimes b where otimes is the Kronecker product operator. Note: the Kronecker product is also known as the matrix direct product or tensor product. It is defined as follows for 2D arrays a and b where shape(a)=(m,n) and shape(b)=(p,q): c = a otimes b => cij = a[i,j]*b where cij is the ij-th submatrix of c. So shape(c)=(m*p,n*q). :Parameters: - `a`: 2-D array - `b`: 2-D array :see: http://en.wikipedia.org/wiki/Kronecker_product :see: http://www.scipy.org/mailinglists/mailman?fn=scipy-user/2003-September/002138.html :author: Nils Wagner :author: Alan G. Isaac :date: 2004-08-12 :copyright: public domain :since: 2003-09-03 :note: Contributed to numarray in Sept 2003. >>> print kroneckerproduct([[1,2]],[[3],[4]]) [[3 6] [4 8]] >>> print kroneckerproduct([[1,2]],[[3,4]]) [ [3 4 6 8]] >>> print kroneckerproduct([[1],[2]],[[3],[4]]) [[3] [4] [6] [8]] ''' a, b = asarray(a), asarray(b) if not (len(shape(a))==2 and len(shape(b))==2): raise ValueError, 'Input must be 2D arrays.' if not a.iscontiguous(): a = reshape(a, a.shape) if not b.iscontiguous(): b = reshape(b, b.shape) o = outerproduct(a,b) o.shape = a.shape + b.shape return concatenate(concatenate(o, axis=1), axis=1) From oliphant.travis at ieee.org Tue Dec 6 22:31:53 2005 From: oliphant.travis at ieee.org (Travis Oliphant) Date: Tue, 06 Dec 2005 20:31:53 -0700 Subject: [SciPy-user] repmat In-Reply-To: <43964200.409@pair.com> References: <43964200.409@pair.com> Message-ID: <439657A9.9010709@ieee.org> Aarre Laakso wrote: >Hi, > >Can anyone give me a clue about how I might implement a fast workalike >for MATLAB's repmat function? > >http://www.mathworks.com/access/helpdesk/help/techdoc/ref/repmat.html > >The simple use case B = repmat(A,m,n) where A is an array and m,n are >positive integers would be sufficient for my needs. > > > I think the kronecker product is what you want: kron(ones(m,n),b) should be the same as repmat(b, m,n) Here is the implementation of kron in scipy.linalg (full scipy --- I think it should come over to scipy core, though). >>> utils.source(scipy.linalg.kron) In file: /usr/lib/python2.4/site-packages/scipy/linalg/basic.py def kron(a,b): """kronecker product of a and b Kronecker product of two matrices is block matrix [[ a[ 0 ,0]*b, a[ 0 ,1]*b, ... , a[ 0 ,n-1]*b ], [ ... ... ], [ a[m-1,0]*b, a[m-1,1]*b, ... , a[m-1,n-1]*b ]] """ if not a.flags['CONTIGUOUS']: a = reshape(a, a.shape) if not b.flags['CONTIGUOUS']: b = reshape(b, b.shape) o = outerproduct(a,b) o=o.reshape(a.shape + b.shape) return concatenate(concatenate(o, axis=1), axis=1) -Travis From cookedm at physics.mcmaster.ca Wed Dec 7 00:11:00 2005 From: cookedm at physics.mcmaster.ca (David M. Cooke) Date: Wed, 7 Dec 2005 00:11:00 -0500 Subject: [SciPy-user] logspace In-Reply-To: References: Message-ID: <20051207051100.GA17075@arbutus.physics.mcmaster.ca> On Tue, Dec 06, 2005 at 08:32:35PM -0500, Alan G Isaac wrote: > Proposed redefinition of logspace: > > def logspace(start,stop,num=50,endpoint=True,base=10.0): > """Evenly spaced numbers on a logarithmic scale. > > Computes int(num) evenly spaced exponents from start to stop. > If endpoint=True, then last exponent is stop. > Returns base**exponents. > """ > y = linspace(start,stop,num=int(num),endpoint=endpoint) > return _nx.power(base,y) Liking it, committed. Oh, and I'm still going with for num=1, returning [start] instead of [stop]. I feel the invariant for that overrides whatever endpoint is set to. (Besides, num=1 is such a corner case that whoever tries to do that won't be happy with either case :-) -- |>|\/|< /--------------------------------------------------------------------------\ |David M. Cooke http://arbutus.physics.mcmaster.ca/dmc/ |cookedm at physics.mcmaster.ca From msomers at mail.ie Wed Dec 7 08:44:47 2005 From: msomers at mail.ie (Martin Somers) Date: Wed, 7 Dec 2005 05:44:47 -0800 (PST) Subject: [SciPy-user] installation Message-ID: <20051207054447.FBF15A5E@dm22.mta.everyone.net> An HTML attachment was scrubbed... URL: From falted at pytables.org Wed Dec 7 11:52:05 2005 From: falted at pytables.org (Francesc Altet) Date: Wed, 7 Dec 2005 17:52:05 +0100 Subject: [SciPy-user] converting from scipy.ndarray to Numeric array In-Reply-To: <20051206154609.GA27365@alpha> References: <20051206154609.GA27365@alpha> Message-ID: <200512071752.06654.falted@pytables.org> A Dimarts 06 Desembre 2005 16:46, Stefan van der Walt va escriure: > What is the preferred way of converting between scipy arrays and > numarray/Numeric arrays? > > I need this in order to display images using mpl (the images are > converted to scipy.ndarray using scipy.utils.pilutil.fromimage). After the arrival of Numeric 24.x and numarray 1.5.x series, and provided you are using a relatively new version of scipy (> 0.4.3), I'd recommend you using the array protocol for doing this. Using the conversion in Python space is easy: numarray_array = numarray.asarray(scipy_array) Numeric_array = Numeric.asarray(scipy_array) If you are using C, you will have to use the array struct described in: http://numeric.scipy.org/array_interface.html HTH, -- Francesc Altet From managan at llnl.gov Wed Dec 7 13:14:07 2005 From: managan at llnl.gov (Rob Managan) Date: Wed, 7 Dec 2005 10:14:07 -0800 Subject: [SciPy-user] FFTs broken on Mac OSX Message-ID: I can't get rid of errors in the fftpack stuff in the new scipy. When I installed fftw2.1.5 I did a make check and it said it all was fine. This is on Mac OSX 10.3.9 Here is a test script based on the first failure I get in scipy.test() The k=1 case is OK, the k=2 case gives effectively zeros and should be a -1*sine curve if I understand this properly. ****** from scipy.fftpack import diff,fft,ifft from scipy.fftpack import fftfreq import scipy.base as Numeric from scipy.base import arange, add, array, sin, cos, pi,exp,tanh,sum def direct_diff(x,k=1,period=None): print 'x',x fx = fft(x) print ' ' print 'fx', fx n = len (fx) print 'n',n if period is None: period = 2*pi print 'fftfreq',fftfreq(n) w = fftfreq(n)*2j*pi/period*n print 'k, w', k,w if k<0: w = 1 / w**k w[0] = 0.0 else: w = w**k print 'w', w if n>2000: w[250:n-250] = 0.0 print "result",ifft(w*fx) return ifft(w*fx).real def check_definition(): n=16 x = arange(n)*2*pi/n print ' k= 1 test ' aaaaa = direct_diff(sin(x),1) print ' k= 2 test ' aaaaa = direct_diff(sin(x),2) check_definition() *** OUTPUT k= 1 test x [ 0.00000000e+00 3.82683432e-01 7.07106781e-01 9.23879533e-01 1.00000000e+00 9.23879533e-01 7.07106781e-01 3.82683432e-01 1.22464680e-16 -3.82683432e-01 -7.07106781e-01 -9.23879533e-01 -1.00000000e+00 -9.23879533e-01 -7.07106781e-01 -3.82683432e-01] fx [ 1.77975831e-16 +0.00000000e+00j -1.35945820e-15 -8.00000000e+00j -3.87815369e-16 -8.43346956e-16j 5.48376387e-17 -5.45964141e-16j 1.14423775e-17 -4.99600361e-16j 4.98926849e-16 -5.45964141e-16j 6.32744729e-16 -1.77213142e-16j 3.15834992e-16 +0.00000000e+00j 2.88998134e-16 +0.00000000e+00j 3.15834992e-16 -0.00000000e+00j 6.32744729e-16 +1.77213142e-16j 4.98926849e-16 +5.45964141e-16j 1.14423775e-17 +4.99600361e-16j 5.48376387e-17 +5.45964141e-16j -3.87815369e-16 +8.43346956e-16j -1.35945820e-15 +8.00000000e+00j] n 16 fftfreq [ 0. 0.0625 0.125 0.1875 0.25 0.3125 0.375 0.4375 -0.5 -0.4375 -0.375 -0.3125 -0.25 -0.1875 -0.125 -0.0625] k, w 1 [ 0.+0.j 0.+1.j 0.+2.j 0.+3.j 0.+4.j 0.+5.j 0.+6.j 0.+7.j 0.-8.j 0.-7.j 0.-6.j 0.-5.j 0.-4.j 0.-3.j 0.-2.j 0.-1.j] w [ 0.00000000e+00+0.j 6.12323400e-17+1.j 1.22464680e-16+2.j 1.83697020e-16+3.j 2.44929360e-16+4.j 3.06161700e-16+5.j 3.67394040e-16+6.j 4.28626380e-16+7.j 4.89858720e-16-8.j 4.28626380e-16-7.j 3.67394040e-16-6.j 3.06161700e-16-5.j 2.44929360e-16-4.j 1.83697020e-16-3.j 1.22464680e-16-2.j 6.12323400e-17-1.j] result [ 1.00000000e+00 +0.00000000e+00j 9.23879533e-01 -2.77555756e-17j 7.07106781e-01 +0.00000000e+00j 3.82683432e-01 +5.26704453e-33j -9.39464148e-17 -0.00000000e+00j -3.82683432e-01 -5.26704453e-33j -7.07106781e-01 -0.00000000e+00j -9.23879533e-01 -2.77555756e-17j -1.00000000e+00 +0.00000000e+00j -9.23879533e-01 +2.77555756e-17j -7.07106781e-01 +0.00000000e+00j -3.82683432e-01 +5.26704453e-33j -9.39464148e-17 +0.00000000e+00j 3.82683432e-01 -5.26704453e-33j 7.07106781e-01 -0.00000000e+00j 9.23879533e-01 +2.77555756e-17j] k= 2 test x [ 0.00000000e+00 3.82683432e-01 7.07106781e-01 9.23879533e-01 1.00000000e+00 9.23879533e-01 7.07106781e-01 3.82683432e-01 1.22464680e-16 -3.82683432e-01 -7.07106781e-01 -9.23879533e-01 -1.00000000e+00 -9.23879533e-01 -7.07106781e-01 -3.82683432e-01] fx [ 1.77975831e-16 +0.00000000e+00j -1.35945820e-15 -8.00000000e+00j -3.87815369e-16 -8.43346956e-16j 5.48376387e-17 -5.45964141e-16j 1.14423775e-17 -4.99600361e-16j 4.98926849e-16 -5.45964141e-16j 6.32744729e-16 -1.77213142e-16j 3.15834992e-16 +0.00000000e+00j 2.88998134e-16 +0.00000000e+00j 3.15834992e-16 -0.00000000e+00j 6.32744729e-16 +1.77213142e-16j 4.98926849e-16 +5.45964141e-16j 1.14423775e-17 +4.99600361e-16j 5.48376387e-17 +5.45964141e-16j -3.87815369e-16 +8.43346956e-16j -1.35945820e-15 +8.00000000e+00j] n 16 fftfreq [ 0. 0.0625 0.125 0.1875 0.25 0.3125 0.375 0.4375 -0.5 -0.4375 -0.375 -0.3125 -0.25 -0.1875 -0.125 -0.0625] k, w 2 [ 0.+0.j 0.+1.j 0.+2.j 0.+3.j 0.+4.j 0.+5.j 0.+6.j 0.+7.j 0.-8.j 0.-7.j 0.-6.j 0.-5.j 0.-4.j 0.-3.j 0.-2.j 0.-1.j] w [ 0. +0.00000000e+00j -1. +1.22464680e-16j -4. +4.89858720e-16j -9. +1.10218212e-15j -16. +1.95943488e-15j -25. +3.06161700e-15j -36. +4.40872848e-15j -49. +6.00076932e-15j -64. -7.83773951e-15j -49. -6.00076932e-15j -36. -4.40872848e-15j -25. -3.06161700e-15j -16. -1.95943488e-15j -9. -1.10218212e-15j -4. -4.89858720e-16j -1. -1.22464680e-16j] result [ -7.09525200e-15 +0.00000000e+00j 5.93691289e-15 -1.64869810e-32j -1.14813636e-15 +0.00000000e+00j -1.52577697e-15 +1.31424439e-31j 1.47456631e-15 -0.00000000e+00j -4.63227633e-16 -1.31424439e-31j -1.11807920e-15 -0.00000000e+00j 6.76061857e-16 -2.79335858e-31j -5.69389769e-16 +0.00000000e+00j 6.76061857e-16 +2.79335858e-31j -1.11807920e-15 +0.00000000e+00j -4.63227633e-16 +1.31424439e-31j 1.47456631e-15 +0.00000000e+00j -1.52577697e-15 -1.31424439e-31j -1.14813636e-15 -0.00000000e+00j 5.93691289e-15 +1.64869810e-32j] -- *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*- Rob Managan email managan at llnl.gov LLNL phone: 925-423-0903 P.O. Box 808, L-095 FAX: 925-422-3389 Livermore, CA 94551-0808 From jadelman at OCF.Berkeley.EDU Wed Dec 7 19:07:30 2005 From: jadelman at OCF.Berkeley.EDU (Joshua L. Adelman) Date: Wed, 7 Dec 2005 16:07:30 -0800 Subject: [SciPy-user] Checking vecLib usage for SciPy (OS X) Message-ID: I was wondering if there was a simple way to tell if an installation of SciPy on OS X properly used the optimized vecLib libraries for ATLAS BLAS and LAPACK or if it was linked against the default libraries (that would not result in optimal performance). Thanks in advance for any help that you can provide. Josh From jadelman at OCF.Berkeley.EDU Wed Dec 7 19:18:47 2005 From: jadelman at OCF.Berkeley.EDU (Joshua L. Adelman) Date: Wed, 7 Dec 2005 16:18:47 -0800 Subject: [SciPy-user] Problem installing Core on OS X Message-ID: <7CF85EDC-5627-475F-8B67-A02DC6F97A00@OCF.Berkeley.EDU> After successfully installing Scipy on my G5 Powermac Workstation, I'm attempting to do the same for my G4 powerbook. I used the instructions for getting the core and scipy from SVN (from "Building Scipy for Mac OSX") and got the following output when using the command: cd core python setup.py build OUTPUT: Traceback (most recent call last): File "setup.py", line 42, in ? setup_package() File "setup.py", line 7, in setup_package from scipy.distutils.core import setup ImportError: No module named scipy.distutils.core c-69-181-149-4:~/Desktop/scipy-0.4.3 lev$ cd ~/Desktop/ c-69-181-149-4:~/Desktop lev$ cd core/ c-69-181-149-4:~/Desktop/core lev$ python setup.py build Running from scipy core source directory. Assuming default configuration (scipy/distutils/command/ {setup_command,setup}.py was not found) Appending scipy.distutils.command configuration to scipy.distutils Assuming default configuration (scipy/distutils/fcompiler/ {setup_fcompiler,setup}.py was not found) Appending scipy.distutils.fcompiler configuration to scipy.distutils Appending scipy.distutils configuration to scipy Appending scipy.weave configuration to scipy Assuming default configuration (scipy/test/{setup_test,setup}.py was not found) Appending scipy.test configuration to scipy No module named __svn_version__ Creating scipy/f2py/__svn_version__.py (version='1597') F2PY Version 2_1597 Appending scipy.f2py configuration to scipy Creating scipy/base/__svn_version__.py (version='1597') Appending scipy.base configuration to scipy blas_opt_info: FOUND: extra_link_args = ['-Wl,-framework', '-Wl,Accelerate'] define_macros = [('NO_ATLAS_INFO', 3)] extra_compile_args = ['-faltivec', '-I/System/Library/Frameworks/ vecLib.framework/Headers'] lapack_opt_info: FOUND: extra_link_args = ['-Wl,-framework', '-Wl,Accelerate'] define_macros = [('NO_ATLAS_INFO', 3)] extra_compile_args = ['-faltivec'] Appending scipy.lib configuration to scipy Appending scipy.basic configuration to scipy Appending scipy configuration to Inheriting attribute 'version' from '?' scipy_core version 0.8.1.1597 running build running config_fc running build_src building extension "scipy.distutils.__config__" sources adding 'build/src/scipy/distutils/scipy/distutils/__config__.py' to sources. building extension "scipy.base.multiarray" sources Generating build/src/scipy/base/config.h customize NAGFCompiler customize AbsoftFCompiler customize IbmFCompiler Could not locate executable f95 customize GnuFCompiler customize GnuFCompiler customize GnuFCompiler using config gcc options: '-fno-strict-aliasing -Wno-long-double -no-cpp-precomp - mno-fused-madd -fPIC -fno-common -dynamic -DNDEBUG -g -O3 -Wall - Wstrict-prototypes' compile options: '-I/Library/Frameworks/Python.framework/Versions/2.4/ include/python2.4 -Iscipy/base/src -I/Library/Frameworks/ Python.framework/Versions/2.4/include/python2.4 -c' gcc: _configtest.c gcc: unrecognized option '-no-cpp-precomp' cc1: error: unrecognized command line option "-Wno-long-double" gcc: unrecognized option '-no-cpp-precomp' cc1: error: unrecognized command line option "-Wno-long-double" failure. removing: _configtest.c _configtest.o Traceback (most recent call last): File "setup.py", line 38, in ? setup_package() File "setup.py", line 31, in setup_package setup( **config.todict() ) File "/Users/lev/Desktop/core/scipy/distutils/core.py", line 93, in setup return old_setup(**new_attr) File "/Library/Frameworks/Python.framework/Versions/2.4/lib/ python2.4/distutils/core.py", line 149, in setup dist.run_commands() File "/Library/Frameworks/Python.framework/Versions/2.4/lib/ python2.4/distutils/dist.py", line 946, in run_commands self.run_command(cmd) File "/Library/Frameworks/Python.framework/Versions/2.4/lib/ python2.4/distutils/dist.py", line 966, in run_command cmd_obj.run() File "/Library/Frameworks/Python.framework/Versions/2.4/lib/ python2.4/distutils/command/build.py", line 112, in run self.run_command(cmd_name) File "/Library/Frameworks/Python.framework/Versions/2.4/lib/ python2.4/distutils/cmd.py", line 333, in run_command self.distribution.run_command(command) File "/Library/Frameworks/Python.framework/Versions/2.4/lib/ python2.4/distutils/dist.py", line 966, in run_command cmd_obj.run() File "/Users/lev/Desktop/core/scipy/distutils/command/ build_src.py", line 86, in run self.build_sources() File "/Users/lev/Desktop/core/scipy/distutils/command/ build_src.py", line 99, in build_sources self.build_extension_sources(ext) File "/Users/lev/Desktop/core/scipy/distutils/command/ build_src.py", line 143, in build_extension_sources sources = self.generate_sources(sources, ext) File "/Users/lev/Desktop/core/scipy/distutils/command/ build_src.py", line 199, in generate_sources source = func(extension, build_dir) File "scipy/base/setup.py", line 36, in generate_config_h raise "ERROR: Failed to test configuration" ERROR: Failed to test configuration removed scipy/base/__svn_version__.py removed scipy/base/__svn_version__.pyc removed scipy/f2py/__svn_version__.py removed scipy/f2py/__svn_version__.pyc From cookedm at physics.mcmaster.ca Wed Dec 7 20:56:31 2005 From: cookedm at physics.mcmaster.ca (David M. Cooke) Date: Wed, 7 Dec 2005 20:56:31 -0500 Subject: [SciPy-user] Checking vecLib usage for SciPy (OS X) In-Reply-To: References: Message-ID: <20051208015631.GA24891@arbutus.physics.mcmaster.ca> On Wed, Dec 07, 2005 at 04:07:30PM -0800, Joshua L. Adelman wrote: > I was wondering if there was a simple way to tell if an installation > of SciPy on OS X properly used the optimized vecLib libraries for > ATLAS BLAS and LAPACK or if it was linked against the default > libraries (that would not result in optimal performance). > > Thanks in advance for any help that you can provide. You could use otool -L against the .so files to see what frameworks they're linked with. On my Mac, they are being linked properly (to the Accelerate framework, which contains the vecLib libraries). -- |>|\/|< /--------------------------------------------------------------------------\ |David M. Cooke http://arbutus.physics.mcmaster.ca/dmc/ |cookedm at physics.mcmaster.ca From arnd.baecker at web.de Thu Dec 8 02:07:05 2005 From: arnd.baecker at web.de (Arnd Baecker) Date: Thu, 8 Dec 2005 08:07:05 +0100 (CET) Subject: [SciPy-user] Checking vecLib usage for SciPy (OS X) In-Reply-To: <20051208015631.GA24891@arbutus.physics.mcmaster.ca> References: <20051208015631.GA24891@arbutus.physics.mcmaster.ca> Message-ID: On Wed, 7 Dec 2005, David M. Cooke wrote: > On Wed, Dec 07, 2005 at 04:07:30PM -0800, Joshua L. Adelman wrote: > > I was wondering if there was a simple way to tell if an installation > > of SciPy on OS X properly used the optimized vecLib libraries for > > ATLAS BLAS and LAPACK or if it was linked against the default > > libraries (that would not result in optimal performance). > > > > Thanks in advance for any help that you can provide. > > You could use otool -L against the .so files to see what frameworks > they're linked with. > > On my Mac, they are being linked properly (to the Accelerate framework, > which contains the vecLib libraries). Another command which I find very helpful (pointed out to me by Pearu, if I remember correctly) is import scipy scipy.__core_config__.show() and for the full scipy scipy.__scipy_config__.show() (for the old scipy one could try `import scipy.config;scipy.config.show()`) Actually, it might be useful to have some scpipy.__core_config.show_used_libraries() (etc.) command, which reveals, which libraries are really used in the end. For fft I used something like this: #################################################### import scipy import os import subprocess dir=os.path.split(scipy.__file__)[0] lib=dir+"/fftpack/_fftpack.so" # firr shared linking (most obvious one, I think ...) print "ldd:" o=subprocess.call("/usr/bin/ldd %s " % (lib),shell=True ) # If the result is not empty for the following commands, fftw # has been linked into _fftpack.so print "search for fftw:" o=subprocess.call("nm %s | grep fftw" % (lib),shell=True ) # If the following is not empty, fftw2 is used # (this symbol only exists for fftw2 and not fftw3) print "fftw2? :" o=subprocess.call("nm %s | grep create" % (lib),shell=True) ############################################################ I am sure this can be made nicer (and more automatic and generalized to other platforms/situations), but maybe it is still useful. Best, Arnd From jaonary at free.fr Thu Dec 8 10:20:30 2005 From: jaonary at free.fr (jaonary at free.fr) Date: Thu, 08 Dec 2005 16:20:30 +0100 Subject: [SciPy-user] scipy 0.4.3, gnuplot and wxPython Message-ID: <1134055230.43984f3e2e8ee@imp3-g19.free.fr> Hi all, I'm trying to use scipy to do some 2d graphics plotting. I run it under win xp sp2 with activepython 2.4.2, scipy_core 0.6 and scipy 0.4.3. All of these intalled using the windows installer available on sourceforge. It said, some where in the scipy web page, that on windows platform, gnuplot is installed automaticly by scipy. But, when I do from scipy import gplt I get Importing io to scipy Importing fftpack to scipy Importing special to scipy Importing utils to scipy Importing cluster to scipy Importing sparse to scipy Importing interpolate to scipy Importing lib to scipy Importing integrate to scipy Importing signal to scipy Importing optimize to scipy Importing linalg to scipy Importing stats to scipy Traceback (most recent call last): File "", line 1, in ? ImportError: cannot import name gplt So I think that, there's no gnuplot installed at all! After some tour on the scipy tutorial, I find that I can plot graphics using wxPython. Great! It makes me happy. Then, I download the wxPython installer (2.6.1.0) and install it. But, .... >>> gui_thread Traceback (most recent call last): File "", line 1, in ? NameError: name 'gui_thread' is not defined Arrrgggg! Any hint will be helpfull. Thank you. From ryanlists at gmail.com Thu Dec 8 10:45:04 2005 From: ryanlists at gmail.com (Ryan Krauss) Date: Thu, 8 Dec 2005 10:45:04 -0500 Subject: [SciPy-user] 'object_arrtype' problem Message-ID: I am having a problem very similar to one Chris Fonnesbeck was having a few days ago. I have a list of user defined objects. I also want to allow for the passing of a scalar to this particular function, so I call atleast_1d on the list/scalar and then iterate over it. After I call atleast_1d, indexing the list returns object_arrtype. One interesting thing is that I have redefined __repr__ for this object, and that method seems to be called correctly, but trying to access any other property of the object causes messages like "*** AttributeError: 'object_arrtype' object has no attribute 'dof'". Here is a pdb session just before and after atleast_1d is called. Is this a bug or should I be doing this differently with new scipy (this code worked fine with old scipy). In [2]: run fortran_dev.py > /home/ryan/rwkpython/TMM/__init__.py(292)__init__() -> if bodeouts: (Pdb) n > /home/ryan/rwkpython/TMM/__init__.py(293)__init__() -> bodeouts=atleast_1d(bodeouts) (Pdb) type(bodeouts) Out[2]: (Pdb) test=bodeouts[0] (Pdb) type(test) Out[2]: (Pdb) test.dof Out[2]: 0 (Pdb) test Out[2]: rwkbode.bodeout instance dof=0 pind=None input=Force in middle ind= output=L/2 position post= type=abs (Pdb) n > /home/ryan/rwkpython/TMM/__init__.py(294)__init__() -> tempbo=[] (Pdb) l 289 self.bccols.append(ent)#in evaluating the eigvalues, the columns of the system U matrix that multiply the non-zero elements of the base state vector are the ones whose sub-determinant must go to 0 290 291 pdb.set_trace() 292 if bodeouts: 293 bodeouts=atleast_1d(bodeouts) 294 -> tempbo=[] 295 for cb in bodeouts: 296 if type(cb)==dict: 297 curtemp=rwkbode.bodeout(**cb) 298 tempbo.append(curtemp) 299 else: (Pdb) type(bodeouts) Out[2]: (Pdb) test=bodeouts[0] (Pdb) type(test) Out[2]: (Pdb) test Out[2]: rwkbode.bodeout instance dof=0 pind=None input=Force in middle ind= output=L/2 position post= type=abs (Pdb) test.dof *** AttributeError: 'object_arrtype' object has no attribute 'dof' (Pdb) Thanks, Ryan From aisaac at american.edu Thu Dec 8 10:46:54 2005 From: aisaac at american.edu (Alan G Isaac) Date: Thu, 8 Dec 2005 10:46:54 -0500 Subject: [SciPy-user] scipy 0.4.3, gnuplot and wxPython In-Reply-To: <1134055230.43984f3e2e8ee@imp3-g19.free.fr> References: <1134055230.43984f3e2e8ee@imp3-g19.free.fr> Message-ID: On Thu, 08 Dec 2005, jaonary at free.fr apparently wrote: > I'm trying to use scipy to do some 2d graphics plotting. The right answer will be to use SciPy and Matplotlib. I think Matplotlib already talks to the new SciPy core, but I'm not positive (since I still use Numeric for Matplotlib numerics). See http://aspn.activestate.com/ASPN/Mail/Message/scipy-user/2923861 hth, Alan Isaac From abe.katsumi at jp.fujitsu.com Thu Dec 8 10:53:05 2005 From: abe.katsumi at jp.fujitsu.com (ABE Katsumi) Date: Fri, 09 Dec 2005 00:53:05 +0900 Subject: [SciPy-user] bit shift of a single byte iinteger Message-ID: Hi all, Is there any function to shift bit of a single byte integer? Thanks you for your help, Katsumi From oliphant.travis at ieee.org Thu Dec 8 12:20:02 2005 From: oliphant.travis at ieee.org (Travis Oliphant) Date: Thu, 08 Dec 2005 10:20:02 -0700 Subject: [SciPy-user] 'object_arrtype' problem In-Reply-To: References: Message-ID: <43986B42.5000904@ieee.org> Ryan Krauss wrote: >I am having a problem very similar to one Chris Fonnesbeck was having >a few days ago. I have a list of user defined objects. I also want >to allow for the passing of a scalar to this particular function, so I >call atleast_1d on the list/scalar and then iterate over it. After I >call atleast_1d, indexing the list returns object_arrtype. One >interesting thing is that I have redefined __repr__ for this object, >and that method seems to be called correctly, but trying to access any >other property of the object causes messages like "*** AttributeError: >'object_arrtype' object has no attribute 'dof'". Here is a pdb >session just before and after atleast_1d is called. Is this a bug or >should I be doing this differently with new scipy (this code worked >fine with old scipy). > > I think the object scalars need a little more work. There is a valid question whether to have them at all. What these scalars do is unify the methods of scalars and arrays. Without them, then object arrays would have different selection semantics then non-object arrays. Perhaps this would be a "good" thing. At any rate, you can always get the underlying object the object-scalar wraps using the toscalar() method. I think a very natural thing-to-do, though, which would clear up these issues and leave the object scalar around is to hand off behavior of the object to the underlying object in all cases. -Travis From wjdandreta at att.net Thu Dec 8 12:20:54 2005 From: wjdandreta at att.net (Bill Dandreta) Date: Thu, 08 Dec 2005 12:20:54 -0500 Subject: [SciPy-user] bit shift of a single byte iinteger In-Reply-To: References: Message-ID: <43986B76.7030103@att.net> ABE Katsumi wrote: >Hi all, > >Is there any function to shift bit of a single byte integer? > >Thanks you for your help, > >Katsumi > >_______________________________________________ >SciPy-user mailing list >SciPy-user at scipy.net >http://www.scipy.net/mailman/listinfo/scipy-user > > > http://www.python.org/doc/2.2.3/lib/bitstring-ops.html Bill From ryanlists at gmail.com Thu Dec 8 12:23:25 2005 From: ryanlists at gmail.com (Ryan Krauss) Date: Thu, 8 Dec 2005 12:23:25 -0500 Subject: [SciPy-user] 'object_arrtype' problem In-Reply-To: <43986B42.5000904@ieee.org> References: <43986B42.5000904@ieee.org> Message-ID: What do you mean by "hand off behavior of the object to the underlying object in all cases"? Ryan On 12/8/05, Travis Oliphant wrote: > Ryan Krauss wrote: > > >I am having a problem very similar to one Chris Fonnesbeck was having > >a few days ago. I have a list of user defined objects. I also want > >to allow for the passing of a scalar to this particular function, so I > >call atleast_1d on the list/scalar and then iterate over it. After I > >call atleast_1d, indexing the list returns object_arrtype. One > >interesting thing is that I have redefined __repr__ for this object, > >and that method seems to be called correctly, but trying to access any > >other property of the object causes messages like "*** AttributeError: > >'object_arrtype' object has no attribute 'dof'". Here is a pdb > >session just before and after atleast_1d is called. Is this a bug or > >should I be doing this differently with new scipy (this code worked > >fine with old scipy). > > > > > I think the object scalars need a little more work. There is a valid > question whether to have them at all. > What these scalars do is unify the methods of scalars and arrays. > Without them, then object arrays would have different selection > semantics then non-object arrays. Perhaps this would be a "good" thing. > > At any rate, you can always get the underlying object the object-scalar > wraps using the toscalar() method. > > I think a very natural thing-to-do, though, which would clear up these > issues and leave the object scalar around is to hand off behavior of > the object to the underlying object in all cases. > > -Travis > > _______________________________________________ > SciPy-user mailing list > SciPy-user at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-user > From oliphant at ee.byu.edu Thu Dec 8 14:01:41 2005 From: oliphant at ee.byu.edu (Travis Oliphant) Date: Thu, 08 Dec 2005 12:01:41 -0700 Subject: [SciPy-user] 'object_arrtype' problem In-Reply-To: References: <43986B42.5000904@ieee.org> Message-ID: <43988315.7090809@ee.byu.edu> Ryan Krauss wrote: >What do you mean by "hand off behavior of the object to the underlying >object in all cases"? > > All arrays return array scalars. This allows us to control the math and the methods of the returned objects. This is very useful for the regular arrays. Object arrays simply inherited that behavior and therefore there is an "object"-array type. (Run type() on one of your returned objects...) In this case, though, the array object contains a pointer to another object (that's the thing that has the methods and attributes you wanted). There is the obvious question as to whether or not having a separate object array-scalar type is even useful, though. It does provide consistency of behavior but I think the expense is too high in this case. Right now, I'm leaning to having OBJECT arrays return the actual object like Numeric did. This will mean, of course that they won't have the array methods and there will be an "except-for object arrays" cluttered throughout documentation, but I think it's a better compromise solution . The change is not difficult and could be done in about 30 minutes. I'd like to hear from people as to what their attitude is: 1) Have object arrays return the actual Python object like Numeric did but different from all other array types which return an "array-scalar" type. 2) Keep the current behavior but soup up the object array type so it "works better". I don't think we could ever make a generic object that can always respond as any other object, though, so there will be minor issues regardless. Let me know. -Travis From ryanlists at gmail.com Thu Dec 8 14:13:50 2005 From: ryanlists at gmail.com (Ryan Krauss) Date: Thu, 8 Dec 2005 14:13:50 -0500 Subject: [SciPy-user] 'object_arrtype' problem In-Reply-To: <43988315.7090809@ee.byu.edu> References: <43986B42.5000904@ieee.org> <43988315.7090809@ee.byu.edu> Message-ID: One thing I don't like about Numeric returning the object is that things get a little messy when you aren't sure if you have an array or not. I find myself calling atleast_1d a lot or writing tests using "if shape(obtject)" which returns an empty tuple for scalars. I guess my thoughts are slightly twisted by everything being an array in Matlab. I want to test if len==1, then it must be a scalar. I guess I would be happiest with clean scalar tests and objects that worked well when iterating or indexing from an object array. Ryan On 12/8/05, Travis Oliphant wrote: > Ryan Krauss wrote: > > >What do you mean by "hand off behavior of the object to the underlying > >object in all cases"? > > > > > > All arrays return array scalars. This allows us to control the math and > the methods of the returned objects. This is very useful for the > regular arrays. Object arrays simply inherited that behavior and > therefore there is an "object"-array type. (Run type() on one of your > returned objects...) In this case, though, the array object contains a > pointer to another object (that's the thing that has the methods and > attributes you wanted). > > There is the obvious question as to whether or not having a separate > object array-scalar type is even useful, though. It does provide > consistency of behavior but I think the expense is too high in this case. > > Right now, I'm leaning to having OBJECT arrays return the actual object > like Numeric did. This will mean, of course that they won't have the > array methods and there will be an "except-for object arrays" cluttered > throughout documentation, but I think it's a better compromise solution . > > The change is not difficult and could be done in about 30 minutes. > > I'd like to hear from people as to what their attitude is: > > 1) Have object arrays return the actual Python object like Numeric did > but different from all other array types which return an "array-scalar" > type. > > 2) Keep the current behavior but soup up the object array type so it > "works better". I don't think we could ever make a generic object that > can always respond as any other object, though, so there will be minor > issues regardless. > > Let me know. > > -Travis > > > _______________________________________________ > SciPy-user mailing list > SciPy-user at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-user > From ryanlists at gmail.com Thu Dec 8 14:37:02 2005 From: ryanlists at gmail.com (Ryan Krauss) Date: Thu, 8 Dec 2005 14:37:02 -0500 Subject: [SciPy-user] weave, new scipy, and ubuntu Message-ID: I am trying to run some code under new scipy that worked under old scipy. I am using weave and I get a very long error message the end of which is: /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/stencils.h:271: error: 'minmax' has not been declared /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/stencils.cc: In function 'void calcStencilExtent(T_extent&, const T_stencil&, const Array&, const T_array2&, const T_array3&, const T_array4&, const T_array5&, const T_array6&, const T_array7&, const T_array8&, const T_array9&, const T_array10&, const T_array11&)': /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/stencils.cc:95: error: expected `;' before 'Bt' /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/stencils.cc:96: error: expected `;' before 'Ct' /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/stencils.cc:97: error: expected `;' before 'Dt' /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/stencils.cc:98: error: expected `;' before 'Et' /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/stencils.cc:99: error: expected `;' before 'Ft' /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/stencils.cc:100: error: expected `;' before 'Gt' /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/stencils.cc:101: error: expected `;' before 'Ht' /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/stencils.cc:102: error: expected `;' before 'It' /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/stencils.cc:103: error: expected `;' before 'Jt' /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/stencils.cc:104: error: expected `;' before 'Kt' /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/stencils.cc:106: error: 'Bt' was not declared in this scope /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/stencils.cc:106: error: 'Ct' was not declared in this scope /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/stencils.cc:106: error: 'Dt' was not declared in this scope /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/stencils.cc:106: error: 'Et' was not declared in this scope /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/stencils.cc:106: error: 'Ft' was not declared in this scope /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/stencils.cc:106: error: 'Gt' was not declared in this scope /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/stencils.cc:106: error: 'Ht' was not declared in this scope /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/stencils.cc:106: error: 'It' was not declared in this scope /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/stencils.cc:106: error: 'Jt' was not declared in this scope /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/stencils.cc:106: error: 'Kt' was not declared in this scope /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/stencils.cc: In function 'void applyStencil_imp(const T_stencil&, Array&, T_array2&, T_array3&, T_array4&, T_array5&, T_array6&, T_array7&, T_array8&, T_array9&, T_array10&, T_array11&)': /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/stencils.cc:222: error: 'minmax' has not been declared /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/stencils.cc:223: error: 'minmax' has not been declared /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/stencils.cc:224: error: 'minmax' has not been declared /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/stencils.cc:226: error: 'minmax' has not been declared /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/stencils.cc:227: error: 'minmax' has not been declared /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/stencils.cc:228: error: 'minmax' has not been declared /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/stencils.cc:239: error: expected `;' before 'Biter' /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/stencils.cc:240: error: expected `;' before 'Citer' /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/stencils.cc:241: error: expected `;' before 'Diter' /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/stencils.cc:242: error: expected `;' before 'Eiter' /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/stencils.cc:243: error: expected `;' before 'Fiter' /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/stencils.cc:244: error: expected `;' before 'Giter' /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/stencils.cc:245: error: expected `;' before 'Hiter' /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/stencils.cc:246: error: expected `;' before 'Iiter' /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/stencils.cc:247: error: expected `;' before 'Jiter' /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/stencils.cc:248: error: expected `;' before 'Kiter' /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/stencils.cc:252: error: 'Biter' was not declared in this scope /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/stencils.cc:253: error: 'Citer' was not declared in this scope /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/stencils.cc:254: error: 'Diter' was not declared in this scope /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/stencils.cc:255: error: 'Eiter' was not declared in this scope /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/stencils.cc:256: error: 'Fiter' was not declared in this scope /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/stencils.cc:257: error: 'Giter' was not declared in this scope /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/stencils.cc:258: error: 'Hiter' was not declared in this scope /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/stencils.cc:259: error: 'Iiter' was not declared in this scope /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/stencils.cc:260: error: 'Jiter' was not declared in this scope /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/stencils.cc:261: error: 'Kiter' was not declared in this scope /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/stencils.cc: In function 'void applyStencil_imp(const T_stencil&, Array&, T_array2&, T_array3&, T_array4&, T_array5&, T_array6&, T_array7&, T_array8&, T_array9&, T_array10&, T_array11&)': /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/stencils.cc:328: error: 'minmax' has not been declared /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/stencils.cc:329: error: 'minmax' has not been declared /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/stencils.cc:331: error: 'minmax' has not been declared /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/stencils.cc:332: error: 'minmax' has not been declared /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/stencils.cc:342: error: expected `;' before 'Biter' /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/stencils.cc:343: error: expected `;' before 'Citer' /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/stencils.cc:344: error: expected `;' before 'Diter' /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/stencils.cc:345: error: expected `;' before 'Eiter' /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/stencils.cc:346: error: expected `;' before 'Fiter' /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/stencils.cc:347: error: expected `;' before 'Giter' /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/stencils.cc:348: error: expected `;' before 'Hiter' /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/stencils.cc:349: error: expected `;' before 'Iiter' /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/stencils.cc:350: error: expected `;' before 'Jiter' /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/stencils.cc:351: error: expected `;' before 'Kiter' /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/stencils.cc:355: error: 'Biter' was not declared in this scope /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/stencils.cc:356: error: 'Citer' was not declared in this scope /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/stencils.cc:357: error: 'Diter' was not declared in this scope /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/stencils.cc:358: error: 'Eiter' was not declared in this scope /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/stencils.cc:359: error: 'Fiter' was not declared in this scope /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/stencils.cc:360: error: 'Giter' was not declared in this scope /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/stencils.cc:361: error: 'Hiter' was not declared in this scope /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/stencils.cc:362: error: 'Iiter' was not declared in this scope /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/stencils.cc:363: error: 'Jiter' was not declared in this scope /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/stencils.cc:364: error: 'Kiter' was not declared in this scope /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/stencils.cc: In function 'void applyStencil_imp(const T_stencil&, Array&, T_array2&, T_array3&, T_array4&, T_array5&, T_array6&, T_array7&, T_array8&, T_array9&, T_array10&, T_array11&)': /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/stencils.cc:425: error: 'minmax' has not been declared /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/stencils.cc:426: error: 'minmax' has not been declared /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/stencils.cc:435: error: expected `;' before 'Biter' /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/stencils.cc:436: error: expected `;' before 'Citer' /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/stencils.cc:437: error: expected `;' before 'Diter' /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/stencils.cc:438: error: expected `;' before 'Eiter' /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/stencils.cc:439: error: expected `;' before 'Fiter' /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/stencils.cc:440: error: expected `;' before 'Giter' /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/stencils.cc:441: error: expected `;' before 'Hiter' /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/stencils.cc:442: error: expected `;' before 'Iiter' /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/stencils.cc:443: error: expected `;' before 'Jiter' /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/stencils.cc:444: error: expected `;' before 'Kiter' /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/stencils.cc:448: error: 'Biter' was not declared in this scope /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/stencils.cc:449: error: 'Citer' was not declared in this scope /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/stencils.cc:450: error: 'Diter' was not declared in this scope /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/stencils.cc:451: error: 'Eiter' was not declared in this scope /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/stencils.cc:452: error: 'Fiter' was not declared in this scope /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/stencils.cc:453: error: 'Giter' was not declared in this scope /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/stencils.cc:454: error: 'Hiter' was not declared in this scope /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/stencils.cc:455: error: 'Iiter' was not declared in this scope /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/stencils.cc:456: error: 'Jiter' was not declared in this scope /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/stencils.cc:457: error: 'Kiter' was not declared in this scope /usr/lib/python2.4/site-packages/scipy/weave/scxx/object.h: At global scope: /usr/lib/python2.4/site-packages/scipy/weave/scxx/object.h:85: error: 'py::object::object(int)' cannot be overloaded /usr/lib/python2.4/site-packages/scipy/weave/scxx/object.h:82: error: with 'py::object::object(int)' /home/ryan/.python24_compiled/sc_01e1613eb6e39ff39d2e56ac7cc755121.cpp:644: error: 'blitz' has not been declared /home/ryan/.python24_compiled/sc_01e1613eb6e39ff39d2e56ac7cc755121.cpp:645: error: 'blitz' has not been declared /home/ryan/.python24_compiled/sc_01e1613eb6e39ff39d2e56ac7cc755121.cpp:646: error: 'blitz' has not been declared /home/ryan/.python24_compiled/sc_01e1613eb6e39ff39d2e56ac7cc755121.cpp:646: error: 'blitz' has not been declared /home/ryan/.python24_compiled/sc_01e1613eb6e39ff39d2e56ac7cc755121.cpp:646: error: no matching function for call to 'all()' /home/ryan/.python24_compiled/sc_01e1613eb6e39ff39d2e56ac7cc755121.cpp:649: error: 'blitz' has not been declared /home/ryan/.python24_compiled/sc_01e1613eb6e39ff39d2e56ac7cc755121.cpp: In function 'Array convert_to_blitz(PyArrayObject*, const char*)': /home/ryan/.python24_compiled/sc_01e1613eb6e39ff39d2e56ac7cc755121.cpp:651: error: 'blitz' has not been declared /home/ryan/.python24_compiled/sc_01e1613eb6e39ff39d2e56ac7cc755121.cpp:652: error: 'blitz' has not been declared /home/ryan/.python24_compiled/sc_01e1613eb6e39ff39d2e56ac7cc755121.cpp:661: error: 'blitz' has not been declared /home/ryan/.python24_compiled/sc_01e1613eb6e39ff39d2e56ac7cc755121.cpp:662: error: 'blitz' has not been declared /home/ryan/.python24_compiled/sc_01e1613eb6e39ff39d2e56ac7cc755121.cpp: At global scope: /home/ryan/.python24_compiled/sc_01e1613eb6e39ff39d2e56ac7cc755121.cpp:666: error: 'blitz' has not been declared /home/ryan/.python24_compiled/sc_01e1613eb6e39ff39d2e56ac7cc755121.cpp: In function 'Array py_to_blitz(PyArrayObject*, const char*)': /home/ryan/.python24_compiled/sc_01e1613eb6e39ff39d2e56ac7cc755121.cpp:669: error: 'blitz' has not been declared /home/ryan/.python24_compiled/sc_01e1613eb6e39ff39d2e56ac7cc755121.cpp:670: error: 'blitz' has not been declared /home/ryan/.python24_compiled/sc_01e1613eb6e39ff39d2e56ac7cc755121.cpp:679: error: 'blitz' has not been declared /home/ryan/.python24_compiled/sc_01e1613eb6e39ff39d2e56ac7cc755121.cpp:680: error: 'blitz' has not been declared /home/ryan/.python24_compiled/sc_01e1613eb6e39ff39d2e56ac7cc755121.cpp: In function 'PyObject* compiled_func(PyObject*, PyObject*)': /home/ryan/.python24_compiled/sc_01e1613eb6e39ff39d2e56ac7cc755121.cpp:706: error: 'blitz' has not been declared /home/ryan/.python24_compiled/sc_01e1613eb6e39ff39d2e56ac7cc755121.cpp:707: error: 'blitz' has not been declared /home/ryan/.python24_compiled/sc_01e1613eb6e39ff39d2e56ac7cc755121.cpp:712: error: 'blitz' has not been declared /home/ryan/.python24_compiled/sc_01e1613eb6e39ff39d2e56ac7cc755121.cpp:713: error: 'blitz' has not been declared /home/ryan/.python24_compiled/sc_01e1613eb6e39ff39d2e56ac7cc755121.cpp:722: error: no match for call to '(py::object) (int&, int&)' /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/storage.h: In constructor 'FortranArray::FortranArray() [with int N_rank = 1]': /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/storage.h:201: instantiated from here /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/storage.h:181: error: expected primary-expression /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/storage.h: In constructor 'FortranArray::FortranArray() [with int N_rank = 2]': /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/storage.h:204: instantiated from here /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/storage.h:181: error: expected primary-expression /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/storage.h: In constructor 'FortranArray::FortranArray() [with int N_rank = 3]': /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/storage.h:207: instantiated from here /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/storage.h:181: error: expected primary-expression /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/storage.h: In constructor 'FortranArray::FortranArray() [with int N_rank = 4]': /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/storage.h:210: instantiated from here /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/storage.h:181: error: expected primary-expression /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/storage.h: In constructor 'FortranArray::FortranArray() [with int N_rank = 5]': /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/storage.h:213: instantiated from here /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/storage.h:181: error: expected primary-expression /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/storage.h: In constructor 'FortranArray::FortranArray() [with int N_rank = 6]': /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/storage.h:216: instantiated from here /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/storage.h:181: error: expected primary-expression /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/storage.h: In constructor 'FortranArray::FortranArray() [with int N_rank = 7]': /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/storage.h:219: instantiated from here /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/storage.h:181: error: expected primary-expression /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/storage.h: In constructor 'FortranArray::FortranArray() [with int N_rank = 8]': /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/storage.h:222: instantiated from here /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/storage.h:181: error: expected primary-expression /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/storage.h: In constructor 'FortranArray::FortranArray() [with int N_rank = 9]': /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/storage.h:225: instantiated from here /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/storage.h:181: error: expected primary-expression /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/storage.h: In constructor 'FortranArray::FortranArray() [with int N_rank = 10]': /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/storage.h:228: instantiated from here /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/storage.h:181: error: expected primary-expression /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/storage.h: In constructor 'FortranArray::FortranArray() [with int N_rank = 11]': /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/storage.h:231: instantiated from here /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/storage.h:181: error: expected primary-expression /usr/include/c++/4.0.2/bits/basic_ios.h: In member function '_CharT std::basic_ios<_CharT, _Traits>::fill() const [with _CharT = char, _Traits = std::char_traits]': /usr/include/c++/4.0.2/bits/ostream.tcc:629: instantiated from 'std::basic_ostream& std::operator<<(std::basic_ostream&, const char*) [with _Traits = std::char_traits]' /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/range.h:173: instantiated from here /usr/include/c++/4.0.2/bits/basic_ios.h:360: error: assignment of data-member 'std::basic_ios >::_M_fill' in read-only structure /usr/include/c++/4.0.2/bits/basic_ios.h:361: error: assignment of data-member 'std::basic_ios >::_M_fill_init' in read-only structure /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/tvecglobs.h: In function 'T_numtype1 product(const TinyVector&) [with T_numtype1 = int, int N_length = 1]': /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array-impl.h:392: instantiated from 'Array::Array(P_numtype*, TinyVector, TinyVector, preexistingMemoryPolicy, GeneralArrayStorage) [with P_numtype = double, int N_rank = 1]' /home/ryan/.python24_compiled/sc_01e1613eb6e39ff39d2e56ac7cc755121.cpp:662: instantiated from 'Array convert_to_blitz(PyArrayObject*, const char*) [with T = double, int N = 1]' /home/ryan/.python24_compiled/sc_01e1613eb6e39ff39d2e56ac7cc755121.cpp:706: instantiated from here /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/tvecglobs.h:68: error: 'f' is not a member of '_bz_meta_vectorProduct<1, 0>' /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/ops.cc: In member function 'Array& Array::operator=(const ETBase&) [with T_expr = _bz_ArrayExpr >, P_numtype = double, int N_rank = 1]': /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/ops.cc:60: instantiated from 'Array& Array::operator=(const Array&) [with P_numtype = double, int N_rank = 1]' /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/methods.cc:271: instantiated from 'Array Array::copy() const [with P_numtype = double, int N_rank = 1]' /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array-impl.h:402: instantiated from 'Array::Array(P_numtype*, TinyVector, TinyVector, preexistingMemoryPolicy, GeneralArrayStorage) [with P_numtype = double, int N_rank = 1]' /home/ryan/.python24_compiled/sc_01e1613eb6e39ff39d2e56ac7cc755121.cpp:662: instantiated from 'Array convert_to_blitz(PyArrayObject*, const char*) [with T = double, int N = 1]' /home/ryan/.python24_compiled/sc_01e1613eb6e39ff39d2e56ac7cc755121.cpp:706: instantiated from here /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/ops.cc:51: error: no type named 'T_numtype' in 'class _bz_ArrayExpr >' /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/tvecglobs.h: In function 'T_numtype1 dot(const TinyVector&, const TinyVector&) [with T_numtype1 = int, T_numtype2 = int, int N_length = 1]': /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array-impl.h:872: instantiated from 'int Array::dataOffset() const [with P_numtype = double, int N_rank = 1]' /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array-impl.h:876: instantiated from 'const P_numtype* Array::data() const [with P_numtype = double, int N_rank = 1]' /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/fastiter.h:70: instantiated from 'FastArrayIterator::FastArrayIterator(const Array&) [with P_numtype = double, int N_rank = 1]' /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array-impl.h:848: instantiated from 'FastArrayIterator Array::beginFast() const [with P_numtype = double, int N_rank = 1]' /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/ops.cc:60: instantiated from 'Array& Array::operator=(const Array&) [with P_numtype = double, int N_rank = 1]' /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array/methods.cc:271: instantiated from 'Array Array::copy() const [with P_numtype = double, int N_rank = 1]' /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/array-impl.h:402: instantiated from 'Array::Array(P_numtype*, TinyVector, TinyVector, preexistingMemoryPolicy, GeneralArrayStorage) [with P_numtype = double, int N_rank = 1]' /home/ryan/.python24_compiled/sc_01e1613eb6e39ff39d2e56ac7cc755121.cpp:662: instantiated from 'Array convert_to_blitz(PyArrayObject*, const char*) [with T = double, int N = 1]' /home/ryan/.python24_compiled/sc_01e1613eb6e39ff39d2e56ac7cc755121.cpp:706: instantiated from here /usr/lib/python2.4/site-packages/scipy/weave/blitz/blitz/tvecglobs.h:47: error: 'f' is not a member of '_bz_meta_vectorDot<1, 0>' --------------------------------------------------------------------------- build_tools.CompileError Traceback (most recent call last) /home/ryan/control_design/fortran_test/fortran_dev.py 71 rwkbode.GenBodePlot(1,freq,mybode1) 72 ---> 73 mybodes=mysystem.BodeResponse(freq) 74 rwkbode.GenBodePlot(1,freq,mybodes[0],clear=False) 75 /home/ryan/rwkpython/TMM/__init__.py in BodeResponse(self, fvect) 1099 elif bodedict.post.lower()=='vel': 1100 tempcomp=tempcomp*svect -> 1101 bodes.append(rwkbode.rwkbode(bodedict.output,bodedict.input,compin=tempcomp)) 1102 return bodes 1103 /home/ryan/rwkpython/rwkbode/__init__.py in __init__(self, output, input, mag, phase, coh, freqlim, maglim, phaselim, averaged, seedfreq, seedphase, labels, legloc, compin) 45 self.mag=colwise(abs(compin)) 46 # self.phase=colwise(mat_atan2(imag(compin),real(compin))*180.0/pi) ---> 47 self.phase=colwise(mat_atan2_c(imag(compin),real(compin))*180.0/pi) 48 else: 49 self.mag=mag /home/ryan/rwkpython/rwkdataproc.py in mat_atan2_c(y, x) 673 type_converters = cblitz, 674 compiler='gcc', --> 675 verbose = 1) 676 return outmat 677 /usr/lib/python2.4/site-packages/scipy/weave/inline_tools.py in inline(code, arg_names, local_dict, global_dict, force, compiler, verbose, support_code, headers, customize, type_converters, auto_downcast, **kw) 332 customize=customize, 333 type_converters = type_converters, --> 334 auto_downcast = auto_downcast, 335 **kw) 336 /usr/lib/python2.4/site-packages/scipy/weave/inline_tools.py in compile_function(code, arg_names, local_dict, global_dict, module_dir, compiler, verbose, support_code, headers, customize, type_converters, auto_downcast, **kw) 440 # setting. All input keywords are passed through to distutils 441 mod.compile(location=storage_dir,compiler=compiler, --> 442 verbose=verbose, **kw) 443 444 # import the module and return the function. Make sure /usr/lib/python2.4/site-packages/scipy/weave/ext_tools.py in compile(self, location, compiler, verbose, **kw) 351 success = build_tools.build_extension(file, temp_dir = temp, 352 compiler_name = compiler, --> 353 verbose = verbose, **kw) 354 if not success: 355 raise SystemError, 'Compilation failed' /usr/lib/python2.4/site-packages/scipy/weave/build_tools.py in build_extension(module_path, compiler_name, build_dir, temp_dir, verbose, **kw) 272 environ = copy.deepcopy(os.environ) 273 try: --> 274 setup(name = module_name, ext_modules = [ext],verbose=verb) 275 finally: 276 # restore state /usr/lib/python2.4/site-packages/scipy/distutils/core.py in setup(**attr) 91 new_attr['data_files'] = new_data_files 92 ---> 93 return old_setup(**new_attr) 94 95 def _check_append_library(libraries, item): /usr/lib/python2.4/distutils/core.py in setup(**attrs) 164 raise 165 else: --> 166 raise SystemExit, "error: " + str(msg) 167 168 return dist CompileError: error: Command "g++ -pthread -fno-strict-aliasing -DNDEBUG -g -O3 -Wstrict-prototypes -fPIC -I/usr/lib/python2.4/site-packages/scipy/weave -I/usr/lib/python2.4/site-packages/scipy/weave/scxx -I/usr/lib/python2.4/site-packages/scipy/weave/blitz -I/usr/lib/python2.4/site-packages/scipy/base/include -I/usr/include/python2.4 -c /home/ryan/.python24_compiled/sc_01e1613eb6e39ff39d2e56ac7cc755121.cpp -o /tmp/ryan/python24_intermediate/compiler_fcf4821de2ee87a8ad4d6579aeaebbc9/home/ryan/.python24_compiled/sc_01e1613eb6e39ff39d2e56ac7cc755121.o" failed with exit status 1 WARNING: Failure executing file: In [19]: What should I do? Ryan From ryanlists at gmail.com Thu Dec 8 14:43:51 2005 From: ryanlists at gmail.com (Ryan Krauss) Date: Thu, 8 Dec 2005 14:43:51 -0500 Subject: [SciPy-user] weave, new scipy, and ubuntu In-Reply-To: References: Message-ID: I replaced what was in scipy/weave/blitz/blitz with the latest blitz download and my error message got a lot shorter. Here it is now: In [19]: run fortran_dev.py Compiling code... cc1plus: warning: command line option "-Wstrict-prototypes" is valid for Ada/C/ObjC but not for C++ /home/ryan/.python24_compiled/sc_01e1613eb6e39ff39d2e56ac7cc755122.cpp: In function 'PyObject* compiled_func(PyObject*, PyObject*)': /home/ryan/.python24_compiled/sc_01e1613eb6e39ff39d2e56ac7cc755122.cpp:722: error: no match for call to '(py::object) (int&, int&)' cc1plus: warning: command line option "-Wstrict-prototypes" is valid for Ada/C/ObjC but not for C++ /home/ryan/.python24_compiled/sc_01e1613eb6e39ff39d2e56ac7cc755122.cpp: In function 'PyObject* compiled_func(PyObject*, PyObject*)': /home/ryan/.python24_compiled/sc_01e1613eb6e39ff39d2e56ac7cc755122.cpp:722: error: no match for call to '(py::object) (int&, int&)' --------------------------------------------------------------------------- build_tools.CompileError Traceback (most recent call last) /home/ryan/control_design/fortran_test/fortran_dev.py 71 rwkbode.GenBodePlot(1,freq,mybode1) 72 ---> 73 mybodes=mysystem.BodeResponse(freq) 74 rwkbode.GenBodePlot(1,freq,mybodes[0],clear=False) 75 /home/ryan/rwkpython/TMM/__init__.py in BodeResponse(self, fvect) 1099 elif bodedict.post.lower()=='vel': 1100 tempcomp=tempcomp*svect -> 1101 bodes.append(rwkbode.rwkbode(bodedict.output,bodedict.input,compin=tempcomp)) 1102 return bodes 1103 /home/ryan/rwkpython/rwkbode/__init__.py in __init__(self, output, input, mag, phase, coh, freqlim, maglim, phaselim, averaged, seedfreq, seedphase, labels, legloc, compin) 45 self.mag=colwise(abs(compin)) 46 # self.phase=colwise(mat_atan2(imag(compin),real(compin))*180.0/pi) ---> 47 self.phase=colwise(mat_atan2_c(imag(compin),real(compin))*180.0/pi) 48 else: 49 self.mag=mag /home/ryan/rwkpython/rwkdataproc.py in mat_atan2_c(y, x) 673 type_converters = cblitz, 674 compiler='gcc', --> 675 verbose = 1) 676 return outmat 677 /usr/lib/python2.4/site-packages/scipy/weave/inline_tools.py in inline(code, arg_names, local_dict, global_dict, force, compiler, verbose, support_code, headers, customize, type_converters, auto_downcast, **kw) 332 customize=customize, 333 type_converters = type_converters, --> 334 auto_downcast = auto_downcast, 335 **kw) 336 /usr/lib/python2.4/site-packages/scipy/weave/inline_tools.py in compile_function(code, arg_names, local_dict, global_dict, module_dir, compiler, verbose, support_code, headers, customize, type_converters, auto_downcast, **kw) 440 # setting. All input keywords are passed through to distutils 441 mod.compile(location=storage_dir,compiler=compiler, --> 442 verbose=verbose, **kw) 443 444 # import the module and return the function. Make sure /usr/lib/python2.4/site-packages/scipy/weave/ext_tools.py in compile(self, location, compiler, verbose, **kw) 351 success = build_tools.build_extension(file, temp_dir = temp, 352 compiler_name = compiler, --> 353 verbose = verbose, **kw) 354 if not success: 355 raise SystemError, 'Compilation failed' /usr/lib/python2.4/site-packages/scipy/weave/build_tools.py in build_extension(module_path, compiler_name, build_dir, temp_dir, verbose, **kw) 272 environ = copy.deepcopy(os.environ) 273 try: --> 274 setup(name = module_name, ext_modules = [ext],verbose=verb) 275 finally: 276 # restore state /usr/lib/python2.4/site-packages/scipy/distutils/core.py in setup(**attr) 91 new_attr['data_files'] = new_data_files 92 ---> 93 return old_setup(**new_attr) 94 95 def _check_append_library(libraries, item): /usr/lib/python2.4/distutils/core.py in setup(**attrs) 164 raise 165 else: --> 166 raise SystemExit, "error: " + str(msg) 167 168 return dist CompileError: error: Command "g++ -pthread -fno-strict-aliasing -DNDEBUG -g -O3 -Wstrict-prototypes -fPIC -I/usr/lib/python2.4/site-packages/scipy/weave -I/usr/lib/python2.4/site-packages/scipy/weave/scxx -I/usr/lib/python2.4/site-packages/scipy/weave/blitz -I/usr/lib/python2.4/site-packages/scipy/base/include -I/usr/include/python2.4 -c /home/ryan/.python24_compiled/sc_01e1613eb6e39ff39d2e56ac7cc755122.cpp -o /tmp/ryan/python24_intermediate/compiler_fcf4821de2ee87a8ad4d6579aeaebbc9/home/ryan/.python24_compiled/sc_01e1613eb6e39ff39d2e56ac7cc755122.o" failed with exit status 1 WARNING: Failure executing file: In [20]: From cookedm at physics.mcmaster.ca Thu Dec 8 17:14:23 2005 From: cookedm at physics.mcmaster.ca (David M. Cooke) Date: Thu, 08 Dec 2005 17:14:23 -0500 Subject: [SciPy-user] weave, new scipy, and ubuntu In-Reply-To: (Ryan Krauss's message of "Thu, 8 Dec 2005 14:43:51 -0500") References: Message-ID: Ryan Krauss writes: > I replaced what was in scipy/weave/blitz/blitz with the latest blitz > download and my error message got a lot shorter. Here it is now: You're using 0.4.3, right? The version in subversion also has the latest blitz (up to about a month ago). What does your actual code that weave is wrapping looking like? -- |>|\/|< /--------------------------------------------------------------------------\ |David M. Cooke http://arbutus.physics.mcmaster.ca/dmc/ |cookedm at physics.mcmaster.ca From fonnesbeck at gmail.com Thu Dec 8 19:47:47 2005 From: fonnesbeck at gmail.com (Chris Fonnesbeck) Date: Thu, 8 Dec 2005 19:47:47 -0500 Subject: [SciPy-user] scipy.random problem Message-ID: <723eb6930512081647u4e385eb3l6ba80f6cb49139e@mail.gmail.com> Having just now updated from svn, I run into the following problem importing scipy.random: In [1]: from scipy import random Importing test to scipy Importing base to scipy Importing basic to scipy Failed to import basic scipy.ArrayType does not appear to be the correct type object --------------------------------------------------------------------------- exceptions.ImportError Traceback (most recent call last) /Users/chris/ ImportError: cannot import name random -- Chris Fonnesbeck Atlanta, GA From dd55 at cornell.edu Thu Dec 8 20:07:17 2005 From: dd55 at cornell.edu (Darren Dale) Date: Thu, 8 Dec 2005 20:07:17 -0500 Subject: [SciPy-user] scipy.random problem In-Reply-To: <723eb6930512081647u4e385eb3l6ba80f6cb49139e@mail.gmail.com> References: <723eb6930512081647u4e385eb3l6ba80f6cb49139e@mail.gmail.com> Message-ID: <200512082007.17919.dd55@cornell.edu> On Thursday 08 December 2005 7:47 pm, Chris Fonnesbeck wrote: > Having just now updated from svn, I run into the following problem > importing scipy.random: > > In [1]: from scipy import random > Importing test to scipy > Importing base to scipy > Importing basic to scipy > Failed to import basic > scipy.ArrayType does not appear to be the correct type object > --------------------------------------------------------------------------- > exceptions.ImportError Traceback (most > recent call last) > > /Users/chris/ > > ImportError: cannot import name random I just updated myself, and found no problems. Did you remember to delete your old build/ and site-packages/scipy directories? From abe.katsumi at jp.fujitsu.com Thu Dec 8 20:33:17 2005 From: abe.katsumi at jp.fujitsu.com (ABE Katsumi) Date: Fri, 09 Dec 2005 10:33:17 +0900 Subject: [SciPy-user] bit shift of a single byte iinteger In-Reply-To: <43986B76.7030103@att.net> References: <43986B76.7030103@att.net> Message-ID: Thanks you, Bill. At first, I should have asked whether I could use a 1byte integer in python. If yes, could anyone tell me how can a 1byte integer be defined? Thanks, Katsumi On Fri, 09 Dec 2005 02:20:54 +0900, Bill Dandreta wrote: > ABE Katsumi wrote: > >> Hi all, >> >> Is there any function to shift bit of a single byte integer? >> >> Thanks you for your help, >> >> Katsumi >> >> _______________________________________________ >> SciPy-user mailing list >> SciPy-user at scipy.net >> http://www.scipy.net/mailman/listinfo/scipy-user >> >> >> > http://www.python.org/doc/2.2.3/lib/bitstring-ops.html > > Bill > > _______________________________________________ > SciPy-user mailing list > SciPy-user at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-user From oliphant.travis at ieee.org Fri Dec 9 05:14:49 2005 From: oliphant.travis at ieee.org (Travis Oliphant) Date: Fri, 09 Dec 2005 03:14:49 -0700 Subject: [SciPy-user] Benchmark data Message-ID: <43995919.2090401@ieee.org> I'd like people to try out scipy core in SVN. I made improvements to the buffered ufunc section of code that I think will make a big difference in the recently published benchmarks. Here are some results that I get now (I've got a debug build with no optimizations). Optimization flags: -g -Wall -Wstrict-prototypes CPU info: getNCPUs has_3dnow has_3dnowext has_mmx is_32bit is_AMD is_singleCPU Numeric-24.2 numarray-1.5.1 scipy-core-0.8.1.1614 benchmark size = 4 (vectors of length 256) label Numeric numarray scipy.base 1 0.0001121 0.002115 9.108e-05 2 0.0001349 0.0008631 0.000133 3 7.105e-05 0.000989 8.202e-05 4 0.0001509 0.003712 0.0001481 5 6.39e-05 0.04328 6.986e-05 6 6.008e-05 5.412e-05 9.012e-05 7 0.0001211 0.0003929 0.000129 8 4.292e-05 0.000118 3.004e-05 9 0.0005081 0.00541 0.0006039 10 0.0004249 0.0006261 0.00056 11 0.000329 0.000932 0.000422 TOTAL 0.002019 0.0585 0.002359 Optimization flags: -g -Wall -Wstrict-prototypes CPU info: getNCPUs has_3dnow has_3dnowext has_mmx is_32bit is_AMD is_singleCPU Numeric-24.2 numarray-1.5.1 scipy-core-0.8.1.1614 benchmark size = 6 (vectors of length 4096) label Numeric numarray scipy.base 1 0.000401 0.002003 0.0003419 2 0.0003641 0.001114 0.0004022 3 0.000263 0.001245 0.000315 4 0.0005591 0.004512 0.000577 5 0.000298 0.001587 0.000283 6 0.000268 0.000284 0.0002999 7 0.000464 0.000725 0.0004301 8 0.0002861 0.000536 0.0001659 9 0.004739 0.0104 0.004864 10 0.04717 0.004666 0.004523 11 0.003594 0.004486 0.003582 TOTAL 0.0584 0.03156 0.01578 Optimization flags: -g -Wall -Wstrict-prototypes CPU info: getNCPUs has_3dnow has_3dnowext has_mmx is_32bit is_AMD is_singleCPU Numeric-24.2 numarray-1.5.1 scipy-core-0.8.1.1614 benchmark size = 11 (vectors of length 4194304) label Numeric numarray scipy.base 1 0.414 0.231 0.3357 2 0.3932 0.509 0.4095 3 0.2833 0.3737 0.3759 4 1.157 1.118 0.6301 5 0.4359 0.4895 0.3693 6 0.2868 0.3933 0.3205 7 1.211 1.354 0.6187 8 0.7242 0.8617 0.4587 9 8.506 12.46 7.865 10 9.726 13.13 6.891 11 7.518 10.44 8.416 TOTAL 30.66 41.35 26.69 I think these benchmarks are showing that scipy base is at least doing better than it was -Travis From basvandijk at home.nl Fri Dec 9 05:31:43 2005 From: basvandijk at home.nl (Bas van Dijk) Date: Fri, 9 Dec 2005 11:31:43 +0100 Subject: [SciPy-user] scipy 0.4.3, gnuplot and wxPython In-Reply-To: References: <1134055230.43984f3e2e8ee@imp3-g19.free.fr> Message-ID: <200512091131.43983.basvandijk@home.nl> You could also check out Chaco: http://code.enthought.com/chaco/ Bas van Dijk. On Thursday 08 December 2005 16:46, Alan G Isaac wrote: > On Thu, 08 Dec 2005, jaonary at free.fr apparently wrote: > > I'm trying to use scipy to do some 2d graphics plotting. > > The right answer will be to use SciPy and Matplotlib. > I think Matplotlib already talks to the new SciPy core, > but I'm not positive (since I still use Numeric for > Matplotlib numerics). See > http://aspn.activestate.com/ASPN/Mail/Message/scipy-user/2923861 > > hth, > Alan Isaac > > > > _______________________________________________ > SciPy-user mailing list > SciPy-user at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-user From ted.horst at earthlink.net Fri Dec 9 09:10:24 2005 From: ted.horst at earthlink.net (Ted Horst) Date: Fri, 9 Dec 2005 08:10:24 -0600 Subject: [SciPy-user] Benchmark data In-Reply-To: <43995919.2090401@ieee.org> References: <43995919.2090401@ieee.org> Message-ID: <6e4d83f513c6d360eac23b9be36968d5@earthlink.net> Excellent work. Thanks. On Dec 9, 2005, at 04:14, Travis Oliphant wrote: > I'd like people to try out scipy core in SVN. I made improvements to > the > buffered ufunc section of code that I think will make a big difference > in the recently published benchmarks. From msomers at mail.ie Fri Dec 9 09:52:52 2005 From: msomers at mail.ie (Martin Somers) Date: Fri, 9 Dec 2005 06:52:52 -0800 (PST) Subject: [SciPy-user] scipy cant see gplt Message-ID: <20051209065253.FBF3BA7C@dm21.mta.everyone.net> An HTML attachment was scrubbed... URL: From aisaac at american.edu Fri Dec 9 10:43:34 2005 From: aisaac at american.edu (Alan G Isaac) Date: Fri, 9 Dec 2005 10:43:34 -0500 Subject: [SciPy-user] scipy cant see gplt In-Reply-To: <20051209065253.FBF3BA7C@dm21.mta.everyone.net> References: <20051209065253.FBF3BA7C@dm21.mta.everyone.net> Message-ID: On Fri, 9 Dec 2005, Martin Somers apparently wrote: [HTML only message.] http://www.american.edu/econ/notes/htmlmail.htm http://www.harley.com/turn-off-html/ hth, Alan Isaac From arnd.baecker at web.de Fri Dec 9 11:40:27 2005 From: arnd.baecker at web.de (Arnd Baecker) Date: Fri, 9 Dec 2005 17:40:27 +0100 (CET) Subject: [SciPy-user] Benchmark data In-Reply-To: <43995919.2090401@ieee.org> References: <43995919.2090401@ieee.org> Message-ID: Hi Travis, On Fri, 9 Dec 2005, Travis Oliphant wrote: > > I'd like people to try out scipy core in SVN. I made improvements to the > buffered ufunc section of code that I think will make a big difference > in the recently published benchmarks. That sounds great! Excellent reason to start the 100th build on the Opteron... Hmm, things don't look fully satisfactory: scipy.test(10,10): Multi-dimensional Fast Fourier Transform =================================================== | real input | complex input --------------------------------------------------- size | scipy | Numeric | scipy | Numeric --------------------------------------------------- 100x100Segmentation fault And for bench.py sizes 4 and 6 work out fine, but python bench.py 11 Python 2.4.2 (#1, Oct 4 2005, 10:10:47) [GCC 3.4.4] Optimization flags: -DNDEBUG -g -O3 -Wall -Wstrict-prototypes CPU info: getNCPUs=2 has_3dnow has_3dnowext has_mmx has_sse has_sse2 is_64bit is_AMD is_Opteron Numeric-24.0b2 scipy-core-0.8.1.1616 benchmark size = 11 (vectors of length 4194304) Segmentation fault gdb Backtrace: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 46912507335168 (LWP 2911)] DOUBLE_multiply (args=0xb10650, dimensions=0x7fffff8343dc, steps=0x2aaabad07e00, func=0x2aaabcd30000) at umathmodule.c:2414 2414 *((double *)op)=*((double *)i1) * *((double *)i2); (gdb) bt #0 DOUBLE_multiply (args=0xb10650, dimensions=0x7fffff8343dc, steps=0x2aaabad07e00, func=0x2aaabcd30000) at umathmodule.c:2414 #1 0x00002aaaac9eb1fd in PyUFunc_GenericFunction (self=0x6840e0, args=0x2aaab6cc0d40, mps=0x2) at ufuncobject.c:1569 #2 0x00002aaaac9edc69 in ufunc_generic_call (self=0x6840e0, args=0x2aaab6cc0d40) at ufuncobject.c:2553 #3 0x0000000000417808 in PyObject_CallFunction (callable=0x6840e0, format=0x6ffdafffffff52
) at abstract.c:1756 #4 0x00002aaaac890937 in array_multiply (m1=0x6ffdafffffff52, m2=0x7fffff8343dc) at arrayobject.c:2261 #5 0x00000000004145ec in binary_op1 (v=0xaf4030, w=0x813a70, op_slot=16) at abstract.c:377 #6 0x00000000004153f8 in PyNumber_Multiply (v=0xaf4030, w=0x813a70) at abstract.c:672 #7 0x0000000000474ffc in PyEval_EvalFrame (f=0x87ec40) at ceval.c:1049 #8 0x0000000000479fb1 in PyEval_EvalFrame (f=0x6861d0) at ceval.c:3640 #9 0x000000000047ad2f in PyEval_EvalCodeEx (co=0x2aaaaab24490, globals=0x7fffff8343dc, locals=0x2aaabad07e00, args=0x6861d0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at ceval.c:2736 #10 0x000000000047af72 in PyEval_EvalCode (co=0xb10650, globals=0x7fffff8343dc, locals=0x2aaabad07e00) at ceval.c:484 #11 0x00000000004a0eeb in PyRun_FileExFlags (fp=0x62f010, filename=0x7fffff835ff8 "bench.py", start=-1160741376, globals=0x6309b0, locals=0x6309b0, closeit=1, flags=0x2aaaaab24490) at pythonrun.c:1265 #12 0x00000000004a188f in PyRun_SimpleFileExFlags (fp=0x62f010, filename=0x7fffff835ff8 "bench.py", closeit=1, flags=0x7fffff835a2c) at pythonrun.c:860 #13 0x0000000000410788 in Py_Main (argc=-8167432, argv=0x0) at main.c:484 #14 0x00002aaaab34d5aa in __libc_start_main () from /lib64/tls/libc.so.6 #15 0x000000000040fdfa in _start () at start.S:113 #16 0x00007fffff835b28 in ?? () #17 0x00002aaaaabc19c0 in rtld_errno () from /lib64/ld-linux-x86-64.so.2 Best, Arnd From managan at llnl.gov Fri Dec 9 13:24:18 2005 From: managan at llnl.gov (Rob Managan) Date: Fri, 9 Dec 2005 10:24:18 -0800 Subject: [SciPy-user] FFT troubles Message-ID: I am wondering if anyone can help me figure out where my FFts are going bad with the latest svn version of scipy. This has been going on for a few weeks. Mac OSX 10.3.9, python 2.4.1 I have fftw-2.1.5 installed and 'make check' reports no problems. >>> from scipy.fftpack import fft,ifft Importing test to scipy ... Importing stats to scipy >>> from scipy.base import arange, sin, cos, pi >>> n=16 >>> x = arange(n)*2*pi/n >>> cx = cos(x) >>> sx = sin(x) >>> print 'sx',sx sx [ 0.00000000e+00 3.82683432e-01 7.07106781e-01 9.23879533e-01 1.00000000e+00 9.23879533e-01 7.07106781e-01 3.82683432e-01 1.22464680e-16 -3.82683432e-01 -7.07106781e-01 -9.23879533e-01 -1.00000000e+00 -9.23879533e-01 -7.07106781e-01 -3.82683432e-01] >>> sfx = fft(sx) >>> print 'sfx=fft(sx)',sfx sfx=fft(sx) [ 1.77975831e-16 +0.00000000e+00j -1.35945820e-15 -8.00000000e+00j -3.87815369e-16 -8.43346956e-16j 5.48376387e-17 -5.45964141e-16j 1.14423775e-17 -4.99600361e-16j 4.98926849e-16 -5.45964141e-16j 6.32744729e-16 -1.77213142e-16j 3.15834992e-16 +0.00000000e+00j 2.88998134e-16 +0.00000000e+00j 3.15834992e-16 -0.00000000e+00j 6.32744729e-16 +1.77213142e-16j 4.98926849e-16 +5.45964141e-16j 1.14423775e-17 +4.99600361e-16j 5.48376387e-17 +5.45964141e-16j -3.87815369e-16 +8.43346956e-16j -1.35945820e-15 +8.00000000e+00j] >>> sfix = ifft(sfx) >>> print 'ifft(sfx)',sfix ifft(sfx) [ 0.00000000e+00 +0.00000000e+00j -3.11858849e-16 -3.26510369e-33j -1.13434883e-16 +0.00000000e+00j 5.44139747e-17 -2.17540312e-32j 0.00000000e+00 -0.00000000e+00j 1.12119479e-16 -2.89787214e-33j 1.68946034e-16 -0.00000000e+00j 1.17569819e-16 +1.55910553e-32j 1.22464680e-16 +0.00000000e+00j 1.17569819e-16 -1.55910553e-32j 1.68946034e-16 +0.00000000e+00j 1.12119479e-16 +2.89787214e-33j 0.00000000e+00 +0.00000000e+00j 5.44139747e-17 +2.17540312e-32j -1.13434883e-16 -0.00000000e+00j -3.11858849e-16 +3.26510369e-33j] >>> Basically ifft(fft(sin(x))) != sin(x), instead it is 0 to round off. But ifft(fft(cos(x))) == cos(x) Why does one fail and the other not! The only difference is that fft(cos(x)) is a real valued result and fft(sin(x)) is imaginary. -- *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*- Rob Managan email managan at llnl.gov LLNL phone: 925-423-0903 P.O. Box 808, L-095 FAX: 925-422-3389 Livermore, CA 94551-0808 From gerard.vermeulen at grenoble.cnrs.fr Fri Dec 9 14:15:10 2005 From: gerard.vermeulen at grenoble.cnrs.fr (Gerard Vermeulen) Date: Fri, 9 Dec 2005 20:15:10 +0100 Subject: [SciPy-user] Benchmark data In-Reply-To: <43995919.2090401@ieee.org> References: <43995919.2090401@ieee.org> Message-ID: <20051209201510.04c352d6.gerard.vermeulen@grenoble.cnrs.fr> On Fri, 09 Dec 2005 03:14:49 -0700 Travis Oliphant wrote: > > I'd like people to try out scipy core in SVN. I made improvements to the > buffered ufunc section of code that I think will make a big difference > in the recently published benchmarks. > Hi Travis, indeed, it made a big difference (for big arrays scipy is now fastest on some statements). Below are my benchmark results on my DIY python, see http://www.scipy.org/mailinglists/mailman?fn=scipy-user/2005-December/006057.html On my system and for large arrays (>4096), numarray is still fastest, scipy moved to second and Numeric is third. Numeric is still fastest for small arrays, scipy is second, numarray is third. Invoking: python bench.py 4 Importing test to scipy Importing base to scipy Importing basic to scipy Python 2.4.2 (#1, Dec 4 2005, 08:21:04) [GCC 3.4.3 (Mandrakelinux 10.2 3.4.3-7mdk)] Optimization flags: -DNDEBUG -O3 -march=i686 CPU info: getNCPUs=2 has_mmx has_sse has_sse2 is_32bit is_Intel is_Pentium is_PentiumIV Numeric-24.2 numarray-1.5.0 scipy-core-0.8.1.1617 benchmark size = 4 (vectors of length 256) label Numeric numarray scipy.base 1 3.409e-05 0.000396 2.789e-05 2 3.6e-05 0.000222 4.816e-05 3 1.788e-05 0.000139 2.885e-05 4 4.101e-05 0.0004969 5.412e-05 5 1.788e-05 0.000155 2.098e-05 6 1.717e-05 1.216e-05 2.289e-05 7 3.195e-05 4.601e-05 3.815e-05 8 1.907e-05 2.694e-05 1.097e-05 9 0.0001988 0.000942 0.0002038 10 0.0001671 0.0001969 0.0001872 11 0.00014 0.0002701 0.00015 TOTAL 0.000721 0.002903 0.000793 Invoking: python bench.py 6 Importing test to scipy Importing base to scipy Importing basic to scipy Python 2.4.2 (#1, Dec 4 2005, 08:21:04) [GCC 3.4.3 (Mandrakelinux 10.2 3.4.3-7mdk)] Optimization flags: -DNDEBUG -O3 -march=i686 CPU info: getNCPUs=2 has_mmx has_sse has_sse2 is_32bit is_Intel is_Pentium is_PentiumIV Numeric-24.2 numarray-1.5.0 scipy-core-0.8.1.1617 benchmark size = 6 (vectors of length 4096) label Numeric numarray scipy.base 1 0.000123 0.0004458 0.0001051 2 9.203e-05 0.0002661 0.0001059 3 6.199e-05 0.00018 8.893e-05 4 0.0001678 0.0006211 0.0001152 5 6.819e-05 0.000191 7.105e-05 6 6.08e-05 4.983e-05 7.987e-05 7 0.0001342 0.0001352 0.0001001 8 0.0001109 0.0001199 1.979e-05 9 0.001745 0.002324 0.001549 10 0.001534 0.001451 0.001552 11 0.001405 0.001292 0.001266 TOTAL 0.005503 0.007076 0.005053 Invoking: python bench.py 8 Importing test to scipy Importing base to scipy Importing basic to scipy Python 2.4.2 (#1, Dec 4 2005, 08:21:04) [GCC 3.4.3 (Mandrakelinux 10.2 3.4.3-7mdk)] Optimization flags: -DNDEBUG -O3 -march=i686 CPU info: getNCPUs=2 has_mmx has_sse has_sse2 is_32bit is_Intel is_Pentium is_PentiumIV Numeric-24.2 numarray-1.5.0 scipy-core-0.8.1.1617 benchmark size = 8 (vectors of length 65536) label Numeric numarray scipy.base 1 0.001536 0.0007961 0.001513 2 0.001063 0.001127 0.001285 3 0.0007641 0.000819 0.001243 4 0.003158 0.002709 0.002409 5 0.001164 0.001175 0.001096 6 0.000771 0.0007038 0.001053 7 0.003375 0.002502 0.00241 8 0.002131 0.001722 0.001514 9 0.03727 0.03172 0.03533 10 0.03748 0.03162 0.03519 11 0.03099 0.02525 0.02958 TOTAL 0.1197 0.1001 0.1126 Invoking: python bench.py 10 Importing test to scipy Importing base to scipy Importing basic to scipy Python 2.4.2 (#1, Dec 4 2005, 08:21:04) [GCC 3.4.3 (Mandrakelinux 10.2 3.4.3-7mdk)] Optimization flags: -DNDEBUG -O3 -march=i686 CPU info: getNCPUs=2 has_mmx has_sse has_sse2 is_32bit is_Intel is_Pentium is_PentiumIV Numeric-24.2 numarray-1.5.0 scipy-core-0.8.1.1617 benchmark size = 10 (vectors of length 1048576) label Numeric numarray scipy.base 1 0.02502 0.004906 0.02432 2 0.01714 0.01492 0.02012 3 0.0122 0.01107 0.01653 4 0.05523 0.03407 0.03489 5 0.01836 0.01492 0.01676 6 0.01232 0.01078 0.01649 7 0.05579 0.039 0.03481 8 0.04067 0.02778 0.02765 9 0.6151 0.4927 0.5701 10 0.6023 0.5226 0.5684 11 0.5072 0.4021 0.4677 TOTAL 1.961 1.575 1.798 Invoking: python bench.py 12 Importing test to scipy Importing base to scipy Importing basic to scipy Python 2.4.2 (#1, Dec 4 2005, 08:21:04) [GCC 3.4.3 (Mandrakelinux 10.2 3.4.3-7mdk)] Optimization flags: -DNDEBUG -O3 -march=i686 CPU info: getNCPUs=2 has_mmx has_sse has_sse2 is_32bit is_Intel is_Pentium is_PentiumIV Numeric-24.2 numarray-1.5.0 scipy-core-0.8.1.1617 benchmark size = 12 (vectors of length 16777216) label Numeric numarray scipy.base 1 0.4127 0.07423 0.3927 2 0.2734 0.2321 0.3234 3 0.1975 0.1821 0.2733 4 0.8747 0.5371 0.5588 5 0.2896 0.2342 0.2737 6 0.2066 0.1731 0.2718 7 0.8761 0.6286 0.5524 8 0.6546 0.4556 0.4533 9 9.488 7.566 8.717 10 9.506 8.064 8.745 11 7.879 6.301 7.305 TOTAL 30.66 24.45 27.87 Thanks, but there is still room for improvement :-) Gerard From ryanlists at gmail.com Fri Dec 9 14:27:20 2005 From: ryanlists at gmail.com (Ryan Krauss) Date: Fri, 9 Dec 2005 14:27:20 -0500 Subject: [SciPy-user] f2py complex number problem Message-ID: I am trying to learn f2py and am running into a problem. I need to take the sin, cos, sinh, and cosh of complex numbers. My FORTRAN is quite rusty but this isn't working: subroutine test(s,out) double complex s, out Cf2py intent(in) s Cf2py intent(out) out out=cos(s)-cosh(s)+sin(s)-sinh(s) END f2py output ends with: test.f: In subroutine `test': test.f:5: out=cos(s)-cosh(s)+sin(s)-sinh(s) ^ Reference to intrinsic `COSH' at (^) invalid -- one or more arguments have incorrect type test.f:5: out=cos(s)-cosh(s)+sin(s)-sinh(s) ^ Reference to intrinsic `SINH' at (^) invalid -- one or more arguments have incorrect type test.f: In subroutine `test': test.f:5: out=cos(s)-cosh(s)+sin(s)-sinh(s) ^ Reference to intrinsic `COSH' at (^) invalid -- one or more arguments have incorrect type test.f:5: out=cos(s)-cosh(s)+sin(s)-sinh(s) ^ Reference to intrinsic `SINH' at (^) invalid -- one or more arguments have incorrect type error: Command "/usr/bin/g77 -Wall -fno-second-underscore -fPIC -O3 -funroll-loops -march=pentium4 -mmmx -msse2 -msse -malign-double -fomit-frame-pointer -I/usr/include/python2.4 -I/tmp/tmppPluVK/src -I/usr/include/python2.4 -c -c test.f -o /tmp/tmppPluVK/test.o" failed with exit status 1 What do I need to do differently? Ryan From pajer at iname.com Fri Dec 9 14:33:04 2005 From: pajer at iname.com (Gary) Date: Fri, 09 Dec 2005 14:33:04 -0500 Subject: [SciPy-user] FFT troubles In-Reply-To: References: Message-ID: <4399DBF0.4070004@iname.com> Rob Managan wrote: >I am wondering if anyone can help me figure out where my FFts are >going bad with the latest svn version of scipy. This has been going >on for a few weeks. >Mac OSX 10.3.9, python 2.4.1 > >I have fftw-2.1.5 installed and 'make check' reports no problems. > > WinXP, python 2.3, binary installed scipy_core and scipy: I keep looking for a mistake in your code, but I don't see one. (Looks like you found a bug??) In [87]: n=16 In [88]: x=arange(n)*2*pi/n In [89]: sx=sin(x) In [90]: sfx = fft(sx) In [91]: ifft(sfx) Out[91]: array([ 0.00000000e+00 +0.00000000e+00j, 3.82683432e-01 +0.00000000e+00j, 7.07106781e-01 -5.55111512e-17j, 9.23879533e-01 -8.32667268e-17j, 1.00000000e+00 +0.00000000e+00j, 9.23879533e-01 -2.77555756e-17j, 7.07106781e-01 -5.55111512e-17j, 3.82683432e-01 -5.55111512e-17j, 1.22460635e-16 +0.00000000e+00j, -3.82683432e-01 +0.00000000e+00j, -7.07106781e-01 +5.55111512e-17j, -9.23879533e-01 +8.32667268e-17j, -1.00000000e+00 +0.00000000e+00j, -9.23879533e-01 +2.77555756e-17j, -7.07106781e-01 +5.55111512e-17j, -3.82683432e-01 +5.55111512e-17j]) > > >>>> from scipy.fftpack import fft,ifft >>>> >>>> >Importing test to scipy >... >Importing stats to scipy > > >>>> from scipy.base import arange, sin, cos, pi >>>> n=16 >>>> x = arange(n)*2*pi/n >>>> cx = cos(x) >>>> sx = sin(x) >>>> print 'sx',sx >>>> >>>> >sx [ 0.00000000e+00 3.82683432e-01 7.07106781e-01 9.23879533e-01 > 1.00000000e+00 9.23879533e-01 7.07106781e-01 3.82683432e-01 > 1.22464680e-16 -3.82683432e-01 -7.07106781e-01 -9.23879533e-01 > -1.00000000e+00 -9.23879533e-01 -7.07106781e-01 -3.82683432e-01] > > >>>> sfx = fft(sx) >>>> print 'sfx=fft(sx)',sfx >>>> >>>> >sfx=fft(sx) [ 1.77975831e-16 +0.00000000e+00j -1.35945820e-15 >-8.00000000e+00j > -3.87815369e-16 -8.43346956e-16j 5.48376387e-17 -5.45964141e-16j > 1.14423775e-17 -4.99600361e-16j 4.98926849e-16 -5.45964141e-16j > 6.32744729e-16 -1.77213142e-16j 3.15834992e-16 +0.00000000e+00j > 2.88998134e-16 +0.00000000e+00j 3.15834992e-16 -0.00000000e+00j > 6.32744729e-16 +1.77213142e-16j 4.98926849e-16 +5.45964141e-16j > 1.14423775e-17 +4.99600361e-16j 5.48376387e-17 +5.45964141e-16j > -3.87815369e-16 +8.43346956e-16j -1.35945820e-15 +8.00000000e+00j] > > >>>> sfix = ifft(sfx) >>>> print 'ifft(sfx)',sfix >>>> >>>> >ifft(sfx) [ 0.00000000e+00 +0.00000000e+00j -3.11858849e-16 -3.26510369e-33j > -1.13434883e-16 +0.00000000e+00j 5.44139747e-17 -2.17540312e-32j > 0.00000000e+00 -0.00000000e+00j 1.12119479e-16 -2.89787214e-33j > 1.68946034e-16 -0.00000000e+00j 1.17569819e-16 +1.55910553e-32j > 1.22464680e-16 +0.00000000e+00j 1.17569819e-16 -1.55910553e-32j > 1.68946034e-16 +0.00000000e+00j 1.12119479e-16 +2.89787214e-33j > 0.00000000e+00 +0.00000000e+00j 5.44139747e-17 +2.17540312e-32j > -1.13434883e-16 -0.00000000e+00j -3.11858849e-16 +3.26510369e-33j] > > > >Basically ifft(fft(sin(x))) != sin(x), instead it is 0 to round off. >But ifft(fft(cos(x))) == cos(x) > >Why does one fail and the other not! The only difference is that >fft(cos(x)) is a real valued result and fft(sin(x)) is imaginary. > > From robert.kern at gmail.com Fri Dec 9 14:36:32 2005 From: robert.kern at gmail.com (Robert Kern) Date: Fri, 09 Dec 2005 11:36:32 -0800 Subject: [SciPy-user] f2py complex number problem In-Reply-To: References: Message-ID: <4399DCC0.5070303@gmail.com> Ryan Krauss wrote: > I am trying to learn f2py and am running into a problem. I need to > take the sin, cos, sinh, and cosh of complex numbers. My FORTRAN is > quite rusty but this isn't working: > > subroutine test(s,out) > double complex s, out > Cf2py intent(in) s > Cf2py intent(out) out > out=cos(s)-cosh(s)+sin(s)-sinh(s) > END > > > f2py output ends with: > test.f: In subroutine `test': > test.f:5: > out=cos(s)-cosh(s)+sin(s)-sinh(s) > ^ > Reference to intrinsic `COSH' at (^) invalid -- one or more arguments > have incorrect type http://gcc.gnu.org/onlinedocs/gcc-3.4.1/g77/CosH-Intrinsic.html#CosH%20Intrinsic The COSH intrinsic only takes REAL agruments, at least in g77. EXP, however, works with COMPLEX arguments, so I suggest defining a ZCOSH function from the definition of cosh(z) = 0.5*(exp(z)+exp(-z)) -- Robert Kern robert.kern at gmail.com "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter From ryanlists at gmail.com Fri Dec 9 15:08:47 2005 From: ryanlists at gmail.com (Ryan Krauss) Date: Fri, 9 Dec 2005 15:08:47 -0500 Subject: [SciPy-user] f2py complex number problem In-Reply-To: <4399DCC0.5070303@gmail.com> References: <4399DCC0.5070303@gmail.com> Message-ID: Thanks Robert. That will work. But what am I doing wrong: subroutine test(s,out) double complex s, out external zsinh, zcosh Cf2py intent(in) s Cf2py intent(out) out out=zcos(s)-zcosh(s)+zsin(s)-zsinh(s) ! out=zcos(s)+zsin(s) END double complex function zcosh(z) double complex z zcosh = 0.5*(exp(z)+exp(-z)) END double complex function zsinh(z) double complex z zsinh = 0.5*(exp(z)-exp(-z)) END I can access zsinh and zcosh from python and they are correct, but calling the main funtion returns NaN. If I switch the comment so that out=zsin(s)=zcos(s), everything works fine, so my zsinh and zcosh seem to be screwing this up. Two other rusty fortran questions. Can I put zsinh and zcosh in a library somewhere and import them either complied or just import the definitions? Is it possible to overwrite the interinsic cos, sin, cosh, and sinh with my own comlex definitions? I have a few fortran books I have checked out of the library and I have tried googling, but I am not getting anywhere. Thanks, Ryan On 12/9/05, Robert Kern wrote: > Ryan Krauss wrote: > > I am trying to learn f2py and am running into a problem. I need to > > take the sin, cos, sinh, and cosh of complex numbers. My FORTRAN is > > quite rusty but this isn't working: > > > > subroutine test(s,out) > > double complex s, out > > Cf2py intent(in) s > > Cf2py intent(out) out > > out=cos(s)-cosh(s)+sin(s)-sinh(s) > > END > > > > > > f2py output ends with: > > test.f: In subroutine `test': > > test.f:5: > > out=cos(s)-cosh(s)+sin(s)-sinh(s) > > ^ > > Reference to intrinsic `COSH' at (^) invalid -- one or more arguments > > have incorrect type > > http://gcc.gnu.org/onlinedocs/gcc-3.4.1/g77/CosH-Intrinsic.html#CosH%20Intrinsic > > The COSH intrinsic only takes REAL agruments, at least in g77. EXP, > however, works with COMPLEX arguments, so I suggest defining a ZCOSH > function from the definition of cosh(z) = 0.5*(exp(z)+exp(-z)) > > -- > Robert Kern > robert.kern at gmail.com > > "In the fields of hell where the grass grows high > Are the graves of dreams allowed to die." > -- Richard Harter > > _______________________________________________ > SciPy-user mailing list > SciPy-user at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-user > From arnd.baecker at web.de Fri Dec 9 15:39:27 2005 From: arnd.baecker at web.de (Arnd Baecker) Date: Fri, 9 Dec 2005 21:39:27 +0100 (CET) Subject: [SciPy-user] Benchmark data In-Reply-To: <20051209201510.04c352d6.gerard.vermeulen@grenoble.cnrs.fr> References: <43995919.2090401@ieee.org> <20051209201510.04c352d6.gerard.vermeulen@grenoble.cnrs.fr> Message-ID: On Fri, 9 Dec 2005, Gerard Vermeulen wrote: > On Fri, 09 Dec 2005 03:14:49 -0700 > Travis Oliphant wrote: > > > > > I'd like people to try out scipy core in SVN. I made improvements to the > > buffered ufunc section of code that I think will make a big difference > > in the recently published benchmarks. After everything is working fine again on the 64 Bit Opteron (with gcc), here some results (in total, scipy.base always wins): python bench.py 4 Python 2.4.2 (#1, Oct 4 2005, 10:10:47) [GCC 3.4.4] Optimization flags: -DNDEBUG -g -O3 -Wall -Wstrict-prototypes CPU info: getNCPUs=2 has_3dnow has_3dnowext has_mmx has_sse has_sse2 is_64bit is_AMD is_Opteron Numeric-24.0b2 numarray-1.5.0 scipy-core-0.8.1.1617 benchmark size = 4 (vectors of length 256) label Numeric numarray scipy.base 1 2.408e-05 0.0004282 2.789e-05 2 3.409e-05 0.0002079 4.792e-05 3 1.383e-05 9.108e-05 2.313e-05 4 3.695e-05 0.0003538 4.506e-05 5 1.407e-05 0.000108 2.193e-05 6 1.597e-05 1.311e-05 1.788e-05 7 1.907e-05 2.789e-05 2.098e-05 8 1.097e-05 1.812e-05 8.106e-06 9 0.0001211 0.000653 0.000139 10 9.68e-05 0.000114 0.0001171 11 7.105e-05 0.0001619 9.203e-05 TOTAL 0.000458 0.002177 0.000561 > python bench.py 6 Python 2.4.2 (#1, Oct 4 2005, 10:10:47) [GCC 3.4.4] Optimization flags: -DNDEBUG -g -O3 -Wall -Wstrict-prototypes CPU info: getNCPUs=2 has_3dnow has_3dnowext has_mmx has_sse has_sse2 is_64bit is_AMD is_Opteron Numeric-24.0b2 numarray-1.5.0 scipy-core-0.8.1.1617 benchmark size = 6 (vectors of length 4096) label Numeric numarray scipy.base 1 7.892e-05 0.0004399 5.913e-05 2 0.0001779 0.000349 0.0001638 3 0.0001261 0.0002031 0.0001411 4 0.000124 0.0004549 8.583e-05 5 0.0001349 0.0002279 0.0001361 6 0.000129 0.0001242 0.0001359 7 9.513e-05 9.084e-05 6.413e-05 8 8.297e-05 0.0001061 1.597e-05 9 0.001184 0.001628 0.001099 10 0.001072 0.001045 0.001109 11 0.00086 0.0008881 0.0009079 TOTAL 0.004065 0.005557 0.003918 > python bench.py 11 Python 2.4.2 (#1, Oct 4 2005, 10:10:47) [GCC 3.4.4] Optimization flags: -DNDEBUG -g -O3 -Wall -Wstrict-prototypes CPU info: getNCPUs=2 has_3dnow has_3dnowext has_mmx has_sse has_sse2 is_64bit is_AMD is_Opteron Numeric-24.0b2 numarray-1.5.0 scipy-core-0.8.1.1617 benchmark size = 11 (vectors of length 4194304) label Numeric numarray scipy.base 1 0.07311 0.03584 0.06633 2 0.1624 0.149 0.1566 3 0.1356 0.1268 0.1347 4 0.23 0.118 0.1195 5 0.1623 0.1485 0.1509 6 0.128 0.1268 0.1346 7 0.2279 0.1499 0.12 8 0.1707 0.1295 0.1293 9 1.896 1.803 1.664 10 1.787 2.018 1.666 11 1.423 1.562 1.321 TOTAL 6.397 6.367 5.663 > python bench.py 12 Python 2.4.2 (#1, Oct 4 2005, 10:10:47) [GCC 3.4.4] Optimization flags: -DNDEBUG -g -O3 -Wall -Wstrict-prototypes CPU info: getNCPUs=2 has_3dnow has_3dnowext has_mmx has_sse has_sse2 is_64bit is_AMD is_Opteron Numeric-24.0b2 numarray-1.5.0 scipy-core-0.8.1.1617 benchmark size = 12 (vectors of length 16777216) label Numeric numarray scipy.base 1 0.2908 0.1507 0.2725 2 0.6984 0.6152 0.653 3 0.5147 0.514 0.5547 4 0.9725 0.4665 0.4707 5 0.6728 0.6113 0.6202 6 0.5188 0.5208 0.548 7 0.9556 0.6282 0.4879 8 0.6531 0.5119 0.5129 9 7.725 7.334 6.63 10 7.553 8.046 6.591 11 5.931 6.236 5.262 TOTAL 26.49 25.63 22.6 Best, Arnd From oliphant.travis at ieee.org Fri Dec 9 15:46:13 2005 From: oliphant.travis at ieee.org (Travis Oliphant) Date: Fri, 09 Dec 2005 13:46:13 -0700 Subject: [SciPy-user] FFT troubles In-Reply-To: References: Message-ID: <4399ED15.5000602@ieee.org> Rob Managan wrote: >I am wondering if anyone can help me figure out where my FFts are >going bad with the latest svn version of scipy. This has been going >on for a few weeks. >Mac OSX 10.3.9, python 2.4.1 > >I have fftw-2.1.5 installed and 'make check' reports no problems. > > This looks like a problem with the interface to fftw. Would you agree? Pearu knows the most about this particular section of code. It looks like his module is generically calling the fftw library. I don't know if all of the supported routines have the same calling conventions. Perhaps something else is going on to make it work with fftw. Do fft's work with the default fft? Do scipy.basic.fft and scipy.basic.ifft from scipy core work as expected? -Travis From oliphant.travis at ieee.org Fri Dec 9 15:01:41 2005 From: oliphant.travis at ieee.org (Travis Oliphant) Date: Fri, 09 Dec 2005 13:01:41 -0700 Subject: [SciPy-user] Benchmark data In-Reply-To: <20051209201510.04c352d6.gerard.vermeulen@grenoble.cnrs.fr> References: <43995919.2090401@ieee.org> <20051209201510.04c352d6.gerard.vermeulen@grenoble.cnrs.fr> Message-ID: <4399E2A5.3090601@ieee.org> Gerard Vermeulen wrote: >On Fri, 09 Dec 2005 03:14:49 -0700 >Travis Oliphant wrote: > > >>I'd like people to try out scipy core in SVN. I made improvements to the >>buffered ufunc section of code that I think will make a big difference >>in the recently published benchmarks. >> >> >> > >Hi Travis, > >indeed, it made a big difference (for big arrays scipy is now fastest on some >statements). > >Below are my benchmark results on my DIY python, see >http://www.scipy.org/mailinglists/mailman?fn=scipy-user/2005-December/006057.html > >On my system and for large arrays (>4096), numarray is still fastest, scipy moved >to second and Numeric is third. >Numeric is still fastest for small arrays, scipy is second, numarray is third. > > Numeric will always be faster for small-enough arrays, I think, because it doesn't have the ufunc overhead. I just don't want it to be a lot faster. We can improve the limiting scalar case in scipy_core using separate scalar math. It looks like we are doing reasonably well. >Invoking: python bench.py 12 >Importing test to scipy >Importing base to scipy >Importing basic to scipy >Python 2.4.2 (#1, Dec 4 2005, 08:21:04) >[GCC 3.4.3 (Mandrakelinux 10.2 3.4.3-7mdk)] >Optimization flags: -DNDEBUG -O3 -march=i686 >CPU info: getNCPUs=2 has_mmx has_sse has_sse2 is_32bit is_Intel is_Pentium is_PentiumIV >Numeric-24.2 >numarray-1.5.0 >scipy-core-0.8.1.1617 >benchmark size = 12 (vectors of length 16777216) >label Numeric numarray scipy.base > 1 0.4127 0.07423 0.3927 > 2 0.2734 0.2321 0.3234 > 3 0.1975 0.1821 0.2733 > 4 0.8747 0.5371 0.5588 > 5 0.2896 0.2342 0.2737 > 6 0.2066 0.1731 0.2718 > 7 0.8761 0.6286 0.5524 > 8 0.6546 0.4556 0.4533 > 9 9.488 7.566 8.717 > 10 9.506 8.064 8.745 > 11 7.879 6.301 7.305 >TOTAL 30.66 24.45 27.87 > > As mentioned before, it looks like the optimizer is doing something nice on your system. One issue is arange which could definitely be made faster by having different "fillers" for different types. I'm still astonished by the markedly different numbers you seem to get than others have shown. Is this all -O3 optimization kicking in? The other issue is the sin and cosine functions. They don't have their own inner loops. They call a generic inner loop with a "function-pointer" data. Perhaps the optimizer can't do as much with that or it needs to written with an optimizer in mind. Ultimately, though, I'd like to see some of the inner loops to take advantage of SSE (and equivalent) instructions if the number of iterations is large-enough. So, yes, I think we could get faster. But, I'd first like to get more data from more machines and compiler flags to determine where the slowness is really coming from. It might be good, for example, to break up one of lines 9, 10, and 11 so that at least one sin and cos calculation is done alone. Thanks, -Travis From robert.kern at gmail.com Fri Dec 9 16:33:03 2005 From: robert.kern at gmail.com (Robert Kern) Date: Fri, 09 Dec 2005 13:33:03 -0800 Subject: [SciPy-user] Benchmark data In-Reply-To: <4399E2A5.3090601@ieee.org> References: <43995919.2090401@ieee.org> <20051209201510.04c352d6.gerard.vermeulen@grenoble.cnrs.fr> <4399E2A5.3090601@ieee.org> Message-ID: <4399F80F.5000801@gmail.com> Travis Oliphant wrote: > Ultimately, though, I'd like to see some of the inner loops to take > advantage of SSE (and equivalent) instructions if the number of > iterations is large-enough. So, yes, I think we could get faster. When we start to seriously look at this, we should consider using liboil to implement these optimizations. http://liboil.freedesktop.org/wiki/ """Liboil is a library of simple functions that are optimized for various CPUs. These functions are generally loops implementing simple algorithms, such as converting an array of N integers to floating-point numbers or multiplying and summing an array of N numbers. Such functions are candidates for significant optimization using various techniques, especially by using extended instructions provided by modern CPUs (Altivec, MMX, SSE, etc.). """ """Each function class has one or more function implementations, which are real functions that perform the exact same action as defined by the documentation for the function. Each class has one implementation that is the reference implementation. This reference implmentation is used to test the accuracy of other implementations. Presumably, the non-reference implementations can perform the action faster than the reference implementation. Thus, the liboil initialization code (at runtime) checks each implementation in a class to determine the fastest implementation. Once this is done, the class's indirect function pointer points to the optimal implementation. After this, any calls to the function class (such as oil_tablelookup_u8() described above) will automatically be routed to the fastest implementation. Implementations can be disabled either at compile time (e.g., assembly code for the wrong architecture) or at run time (e.g., implementation uses unsupported opcodes). This is done automatically. In addition, implementations may be disabled because they do not produce the same results as the reference implementation. """ And the all-important: """Liboil may be modified and distributed in accordance with a very liberal license commonly referred to as "Two-Clause BSD".""" -- Robert Kern robert.kern at gmail.com "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter From managan at llnl.gov Fri Dec 9 17:20:19 2005 From: managan at llnl.gov (Rob Managan) Date: Fri, 9 Dec 2005 14:20:19 -0800 Subject: [SciPy-user] FFT troubles In-Reply-To: <4399ED15.5000602@ieee.org> References: <4399ED15.5000602@ieee.org> Message-ID: At 1:46 PM -0700 12/9/05, Travis Oliphant wrote: >Rob Managan wrote: > >>I am wondering if anyone can help me figure out where my FFts are >>going bad with the latest svn version of scipy. This has been going >>on for a few weeks. >>Mac OSX 10.3.9, python 2.4.1 >> >>I have fftw-2.1.5 installed and 'make check' reports no problems. >> >> >This looks like a problem with the interface to fftw. Would you agree? > >Pearu knows the most about this particular section of code. It looks >like his >module is generically calling the fftw library. I don't know if all of >the supported >routines have the same calling conventions. > >Perhaps something else is going on to make it work with fftw. Do fft's >work with the default fft? > >Do scipy.basic.fft and scipy.basic.ifft from scipy core work as expected? > Make that scipy.fft and scipy.ifft and the answer is yes. Just to be clear here is what I did. rm -rf .../site-packages/scipy/ cd core python setup.py install cd .. Then the test runs fine using scipy.fft and scipy.ifft . When I cd scipy python setup.py install cd .. Then the test fails. I guess that means there is a problem in how the scipy package links with fftw-2.1.5. What is the best way to figure out where the problem is?? -- *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*- Rob Managan email managan at llnl.gov LLNL phone: 925-423-0903 P.O. Box 808, L-095 FAX: 925-422-3389 Livermore, CA 94551-0808 From managan at llnl.gov Fri Dec 9 17:41:06 2005 From: managan at llnl.gov (Rob Managan) Date: Fri, 9 Dec 2005 14:41:06 -0800 Subject: [SciPy-user] FFT troubles In-Reply-To: <4399ED15.5000602@ieee.org> References: <4399ED15.5000602@ieee.org> Message-ID: > >Do scipy.basic.fft and scipy.basic.ifft from scipy core work as expected? > >-Travis OK, I am a little slow today. I mixed up scipy.base and scipy.basic. With the full scipy installed I see the bug with scipy.fft (same function as scipy.fftpack.fft) but not with scipy.basic.fft (which is distinct from scipy.fft) -- *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*- Rob Managan email managan at llnl.gov LLNL phone: 925-423-0903 P.O. Box 808, L-095 FAX: 925-422-3389 Livermore, CA 94551-0808 From gerard.vermeulen at grenoble.cnrs.fr Fri Dec 9 19:16:24 2005 From: gerard.vermeulen at grenoble.cnrs.fr (Gerard Vermeulen) Date: Sat, 10 Dec 2005 01:16:24 +0100 Subject: [SciPy-user] Benchmark data In-Reply-To: <4399E2A5.3090601@ieee.org> References: <43995919.2090401@ieee.org> <20051209201510.04c352d6.gerard.vermeulen@grenoble.cnrs.fr> <4399E2A5.3090601@ieee.org> Message-ID: <20051210011624.7347cb56.gerard.vermeulen@grenoble.cnrs.fr> On Fri, 09 Dec 2005 13:01:41 -0700 Travis Oliphant wrote: > Gerard Vermeulen wrote: > > >On Fri, 09 Dec 2005 03:14:49 -0700 > >Travis Oliphant wrote: > > > > > >>I'd like people to try out scipy core in SVN. I made improvements to the > >>buffered ufunc section of code that I think will make a big difference > >>in the recently published benchmarks. > >> > >> > >> > > > >Hi Travis, > > > >indeed, it made a big difference (for big arrays scipy is now fastest on some > >statements). > > > >Below are my benchmark results on my DIY python, see > >http://www.scipy.org/mailinglists/mailman?fn=scipy-user/2005-December/006057.html > > > >On my system and for large arrays (>4096), numarray is still fastest, scipy moved > >to second and Numeric is third. > >Numeric is still fastest for small arrays, scipy is second, numarray is third. > > > > > Numeric will always be faster for small-enough arrays, I think, because > it doesn't have the ufunc overhead. I just don't want it to be a lot > faster. We can improve the limiting scalar case in scipy_core using > separate scalar math. It looks like we are doing reasonably well. > Agreed, the tiny difference won't stop me from using scipy :-) > > >Invoking: python bench.py 12 > >Importing test to scipy > >Importing base to scipy > >Importing basic to scipy > >Python 2.4.2 (#1, Dec 4 2005, 08:21:04) > >[GCC 3.4.3 (Mandrakelinux 10.2 3.4.3-7mdk)] > >Optimization flags: -DNDEBUG -O3 -march=i686 > >CPU info: getNCPUs=2 has_mmx has_sse has_sse2 is_32bit is_Intel is_Pentium is_PentiumIV > >Numeric-24.2 > >numarray-1.5.0 > >scipy-core-0.8.1.1617 > >benchmark size = 12 (vectors of length 16777216) > >label Numeric numarray scipy.base > > 1 0.4127 0.07423 0.3927 > > 2 0.2734 0.2321 0.3234 > > 3 0.1975 0.1821 0.2733 > > 4 0.8747 0.5371 0.5588 > > 5 0.2896 0.2342 0.2737 > > 6 0.2066 0.1731 0.2718 > > 7 0.8761 0.6286 0.5524 > > 8 0.6546 0.4556 0.4533 > > 9 9.488 7.566 8.717 > > 10 9.506 8.064 8.745 > > 11 7.879 6.301 7.305 > >TOTAL 30.66 24.45 27.87 > > > > > > As mentioned before, it looks like the optimizer is doing something nice > on your system. One issue is arange which could definitely be made > faster by having different "fillers" for different types. I'm still > astonished by the markedly different numbers you seem to get than others > have shown. Is this all -O3 optimization kicking in? > Below there is data for a build without optimize options (OPT='-g'), with a plain configure invokation (configure sets -O3 by itself) and a debug build. Above there is data showing the benefits of an additional -march=i686 (less benefit than I claimed in one of my previous mails). The compiler flags do not make a big overall difference on my machine, but a debug build is bad for numarray (easy to explain, since numarray does more in plain Python, so it will suffer more from Python's debug overhead). > > The other issue is the sin and cosine functions. They don't have their > own inner loops. They call a generic inner loop with a > "function-pointer" data. Perhaps the optimizer can't do as much with > that or it needs to written with an optimizer in mind. > I understand that gcc uses inline assembler for simple math functions, so it is certainly something to look into. > > Ultimately, though, I'd like to see some of the inner loops to take > advantage of SSE (and equivalent) instructions if the number of > iterations is large-enough. So, yes, I think we could get faster. > But, I'd first like to get more data from more machines and compiler > flags to determine where the slowness is really coming from. It might > be good, for example, to break up one of lines 9, 10, and 11 so that at > least one sin and cos calculation is done alone. > I agree that more data is necessary and I remind everybody that my data is for an Intel CPU and that all other data (David Cooke, Arnd Backer and you) is for AMD CPU's. It may be worthwhile to generalize the benchmark program so that it reads statements from a file and does timed calls to eval(statement). I am going to play with this idea this weekend. Travis, I really appreciate how seriously you take this, Gerard PS: the additional benchmark data: # NO OPTIMIZATION, SET -g [packer at titan BUILD]$ python bench.py 12 Importing test to scipy Importing base to scipy Importing basic to scipy Python 2.4.2 (#1, Dec 9 2005, 23:29:32) [GCC 3.4.3 (Mandrakelinux 10.2 3.4.3-7mdk)] Optimization flags: -DNDEBUG -g CPU info: getNCPUs=2 has_mmx has_sse has_sse2 is_32bit is_Intel is_Pentium is_PentiumIV Numeric-24.2 numarray-1.5.0 scipy-core-0.8.1.1617 benchmark size = 12 (vectors of length 16777216) label Numeric numarray scipy.base 1 0.4933 0.1256 0.4204 2 0.3355 0.3553 0.4266 3 0.2704 0.2815 0.3545 4 0.9105 0.6438 0.6785 5 0.3868 0.3442 0.3511 6 0.2617 0.2815 0.3553 7 0.9159 0.707 0.6803 8 0.6202 0.4303 0.4254 9 11.22 9.597 10.7 10 11.11 9.906 10.67 11 9.129 7.836 8.837 TOTAL 35.66 30.51 33.9 # LET configure DECIDE BY ITSELF [packer at titan BUILD]$ python bench.py 12 Importing test to scipy Importing base to scipy Importing basic to scipy Python 2.4.2 (#1, Dec 9 2005, 23:38:46) [GCC 3.4.3 (Mandrakelinux 10.2 3.4.3-7mdk)] Optimization flags: -DNDEBUG -g -O3 -Wall -Wstrict-prototypes CPU info: getNCPUs=2 has_mmx has_sse has_sse2 is_32bit is_Intel is_Pentium is_PentiumIV Numeric-24.2 numarray-1.5.0 scipy-core-0.8.1.1617 benchmark size = 12 (vectors of length 16777216) label Numeric numarray scipy.base 1 0.4525 0.07366 0.413 2 0.2674 0.2354 0.3261 3 0.2022 0.1853 0.2755 4 0.8649 0.5381 0.5522 5 0.2831 0.2361 0.2681 6 0.1919 0.1747 0.2755 7 0.8809 0.6236 0.5593 8 0.629 0.4348 0.4341 9 11.12 9.065 10.34 10 11.15 9.49 10.37 11 9.179 7.484 8.599 TOTAL 35.23 28.54 32.41 # DEBUG BUILD, NO OPTIMIZATION [packer at titan BUILD]$ python bench.py 12 Importing test to scipy Importing base to scipy Importing basic to scipy Python 2.4.2 (#1, Dec 9 2005, 23:48:07) [GCC 3.4.3 (Mandrakelinux 10.2 3.4.3-7mdk)] Optimization flags: -g -Wall -Wstrict-prototypes CPU info: getNCPUs=2 has_mmx has_sse has_sse2 is_32bit is_Intel is_Pentium is_PentiumIV Numeric-24.2 numarray-1.5.0 scipy-core-0.8.1.1617 benchmark size = 12 (vectors of length 16777216) label Numeric numarray scipy.base 1 0.5178 0.1394 0.4421 2 0.3371 0.3589 0.4191 3 0.2615 0.2919 0.364 4 0.9209 0.801 0.6696 5 0.3899 0.3668 0.361 6 0.2619 0.2804 0.3552 7 0.9191 0.9445 0.6808 8 0.6171 0.6379 0.4235 9 11.09 11.31 10.69 10 11.11 11.79 10.69 11 9.125 9.256 8.836 TOTAL 35.56 36.18 33.94 [47538 refs] [packer at titan BUILD]$ From robert.kern at gmail.com Fri Dec 9 19:27:50 2005 From: robert.kern at gmail.com (Robert Kern) Date: Fri, 09 Dec 2005 16:27:50 -0800 Subject: [SciPy-user] Benchmark data In-Reply-To: <20051210011624.7347cb56.gerard.vermeulen@grenoble.cnrs.fr> References: <43995919.2090401@ieee.org> <20051209201510.04c352d6.gerard.vermeulen@grenoble.cnrs.fr> <4399E2A5.3090601@ieee.org> <20051210011624.7347cb56.gerard.vermeulen@grenoble.cnrs.fr> Message-ID: <439A2106.20907@gmail.com> Gerard Vermeulen wrote: > It may be worthwhile to generalize the benchmark program so that it > reads statements from a file and does timed calls to eval(statement). > I am going to play with this idea this weekend. That's what timeit.py is for. -- Robert Kern robert.kern at gmail.com "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter From fonnesbeck at gmail.com Fri Dec 9 23:47:32 2005 From: fonnesbeck at gmail.com (Chris Fonnesbeck) Date: Fri, 9 Dec 2005 23:47:32 -0500 Subject: [SciPy-user] array resize() method error in scipy_core Message-ID: <723eb6930512092047n39a2f2fcrc822b990fd305a3c@mail.gmail.com> Not sure why I get this error: 502 # Container list for intervals 503 means = array([0.0]) --> 504 means.resize(dims[:-1][0]) means.resize = dims = (2, 4000) 505 506 for index in make_indices(dims[:-1]): ValueError: cannot resize an array that has been referenced or is referencing another array in this way. Use the resize function I'm using a recent svn of scipy_core. The odd thing is, I only get this error when profiling. -- Chris Fonnesbeck Atlanta, GA From oliphant.travis at ieee.org Sat Dec 10 00:09:03 2005 From: oliphant.travis at ieee.org (Travis Oliphant) Date: Fri, 09 Dec 2005 22:09:03 -0700 Subject: [SciPy-user] array resize() method error in scipy_core In-Reply-To: <723eb6930512092047n39a2f2fcrc822b990fd305a3c@mail.gmail.com> References: <723eb6930512092047n39a2f2fcrc822b990fd305a3c@mail.gmail.com> Message-ID: <439A62EF.4000906@ieee.org> Chris Fonnesbeck wrote: >Not sure why I get this error: > > 502 # Container list for intervals > 503 means = array([0.0]) >--> 504 means.resize(dims[:-1][0]) > means.resize = at 0x385ad70> > dims = (2, 4000) > 505 > 506 for index in make_indices(dims[:-1]): > >ValueError: cannot resize an array that has been referenced or is referencing >another array in this way. Use the resize function > >I'm using a recent svn of scipy_core. The odd thing is, I only get >this error when profiling. > > The resize function is very conservative about letting you resize the memory of an array in-place because of the possibility of sharing the data through the buffer interface. If you resized the memory while another object was holding the memory you could easily get a segfault later. Unfortunately, there is no way to tell whether another object is referencing the memory of the array except through the reference count (which also increases on simple name binding, too.) So, perhaps while profiling an additional reference is being held to the objects and therefore, the resize function won't let you resize the memory. I'm not sure how to be more generous about when resizing is possible. -Travis From oliphant.travis at ieee.org Sat Dec 10 00:14:34 2005 From: oliphant.travis at ieee.org (Travis Oliphant) Date: Fri, 09 Dec 2005 22:14:34 -0700 Subject: [SciPy-user] Benchmark data In-Reply-To: <20051210011624.7347cb56.gerard.vermeulen@grenoble.cnrs.fr> References: <43995919.2090401@ieee.org> <20051209201510.04c352d6.gerard.vermeulen@grenoble.cnrs.fr> <4399E2A5.3090601@ieee.org> <20051210011624.7347cb56.gerard.vermeulen@grenoble.cnrs.fr> Message-ID: <439A643A.10904@ieee.org> > > >> >> >> >I understand that gcc uses inline assembler for simple math >functions, so it is certainly something to look into. > > We should find out which functions and make sure they have their own inner loop instead of using the generic one. It definitely looks like gcc is able to optimize numarray code better on Intel processors. It would be nice to have more people on Intel chips confirm this as well --- I have access to one so I can look into it. I'll play with some differences in the way the loops are written to see what effect it has. As you can see, I've not noticed any effect on an AMD chip, but on INTEL chips gcc may be able to do more. >I agree that more data is necessary and I remind everybody that my data is >for an Intel CPU and that all other data (David Cooke, Arnd Backer and you) >is for AMD CPU's. > > Yes, I think it's been very valuable to show us these cases. > >Gerard > >PS: the additional benchmark data: > >[snip] > Thanks for those additional data. I think they show that it's more the INTEL architecture then the optimizations. -Travis From fonnesbeck at gmail.com Sat Dec 10 00:33:10 2005 From: fonnesbeck at gmail.com (Chris Fonnesbeck) Date: Sat, 10 Dec 2005 00:33:10 -0500 Subject: [SciPy-user] array resize() method error in scipy_core In-Reply-To: <439A62EF.4000906@ieee.org> References: <723eb6930512092047n39a2f2fcrc822b990fd305a3c@mail.gmail.com> <439A62EF.4000906@ieee.org> Message-ID: <723eb6930512092133n4ee3ffefx1baee2a6fc87643d@mail.gmail.com> On 12/10/05, Travis Oliphant wrote: > > The resize function is very conservative about letting you resize the > memory of an array in-place because of the possibility of sharing the > data through the buffer interface. If you resized the memory while > another object was holding the memory you could easily get a segfault > later. > > Unfortunately, there is no way to tell whether another object is > referencing the memory of the array except through the reference count > (which also increases on simple name binding, too.) > > So, perhaps while profiling an additional reference is being held to the > objects and therefore, the resize function won't let you resize the > memory. I'm not sure how to be more generous about when resizing is > possible. > Hi Travis, I assume you mean the resize *method*, right? Should I go back to using the function (i.e. resize(my_array) rather than my_array.resize())? I switched over because it seemed faster, not having to use oldnumeric and all ... -- Chris Fonnesbeck Atlanta, GA From oliphant.travis at ieee.org Sat Dec 10 00:41:42 2005 From: oliphant.travis at ieee.org (Travis Oliphant) Date: Fri, 09 Dec 2005 22:41:42 -0700 Subject: [SciPy-user] array resize() method error in scipy_core In-Reply-To: <723eb6930512092133n4ee3ffefx1baee2a6fc87643d@mail.gmail.com> References: <723eb6930512092047n39a2f2fcrc822b990fd305a3c@mail.gmail.com> <439A62EF.4000906@ieee.org> <723eb6930512092133n4ee3ffefx1baee2a6fc87643d@mail.gmail.com> Message-ID: <439A6A96.6090406@ieee.org> Chris Fonnesbeck wrote: >On 12/10/05, Travis Oliphant wrote: > > >>The resize function is very conservative about letting you resize the >>memory of an array in-place because of the possibility of sharing the >>data through the buffer interface. If you resized the memory while >>another object was holding the memory you could easily get a segfault >>later. >> >>Unfortunately, there is no way to tell whether another object is >>referencing the memory of the array except through the reference count >>(which also increases on simple name binding, too.) >> >>So, perhaps while profiling an additional reference is being held to the >>objects and therefore, the resize function won't let you resize the >>memory. I'm not sure how to be more generous about when resizing is >>possible. >> >> >> > >Hi Travis, > >I assume you mean the resize *method*, right? Should I go back to >using the function (i.e. resize(my_array) > Yes the resize() works for anything (it also fills differently --- the .resize method doesn't fill the new memory at all, the resize function fills the old way of copying old data repeatedly. .resize() is faster, but it does have that no-other references restriction (perhaps you could use one while profiling and another in production...) -Travis From oliphant.travis at ieee.org Sat Dec 10 00:50:56 2005 From: oliphant.travis at ieee.org (Travis Oliphant) Date: Fri, 09 Dec 2005 22:50:56 -0700 Subject: [SciPy-user] Benchmark data In-Reply-To: <20051210011624.7347cb56.gerard.vermeulen@grenoble.cnrs.fr> References: <43995919.2090401@ieee.org> <20051209201510.04c352d6.gerard.vermeulen@grenoble.cnrs.fr> <4399E2A5.3090601@ieee.org> <20051210011624.7347cb56.gerard.vermeulen@grenoble.cnrs.fr> Message-ID: <439A6CC0.6070003@ieee.org> I know people may be tired of the benchmark data, but I'm just trying to understand what kinds of techniques produce fast code. I recompiled python 2.4.2 using gcc 3.4.1 on Mandrake 10.1 (with py-debug off) and rebuilt Numeric, numarray, and scipy_core. The results of my benchmarks are: > uname -a Linux oliphant 2.6.3-9mdkenterprise #1 SMP Fri Apr 23 12:23:42 EDT 2004 i686 Intel(R) Xeon(TM) CPU 2.66GHz unknown GNU/Linux Python 2.4.2 (#1, Dec 9 2005, 22:29:36) [GCC 3.4.1 (Mandrakelinux 10.1 3.4.1-4mdk)] Optimization flags: -DNDEBUG -g -O3 -Wall -Wstrict-prototypes CPU info: getNCPUs=2 has_mmx has_sse has_sse2 is_32bit is_Intel Numeric-24.2 numarray-1.5.1 scipy-core-0.8.1.1619 benchmark size = 12 (vectors of length 16777216) label Numeric numarray scipy.base 1 0.5558 0.1091 0.4889 2 0.3804 0.3641 0.3706 3 0.2654 0.265 0.2802 4 1.302 0.7388 0.7712 5 0.4035 0.4016 0.3729 6 0.2651 0.2689 0.28 7 1.304 0.9061 0.7685 8 1.077 0.6743 0.6736 9 14.15 12.75 12.81 10 13.94 13.51 12.79 11 11.16 10.58 10.39 TOTAL 44.8 40.56 40 So, I'm not sure how to reproduce what Gerard sees (except numarray's faster arange) which is a little perplexing. I suppose that's why people criticize benchmarks so much. But at least we can still see that an improved arange may be a benefit. As part of the recent ufunc changes, I also improved the remainder function to not use floating point unless it must (in order to match the python's remainder function). Notice that neither numarray nor Numeric match python's usage of % for integers. -Travis From oliphant.travis at ieee.org Sat Dec 10 02:24:33 2005 From: oliphant.travis at ieee.org (Travis Oliphant) Date: Sat, 10 Dec 2005 00:24:33 -0700 Subject: [SciPy-user] 'object_arrtype' problem In-Reply-To: References: <43986B42.5000904@ieee.org> <43988315.7090809@ee.byu.edu> Message-ID: <439A82B1.1040608@ieee.org> Ryan Krauss wrote: >One thing I don't like about Numeric returning the object is that >things get a little messy when you aren't sure if you have an array or >not. I find myself calling atleast_1d a lot or writing tests using >"if shape(obtject)" which returns an empty tuple for scalars. I guess >my thoughts are slightly twisted by everything being an array in >Matlab. I want to test if len==1, then it must be a scalar. I guess >I would be happiest with clean scalar tests and objects that worked >well when iterating or indexing from an object array. > > Yes, this is why we went with the array scalars in the first place to avoid some of these problems. I improved the object array-scalars a bit, so that they pass attribute lookups on to the wrapped object. This will fix the immediate problem you encountered, and it seems like an obvious thing to do. -Travis From jaonary at free.fr Sat Dec 10 05:22:02 2005 From: jaonary at free.fr (Jaonary Rabarisoa) Date: Sat, 10 Dec 2005 11:22:02 +0100 Subject: [SciPy-user] scipy 0.4.3, gnuplot and wxPython In-Reply-To: <200512091131.43983.basvandijk@home.nl> References: <1134055230.43984f3e2e8ee@imp3-g19.free.fr> <200512091131.43983.basvandijk@home.nl> Message-ID: Thanks for yout post. I finally use matplotlib. But, I'd like to know if scipy developers plan to develop only one graphic package in the future. I found that having a lot of graphic package is a bit confusing for a new be like me :-) > You could also check out Chaco: > > http://code.enthought.com/chaco/ > > Bas van Dijk. > > On Thursday 08 December 2005 16:46, Alan G Isaac wrote: >> On Thu, 08 Dec 2005, jaonary at free.fr apparently wrote: >>> I'm trying to use scipy to do some 2d graphics plotting. >> >> The right answer will be to use SciPy and Matplotlib. >> I think Matplotlib already talks to the new SciPy core, >> but I'm not positive (since I still use Numeric for >> Matplotlib numerics). See >> http://aspn.activestate.com/ASPN/Mail/Message/scipy-user/2923861 >> >> hth, >> Alan Isaac >> >> >> >> _______________________________________________ >> SciPy-user mailing list >> SciPy-user at scipy.net >> http://www.scipy.net/mailman/listinfo/scipy-user > > _______________________________________________ > SciPy-user mailing list > SciPy-user at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-user > From jaonary at free.fr Sat Dec 10 05:36:17 2005 From: jaonary at free.fr (Jaonary Rabarisoa) Date: Sat, 10 Dec 2005 11:36:17 +0100 Subject: [SciPy-user] C/C++ extension with swig Message-ID: Hi all, I'd like to write a python interface for some c/c++ code. I've already done this with the standard way (without swig) and now, I'd like to use swig. The code that I like to wrap is like this : void (double *input, some other args, ...., double *output1, double *output2, ...) The input and output arguments represent arrays (matirx, vectors, .nd- arrays, ...). In python, I'd like to passe the argument as a list (or scipy array) of the form [ [row1], .........., [rowN] ] and so the outputs are. My problem in the type mapping (Python -> C/C++ and C/C++ -> Python). I found in the swig documentation some hint about this but nowhere there are usefull information on how to use use scipy arrays without pain and transparently. I tryed to follow the example of scipy.cluster.vq but I doesn't work anymore. This issue is already mentionned here. Thank you for your help From elcorto at gmx.net Sat Dec 10 06:32:55 2005 From: elcorto at gmx.net (Steve Schmerler) Date: Sat, 10 Dec 2005 12:32:55 +0100 Subject: [SciPy-user] gcc error In-Reply-To: References: <1134055230.43984f3e2e8ee@imp3-g19.free.fr> <200512091131.43983.basvandijk@home.nl> Message-ID: <439ABCE7.10607@gmx.net> Hi Compiling the latest svn core fails: ########################################################################################################################################### elcorto at ramrod:~/Install/Python/SciPy$ sudo python core/setup.py install [...] gcc: scipy/corelib/blasdot/_dotblas.c scipy/corelib/blasdot/_dotblas.c: In Funktion ?dotblas_alterdot?: scipy/corelib/blasdot/_dotblas.c:71: error: structure has no member named `dotfunc' scipy/corelib/blasdot/_dotblas.c:72: error: structure has no member named `dotfunc' scipy/corelib/blasdot/_dotblas.c:75: error: structure has no member named `dotfunc' scipy/corelib/blasdot/_dotblas.c:76: error: structure has no member named `dotfunc' scipy/corelib/blasdot/_dotblas.c:79: error: structure has no member named `dotfunc' scipy/corelib/blasdot/_dotblas.c:80: error: structure has no member named `dotfunc' scipy/corelib/blasdot/_dotblas.c:83: error: structure has no member named `dotfunc' scipy/corelib/blasdot/_dotblas.c:84: error: structure has no member named `dotfunc' scipy/corelib/blasdot/_dotblas.c: In Funktion ?dotblas_restoredot?: scipy/corelib/blasdot/_dotblas.c:104: error: structure has no member named `dotfunc' scipy/corelib/blasdot/_dotblas.c:108: error: structure has no member named `dotfunc' scipy/corelib/blasdot/_dotblas.c:112: error: structure has no member named `dotfunc' scipy/corelib/blasdot/_dotblas.c:116: error: structure has no member named `dotfunc' scipy/corelib/blasdot/_dotblas.c: In Funktion ?dotblas_alterdot?: scipy/corelib/blasdot/_dotblas.c:71: error: structure has no member named `dotfunc' scipy/corelib/blasdot/_dotblas.c:72: error: structure has no member named `dotfunc' scipy/corelib/blasdot/_dotblas.c:75: error: structure has no member named `dotfunc' scipy/corelib/blasdot/_dotblas.c:76: error: structure has no member named `dotfunc' scipy/corelib/blasdot/_dotblas.c:79: error: structure has no member named `dotfunc' scipy/corelib/blasdot/_dotblas.c:80: error: structure has no member named `dotfunc' scipy/corelib/blasdot/_dotblas.c:83: error: structure has no member named `dotfunc' scipy/corelib/blasdot/_dotblas.c:84: error: structure has no member named `dotfunc' scipy/corelib/blasdot/_dotblas.c: In Funktion ?dotblas_restoredot?: scipy/corelib/blasdot/_dotblas.c:104: error: structure has no member named `dotfunc' scipy/corelib/blasdot/_dotblas.c:108: error: structure has no member named `dotfunc' scipy/corelib/blasdot/_dotblas.c:112: error: structure has no member named `dotfunc' scipy/corelib/blasdot/_dotblas.c:116: error: structure has no member named `dotfunc' error: Command "gcc -pthread -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -DATLAS_INFO="\"3.2.1_pre3.3.6\"" -Iscipy/corelib/blasdot -Iscipy/base/include -Ibuild/src/scipy/base -Iscipy/base/src -I/usr/include/python2.3 -c scipy/corelib/blasdot/_dotblas.c -o build/temp.linux-i686-2.3/scipy/corelib/blasdot/_dotblas.o" failed with exit status 1 ########################################################################################################################################### Cheers, steve -- Should array indices start at 0 or 1? My compromise of 0.5 was rejected without, I thought, proper consideration. -- Stan Kelly-Bootle From elcorto at gmx.net Sat Dec 10 07:23:04 2005 From: elcorto at gmx.net (Steve Schmerler) Date: Sat, 10 Dec 2005 13:23:04 +0100 Subject: [SciPy-user] gcc error In-Reply-To: <439ABCE7.10607@gmx.net> References: <1134055230.43984f3e2e8ee@imp3-g19.free.fr> <200512091131.43983.basvandijk@home.nl> <439ABCE7.10607@gmx.net> Message-ID: <439AC8A8.3050602@gmx.net> Thanx for the *fast* _dotblas.c update :). But compiling scipy I get ######################################################################################################################################### python scipy/setup.py install [...] gcc: Lib/integrate/_quadpackmodule.c In file included from Lib/integrate/_quadpackmodule.c:6: Lib/integrate/__quadpack.h: In Funktion ?quad_function?: Lib/integrate/__quadpack.h:60: Warnung: unused variable `nb' Lib/integrate/__quadpack.h: In Funktion ?quadpack_qagse?: Lib/integrate/__quadpack.h:141: error: too many arguments to function `dqagse_' Lib/integrate/__quadpack.h: In Funktion ?quadpack_qagie?: Lib/integrate/__quadpack.h:219: error: too many arguments to function `dqagie_' Lib/integrate/__quadpack.h: In Funktion ?quadpack_qagpe?: Lib/integrate/__quadpack.h:314: error: too many arguments to function `dqagpe_' Lib/integrate/__quadpack.h: In Funktion ?quadpack_qawoe?: Lib/integrate/__quadpack.h:420: error: too many arguments to function `dqawoe_' Lib/integrate/__quadpack.h: In Funktion ?quadpack_qawfe?: Lib/integrate/__quadpack.h:521: error: too many arguments to function `dqawfe_' Lib/integrate/__quadpack.h: In Funktion ?quadpack_qawce?: Lib/integrate/__quadpack.h:610: error: too many arguments to function `dqawce_' Lib/integrate/__quadpack.h: In Funktion ?quadpack_qawse?: Lib/integrate/__quadpack.h:690: error: too many arguments to function `dqawse_' Lib/integrate/_quadpackmodule.c: Auf h?chster Ebene: Lib/integrate/_quadpackmodule.c:17: Warnung: function declaration isn't a prototype In file included from Lib/integrate/_quadpackmodule.c:6: Lib/integrate/__quadpack.h: In Funktion ?quad_function?: Lib/integrate/__quadpack.h:60: Warnung: unused variable `nb' Lib/integrate/__quadpack.h: In Funktion ?quadpack_qagse?: Lib/integrate/__quadpack.h:141: error: too many arguments to function `dqagse_' Lib/integrate/__quadpack.h: In Funktion ?quadpack_qagie?: Lib/integrate/__quadpack.h:219: error: too many arguments to function `dqagie_' Lib/integrate/__quadpack.h: In Funktion ?quadpack_qagpe?: Lib/integrate/__quadpack.h:314: error: too many arguments to function `dqagpe_' Lib/integrate/__quadpack.h: In Funktion ?quadpack_qawoe?: Lib/integrate/__quadpack.h:420: error: too many arguments to function `dqawoe_' Lib/integrate/__quadpack.h: In Funktion ?quadpack_qawfe?: Lib/integrate/__quadpack.h:521: error: too many arguments to function `dqawfe_' Lib/integrate/__quadpack.h: In Funktion ?quadpack_qawce?: Lib/integrate/__quadpack.h:610: error: too many arguments to function `dqawce_' Lib/integrate/__quadpack.h: In Funktion ?quadpack_qawse?: Lib/integrate/__quadpack.h:690: error: too many arguments to function `dqawse_' Lib/integrate/_quadpackmodule.c: Auf h?chster Ebene: Lib/integrate/_quadpackmodule.c:17: Warnung: function declaration isn't a prototype error: Command "gcc -pthread -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -I/usr/lib/python2.3/site-packages/scipy/base/include -I/usr/include/python2.3 -c Lib/integrate/_quadpackmodule.c -o build/temp.linux-i686-2.3/Lib/integrate/_quadpackmodule.o" failed with exit status 1 ######################################################################################################################################### cheers, steve -- Should array indices start at 0 or 1? My compromise of 0.5 was rejected without, I thought, proper consideration. -- Stan Kelly-Bootle From arnd.baecker at web.de Sat Dec 10 09:13:42 2005 From: arnd.baecker at web.de (arnd.baecker at web.de) Date: Sat, 10 Dec 2005 15:13:42 +0100 (CET) Subject: [SciPy-user] Benchmark data In-Reply-To: <439A6CC0.6070003@ieee.org> References: <43995919.2090401@ieee.org> <20051209201510.04c352d6.gerard.vermeulen@grenoble.cnrs.fr> <20051210011624.7347cb56.gerard.vermeulen@grenoble.cnrs.fr> <439A6CC0.6070003@ieee.org> Message-ID: On Fri, 9 Dec 2005, Travis Oliphant wrote: > I know people may be tired of the benchmark data, In my opinion just the contrary - the more benchmark results we can get for scipy, the better! What about setting up a `scipy.bench()` suite (similar to `scipy.test()` )? They could be collected as `bench_xxx.py` (and their level could determine how long the are expected to run). For FFT, scipy.test already includes a speed comparison, but I would like to see more of this (Esssentially for all subpackages linalg, sparse, integrate, interpolate stats, random .... and in general for ufunc operations, scalar operations etc.). This would allow to compare the efficiency of different LAPACK variants, compiler settings, different compilers etc. etc. I think it would be great if users could contribute simple benchmark examples of their area of interest. > but I'm just trying to > understand what kinds of techniques produce fast code. I very much appreciate that you take this issue so serious!! [...] > So, I'm not sure how to reproduce what Gerard sees (except numarray's > faster arange) > which is a little perplexing. I suppose that's why people criticize > benchmarks so much. In the end it only counts, how fast a given code is executed. But there is no (easy?) way to find the optimal compile flags - the space spanned by all possible options is just too big. And varying the problem size can lead to different optimal values... The task is not made simpler by different compilers, different CPUs/Cache sizes, different distributions, different kernels, whatever else ... So I would not be surprised at all if gcc 4.x or Intels icc produce different results. Just one remark on bench.py: it uses time.time(). So it does not determine the CPU time of a process. This could be determined with jiffies from scipy.test.testing import jiffies Another option might be timeit.py, see In [4]: import timeit In [5]: timeit? (worth reading!) Some more remarks on profiling, which might be useful to other as well: Python code can be profiled using the `hotshot` module. Together with kcachegrind http://kcachegrind.sourceforge.net/ and Joerg Beyer's script `hotshot2cachegrind.py` you can use a GUI to inspect the profiling results: ############ import hotshot def run(): # call your stuff here .... prof = hotshot.Profile("pythongrind.prof", lineevents=1) prof.runcall(run) prof.close() ############ - this will generate the profiling results in "pythongrind.prof" - then use hotshot2cachegrind -o cachegrind.out.42 pythongrind.prof to convert - Start kcachegrind cachegrind.out.42 which will give a nice graphical interface to the profiling data Remark: kcachegrind can also be used to display profilings of gcc code (However, I don't think it is possible to descend from the python results to the C level of the called functions ...) Note that this is particularly helpful to find and analyze the main bottlenecks in a given code. So in the above case, where the speed of single operations is compared, I don't think it will help much. (Also note, that it takes some time to understand the output; a couple of things still look mysterious to me ;-)... Thanks for all your effort! Best, Arnd From arnd.baecker at web.de Sat Dec 10 11:46:32 2005 From: arnd.baecker at web.de (Arnd Baecker) Date: Sat, 10 Dec 2005 17:46:32 +0100 (CET) Subject: [SciPy-user] Benchmark data In-Reply-To: References: <43995919.2090401@ieee.org> <20051209201510.04c352d6.gerard.vermeulen@grenoble.cnrs.fr> <439A6CC0.6070003@ieee.org> Message-ID: Hi, > > So, I'm not sure how to reproduce what Gerard sees (except numarray's > > faster arange) > > which is a little perplexing. I suppose that's why people criticize > > benchmarks so much. Maybe this one can explain it: > Just one remark on bench.py: it uses time.time(). > So it does not determine the CPU time of a process. > This could be determined with jiffies > from scipy.test.testing import jiffies > Another option might be timeit.py, see > In [4]: import timeit > In [5]: timeit? > (worth reading!) I just tested bench.py with an updated installation on my laptop and wanted to compare it with an older one. The fluctuations between measurements are substantial: TOTAL 25.47 18.81 17.27 TOTAL 22.47 19.03 18.55 TOTAL 22.59 18.92 15.83 (you will like the last one most, I guess ;-) If one uses time.clock() - which is one option on Linux, the timings for the small sizes (4,6, 8?) are essentially 0. For 11 one gets pretty stable results: python bench.py 11 Python 2.3.5 (#2, Sep 4 2005, 22:01:42) [GCC 3.3.5 (Debian 1:3.3.5-13)] Optimization flags: -DNDEBUG -g -O3 -Wall -Wstrict-prototypes CPU info: getNCPUs has_mmx has_sse is_32bit is_Intel is_Pentium is_PentiumII is_PentiumIII is_i686 is_singleCPU Numeric-23.8 numarray-1.1.1 scipy-core-0.8.2.1623 benchmark size = 11 (vectors of length 4194304) label Numeric numarray scipy.base 1 0.38 0.07 0.33 2 0.2 0.15 0.24 3 0.15 0.13 0.23 4 0.99 0.4 0.41 5 0.21 0.16 0.16 6 0.17 0.14 0.22 7 1.02 0.68 0.42 8 0.62 0.33 0.33 9 6.79 5.53 4.76 10 6.78 6.24 4.79 11 5.38 4.8 3.9 TOTAL 22.69 18.63 15.79 Presumably we really should use timeit for the smaller problem sizes ... Best, Arnd From oliphant.travis at ieee.org Sat Dec 10 12:39:27 2005 From: oliphant.travis at ieee.org (Travis Oliphant) Date: Sat, 10 Dec 2005 10:39:27 -0700 Subject: [SciPy-user] gcc error In-Reply-To: <439AC8A8.3050602@gmx.net> References: <1134055230.43984f3e2e8ee@imp3-g19.free.fr> <200512091131.43983.basvandijk@home.nl> <439ABCE7.10607@gmx.net> <439AC8A8.3050602@gmx.net> Message-ID: <439B12CF.1060606@ieee.org> Steve Schmerler wrote: >Thanx for the *fast* _dotblas.c update :). But compiling scipy I get > >######################################################################################################################################### > >python scipy/setup.py install > >[...] > > > Thanks for the note. I changed something to get rid of a compiler warning but changed it badly. I apologize for the mistake. The recent tree instability was brought about by my moving the function pointers out of the type descr structure so that the PyArray_Descr structure just has a pointer to a function-pointer table. Type descriptors are dynamic and can get copied around and this will save a little-bit of unnecessary jostling. This has C-API issues for those who used direct access to the function pointers in the descr table. Now, you reach them through the member named 'f'. Thus what was descr->cast is now descr->f->cast. -Travis From prabhu_r at users.sf.net Sat Dec 10 12:46:49 2005 From: prabhu_r at users.sf.net (Prabhu Ramachandran) Date: Sat, 10 Dec 2005 23:16:49 +0530 Subject: [SciPy-user] C/C++ extension with swig In-Reply-To: References: Message-ID: <17307.5257.893136.420353@monster.iitb.ac.in> >>>>> "JR" == Jaonary Rabarisoa writes: JR> void (double *input, some other args, ...., double JR> *output1, double JR> *output2, ...) JR> The input and output arguments represent arrays (matirx, JR> vectors, .nd- arrays, ...). In python, I'd like to passe the JR> argument as a list (or scipy array) of the form JR> [ [row1], .........., [rowN] ] I sent a related reply on the swig-users list a while back that probably never made it to the list for reasons unknown to me. Anyway, here is part of that message and it might be of some use to you. In short, you could use the buffer protocol of the array. scipy arrays (and Numeric/numarray) feature a buffer protocol (for numarray you need to use the array's '_data' attribute to get a buffer capable object) and internally manages its data using a single "char *data". I've attached a simple example buffer.i file (along with a test_buffer.py example) that should give you an idea of how this can be done. In the example I have some simple for loops to pump the data into scipy (or Numeric or numarray) arrays but you could instead use memcpy or anything else. A faster approach would be to create the scipy array from the Python side and then point your internal data pointers to use the the pointer used by the scipy arrays. This eliminates the need for a copy. I suggest you experiment with the buffer.i and figure out an approach you can use. cheers, prabhu -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: buffer.i URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: test_buffer.py URL: From ckkart at hoc.net Sat Dec 10 13:38:27 2005 From: ckkart at hoc.net (Christian Kristukat) Date: Sat, 10 Dec 2005 19:38:27 +0100 Subject: [SciPy-user] newscipy interp1d Message-ID: <439B20A3.6000105@hoc.net> Hi, I get errors when using scipy.interpolate.interp1d from newscipy like the following: x=linspace(-1,4,20) y=x**2 ip=interp1e(x,y) xn=linspace(-.5,1,200) yn=ip(xn) Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.4/site-packages/scipy/interpolate/interpolate.py", line 180, in __call__ putmask(y_new, new_out.ravel(), self.fill_value) File "/usr/lib/python2.4/site-packages/scipy/base/oldnumeric.py", line 187, in putmask return a.putmask(v, mask) TypeError: array cannot be safely cast to required type I guess this a bug.? Regards, Christian From ckkart at hoc.net Sat Dec 10 14:01:00 2005 From: ckkart at hoc.net (Christian Kristukat) Date: Sat, 10 Dec 2005 20:01:00 +0100 Subject: [SciPy-user] newscipy interp1d In-Reply-To: <439B20A3.6000105@hoc.net> References: <439B20A3.6000105@hoc.net> Message-ID: <439B25EC.50904@hoc.net> Christian Kristukat wrote: > Hi, > I get errors when using scipy.interpolate.interp1d from newscipy like the following: > > x=linspace(-1,4,20) > y=x**2 > ip=interp1e(x,y) > xn=linspace(-.5,1,200) > yn=ip(xn) > > Traceback (most recent call last): > File "", line 1, in ? > File "/usr/lib/python2.4/site-packages/scipy/interpolate/interpolate.py", > line 180, in __call__ > putmask(y_new, new_out.ravel(), self.fill_value) > File "/usr/lib/python2.4/site-packages/scipy/base/oldnumeric.py", line 187, > in putmask > return a.putmask(v, mask) > TypeError: array cannot be safely cast to required type > > I guess this a bug.? > I found out that putmask is not accepting an array object as mask, a python list however is ok. I guess this is not the intended behaviour? Christian From oliphant.travis at ieee.org Sat Dec 10 14:28:52 2005 From: oliphant.travis at ieee.org (Travis Oliphant) Date: Sat, 10 Dec 2005 12:28:52 -0700 Subject: [SciPy-user] newscipy interp1d In-Reply-To: <439B25EC.50904@hoc.net> References: <439B20A3.6000105@hoc.net> <439B25EC.50904@hoc.net> Message-ID: <439B2C74.7030703@ieee.org> Christian Kristukat wrote: >Christian Kristukat wrote: > > >>Hi, >>I get errors when using scipy.interpolate.interp1d from newscipy like the following: >> >>x=linspace(-1,4,20) >>y=x**2 >>ip=interp1e(x,y) >>xn=linspace(-.5,1,200) >>yn=ip(xn) >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.4/site-packages/scipy/interpolate/interpolate.py", >>line 180, in __call__ >> putmask(y_new, new_out.ravel(), self.fill_value) >> File "/usr/lib/python2.4/site-packages/scipy/base/oldnumeric.py", line 187, >>in putmask >> return a.putmask(v, mask) >>TypeError: array cannot be safely cast to required type >> >>I guess this a bug.? >> >> >> This should be fixed. Now, putmask accepts anything as the second argument and converts it to a BOOL array. Previously it was only converting if it could do so "safely". This was an unneccessary restriction. Scipy Core in SVN has the fix and I'll be making a new release of scipy core in a few days. > >I found out that putmask is not accepting an array object as mask, a python list >however is ok. I guess this is not the intended behaviour? > > The problem is that it wasn't taking anything but a BOOL array. It should work better now. -Travis From arnd.baecker at web.de Sat Dec 10 16:18:15 2005 From: arnd.baecker at web.de (Arnd Baecker) Date: Sat, 10 Dec 2005 22:18:15 +0100 (CET) Subject: [SciPy-user] Benchmark data In-Reply-To: References: <43995919.2090401@ieee.org> <20051209201510.04c352d6.gerard.vermeulen@grenoble.cnrs.fr> Message-ID: Hi, enclosed is a short example of a benchmarking test for basic functions. This makes use of the whole machinery already provided by scipy.test, in particular of `measure` which is also used in the tests of fft. On my PIII 1.2 GHz laptop I get: python test_bench.py Importing test to scipy Importing base to scipy Importing basic to scipy Python 2.3.5 (#2, Sep 4 2005, 22:01:42) [GCC 3.3.5 (Debian 1:3.3.5-13)] Optimization flags: -DNDEBUG -g -O3 -Wall -Wstrict-prototypes CPU info: getNCPUs has_mmx has_sse is_32bit is_Intel is_Pentium is_PentiumII is_PentiumIII is_i686 is_singleCPU Numeric: 23.8 numarray: 1.1.1 scipy: 0.8.2.1623 Running pystone... Pystone(1.1) time for 50000 passes = 2.61 This machine benchmarks at 19157.1 pystones/second ==== bench arange ==== size Numeric numarray scipy 10 0.12 1.77 0.18 (secs for 10000 calls) 100 0.20 1.75 0.25 (secs for 10000 calls) 1000 0.44 0.89 0.41 (secs for 5000 calls) 10000 0.77 0.20 0.66 (secs for 1000 calls) 100000 0.79 0.05 0.67 (secs for 100 calls) . ==== bench function: exp ==== size Numeric numarray scipy 10 0.10 0.29 0.17 (secs for 10000 calls) 100 0.28 0.45 0.32 (secs for 10000 calls) 1000 0.99 1.03 0.98 (secs for 5000 calls) 10000 1.93 1.82 1.83 (secs for 1000 calls) 100000 2.13 1.81 1.72 (secs for 100 calls) . ==== bench function: sin ==== size Numeric numarray scipy 10 0.10 0.28 0.16 (secs for 10000 calls) 100 0.20 0.38 0.24 (secs for 10000 calls) 1000 0.62 0.67 0.60 (secs for 5000 calls) 10000 1.19 1.08 1.07 (secs for 1000 calls) 100000 1.30 1.15 1.09 (secs for 100 calls) . ---------------------------------------------------------------------- Ran 6 tests in 36.768s So, apart from arange, it looks very good for scipy! Maybe some developer can have a look over the code (which is a combination of bench.py, the tests in fftpack and some additions), and if it is of sufficient interest it could maybe serve as a basis for adding more routines from all over scipy to get detailed performance coverage? Best, Arnd -------------- next part -------------- A non-text attachment was scrubbed... Name: test_bench.py Type: text/x-python Size: 6912 bytes Desc: URL: From dd55 at cornell.edu Sat Dec 10 17:57:16 2005 From: dd55 at cornell.edu (Darren Dale) Date: Sat, 10 Dec 2005 17:57:16 -0500 Subject: [SciPy-user] test_fft, test_ifft results Message-ID: <200512101757.17068.dd55@cornell.edu> I have been wondering about the results of fftpack.basic.test_basic.test_fft, fftpack.basic.test_basic.test_fftn and fftpack.basic.test_basic.test_ifft. On my system, with scipy built against fftw2 or 3, ffts of complex input takes over 8 times as long as real input. I dont see the same behavior with fftn. Does anyone else see this? Thanks, Darren bench_random (scipy.fftpack.basic.test_basic.test_fft) Fast Fourier Transform ================================================= | real input | complex input ------------------------------------------------- size | scipy | Numeric | scipy | Numeric ------------------------------------------------- 100 | 0.18 | 0.16 | 1.51 | 0.17 (secs for 7000 calls) 1000 | 0.18 | 0.21 | 1.52 | 0.22 (secs for 2000 calls) 256 | 0.35 | 0.34 | 2.90 | 0.33 (secs for 10000 calls) 512 | 0.52 | 0.54 | 4.40 | 0.57 (secs for 10000 calls) 1024 | 0.09 | 0.10 | 0.70 | 0.10 (secs for 1000 calls) 2048 | 0.16 | 0.19 | 1.37 | 0.21 (secs for 1000 calls) 4096 | 0.16 | 0.22 | 1.24 | 0.22 (secs for 500 calls) 8192 | 0.35 | 0.63 | 2.56 | 0.71 (secs for 500 calls) ... ok check_definition (scipy.fftpack.basic.test_basic.test_fft) ... ok check_djbfft (scipy.fftpack.basic.test_basic.test_fft) ... ok check_n_argument_real (scipy.fftpack.basic.test_basic.test_fft) ... ok bench_random (scipy.fftpack.basic.test_basic.test_fftn) Multi-dimensional Fast Fourier Transform =================================================== | real input | complex input --------------------------------------------------- size | scipy | Numeric | scipy | Numeric --------------------------------------------------- 100x100 | 0.15 | 0.20 | 0.14 | 0.21 (secs for 100 calls) 1000x100 | 0.11 | 0.19 | 0.10 | 0.17 (secs for 7 calls) 256x256 | 0.22 | 0.26 | 0.21 | 0.27 (secs for 10 calls) 512x512 | 0.26 | 0.32 | 0.26 | 0.33 (secs for 3 calls) ... ok check_axes_argument (scipy.fftpack.basic.test_basic.test_fftn) ... ok check_definition (scipy.fftpack.basic.test_basic.test_fftn) ... ok check_shape_argument (scipy.fftpack.basic.test_basic.test_fftn) ... ok check_shape_axes_argument (scipy.fftpack.basic.test_basic.test_fftn) ... ok bench_random (scipy.fftpack.basic.test_basic.test_ifft) Inverse Fast Fourier Transform =============================================== | real input | complex input ----------------------------------------------- size | scipy | Numeric | scipy | Numeric ----------------------------------------------- 100 | 0.18 | 0.50 | 1.88 | 0.51 (secs for 7000 calls) 1000 | 0.19 | 0.63 | 1.65 | 0.62 (secs for 2000 calls) 256 | 0.36 | 1.10 | 3.36 | 1.10 (secs for 10000 calls) 512 | 0.57 | 1.85 | 4.81 | 1.77 (secs for 10000 calls) 1024 | 0.10 | 0.32 | 0.86 | 0.32 (secs for 1000 calls) 2048 | 0.17 | 0.61 | 1.40 | 0.61 (secs for 1000 calls) 4096 | 0.18 | 0.64 | 1.44 | 0.67 (secs for 500 calls) 8192 | 0.39 | 1.58 | 2.75 | 1.58 (secs for 500 calls) From dd55 at cornell.edu Sat Dec 10 13:53:24 2005 From: dd55 at cornell.edu (Darren Dale) Date: Sat, 10 Dec 2005 13:53:24 -0500 Subject: [SciPy-user] newscipy interp1d In-Reply-To: <439B20A3.6000105@hoc.net> References: <439B20A3.6000105@hoc.net> Message-ID: <200512101353.24288.dd55@cornell.edu> On Saturday 10 December 2005 1:38 pm, Christian Kristukat wrote: > Hi, > I get errors when using scipy.interpolate.interp1d from newscipy like the > following: > > x=linspace(-1,4,20) > y=x**2 > ip=interp1e(x,y) > xn=linspace(-.5,1,200) > yn=ip(xn) > > Traceback (most recent call last): > File "", line 1, in ? > File > "/usr/lib/python2.4/site-packages/scipy/interpolate/interpolate.py", line > 180, in __call__ > putmask(y_new, new_out.ravel(), self.fill_value) > File "/usr/lib/python2.4/site-packages/scipy/base/oldnumeric.py", line > 187, in putmask > return a.putmask(v, mask) > TypeError: array cannot be safely cast to required type > > I guess this a bug.? This may be a casting problem. I'm not sure of the origin, but I have traced it as far back as the putmask method of the ndarray object: from scipy import * a=arange(10) a.putmask(0,ones(10,'?')) # works ones(10).astype('?') # works a.putmask(0,ones(10)) # doesnt work My hack for getting interp1d to work (until the actual issue is resolved) is to change line 179 in scipy/Lib/interpolate/interpolate.py from new_out = ones(new_shape)*out_of_bounds to new_out = ones(new_shape, '?')*out_of_bounds Darren From oliphant.travis at ieee.org Sun Dec 11 03:46:16 2005 From: oliphant.travis at ieee.org (Travis Oliphant) Date: Sun, 11 Dec 2005 01:46:16 -0700 Subject: [SciPy-user] Arange has been sped up Message-ID: <439BE758.10109@ieee.org> Friends, I've just sped up arange using individual filling loops like numarray does -- and added (untested) complex arange functionality. The benchmarks are showing a marked improvement in the arange function for scipy over its previous performance. Thanks for the testing. Remember this is with a debug-build for scipy on an AMD chip. Python 2.4.2 (#1, Nov 14 2005, 21:26:13) [GCC 3.4.1 (Mandrakelinux 10.1 3.4.1-4mdk)] Optimization flags: -g -Wall -Wstrict-prototypes CPU info: getNCPUs has_3dnow has_3dnowext has_mmx is_32bit is_AMD is_singleCPU Numeric-24.2 numarray-1.5.1 scipy-core-0.8.2.1627 benchmark size = 10 (vectors of length 1048576) label Numeric numarray scipy.base 1 0.1377 0.0505 0.02734 2 0.1017 0.1063 0.09208 3 0.07226 0.07828 0.0825 4 0.4258 0.2689 0.1533 5 0.1126 0.1079 0.08457 6 0.0719 0.07721 0.08304 7 0.3053 0.3167 0.1547 8 0.1958 0.1964 0.1075 9 2.259 2.829 1.775 10 2.221 2.925 1.811 11 1.725 2.329 1.438 TOTAL 7.628 9.285 5.81 For all but lines 3 and 6, scipy_core is apparently doing better on my system. These are lines calling x % y and scipy_core implements the remainder the same way that Python does (thus needing extra checking) which I expect accounts for its tiny slowness -Travis From arnd.baecker at web.de Sun Dec 11 05:53:19 2005 From: arnd.baecker at web.de (Arnd Baecker) Date: Sun, 11 Dec 2005 11:53:19 +0100 (CET) Subject: [SciPy-user] Arange has been sped up In-Reply-To: <439BE758.10109@ieee.org> References: <439BE758.10109@ieee.org> Message-ID: Hi, On Sun, 11 Dec 2005, Travis Oliphant wrote: > Friends, > > I've just sped up arange using individual filling loops like numarray > does -- and added (untested) complex arange functionality. > > The benchmarks are showing a marked improvement in the arange function > for scipy over its previous performance. Thanks for the testing. On laptop I get for `python test_bench.py`: Python 2.3.5 (#2, Sep 4 2005, 22:01:42) [GCC 3.3.5 (Debian 1:3.3.5-13)] Optimization flags: -DNDEBUG -g -O3 -Wall -Wstrict-prototypes CPU info: getNCPUs has_mmx has_sse is_32bit is_Intel is_Pentium is_PentiumII is_PentiumIII is_i686 is_singleCPU Numeric: 23.8 numarray: 1.1.1 Running pystone... Pystone(1.1) time for 50000 passes = 2.6 This machine benchmarks at 19230.8 pystones/second scipy: 0.8.2.1623 ==== bench arange ==== size Numeric numarray scipy 10 0.12 1.77 0.18 (secs for 10000 calls) 100 0.20 1.75 0.25 (secs for 10000 calls) 1000 0.44 0.89 0.41 (secs for 5000 calls) 10000 0.77 0.20 0.66 (secs for 1000 calls) 100000 0.79 0.05 0.67 (secs for 100 calls) scipy: 0.8.3.1630 ==== bench arange ==== size Numeric numarray scipy 10 0.12 1.77 0.18 (secs for 10000 calls) 100 0.20 1.80 0.20 (secs for 10000 calls) 1000 0.44 0.90 0.11 (secs for 5000 calls) 10000 0.78 0.20 0.04 (secs for 1000 calls) 100000 0.83 0.06 0.05 (secs for 100 calls) So only at small array sizes Numeric is faster (if one can believe the benchmark ;-). The data suggest that the crossover is at around 100. For the larger sizes getting a factor of more than 10 is impressive!! My compliments, Travis! Best, Arnd From aisaac at american.edu Sun Dec 11 09:22:37 2005 From: aisaac at american.edu (Alan G Isaac) Date: Sun, 11 Dec 2005 09:22:37 -0500 Subject: [SciPy-user] buffered data not permissible Message-ID: Here's a simple illustration of a problem that surprised me: one can create a working array with zip but not with izip. It appears intentional. Can someone tell me why? Two things looking like a small bug. If you make an array out of an itertools.izip object: - the result is not iterable - it's representation is that it is an itertools.izip object (which seems to be false) Thank you, Alan Isaac >>> scipy.base.__version__ '0.4.2.1252' >>> x=scipy.array(zip(xrange(5),itertools.cycle([1]))) >>> x array([[0, 1], [1, 1], [2, 1], [3, 1], [4, 1]]) >>> x=scipy.array(itertools.izip(xrange(5),itertools.cycle([1]))) >>> x >>> type(x) >>> list(x) Traceback (most recent call last): File "", line 1, in ? TypeError: iteration over non-sequence >>> x=scipy.mat(zip(xrange(5),itertools.cycle([1]))) >>> x=scipy.mat(itertools.izip(xrange(5),itertools.cycle([1]))) Traceback (most recent call last): File "", line 1, in ? File "C:\Python24\lib\site-packages\scipy\base\matrix.py", line 87, in __new__ swap=(not arr.flags['NOTSWAPPED'])) TypeError: cannot construct an object array from buffer data. >>> From elcorto at gmx.net Sun Dec 11 10:06:15 2005 From: elcorto at gmx.net (Steve Schmerler) Date: Sun, 11 Dec 2005 16:06:15 +0100 Subject: [SciPy-user] floating point exeption In-Reply-To: <4391EEB3.9030207@astraw.com> References: <438DCA77.8070303@att.net> <438E152B.6050804@csun.edu> <438E92EB.9030106@att.net> <439191BA.5080403@gmx.net> <4391DAC1.1020706@gmx.net> <4391EEB3.9030207@astraw.com> Message-ID: <439C4067.8050901@gmx.net> Andrew Straw wrote: > Steve Schmerler wrote: > > >> scipy.test() >> >>I get a floating point exception: >> >>...................................................................................... >>......................................................................................................................... >>.............................Gleitkomma-Ausnahme >> >> > > > Are you running Debian sarge on a machine with SSE? > > GNU libc version 2.3.2 has a bug[1] "feclearexcept() error on CPUs with > SSE" (fixed in 2.3.3) which has been submitted to Debian[2] but not > fixed in sarge. You can see my page about the issue, complete with patch[3]. > > [1] http://sources.redhat.com/bugzilla/show_bug.cgi?id=10 > [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=279294 > [3] > http://www.its.caltech.edu/~astraw/coding.html#libc-patched-for-debian-sarge-to-fix-floating-point-exceptions-on-sse2 > As mentioned in a previous mail the exception occures when calling some fumctions in scipy.special._cephes. I'm running Debian sarge stable. Some days ago I pretended that my CPU doesn't have SSE, but a look in /proc/cpuinfo reveals ----------------------------------------------------------------------------------- processor : 0 vendor_id : AuthenticAMD cpu family : 6 model : 8 model name : AMD Athlon(TM) XP 2400+ stepping : 1 cpu MHz : 1990.656 cache size : 256 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse syscall mmxext 3dnowext 3dnow bogomips : 3984.77 ----------------------------------------------------------------------------------- Is the patch [3] for SSE and/or SSE2? I'm relatively new to Linux and don't really feel like fiddling with my libc :) Is it advisable to install libc6 from testing (version 2.3.5)? cheers, steve -- Should array indices start at 0 or 1? My compromise of 0.5 was rejected without, I thought, proper consideration. -- Stan Kelly-Bootle From ckkart at hoc.net Sun Dec 11 10:50:03 2005 From: ckkart at hoc.net (Christian Kristukat) Date: Sun, 11 Dec 2005 16:50:03 +0100 Subject: [SciPy-user] transition problems Message-ID: <439C4AAB.70308@hoc.net> Hi, I noticed that using the new core together with older packages that are based on numeric, like the plotting module from wxPython, matplotlib, grace_np.py, etc. is problematic since numeric seems to be unable to recognize new core arrays as equivalent to the numeric ones. In some cases it is sufficient to add a .tolist() to array parameters but that is not really satisfactory. Will a final version of new core have solved these incompatibilities? Regards, Christian From ckkart at hoc.net Sun Dec 11 10:51:56 2005 From: ckkart at hoc.net (Christian Kristukat) Date: Sun, 11 Dec 2005 16:51:56 +0100 Subject: [SciPy-user] newscipy interp1d In-Reply-To: <439B2C74.7030703@ieee.org> References: <439B20A3.6000105@hoc.net> <439B25EC.50904@hoc.net> <439B2C74.7030703@ieee.org> Message-ID: <439C4B1C.9010506@hoc.net> Travis Oliphant wrote: > Christian Kristukat wrote: > > >>Christian Kristukat wrote: >> >> >> >>>Hi, >>>I get errors when using scipy.interpolate.interp1d from newscipy like the following: >>> >>>x=linspace(-1,4,20) >>>y=x**2 >>>ip=interp1e(x,y) >>>xn=linspace(-.5,1,200) >>>yn=ip(xn) >>> >>>Traceback (most recent call last): >>> File "", line 1, in ? >>> File "/usr/lib/python2.4/site-packages/scipy/interpolate/interpolate.py", >>>line 180, in __call__ >>> putmask(y_new, new_out.ravel(), self.fill_value) >>> File "/usr/lib/python2.4/site-packages/scipy/base/oldnumeric.py", line 187, >>>in putmask >>> return a.putmask(v, mask) >>>TypeError: array cannot be safely cast to required type >>> >>>I guess this a bug.? >>> >>> >>> > > This should be fixed. Now, putmask accepts anything as the second > argument and converts it to a BOOL array. Previously it was only > converting if it could do so "safely". This was an unneccessary > restriction. > > Scipy Core in SVN has the fix and I'll be making a new release of scipy > core in a few days. > > >>I found out that putmask is not accepting an array object as mask, a python list >>however is ok. I guess this is not the intended behaviour? >> >> > > The problem is that it wasn't taking anything but a BOOL array. It > should work better now. It does. Thanks. Christian From prabhu_r at users.sf.net Sun Dec 11 11:10:43 2005 From: prabhu_r at users.sf.net (Prabhu Ramachandran) Date: Sun, 11 Dec 2005 21:40:43 +0530 Subject: [SciPy-user] floating point exeption In-Reply-To: <439C4067.8050901@gmx.net> References: <438DCA77.8070303@att.net> <438E152B.6050804@csun.edu> <438E92EB.9030106@att.net> <439191BA.5080403@gmx.net> <4391DAC1.1020706@gmx.net> <4391EEB3.9030207@astraw.com> <439C4067.8050901@gmx.net> Message-ID: <17308.20355.659936.212329@monster.iitb.ac.in> >>>>> "Steve" == Steve Schmerler writes: Steve> I'm relatively new to Linux and don't really feel like Steve> fiddling with my libc :) Is it advisable to install libc6 Steve> from testing (version 2.3.5)? There are links to recompiled debs for sarge on Andrew's page (they work for me on sarge). Here it is: http://www.its.caltech.edu/~astraw/debian_glibc_patch_r22/ Get the libc6*_2.3.2.ds1-22.1_i386.deb files corresponding to what you have installed on your system (run dpkg -l libc6* to find out), install them with "dpkg -i *.deb" and you should be all set. cheers, prabhu From robert.kern at gmail.com Sun Dec 11 13:21:33 2005 From: robert.kern at gmail.com (Robert Kern) Date: Sun, 11 Dec 2005 10:21:33 -0800 Subject: [SciPy-user] transition problems In-Reply-To: <439C4AAB.70308@hoc.net> References: <439C4AAB.70308@hoc.net> Message-ID: <439C6E2D.6070707@gmail.com> Christian Kristukat wrote: > Hi, > I noticed that using the new core together with older packages that are based on > numeric, like the plotting module from wxPython, matplotlib, grace_np.py, etc. > is problematic since numeric seems to be unable to recognize new core arrays as > equivalent to the numeric ones. In some cases it is sufficient to add a > .tolist() to array parameters but that is not really satisfactory. > Will a final version of new core have solved these incompatibilities? Generally, scipy_core should work fine with Numeric 24.x. What version of Numeric are you using? -- Robert Kern robert.kern at gmail.com "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter From oliphant.travis at ieee.org Sun Dec 11 15:53:47 2005 From: oliphant.travis at ieee.org (Travis Oliphant) Date: Sun, 11 Dec 2005 13:53:47 -0700 Subject: [SciPy-user] transition problems In-Reply-To: <439C4AAB.70308@hoc.net> References: <439C4AAB.70308@hoc.net> Message-ID: <439C91DB.1060505@ieee.org> Christian Kristukat wrote: >Hi, >I noticed that using the new core together with older packages that are based on >numeric, like the plotting module from wxPython, matplotlib, grace_np.py, etc. >is problematic since numeric seems to be unable to recognize new core arrays as >equivalent to the numeric ones. > If you get a recent version (>=24.0) of Numeric then it shouldn't be a problem. One of the purposes of the array interface is to ease the transition, but only recent versions of Numeric use it properly. If there are problems with recent versions of Numeric and the array interface then please post them. Older versions of Numeric would need to use tostring and fromstring (better than tolist...) >In some cases it is sufficient to add a >.tolist() to array parameters but that is not really satisfactory. >Will a final version of new core have solved these incompatibilities? > > Unfortunately, I don't know how to solve incompatibilities with older versions of Numeric. All third-party libraries should either start using only the array interface or switch to scipy_core. I've noticed there is some confusion still circulating on the net that the new arrayobject in scipy_core is going to get into Python at some point, and some people are holding off making any changes until that happens. I am probably the source of that confusion since at one time I did have that goal. However, early on (in March) after discussions with Paul, Perry, and Guido we decided that trying to force an arrayobject into Python would place us on a release cycle that would be constraining. So, don't wait to try out scipy_core because there is nothing going into Python any time soon that is even as capable as Numeric. There are plans for getting a very simple arrayobject into Python (largely to enshrine the array interface), but we really need help moving that forward. With the recent changes to scipy_core, I think we have a very good design for a generic array object with associated data-descriptor that could go into Python. For python itself, I would only say that descriptors should only be written for Object, integer, float, and complex-float arrays. A PEP has been started and sits at http://svn.scipy.org/svn/PEP waiting for more people to help push it forward. Best, -Travis From elcorto at gmx.net Sun Dec 11 14:01:32 2005 From: elcorto at gmx.net (Steve Schmerler) Date: Sun, 11 Dec 2005 20:01:32 +0100 Subject: [SciPy-user] floating point exeption In-Reply-To: <17308.20355.659936.212329@monster.iitb.ac.in> References: <438DCA77.8070303@att.net> <438E152B.6050804@csun.edu> <438E92EB.9030106@att.net> <439191BA.5080403@gmx.net> <4391DAC1.1020706@gmx.net> <4391EEB3.9030207@astraw.com> <439C4067.8050901@gmx.net> <17308.20355.659936.212329@monster.iitb.ac.in> Message-ID: <439C778C.2010004@gmx.net> Prabhu Ramachandran wrote: >>>>>>"Steve" == Steve Schmerler writes: > > > Steve> I'm relatively new to Linux and don't really feel like > Steve> fiddling with my libc :) Is it advisable to install libc6 > Steve> from testing (version 2.3.5)? > > There are links to recompiled debs for sarge on Andrew's page (they > work for me on sarge). Here it is: > > http://www.its.caltech.edu/~astraw/debian_glibc_patch_r22/ > > Get the libc6*_2.3.2.ds1-22.1_i386.deb files corresponding to what you > have installed on your system (run dpkg -l libc6* to find out), > install them with "dpkg -i *.deb" and you should be all set. > > cheers, > prabhu > I was a bit affraid of patching libc but it works now. Thanx a lot!! cheers, steve -- Should array indices start at 0 or 1? My compromise of 0.5 was rejected without, I thought, proper consideration. -- Stan Kelly-Bootle From dd55 at cornell.edu Sun Dec 11 14:40:48 2005 From: dd55 at cornell.edu (Darren Dale) Date: Sun, 11 Dec 2005 14:40:48 -0500 Subject: [SciPy-user] recognizing djbfft In-Reply-To: <200511292029.23404.dd55@cornell.edu> References: <200511292029.23404.dd55@cornell.edu> Message-ID: <200512111440.48878.dd55@cornell.edu> On Tuesday 29 November 2005 8:29 pm, Darren Dale wrote: > Could someone tell me if svn scipy will recognize djbfft? I have > djbfft-0.76 installed, in /usr/lib/ and /usr/include, but scipy does not > find it according to the output of system_info.py. I would like to suggest that line 593 in distutils/system_info.py be changed to include the libdjbfft.so: p = self.combine_paths (d,['libdjbfft.a', 'libdjbfft.so']) Darren From dd55 at cornell.edu Sun Dec 11 14:53:37 2005 From: dd55 at cornell.edu (Darren Dale) Date: Sun, 11 Dec 2005 14:53:37 -0500 Subject: [SciPy-user] test_fft, test_ifft results In-Reply-To: <200512101757.17068.dd55@cornell.edu> References: <200512101757.17068.dd55@cornell.edu> Message-ID: <200512111453.37257.dd55@cornell.edu> On Saturday 10 December 2005 5:57 pm, Darren Dale wrote: > I have been wondering about the results of > fftpack.basic.test_basic.test_fft, fftpack.basic.test_basic.test_fftn and > fftpack.basic.test_basic.test_ifft. On my system, with scipy built against > fftw2 or 3, ffts of complex input takes over 8 times as long as real input. I would like to clarify this report. I thought that editing site.cfg to find fftw-2 would make scipy build against it, but this is not the case. One can build scipy with support for only fftw-2 by commenting out the fftw3 dictionary in the fftw_info class in scipy/distutils/systeminfo.py. The performance of fft's for complex and real input are comparable if scipy is built with fftw-2 in this way. According to some benchmarks posted at http://www.fftw.org/speed/p4-2.2GHz-gcc/ , version 3 should be faster than version 2. However, I haven't been able to build benchfft and test my own installation independent of scipy. Darren From prabhu_r at users.sf.net Sun Dec 11 23:24:48 2005 From: prabhu_r at users.sf.net (Prabhu Ramachandran) Date: Mon, 12 Dec 2005 09:54:48 +0530 Subject: [SciPy-user] floating point exeption In-Reply-To: <439C778C.2010004@gmx.net> References: <438DCA77.8070303@att.net> <438E152B.6050804@csun.edu> <438E92EB.9030106@att.net> <439191BA.5080403@gmx.net> <4391DAC1.1020706@gmx.net> <4391EEB3.9030207@astraw.com> <439C4067.8050901@gmx.net> <17308.20355.659936.212329@monster.iitb.ac.in> <439C778C.2010004@gmx.net> Message-ID: <17308.64400.784597.994429@monster.iitb.ac.in> >>>>> "Steve" == Steve Schmerler writes: >> http://www.its.caltech.edu/~astraw/debian_glibc_patch_r22/ Steve> I was a bit affraid of patching libc but it works Steve> now. Thanx a lot!! BTW, please also install the locales deb that is available there, if you don't your existing locales package will be unhappy... cheers, prabhu From arnd.baecker at web.de Mon Dec 12 03:28:07 2005 From: arnd.baecker at web.de (Arnd Baecker) Date: Mon, 12 Dec 2005 09:28:07 +0100 (CET) Subject: [SciPy-user] test_fft, test_ifft results In-Reply-To: <200512111453.37257.dd55@cornell.edu> References: <200512101757.17068.dd55@cornell.edu> <200512111453.37257.dd55@cornell.edu> Message-ID: Hi Darren and all fft-enthusiasts, On Sun, 11 Dec 2005, Darren Dale wrote: > On Saturday 10 December 2005 5:57 pm, Darren Dale wrote: > > I have been wondering about the results of > > fftpack.basic.test_basic.test_fft, fftpack.basic.test_basic.test_fftn and > > fftpack.basic.test_basic.test_ifft. On my system, with scipy built against > > fftw2 or 3, ffts of complex input takes over 8 times as long as real input. > > I would like to clarify this report. I thought that editing site.cfg to find > fftw-2 would make scipy build against it, but this is not the case. One can > build scipy with support for only fftw-2 by commenting out the fftw3 > dictionary in the fftw_info class in scipy/distutils/systeminfo.py. The > performance of fft's for complex and real input are comparable if scipy is > built with fftw-2 in this way. On Itanium2, we also get that fftw3 performs badly for the complex case http://www.scipy.net/pipermail/scipy-dev/2005-December/004408.html The same holds for the 64 Bit Opteron machine. Also note, that fftw3 support was only added recently (http://www.scipy.net/pipermail/scipy-dev/2005-November/003989.html) to new scipy. I also think that it might not have recieved much testing in old scipy, as it has been added only in July http://www.scipy.org/documentation/mailman?fn=scipy-dev/2005-July/003061.html Over the weekend I did some checks comparing the fftw performance for "old" scipy (fftw2 only) and new scipy (fft2 and fftw3) on my PIII laptop, see test_AB.png. Darren also has sent me his results off-list, see test_DD.png. Both plots (and the script + input file) are at http://www.physik.tu-dresden.de/~baecker/tmp/fftw/ and display the ratio of the scipy time vs. Numeric time for the fftw, so anything below 1 is not ok. E.g. for data like: Fast Fourier Transform ================================================= | real input | complex input ------------------------------------------------- size | scipy | Numeric | scipy | Numeric ------------------------------------------------- 100 | 0.23 | 0.23 | 1.56 | 0.23 (secs for 7000 calls) 1000 | 0.17 | 0.31 | 1.62 | 0.30 (secs for 2000 calls) 256 | 0.40 | 0.46 | 3.21 | 0.47 (secs for 10000 calls) 512 | 0.55 | 0.84 | 4.19 | 0.81 (secs for 10000 calls) 1024 | 0.09 | 0.16 | 0.67 | 0.15 (secs for 1000 calls) 2048 | 0.16 | 0.28 | 1.16 | 0.30 (secs for 1000 calls) 4096 | 0.17 | 0.30 | 1.08 | 0.29 (secs for 500 calls) 8192 | 0.46 | 1.04 | 2.38 | 1.01 (secs for 500 calls) I looked at the profiling output (on the scipy side) for the fftw2 and and fftw3 case, but could not see any difference which could cause the above effect. > According to some benchmarks posted at > http://www.fftw.org/speed/p4-2.2GHz-gcc/ , version 3 should be faster than > version 2. And for 1D complex, size 8192 fftw3 would almost be a factor of 2 faster than fftw2!! For 1D real, size 8192 it is still about 1.5. > However, I haven't been able to build benchfft and test my own > installation independent of scipy. There is another way, if you built fftw3 from source: see fftw-3.0.1/tests/README ./bench -opatient -s icf8192 ./bench -opatient -s irf8192 and for 2D: ./bench -opatient -s icf256x256 Remarks - ./bench does not exist for fftw2 - i: in-place (o: out-of-place) - c: complex (r: real) - f: forward (b: backwards fft) Hope that this somehow helps to get all this sorted! Could maybe some scipy/fft(pack) expert explain, why for FFTW3 no caching is needed (see scipy/Lib/fftpack/src/zfft.c), whereas for FFTW2 this is done? ((Presumably all this is explained in http://www.fftw.org/fftw-paper-ieee.pdf but, at a quick glance I could not extract the relevant information...)) Best, Arnd From cimrman3 at ntc.zcu.cz Mon Dec 12 04:16:52 2005 From: cimrman3 at ntc.zcu.cz (Robert Cimrman) Date: Mon, 12 Dec 2005 10:16:52 +0100 Subject: [SciPy-user] C/C++ extension with swig In-Reply-To: References: Message-ID: <439D4004.5040805@ntc.zcu.cz> Jaonary Rabarisoa wrote: > Hi all, > > I'd like to write a python interface for some c/c++ code. I've > already done this with the standard way (without swig) and now, I'd > like to use swig. > The code that I like to wrap is like this : > > void (double *input, some other args, ...., double *output1, double > *output2, ...) > > > The input and output arguments represent arrays (matirx, vectors, .nd- > arrays, ...). In python, I'd like to passe the argument as a list (or > scipy array) of the form > > [ [row1], .........., [rowN] ] > > and so the outputs are. > > My problem in the type mapping (Python -> C/C++ and C/C++ -> Python). > I found in the swig documentation some hint about this but nowhere > there are usefull information on how to use use scipy arrays without > pain and transparently. I tryed to follow the example of > scipy.cluster.vq but I doesn't work anymore. This issue is already > mentionned here. You can also have a look at scipy/Lib/sandbox/umfpack/umfpack.i, which is less complex than the interace file of scipy.cluster.vq. (It might be too simple for your purposes, but anyway...) cheers, r. From ckkart at hoc.net Mon Dec 12 04:32:19 2005 From: ckkart at hoc.net (Christian Kristukat) Date: Mon, 12 Dec 2005 10:32:19 +0100 Subject: [SciPy-user] transition problems In-Reply-To: <439C91DB.1060505@ieee.org> References: <439C4AAB.70308@hoc.net> <439C91DB.1060505@ieee.org> Message-ID: <439D43A3.8040107@hoc.net> Travis Oliphant wrote: > Christian Kristukat wrote: > > >>Hi, >>I noticed that using the new core together with older packages that are based on >>numeric, like the plotting module from wxPython, matplotlib, grace_np.py, etc. >>is problematic since numeric seems to be unable to recognize new core arrays as >>equivalent to the numeric ones. >> > > If you get a recent version (>=24.0) of Numeric then it shouldn't be a > problem. One of the purposes of the array interface is to ease the > transition, but only recent versions of Numeric use it properly. If > there are problems with recent versions of Numeric and the array > interface then please post them. > Nice to hear that transition will be easy. Unfortunately I'm already using Numeric 24.0. I wrote a small example using wxPython which works with Numeric but doesn't with scipy.base: import wx from wx.lib import plot from scipy.base import * #from Numeric import * class MyApp(wx.App): def OnInit(self): wx.InitAllImageHandlers() frame = plot.TestFrame(None, -1, "PlotCanvas") #frame.Show(True) gr = plot.PlotGraphics([plot.PolyLine(transpose([arange(10),arange(10)]))]) frame.client.Draw(gr) self.SetTopWindow(frame) return True app = MyApp(0) app.MainLoop() Regards, Christian From oliphant.travis at ieee.org Mon Dec 12 05:12:32 2005 From: oliphant.travis at ieee.org (Travis Oliphant) Date: Mon, 12 Dec 2005 03:12:32 -0700 Subject: [SciPy-user] transition problems In-Reply-To: <439D43A3.8040107@hoc.net> References: <439C4AAB.70308@hoc.net> <439C91DB.1060505@ieee.org> <439D43A3.8040107@hoc.net> Message-ID: <439D4D10.9060101@ieee.org> Christian Kristukat wrote: >Travis Oliphant wrote: > > >>Christian Kristukat wrote: >> >> >> >> >>>Hi, >>>I noticed that using the new core together with older packages that are based on >>>numeric, like the plotting module from wxPython, matplotlib, grace_np.py, etc. >>>is problematic since numeric seems to be unable to recognize new core arrays as >>>equivalent to the numeric ones. >>> >>> >>> >>If you get a recent version (>=24.0) of Numeric then it shouldn't be a >>problem. One of the purposes of the array interface is to ease the >>transition, but only recent versions of Numeric use it properly. If >>there are problems with recent versions of Numeric and the array >>interface then please post them. >> >> >> > >Nice to hear that transition will be easy. Unfortunately I'm already using >Numeric 24.0. I wrote a small example using wxPython which works with Numeric >but doesn't with scipy.base: > > You should show us the error so we can be sure, but... This problem looks like it is with the third-party library (wx in this case) --- and there is no way to eliminate all such problems until people get behind a single library (or at least a single interface). This will just take people willing to make the required patches. All such third-party libraries should convert to scipy_core as soon as possible. Now, it might be as simple as re-compling the library after replacing #include Numeric/arrayobject.h with #include scipy/arrayobject.h Or, if the third-party libraries asked Numeric to translate the object into a Numeric array, then they will work when compiled against Numeric 24.x. However, if the library intentionally failed unless the object was a Numeric array (which I suspect the PolyLine function did when it was compiled against the Numeric C-API), then the only way to get it to work is to re-compile against the scipy_core library. While the transistion is really not difficult for third-party developers (we managed to convert the entire scipy library very quickly), it does take some effort. In the mean time, what you can do is use Numeric and scipy together so that before you hand off to a third-party app compiled against Numeric, convert your scipy array to a Numeric array and then use the Numeric array in the third-party app. If you use array(<>, copy=0) then no copying should be done: numeric_array = Numeric.array(scipy_array,copy=0) or numeric_array = Numeric.asarray(scipy_array) which does copy=0 by default. -Travis From elcorto at gmx.net Mon Dec 12 09:29:31 2005 From: elcorto at gmx.net (Steve Schmerler) Date: Mon, 12 Dec 2005 15:29:31 +0100 Subject: [SciPy-user] floating point exeption In-Reply-To: <17308.64400.784597.994429@monster.iitb.ac.in> References: <438DCA77.8070303@att.net> <438E152B.6050804@csun.edu> <438E92EB.9030106@att.net> <439191BA.5080403@gmx.net> <4391DAC1.1020706@gmx.net> <4391EEB3.9030207@astraw.com> <439C4067.8050901@gmx.net> <17308.20355.659936.212329@monster.iitb.ac.in> <439C778C.2010004@gmx.net> <17308.64400.784597.994429@monster.iitb.ac.in> Message-ID: <439D894B.1010908@gmx.net> Prabhu Ramachandran wrote: >>>>>>"Steve" == Steve Schmerler writes: > > > >> http://www.its.caltech.edu/~astraw/debian_glibc_patch_r22/ > > Steve> I was a bit affraid of patching libc but it works > Steve> now. Thanx a lot!! > > BTW, please also install the locales deb that is available there, if > you don't your existing locales package will be unhappy... > Thanks. After asking dpkg -l I Installed libc6_2.3.2.ds1-22.1_i386.deb libc6-dev_2.3.2.ds1-22.1_i386.deb locales_2.3.2.ds1-22.1_all.deb Everything works fine so far. cheers, steve -- Should array indices start at 0 or 1? My compromise of 0.5 was rejected without, I thought, proper consideration. -- Stan Kelly-Bootle From elcorto at gmx.net Mon Dec 12 09:34:06 2005 From: elcorto at gmx.net (Steve Schmerler) Date: Mon, 12 Dec 2005 15:34:06 +0100 Subject: [SciPy-user] keep scipy quiet In-Reply-To: <17308.64400.784597.994429@monster.iitb.ac.in> References: <438DCA77.8070303@att.net> <438E152B.6050804@csun.edu> <438E92EB.9030106@att.net> <439191BA.5080403@gmx.net> <4391DAC1.1020706@gmx.net> <4391EEB3.9030207@astraw.com> <439C4067.8050901@gmx.net> <17308.20355.659936.212329@monster.iitb.ac.in> <439C778C.2010004@gmx.net> <17308.64400.784597.994429@monster.iitb.ac.in> Message-ID: <439D8A5E.2070706@gmx.net> Hi I'm sure this question has been asked before, but how can I get rid of the "importing to scipy" messages. ########################################################################### In [1]: import scipy Importing test to scipy Importing base to scipy Importing basic to scipy Importing io to scipy Importing fftpack to scipy Importing special to scipy Importing cluster to scipy Importing sparse to scipy Importing utils to scipy Importing interpolate to scipy Importing lib to scipy Importing signal to scipy Importing integrate to scipy Importing optimize to scipy Importing linalg to scipy Importing stats to scipy ########################################################################### cheers, steve -- Should array indices start at 0 or 1? My compromise of 0.5 was rejected without, I thought, proper consideration. -- Stan Kelly-Bootle From dd55 at cornell.edu Mon Dec 12 09:40:18 2005 From: dd55 at cornell.edu (Darren Dale) Date: Mon, 12 Dec 2005 09:40:18 -0500 Subject: [SciPy-user] keep scipy quiet In-Reply-To: <439D8A5E.2070706@gmx.net> References: <438DCA77.8070303@att.net> <17308.64400.784597.994429@monster.iitb.ac.in> <439D8A5E.2070706@gmx.net> Message-ID: <200512120940.18874.dd55@cornell.edu> On Monday 12 December 2005 09:34, Steve Schmerler wrote: > Hi > > I'm sure this question has been asked before, but how can I get rid of > the "importing to scipy" messages. Comment out line 119 in scipy_core's scipy/_import_tools.py file: print 'Importing',package_name,'to',self.parent_name Darren From cdavis at staffmail.ed.ac.uk Mon Dec 12 10:33:45 2005 From: cdavis at staffmail.ed.ac.uk (Cory Davis) Date: Mon, 12 Dec 2005 15:33:45 +0000 Subject: [SciPy-user] keep scipy quiet In-Reply-To: <200512120940.18874.dd55@cornell.edu> References: <438DCA77.8070303@att.net> <17308.64400.784597.994429@monster.iitb.ac.in> <439D8A5E.2070706@gmx.net> <200512120940.18874.dd55@cornell.edu> Message-ID: <439D9859.5030808@staffmail.ed.ac.uk> Shouldn't the default be to say nothing? There was a similar discussion earlier regarding the "numerix Numeric xx.x" message and the consensus was that unless something has gone wrong, there shouldn't be any screen output at all. These messages can be a real pain, for instance when using pipes to communicate between processes. Also, not everyone has root access, so can't make the suggested change. I think it would be better if this message was disabled in the scipy distribution. Cheers, Cory. Darren Dale wrote: > On Monday 12 December 2005 09:34, Steve Schmerler wrote: > >>Hi >> >>I'm sure this question has been asked before, but how can I get rid of >>the "importing to scipy" messages. > > > Comment out line 119 in scipy_core's scipy/_import_tools.py file: > > print 'Importing',package_name,'to',self.parent_name > > Darren > > _______________________________________________ > SciPy-user mailing list > SciPy-user at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-user -- --------------------------------------------------- Cory Davis Institute for Atmospheric and Environmental Science Room 307, Crew Building, Kings Buildings, University of Edinburgh. Edinburgh EH9 3JN phone: +44 131 6505092 www: http://www.geos.ed.ac.uk/contacts/homes/cdavis From alexander.borghgraef.rma at gmail.com Mon Dec 12 11:01:44 2005 From: alexander.borghgraef.rma at gmail.com (Alexander Borghgraef) Date: Mon, 12 Dec 2005 17:01:44 +0100 Subject: [SciPy-user] Divide by zero is inf? Message-ID: <9e8c52a20512120801h539c9544y328be00c35d894e2@mail.gmail.com> Hi all, I'm trying to convert a field of 2Dvectors (3D-array) from Cartesian to pole coordinates. Now I would like to use as few for loops as possible, and use ufuncs instead. However, in calculating the angle coordinate via the formula "theta = arctan(y/x)", there is a risk of division by zero. In a for-loop scheme, this is easily solved by adding a test inside the loop, checking for x == 0, but there's no such thing for a ufunc scheme. Now, I am aware of the existence of "inf" in scipy, and since "arctan(inf) == pi /2", there should be no problem with the following code: vectorField = array( [ zeros( [10,10] ), ones( [10,10] ) ] ) poleField = array( [ sqrt( sum( vectorField **2 ) ), arctan( vectorField[ 1, :, :] / vectorField[ 0, :, :] ) ] ) However, I can't seem to find out how to do division by zero resulting in "inf", I always get a "ZeroDivisionError" exception. How do I do this? Any other suggestions of solving similar problems with ufuncs? I'm currently using scipy 0.3.2, with Numeric 24.1. -- Alex Borghgraef -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryanlists at gmail.com Mon Dec 12 11:32:03 2005 From: ryanlists at gmail.com (Ryan Krauss) Date: Mon, 12 Dec 2005 11:32:03 -0500 Subject: [SciPy-user] Divide by zero is inf? In-Reply-To: <9e8c52a20512120801h539c9544y328be00c35d894e2@mail.gmail.com> References: <9e8c52a20512120801h539c9544y328be00c35d894e2@mail.gmail.com> Message-ID: Use arctan2: In [50]: arctan2(1,0) Out[50]: 1.5707963267948966 On 12/12/05, Alexander Borghgraef wrote: > Hi all, > > I'm trying to convert a field of 2Dvectors (3D-array) from Cartesian to > pole coordinates. Now I would like to use as > few for loops as possible, and use ufuncs instead. However, in calculating > the angle coordinate via the formula > "theta = arctan(y/x)", there is a risk of division by zero. In a for-loop > scheme, this is easily solved by adding a test inside > the loop, checking for x == 0, but there's no such thing for a ufunc > scheme. > Now, I am aware of the existence of "inf" in scipy, and since > "arctan(inf) == pi /2", there should be no problem with the > following code: > > > vectorField = array( [ zeros( [10,10] ), ones( [10,10] ) ] ) > > poleField = array( [ sqrt( sum( vectorField **2 ) ), arctan( vectorField[ 1, > :, :] / vectorField[ 0, :, :] ) ] ) > > However, I can't seem to find out how to do division by zero resulting in > "inf", I always get a "ZeroDivisionError" > exception. How do I do this? Any other suggestions of solving similar > problems with ufuncs? I'm currently using scipy 0.3.2, > with Numeric 24.1. > > > -- > Alex Borghgraef > _______________________________________________ > SciPy-user mailing list > SciPy-user at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-user > > > From jh at oobleck.astro.cornell.edu Mon Dec 12 11:38:41 2005 From: jh at oobleck.astro.cornell.edu (Joe Harrington) Date: Mon, 12 Dec 2005 11:38:41 -0500 Subject: [SciPy-user] keep scipy quiet In-Reply-To: (scipy-user-request@scipy.net) References: Message-ID: <200512121638.jBCGcfHx015410@oobleck.astro.cornell.edu> > how can I get rid of the "importing to scipy" messages. I agree with Steve and Cory. The diagnostics are useful in some circumstances, particularly interactive use, when debugging your own code, etc. But, it is important to be able to turn all non-user-commanded output off before any occurs. For example, say you are writing a stand-alone Python script to perform some mathematical operation in a Unix shell pipeline (what Cory was saying): % pyreaddata | pycomputefft | someplottingprogram --xyplot --coloneisy Without some way of turning off all babble from Python, you'd have to stick an ugly sed command after every py* command to strip the diagnostics out - and hope you got all possible babble anyone might think of to include in the future. Maybe the way to do it is to have a global diagnostic status to set: -3, etc etc -2 even more debugging output -1 debug mode, print basic debugging messages 0 default, interactive mode, print normal diagnostics 1 quiet mode, print only critical error messages 2 don't even print critical error messages, just die with a status The last option is useful if the program is going to be writing binary data files and there is no way anyone is going to go looking for text messages in them (though such messages should go to stderr anyway). I'm not suggesting a particular implementation here, just that the diagnostic status should be visible any time a diagnostic print might occur (which is pretty much anywhere). Lacking that, all diagnostic babble should start with the same constant string to make filtering it out with sed easy: DIAG: Importing test to scipy DIAG: Importing base to scipy ... That way, if next year someone updates a package to include a new diagnostic, it doesn't break my old code that filters diagnostics. But, it would be better just to be able to turn them off. If there's already a way to do this, it needs to be documented better... --jh-- From david.huard at gmail.com Mon Dec 12 12:10:16 2005 From: david.huard at gmail.com (David Huard) Date: Mon, 12 Dec 2005 12:10:16 -0500 Subject: [SciPy-user] Difficulties with gaussian_kde Message-ID: <91cf711d0512120910p2a9eaca7ycf327b587642f840@mail.gmail.com> Hi, I'm trying to use gaussian_kde but it returns an error. Here's the code from scipy.stats import gaussian_kde, norm x = norm.rvs(10,2,size = 100) ckde = gaussian_kde(x) ckde.evaluate(10.) returning the message : File "/usr/lib/python2.4/site-packages/scipy/stats/kde.py", line 91, in evaluate points = atleast_2d(points).astype(self.dataset.typecode()) AttributeError: 'scipy.ndarray' object has no attribute 'typecode' when trying resample(size = 10), I get File "mtrand.pyx", line 837, in mtrand.RandomState.multivariate_normal AttributeError: 'module' object has no attribute 'singular_value_decomposition' I'm using a version of scipy obtained from svn last week. Since I'm a newbie to Python and Scipy, I have the nagging feeling that I am missing something trivial here. Am I ? Thanks, David Huard If I may suggest, I would add a first line in the docstring of kde.pydescribing how to call gaussian_kde, something as """ Uni/multi-variate kernel density estimation. gaussian_kde(dataset) -> class object the rest of the docstring is pretty straighforward but the first step is taken for granted, and since it returned errors, I had serious doubts as to how the class had to be called. -------------- next part -------------- An HTML attachment was scrubbed... URL: From haase at msg.ucsf.edu Mon Dec 12 12:32:47 2005 From: haase at msg.ucsf.edu (Sebastian Haase) Date: Mon, 12 Dec 2005 09:32:47 -0800 Subject: [SciPy-user] how to make a sinc(x) function - "divide by zero" ! Message-ID: <200512120932.47457.haase@msg.ucsf.edu> Hi, I was trying to implement a "sinc" [sin(x)/x] in numarray. But the "where"-semantics makes it choke on the x=0: 0/0 case. (This should of course work for x being an array - so "if" is no option) The best I could come up with was: def sinc(r): na.Error.pushMode(all="ignore") a = na.where(r, na.divide(na.sin(r),r), 1) na.Error.popMode() return a but I still seem to get a warning... >>> F.sinc(0) Warning: Encountered invalid numeric result(s) in divide 1.0 What is a better way of doing this ? Thanks, Sebastian Haase ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click _______________________________________________ Numpy-discussion mailing list Numpy-discussion at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion From arnd.baecker at web.de Mon Dec 12 12:39:29 2005 From: arnd.baecker at web.de (Arnd Baecker) Date: Mon, 12 Dec 2005 18:39:29 +0100 (CET) Subject: [SciPy-user] how to make a sinc(x) function - "divide by zero" ! In-Reply-To: <200512120932.47457.haase@msg.ucsf.edu> References: <200512120932.47457.haase@msg.ucsf.edu> Message-ID: On Mon, 12 Dec 2005, Sebastian Haase wrote: > Hi, > I was trying to implement a "sinc" [sin(x)/x] in numarray. But the > "where"-semantics makes it choke on the x=0: 0/0 case. > (This should of course work for x being an array - so "if" is no option) > The best I could come up with was: > > def sinc(r): > na.Error.pushMode(all="ignore") > a = na.where(r, na.divide(na.sin(r),r), 1) > na.Error.popMode() > return a > > but I still seem to get a warning... > > >>> F.sinc(0) > > Warning: Encountered invalid numeric result(s) in divide > 1.0 > > What is a better way of doing this ? Yuo could try to use `vectorize` (warning: untested code) def sinc(x): if x==0.0: # presumably better to check for small x return 0.0 # here ... else: return sin(x)/x sinc_vectorized=scipy.vectorize(sinc) HTH, Arnd From sransom at nrao.edu Mon Dec 12 13:04:16 2005 From: sransom at nrao.edu (Scott Ransom) Date: Mon, 12 Dec 2005 13:04:16 -0500 Subject: [SciPy-user] how to make a sinc(x) function - "divide by zero" ! In-Reply-To: References: <200512120932.47457.haase@msg.ucsf.edu> Message-ID: <200512121304.17040.sransom@nrao.edu> Here is a simple version that I use. It uses the Taylor expansion when the argument is near zero. Note that this is using Numeric and umath right now. This should be trivial to change to new scipy_core (which I am not using yet): def sinc(xs): """ sinc(xs): Return the sinc function [i.e. sin(pi * xs)/(pi * xs)] for the values xs. """ pxs = umath.pi*xs return Numeric.where(umath.fabs(pxs)<1e-3, 1.0-pxs*pxs/6.0, umath.sin(pxs)/pxs) Scott On Monday 12 December 2005 12:39 pm, Arnd Baecker wrote: > On Mon, 12 Dec 2005, Sebastian Haase wrote: > > Hi, > > I was trying to implement a "sinc" [sin(x)/x] in numarray. But the > > "where"-semantics makes it choke on the x=0: 0/0 case. > > (This should of course work for x being an array - so "if" is no > > option) The best I could come up with was: > > > > def sinc(r): > > na.Error.pushMode(all="ignore") > > a = na.where(r, na.divide(na.sin(r),r), 1) > > na.Error.popMode() > > return a > > > > but I still seem to get a warning... > > > > >>> F.sinc(0) > > > > Warning: Encountered invalid numeric result(s) in divide > > 1.0 > > > > What is a better way of doing this ? > > Yuo could try to use `vectorize` (warning: untested code) > > def sinc(x): > if x==0.0: # presumably better to check for small > x return 0.0 # here ... > else: > return sin(x)/x > > sinc_vectorized=scipy.vectorize(sinc) > > HTH, > > Arnd > > _______________________________________________ > SciPy-user mailing list > SciPy-user at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-user -- Scott M. Ransom Address: NRAO Phone: (434) 296-0320 520 Edgemont Rd. email: sransom at nrao.edu Charlottesville, VA 22903 USA GPG Fingerprint: 06A9 9553 78BE 16DB 407B FFCA 9BFA B6FF FFD3 2989 From aisaac at american.edu Mon Dec 12 13:16:02 2005 From: aisaac at american.edu (Alan G Isaac) Date: Mon, 12 Dec 2005 13:16:02 -0500 Subject: [SciPy-user] keep scipy quiet In-Reply-To: <200512120940.18874.dd55@cornell.edu> References: <438DCA77.8070303@att.net><17308.64400.784597.994429@monster.iitb.ac.in><439D8A5E.2070706@gmx.net><200512120940.18874.dd55@cornell.edu> Message-ID: On Mon, 12 Dec 2005, Darren Dale apparently wrote: > Comment out line 119 in scipy_core's > scipy/_import_tools.py file: > print 'Importing',package_name,'to',self.parent_name Shouldn't this kind of thing be handled with the logging module, at least from Python 2.3 on? Just curious. Thanks, Alan Isaac From perry at stsci.edu Mon Dec 12 13:13:26 2005 From: perry at stsci.edu (Perry Greenfield) Date: Mon, 12 Dec 2005 13:13:26 -0500 Subject: [SciPy-user] how to make a sinc(x) function - "divide by zero" ! In-Reply-To: <200512120932.47457.haase@msg.ucsf.edu> References: <200512120932.47457.haase@msg.ucsf.edu> Message-ID: <01c9260752a962555edb476ab47550bc@stsci.edu> On Dec 12, 2005, at 12:32 PM, Sebastian Haase wrote: > Hi, > I was trying to implement a "sinc" [sin(x)/x] in numarray. But the > "where"-semantics makes it choke on the x=0: 0/0 case. > (This should of course work for x being an array - so "if" is no > option) > The best I could come up with was: > > def sinc(r): > na.Error.pushMode(all="ignore") > a = na.where(r, na.divide(na.sin(r),r), 1) > na.Error.popMode() > return a > > but I still seem to get a warning... > >>>> F.sinc(0) > > Warning: Encountered invalid numeric result(s) in divide > 1.0 > > What is a better way of doing this ? > Thanks, > Sebastian Haase > That's odd. When I try your example it prints 1 without any warning. What version and platform are you running on? Thanks, Perry From haase at msg.ucsf.edu Mon Dec 12 13:26:34 2005 From: haase at msg.ucsf.edu (Sebastian Haase) Date: Mon, 12 Dec 2005 10:26:34 -0800 Subject: [SciPy-user] how to make a sinc(x) function - "divide by zero" ! In-Reply-To: <01c9260752a962555edb476ab47550bc@stsci.edu> References: <200512120932.47457.haase@msg.ucsf.edu> <01c9260752a962555edb476ab47550bc@stsci.edu> Message-ID: <200512121026.34709.haase@msg.ucsf.edu> Thanks Perry, that's the answer I hoped for ;-) I was using something like CVS numarray - around 1.3 ; >>> na.__version__ '1.4.0' (na.array has not dtype argument yet...) but now it works !!?? (Maybe the errorMode stack got messed up when I was playing with it !) - Sebastian On Monday 12 December 2005 10:13, Perry Greenfield wrote: > On Dec 12, 2005, at 12:32 PM, Sebastian Haase wrote: > > Hi, > > I was trying to implement a "sinc" [sin(x)/x] in numarray. But the > > "where"-semantics makes it choke on the x=0: 0/0 case. > > (This should of course work for x being an array - so "if" is no > > option) > > The best I could come up with was: > > > > def sinc(r): > > na.Error.pushMode(all="ignore") > > a = na.where(r, na.divide(na.sin(r),r), 1) > > na.Error.popMode() > > return a > > > > but I still seem to get a warning... > > > >>>> F.sinc(0) > > > > Warning: Encountered invalid numeric result(s) in divide > > 1.0 > > > > What is a better way of doing this ? > > Thanks, > > Sebastian Haase > > That's odd. When I try your example it prints 1 without any warning. > What version and platform are you running on? > > Thanks, Perry > > _______________________________________________ > SciPy-user mailing list > SciPy-user at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-user From haase at msg.ucsf.edu Mon Dec 12 13:30:08 2005 From: haase at msg.ucsf.edu (Sebastian Haase) Date: Mon, 12 Dec 2005 10:30:08 -0800 Subject: [SciPy-user] how to make a sinc(x) function - "divide by zero" ! In-Reply-To: <200512121304.17040.sransom@nrao.edu> References: <200512120932.47457.haase@msg.ucsf.edu> <200512121304.17040.sransom@nrao.edu> Message-ID: <200512121030.09158.haase@msg.ucsf.edu> Scott, Thanks for your reply. (As Perry points out - my code actually works on numarray) But in your code: Don't you get a "division by zero" in Numeric here ? "where" is evaluation BOTH* results FIRST (over the ENTIRE array) and only AFTERWARDS "selects" based on the on the first argument (* actually all "three" arrays) Thanks, Sebastian Haase On Monday 12 December 2005 10:04, Scott Ransom wrote: > Here is a simple version that I use. It uses the Taylor > expansion when the argument is near zero. Note that this > is using Numeric and umath right now. This should be > trivial to change to new scipy_core (which I am not using yet): > > def sinc(xs): > """ > sinc(xs): > Return the sinc function [i.e. sin(pi * xs)/(pi * xs)] > for the values xs. > """ > pxs = umath.pi*xs > return Numeric.where(umath.fabs(pxs)<1e-3, > 1.0-pxs*pxs/6.0, umath.sin(pxs)/pxs) > > Scott > > On Monday 12 December 2005 12:39 pm, Arnd Baecker wrote: > > On Mon, 12 Dec 2005, Sebastian Haase wrote: > > > Hi, > > > I was trying to implement a "sinc" [sin(x)/x] in numarray. But the > > > "where"-semantics makes it choke on the x=0: 0/0 case. > > > (This should of course work for x being an array - so "if" is no > > > option) The best I could come up with was: > > > > > > def sinc(r): > > > na.Error.pushMode(all="ignore") > > > a = na.where(r, na.divide(na.sin(r),r), 1) > > > na.Error.popMode() > > > return a > > > > > > but I still seem to get a warning... > > > > > > >>> F.sinc(0) > > > > > > Warning: Encountered invalid numeric result(s) in divide > > > 1.0 > > > > > > What is a better way of doing this ? > > > > Yuo could try to use `vectorize` (warning: untested code) > > > > def sinc(x): > > if x==0.0: # presumably better to check for small > > x return 0.0 # here ... > > else: > > return sin(x)/x > > > > sinc_vectorized=scipy.vectorize(sinc) > > > > HTH, > > > > Arnd > > > > _______________________________________________ > > SciPy-user mailing list > > SciPy-user at scipy.net > > http://www.scipy.net/mailman/listinfo/scipy-user From robert.kern at gmail.com Mon Dec 12 13:48:02 2005 From: robert.kern at gmail.com (Robert Kern) Date: Mon, 12 Dec 2005 10:48:02 -0800 Subject: [SciPy-user] Difficulties with gaussian_kde In-Reply-To: <91cf711d0512120910p2a9eaca7ycf327b587642f840@mail.gmail.com> References: <91cf711d0512120910p2a9eaca7ycf327b587642f840@mail.gmail.com> Message-ID: <439DC5E2.5090807@gmail.com> David Huard wrote: > I'm using a version of scipy obtained from svn last week. Since I'm a > newbie to Python and Scipy, I have the nagging feeling that I am missing > something trivial here. Am I ? I goofed and didn't update it properly for scipy_core. It will be fixed shortly. -- Robert Kern robert.kern at gmail.com "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter From sransom at nrao.edu Mon Dec 12 14:05:08 2005 From: sransom at nrao.edu (Scott Ransom) Date: Mon, 12 Dec 2005 14:05:08 -0500 Subject: [SciPy-user] how to make a sinc(x) function - "divide by zero" ! In-Reply-To: <200512121030.09158.haase@msg.ucsf.edu> References: <200512120932.47457.haase@msg.ucsf.edu> <200512121304.17040.sransom@nrao.edu> <200512121030.09158.haase@msg.ucsf.edu> Message-ID: <20051212190508.GA384@ssh.cv.nrao.edu> Short answer is no. At least not for arrays: In [25]:x = asarray([-0.1, -0.05, -0.01, -0.005, -0.001, 0.0, \ 0.001, 0.005, 0.01, 0.05, 0.1]) In [26]:sinc(x) Out[26]: array([ 0.98363164, 0.99589274, 0.99983551, 0.99995888, 0.99999836, 1. , 0.99999836, 0.99995888, 0.99983551, 0.99589274, 0.98363164]) Scalars, however, seem to be a different story. I guess that I must have only used this function with arrays... In [27]:sinc(0.0) --------------------------------------------------------------------------- exceptions.ZeroDivisionError Traceback (most recent call last) /home/ransom/ /home/ransom/ in sinc(xs) ZeroDivisionError: float division Scott On Mon, Dec 12, 2005 at 10:30:08AM -0800, Sebastian Haase wrote: > Scott, > Thanks for your reply. (As Perry points out - my code actually works on > numarray) > But in your code: Don't you get a "division by zero" in Numeric here ? > "where" is evaluation BOTH* results FIRST (over the ENTIRE array) and only > AFTERWARDS "selects" based on the on the first argument > (* actually all "three" arrays) > > Thanks, > Sebastian Haase > > > On Monday 12 December 2005 10:04, Scott Ransom wrote: > > Here is a simple version that I use. It uses the Taylor > > expansion when the argument is near zero. Note that this > > is using Numeric and umath right now. This should be > > trivial to change to new scipy_core (which I am not using yet): > > > > def sinc(xs): > > """ > > sinc(xs): > > Return the sinc function [i.e. sin(pi * xs)/(pi * xs)] > > for the values xs. > > """ > > pxs = umath.pi*xs > > return Numeric.where(umath.fabs(pxs)<1e-3, > > 1.0-pxs*pxs/6.0, umath.sin(pxs)/pxs) > > > > Scott > > > > On Monday 12 December 2005 12:39 pm, Arnd Baecker wrote: > > > On Mon, 12 Dec 2005, Sebastian Haase wrote: > > > > Hi, > > > > I was trying to implement a "sinc" [sin(x)/x] in numarray. But the > > > > "where"-semantics makes it choke on the x=0: 0/0 case. > > > > (This should of course work for x being an array - so "if" is no > > > > option) The best I could come up with was: > > > > > > > > def sinc(r): > > > > na.Error.pushMode(all="ignore") > > > > a = na.where(r, na.divide(na.sin(r),r), 1) > > > > na.Error.popMode() > > > > return a > > > > > > > > but I still seem to get a warning... > > > > > > > > >>> F.sinc(0) > > > > > > > > Warning: Encountered invalid numeric result(s) in divide > > > > 1.0 > > > > > > > > What is a better way of doing this ? > > > > > > Yuo could try to use `vectorize` (warning: untested code) > > > > > > def sinc(x): > > > if x==0.0: # presumably better to check for small > > > x return 0.0 # here ... > > > else: > > > return sin(x)/x > > > > > > sinc_vectorized=scipy.vectorize(sinc) > > > > > > HTH, > > > > > > Arnd > > > > > > _______________________________________________ > > > SciPy-user mailing list > > > SciPy-user at scipy.net > > > http://www.scipy.net/mailman/listinfo/scipy-user > > _______________________________________________ > SciPy-user mailing list > SciPy-user at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-user -- -- Scott M. Ransom Address: NRAO Phone: (434) 296-0320 520 Edgemont Rd. email: sransom at nrao.edu Charlottesville, VA 22903 USA GPG Fingerprint: 06A9 9553 78BE 16DB 407B FFCA 9BFA B6FF FFD3 2989 From haase at msg.ucsf.edu Mon Dec 12 14:42:36 2005 From: haase at msg.ucsf.edu (Sebastian Haase) Date: Mon, 12 Dec 2005 11:42:36 -0800 Subject: [SciPy-user] how to make a sinc(x) function - "divide by zero" ! In-Reply-To: <20051212190508.GA384@ssh.cv.nrao.edu> References: <200512120932.47457.haase@msg.ucsf.edu> <200512121030.09158.haase@msg.ucsf.edu> <20051212190508.GA384@ssh.cv.nrao.edu> Message-ID: <200512121142.37150.haase@msg.ucsf.edu> Then there is a BIG (?) difference in how "where" is implemented in Numeric and numarray Unless, Numeric defaults to "ignore" divide-by-zero ... - Sebastian On Monday 12 December 2005 11:05, Scott Ransom wrote: > Short answer is no. At least not for arrays: > > In [25]:x = asarray([-0.1, -0.05, -0.01, -0.005, -0.001, 0.0, \ > 0.001, 0.005, 0.01, 0.05, 0.1]) > > In [26]:sinc(x) > Out[26]: > array([ 0.98363164, 0.99589274, 0.99983551, 0.99995888, > 0.99999836, 1. , 0.99999836, 0.99995888, > 0.99983551, 0.99589274, 0.98363164]) > > Scalars, however, seem to be a different story. I guess that I > must have only used this function with arrays... > > In [27]:sinc(0.0) > --------------------------------------------------------------------------- > exceptions.ZeroDivisionError Traceback > (most recent call last) > > /home/ransom/ > > /home/ransom/ in sinc(xs) > > ZeroDivisionError: float division > > > Scott > > On Mon, Dec 12, 2005 at 10:30:08AM -0800, Sebastian Haase wrote: > > Scott, > > Thanks for your reply. (As Perry points out - my code actually works on > > numarray) > > But in your code: Don't you get a "division by zero" in Numeric here ? > > "where" is evaluation BOTH* results FIRST (over the ENTIRE array) and > > only AFTERWARDS "selects" based on the on the first argument > > (* actually all "three" arrays) > > > > Thanks, > > Sebastian Haase > > > > On Monday 12 December 2005 10:04, Scott Ransom wrote: > > > Here is a simple version that I use. It uses the Taylor > > > expansion when the argument is near zero. Note that this > > > is using Numeric and umath right now. This should be > > > trivial to change to new scipy_core (which I am not using yet): > > > > > > def sinc(xs): > > > """ > > > sinc(xs): > > > Return the sinc function [i.e. sin(pi * xs)/(pi * xs)] > > > for the values xs. > > > """ > > > pxs = umath.pi*xs > > > return Numeric.where(umath.fabs(pxs)<1e-3, > > > 1.0-pxs*pxs/6.0, umath.sin(pxs)/pxs) > > > > > > Scott > > > > > > On Monday 12 December 2005 12:39 pm, Arnd Baecker wrote: > > > > On Mon, 12 Dec 2005, Sebastian Haase wrote: > > > > > Hi, > > > > > I was trying to implement a "sinc" [sin(x)/x] in numarray. But the > > > > > "where"-semantics makes it choke on the x=0: 0/0 case. > > > > > (This should of course work for x being an array - so "if" is no > > > > > option) The best I could come up with was: > > > > > > > > > > def sinc(r): > > > > > na.Error.pushMode(all="ignore") > > > > > a = na.where(r, na.divide(na.sin(r),r), 1) > > > > > na.Error.popMode() > > > > > return a > > > > > > > > > > but I still seem to get a warning... > > > > > > > > > > >>> F.sinc(0) > > > > > > > > > > Warning: Encountered invalid numeric result(s) in divide > > > > > 1.0 > > > > > > > > > > What is a better way of doing this ? > > > > > > > > Yuo could try to use `vectorize` (warning: untested code) > > > > > > > > def sinc(x): > > > > if x==0.0: # presumably better to check for small > > > > x return 0.0 # here ... > > > > else: > > > > return sin(x)/x > > > > > > > > sinc_vectorized=scipy.vectorize(sinc) > > > > > > > > HTH, > > > > > > > > Arnd > > > > > > > > _______________________________________________ > > > > SciPy-user mailing list > > > > SciPy-user at scipy.net > > > > http://www.scipy.net/mailman/listinfo/scipy-user > > > > _______________________________________________ > > SciPy-user mailing list > > SciPy-user at scipy.net > > http://www.scipy.net/mailman/listinfo/scipy-user > > -- From david.huard at gmail.com Mon Dec 12 14:52:38 2005 From: david.huard at gmail.com (David Huard) Date: Mon, 12 Dec 2005 14:52:38 -0500 Subject: [SciPy-user] Difficulties with gaussian_kde In-Reply-To: <439DC5E2.5090807@gmail.com> References: <91cf711d0512120910p2a9eaca7ycf327b587642f840@mail.gmail.com> <439DC5E2.5090807@gmail.com> Message-ID: <91cf711d0512121152t734af3d9y898059cccea29b90@mail.gmail.com> Thanks a lot, I'm looking forward to it. David Huard On 12/12/05, Robert Kern wrote: > > David Huard wrote: > > > I'm using a version of scipy obtained from svn last week. Since I'm a > > newbie to Python and Scipy, I have the nagging feeling that I am missing > > something trivial here. Am I ? > > I goofed and didn't update it properly for scipy_core. It will be fixed > shortly. > > -- > Robert Kern > robert.kern at gmail.com > > "In the fields of hell where the grass grows high > Are the graves of dreams allowed to die." > -- Richard Harter > > _______________________________________________ > SciPy-user mailing list > SciPy-user at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lanceboyle at qwest.net Tue Dec 13 00:35:45 2005 From: lanceboyle at qwest.net (lanceboyle at qwest.net) Date: Mon, 12 Dec 2005 22:35:45 -0700 Subject: [SciPy-user] how to make a sinc(x) function - "divide by zero" ! In-Reply-To: References: <200512120932.47457.haase@msg.ucsf.edu> Message-ID: <8133CCB7-6CB4-445D-8180-75423CF39CA6@qwest.net> On Dec 12, 2005, at 10:39 AM, Arnd Baecker wrote: > On Mon, 12 Dec 2005, Sebastian Haase wrote: > > > >> Hi, >> I was trying to implement a "sinc" [sin(x)/x] in numarray. But the >> "where"-semantics makes it choke on the x=0: 0/0 case. >> (This should of course work for x being an array - so "if" is no >> option) >> The best I could come up with was: >> >> def sinc(r): >> na.Error.pushMode(all="ignore") >> a = na.where(r, na.divide(na.sin(r),r), 1) >> na.Error.popMode() >> return a >> >> but I still seem to get a warning... >> >> >> >>>>> F.sinc(0) >>>>> >>>>> >> >> Warning: Encountered invalid numeric result(s) in divide >> 1.0 >> >> What is a better way of doing this ? >> >> > > Yuo could try to use `vectorize` (warning: untested code) > > def sinc(x): > if x==0.0: # presumably better to check for small x > return 0.0 # here ... > else: > return sin(x)/x > sinc(0.0) is 1.0, not 0.0. > > sinc_vectorized=scipy.vectorize(sinc) > > HTH, > > Arnd > > _______________________________________________ > SciPy-user mailing list > SciPy-user at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-user > > > From arnd.baecker at web.de Tue Dec 13 01:45:43 2005 From: arnd.baecker at web.de (Arnd Baecker) Date: Tue, 13 Dec 2005 07:45:43 +0100 (CET) Subject: [SciPy-user] how to make a sinc(x) function - "divide by zero" ! In-Reply-To: <8133CCB7-6CB4-445D-8180-75423CF39CA6@qwest.net> References: <200512120932.47457.haase@msg.ucsf.edu> <8133CCB7-6CB4-445D-8180-75423CF39CA6@qwest.net> Message-ID: On Mon, 12 Dec 2005 lanceboyle at qwest.net wrote: > On Dec 12, 2005, at 10:39 AM, Arnd Baecker wrote: [...] > > Yuo could try to use `vectorize` (warning: untested code) > > > > def sinc(x): > > if x==0.0: # presumably better to check for small x > > return 0.0 # here ... > > else: > > return sin(x)/x > > > > sinc(0.0) is 1.0, not 0.0. Presumably that's one thing which I anticipated with "untested code". Clearly a nice way of showing my competence ;-). ((note to self: should stop trying to give advice when already rushing out of the door.)) > > sinc_vectorized=scipy.vectorize(sinc) I just saw the scipy.special also implements `sinc(x)`: In [3]:scipy.special.sinc?? Type: function Base Class: String Form: Namespace: Interactive File: /usr/lib/python2.3/site-packages/scipy/special/basic.py Definition: scipy.special.sinc(x) Source: def sinc(x): """Returns sin(pi*x)/(pi*x) at all points of array x. """ w = asarray(asarray(x)*pi) return where(x==0, 1.0, sin(w)/w) Best, Arnd From msomers at mail.ie Tue Dec 13 03:29:32 2005 From: msomers at mail.ie (Martin Somers) Date: Tue, 13 Dec 2005 00:29:32 -0800 (PST) Subject: [SciPy-user] scipy on XP isnt happening Message-ID: <20051213002933.FBF601F2@dm22.mta.everyone.net> Trying to in stall a single plotting package for scipy and its not happening, I must have some strange configuration as most my efforts under XP were fruitless, trying to install chaco using python setup.py build python setup.py install I getting an import error of no module names seup_agg (which seems to be part of swig) The only other thing I can think of is that I?ve downloaded Unix files and trying to run them?. Surely an installation can?t be that difficult, by the way I dont see a default plotting package in scipy well those that I have tried wont work Any ideas on how to get scipy out of its box and running I also seem to be having a lot of trouble with the files housed in the distutils folder ? what do they do Any help would be appreciated later M _____________________________________________________________ Sign up for Private, FREE email from Mail.ie at http://www.mail.ie From robert.kern at gmail.com Tue Dec 13 03:55:18 2005 From: robert.kern at gmail.com (Robert Kern) Date: Tue, 13 Dec 2005 00:55:18 -0800 Subject: [SciPy-user] scipy on XP isnt happening In-Reply-To: <20051213002933.FBF601F2@dm22.mta.everyone.net> References: <20051213002933.FBF601F2@dm22.mta.everyone.net> Message-ID: <439E8C76.9010307@gmail.com> Martin Somers wrote: > Trying to in stall a single plotting package for scipy and its > not happening, scipy no longer distributes any plotting packages. Older versions (0.3.x) do have some, but they are unsupported. Probably the best place for you to start with is matplotlib. http://matplotlib.sourceforge.net > I must have some strange configuration as most > my efforts under XP were fruitless, > > trying to install chaco using python setup.py build python setup.py install I getting an import error of no module names seup_agg (which seems to be part of swig) Where did you get this version of Chaco? It is almost certainly not up-to-date. A more current, working version of Chaco is coming soon, but it will not be a part of scipy. > The only other thing I can think of is that I?ve downloaded Unix files and trying to run them?. > > Surely an installation can?t be that difficult, by the way I dont see a default plotting package in scipy well those that I have tried wont work > > Any ideas on how to get scipy out of its box and running We can't help you until you give us more detailed information like what version of Python you have installed, what version of scipy you are trying to install, what C and Fortran compilers you are using, and the actual text of the error messages you are seeing. > I also seem to be having a lot of trouble with the files > housed in the distutils folder ? what do they do They actually build and install the package. -- Robert Kern robert.kern at gmail.com "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter From noel.oboyle2 at mail.dcu.ie Tue Dec 13 04:21:06 2005 From: noel.oboyle2 at mail.dcu.ie (Noel O'Boyle) Date: Tue, 13 Dec 2005 09:21:06 +0000 Subject: [SciPy-user] scipy on XP isnt happening In-Reply-To: <20051213002933.FBF601F2@dm22.mta.everyone.net> References: <20051213002933.FBF601F2@dm22.mta.everyone.net> Message-ID: <1134465666.5870.22.camel@sandwi.ch.cam.ac.uk> Python module distributions for windows usually come in the form of a binary installer (that is, an exe). See is there one available for chaco. On Tue, 2005-12-13 at 00:29 -0800, Martin Somers wrote: > Trying to in stall a single plotting package for scipy and its > not happening, > > I must have some strange configuration as most > my efforts under XP were fruitless, > > trying to install chaco using python setup.py build python setup.py install I getting an import error of no module names seup_agg (which seems to be part of swig) > > The only other thing I can think of is that I?ve downloaded Unix files and trying to run them?. > > Surely an installation can?t be that difficult, by the way I dont see a default plotting package in scipy well those that I have tried wont work > > Any ideas on how to get scipy out of its box and running > > I also seem to be having a lot of trouble with the files > housed in the distutils folder ? what do they do > > Any help would be appreciated > later > M > > > _____________________________________________________________ > Sign up for Private, FREE email from Mail.ie at http://www.mail.ie > > _______________________________________________ > SciPy-user mailing list > SciPy-user at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-user From msomers at mail.ie Tue Dec 13 07:09:17 2005 From: msomers at mail.ie (Martin Somers) Date: Tue, 13 Dec 2005 04:09:17 -0800 (PST) Subject: [SciPy-user] scipy on XP isnt happening Message-ID: <20051213040918.FBF6EB33@dm20.mta.everyone.net> Here all the files that i've been using for my installation 13/12/2005 12:01 . 13/12/2005 12:01 .. 12/12/2005 17:15 5,114,266 matplotlib-0.85.win32-py2.4.exe 13/12/2005 11:24 1,132,502 numarray-1.5.0.win32-py2.4.exe 13/12/2005 11:23 1,110,177 Numeric-24.2.win32-py2.4.exe 05/12/2005 16:42 10,887,168 python-2.4.msi 06/12/2005 10:12 2,320,640 scipy_core-0.6.1.win32-py2.4.exe 13/12/2005 11:25 2,331,704 scipy_core-0.8.4.win32-py2.4.exe 12/12/2005 13:28 150,318 scipy_distutils-latest.win32.exe 05/12/2005 11:37 5,570,124 wxPython2.6-win32-unicode-2.6.1.0-py24.exe 9 File(s) 28,616,899 bytes 2 Dir(s) 10,539,999,232 bytes free when i try installing scipy_core python setup.build python setup.install ..... I get a no module named ccomplier error its an import error when trying to install scipy_core ... main problem seems with the distutils folder I've tried using the mingw complier to install the distutils but i recieved an error saying that the library have been compiled using MVS 7.1 any ideas what i can try next... where could i get my hands on MVS 7.1 --- Robert Kern wrote: From: Robert Kern Date: Tue, 13 Dec 2005 00:55:18 -0800 To: msomers at mail.ie, SciPy Users List Subject: Re: [SciPy-user] scipy on XP isnt happening Martin Somers wrote: > Trying to in stall a single plotting package for scipy and its > not happening, scipy no longer distributes any plotting packages. Older versions (0.3.x) do have some, but they are unsupported. Probably the best place for you to start with is matplotlib. http://matplotlib.sourceforge.net > I must have some strange configuration as most > my efforts under XP were fruitless, > > trying to install chaco using python setup.py build python setup.py install I getting an import error of no module names seup_agg (which seems to be part of swig) Where did you get this version of Chaco? It is almost certainly not up-to-date. A more current, working version of Chaco is coming soon, but it will not be a part of scipy. > The only other thing I can think of is that I?ve downloaded Unix files and trying to run them?. > > Surely an installation can?t be that difficult, by the way I dont see a default plotting package in scipy well those that I have tried wont work > > Any ideas on how to get scipy out of its box and running We can't help you until you give us more detailed information like what version of Python you have installed, what version of scipy you are trying to install, what C and Fortran compilers you are using, and the actual text of the error messages you are seeing. > I also seem to be having a lot of trouble with the files > housed in the distutils folder ? what do they do They actually build and install the package. -- Robert Kern robert.kern at gmail.com "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter _____________________________________________________________ Sign up for Private, FREE email from Mail.ie at http://www.mail.ie From gpajer at rider.edu Tue Dec 13 08:54:34 2005 From: gpajer at rider.edu (Gary Pajer) Date: Tue, 13 Dec 2005 08:54:34 -0500 Subject: [SciPy-user] scipy on XP isnt happening In-Reply-To: <20051213040918.FBF6EB33@dm20.mta.everyone.net> References: <20051213040918.FBF6EB33@dm20.mta.everyone.net> Message-ID: <439ED29A.70902@rider.edu> Martin Somers wrote: >[...] > >when i try installing scipy_core >python setup.build >python setup.install ..... > >I get a > >no module named ccomplier error > >its an import error when trying to install scipy_core ... main problem seems with the distutils folder > >I've tried using the mingw complier to install the distutils but i recieved an error saying that the library have been compiled using MVS 7.1 > >any ideas what i can try next... > >where could i get my hands on MVS 7.1 > > Try this: http://www.scipy.org/mailinglists/mailman?fn=scipy-user/2005-November/005872.html I had to use MinGW 3.1 to get it to work. MinGW 4.1 didn't work. Get the atlas binary, set ATLAS=c:\path\to\atlas -gary From svetosch at gmx.net Tue Dec 13 09:16:56 2005 From: svetosch at gmx.net (Sven Schreiber) Date: Tue, 13 Dec 2005 15:16:56 +0100 Subject: [SciPy-user] scipy on XP isnt happening In-Reply-To: <439ED29A.70902@rider.edu> References: <20051213040918.FBF6EB33@dm20.mta.everyone.net> <439ED29A.70902@rider.edu> Message-ID: <439ED7D8.6050704@gmx.net> Gary Pajer schrieb: > Martin Somers wrote: > > >>[...] >> >>when i try installing scipy_core >>python setup.build >>python setup.install ..... >> Maybe I don't understand your (ie., Martin's) problem, but the installation on windwos with the binary installers is actually quite simple, no need to do builds, compilations and distutils stuff on your own. >From your earlier message it seems maybe you're missing the win32-extensions of python? (Before installing scipy and stuff.) I used, in that order (as admin, but have also installed on a different machine w/o admin rights, but of course only in "my documents"): python-2.4.2.msi pywin32-205.win32-py2.4.exe (these are the infamous extensions mentioned above) scipy_core-0.6.1.win32-py2.4.exe scipy-0.4.3.win32-py2.4.exe (can add wxPython here as well if you like) and then for matplotlib: Numeric-24.2.win32-py2.4.exe (should/will be unnecessary in the future) matplotlib-0.85.win32-py2.4.exe > > Try this: > http://www.scipy.org/mailinglists/mailman?fn=scipy-user/2005-November/005872.html > > I had to use MinGW 3.1 to get it to work. MinGW 4.1 didn't work. > Get the atlas binary, > set ATLAS=c:\path\to\atlas > I don't think that's what he (Martin again) wants, see above. hth, sven From oliphant.travis at ieee.org Tue Dec 13 09:33:33 2005 From: oliphant.travis at ieee.org (Travis Oliphant) Date: Tue, 13 Dec 2005 07:33:33 -0700 Subject: [SciPy-user] scipy on XP isnt happening In-Reply-To: <20051213040918.FBF6EB33@dm20.mta.everyone.net> References: <20051213040918.FBF6EB33@dm20.mta.everyone.net> Message-ID: <439EDBBD.3060802@ieee.org> Martin Somers wrote: >Here all the files that i've been using for my installation > > >13/12/2005 12:01 . >13/12/2005 12:01 .. >12/12/2005 17:15 5,114,266 matplotlib-0.85.win32-py2.4.exe >13/12/2005 11:24 1,132,502 numarray-1.5.0.win32-py2.4.exe >13/12/2005 11:23 1,110,177 Numeric-24.2.win32-py2.4.exe >05/12/2005 16:42 10,887,168 python-2.4.msi >06/12/2005 10:12 2,320,640 scipy_core-0.6.1.win32-py2.4.exe >13/12/2005 11:25 2,331,704 scipy_core-0.8.4.win32-py2.4.exe >12/12/2005 13:28 150,318 scipy_distutils-latest.win32.exe >05/12/2005 11:37 5,570,124 wxPython2.6-win32-unicode-2.6.1.0-py24.exe > 9 File(s) 28,616,899 bytes > 2 Dir(s) 10,539,999,232 bytes free > > > > Hi Martin, These are all executable installers. What that means is that all you need to do is run them. I.e. either click on them in Windows explorer or from the command line just type the name. You don't need scipy_core-0.6.1.win32-py2.4.exe (replaced by newer version) scipy_distutils-latest.win32.exe (comes as part of scipy_core) You should install python-2.4.msi first and then any of the others that you want. I hope that helps. Best, -Travis From gpajer at rider.edu Tue Dec 13 09:50:24 2005 From: gpajer at rider.edu (Gary Pajer) Date: Tue, 13 Dec 2005 09:50:24 -0500 Subject: [SciPy-user] scipy on XP isnt happening -- and: concerning confusions In-Reply-To: <439ED7D8.6050704@gmx.net> References: <20051213040918.FBF6EB33@dm20.mta.everyone.net> <439ED29A.70902@rider.edu> <439ED7D8.6050704@gmx.net> Message-ID: <439EDFB0.4060504@rider.edu> Sven Schreiber wrote: >Gary Pajer schrieb: > > >>Martin Somers wrote: >> >> >> >> >>>[...] >>> >>>when i try installing scipy_core >>>python setup.build >>>python setup.install ..... >>> >>> >>> > >Maybe I don't understand your (ie., Martin's) problem, but the installation on windwos with the >binary installers is actually quite simple, no need to do builds, compilations and distutils stuff >on your own. > > Correct, of course. In looking back at Martin's post, I see that he listed some binary installers. Maybe he is indeed looking for a simple installation procedure. If so, see Steve's instructions below. (what is pywin32?? I don't think I have it; if that's true, it would be unnecessary) I always have trouble finding the binaries. scipy_core is at: http://sourceforge.net/project/showfiles.php?group_id=1369&package_id=6222 But IIRC, scipy is somewhere else... and I can't find it at the moment. I had guessed that Martin wanted to compile the latest version with the latest tweaks. [aside: a few things have confused me over that past few weeks. One is the above-mentioned difficulty in finding the binary installers. Another is the similarity of the names "scipy" and "scipy core" and the occasional use of "scipy" to mean the combination of the two, and my own use of the word "scipy" when I really mean "scipy core". I don't suppose it's advisable to change the names now, but as the dust settles, a clear paragraph or two on the scipy home page, with clear pointers to the appropriate files. Personally, I'd vote to see the names changed ... Maybe take the "sci" out of scipy core, since it has application beyond scipy. NuCore? I don't know.] >>From your earlier message it seems maybe you're missing the win32-extensions of python? (Before >installing scipy and stuff.) > >I used, in that order (as admin, but have also installed on a different machine w/o admin rights, >but of course only in "my documents"): >python-2.4.2.msi >pywin32-205.win32-py2.4.exe (these are the infamous extensions mentioned above) >scipy_core-0.6.1.win32-py2.4.exe >scipy-0.4.3.win32-py2.4.exe >(can add wxPython here as well if you like) > >and then for matplotlib: >Numeric-24.2.win32-py2.4.exe (should/will be unnecessary in the future) >matplotlib-0.85.win32-py2.4.exe > > > > >>Try this: >>http://www.scipy.org/mailinglists/mailman?fn=scipy-user/2005-November/005872.html >> >>I had to use MinGW 3.1 to get it to work. MinGW 4.1 didn't work. >>Get the atlas binary, >>set ATLAS=c:\path\to\atlas >> >> >> > >I don't think that's what he (Martin again) wants, see above. >hth, sven > >_______________________________________________ >SciPy-user mailing list >SciPy-user at scipy.net >http://www.scipy.net/mailman/listinfo/scipy-user > > > From jaonary at free.fr Tue Dec 13 10:20:29 2005 From: jaonary at free.fr (jaonary at free.fr) Date: Tue, 13 Dec 2005 16:20:29 +0100 Subject: [SciPy-user] Scipy distutils swig how to ? Message-ID: <1134487229.439ee6bd96ec7@imp2-g19.free.fr> Hi all, I have a yet another problem in building a c++ extension to scipy with swig. After managing to find a little hack with the type mapping and scipy arrays I have now, a build problem. I code in c++, and I want to use distutils. My setup.py looks like this : from scipy.disutils.core import setup, Extension setup(name='_mymodule',ext_modules = [swig_opts='-c++',language='c++',sources=...] Now, when I run python setup.py build. The swig command doesn't use the '-c++'m generate a C code and compile it with gcc! How to get a C++ code and compil it with g++ ? Thanks From pjrandew at sun.ac.za Tue Dec 13 10:34:38 2005 From: pjrandew at sun.ac.za (Randewijk P-J ) Date: Tue, 13 Dec 2005 17:34:38 +0200 Subject: [SciPy-user] scipy on XP isnt happening -- and: concerning confusions Message-ID: > -----Original Message----- > From: scipy-user-bounces at scipy.net > [mailto:scipy-user-bounces at scipy.net] On Behalf Of Gary Pajer > Sent: 13 December 2005 16:50 > To: SciPy Users List > Subject: Re: [SciPy-user] scipy on XP isnt happening -- and: > concerning confusions > > below. (what > is pywin32?? I don't think I have it; if that's true, it would be > unnecessary) > It is one package to (i) wrap the win32 API in python and ii) to use python to interface to any win32 COM (ActiveX) component and (iii) it includes a usefull editor (my default choise) as a bonus... but it is not needed to run scipy... see: http://www.python.org/windows/ and the sf download site: https://sourceforge.net/project/showfiles.php?group_id=78018 > I always have trouble finding the binaries. scipy_core is at: > > http://sourceforge.net/project/showfiles.php?group_id=1369&pac > kage_id=6222 Bookmark also: http://sourceforge.net/project/showfiles.php?group_id=1369&release_id=22 3264 Your one webpage stop for Numarray, numpy and scipy_core... > But IIRC, scipy is somewhere else... and I can't find it at > the moment. see: http://sourceforge.net/project/showfiles.php?group_id=27747 > [aside: a few things have confused me over that past few > weeks. One is > the above-mentioned difficulty in finding the binary installers. > Another is the similarity of the names "scipy" and "scipy > core" and the > occasional use of "scipy" to mean the combination of the two, > and my own > use of the word "scipy" when I really mean "scipy core". I don't > suppose it's advisable to change the names now, but as the dust > settles, a clear paragraph or two on the scipy home page, with clear > pointers to the appropriate files. Personally, I'd vote to see the > names changed ... Maybe take the "sci" out of scipy core, > since it has > application beyond scipy. NuCore? I don't know.] scipy's core used to be Numeric, a.k.a. numpy, not to be confuse with numarray, a bit confusing... Now scipy's core is "scipy core", a little bit less confusing... :) Regards, Peter-Jan From dalembertian at yahoo.com Tue Dec 13 13:08:45 2005 From: dalembertian at yahoo.com (Frank) Date: Tue, 13 Dec 2005 12:08:45 -0600 Subject: [SciPy-user] Certain subpackages fail to load Message-ID: Hi All, I have been trying to figure out this bit of weirdness for several days now. After what seems to be a clean scipy install (Mac OS 10.4.3 Python 2.3.5), several of the subpackages, such as integrate and interpolate, are unavailable while others, such as linalg and fft seem to work just fine. Python 2.3.5 (#1, Mar 20 2005, 20:38:20) [GCC 3.3 20030304 (Apple Computer, Inc. build 1809)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import scipy >>> help(scipy.fft) >>> help(scipy.interpolate) Traceback (most recent call last): File "", line 1, in ? AttributeError: 'module' object has no attribute 'interpolate' >>> I realize that linalg and fft are part of scipy.basic while interpolate and integrate are not but this does not help me toward understanding how to fix the problem. Furthering my confusion, many top-level functions are also unavailable: >>> help(scipy.derivative) Traceback (most recent call last): File "", line 1, in ? AttributeError: 'module' object has no attribute 'derivative' >>> Curiously, I have seen in the Archives that, upon import, others get something like: >>> import scipy Importing test to scipy Importing base to scipy Importing basic to scipy Importing io to scipy Importing fftpack to scipy Importing special to scipy Importing cluster to scipy Importing sparse to scipy Importing utils to scipy Importing interpolate to scipy Importing lib to scipy Importing integrate to scipy Importing signal to scipy Importing optimize to scipy Importing linalg to scipy Importing stats to scipy I do not get any such verbose response. >>> import scipy gives me nothing but a new prompt. I began to wonder if the first lines of the build log were relevant: Skip importing scipy packages (NO_SCIPY_IMPORT=SciPy/setup.py) Assuming default configuration (Lib/utils/{setup_utils,setup}.py was not found) however, this is the default setup file. I certainly didn't go mucking around in the setup.py file save for the minor change to extra link arguments suggested on Fonnebeck's website to fix a fftpack issue on OSX. The build log seems to indicate that the relevant configuration files were indeed included e.g., "Appending scipy.interpolate configuration to scipy." I have the complete build log handy if would help diagnosis. Thanks so much, Frank From managan at llnl.gov Tue Dec 13 15:46:10 2005 From: managan at llnl.gov (Rob Managan) Date: Tue, 13 Dec 2005 12:46:10 -0800 Subject: [SciPy-user] building with local libraries Message-ID: What is the proper way to tell scipy to use libraries that are not in the 'standard" locations? It seems that for FFTW you have to set and environment variable and not use site.cfg. -- *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*- Rob Managan email managan at llnl.gov LLNL phone: 925-423-0903 P.O. Box 808, L-095 FAX: 925-422-3389 Livermore, CA 94551-0808 From dalembertian at yahoo.com Tue Dec 13 16:06:06 2005 From: dalembertian at yahoo.com (Frank) Date: Tue, 13 Dec 2005 15:06:06 -0600 Subject: [SciPy-user] building with local libraries In-Reply-To: References: Message-ID: Rob, I don't know the answer to your general question, however, in the case of my scipy installation, the builder couldn't find the FFTW libraries after I had successfully installed them. The solution for me was to reconfigure/make FFTW after having forced use of the gcc 3.3 compiler via 'sudo gcc_select 3.3.' It would seem that gcc 4 (at least on Tiger) does not correctly handle certain links. I have seen this mentioned on several forums including the archives of this mailing list but I do not understand what the specific problem is. Frank From travis.brady at gmail.com Tue Dec 13 18:58:49 2005 From: travis.brady at gmail.com (Travis Brady) Date: Tue, 13 Dec 2005 15:58:49 -0800 Subject: [SciPy-user] Building new scipy with Python 2.4 on Windows 2000 with MingW32 Message-ID: I successfully built scipy_core from SVN sources using MSYS and MingW but haven't been able to figure out how to build new scipy on top of that. Are there a set of directions somewhere detailing how to do this? I've been referring to Pearu's email here: http://www.scipy.org/mailinglists/mailman?fn=scipy-user/2005-December/006048.html But haven't been able to get past the following error: C:\usr\src\scipy>python setup.py config --compiler=mingw32 build --compiler=ming w32 install Importing test to scipy Importing base to scipy Importing basic to scipy Skip importing scipy packages (NO_SCIPY_IMPORT=SciPy/setup.py) Assuming default configuration (Lib\utils/{setup_utils,setup}.py was not found) Appending scipy.utils configuration to scipy Appending scipy.io configuration to scipy fftw_info: fftw3 not found fftw2 not found NOT AVAILABLE dfftw_info: dfftw not found NOT AVAILABLE FFTW (http://www.fftw.org/) libraries not found. Directories to search for the libraries can be specified in the scipy_distutils/site.cfg file (section [fftw]) or by setting the FFTW environment variable. djbfft_info: NOT AVAILABLE DJBFFT (http://cr.yp.to/djbfft.html) libraries not found. Directories to search for the libraries can be specified in the scipy_distutils/site.cfg file (section [djbfft]) or by setting the DJBFFT environment variable. Appending scipy.fftpack configuration to scipy Appending scipy.signal configuration to scipy blas_opt_info: atlas_blas_threads_info: Setting PTATLAS=ATLAS NOT AVAILABLE atlas_blas_info: NOT AVAILABLE C:\Python24\lib\site-packages\scipy\distutils\system_info.py:1076: UserWarning: Atlas (http://math-atlas.sourceforge.net/) libraries not found. Directories to search for the libraries can be specified in the scipy_distutils/site.cfg file (section [atlas]) or by setting the ATLAS environment variable. warnings.warn(AtlasNotFoundError.__doc__) blas_info: NOT AVAILABLE C:\Python24\lib\site-packages\scipy\distutils\system_info.py:1085: UserWarning: Blas (http://www.netlib.org/blas/) libraries not found. Directories to search for the libraries can be specified in the scipy_distutils/site.cfg file (section [blas]) or by setting the BLAS environment variable. warnings.warn(BlasNotFoundError.__doc__) blas_src_info: NOT AVAILABLE C:\Python24\lib\site-packages\scipy\distutils\system_info.py:1088: UserWarning: Blas (http://www.netlib.org/blas/) sources not found. Directories to search for the sources can be specified in the scipy_distutils/site.cfg file (section [blas_src]) or by setting the BLAS_SRC environment variable. warnings.warn(BlasSrcNotFoundError.__doc__) NOT AVAILABLE Traceback (most recent call last): File "setup.py", line 42, in ? setup_package() File "setup.py", line 28, in setup_package config.add_subpackage('Lib') File "C:\Python24\Lib\site-packages\scipy\distutils\misc_util.py", line 399, i n add_subpackage config = self.get_subpackage(subpackage_name,subpackage_path) File "C:\Python24\Lib\site-packages\scipy\distutils\misc_util.py", line 389, i n get_subpackage config = setup_module.configuration(*args) File "C:\usr\src\scipy\Lib\setup.py", line 10, in configuration config.add_subpackage('integrate') File "C:\Python24\Lib\site-packages\scipy\distutils\misc_util.py", line 399, i n add_subpackage config = self.get_subpackage(subpackage_name,subpackage_path) File "C:\Python24\Lib\site-packages\scipy\distutils\misc_util.py", line 389, i n get_subpackage config = setup_module.configuration(*args) File "Lib\integrate\setup.py", line 18, in configuration raise NotFoundError,'no blas resources found' NameError: global name 'NotFoundError' is not defined -------------- next part -------------- An HTML attachment was scrubbed... URL: From oliphant.travis at ieee.org Tue Dec 13 20:43:17 2005 From: oliphant.travis at ieee.org (Travis Oliphant) Date: Tue, 13 Dec 2005 18:43:17 -0700 Subject: [SciPy-user] ***[Possible UCE]*** Building new scipy with Python 2.4 on Windows 2000 with MingW32 In-Reply-To: References: Message-ID: <439F78B5.8050203@ieee.org> Travis Brady wrote: > I successfully built scipy_core from SVN sources using MSYS and MingW > but haven't been able to figure out how to build new scipy on top of that. > Are there a set of directions somewhere detailing how to do this? > > I've been referring to Pearu's email here: > > http://www.scipy.org/mailinglists/mailman?fn=scipy-user/2005-December/006048.html > > But haven't been able to get past the following error: It looks like it's not finding blas or lapack and so it dies when trying to compile integration routines on your system (which need blas, I think). Have you compiled ATLAS? Apparently, scipy.distutils is not finding it. > atlas_blas_info: > NOT AVAILABLE > > C:\Python24\lib\site-packages\scipy\distutils\system_info.py:1076: > UserWarning: > > Atlas (http://math-atlas.sourceforge.net/) libraries not found. > Directories to search for the libraries can be specified in the > scipy_distutils/site.cfg file (section [atlas]) or by setting > the ATLAS environment variable. > warnings.warn(AtlasNotFoundError.__doc__) > blas_info: > NOT AVAILABLE > > C:\Python24\lib\site-packages\scipy\distutils\system_info.py:1085: > UserWarning: > > Blas (http://www.netlib.org/blas/) libraries not found. > Directories to search for the libraries can be specified in the > scipy_distutils/site.cfg file (section [blas]) or by setting > the BLAS environment variable. > warnings.warn(BlasNotFoundError.__doc__) > blas_src_info: > NOT AVAILABLE > > C:\Python24\lib\site-packages\scipy\distutils\system_info.py:1088: > UserWarning: > > Blas ( http://www.netlib.org/blas/) sources not found. > Directories to search for the sources can be specified in the > scipy_distutils/site.cfg file (section [blas_src]) or by setting > the BLAS_SRC environment variable. > warnings.warn(BlasSrcNotFoundError.__doc__) > NOT AVAILABLE These are the important erros. You need to either install BLAS or get the blas source and place it where scipy.distutils can find it --- or edit the site.cfg file to show where you have it installed. > > Traceback (most recent call last): > File "setup.py", line 42, in ? > setup_package() > File "setup.py", line 28, in setup_package > config.add_subpackage('Lib') > File "C:\Python24\Lib\site-packages\scipy\distutils\misc_util.py", > line 399, i > n add_subpackage > config = self.get_subpackage(subpackage_name,subpackage_path) > File "C:\Python24\Lib\site-packages\scipy\distutils\misc_util.py", > line 389, i > n get_subpackage > config = setup_module.configuration(*args) > File "C:\usr\src\scipy\Lib\setup.py", line 10, in configuration > config.add_subpackage('integrate') > File "C:\Python24\Lib\site-packages\scipy\distutils\misc_util.py", > line 399, i > n add_subpackage > config = self.get_subpackage(subpackage_name,subpackage_path) > File "C:\Python24\Lib\site-packages\scipy\distutils\misc_util.py", > line 389, i > n get_subpackage > config = setup_module.configuration(*args) > File "Lib\integrate\setup.py", line 18, in configuration > raise NotFoundError,'no blas resources found' > NameError: global name 'NotFoundError' is not defined > It looks like there is a problem with the setup.py script, but the real problem is that you don't have BLAS (or LAPACK) and full scipy needs those. -Travis From travis.brady at gmail.com Tue Dec 13 21:02:14 2005 From: travis.brady at gmail.com (Travis Brady) Date: Tue, 13 Dec 2005 18:02:14 -0800 Subject: [SciPy-user] ***[Possible UCE]*** Building new scipy with Python 2.4 on Windows 2000 with MingW32 In-Reply-To: <439F78B5.8050203@ieee.org> References: <439F78B5.8050203@ieee.org> Message-ID: Ok, Thanks, I admit to being a complete newbie by the way, so am I right in assuming I'll need something other than just the ATLAS binaries here: http://www.scipy.org/download/atlasbinaries/winnt/ Will I need to get both BLAS and LAPACK? I guess I'm not really sure what does what, I was thinking that ATLAS sort of took care of all of the linalg stuff but I must be wrong. If I get both BLAS and LAPACK should I build them with MSYS/MingW and then edit something in site.cfg telling distutils where everything is? thank you Travis On 12/13/05, Travis Oliphant wrote: > > Travis Brady wrote: > > > I successfully built scipy_core from SVN sources using MSYS and MingW > > but haven't been able to figure out how to build new scipy on top of > that. > > Are there a set of directions somewhere detailing how to do this? > > > > I've been referring to Pearu's email here: > > > > > http://www.scipy.org/mailinglists/mailman?fn=scipy-user/2005-December/006048.html > > > > But haven't been able to get past the following error: > > > It looks like it's not finding blas or lapack and so it dies when trying > to compile integration routines on your system (which need blas, I > think). Have you compiled ATLAS? Apparently, scipy.distutils is not > finding it. > > > > atlas_blas_info: > > NOT AVAILABLE > > > > C:\Python24\lib\site-packages\scipy\distutils\system_info.py:1076: > > UserWarning: > > > > Atlas (http://math-atlas.sourceforge.net/) libraries not found. > > Directories to search for the libraries can be specified in the > > scipy_distutils/site.cfg file (section [atlas]) or by setting > > the ATLAS environment variable. > > warnings.warn(AtlasNotFoundError.__doc__) > > blas_info: > > NOT AVAILABLE > > > > C:\Python24\lib\site-packages\scipy\distutils\system_info.py:1085: > > UserWarning: > > > > Blas (http://www.netlib.org/blas/) libraries not found. > > Directories to search for the libraries can be specified in the > > scipy_distutils/site.cfg file (section [blas]) or by setting > > the BLAS environment variable. > > warnings.warn(BlasNotFoundError.__doc__) > > blas_src_info: > > NOT AVAILABLE > > > > C:\Python24\lib\site-packages\scipy\distutils\system_info.py:1088: > > UserWarning: > > > > Blas ( http://www.netlib.org/blas/) sources not found. > > Directories to search for the sources can be specified in the > > scipy_distutils/site.cfg file (section [blas_src]) or by setting > > the BLAS_SRC environment variable. > > warnings.warn(BlasSrcNotFoundError.__doc__) > > NOT AVAILABLE > > > These are the important erros. You need to either install BLAS or get > the blas source and place it where scipy.distutils can find it --- or > edit the site.cfg file to show where you have it installed. > > > > > Traceback (most recent call last): > > File "setup.py", line 42, in ? > > setup_package() > > File "setup.py", line 28, in setup_package > > config.add_subpackage('Lib') > > File "C:\Python24\Lib\site-packages\scipy\distutils\misc_util.py", > > line 399, i > > n add_subpackage > > config = self.get_subpackage(subpackage_name,subpackage_path) > > File "C:\Python24\Lib\site-packages\scipy\distutils\misc_util.py", > > line 389, i > > n get_subpackage > > config = setup_module.configuration(*args) > > File "C:\usr\src\scipy\Lib\setup.py", line 10, in configuration > > config.add_subpackage('integrate') > > File "C:\Python24\Lib\site-packages\scipy\distutils\misc_util.py", > > line 399, i > > n add_subpackage > > config = self.get_subpackage(subpackage_name,subpackage_path) > > File "C:\Python24\Lib\site-packages\scipy\distutils\misc_util.py", > > line 389, i > > n get_subpackage > > config = setup_module.configuration(*args) > > File "Lib\integrate\setup.py", line 18, in configuration > > raise NotFoundError,'no blas resources found' > > NameError: global name 'NotFoundError' is not defined > > > It looks like there is a problem with the setup.py script, but the real > problem is that you don't have BLAS (or LAPACK) and full scipy needs > those. > > -Travis > > _______________________________________________ > SciPy-user mailing list > SciPy-user at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: From oliphant.travis at ieee.org Tue Dec 13 22:54:22 2005 From: oliphant.travis at ieee.org (Travis Oliphant) Date: Tue, 13 Dec 2005 20:54:22 -0700 Subject: [SciPy-user] ***[Possible UCE]*** Building new scipy with Python 2.4 on Windows 2000 with MingW32 In-Reply-To: References: <439F78B5.8050203@ieee.org> Message-ID: <439F976E.2040407@ieee.org> Travis Brady wrote: > Ok, > > Thanks, I admit to being a complete newbie by the way, so am I right > in assuming I'll need something other than just the ATLAS binaries > here: http://www.scipy.org/download/atlasbinaries/winnt/ > No, those binaries should be enough. From arnd.baecker at web.de Wed Dec 14 02:45:34 2005 From: arnd.baecker at web.de (Arnd Baecker) Date: Wed, 14 Dec 2005 08:45:34 +0100 (CET) Subject: [SciPy-user] New Quantian release 0.7.9.1 available Message-ID: Hi, the new Quantian release might be of interest to some. In particular it contains python2.3-scipy 0.3.2-7 scientific tools for Python 2.3 python2.3-scipy-core 0.3.2-4 low level utilities for scipy python2.3-matplotlib 0.82-5 python based plotting system numarray 1.4.1-1 numeric 23.8-1 python-wxgtk2.6 2.6.1.2 python-vtk 4.4.2-8 mayavi 1.4-1 The full list is at http://dirk.eddelbuettel.com/quantian/quantian_0.7.9.1.quantian.packages.txt Best, Arnd ---------- Forwarded message ---------- Date: Tue, 13 Dec 2005 22:23:46 -0600 From: Dirk Eddelbuettel To: quantian-announce Subject: [Quantian-general] [Quantian-announce] New Quantian release 0.7.9.1 available (Please see note [1] below regarding recipients for this posting. Thanks!) Executive Summary: Quantian 0.7.9.1 is the first Quantian release based on Knoppix 4.0.2. Quantian adds hundreds of scientific / numeric packages, as well as the openMosix enabled 2.4.27 kernel, to the cdrom version of Knoppix. Relative to the previous release 0.6.9.3, hundreds of applications have been updated, and many new applications (such as polyxmass, scigraphica, kst, octaviz, gromacs) have been added. Quantian now contains over 2400 Debian packages, and over 800 packages for R. Quantian comes as one bootable dvd iso of 2.5gb (compressed) with almost 7 gb (uncompressed) of software of interest to quantitative analysts, scientists, researchers or students. Announcing Quantian release 0.7.9.1 =================================== I What is it? Quantian is a remastering of Knoppix, the self-configuring and directly bootable cdrom/dvd that turns any pc or laptop into a full-featured Linux workstation, and (parts of) clusterKnoppix, which adds support for openMosix-based cluster computing. However, Quantian differs from Knoppix by having a particular focus on quantitative, numerical or scientific applications, and hence adds a very large set of programs of interest to applied or theoretical workers in quantitative or data-driven fields to the solid base provided by Knoppix. See http://dirk.eddelbuettel.com/quantian.html for more details. II What Quantian highlights should I care about ? o First release based on Knoppix 4.0.2: Derived from the cdrom version of Knoppix, Quantian utilises the unionfs setup of Knoppix to combine two compressed loop images for a total of 2.5 gb (from two files of 2.0 gb and 425 mb) corresponding to almost 7 gb of software. o KDE 3.4, Kernel 2.6.12; added backport of kernel 2.4.27 with openMosix patch for continued openMosix support [ but note that openMosix and unionfs seem to conflict so kernel 2.4.27 only sees the first compressed loop image ] o Some highlights in 0.7.9.1 are - very complete R support with over 800 packages (28 from 'core R', another 70 from Debian packages, and 724 directly installed from CRAN and BioConductor, covering over 99% of all packages at CRAN and BioConductor [ not counting a handful of windows-only CRAN packages ] ), ESS editing in Emacs/XEmacs, GGobi visualization, Rpad webinterface, and initial support for the RKward GUI; - even stronger bioinformatics/biology support than before: BioConductor, arb, biofox, bioperl, biopython, blast2, boxshade, bugsx, clustalw, fastdnaml, fastlink, garlic, gromacs, hmmer, loki, mipe, molphy, muscle, ncbi, phylip, rasmol, readseq, seaview, t-coffee, textopo, and more; - continued strong mathematics / computational algrebra support: axiom, blacs, calc, euler, gap, giac, mathomatic, maxima, pari, scalapack, scilab, texmacs, yacas, yorick; - strong visualization / graphics support: dx, garlic, gdpc, gnuplot, grace, grass, gri, illuminator, kst, labplot, mayavi, matplot, proj, plplot, plotmtv, rasmol, starplot, vtk, xd3d, xgraph, ygraph; - large number of programming and scripting languages, editors, debuggers and libraries; - excellent latex support with auctex, lyx, kile, texmacs interface, as well as numerous macro packages, bibtex tools; - office support via openoffice and koffice suites, abiword, gnumeric and other applications; - plus all the tools and toys from the current Knoppix relase. o See http://dirk.eddelbuettel.com/quantian/changelog.html for details. o See http://dirk.eddelbuettel.com/quantian/howto.html for several short HOWTOs on booting Quantian from hd on either Windows or Linux, booting via a bootcd (such as clusterKnoppix), or botting from a USB memory device. Contributions, corrections, and feedback on these HOWTOs is always appreciated. III Where do I get it? o Downloads are available from the main host at Seattle at FHCRC: http://quantian.fhcrc.org/ rsync://quantian.fhcrc.org/quantian/ and at the East Coast at http://research.warnes.net/downloads/quantian/CURRENT/ ftp://research.warnes.net/users/edd/quantian/CURRENT/ The most recent release is also available at http://quantian.alioth.debian.org/ Note that file size of 2.5 gb may upset web caching system such as squid. It may be best to rely on rsync or bittorrent instead of http. o Bittorrents should be available shortly at http://www.tlm-project.org/public/distributions/quantian/ o The main European mirrors should catch up shortly: http://sunsite.rediris.es/mirror/quantian http://sunsite.informatik.rwth-aachen.de/ftp/pub/Linux/quantian o CD/DVD vendors will probably update their offerings soon as well. See the Quantian site for a list. IV Mailing lists o Two mailing lists exist for Quantian quantian-announce for announcements, intended to be low volume quantian-general for general discussions about Quantian available via http://alioth.debian.org/mail/?group_id=30303 for subscription info etc., and start using the quantian-general lists for general questions, comments, suggestions or discussions about Quantian. Quantian-general is subscribed to quantian-announce, so you only need to subscribe to one (but can of course subscribe to both). Posting to quantian-general requires a subscription. Reply-To: for this message is quantian-general at lists.alioth.debian.org so that discussions can be continued on the list. V Known Bugs in 0.7.9.1 o Debian's current C++ transition affects the KDE packages. Several packages had to be installed from the stable relase, and a few (celestia, gdal) are currently uninstallable. This should should improve over the next few weeks/months. o Kdvi is broken. However, xdvi works as do the various pdf previewers so (PDF)LaTeX use is still possible. o As noticed above, when openMosix and kernel 2.4.27 are used, the second compressed loop image is not accessible implying that the /opt, /usr/games, /usr/lib/j2se, /usr/share/doc, /usr/src, /usr/NX directories are not accessible. VI Other items o Feedback / poll on package additions or removal As always, I welcome comments and suggestions about programs to be added or removed. Existing Debian packages, and possibly existing rpm packages, typically get inserted quite readily. Please send feedback, questions, comments, ... to the quantian-general at lists.alioth.debian.org list to maximise the number of eyes glancing at any one question. Notice that a subscription to the list is needed in order to post. o Feedback would also be appreciated on ways to better communicate with difference scientific communities that could be interested in Quantian. VII Notes [1] This email is sent via the quantian-announce mailing list. I have subscribed those whose email addresses are in my quantian mail folder due to prior emails. The quantian-announce mailing list only sends moderator-approved posts -- so there should be no spam whatsoever. Anybody who considers this unwanted is kindly asked to send me a private mail to get unsubscribed immediately. Otherwise, replies and follow-ups should go to quantian-general at lists.alioth.debian.org where posting may require an initial subscription. Best regards, Dirk -- Hell, there are no rules here - we're trying to accomplish something. -- Thomas A. Edison _______________________________________________ Quantian-announce mailing list Quantian-announce at lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/quantian-announce _______________________________________________ Quantian-general mailing list Quantian-general at lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/quantian-general From arnd.baecker at web.de Wed Dec 14 03:10:40 2005 From: arnd.baecker at web.de (Arnd Baecker) Date: Wed, 14 Dec 2005 09:10:40 +0100 (CET) Subject: [SciPy-user] building with local libraries In-Reply-To: References: Message-ID: On Tue, 13 Dec 2005, Rob Managan wrote: > What is the proper way to tell scipy to use libraries that are not in > the 'standard" locations? > It seems that for FFTW you have to set and environment variable and > not use site.cfg. Which lines did you put into site.cfg? For example: [fftw] library_dirs = /scr/python/lib/ include_dirs = /scr/python/include/ Note that you will also have to specify `include_dirs`, otherwise it will find the libraries, but not the include files and therefore tell you that there is no fftw at all. (Note to developers: wouldn't it be nicer at this point to tell the user that the libs were found, but not the header files, which are needed for the install?) Best, Arnd From pjrandew at sun.ac.za Wed Dec 14 09:43:20 2005 From: pjrandew at sun.ac.za (Randewijk P-J ) Date: Wed, 14 Dec 2005 16:43:20 +0200 Subject: [SciPy-user] Bug in inverse matrix calculation for "scipy_core-0.8.4.win32-py2.3.exe" Message-ID: Dear Travis, Thank-you for the "silent" version (0.8.4) of scipy_core. Unfortunately when trying to invert a singular matrix using scipy_core 0.8.4, python "crashes" instead of issuing the usual error message: ... >>> m.I Traceback (most recent call last): File "", line 1, in ? File "C:\Python\Lib\site-packages\scipy\base\matrix.py", line 197, in getI return matrix(linalg.inv(self)) File "C:\Python\Lib\site-packages\scipy\linalg\basic.py", line 221, in inv if info>0: raise LinAlgError, "singular matrix" LinAlgError: singular matrix >>> ... On this note. Is there a way of determining before hand in scipy if a matrix is singular, say by calculating its rank, e.g.: ... >>> if matrix_rank(my_matrix) < max(my_matrix.shape): ... And then if the matrix is singular, is there a way in scipy to calculate the reduced row-echelon form (RREF) for a linear system of equation, a.k.a. linalg.solve, e.g. ... >>> linalg.rref(a,b) ... http://en.wikipedia.org/wiki/Gauss-Jordan_elimination shows a "formal algorithm" to calculate reduced row-echelon matrix. Its looks easy to implement in ("high level") python, but a "low level" implementation in scipy would be "nice"... (for lazy people like myself) Regards, Peter-Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From dalembertian at yahoo.com Wed Dec 14 09:51:56 2005 From: dalembertian at yahoo.com (Frank) Date: Wed, 14 Dec 2005 08:51:56 -0600 Subject: [SciPy-user] Bug in inverse matrix calculation for "scipy_core-0.8.4.win32-py2.3.exe" In-Reply-To: References: Message-ID: "On this note. Is there a way of determining before hand in scipy if a matrix is singular, say by calculating its rank, e.g.:" if det(matrix) = 0, then the matrix is singular From pjrandew at sun.ac.za Wed Dec 14 09:54:55 2005 From: pjrandew at sun.ac.za (Randewijk P-J ) Date: Wed, 14 Dec 2005 16:54:55 +0200 Subject: [SciPy-user] Bug in inverse matrix calculationfor "scipy_core-0.8.4.win32-py2.3.exe" Message-ID: Thanks, maybe I'm to lazy to think this afternoon... > -----Original Message----- > From: scipy-user-bounces at scipy.net > [mailto:scipy-user-bounces at scipy.net] On Behalf Of Frank > Sent: 14 December 2005 16:52 > To: SciPy Users List > Subject: Re: [SciPy-user] Bug in inverse matrix > calculationfor "scipy_core-0.8.4.win32-py2.3.exe" > > > "On this note. Is there a way of determining before hand in > scipy if a matrix is singular, say by calculating its rank, e.g.:" > > if det(matrix) = 0, then the matrix is singular > > _______________________________________________ > SciPy-user mailing list > SciPy-user at scipy.net http://www.scipy.net/mailman/listinfo/scipy-user > From nwagner at mecha.uni-stuttgart.de Wed Dec 14 10:01:13 2005 From: nwagner at mecha.uni-stuttgart.de (Nils Wagner) Date: Wed, 14 Dec 2005 16:01:13 +0100 Subject: [SciPy-user] Bug in inverse matrix calculation for "scipy_core-0.8.4.win32-py2.3.exe" In-Reply-To: References: Message-ID: <43A033B9.5000303@mecha.uni-stuttgart.de> Frank wrote: >"On this note. Is there a way of determining before hand in scipy if a >matrix is singular, say by calculating its rank, e.g.:" > >if det(matrix) = 0, then the matrix is singular > >_______________________________________________ >SciPy-user mailing list >SciPy-user at scipy.net >http://www.scipy.net/mailman/listinfo/scipy-user > This is not very reliable when using floating point operations. See the book by Carl D. Meyer "Matrix analysis and applied linear algebra" SIAM 2000 especially chapter 6 p. 466 Example 6.1.2 Nils From pjrandew at sun.ac.za Wed Dec 14 10:13:07 2005 From: pjrandew at sun.ac.za (Randewijk P-J ) Date: Wed, 14 Dec 2005 17:13:07 +0200 Subject: [SciPy-user] Bug in inverse matrixcalculation for "scipy_core-0.8.4.win32-py2.3.exe" Message-ID: Now that you metion it... "sometimes" the inverse of some of my supposedly singular matrixes has "very large" values, because the determinant is actually not zero, but a "very small" value... e.g. >>> linalg.det(m) -1.5717747464951435e-006 >>> > -----Original Message----- > From: scipy-user-bounces at scipy.net > [mailto:scipy-user-bounces at scipy.net] On Behalf Of Nils Wagner > Sent: 14 December 2005 17:01 > To: SciPy Users List > Subject: Re: [SciPy-user] Bug in inverse matrixcalculation > for "scipy_core-0.8.4.win32-py2.3.exe" > > > Frank wrote: > >"On this note. Is there a way of determining before hand in > scipy if a > >matrix is singular, say by calculating its rank, e.g.:" > > > >if det(matrix) = 0, then the matrix is singular > > > >_______________________________________________ > >SciPy-user mailing list > >SciPy-user at scipy.net http://www.scipy.net/mailman/listinfo/scipy-user > > > This is not very reliable when using floating point > operations. See the book by Carl D. Meyer "Matrix analysis > and applied linear algebra" SIAM 2000 especially chapter 6 p. > 466 Example 6.1.2 > > Nils > > _______________________________________________ > SciPy-user mailing list > SciPy-user at scipy.net http://www.scipy.net/mailman/listinfo/scipy-user > From managan at llnl.gov Wed Dec 14 12:12:06 2005 From: managan at llnl.gov (Rob Managan) Date: Wed, 14 Dec 2005 09:12:06 -0800 Subject: [SciPy-user] building with local libraries In-Reply-To: References: Message-ID: >On Tue, 13 Dec 2005, Rob Managan wrote: > >> What is the proper way to tell scipy to use libraries that are not in >> the 'standard" locations? >> It seems that for FFTW you have to set and environment variable and >> not use site.cfg. > >Which lines did you put into site.cfg? > >For example: > >[fftw] >library_dirs = /scr/python/lib/ >include_dirs = /scr/python/include/ > >Note that you will also have to specify `include_dirs`, >otherwise it will find the libraries, but not the include >files and therefore tell you that there is no fftw at all. > >(Note to developers: wouldn't it be nicer at this point >to tell the user that the libs were found, but >not the header files, which are needed for the install?) > I actually tried to do it with the DEFAULT section by adding a directory to the end of the existing list for both libraries and includes and sources as follows: [DEFAULT] library_dirs = /usr/lib:/usr/local/lib:/opt/lib:/Users/managan/Documents/local/lib include_dirs = /usr/include:/usr/local/include:/opt/include:/Users/managan/Documents/local/include src_dirs = /usr/local/src:/opt/src:/Users/managan/Documents/local/src # search static libraries (.a) in preference to shared ones (.so) search_static_first = 0 [fftw] #fftw_libs = rfftw, fftw #fftw_opt_libs = rfftw_threaded, fftw_threaded # if the above aren't found, look for {s,d}fftw_libs and {s,d}fftw_opt_libs I will try your suggestion and see if that works. -- *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*- Rob Managan email managan at llnl.gov LLNL phone: 925-423-0903 P.O. Box 808, L-095 FAX: 925-422-3389 Livermore, CA 94551-0808 From managan at llnl.gov Wed Dec 14 12:17:11 2005 From: managan at llnl.gov (Rob Managan) Date: Wed, 14 Dec 2005 09:17:11 -0800 Subject: [SciPy-user] building with local libraries In-Reply-To: References: Message-ID: At 9:10 AM +0100 12/14/05, Arnd Baecker wrote: >On Tue, 13 Dec 2005, Rob Managan wrote: > >> What is the proper way to tell scipy to use libraries that are not in >> the 'standard" locations? >> It seems that for FFTW you have to set and environment variable and >> not use site.cfg. > >Which lines did you put into site.cfg? > >For example: > >[fftw] >library_dirs = /scr/python/lib/ >include_dirs = /scr/python/include/ Adding this info (using my directory names) to the site.cfg file did not help. The setup routines only find the FFTW libraries and headers if I set the FFTW environment variable. -- *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*- Rob Managan email managan at llnl.gov LLNL phone: 925-423-0903 P.O. Box 808, L-095 FAX: 925-422-3389 Livermore, CA 94551-0808 From Fernando.Perez at colorado.edu Wed Dec 14 16:05:18 2005 From: Fernando.Perez at colorado.edu (Fernando Perez) Date: Wed, 14 Dec 2005 14:05:18 -0700 Subject: [SciPy-user] Bug in inverse matrixcalculation for "scipy_core-0.8.4.win32-py2.3.exe" In-Reply-To: References: Message-ID: <43A0890E.4000100@colorado.edu> Randewijk P-J wrote: > Now that you metion it... "sometimes" the inverse of some of my > supposedly singular matrixes has "very large" values, because the > determinant is actually not zero, but a "very small" value... e.g. > > >>>>linalg.det(m) > > -1.5717747464951435e-006 Yup. Condition number and singularity are actually decoupled notions (to the surprise of many, including myself when I learned it). You can have a perfectly non-singular matrix with hideous condition number (making its finite-precision inversion effectively impossible) and also near-singular matrices which are well-conditioned, and hence perfectly easy to invert. Golub's text has an excellent discussion of this topic, which should be manadatory reading for anyone doing numerical linear algebra. The above paragraph I wrote refers specifically to sec. 2.7.3 (p. 81) in the second edition, which gives examples of both situations. Cheers, f From oliphant.travis at ieee.org Wed Dec 14 17:27:02 2005 From: oliphant.travis at ieee.org (Travis Oliphant) Date: Wed, 14 Dec 2005 15:27:02 -0700 Subject: [SciPy-user] Bug in inverse matrix calculation for "scipy_core-0.8.4.win32-py2.3.exe" In-Reply-To: References: Message-ID: <43A09C36.9050507@ieee.org> Randewijk P-J wrote: > Dear Travis, > > Thank-you for the "silent" version (0.8.4) of scipy_core. > > Unfortunately when trying to invert a singular matrix using scipy_core > 0.8.4, python "crashes" instead of issuing the usual error message: I'm not seeing this. I'm getting the proper error message. Can you show us the matrix you are using and give more information about the platform. Also, try it when the environment variable NO_SCIPY_IMPORT=1 import os os.environ['NO_SCIPY_IMPORT']=1 # this will not import full scipy but use only scipy_core\ import scipy Full scipy installs its own (hopefully better) matrix inverse. We need to figure out which one is giving you trouble. -Travis From oliphant.travis at ieee.org Wed Dec 14 17:56:26 2005 From: oliphant.travis at ieee.org (Travis Oliphant) Date: Wed, 14 Dec 2005 15:56:26 -0700 Subject: [SciPy-user] Changes in SVN scipy_core Message-ID: <43A0A31A.1000607@ieee.org> Hi Folks, It's great to see the configuration stuff getting better in scipy.distutils. Thanks to Pearu for all his hard work on scipy.distutils. I want to let you all know about the recent changes in the SVN version of scipy_core. As you may recall, I dramatically improved the way the data in an array can be understood by improving the PyArray_Descr structure and making it an object. As part of that improvement, it became clear that the NOTSWAPPED flag was an anomaly and shouldn't be a flag on the array itself. The byte-order of the data is a property of the data-type descriptor. This is especially clear when considering records which according to the array protocol can have some fields in one byte order and some in another. As a result, I've removed the NOTSWAPPED flag from the array object. The equivalent of arr.flags.notswapped is now arr.dtypedescr.isnative. In C, the macro PyArray_ISNOTSWAPPED(arr) is still available but it checks the data-type descriptor. All C-API and python calls that used to pass a swap paramter along with a data-type descriptor have the swap paramter deleted. These C-API changes mean you will need to fully rebuild (remove the build directory and build) both scipy_core and scipy if you check out the new SVN version. I realize that the pace of development has been rapid --- but I'm on a tight schedule ;-) Hopefully, this wil be the last relatively major change to the code base for a while. All tests pass for me for full scipy after these changes. As we all know, however, there still may be remaining issues. One issue, for example, is that a.copy() returns a copy of the data (with the same data-type descriptor so no change in the byte-order is done). There is a new method a.newbyteorder() which returns the equivalent of a.view(a.dtypedescr.newbyteorder()) which returns a new view of the data using a different byte-order description. Note that the newbyteorder method of a dtypedescr object returns a new copy of the dtypedescr object with the byte-orders swapped if is not given or forces the byteorder to a particular value if arg is given (and not arg=='|' which means ignore). All fields of the dtypedescr object are (recursively) updated with the same rule as well. Look what comes along for the ride because of these changes: a = ones((5,), 'i4') # define a big-endian array a.tostring() '\x01\x00\x00\x00\x01\x00\x00\x00\x01\x00\x00\x00\x01\x00\x00\x00\x01\x00\x00\x00' b.tostring() '\x00\x00\x00\x01\x00\x00\x00\x01\x00\x00\x00\x01\x00\x00\x00\x01\x00\x00\x00\x01' You can use these byte-order flags anywhere a data-type descriptor (dtype parameter) is required. I have not tested all the possibilities, of course, so there may still be outstanding issues. Note, however, that if you work with arrays that are not in native-byte order some operations will generally be slower. Regards, -Travis From pajer at iname.com Wed Dec 14 18:59:51 2005 From: pajer at iname.com (Gary) Date: Wed, 14 Dec 2005 18:59:51 -0500 Subject: [SciPy-user] Changes in SVN scipy_core In-Reply-To: <43A0A31A.1000607@ieee.org> References: <43A0A31A.1000607@ieee.org> Message-ID: <43A0B1F7.5030204@iname.com> Travis Oliphant wrote: >Hi Folks, > >It's great to see the configuration stuff getting better in >scipy.distutils. Thanks to Pearu for all his hard work on >scipy.distutils. > >I want to let you all know about the recent changes in the SVN version >of scipy_core. > The new version doesn't compile for me ... the old version did. WinXP, atlas binaries, MinGW 3.1, python 2.3 -regards, gary ------------------------------------------------ building 'scipy.base.multiarray' extension compiling C sources gcc options: '-O2 -Wall -Wstrict-prototypes' creating build\temp.win32-2.3\Release\scipy creating build\temp.win32-2.3\Release\scipy\base creating build\temp.win32-2.3\Release\scipy\base\src compile options: '-Ibuild\src\scipy\base\src -Iscipy\base\include -Ibuild\src\sc ipy\base -Iscipy\base\src -IC:\Python23\include -IC:\Python23\PC -c' gcc -O2 -Wall -Wstrict-prototypes -Ibuild\src\scipy\base\src -Iscipy\base\includ e -Ibuild\src\scipy\base -Iscipy\base\src -IC:\Python23\include -IC:\Python23\PC -c scipy\base\src\multiarraymodule.c -o build\temp.win32-2.3\Release\scipy\base \src\multiarraymodule.o In file included from scipy/base/src/arrayobject.c:559, from scipy/base/src/multiarraymodule.c:64: build/src/scipy/base/src/arraytypes.inc: In function `VOID_setitem': build/src/scipy/base/src/arraytypes.inc:938: warning: `savedflags' might be used uninitialized in this function build/src/scipy/base/src/arraytypes.inc: At top level: build/src/scipy/base/src/arraytypes.inc:11136: initializer element is not consta nt build/src/scipy/base/src/arraytypes.inc:11136: (near initialization for `VOID_De scr.fields') build/src/scipy/base/src/arraytypes.inc:11188: initializer element is not consta nt build/src/scipy/base/src/arraytypes.inc:11188: (near initialization for `STRING_ Descr.fields') build/src/scipy/base/src/arraytypes.inc:11240: initializer element is not consta nt build/src/scipy/base/src/arraytypes.inc:11240: (near initialization for `UNICODE _Descr.fields') build/src/scipy/base/src/arraytypes.inc:11295: initializer element is not consta nt build/src/scipy/base/src/arraytypes.inc:11295: (near initialization for `BOOL_De scr.fields') build/src/scipy/base/src/arraytypes.inc:11348: initializer element is not consta nt build/src/scipy/base/src/arraytypes.inc:11348: (near initialization for `BYTE_De scr.fields') build/src/scipy/base/src/arraytypes.inc:11401: initializer element is not consta nt build/src/scipy/base/src/arraytypes.inc:11401: (near initialization for `UBYTE_D escr.fields') build/src/scipy/base/src/arraytypes.inc:11454: initializer element is not consta nt build/src/scipy/base/src/arraytypes.inc:11454: (near initialization for `SHORT_D escr.fields') build/src/scipy/base/src/arraytypes.inc:11507: initializer element is not consta nt build/src/scipy/base/src/arraytypes.inc:11507: (near initialization for `USHORT_ Descr.fields') build/src/scipy/base/src/arraytypes.inc:11560: initializer element is not consta nt build/src/scipy/base/src/arraytypes.inc:11560: (near initialization for `INT_Des cr.fields') build/src/scipy/base/src/arraytypes.inc:11613: initializer element is not consta nt build/src/scipy/base/src/arraytypes.inc:11613: (near initialization for `UINT_De scr.fields') build/src/scipy/base/src/arraytypes.inc:11666: initializer element is not consta nt build/src/scipy/base/src/arraytypes.inc:11666: (near initialization for `LONG_De scr.fields') build/src/scipy/base/src/arraytypes.inc:11719: initializer element is not consta nt build/src/scipy/base/src/arraytypes.inc:11719: (near initialization for `ULONG_D escr.fields') build/src/scipy/base/src/arraytypes.inc:11772: initializer element is not consta nt build/src/scipy/base/src/arraytypes.inc:11772: (near initialization for `LONGLON G_Descr.fields') build/src/scipy/base/src/arraytypes.inc:11825: initializer element is not consta nt build/src/scipy/base/src/arraytypes.inc:11825: (near initialization for `ULONGLO NG_Descr.fields') build/src/scipy/base/src/arraytypes.inc:11878: initializer element is not consta nt build/src/scipy/base/src/arraytypes.inc:11878: (near initialization for `FLOAT_D escr.fields') build/src/scipy/base/src/arraytypes.inc:11931: initializer element is not consta nt build/src/scipy/base/src/arraytypes.inc:11931: (near initialization for `DOUBLE_ Descr.fields') build/src/scipy/base/src/arraytypes.inc:11984: initializer element is not consta nt build/src/scipy/base/src/arraytypes.inc:11984: (near initialization for `LONGDOU BLE_Descr.fields') build/src/scipy/base/src/arraytypes.inc:12037: initializer element is not consta nt build/src/scipy/base/src/arraytypes.inc:12037: (near initialization for `CFLOAT_ Descr.fields') build/src/scipy/base/src/arraytypes.inc:12090: initializer element is not consta nt build/src/scipy/base/src/arraytypes.inc:12090: (near initialization for `CDOUBLE _Descr.fields') build/src/scipy/base/src/arraytypes.inc:12143: initializer element is not consta nt build/src/scipy/base/src/arraytypes.inc:12143: (near initialization for `CLONGDO UBLE_Descr.fields') build/src/scipy/base/src/arraytypes.inc:12196: initializer element is not consta nt build/src/scipy/base/src/arraytypes.inc:12196: (near initialization for `OBJECT_ Descr.fields') error: Command "gcc -O2 -Wall -Wstrict-prototypes -Ibuild\src\scipy\base\src -Is cipy\base\include -Ibuild\src\scipy\base -Iscipy\base\src -IC:\Python23\include -IC:\Python23\PC -c scipy\base\src\multiarraymodule.c -o build\temp.win32-2.3\Re lease\scipy\base\src\multiarraymodule.o" failed with exit status 1 From oliphant.travis at ieee.org Wed Dec 14 19:12:15 2005 From: oliphant.travis at ieee.org (Travis Oliphant) Date: Wed, 14 Dec 2005 17:12:15 -0700 Subject: [SciPy-user] Changes in SVN scipy_core In-Reply-To: <43A0B1F7.5030204@iname.com> References: <43A0A31A.1000607@ieee.org> <43A0B1F7.5030204@iname.com> Message-ID: <43A0B4DF.5080805@ieee.org> Gary wrote: >Travis Oliphant wrote: > > > >>Hi Folks, >> >>It's great to see the configuration stuff getting better in >>scipy.distutils. Thanks to Pearu for all his hard work on >>scipy.distutils. >> >>I want to let you all know about the recent changes in the SVN version >>of scipy_core. >> >> >> >The new version doesn't compile for me ... the old version did. >WinXP, atlas binaries, MinGW 3.1, python 2.3 > > Try now. I forgot about that little issue on windows. -Travis From pajer at iname.com Wed Dec 14 19:38:11 2005 From: pajer at iname.com (Gary) Date: Wed, 14 Dec 2005 19:38:11 -0500 Subject: [SciPy-user] Changes in SVN scipy_core In-Reply-To: <43A0B4DF.5080805@ieee.org> References: <43A0A31A.1000607@ieee.org> <43A0B1F7.5030204@iname.com> <43A0B4DF.5080805@ieee.org> Message-ID: <43A0BAF3.8020407@iname.com> Travis Oliphant wrote: >Gary wrote: > > > >>Travis Oliphant wrote: >> >> >> >> >> >>>Hi Folks, >>> >>>It's great to see the configuration stuff getting better in >>>scipy.distutils. Thanks to Pearu for all his hard work on >>>scipy.distutils. >>> >>>I want to let you all know about the recent changes in the SVN version >>>of scipy_core. >>> >>> >>> >>> >>> >>The new version doesn't compile for me ... the old version did. >>WinXP, atlas binaries, MinGW 3.1, python 2.3 >> >> >> >> >Try now. I forgot about that little issue on windows. > >-Travis > > A - OK now. thanks, g >_______________________________________________ >SciPy-user mailing list >SciPy-user at scipy.net >http://www.scipy.net/mailman/listinfo/scipy-user > > > From pjrandew at sun.ac.za Thu Dec 15 02:38:53 2005 From: pjrandew at sun.ac.za (Randewijk P-J ) Date: Thu, 15 Dec 2005 09:38:53 +0200 Subject: [SciPy-user] Bug in inverse matrixcalculation for "scipy_core-0.8.4.win32-py2.3.exe" Message-ID: Dear Travis, ... >>> os.environ['NO_SCIPY_IMPORT']='True' >>> from scipy import * Skip importing scipy packages (NO_SCIPY_IMPORT=True) >>> k matrix([[ 400. , 400. , 0. , 0. ], [ 0. , 0. , 400. , 400. ], [ 0. , 346.41016151, 0. , 173.20508076], [ 346.41016151, 0. , 173.20508076, 0. ]]) >>> k.I Traceback (most recent call last): File "", line 1, in ? k.I File "C:\Python\Lib\site-packages\scipy\base\matrix.py", line 204, in getI return matrix(linalg.inv(self)) File "C:\Python\Lib\site-packages\scipy\basic\basic_lite.py", line 103, in inverse return solve_linear_equations(a, Numeric.identity(a.shape[0])) File "C:\Python\Lib\site-packages\scipy\basic\basic_lite.py", line 93, in solve_linear_equations raise LinAlgError, 'Singular matrix' LinAlgError: Singular matrix >>> ... Further to Nils & Fernando's comments, for the following singular matrix k, and with 'NO_SCIPY_IMPORT'='True' ... >>> k matrix([[ 391.69663728, 407.81602433, 0. , 0. ], [ 0. , 0. , 391.69663728, 407.81602433], [ 0. , 346.1991378 , 0. , 183.56941791], [ 346.1991378 , 0. , 183.56941791, 0. ]]) >>> k.I matrix([[ -1.64892268e+13, -8.74328513e+12, 1.94239968e+13, 1.86562414e+13], [ 1.58374716e+13, 8.39769695e+12, -1.86562414e+13, -1.79188325e+13], [ 3.10975335e+13, 1.64892268e+13, -3.66323052e+13, -3.51843721e+13], [ -2.98683685e+13, -1.58374716e+13, 3.51843721e+13, 3.37936702e+13]]) >>> ... Both k matrixes fail however in full scipy... and shows the annoying message, "pythonw.exe has encountered a problem and needs to close. We are sorry for the inconvenience." My platform is winXP, py2.3 using the following binaries: scipy_core-0.8.4.win32-py2.3.exe scipy-0.4.3.win32-py2.3.exe scipy_core-0.6.1.win32-py2.3.exe and scipy-0.4.3.win32-py2.3.exe Doesn't works fine together... PJR P.S. How does the 'NO_SCIPY_IMPORT' environment variable work? with ... >>> os.environ['NO_SCIPY_IMPORT']=1 Traceback (most recent call last): File "", line 1, in ? os.environ['NO_SCIPY_IMPORT']=1 # this will not import full scipy but File "C:\Python\Lib\os.py", line 414, in __setitem__ putenv(key, item) TypeError: putenv() argument 2 must be string, not int ... "os.environ['NO_SCIPY_IMPORT']='True'" works, as shown at the top, but ... >>> os.environ['NO_SCIPY_IMPORT']='False' >>> from scipy import * Skip importing scipy packages (NO_SCIPY_IMPORT=False) >>> ... Doesn't work as I would have expect it... > -----Original Message----- > From: scipy-user-bounces at scipy.net > [mailto:scipy-user-bounces at scipy.net] On Behalf Of Travis Oliphant > Sent: 15 December 2005 00:27 > To: SciPy Users List > Subject: Re: [SciPy-user] Bug in inverse matrixcalculation > for "scipy_core-0.8.4.win32-py2.3.exe" > > > Randewijk P-J wrote: > > > Dear Travis, > > > > Thank-you for the "silent" version (0.8.4) of scipy_core. > > > > Unfortunately when trying to invert a singular matrix using > scipy_core > > 0.8.4, python "crashes" instead of issuing the usual error message: > > I'm not seeing this. I'm getting the proper error message. > Can you show > us the matrix you are using and give more information about > the platform. > > Also, try it when the environment variable NO_SCIPY_IMPORT=1 > > import os > os.environ['NO_SCIPY_IMPORT']=1 # this will not import full > scipy but > use only scipy_core\ > import scipy > > Full scipy installs its own (hopefully better) matrix > inverse. We need > to figure out which one is giving you trouble. > > -Travis > > > _______________________________________________ > SciPy-user mailing list > SciPy-user at scipy.net http://www.scipy.net/mailman/listinfo/scipy-user > From pjrandew at sun.ac.za Thu Dec 15 02:45:23 2005 From: pjrandew at sun.ac.za (Randewijk P-J ) Date: Thu, 15 Dec 2005 09:45:23 +0200 Subject: [SciPy-user] Bug in inversematrixcalculation for "scipy_core-0.8.4.win32-py2.3.exe" Message-ID: Oops, My platform is winXP, py2.3 using the following binaries: scipy_core-0.8.4.win32-py2.3.exe and scipy-0.4.3.win32-py2.3.exe The "older" scipy_core binary file: scipy_core-0.6.1.win32-py2.3.exe and scipy-0.4.3.win32-py2.3.exe does works fine together... > -----Original Message----- > From: scipy-user-bounces at scipy.net > [mailto:scipy-user-bounces at scipy.net] On Behalf Of Randewijk > P-J > Sent: 15 December 2005 09:39 > To: SciPy Users List > Subject: Re: [SciPy-user] Bug in inversematrixcalculation for > "scipy_core-0.8.4.win32-py2.3.exe" > > > Dear Travis, > > ... > >>> os.environ['NO_SCIPY_IMPORT']='True' > >>> from scipy import * > Skip importing scipy packages (NO_SCIPY_IMPORT=True) > >>> k > matrix([[ 400. , 400. , 0. , 0. ], > [ 0. , 0. , 400. , 400. ], > [ 0. , 346.41016151, 0. , 173.20508076], > [ 346.41016151, 0. , 173.20508076, 0. ]]) > >>> k.I > Traceback (most recent call last): > File "", line 1, in ? > k.I > File "C:\Python\Lib\site-packages\scipy\base\matrix.py", > line 204, in getI > return matrix(linalg.inv(self)) > File > "C:\Python\Lib\site-packages\scipy\basic\basic_lite.py", line > 103, in inverse > return solve_linear_equations(a, Numeric.identity(a.shape[0])) > File > "C:\Python\Lib\site-packages\scipy\basic\basic_lite.py", line > 93, in solve_linear_equations > raise LinAlgError, 'Singular matrix' > LinAlgError: Singular matrix > >>> > ... > > Further to Nils & Fernando's comments, for the following > singular matrix k, and with 'NO_SCIPY_IMPORT'='True' > > ... > >>> k > matrix([[ 391.69663728, 407.81602433, 0. , 0. ], > [ 0. , 0. , 391.69663728, 407.81602433], > [ 0. , 346.1991378 , 0. , 183.56941791], > [ 346.1991378 , 0. , 183.56941791, 0. ]]) > >>> k.I > matrix([[ -1.64892268e+13, -8.74328513e+12, 1.94239968e+13, > 1.86562414e+13], > [ 1.58374716e+13, 8.39769695e+12, -1.86562414e+13, > -1.79188325e+13], > [ 3.10975335e+13, 1.64892268e+13, -3.66323052e+13, > -3.51843721e+13], > [ -2.98683685e+13, -1.58374716e+13, 3.51843721e+13, > 3.37936702e+13]]) > >>> > ... > > Both k matrixes fail however in full scipy... and shows the > annoying message, "pythonw.exe has encountered a problem and > needs to close. We are sorry for the inconvenience." > > My platform is winXP, py2.3 using the following binaries: > scipy_core-0.8.4.win32-py2.3.exe scipy-0.4.3.win32-py2.3.exe > > scipy_core-0.6.1.win32-py2.3.exe > and > scipy-0.4.3.win32-py2.3.exe > > Doesn't works fine together... > > PJR > > P.S. How does the 'NO_SCIPY_IMPORT' environment variable work? > > with > > ... > >>> os.environ['NO_SCIPY_IMPORT']=1 > > Traceback (most recent call last): > File "", line 1, in ? > os.environ['NO_SCIPY_IMPORT']=1 # this will not import > full scipy but > File "C:\Python\Lib\os.py", line 414, in __setitem__ > putenv(key, item) > TypeError: putenv() argument 2 must be string, not int > ... > > "os.environ['NO_SCIPY_IMPORT']='True'" works, as shown at the > top, but > > ... > >>> os.environ['NO_SCIPY_IMPORT']='False' > >>> from scipy import * > Skip importing scipy packages (NO_SCIPY_IMPORT=False) > >>> > ... > > Doesn't work as I would have expect it... > > > > -----Original Message----- > > From: scipy-user-bounces at scipy.net > > [mailto:scipy-user-bounces at scipy.net] On Behalf Of Travis Oliphant > > Sent: 15 December 2005 00:27 > > To: SciPy Users List > > Subject: Re: [SciPy-user] Bug in inverse matrixcalculation > > for "scipy_core-0.8.4.win32-py2.3.exe" > > > > > > Randewijk P-J wrote: > > > > > Dear Travis, > > > > > > Thank-you for the "silent" version (0.8.4) of scipy_core. > > > > > > Unfortunately when trying to invert a singular matrix using > > scipy_core > > > 0.8.4, python "crashes" instead of issuing the usual > error message: > > > > I'm not seeing this. I'm getting the proper error message. > > Can you show > > us the matrix you are using and give more information about > > the platform. > > > > Also, try it when the environment variable NO_SCIPY_IMPORT=1 > > > > import os > > os.environ['NO_SCIPY_IMPORT']=1 # this will not import full > > scipy but > > use only scipy_core\ > > import scipy > > > > Full scipy installs its own (hopefully better) matrix > > inverse. We need > > to figure out which one is giving you trouble. > > > > -Travis > > > > > > _______________________________________________ > > SciPy-user mailing list > > SciPy-user at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-user > > > > _______________________________________________ > SciPy-user mailing list > SciPy-user at scipy.net http://www.scipy.net/mailman/listinfo/scipy-user > From oliphant.travis at ieee.org Thu Dec 15 02:56:03 2005 From: oliphant.travis at ieee.org (Travis Oliphant) Date: Thu, 15 Dec 2005 00:56:03 -0700 Subject: [SciPy-user] Bug in inversematrixcalculation for "scipy_core-0.8.4.win32-py2.3.exe" In-Reply-To: References: Message-ID: <43A12193.80300@ieee.org> Randewijk P-J wrote: >Oops, > >My platform is winXP, py2.3 using the following binaries: > >scipy_core-0.8.4.win32-py2.3.exe >and >scipy-0.4.3.win32-py2.3.exe > > Ah, yes. That's the problem. The new scipy_core is binary incompatible with its previous C-API (that's one reason for the bump in version numbers). All compiled extensions must be rebuilt. This means the old scipy-0.4.3 binary will not work but give problems like you encountered. It might be possible to catch this kind of error and warn the user before they encounter a segfault. David Cooke is working on it. Full scipy needs to be re-compiled and a new binary made. I would really appreciate the help from other users to make binary releases of full scipy (which takes a bit longer to compile...) I'm going to make another release of scipy core and at that point I will make a binary of full scipy available as well. -Travis From oliphant.travis at ieee.org Thu Dec 15 03:57:37 2005 From: oliphant.travis at ieee.org (Travis E. Oliphant) Date: Thu, 15 Dec 2005 01:57:37 -0700 Subject: [SciPy-user] New named fields in scipy core --- possible uses in color images In-Reply-To: <439CD911.9000407@astraw.com> References: <439CD911.9000407@astraw.com> Message-ID: <43A13001.8090808@ieee.org> I know that many people are not aware of the new named fields that are now an integral part of scipy_core. So, here is a simple example of their use. First of all, named fields can be constructed from any data type, not just records. The only thing the recarray subclass does is to make construction a bit cleaner, perhaps, and to allow attribute access to fields. Consider the following code (works with recent SVN): image = zeros((256,256),dtype=(uint32, [('r','u1'),('g','u1'),('b','u1'),('a','u1')])) This creates an array of zeros (which for math operations can be interpreted as an unsigned 32-bit integer) but which has named fields 'r', 'g', 'b', and 'a'. These fields can be accessed (as unsigned 8-bit integers) using image['r'] image['g'] image['b'] image['a'] or the whole image can be accessed at one time using the image array. I'm not sure, aside from perhaps code readibility, if there is any benefit from this approach over the standard representation as image = zeros((256,256,4), dtype=uint8) but, it's kind of interesting that such things are now possible. Note, however, that one thing the records.py module provides over this simple approach is an "array-scalar" that also can have fields. In our example: image['r'][10,20] would work and return a uint8 scalar, but image[10,20]['r'] would not because image[10,20] is a uint32 scalar (no fields). image[10,20].getfield(*image.dtypedescr.fields['r']) would work though. Have fun... -Travis From nwagner at mecha.uni-stuttgart.de Thu Dec 15 04:06:36 2005 From: nwagner at mecha.uni-stuttgart.de (Nils Wagner) Date: Thu, 15 Dec 2005 10:06:36 +0100 Subject: [SciPy-user] Bug in inverse matrix calculation for "scipy_core-0.8.4.win32-py2.3.exe" In-Reply-To: <43A09C36.9050507@ieee.org> References: <43A09C36.9050507@ieee.org> Message-ID: <43A1321C.4020204@mecha.uni-stuttgart.de> Travis Oliphant wrote: >Randewijk P-J wrote: > > >>Dear Travis, >> >>Thank-you for the "silent" version (0.8.4) of scipy_core. >> >>Unfortunately when trying to invert a singular matrix using scipy_core >>0.8.4, python "crashes" instead of issuing the usual error message: >> > >I'm not seeing this. I'm getting the proper error message. Can you show >us the matrix you are using and give more information about the platform. > >Also, try it when the environment variable NO_SCIPY_IMPORT=1 > >import os >os.environ['NO_SCIPY_IMPORT']=1 # this will not import full scipy but >use only scipy_core\ >import scipy > >Full scipy installs its own (hopefully better) matrix inverse. We need >to figure out which one is giving you trouble. > >-Travis > > >_______________________________________________ >SciPy-user mailing list >SciPy-user at scipy.net >http://www.scipy.net/mailman/listinfo/scipy-user > Hi Travis, I would prefer a warning similar to matlab Warning: Matrix is close to singular or badly scaled. Results may be inaccurate. e.g. RCOND=2.051286e-16 The inverse is useless in case of (nearly) singular matrices and should not be used for further computations. Any comments ? Nils -------------- next part -------------- A non-text attachment was scrubbed... Name: test_inv.m Type: application/m-file Size: 46 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: test_inv.py Type: text/x-python Size: 107 bytes Desc: not available URL: From jaonary at free.fr Thu Dec 15 09:23:32 2005 From: jaonary at free.fr (jaonary at free.fr) Date: Thu, 15 Dec 2005 15:23:32 +0100 Subject: [SciPy-user] what's wrong with radom.multivariate_normal Message-ID: <1134656612.43a17c644dc80@imp1-g19.free.fr> Hi all, Here I am again with yet another scipy usage problem :-). I'd like to generate a sample of multivariate_normal random variable. Before, I used numeric with RandomArray. This worked well, but the resulting array was misformed. There was an extra comma at the end of each row something like [1,2,]. It's a problem for me because I need to put the result in a function that expect a scipy array as input. After, some google search I see that there's a funcition in scipy.random that sample different rv. When I try to use the one for the multinomial rv I get this error : data1 = random.multivariate_normal([0,0],[[0.5,0],[0,0.5]],[10]) Traceback (most recent call last): File "", line 1, in -toplevel- data1 = random.multivariate_normal([0,0],[[0.5,0],[0,0.5]],[10]) File "mtrand.pyx", line 837, in mtrand.RandomState.multivariate_normal AttributeError: 'module' object has no attribute 'singular_value_decomposition' What's up ? Thanks for your help Jaonary From aisaac at american.edu Thu Dec 15 09:40:40 2005 From: aisaac at american.edu (Alan G Isaac) Date: Thu, 15 Dec 2005 09:40:40 -0500 Subject: [SciPy-user] what's wrong with radom.multivariate_normal In-Reply-To: <1134656612.43a17c644dc80@imp1-g19.free.fr> References: <1134656612.43a17c644dc80@imp1-g19.free.fr> Message-ID: On Thu, 15 Dec 2005, jaonary at free.fr apparently wrote: > data1 = random.multivariate_normal([0,0],[[0.5,0],[0,0.5]],[10]) > Traceback (most recent call last): > File "", line 1, in -toplevel- > data1 = random.multivariate_normal([0,0],[[0.5,0],[0,0.5]],[10]) > File "mtrand.pyx", line 837, in mtrand.RandomState.multivariate_normal > AttributeError: 'module' object has no attribute 'singular_value_decomposition' >>> scipy.base.__version__ '0.8.4' >>> data1 = scipy.random.multivariate_normal([0,0],[[0.5,0],[0,0.5]],[10]) >>> data1 array([[ 0.24173896, 0.68537262], [-0.75999958, 0.26496178], [ 0.15525849, -0.61052565], [-0.94612055, -0.98556872], [-0.34111442, 0.86108778], [ 1.09459551, 0.56298158], [ 0.12430803, -0.42073144], [-0.30572437, -0.6358559 ], [-0.52274094, 0.00495374], [-1.34852903, -0.96152263]]) fwiw, Alan Isaac From pajer at iname.com Thu Dec 15 09:52:56 2005 From: pajer at iname.com (Gary) Date: Thu, 15 Dec 2005 09:52:56 -0500 Subject: [SciPy-user] what's wrong with radom.multivariate_normal In-Reply-To: References: <1134656612.43a17c644dc80@imp1-g19.free.fr> Message-ID: <43A18348.7030004@iname.com> Alan G Isaac wrote: >On Thu, 15 Dec 2005, jaonary at free.fr apparently wrote: > > >>data1 = random.multivariate_normal([0,0],[[0.5,0],[0,0.5]],[10]) >>Traceback (most recent call last): >> File "", line 1, in -toplevel- >> data1 = random.multivariate_normal([0,0],[[0.5,0],[0,0.5]],[10]) >> File "mtrand.pyx", line 837, in mtrand.RandomState.multivariate_normal >>AttributeError: 'module' object has no attribute 'singular_value_decomposition' >> >> > > > > >>>>scipy.base.__version__ >>>> >>>> >'0.8.4' > > >>>>data1 = scipy.random.multivariate_normal([0,0],[[0.5,0],[0,0.5]],[10]) >>>>data1 >>>> >>>> >array([[ 0.24173896, 0.68537262], > [-0.75999958, 0.26496178], > [ 0.15525849, -0.61052565], > [-0.94612055, -0.98556872], > [-0.34111442, 0.86108778], > [ 1.09459551, 0.56298158], > [ 0.12430803, -0.42073144], > [-0.30572437, -0.6358559 ], > [-0.52274094, 0.00495374], > [-1.34852903, -0.96152263]]) > >fwiw, >Alan Isaac > > yet [WinXP, python2.3] In [4]: scipy.random.multivariate_normal([0,0], [[0.5,0], [0,0.5]],[10]) --------------------------------------------------------------------------- exceptions.AttributeError Traceback (most recent call last) C:\Documents and Settings\Gary\My Documents\ C:\Documents and Settings\Gary\My Documents\mtrand.pyx in mtrand.RandomState.mul tivariate_normal() AttributeError: 'module' object has no attribute 'singular_value_decomposition' In [5]: scipy.base.__version__ Out[5]: '0.8.6.1666' fwiw, -gary >_______________________________________________ >SciPy-user mailing list >SciPy-user at scipy.net >http://www.scipy.net/mailman/listinfo/scipy-user > > > From dalembertian at yahoo.com Thu Dec 15 10:30:12 2005 From: dalembertian at yahoo.com (Frank) Date: Thu, 15 Dec 2005 09:30:12 -0600 Subject: [SciPy-user] interpolate subpackage Message-ID: <049D6598-656F-4602-BE04-770277EFB6F0@yahoo.com> Does anyone know why certain subpackages such as interpolate and integrate are not defined while others such as linalg and fft work fine? For example: Python 2.3.5 (#1, Mar 20 2005, 20:38:20) [GCC 3.3 20030304 (Apple Computer, Inc. build 1809)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> from scipy import * >>> interpolate Traceback (most recent call last): File "", line 1, in ? NameError: name 'interpolate' is not defined >>> linalg >>> From helmrp at yahoo.com Thu Dec 15 10:37:51 2005 From: helmrp at yahoo.com (The Helmbolds) Date: Thu, 15 Dec 2005 07:37:51 -0800 (PST) Subject: [SciPy-user] What random number generator is used in Numeric and SciPy? In-Reply-To: <43A18348.7030004@iname.com> Message-ID: <20051215153751.71953.qmail@web31813.mail.mud.yahoo.com> Python bases its random number generators on the Mersenne Twister. Do Numeric and SciPy also base their random number generators on the Mersenne Twister? If not, what do they use? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jaonary at free.fr Thu Dec 15 10:59:47 2005 From: jaonary at free.fr (jaonary at free.fr) Date: Thu, 15 Dec 2005 16:59:47 +0100 Subject: [SciPy-user] what's wrong with radom.multivariate_normal In-Reply-To: <43A18348.7030004@iname.com> References: <1134656612.43a17c644dc80@imp1-g19.free.fr> <43A18348.7030004@iname.com> Message-ID: <1134662387.43a192f3d7d5b@imp1-g19.free.fr> Here I get : >>> from scipy import * >>> import scipy.base >>> scipy.base.__version__ '0.8.4' >>> data1 = scipy.random.multivariate_normal([0,0],[[0.5,0],[0,0.5]],[10]) Traceback (most recent call last): File "", line 1, in -toplevel- data1 = scipy.random.multivariate_normal([0,0],[[0.5,0],[0,0.5]],[10]) File "mtrand.pyx", line 837, in mtrand.RandomState.multivariate_normal AttributeError: 'module' object has no attribute 'singular_value_decomposition' >>> My system : win XP sp2 , python 2.4.2 Jaonary From fonnesbeck at gmail.com Thu Dec 15 11:03:05 2005 From: fonnesbeck at gmail.com (Chris Fonnesbeck) Date: Thu, 15 Dec 2005 11:03:05 -0500 Subject: [SciPy-user] weave issue Message-ID: <723eb6930512150803h366f92e4wa8e191f20bf67efa@mail.gmail.com> I am trying to use weave inline to help me calculate the gamma function: def gamma_function(xx): # Returns the value ln[gamma(xx)] for xx > 0 gammln = """ # Line 10 "likelihood_plots.py" double x,y,tmp,ser; static double cof[6]={76.18009172947146,-86.50532032941677, 24.01409824083091,-1.231739572450155, 0.1208650973866179e-2,-0.5395239384953e-5}; int j; y=x=xx; tmp=x+5.5; tmp -= (x+0.5)*log(tmp); ser=1.000000000190015; for (j=0;j<=5;j++) ser += cof[j]/++y; return_val = -tmp+log(2.5066282746310005*ser/x); """ return weave.inline(gammln,['xx'],headers=['math.h'],compiler='gcc') As far as I can tell this looks valid. However, it fails: /Users/chris/.python24_compiled/sc_2ced629c1dae7b8a8d767dfb199392380.cpp:17:10: #include expects "FILENAME" or /Users/chris/.python24_compiled/sc_2ced629c1dae7b8a8d767dfb199392380.cpp:660:23: invalid preprocessing directive #Line /Users/chris/.python24_compiled/sc_2ced629c1dae7b8a8d767dfb199392380.cpp:17:10: #include expects "FILENAME" or /Users/chris/.python24_compiled/sc_2ced629c1dae7b8a8d767dfb199392380.cpp:660:23: invalid preprocessing directive #Line --------------------------------------------------------------------------- scipy.weave.build_tools.CompileError Traceback (most recent call last) /Users/chris/ /Users/chris/likelihood_plots.py in gamma_function(xx=4.0) 22 """ 23 ---> 24 return weave.inline(gammln,['xx'],headers=['math.h'],compiler='gcc') global weave.inline = gammln = ' \n # Line 10 "likelihood_plots.py"\n double x,y,tmp,ser; \n static double cof[6]={76.18009172947146,-86.50532032941677, \n 24.01409824083091,-1.231739572450155, \n 0.1208650973866179e-2,-0.5395239384953e-5}; \n int j; \n y=x=xx; \n tmp=x+5.5; \n tmp -= (x+0.5)*log(tmp); \n ser=1.000000000190015; \n for (j=0;j<=5;j++) ser += cof[j]/++y; \n return_val = -tmp+log(2.5066282746310005*ser/x); \n ' global headers = undefined global compiler = undefined 25 26 def factln(x): /Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/scipy/weave/inline_tools.py in inline(code=' \n # Line 10 "likelihood_plots.py"\n ...n_val = -tmp+log(2.5066282746310005*ser/x); \n ', arg_names=['xx'], local_dict={'__builtins__': {'ArithmeticError': , 'AssertionError': , 'AttributeError': , 'DeprecationWarning': , 'EOFError': , 'Ellipsis': Ellipsis, 'EnvironmentError': , 'Exception': , 'False': False, 'FloatingPointError': , ...}, 'gammln': ' \n # Line 10 "likelihood_plots.py"\n ...n_val = -tmp+log(2.5066282746310005*ser/x); \n ', 'xx': 4.0}, global_dict={'ArrayType': , 'Character': 'S1', 'Complex': 'D', 'Complex0': 'D', 'Complex128': 'G', 'Complex32': 'F', 'Complex64': 'D', 'ERR_CALL': 3, 'ERR_DEFAULT': 0, 'ERR_IGNORE': 0, ...}, force=0, compiler='gcc', verbose=0, support_code=None, headers=['math.h'], customize=None, type_converters=None, auto_downcast=1, **kw={}) 332 customize=customize, 333 type_converters = type_converters, --> 334 auto_downcast = auto_downcast, auto_downcast = 1 335 **kw) 336 /Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/scipy/weave/inline_tools.py in compile_function(code=' \n # Line 10 "likelihood_plots.py"\n ...n_val = -tmp+log(2.5066282746310005*ser/x); \n ', arg_names=['xx'], local_dict={'__builtins__': {'ArithmeticError': , 'AssertionError': , 'AttributeError': , 'DeprecationWarning': , 'EOFError': , 'Ellipsis': Ellipsis, 'EnvironmentError': , 'Exception': , 'False': False, 'FloatingPointError': , ...}, 'gammln': ' \n # Line 10 "likelihood_plots.py"\n ...n_val = -tmp+log(2.5066282746310005*ser/x); \n ', 'xx': 4.0}, global_dict={'ArrayType': , 'Character': 'S1', 'Complex': 'D', 'Complex0': 'D', 'Complex128': 'G', 'Complex32': 'F', 'Complex64': 'D', 'ERR_CALL': 3, 'ERR_DEFAULT': 0, 'ERR_IGNORE': 0, ...}, module_dir='likelihood_plots.py', compiler='gcc', verbose=0, support_code=None, headers=['math.h'], customize=None, type_converters=None, auto_downcast=1, **kw={}) 440 # setting. All input keywords are passed through to distutils 441 mod.compile(location=storage_dir,compiler=compiler, --> 442 verbose=verbose, **kw) verbose = 0 kw = {} 443 444 # import the module and return the function. Make sure /Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/scipy/weave/ext_tools.py in compile(self=, location='/Users/chris/.python24_compiled', compiler='gcc', verbose=0, **kw={'define_macros': [], 'extra_compile_args': [], 'extra_link_args': [], 'include_dirs': ['/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/scipy/weave', '/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/scipy/weave/scxx'], 'libraries': [], 'library_dirs': [], 'sources': ['/Library/Frameworks/Python.framework/Versions/2....n2.4/site-packages/scipy/weave/scxx/weave_imp.cpp']}) 351 success = build_tools.build_extension(file, temp_dir = temp, 352 compiler_name = compiler, --> 353 verbose = verbose, **kw) verbose = 0 kw = {'extra_link_args': [], 'define_macros': [], 'libraries': [], 'sources': ['/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/scipy/weave/scxx/weave_imp.cpp'], 'extra_compile_args': [], 'library_dirs': [], 'include_dirs': ['/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/scipy/weave', '/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/scipy/weave/scxx']} 354 if not success: 355 raise SystemError, 'Compilation failed' /Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/scipy/weave/build_tools.py in build_extension(module_path='/Users/chris/.python24_compiled/sc_2ced629c1dae7b8a8d767dfb199392380.cpp', compiler_name='unix', build_dir='/Users/chris/.python24_compiled', temp_dir='/tmp/chris/python24_intermediate/compiler_d8b3562b82bb4cfa4fea7b37ec5ea6ce', verbose=0, **kw={'define_macros': [], 'extra_compile_args': [], 'extra_link_args': [], 'include_dirs': ['/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/scipy/weave', '/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/scipy/weave/scxx'], 'libraries': [], 'library_dirs': [], 'sources': ['/Library/Frameworks/Python.framework/Versions/2....n2.4/site-packages/scipy/weave/scxx/weave_imp.cpp']}) 272 environ = copy.deepcopy(os.environ) 273 try: --> 274 setup(name = module_name, ext_modules = [ext],verbose=verb) setup = global name = undefined module_name = 'sc_2ced629c1dae7b8a8d767dfb199392380' global ext_modules = undefined ext = verbose = 0 verb = 0 275 finally: 276 # restore state /Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/scipy/distutils/core.py in setup(**attr={'ext_modules': [], 'name': 'sc_2ced629c1dae7b8a8d767dfb199392380', 'verbose': 0}) 91 new_attr['data_files'] = new_data_files 92 ---> 93 return old_setup(**new_attr) global old_setup = new_attr = {'cmdclass': {'bdist_rpm': , 'sdist': , 'build_src': , 'config_fc': , 'build_clib': , 'build_scripts': , 'build_ext': , 'develop': , 'build_py': , 'install_data': , 'egg_info': , 'install_headers': , 'easy_install': , 'bdist_egg': , 'install': , 'config': , 'build': }, 'headers': [], 'ext_modules': [], 'name': 'sc_2ced629c1dae7b8a8d767dfb199392380', 'verbose': 0} 94 95 def _check_append_library(libraries, item): /Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/distutils/core.py in setup(**attrs={'cmdclass': {'bdist_egg': , 'bdist_rpm': , 'build': , 'build_clib': , 'build_ext': , 'build_py': , 'build_scripts': , 'build_src': , 'config': , 'config_fc': , ...}, 'ext_modules': [], 'headers': [], 'name': 'sc_2ced629c1dae7b8a8d767dfb199392380', 'script_args': ['build_ext', '--compiler=unix', '--build-lib', '/Users/chris/.python24_compiled', '--build-temp', '/tmp/chris/python24_intermediate/compiler_d8b3562b82bb4cfa4fea7b37ec5ea6ce'], 'script_name': '', 'verbose': 0}) 164 raise 165 else: --> 166 raise SystemExit, "error: " + str(msg) global SystemExit = undefined global str = undefined msg = 167 168 return dist CompileError: error: Command "c++ -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd -fPIC -fno-common -dynamic -DNDEBUG -g -O3 -Wstrict-prototypes -I/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/scipy/weave -I/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/scipy/weave/scxx -I/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/scipy/base/include -I/Library/Frameworks/Python.framework/Versions/2.4/include/python2.4 -c /Users/chris/.python24_compiled/sc_2ced629c1dae7b8a8d767dfb199392380.cpp -o /tmp/chris/python24_intermediate/compiler_d8b3562b82bb4cfa4fea7b37ec5ea6ce/Users/chris/.python24_compiled/sc_2ced629c1dae7b8a8d767dfb199392380.o" failed with exit status 1 -- Chris Fonnesbeck Atlanta, GA From fonnesbeck at gmail.com Thu Dec 15 11:20:11 2005 From: fonnesbeck at gmail.com (Chris Fonnesbeck) Date: Thu, 15 Dec 2005 11:20:11 -0500 Subject: [SciPy-user] weave issue NEVER MIND Message-ID: <723eb6930512150820t341f275cje39e0b215fa38c16@mail.gmail.com> I'm an idiot. Sorry. On 12/15/05, Chris Fonnesbeck wrote: > I am trying to use weave inline to help me calculate the gamma function: > > def gamma_function(xx): > > # Returns the value ln[gamma(xx)] for xx > 0 > gammln = """ > # Line 10 "likelihood_plots.py" > double x,y,tmp,ser; > static double cof[6]={76.18009172947146,-86.50532032941677, > 24.01409824083091,-1.231739572450155, > 0.1208650973866179e-2,-0.5395239384953e-5}; > int j; > y=x=xx; > tmp=x+5.5; > tmp -= (x+0.5)*log(tmp); > ser=1.000000000190015; > for (j=0;j<=5;j++) ser += cof[j]/++y; > return_val = -tmp+log(2.5066282746310005*ser/x); > """ > > return weave.inline(gammln,['xx'],headers=['math.h'],compiler='gcc') > > As far as I can tell this looks valid. However, it fails: > > > /Users/chris/.python24_compiled/sc_2ced629c1dae7b8a8d767dfb199392380.cpp:17:10: > #include expects "FILENAME" or > /Users/chris/.python24_compiled/sc_2ced629c1dae7b8a8d767dfb199392380.cpp:660:23: > invalid preprocessing directive #Line > /Users/chris/.python24_compiled/sc_2ced629c1dae7b8a8d767dfb199392380.cpp:17:10: > #include expects "FILENAME" or > /Users/chris/.python24_compiled/sc_2ced629c1dae7b8a8d767dfb199392380.cpp:660:23: > invalid preprocessing directive #Line > --------------------------------------------------------------------------- > scipy.weave.build_tools.CompileError > Traceback (most recent call last) > > /Users/chris/ > > /Users/chris/likelihood_plots.py in gamma_function(xx=4.0) > 22 """ > 23 > ---> 24 return weave.inline(gammln,['xx'],headers=['math.h'],compiler='gcc') > global weave.inline = > gammln = ' \n # Line 10 "likelihood_plots.py"\n > double x,y,tmp,ser; \n static double > cof[6]={76.18009172947146,-86.50532032941677, \n > 24.01409824083091,-1.231739572450155, \n > 0.1208650973866179e-2,-0.5395239384953e-5}; \n int j; \n > y=x=xx; \n tmp=x+5.5; \n tmp -= > (x+0.5)*log(tmp); \n ser=1.000000000190015; \n > for (j=0;j<=5;j++) ser += cof[j]/++y; \n return_val = > -tmp+log(2.5066282746310005*ser/x); \n ' > global headers = undefined > global compiler = undefined > 25 > 26 def factln(x): > > /Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/scipy/weave/inline_tools.py > in inline(code=' \n # Line 10 "likelihood_plots.py"\n > ...n_val = -tmp+log(2.5066282746310005*ser/x); \n ', > arg_names=['xx'], local_dict={'__builtins__': {'ArithmeticError': > , 'AssertionError': exceptions.AssertionError at 0x7ab0>, 'AttributeError': exceptions.AttributeError at 0x7960>, 'DeprecationWarning': exceptions.DeprecationWarning at 0x1e120>, 'EOFError': exceptions.EOFError at 0x7750>, 'Ellipsis': Ellipsis, > 'EnvironmentError': , > 'Exception': , 'False': False, > 'FloatingPointError': , > ...}, 'gammln': ' \n # Line 10 "likelihood_plots.py"\n > ...n_val = -tmp+log(2.5066282746310005*ser/x); \n ', 'xx': 4.0}, > global_dict={'ArrayType': , 'Character': 'S1', > 'Complex': 'D', 'Complex0': 'D', 'Complex128': 'G', 'Complex32': 'F', > 'Complex64': 'D', 'ERR_CALL': 3, 'ERR_DEFAULT': 0, 'ERR_IGNORE': 0, > ...}, force=0, compiler='gcc', verbose=0, support_code=None, > headers=['math.h'], customize=None, type_converters=None, > auto_downcast=1, **kw={}) > 332 customize=customize, > 333 type_converters = type_converters, > --> 334 auto_downcast = auto_downcast, > auto_downcast = 1 > 335 **kw) > 336 > > /Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/scipy/weave/inline_tools.py > in compile_function(code=' \n # Line 10 > "likelihood_plots.py"\n ...n_val = > -tmp+log(2.5066282746310005*ser/x); \n ', arg_names=['xx'], > local_dict={'__builtins__': {'ArithmeticError': exceptions.ArithmeticError at 0x7ba0>, 'AssertionError': exceptions.AssertionError at 0x7ab0>, 'AttributeError': exceptions.AttributeError at 0x7960>, 'DeprecationWarning': exceptions.DeprecationWarning at 0x1e120>, 'EOFError': exceptions.EOFError at 0x7750>, 'Ellipsis': Ellipsis, > 'EnvironmentError': , > 'Exception': , 'False': False, > 'FloatingPointError': , > ...}, 'gammln': ' \n # Line 10 "likelihood_plots.py"\n > ...n_val = -tmp+log(2.5066282746310005*ser/x); \n ', 'xx': 4.0}, > global_dict={'ArrayType': , 'Character': 'S1', > 'Complex': 'D', 'Complex0': 'D', 'Complex128': 'G', 'Complex32': 'F', > 'Complex64': 'D', 'ERR_CALL': 3, 'ERR_DEFAULT': 0, 'ERR_IGNORE': 0, > ...}, module_dir='likelihood_plots.py', compiler='gcc', verbose=0, > support_code=None, headers=['math.h'], customize=None, > type_converters=None, auto_downcast=1, **kw={}) > 440 # setting. All input keywords are passed through to distutils > 441 mod.compile(location=storage_dir,compiler=compiler, > --> 442 verbose=verbose, **kw) > verbose = 0 > kw = {} > 443 > 444 # import the module and return the function. Make sure > > /Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/scipy/weave/ext_tools.py > in compile(self= at 0x4610260>, location='/Users/chris/.python24_compiled', > compiler='gcc', verbose=0, **kw={'define_macros': [], > 'extra_compile_args': [], 'extra_link_args': [], 'include_dirs': > ['/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/scipy/weave', > '/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/scipy/weave/scxx'], > 'libraries': [], 'library_dirs': [], 'sources': > ['/Library/Frameworks/Python.framework/Versions/2....n2.4/site-packages/scipy/weave/scxx/weave_imp.cpp']}) > 351 success = build_tools.build_extension(file, temp_dir = temp, > 352 compiler_name = compiler, > --> 353 verbose = verbose, **kw) > verbose = 0 > kw = {'extra_link_args': [], 'define_macros': [], 'libraries': > [], 'sources': ['/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/scipy/weave/scxx/weave_imp.cpp'], > 'extra_compile_args': [], 'library_dirs': [], 'include_dirs': > ['/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/scipy/weave', > '/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/scipy/weave/scxx']} > 354 if not success: > 355 raise SystemError, 'Compilation failed' > > /Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/scipy/weave/build_tools.py > in build_extension(module_path='/Users/chris/.python24_compiled/sc_2ced629c1dae7b8a8d767dfb199392380.cpp', > compiler_name='unix', build_dir='/Users/chris/.python24_compiled', > temp_dir='/tmp/chris/python24_intermediate/compiler_d8b3562b82bb4cfa4fea7b37ec5ea6ce', > verbose=0, **kw={'define_macros': [], 'extra_compile_args': [], > 'extra_link_args': [], 'include_dirs': > ['/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/scipy/weave', > '/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/scipy/weave/scxx'], > 'libraries': [], 'library_dirs': [], 'sources': > ['/Library/Frameworks/Python.framework/Versions/2....n2.4/site-packages/scipy/weave/scxx/weave_imp.cpp']}) > 272 environ = copy.deepcopy(os.environ) > 273 try: > --> 274 setup(name = module_name, ext_modules = [ext],verbose=verb) > setup = > global name = undefined > module_name = 'sc_2ced629c1dae7b8a8d767dfb199392380' > global ext_modules = undefined > ext = > verbose = 0 > verb = 0 > 275 finally: > 276 # restore state > > /Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/scipy/distutils/core.py > in setup(**attr={'ext_modules': [ instance at 0x4620b48>], 'name': > 'sc_2ced629c1dae7b8a8d767dfb199392380', 'verbose': 0}) > 91 new_attr['data_files'] = new_data_files > 92 > ---> 93 return old_setup(**new_attr) > global old_setup = > new_attr = {'cmdclass': {'bdist_rpm': scipy.distutils.command.bdist_rpm.bdist_rpm at 0x292fc00>, 'sdist': > , 'build_src': > , > 'config_fc': at 0x28fe360>, 'build_clib': scipy.distutils.command.build_clib.build_clib at 0x28fea50>, > 'build_scripts': scipy.distutils.command.build_scripts.build_scripts at 0x290ef60>, > 'build_ext': 0x28fe690>, 'develop': 0x292fed0>, 'build_py': scipy.distutils.command.build_py.build_py at 0x28fe330>, > 'install_data': scipy.distutils.command.install_data.install_data at 0x29186f0>, > 'egg_info': , > 'install_headers': scipy.distutils.command.install_headers.install_headers at 0x292f6f0>, > 'easy_install': 0x295ec90>, 'bdist_egg': at 0x28dffc0>, 'install': scipy.distutils.command.install.install at 0x292f720>, 'config': > , 'build': > }, 'headers': > [], 'ext_modules': [ 0x4620b48>], 'name': 'sc_2ced629c1dae7b8a8d767dfb199392380', > 'verbose': 0} > 94 > 95 def _check_append_library(libraries, item): > > /Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/distutils/core.py > in setup(**attrs={'cmdclass': {'bdist_egg': setuptools.command.bdist_egg.bdist_egg at 0x28dffc0>, 'bdist_rpm': > , > 'build': , > 'build_clib': 0x28fea50>, 'build_ext': scipy.distutils.command.build_ext.build_ext at 0x28fe690>, 'build_py': > , > 'build_scripts': scipy.distutils.command.build_scripts.build_scripts at 0x290ef60>, > 'build_src': 0x290ef00>, 'config': 0x28f7f90>, 'config_fc': scipy.distutils.command.config_compiler.config_fc at 0x28fe360>, ...}, > 'ext_modules': [ 0x4620b48>], 'headers': [], 'name': > 'sc_2ced629c1dae7b8a8d767dfb199392380', 'script_args': ['build_ext', > '--compiler=unix', '--build-lib', '/Users/chris/.python24_compiled', > '--build-temp', > '/tmp/chris/python24_intermediate/compiler_d8b3562b82bb4cfa4fea7b37ec5ea6ce'], > 'script_name': '', 'verbose': 0}) > 164 raise > 165 else: > --> 166 raise SystemExit, "error: " + str(msg) > global SystemExit = undefined > global str = undefined > msg = > 167 > 168 return dist > > CompileError: error: Command "c++ -fno-strict-aliasing > -Wno-long-double -no-cpp-precomp -mno-fused-madd -fPIC -fno-common > -dynamic -DNDEBUG -g -O3 -Wstrict-prototypes > -I/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/scipy/weave > -I/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/scipy/weave/scxx > -I/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/scipy/base/include > -I/Library/Frameworks/Python.framework/Versions/2.4/include/python2.4 > -c /Users/chris/.python24_compiled/sc_2ced629c1dae7b8a8d767dfb199392380.cpp > -o /tmp/chris/python24_intermediate/compiler_d8b3562b82bb4cfa4fea7b37ec5ea6ce/Users/chris/.python24_compiled/sc_2ced629c1dae7b8a8d767dfb199392380.o" > failed with exit status 1 > > > -- > Chris Fonnesbeck > Atlanta, GA > -- Chris Fonnesbeck Atlanta, GA From managan at llnl.gov Thu Dec 15 13:04:15 2005 From: managan at llnl.gov (Rob Managan) Date: Thu, 15 Dec 2005 10:04:15 -0800 Subject: [SciPy-user] Bug in FFTPACK wrappers Message-ID: I am still getting errors on mac OSX 10.3.9, python 2.4.1 in the ifft(fft(sin(x))) when the fftpack routine is used. The routines in the basic package work properly. Does anyone have them working properly? Any pointers on how to find out where the problem is? I think fftpack is using fftw-3.x libraries. I have attached a simple script that shows the difference between the basic and fftpack results. -- *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*- Rob Managan email managan at llnl.gov LLNL phone: 925-423-0903 P.O. Box 808, L-095 FAX: 925-422-3389 Livermore, CA 94551-0808 -------------- next part -------------- A non-text attachment was scrubbed... Name: testfft2.py Type: application/octet-stream Size: 646 bytes Desc: not available URL: From managan at llnl.gov Thu Dec 15 13:45:52 2005 From: managan at llnl.gov (Rob Managan) Date: Thu, 15 Dec 2005 10:45:52 -0800 Subject: [SciPy-user] Benchmark data In-Reply-To: References: <43995919.2090401@ieee.org> <20051209201510.04c352d6.gerard.vermeulen@grenoble.cnrs.fr> <20051210011624.7347cb56.gerard.vermeulen@grenoble.cnrs.fr> <439A6CC0.6070003@ieee.org> Message-ID: Here is benchmark data for Mac OSX 10.3.9 I also see that scipy.base wins overall. The results are surprisingly good for the small vector lengths. Enough so that I inverted the order that the packages were tested in from Numeric, numarray, scipy to scipy, numarray, Numeric. The results change a lot!! There must be a cache issue with the data or something. python bench.py 3 Python 2.4.1 (#2, Mar 31 2005, 00:05:10) [GCC 3.3 20030304 (Apple Computer, Inc. build 1666)] Optimization flags: -DNDEBUG -g -O3 -Wall -Wstrict-prototypes CPU info: getNCPUs is_32bit is_ppc Numeric-24.2 numarray-1.5.0 scipy-core-0.8.6.1671 benchmark size = 3 (vectors of length 64) label Numeric numarray scipy.base 1 0.000114 0.001903 0.0001171 2 0.000108 0.003893 5.198e-05 3 2.193e-05 0.0006509 3.481e-05 4 7.2e-05 0.002964 5.817e-05 5 1.812e-05 0.00088 2.193e-05 6 1.788e-05 2.098e-05 2.193e-05 7 4.601e-05 8.011e-05 4.411e-05 8 1.311e-05 4.292e-05 1.097e-05 9 0.000149 0.002177 0.000205 10 0.0001209 0.0002561 0.0004699 11 0.008709 0.0003729 0.000217 TOTAL 0.00939 0.01324 0.001253 python bench.py 5 Python 2.4.1 (#2, Mar 31 2005, 00:05:10) [GCC 3.3 20030304 (Apple Computer, Inc. build 1666)] Optimization flags: -DNDEBUG -g -O3 -Wall -Wstrict-prototypes CPU info: getNCPUs is_32bit is_ppc Numeric-24.2 numarray-1.5.0 scipy-core-0.8.6.1671 benchmark size = 5 (vectors of length 1024) label Numeric numarray scipy.base 1 0.000159 0.002145 0.0001631 2 0.00016 0.0005598 8.202e-05 3 4.196e-05 0.000659 6.199e-05 4 0.008766 0.008109 9.298e-05 5 4.506e-05 0.0007169 4.101e-05 6 5.698e-05 4.411e-05 4.601e-05 7 0.0003481 0.0001349 7.987e-05 8 0.0002658 0.0003841 0.0001831 9 0.0006611 0.004028 0.000767 10 0.000603 0.0005531 0.0005159 11 0.0003901 0.0008669 0.000401 TOTAL 0.0115 0.0182 0.002434 % python bench.py 7 Python 2.4.1 (#2, Mar 31 2005, 00:05:10) [GCC 3.3 20030304 (Apple Computer, Inc. build 1666)] Optimization flags: -DNDEBUG -g -O3 -Wall -Wstrict-prototypes CPU info: getNCPUs is_32bit is_ppc Numeric-24.2 numarray-1.5.0 scipy-core-0.8.6.1671 benchmark size = 7 (vectors of length 16384) label Numeric numarray scipy.base 1 0.00989 0.001385 0.0003741 2 0.00103 0.001106 0.0008531 3 0.0005479 0.0009282 0.00054 4 0.003236 0.007418 0.002718 5 0.000699 0.0172 0.0006359 6 0.000463 0.0006778 0.00056 7 0.008911 0.00371 0.004615 8 0.002682 0.002305 0.01123 9 0.01685 0.06133 0.03925 10 0.02049 0.01679 0.01465 11 0.03076 0.01315 0.0128 TOTAL 0.09556 0.126 0.08823 python bench.py 10 Python 2.4.1 (#2, Mar 31 2005, 00:05:10) [GCC 3.3 20030304 (Apple Computer, Inc. build 1666)] Optimization flags: -DNDEBUG -g -O3 -Wall -Wstrict-prototypes CPU info: getNCPUs is_32bit is_ppc Numeric-24.2 numarray-1.5.0 scipy-core-0.8.6.1671 benchmark size = 10 (vectors of length 1048576) label Numeric numarray scipy.base 1 0.07384 0.01642 0.01819 2 0.03989 0.03953 0.1033 3 0.02711 0.02703 0.04777 4 0.1793 0.1063 0.1082 5 0.0731 0.03541 0.03534 6 0.07709 0.02951 0.02816 7 0.2825 0.1881 0.1056 8 0.09519 0.1824 0.06622 9 1.242 0.932 0.9789 10 1.006 1.081 0.9415 11 0.7909 0.6992 0.7932 TOTAL 3.887 3.337 3.226 AFTER reversing the order of the three packages python bench.py 3 [GCC 3.3 20030304 (Apple Computer, Inc. build 1666)] Optimization flags: -DNDEBUG -g -O3 -Wall -Wstrict-prototypes CPU info: getNCPUs is_32bit is_ppc Numeric-24.2 numarray-1.5.0 scipy-core-0.8.6.1671 benchmark size = 3 (vectors of length 64) label scipy.base numarray Numeric 1 0.000216 0.001491 8.392e-05 2 6.485e-05 0.004609 9.108e-05 3 5.698e-05 0.000685 2.003e-05 4 7.319e-05 0.001654 5.507e-05 5 2.289e-05 0.0004721 1.693e-05 6 2.193e-05 1.788e-05 1.788e-05 7 4.506e-05 7.391e-05 3.409e-05 8 2.599e-05 4.005e-05 1.097e-05 9 0.000242 0.002147 0.000128 10 0.009578 0.0001972 0.0001061 11 0.000159 0.00072 7.987e-05 TOTAL 0.01051 0.01211 0.000644 python bench.py 5 Python 2.4.1 (#2, Mar 31 2005, 00:05:10) [GCC 3.3 20030304 (Apple Computer, Inc. build 1666)] Optimization flags: -DNDEBUG -g -O3 -Wall -Wstrict-prototypes CPU info: getNCPUs is_32bit is_ppc Numeric-24.2 numarray-1.5.0 scipy-core-0.8.6.1671 benchmark size = 5 (vectors of length 1024) label scipy.base numarray Numeric 1 0.000123 0.001099 0.0001161 2 8.082e-05 0.0005021 0.000149 3 0.0001712 0.0005639 4.196e-05 4 0.003357 0.001518 9.298e-05 5 4.506e-05 0.0004861 3.815e-05 6 4.983e-05 3.982e-05 3.886e-05 7 0.0001111 0.000108 6.795e-05 8 0.0002811 0.001387 0.0001831 9 0.0006509 0.01415 0.0004981 10 0.0005009 0.000551 0.0004358 11 0.0004001 0.0008461 0.0003531 TOTAL 0.005771 0.02125 0.002015 python bench.py 7 Python 2.4.1 (#2, Mar 31 2005, 00:05:10) [GCC 3.3 20030304 (Apple Computer, Inc. build 1666)] Optimization flags: -DNDEBUG -g -O3 -Wall -Wstrict-prototypes CPU info: getNCPUs is_32bit is_ppc Numeric-24.2 numarray-1.5.0 scipy-core-0.8.6.1671 benchmark size = 7 (vectors of length 16384) label scipy.base numarray Numeric 1 0.000561 0.001411 0.001281 2 0.01064 0.001446 0.0008008 3 0.0007398 0.001116 0.0004001 4 0.005841 0.003638 0.002384 5 0.0006442 0.001256 0.001408 6 0.0004599 0.0004351 0.0004339 7 0.002262 0.002427 0.00267 8 0.001092 0.001196 0.001114 9 0.02235 0.01926 0.01542 10 0.01499 0.01553 0.0199 11 0.01259 0.01623 0.0115 TOTAL 0.07216 0.06394 0.05731 python bench.py 10 Python 2.4.1 (#2, Mar 31 2005, 00:05:10) [GCC 3.3 20030304 (Apple Computer, Inc. build 1666)] Optimization flags: -DNDEBUG -g -O3 -Wall -Wstrict-prototypes CPU info: getNCPUs is_32bit is_ppc Numeric-24.2 numarray-1.5.0 scipy-core-0.8.6.1671 benchmark size = 10 (vectors of length 1048576) label scipy.base numarray Numeric 1 0.02554 0.01738 0.05895 2 0.04277 0.04239 0.04094 3 0.03304 0.02614 0.02599 4 0.1083 0.1622 0.1374 5 0.03525 0.03637 0.03725 6 0.02828 0.02795 0.02666 7 0.1027 0.1638 0.1325 8 0.07478 0.06667 0.07561 9 1.121 0.8961 1.004 10 1.059 0.9931 0.8719 11 0.768 0.7031 0.8103 TOTAL 3.399 3.135 3.221 -- *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*- Rob Managan email managan at llnl.gov LLNL phone: 925-423-0903 P.O. Box 808, L-095 FAX: 925-422-3389 Livermore, CA 94551-0808 From dd55 at cornell.edu Thu Dec 15 13:55:49 2005 From: dd55 at cornell.edu (Darren Dale) Date: Thu, 15 Dec 2005 13:55:49 -0500 Subject: [SciPy-user] Bug in FFTPACK wrappers In-Reply-To: References: Message-ID: <200512151355.49298.dd55@cornell.edu> On Thursday 15 December 2005 13:04, Rob Managan wrote: > I am still getting errors on mac OSX 10.3.9, python 2.4.1 in the > ifft(fft(sin(x))) when the fftpack routine is used. The routines in > the basic package work properly. Does anyone have them working > properly? > > Any pointers on how to find out where the problem is? I think fftpack > is using fftw-3.x libraries. Can you try to make scipy use fftw-2.x? Try commenting out the fftw3 dictionary in scipy/distutils/system_info.py's fftw_info class (around line 503). Darren From oliphant.travis at ieee.org Thu Dec 15 16:41:09 2005 From: oliphant.travis at ieee.org (Travis Oliphant) Date: Thu, 15 Dec 2005 14:41:09 -0700 Subject: [SciPy-user] what's wrong with radom.multivariate_normal In-Reply-To: <1134662387.43a192f3d7d5b@imp1-g19.free.fr> References: <1134656612.43a17c644dc80@imp1-g19.free.fr> <43A18348.7030004@iname.com> <1134662387.43a192f3d7d5b@imp1-g19.free.fr> Message-ID: <43A1E2F5.5030004@ieee.org> jaonary at free.fr wrote: >Here I get : > > > >>>>from scipy import * >>>>import scipy.base >>>>scipy.base.__version__ >>>> >>>> >'0.8.4' > > >>>>data1 = scipy.random.multivariate_normal([0,0],[[0.5,0],[0,0.5]],[10]) >>>> >>>> > >Traceback (most recent call last): > File "", line 1, in -toplevel- > data1 = scipy.random.multivariate_normal([0,0],[[0.5,0],[0,0.5]],[10]) > File "mtrand.pyx", line 837, in mtrand.RandomState.multivariate_normal >AttributeError: 'module' object has no attribute 'singular_value_decomposition' > > What do you get when you type import scipy scipy.linalg scipy.linalg.singular_value_decomposition -Travis From robert.kern at gmail.com Thu Dec 15 16:57:41 2005 From: robert.kern at gmail.com (Robert Kern) Date: Thu, 15 Dec 2005 13:57:41 -0800 Subject: [SciPy-user] what's wrong with radom.multivariate_normal In-Reply-To: <43A18348.7030004@iname.com> References: <1134656612.43a17c644dc80@imp1-g19.free.fr> <43A18348.7030004@iname.com> Message-ID: <43A1E6D5.3040707@gmail.com> Gary wrote: > Alan G Isaac wrote: > > >>On Thu, 15 Dec 2005, jaonary at free.fr apparently wrote: >> >> >> >>>data1 = random.multivariate_normal([0,0],[[0.5,0],[0,0.5]],[10]) >>>Traceback (most recent call last): >>> File "", line 1, in -toplevel- >>> data1 = random.multivariate_normal([0,0],[[0.5,0],[0,0.5]],[10]) >>> File "mtrand.pyx", line 837, in mtrand.RandomState.multivariate_normal >>>AttributeError: 'module' object has no attribute 'singular_value_decomposition' >>> >>> >> >>>>>scipy.base.__version__ >>>>> >>>>> >> >>'0.8.4' >> >>>>>data1 = scipy.random.multivariate_normal([0,0],[[0.5,0],[0,0.5]],[10]) >>>>>data1 >>>>> >>>>> >> >>array([[ 0.24173896, 0.68537262], >> [-0.75999958, 0.26496178], >> [ 0.15525849, -0.61052565], >> [-0.94612055, -0.98556872], >> [-0.34111442, 0.86108778], >> [ 1.09459551, 0.56298158], >> [ 0.12430803, -0.42073144], >> [-0.30572437, -0.6358559 ], >> [-0.52274094, 0.00495374], >> [-1.34852903, -0.96152263]]) >> >>fwiw, >>Alan Isaac > > yet [WinXP, python2.3] > > In [4]: scipy.random.multivariate_normal([0,0], [[0.5,0], [0,0.5]],[10]) > --------------------------------------------------------------------------- > exceptions.AttributeError Traceback (most > recent call > last) > > C:\Documents and Settings\Gary\My Documents\ > > C:\Documents and Settings\Gary\My Documents\mtrand.pyx in > mtrand.RandomState.mul > tivariate_normal() > > AttributeError: 'module' object has no attribute > 'singular_value_decomposition' > > In [5]: scipy.base.__version__ > Out[5]: '0.8.6.1666' You and Jaonary have full scipy installed, so scipy.linalg.singular_value_decomposition isn't aliased to scipy.linalg.svd as it is in scipy_core. Alan only has scipy_core installed, I'm betting. Or at least only the scipy_core version of scipy.linalg is being picked up in his case. This gives me cause to raise this issue again: Let's stop trying to be clever about these imports. The linalg and fftpack packages in scipy_core are different from the linalg and fftpack packages in full scipy. I would greatly prefer that they be imported differently. If one only needs the linear algebra routines provided by scipy_core then one would import from scipy.basic.linalg (I still prefer the names scipy.corelinalg and scipy.corefft, but I can live with the basic package, too). Most people only need the routines in scipy.basic.linalg; I went through the full scipy package, and it appeared that no other package used anything from scipy.linalg that wasn't in scipy.basic.linalg. As a bonus, we solve the fragility of importing scipy.linalg and scipy.fftpack caused by our aliasing of the packages in scipy/__init__.py . Importing packages should never be fragile. Users shouldn't have to import packages in a special way just to get it to work. -- Robert Kern robert.kern at gmail.com "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter From oliphant at ee.byu.edu Thu Dec 15 17:17:57 2005 From: oliphant at ee.byu.edu (Travis Oliphant) Date: Thu, 15 Dec 2005 15:17:57 -0700 Subject: [SciPy-user] what's wrong with radom.multivariate_normal In-Reply-To: <43A1E6D5.3040707@gmail.com> References: <1134656612.43a17c644dc80@imp1-g19.free.fr> <43A18348.7030004@iname.com> <43A1E6D5.3040707@gmail.com> Message-ID: <43A1EB95.7090107@ee.byu.edu> Robert Kern wrote: >This gives me cause to raise this issue again: Let's stop trying to be clever >about these imports. The linalg and fftpack packages in scipy_core are different >from the linalg and fftpack packages in full scipy. I would greatly prefer that >they be imported differently. If one only needs the linear algebra routines >provided by scipy_core then one would import from scipy.basic.linalg (I still >prefer the names scipy.corelinalg and scipy.corefft, but I can live with the >basic package, too). Most people only need the routines in scipy.basic.linalg; I >went through the full scipy package, and it appeared that no other package used >anything from scipy.linalg that wasn't in scipy.basic.linalg. > >As a bonus, we solve the fragility of importing scipy.linalg and scipy.fftpack >caused by our aliasing of the packages in scipy/__init__.py . Importing packages >should never be fragile. Users shouldn't have to import packages in a special >way just to get it to work. > > > Robert, Can you make these changes? Pick the names you want... I think the little experiment is bust and we should do as you say. -Travis From robert.kern at gmail.com Thu Dec 15 17:24:22 2005 From: robert.kern at gmail.com (Robert Kern) Date: Thu, 15 Dec 2005 14:24:22 -0800 Subject: [SciPy-user] what's wrong with radom.multivariate_normal In-Reply-To: <43A1EB95.7090107@ee.byu.edu> References: <1134656612.43a17c644dc80@imp1-g19.free.fr> <43A18348.7030004@iname.com> <43A1E6D5.3040707@gmail.com> <43A1EB95.7090107@ee.byu.edu> Message-ID: <43A1ED16.7010403@gmail.com> Travis Oliphant wrote: > Can you make these changes? Pick the names you want... I think the > little experiment is bust and we should do as you say. Yes, I can do this tonight. -- Robert Kern robert.kern at gmail.com "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter From gruben at bigpond.net.au Thu Dec 15 18:44:57 2005 From: gruben at bigpond.net.au (Gary Ruben) Date: Fri, 16 Dec 2005 10:44:57 +1100 Subject: [SciPy-user] New named fields in scipy core --- possible uses in color images In-Reply-To: <43A13001.8090808@ieee.org> References: <439CD911.9000407@astraw.com> <43A13001.8090808@ieee.org> Message-ID: <43A1FFF9.4070105@bigpond.net.au> I think this named record feature will be quite popular. I was expecting that fields would be accessed using a syntax like image.r image.g etc. However, using strings as Travis has done suggests other possibilities for accessing slices such as image['rgb'] or image['r','g','b'] and perhaps image['g','b','r']. Just putting this out to see if it's a good idea, Gary Ruben Travis E. Oliphant wrote: > I know that many people are not aware of the new named fields that are > now an integral part of scipy_core. So, here is a simple example of > their use. > > First of all, named fields can be constructed from any data type, not > just records. The only thing the recarray subclass does is to make > construction a bit cleaner, perhaps, and to allow attribute access to > fields. > > Consider the following code (works with recent SVN): > > image = zeros((256,256),dtype=(uint32, > [('r','u1'),('g','u1'),('b','u1'),('a','u1')])) > > This creates an array of zeros (which for math operations can be > interpreted as an unsigned 32-bit integer) but which has named fields > 'r', 'g', 'b', and 'a'. > > These fields can be accessed (as unsigned 8-bit integers) using > > image['r'] > image['g'] > image['b'] > image['a'] > > or the whole image can be accessed at one time using the image array. > > I'm not sure, aside from perhaps code readibility, if there is any > benefit from this approach over the standard representation as > > image = zeros((256,256,4), dtype=uint8) > > but, it's kind of interesting that such things are now possible. > > Note, however, that one thing the records.py module provides over this > simple approach is an "array-scalar" that also can have fields. > > In our example: > > image['r'][10,20] would work and return a uint8 scalar, but > image[10,20]['r'] would not because image[10,20] is a uint32 scalar (no > fields). > > image[10,20].getfield(*image.dtypedescr.fields['r']) would work though. > > Have fun... > > -Travis > > > > _______________________________________________ > SciPy-user mailing list > SciPy-user at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-user > From oliphant at ee.byu.edu Thu Dec 15 19:03:38 2005 From: oliphant at ee.byu.edu (Travis Oliphant) Date: Thu, 15 Dec 2005 17:03:38 -0700 Subject: [SciPy-user] New named fields in scipy core --- possible uses in color images In-Reply-To: <43A1FFF9.4070105@bigpond.net.au> References: <439CD911.9000407@astraw.com> <43A13001.8090808@ieee.org> <43A1FFF9.4070105@bigpond.net.au> Message-ID: <43A2045A.3020402@ee.byu.edu> Gary Ruben wrote: >I think this named record feature will be quite popular. I was expecting >that fields would be accessed using a syntax like image.r image.g etc. >However, using strings as Travis has done suggests other possibilities >for accessing slices such as image['rgb'] or image['r','g','b'] and >perhaps image['g','b','r']. Just putting this out to see if it's a good >idea, > > The recarray subclass implements attribute access so that you could access the fields as image.r image.g image.b and so forth. But, such records are always subclasses of the void data-type. Thus, you couldn't do math with them as a whole (you can do math with the fields though). -Travis From dalembertian at yahoo.com Thu Dec 15 21:40:42 2005 From: dalembertian at yahoo.com (Frank) Date: Thu, 15 Dec 2005 20:40:42 -0600 Subject: [SciPy-user] Failed Build from SVN Message-ID: Hi All, After a successful (?) core installation, I get the following (see below for full log) during the scipy build: "AttributeError: Configuration instance has no attribute 'make_config_py" Any ideas? Thanks, Frank Assuming default configuration (Lib/utils/{setup_utils,setup}.py was not found) Appending scipy.utils configuration to scipy Appending scipy.io configuration to scipy fftw_info: FOUND: libraries = ['rfftw', 'fftw'] library_dirs = ['/usr/local/lib'] define_macros = [('SCIPY_FFTW_H', None)] include_dirs = ['/usr/local/include'] djbfft_info: NOT AVAILABLE DJBFFT (http://cr.yp.to/djbfft.html) libraries not found. Directories to search for the libraries can be specified in the scipy_distutils/site.cfg file (section [djbfft]) or by setting the DJBFFT environment variable. Appending scipy.fftpack configuration to scipy Appending scipy.signal configuration to scipy blas_opt_info: FOUND: extra_link_args = ['-Wl,-framework', '-Wl,Accelerate'] define_macros = [('NO_ATLAS_INFO', 3)] extra_compile_args = ['-faltivec', '-I/System/Library/Frameworks/ vecLib.framework/Headers'] Appending scipy.integrate configuration to scipy lapack_opt_info: FOUND: extra_link_args = ['-Wl,-framework', '-Wl,Accelerate'] define_macros = [('NO_ATLAS_INFO', 3)] extra_compile_args = ['-faltivec'] Appending scipy.linalg configuration to scipy Appending scipy.special configuration to scipy Appending scipy.optimize configuration to scipy Appending scipy.stats configuration to scipy Appending scipy.interpolate configuration to scipy Appending scipy.sparse configuration to scipy Appending scipy.cluster configuration to scipy Appending scipy.lib.blas configuration to scipy.lib Appending scipy.lib.lapack configuration to scipy.lib Appending scipy.lib configuration to scipy Traceback (most recent call last): File "setup.py", line 42, in ? setup_package() File "setup.py", line 28, in setup_package config.add_subpackage('Lib') File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/site-packages/scipy/distutils/misc_util.py", line 395, in add_subpackage config = self.get_subpackage(subpackage_name,subpackage_path) File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/site-packages/scipy/distutils/misc_util.py", line 385, in get_subpackage config = setup_module.configuration(*args) File "/Users/fjbrooks/installme/scipy/Lib/setup.py", line 20, in configuration config.make_config_py('__scipy_config__') AttributeError: Configuration instance has no attribute 'make_config_py' From robert.kern at gmail.com Thu Dec 15 21:54:17 2005 From: robert.kern at gmail.com (Robert Kern) Date: Thu, 15 Dec 2005 18:54:17 -0800 Subject: [SciPy-user] Failed Build from SVN In-Reply-To: References: Message-ID: <43A22C59.1060301@gmail.com> Frank wrote: > Traceback (most recent call last): > File "setup.py", line 42, in ? > setup_package() > File "setup.py", line 28, in setup_package > config.add_subpackage('Lib') > File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ > python2.3/site-packages/scipy/distutils/misc_util.py", line 395, in > add_subpackage > config = self.get_subpackage(subpackage_name,subpackage_path) > File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ > python2.3/site-packages/scipy/distutils/misc_util.py", line 385, in > get_subpackage > config = setup_module.configuration(*args) > File "/Users/fjbrooks/installme/scipy/Lib/setup.py", line 20, in > configuration > config.make_config_py('__scipy_config__') > AttributeError: Configuration instance has no attribute 'make_config_py' Delete the version of scipy in /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/ -- Robert Kern robert.kern at gmail.com "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter From aisaac at american.edu Thu Dec 15 21:59:25 2005 From: aisaac at american.edu (Alan G Isaac) Date: Thu, 15 Dec 2005 21:59:25 -0500 Subject: [SciPy-user] unexpected matrix behavior Message-ID: I would like to understand the behavior of matrices, as shown below. Is it expected? If so, what is the general principle? Thank you, Alan Isaac >>> scipy.base.__version__ '0.8.4' >>> x = [[1,2],[3,4]] >>> y = scipy.array(x) >>> z = scipy.mat(x) >>> xz = zip(*x) >>> yz = zip(*y) >>> zz = zip(*z) >>> xz [(1, 3), (2, 4)] >>> yz [(1, 3), (2, 4)] >>> zz [(matrix([[1, 2]]), matrix([[3, 4]]))] From aisaac at american.edu Thu Dec 15 21:59:41 2005 From: aisaac at american.edu (Alan G Isaac) Date: Thu, 15 Dec 2005 21:59:41 -0500 Subject: [SciPy-user] what's wrong with radom.multivariate_normal In-Reply-To: <43A1E6D5.3040707@gmail.com> References: <1134656612.43a17c644dc80@imp1-g19.free.fr><43A18348.7030004@iname.com><43A1E6D5.3040707@gmail.com> Message-ID: On Thu, 15 Dec 2005, Robert Kern apparently wrote: > Alan only has scipy_core installed, I'm betting. You won that bet. Cheers, Alan From oliphant.travis at ieee.org Thu Dec 15 23:13:13 2005 From: oliphant.travis at ieee.org (Travis Oliphant) Date: Thu, 15 Dec 2005 21:13:13 -0700 Subject: [SciPy-user] unexpected matrix behavior In-Reply-To: References: Message-ID: <43A23ED9.2050601@ieee.org> Alan G Isaac wrote: >I would like to understand the behavior of matrices, >as shown below. Is it expected? If so, what is the >general principle? > > > Yes this is expected... >>>>x = [[1,2],[3,4]] >>>>y = scipy.array(x) >>>>z = scipy.mat(x) >>>>xz = zip(*x) >>>>yz = zip(*y) >>>>zz = zip(*z) >>>>xz >>>> >>>> >[(1, 3), (2, 4)] > > >>>>yz >>>> >>>> >[(1, 3), (2, 4)] > > >>>>zz >>>> >>>> >[(matrix([[1, 2]]), matrix([[3, 4]]))] > > > The general principle is that matrices are *always* two-dimensional and when you slice a matrix you get a matrix. Thus, the essential difference is that z[0] is another two-dimensional object while y[0] and x[0] are both one-dimensional objects. Compare: len(z[0]) with len(x[0]) and len(y[0]) to see what's really going on. An array view of the same data is always available as z.A So, zip(*z.A) gives [(1, 3), (2, 4)] -Travis > >_______________________________________________ >SciPy-user mailing list >SciPy-user at scipy.net >http://www.scipy.net/mailman/listinfo/scipy-user > > From dalembertian at yahoo.com Thu Dec 15 23:38:53 2005 From: dalembertian at yahoo.com (Frank) Date: Thu, 15 Dec 2005 22:38:53 -0600 Subject: [SciPy-user] Failed Build from SVN In-Reply-To: <43A22C59.1060301@gmail.com> References: <43A22C59.1060301@gmail.com> Message-ID: Thanks, Robert. Although I was able to build and install the SVN version of scipy by following your suggestion, I am still unable to get to most of the subpackages (such as interpolate) to import. Any ideas why only some are not imported while others are? Thanks, Frank Python 2.3.5 (#1, Mar 20 2005, 20:38:20) [GCC 3.3 20030304 (Apple Computer, Inc. build 1809)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import scipy >>> scipy.test() Found 4 tests for scipy.base.records Found 2 tests for scipy.base.umath Found 25 tests for scipy.base.function_base Found 3 tests for scipy.base.getlimits Found 9 tests for scipy.base.twodim_base Found 17 tests for scipy.base.ma Found 6 tests for scipy.base.matrix Found 44 tests for scipy.base.shape_base Found 4 tests for scipy.base.index_tricks Found 42 tests for scipy.base.type_check Found 3 tests for scipy.basic.helper Found 0 tests for __main__ ........................................................................ ........................................................................ ................. ---------------------------------------------------------------------- Ran 161 tests in 1.222s OK >>> ^D host >> cd .. host >> cd .. host >> python Python 2.3.5 (#1, Mar 20 2005, 20:38:20) [GCC 3.3 20030304 (Apple Computer, Inc. build 1809)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> from scipy import * >>> linalg >>> integrate Traceback (most recent call last): File "", line 1, in ? NameError: name 'integrate' is not defined >>> interpolate.linear_1d(x,y) Traceback (most recent call last): File "", line 1, in ? NameError: name 'interpolate' is not defined >>> From robert.kern at gmail.com Fri Dec 16 00:00:06 2005 From: robert.kern at gmail.com (Robert Kern) Date: Thu, 15 Dec 2005 21:00:06 -0800 Subject: [SciPy-user] Failed Build from SVN In-Reply-To: References: <43A22C59.1060301@gmail.com> Message-ID: <43A249D6.9050507@gmail.com> Frank wrote: > Thanks, Robert. Although I was able to build and install the SVN > version of scipy by following your suggestion, I am still unable to > get to most of the subpackages (such as interpolate) to import. > > Any ideas why only some are not imported while others are? We haven't fully implemented the postponed import framework that used to be in the old scipy. Try importing those subpackages directly ("from scipy import interpolate"). Personally, I'm -1 on adding the postponed imports. With a few exceptions, messing with the import machinery tends to cause headaches more than it cures them, in my experience. -- Robert Kern robert.kern at gmail.com "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter From dalembertian at yahoo.com Fri Dec 16 00:12:29 2005 From: dalembertian at yahoo.com (Frank) Date: Thu, 15 Dec 2005 23:12:29 -0600 Subject: [SciPy-user] Failed Build from SVN In-Reply-To: <43A249D6.9050507@gmail.com> References: <43A22C59.1060301@gmail.com> <43A249D6.9050507@gmail.com> Message-ID: Thanks for the suggestion but I cannot import directly either. It must be something I'm doing (or haven't done) as I have this problem on several machines. Thanks again, Frank Python 2.3.5 (#1, Mar 20 2005, 20:38:20) [GCC 3.3 20030304 (Apple Computer, Inc. build 1809)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> from scipy import interpolate Traceback (most recent call last): File "", line 1, in ? ImportError: cannot import name interpolate >>> From robert.kern at gmail.com Fri Dec 16 00:21:28 2005 From: robert.kern at gmail.com (Robert Kern) Date: Thu, 15 Dec 2005 21:21:28 -0800 Subject: [SciPy-user] Failed Build from SVN In-Reply-To: References: <43A22C59.1060301@gmail.com> <43A249D6.9050507@gmail.com> Message-ID: <43A24ED8.60105@gmail.com> Frank wrote: > Thanks for the suggestion but I cannot import directly either. It > must be something I'm doing (or haven't done) as I have this problem > on several machines. Okay, you successfully built and installed (by which I mean that the files actually got put into the right place; I know it's not working, yet) full scipy after you installed scipy_core, right? What does $ ls /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/scipy/ give you? -- Robert Kern robert.kern at gmail.com "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter From dalembertian at yahoo.com Fri Dec 16 00:38:05 2005 From: dalembertian at yahoo.com (Frank) Date: Thu, 15 Dec 2005 23:38:05 -0600 Subject: [SciPy-user] Failed Build from SVN In-Reply-To: <43A24ED8.60105@gmail.com> References: <43A22C59.1060301@gmail.com> <43A249D6.9050507@gmail.com> <43A24ED8.60105@gmail.com> Message-ID: <0478D261-B267-4115-AA78-C92AFA6B75AF@yahoo.com> Robert, I built and installed the scipy_core from SVN. Then build and installed scipy from SVN. The build log seemed to indicated that files from subpackages were being copied. I've been following the instructions at Chris Fonnesbeck's website: http://www.scipy.org/documentation/Members/fonnesbeck/osx_build.txt Thanks, Frank As per your question: host >> ls /System/Library/Frameworks/Python.framework/Versions/2.3/ lib/python2.3/site-packages/scipy/ __core_config__.py _import_tools.py core_version.py f2py test __core_config__.pyc _import_tools.pyc core_version.pyc lib weave __init__.py base distutils setup.py __init__.pyc basic doc setup.pyc From robert.kern at gmail.com Fri Dec 16 01:02:53 2005 From: robert.kern at gmail.com (Robert Kern) Date: Thu, 15 Dec 2005 22:02:53 -0800 Subject: [SciPy-user] Failed Build from SVN In-Reply-To: <0478D261-B267-4115-AA78-C92AFA6B75AF@yahoo.com> References: <43A22C59.1060301@gmail.com> <43A249D6.9050507@gmail.com> <43A24ED8.60105@gmail.com> <0478D261-B267-4115-AA78-C92AFA6B75AF@yahoo.com> Message-ID: <43A2588D.5000201@gmail.com> Frank wrote: > Robert, > > I built and installed the scipy_core from SVN. Then build and > installed scipy from SVN. The build log seemed to indicated that > files from subpackages were being copied. I've been following the > instructions at Chris Fonnesbeck's website: > > http://www.scipy.org/documentation/Members/fonnesbeck/osx_build.txt > > Thanks, > Frank > > As per your question: > > host >> ls /System/Library/Frameworks/Python.framework/Versions/2.3/ > lib/python2.3/site-packages/scipy/ > > __core_config__.py _import_tools.py > core_version.py f2py test > __core_config__.pyc _import_tools.pyc > core_version.pyc lib weave > __init__.py base > distutils setup.py > __init__.pyc basic > doc setup.pyc Well, it looks like they weren't actually copied. I don't know why. Try again and see if it works. If it doesn't work, post a bit of the build log where it is actually copying things. -- Robert Kern robert.kern at gmail.com "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter From pearu at scipy.org Fri Dec 16 01:30:42 2005 From: pearu at scipy.org (Pearu Peterson) Date: Fri, 16 Dec 2005 00:30:42 -0600 (CST) Subject: [SciPy-user] what's wrong with radom.multivariate_normal In-Reply-To: <43A1ED16.7010403@gmail.com> References: <1134656612.43a17c644dc80@imp1-g19.free.fr> <43A18348.7030004@iname.com><43A1ED16.7010403@gmail.com> Message-ID: On Thu, 15 Dec 2005, Robert Kern wrote: > Travis Oliphant wrote: > >> Can you make these changes? Pick the names you want... I think the >> little experiment is bust and we should do as you say. > > Yes, I can do this tonight. I suggest then moving some of scipy.corelib packages under scipy.basic as well. Currently linalg related codes, for instance, are dispersed in too many places: scipy.lib.lapack_lite, scipy.basic.linalg, scipy.basic.basic_lite + full scipy packages scipy.lib.lapack, scipy.linalg. I would move scipy.lib.lapack_lite under scipy.basic and joining scipy.basic.linalg and scipy.basic.basic_lite to scipy.basic.linalg. I suggest also renaming scipy/corelib to scipy/lib. I can do some of the code clean up today as well. Pearu From aisaac at american.edu Fri Dec 16 02:54:59 2005 From: aisaac at american.edu (Alan G Isaac) Date: Fri, 16 Dec 2005 02:54:59 -0500 Subject: [SciPy-user] unexpected matrix behavior In-Reply-To: <43A23ED9.2050601@ieee.org> References: <43A23ED9.2050601@ieee.org> Message-ID: On Thu, 15 Dec 2005, Travis Oliphant apparently wrote: > when you slice a matrix you get a matrix. > Thus, the essential difference is that > z[0] is another two-dimensional object Aha! I suggest adding this as another example in section 7.3, second item: 2. Matrix objects are always two-dimensional. This has far-reaching implications, in that m.ravel() is still two-dimensional (with a 1 in the first dimension), and item selection returns two-dimensional arrays. Yes I see now that the explanation is there ... Thanks! Alan From robert.kern at gmail.com Fri Dec 16 05:34:05 2005 From: robert.kern at gmail.com (Robert Kern) Date: Fri, 16 Dec 2005 02:34:05 -0800 Subject: [SciPy-user] what's wrong with radom.multivariate_normal In-Reply-To: References: <1134656612.43a17c644dc80@imp1-g19.free.fr> <43A18348.7030004@iname.com><43A1ED16.7010403@gmail.com> Message-ID: <43A2981D.4030406@gmail.com> Pearu Peterson wrote: > > On Thu, 15 Dec 2005, Robert Kern wrote: > >>Travis Oliphant wrote: >> >>>Can you make these changes? Pick the names you want... I think the >>>little experiment is bust and we should do as you say. >> >>Yes, I can do this tonight. I've just commited my changes to scipy_core. Now, I must be missing something, because scipy.linalg still exists and is the same module as scipy.basic.linalg, not scipy.linalg from full scipy no matter how I try to import things. I'm using a regular install; not eggs. I've also moved random.py out into main core/scipy/ directory under the reasoning that we shouldn't get name conflicts with anything in full scipy. I think that anything we'd want to add to full scipy wrt random numbers should either get its own module (e.g. scipy.mcmc, scipy.aesprng) or will fit comfortably in scipy.stats. Also, since we no longer want to automatically import things exposed in scipy.basic.__init__, can we make it an empty __init__.py? That way we don't waste time and memory importing the fft modules when we only need linear algebra. > I suggest then moving some of scipy.corelib packages under scipy.basic as > well. Currently linalg related codes, for instance, are dispersed in too > many places: scipy.lib.lapack_lite, scipy.basic.linalg, > scipy.basic.basic_lite + full scipy packages scipy.lib.lapack, > scipy.linalg. I would move scipy.lib.lapack_lite under scipy.basic and > joining scipy.basic.linalg and scipy.basic.basic_lite to > scipy.basic.linalg. > > I suggest also renaming scipy/corelib to scipy/lib. > > I can do some of the code clean up today as well. Can you do what you suggested? I'm pretty sure I'll muck it up somehow. -- Robert Kern robert.kern at gmail.com "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter From oliphant.travis at ieee.org Fri Dec 16 06:50:49 2005 From: oliphant.travis at ieee.org (Travis Oliphant) Date: Fri, 16 Dec 2005 04:50:49 -0700 Subject: [SciPy-user] what's wrong with radom.multivariate_normal In-Reply-To: <43A2981D.4030406@gmail.com> References: <1134656612.43a17c644dc80@imp1-g19.free.fr> <43A18348.7030004@iname.com><43A1ED16.7010403@gmail.com> <43A2981D.4030406@gmail.com> Message-ID: <43A2AA19.4000405@ieee.org> >I've also moved random.py out into main core/scipy/ directory under the >reasoning that we shouldn't get name conflicts with anything in full scipy. I >think that anything we'd want to add to full scipy wrt random numbers should >either get its own module (e.g. scipy.mcmc, scipy.aesprng) or will fit >comfortably in scipy.stats. > > I think one of the reasons to place random.py under basic is to allow it to export global symbols (rand and randn) to the scipy namespace using the general approach of documenting such actions in the info.py file. For that matter, I don't see the global names fft, ifft, rand, and randn in the scipy name-space anymore. Was that intentional? -Travis From pearu at scipy.org Fri Dec 16 06:08:43 2005 From: pearu at scipy.org (Pearu Peterson) Date: Fri, 16 Dec 2005 05:08:43 -0600 (CST) Subject: [SciPy-user] what's wrong with radom.multivariate_normal In-Reply-To: <43A2AA19.4000405@ieee.org> References: <1134656612.43a17c644dc80@imp1-g19.free.fr> <43A18348.7030004@iname.com><43A1ED16.7010403@gmail.com> <43A2981D.4030406@gmail.com> <43A2AA19.4000405@ieee.org> Message-ID: On Fri, 16 Dec 2005, Travis Oliphant wrote: >> I've also moved random.py out into main core/scipy/ directory under the >> reasoning that we shouldn't get name conflicts with anything in full scipy. I >> think that anything we'd want to add to full scipy wrt random numbers should >> either get its own module (e.g. scipy.mcmc, scipy.aesprng) or will fit >> comfortably in scipy.stats. >> >> > I think one of the reasons to place random.py under basic is to allow it > to export global symbols (rand and randn) to the scipy namespace using > the general approach of documenting such actions in the info.py file. PackageImport should be extended to import modules similar to the general approach of importing packages. I'll look into it.. > For that matter, I don't see the global names fft, ifft, rand, and randn > in the scipy name-space anymore. Was that intentional? I think not, I see where is the bug but I cannot commit the fix at the moment because I am in the middle of changes. Pearu From pearu at scipy.org Fri Dec 16 07:35:58 2005 From: pearu at scipy.org (Pearu Peterson) Date: Fri, 16 Dec 2005 06:35:58 -0600 (CST) Subject: [SciPy-user] what's wrong with radom.multivariate_normal In-Reply-To: <43A2981D.4030406@gmail.com> References: <1134656612.43a17c644dc80@imp1-g19.free.fr> <43A18348.7030004@iname.com><43A1ED16.7010403@gmail.com> <43A2981D.4030406@gmail.com> Message-ID: On Fri, 16 Dec 2005, Robert Kern wrote: > I've just commited my changes to scipy_core. Now, I must be missing something, > because scipy.linalg still exists and is the same module as scipy.basic.linalg, > not scipy.linalg from full scipy no matter how I try to import things. I'm using > a regular install; not eggs. scipy.basic.linalg is exposed as scipy.linalg via scipy/basic/info.py. When full scipy is installed, scipy.linalg is reset to scipy.linalg (from full scipy): In [1]: import scipy Skip importing scipy packages (NO_SCIPY_IMPORT=1) In [2]: scipy.linalg Out[2]: and In [1]: import scipy In [2]: scipy.linalg Out[2]: after installing full scipy. So, I would expect that you don't have full scipy installed.. >> I suggest then moving some of scipy.corelib packages under scipy.basic as >> well. Currently linalg related codes, for instance, are dispersed in too >> many places: scipy.lib.lapack_lite, scipy.basic.linalg, >> scipy.basic.basic_lite + full scipy packages scipy.lib.lapack, >> scipy.linalg. I would move scipy.lib.lapack_lite under scipy.basic and >> joining scipy.basic.linalg and scipy.basic.basic_lite to >> scipy.basic.linalg. >> >> I suggest also renaming scipy/corelib to scipy/lib. >> >> I can do some of the code clean up today as well. > > Can you do what you suggested? I'm pretty sure I'll muck it up somehow. I have now moved lapack_lite and fftpack_lite to core/scipy/basic, created core/scipy/basic/{linalg,fftpack}.py modules and removed old files, and renamed corelib to lib. All scipy core and scipy tests pass ok here after these changes. Pearu From dalembertian at yahoo.com Fri Dec 16 09:50:25 2005 From: dalembertian at yahoo.com (Frank) Date: Fri, 16 Dec 2005 08:50:25 -0600 Subject: [SciPy-user] Failed Build from SVN In-Reply-To: <43A2588D.5000201@gmail.com> References: <43A22C59.1060301@gmail.com> <43A249D6.9050507@gmail.com> <43A24ED8.60105@gmail.com> <0478D261-B267-4115-AA78-C92AFA6B75AF@yahoo.com> <43A2588D.5000201@gmail.com> Message-ID: <0D43BBE9-6871-4694-9888-61E6746FE456@yahoo.com> Robert, Here are the relevant snippets from the scipy build log. I can zip and attach the entire log of both the scipy_core and scipy builds (~36 KB) if you think it would help. Thanks, so much. I am really keen on getting that interpolate package working. Frank Appending scipy.interpolate configuration to scipy ... building extension "scipy.interpolate._fitpack" sources building extension "scipy.interpolate.dfitpack" sources creating build/src/Lib/interpolate f2py options: [] f2py: Lib/interpolate/fitpack.pyf Reading fortran codes... Reading file 'Lib/interpolate/fitpack.pyf' (format:free) ... creating build/lib.darwin-8.3.0-Power_Macintosh-2.3/scipy/interpolate copying Lib/interpolate/__init__.py -> build/lib.darwin-8.3.0- Power_Macintosh-2.3/scipy/interpolate copying Lib/interpolate/common_routines.py -> build/lib.darwin-8.3.0- Power_Macintosh-2.3/scipy/interpolate copying Lib/interpolate/fitpack.py -> build/lib.darwin-8.3.0- Power_Macintosh-2.3/scipy/interpolate copying Lib/interpolate/fitpack2.py -> build/lib.darwin-8.3.0- Power_Macintosh-2.3/scipy/interpolate copying Lib/interpolate/info.py -> build/lib.darwin-8.3.0- Power_Macintosh-2.3/scipy/interpolate copying Lib/interpolate/interpolate.py -> build/lib.darwin-8.3.0- Power_Macintosh-2.3/scipy/interpolate copying Lib/interpolate/setup.py -> build/lib.darwin-8.3.0- Power_Macintosh-2.3/scipy/interpolate ... creating build/temp.darwin-8.3.0-Power_Macintosh-2.3/Lib/interpolate creating build/temp.darwin-8.3.0-Power_Macintosh-2.3/Lib/interpolate/ fitpack compile options: '-c' g77:f77: Lib/interpolate/fitpack/bispev.f g77:f77: Lib/interpolate/fitpack/clocur.f g77:f77: Lib/interpolate/fitpack/cocosp.f g77:f77: Lib/interpolate/fitpack/concon.f g77:f77: Lib/interpolate/fitpack/concur.f Lib/interpolate/fitpack/concur.f: In subroutine `concur': In file included from Lib/interpolate/fitpack/concur.f:0: Lib/interpolate/fitpack/concur.f:287: warning: unused variable 'dist' g77:f77: Lib/interpolate/fitpack/cualde.f (LOTS MORE HERE) g77:f77: Lib/interpolate/fitpack/surfit.f ar: adding 50 object files to build/temp.darwin-8.3.0- Power_Macintosh-2.3/libfitpack.a ar: adding 33 object files to build/temp.darwin-8.3.0- Power_Macintosh-2.3/libfitpack.a ranlib:@ build/temp.darwin-8.3.0-Power_Macintosh-2.3/libfitpack.a From aisaac at american.edu Fri Dec 16 10:40:55 2005 From: aisaac at american.edu (Alan G Isaac) Date: Fri, 16 Dec 2005 10:40:55 -0500 Subject: [SciPy-user] sequence emulation -/-> array access? Message-ID: Is a special array interface necessary for scipy.array to access even simple sequence emulators? E.g., suppose I have >>> class simple: ... def __init__(self,data): ... self.data = data ... where it is enforced that data is a list, and to class this I add sequence emulation http://docs.python.org/ref/sequence-types.html Can someone please point me to a *minimal* example where I can then do x = simple([1,2,3]) y = scipy.array(x) and end up with an array of the list values (just like when you do scipy.array([1,2,3])). Thank you, Alan Isaac From dkuhlman at cutter.rexx.com Fri Dec 16 12:45:20 2005 From: dkuhlman at cutter.rexx.com (Dave Kuhlman) Date: Fri, 16 Dec 2005 09:45:20 -0800 Subject: [SciPy-user] sequence emulation -/-> array access? In-Reply-To: References: Message-ID: <20051216174520.GA49361@cutter.rexx.com> On Fri, Dec 16, 2005 at 10:40:55AM -0500, Alan G Isaac wrote: > Is a special array interface necessary for scipy.array > to access even simple sequence emulators? > > E.g., suppose I have > > >>> class simple: > ... def __init__(self,data): > ... self.data = data > ... > where it is enforced that data is a list, > and to class this I add sequence emulation > http://docs.python.org/ref/sequence-types.html > > Can someone please point me to a *minimal* example > where I can then do > x = simple([1,2,3]) > y = scipy.array(x) > and end up with an array of the list values > (just like when you do scipy.array([1,2,3])). > Perhaps you want something like this: class Simple: def __init__(self, data=None): if data == None: self.data = [] elif type(data) != type([]): raise TypeError('data must be list') else: self.data = data def get_data(self): return self.data # # This should work OK. # def test1(): x = Simple([1., 2., 3.,]) y = scipy.array(x.get_data()) print y # # This should fail. # def test2(): x = Simple(1.0) y = scipy.array(x.get_data()) print y test1() test2() A few notes: 1. Note that the initializer for data is ``data=None`` and then we check for a None value and create an empty list rather than using an initializer like ``data=[]``. If we were to use the second (``data=[]``), then our instances would share a single list, which we do not want. It's a somewhat tricky Python gotcha. 2. Using properties or new style classes or something, there is a way to implement class Simple so that you can write ``x.data`` to get the value instead of ``x.get_data()``. But, you asked for simple, so that extension "is left as an excercise for the reader". 3. About emulating a list. To do that, just inherit from ``list``. For example: class Simple(list): pass But, that made the solution *too* simple, and no fun at all. Hope this helps. Dave -- Dave Kuhlman http://www.rexx.com/~dkuhlman From michael.blazej at gmail.com Fri Dec 16 15:54:26 2005 From: michael.blazej at gmail.com (Michael Blazej) Date: Fri, 16 Dec 2005 15:54:26 -0500 Subject: [SciPy-user] question about scipy.polynomial.poly1d Message-ID: <1e59dec00512161254j55dd03f6k6b238c3bc1edcfec@mail.gmail.com> Mike here, this is my first time writing something, usually I'm just reading it but by question was. Is there a way to get different variables into poly1d such as 'y' or 'lamda'. Thank you all, this is a great way for new people to learn about scipy and python. -------------- next part -------------- An HTML attachment was scrubbed... URL: From aisaac at american.edu Fri Dec 16 16:24:37 2005 From: aisaac at american.edu (Alan G Isaac) Date: Fri, 16 Dec 2005 16:24:37 -0500 Subject: [SciPy-user] question about scipy.polynomial.poly1d In-Reply-To: <1e59dec00512161254j55dd03f6k6b238c3bc1edcfec@mail.gmail.com> References: <1e59dec00512161254j55dd03f6k6b238c3bc1edcfec@mail.gmail.com> Message-ID: On Fri, 16 Dec 2005, Michael Blazej apparently wrote: > Is there a way to get different variables into poly1d such > as 'y' or 'lamda'. I think I don't understand your question. I assume you are not just asking whether one can do this: >>> y=(3,1,2) >>> p=scipy.poly1d(y) >>> p poly1d([3, 1, 2]) I strongly recommend the SciPy book: http://www.scipy.org/documentation/ hth, Alan Isaac From michael.blazej at gmail.com Fri Dec 16 16:28:04 2005 From: michael.blazej at gmail.com (Michael Blazej) Date: Fri, 16 Dec 2005 16:28:04 -0500 Subject: [SciPy-user] question about scipy.polynomial.poly1d In-Reply-To: References: <1e59dec00512161254j55dd03f6k6b238c3bc1edcfec@mail.gmail.com> Message-ID: <1e59dec00512161328m60b95166o7331f97bcb13caf5@mail.gmail.com> No, sorry, that is not what I'm asking. Okay instead of the output of print poly1d([1,2,3]) x^2+2x+3 is there a way to change the variable to something arbitrary like y^2+2y+3 On 12/16/05, Alan G Isaac wrote: > > On Fri, 16 Dec 2005, Michael Blazej apparently wrote: > > Is there a way to get different variables into poly1d such > > as 'y' or 'lamda'. > > I think I don't understand your question. > I assume you are not just asking whether one can do this: > > >>> y=(3,1,2) > >>> p=scipy.poly1d(y) > >>> p > poly1d([3, 1, 2]) > > I strongly recommend the SciPy book: > http://www.scipy.org/documentation/ > > hth, > Alan Isaac > > > > > _______________________________________________ > SciPy-user mailing list > SciPy-user at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aisaac at american.edu Fri Dec 16 16:42:16 2005 From: aisaac at american.edu (Alan G Isaac) Date: Fri, 16 Dec 2005 16:42:16 -0500 Subject: [SciPy-user] question about scipy.polynomial.poly1d In-Reply-To: <1e59dec00512161328m60b95166o7331f97bcb13caf5@mail.gmail.com> References: <1e59dec00512161254j55dd03f6k6b238c3bc1edcfec@mail.gmail.com><1e59dec00512161328m60b95166o7331f97bcb13caf5@mail.gmail.com> Message-ID: On Fri, 16 Dec 2005, Michael Blazej apparently wrote: > Okay instead of the output of print poly1d([1,2,3]) > x^2+2x+3 > is there a way to change the variable to something arbitrary like > y^2+2y+3 Oh, you mean in the string representation. Presumably you could override, but may it's good enough to: >>> print str(p).replace('x','y') 2 3 y + 1 y + 2 hth, Alan Isaac From oliphant.travis at ieee.org Fri Dec 16 16:39:13 2005 From: oliphant.travis at ieee.org (Travis Oliphant) Date: Fri, 16 Dec 2005 14:39:13 -0700 Subject: [SciPy-user] question about scipy.polynomial.poly1d In-Reply-To: References: <1e59dec00512161254j55dd03f6k6b238c3bc1edcfec@mail.gmail.com> Message-ID: <43A33401.2000605@ieee.org> Alan G Isaac wrote: >On Fri, 16 Dec 2005, Michael Blazej apparently wrote: > > >>Is there a way to get different variables into poly1d such >>as 'y' or 'lamda'. >> >> > > > I think he may mean in printing. In other-words can you get it to print with a different variable. Right now, no. But, it wouldn't be that hard to change (at least for single-character replacements). From aisaac at american.edu Sat Dec 17 15:47:36 2005 From: aisaac at american.edu (Alan G Isaac) Date: Sat, 17 Dec 2005 15:47:36 -0500 Subject: [SciPy-user] sequence emulation -/-> array access? In-Reply-To: <20051216174520.GA49361@cutter.rexx.com> References: <20051216174520.GA49361@cutter.rexx.com> Message-ID: > On Fri, Dec 16, 2005 at 10:40:55AM -0500, Alan G Isaac wrote: >> Is a special array interface necessary for scipy.array >> to access even simple sequence emulators? >> E.g., suppose I have >> >>> class simple: >> ... def __init__(self,data): >> ... self.data = data >> ... >> where it is enforced that data is a list, >> and to class this I add sequence emulation >> http://docs.python.org/ref/sequence-types.html >> Can someone please point me to a minimal example where >> I can then do >> x = simple([1,2,3]) >> y = scipy.array(x) >> and end up with an array of the list values >> (just like when you do scipy.array([1,2,3])). On Fri, 16 Dec 2005, Dave Kuhlman apparently wrote: > # This should work OK. # def test1(): x = Simple([1., > 2., 3.,]) y = scipy.array(x.get_data()) print y Sure. But I want to be able to do x = simple([1,2,3]) y = scipy.array(x) One reason: I don't want to test for what kind of object I am passing to scipy.array, whether it has the get_data attribute, etc. So my question is: what is a minimal set of attributes to allow this to work. I have found that sequence emulation (see: http://docs.python.org/ref/sequence-types.html ) is not enough. Cheers, Alan Isaac From jdc at uwo.ca Sat Dec 17 18:18:46 2005 From: jdc at uwo.ca (Dan Christensen) Date: Sat, 17 Dec 2005 18:18:46 -0500 Subject: [SciPy-user] sequence emulation -/-> array access? In-Reply-To: References: <20051216174520.GA49361@cutter.rexx.com> Message-ID: <87bqzfnwh5.fsf@uwo.ca> Alan G Isaac writes: > I want to be able to do > x = simple([1,2,3]) > y = scipy.array(x) > One reason: I don't want to test for what > kind of object I am passing to scipy.array, > whether it has the get_data attribute, etc. > > So my question is: > what is a minimal set of attributes to allow > this to work. I have found that sequence emulation (see: > http://docs.python.org/ref/sequence-types.html ) > is not enough. I don't know the answer to your question, but I have a related question. I've read that subclasses Numeric and numarray is non-trivial. Is this any easier with scipy core? In more detail, I'd like to override + and * on arrays, but allow them to be used in other ways as standard arrays, e.g. innerproduct(a,b) should do the usual thing. Dan From oliphant.travis at ieee.org Sat Dec 17 19:50:04 2005 From: oliphant.travis at ieee.org (Travis Oliphant) Date: Sat, 17 Dec 2005 17:50:04 -0700 Subject: [SciPy-user] sequence emulation -/-> array access? In-Reply-To: References: Message-ID: <43A4B23C.4040502@ieee.org> Alan G Isaac wrote: >Is a special array interface necessary for scipy.array >to access even simple sequence emulators? > > > No, it shoudn't be. Internally, there is an if-else statement that checks if the object (in-order): 1. is an array (or subclass) 2. is an array-scalar 3. has the __array_struct__ interface 4. has the other __array_yyyy__ interface 5. has the __array__ method If all the above fail, then either Array_FromSequence is called or Array_FromScalar is called. To succeed in conversion your object must be able to be interpreted using the C-API PySequence_GetItem command. So, the question is: What is needed on obj for PySequence_Check(obj) and PySequence_GetItem(obj) to succeed? These are Python C-API calls. My impression has always been that classes that define at least the __len__ method and the __getitem__ method would succeed. So, try this: class myobj(object): def __init__(self, data): self.data = data def __len__(self): return len(self.data) def __getitem__(self, key): return self.data[key] This seems to work for me... a = myobj([1,2,3,4]) b = array(a) print b -Travis From oliphant.travis at ieee.org Sat Dec 17 19:58:43 2005 From: oliphant.travis at ieee.org (Travis Oliphant) Date: Sat, 17 Dec 2005 17:58:43 -0700 Subject: [SciPy-user] sequence emulation -/-> array access? In-Reply-To: <87bqzfnwh5.fsf@uwo.ca> References: <20051216174520.GA49361@cutter.rexx.com> <87bqzfnwh5.fsf@uwo.ca> Message-ID: <43A4B443.7040908@ieee.org> Dan Christensen wrote: >In more detail, I'd like to override + and * on arrays, but allow them >to be used in other ways as standard arrays, e.g. innerproduct(a,b) >should do the usual thing. > > Well, internally innerproduct does not use the generic + and * operator to do the computation unless the type of the array is *object*. So, you should be able to subclass rather easily. The only confusion, perhaps, is that the array function *is not* a __new__ method. The ndarray.__new__ method has arguments that are slightly different. There are basically two ways to create an array (as an empty array or from a buffer). The docstring of ndarray has more information in newer versions: help(ndarray). Also, look at matrix.py, chararray.py, records.py, and memmap.py for examples of how to subclass. Basically, you need to define the __new__ method (the only thing that's necessary, no __init__ is needed). Then define __mul__ and __add__ the way you want. from scipy import ndarray class mysub(ndarray): def __new__(self, *args): pass #you need to call ndarray.__new__ in here with one of two sets of arguments def __mul__(self, other): # do what you want def __add__(self, other): # do what you want. If you want to define an __array_finalize__ method it will be called every time a new object of your class is created so you can keep meta information consistent. This is what the matrix class does to enforce a 2-dimensional array all the time. -Travis From aisaac at american.edu Sat Dec 17 20:49:18 2005 From: aisaac at american.edu (Alan G Isaac) Date: Sat, 17 Dec 2005 20:49:18 -0500 Subject: [SciPy-user] sequence emulation -/-> array access? In-Reply-To: <43A4B23C.4040502@ieee.org> References: <43A4B23C.4040502@ieee.org> Message-ID: On Sat, 17 Dec 2005, Travis Oliphant apparently wrote: > class myobj(object): Argh! So the only issue was that it needs to be a "New Class" instead of a "Classic Class"! Thanks!! Alan PS Illustrative details: ################ script ####################### import scipy as S class new(object): def __init__(self, data): self.data = data def __len__(self): return len(self.data) def __getitem__(self, key): return self.data[key] class old: def __init__(self, data): self.data = data def __len__(self): return len(self.data) def __getitem__(self, key): return self.data[key] a1 = new([1,2,3,4]) a2 = old([1,2,3,4]) b1 = S.array(a1) print b1[0], "new class works fine" b2 = S.array(a2) print "but old class does not", b2[0] ################ output ####################### 1 new class works fine but old class does not Traceback (most recent call last): File "", line 1, in ? File "c:/temp5.py", line 24, in ? print "but old class does not", b2[0] ValueError: 0-d arrays can't be indexed. From jdc at uwo.ca Sat Dec 17 22:14:20 2005 From: jdc at uwo.ca (Dan Christensen) Date: Sat, 17 Dec 2005 22:14:20 -0500 Subject: [SciPy-user] sequence emulation -/-> array access? In-Reply-To: <43A4B443.7040908@ieee.org> References: <20051216174520.GA49361@cutter.rexx.com><87bqzfnwh5.fsf@uwo.ca> <43A4B443.7040908@ieee.org> Message-ID: <877ja3nlkj.fsf@uwo.ca> Travis Oliphant writes: > So, you should be able to subclass rather easily. Great, glad to hear it! > The only confusion, > perhaps, is that the array function *is not* a __new__ method. The > ndarray.__new__ method has arguments that are slightly different. There > are basically two ways to create an array (as an empty array or from a > buffer). The docstring of ndarray has more information in newer > versions: help(ndarray). Also, look at matrix.py, chararray.py, > records.py, and memmap.py for examples of how to subclass. > > Basically, you need to define the __new__ method (the only thing that's > necessary, no __init__ is needed). Then define __mul__ and __add__ the > way you want. > > from scipy import ndarray > > class mysub(ndarray): > def __new__(self, *args): > pass > #you need to call ndarray.__new__ in here with one of two sets > of arguments I guess what you are saying is that it's not generally useful to create an array directly with arr = ndarray(...params...) and so if I subclass without overriding the __new__ method, I won't be able to conveniently create objects of my new class with myob = mysub(...param...) I'm a bit confused by why ndarray is designed in a way that makes this necessary, but I should be able to imitate what is done in matrix.py, etc, to do what I want. I haven't yet installed scipy core but will hopefully find time to play with it soon. Thanks so much for the detailed help! Dan From dalembertian at yahoo.com Sat Dec 17 22:23:56 2005 From: dalembertian at yahoo.com (Frank) Date: Sat, 17 Dec 2005 21:23:56 -0600 Subject: [SciPy-user] Failed build (AGAIN) Message-ID: <8D420925-A26B-4E77-AC13-67ACD58A48ED@yahoo.com> Dear All, What am I doing wrong? Although I have never gotten an explicit build error, I have never been able to import the interpolate of integrate subpackages. After numerous failed attempts, I tried to build from scratch. I deleted the directory: /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/site-packages/scipy and then followed the instructions for building from SVN at Chris Fonnesbeck's "Building SciPy for Mac OS X" webpage to the letter. I still cannot import most subpackages such as integrate while others such as linalg and fft import just fine. Incidentally, I also do no have access to "top-level" functions such as derivative or factorial. I have attached a complete build log of the entire process. I would be very grateful for any help you could provide. Thank you so much, Frank -------------- next part -------------- A non-text attachment was scrubbed... Name: build_log.txt.zip Type: application/zip Size: 47399 bytes Desc: not available URL: -------------- next part -------------- From robert.kern at gmail.com Sat Dec 17 22:51:35 2005 From: robert.kern at gmail.com (Robert Kern) Date: Sat, 17 Dec 2005 19:51:35 -0800 Subject: [SciPy-user] Failed build (AGAIN) In-Reply-To: <8D420925-A26B-4E77-AC13-67ACD58A48ED@yahoo.com> References: <8D420925-A26B-4E77-AC13-67ACD58A48ED@yahoo.com> Message-ID: <43A4DCC7.1060905@gmail.com> Frank wrote: > Dear All, > > What am I doing wrong? Although I have never gotten an explicit build > error, I have never been able to import the interpolate of integrate > subpackages. After numerous failed attempts, I tried to build from > scratch. I deleted the directory: > > /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ > python2.3/site-packages/scipy > > and then followed the instructions for building from SVN at Chris > Fonnesbeck's "Building SciPy for Mac OS X" webpage to the letter. I > still cannot import most subpackages such as integrate while others > such as linalg and fft import just fine. Incidentally, I also do no > have access to "top-level" functions such as derivative or factorial. > > I have attached a complete build log of the entire process. I would be > very grateful for any help you could provide. You have to run $ python setup.py install after you run $ python setup.py build -- Robert Kern robert.kern at gmail.com "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter From dalembertian at yahoo.com Sat Dec 17 23:18:01 2005 From: dalembertian at yahoo.com (Frank) Date: Sat, 17 Dec 2005 22:18:01 -0600 Subject: [SciPy-user] Failed build (AGAIN) In-Reply-To: <43A4DCC7.1060905@gmail.com> References: <8D420925-A26B-4E77-AC13-67ACD58A48ED@yahoo.com> <43A4DCC7.1060905@gmail.com> Message-ID: Sorry, I must have left that out of this log but I certainly did run the install. From dalembertian at yahoo.com Sat Dec 17 23:26:28 2005 From: dalembertian at yahoo.com (Frank) Date: Sat, 17 Dec 2005 22:26:28 -0600 Subject: [SciPy-user] Failed build (AGAIN) In-Reply-To: <43A4DCC7.1060905@gmail.com> References: <8D420925-A26B-4E77-AC13-67ACD58A48ED@yahoo.com> <43A4DCC7.1060905@gmail.com> Message-ID: Oh my goodness, I have found the problem and it is so stupid I cannot even believe it. I am so sorry for badgering folks on the list. You all have been very patient and helpful. Thank you so much, Frank From robert.kern at gmail.com Sat Dec 17 23:28:49 2005 From: robert.kern at gmail.com (Robert Kern) Date: Sat, 17 Dec 2005 20:28:49 -0800 Subject: [SciPy-user] Failed build (AGAIN) In-Reply-To: References: <8D420925-A26B-4E77-AC13-67ACD58A48ED@yahoo.com> <43A4DCC7.1060905@gmail.com> Message-ID: <43A4E581.30200@gmail.com> Frank wrote: > Sorry, I must have left that out of this log but I certainly did run > the install. Okay, can you give us the output of $ python setup.py install ? -- Robert Kern robert.kern at gmail.com "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter From oliphant.travis at ieee.org Sun Dec 18 00:52:31 2005 From: oliphant.travis at ieee.org (Travis Oliphant) Date: Sat, 17 Dec 2005 22:52:31 -0700 Subject: [SciPy-user] sequence emulation -/-> array access? In-Reply-To: <877ja3nlkj.fsf@uwo.ca> References: <20051216174520.GA49361@cutter.rexx.com><87bqzfnwh5.fsf@uwo.ca> <43A4B443.7040908@ieee.org> <877ja3nlkj.fsf@uwo.ca> Message-ID: <43A4F91F.2080009@ieee.org> >>The only confusion, >>perhaps, is that the array function *is not* a __new__ method. The >>ndarray.__new__ method has arguments that are slightly different. There >>are basically two ways to create an array (as an empty array or from a >>buffer). The docstring of ndarray has more information in newer >>versions: help(ndarray). Also, look at matrix.py, chararray.py, >>records.py, and memmap.py for examples of how to subclass. >> >>Basically, you need to define the __new__ method (the only thing that's >>necessary, no __init__ is needed). Then define __mul__ and __add__ the >>way you want. >> >>from scipy import ndarray >> >>class mysub(ndarray): >> def __new__(self, *args): >> pass >> #you need to call ndarray.__new__ in here with one of two sets >>of arguments >> >> > >I guess what you are saying is that it's not generally useful to >create an array directly with > > arr = ndarray(...params...) > >and so if I subclass without overriding the __new__ method, I won't >be able to conveniently create objects of my new class with > > myob = mysub(...param...) > >I'm a bit confused by why ndarray is designed in a way that makes this >necessary, but I should be able to imitate what is done in matrix.py, >etc, to do what I want. I haven't yet installed scipy core but will >hopefully find time to play with it soon. > > > Well, no, you could actually not override the new method and just use the same creation function for your subclass. It's just that the most common array creation function "array"0 is *not* the new method. I suppose this is historical more than anything. Perhaps we should rethink the new method of the ndarray so that in fact ndarray(someobject) has the same behavior as array(someobject) I'm certainly not opposed to that and have been considering it. Sooner is better than latter, of course. Ideas welcome. -Travis From oliphant.travis at ieee.org Sun Dec 18 01:22:58 2005 From: oliphant.travis at ieee.org (Travis Oliphant) Date: Sat, 17 Dec 2005 23:22:58 -0700 Subject: [SciPy-user] sequence emulation -/-> array access? In-Reply-To: References: <43A4B23C.4040502@ieee.org> Message-ID: <43A50042.8040707@ieee.org> Alan G Isaac wrote: >On Sat, 17 Dec 2005, Travis Oliphant apparently wrote: > > >>class myobj(object): >> >> > >Argh! >So the only issue was that it needs to be a "New Class" >instead of a "Classic Class"! > >Thanks!! >Alan > >PS Illustrative details: > >################ script ####################### >import scipy as S > >class new(object): > def __init__(self, data): > self.data = data > def __len__(self): > return len(self.data) > def __getitem__(self, key): > return self.data[key] > >class old: > def __init__(self, data): > self.data = data > def __len__(self): > return len(self.data) > def __getitem__(self, key): > return self.data[key] > >a1 = new([1,2,3,4]) >a2 = old([1,2,3,4]) >b1 = S.array(a1) >print b1[0], "new class works fine" >b2 = S.array(a2) >print "but old class does not", b2[0] > > > Interesting. I suspect this is because the old-style classes don't fill in the sequence-protocol function pointers when the class get's created but new-style classes do. PySequence_Check and PySequence_GetItem are used to understand the object (which uses the sequence protocol), and so apparantely these aren't filled in for old-style classes (thus it gets interpreted as a single object and an object-array returned). -Travis From jaonary at free.fr Sun Dec 18 06:56:31 2005 From: jaonary at free.fr (Jaonary Rabarisoa) Date: Sun, 18 Dec 2005 12:56:31 +0100 Subject: [SciPy-user] what's wrong with radom.multivariate_normal In-Reply-To: References: <1134656612.43a17c644dc80@imp1-g19.free.fr> <43A18348.7030004@iname.com><43A1ED16.7010403@gmail.com> <43A2981D.4030406@gmail.com> Message-ID: <63C977C1-303C-456F-A1E4-5354EF765CF3@free.fr> I've built the latest svn on a mac os 10.4.2, with python 2.4.2 and FFTW installed with fink. It worked perfectly with gcc 3.3, broke with gcc 4.0.1. The problem with the random.mutlivariate_normal seems to be solved : import scipy a = scipy.random.multivariate_normal([0,0],[[1,0],[0,1]],[10]) print a [[ 1.16298025 -0.44751277] [ 0.40711338 1.15414107] [ 0.0787966 -1.30920437] [-1.3057994 0.43813078] [ 0.56662083 -0.55948958] [-0.23552752 -0.07318171] [-0.39799132 0.74541927] [ 0.73509922 -0.11506159] [-1.02453562 -0.47928837] [-1.26826607 -0.36258142]] Good work :-) I've also run the scipy.test() after the build process. It's seems that there's a lot of faillures. I don't really understand the meaning of the out put but you can find some part of it below. Regards, Jaonary ====================================================================== FAIL: check_definition (scipy.fftpack.pseudo_diffs.test_pseudo_diffs.test_diff) ---------------------------------------------------------------------- Traceback (most recent call last): File "/sw/lib/python2.4/site-packages/scipy/fftpack/tests/ test_pseudo_diffs.py", line 89, in check_definition assert_array_almost_equal(diff(sin(x),2),direct_diff(sin(x),2)) File "/sw/lib/python2.4/site-packages/scipy/test/testing.py", line 763, in assert_array_almost_equal assert cond,\ AssertionError: Arrays are not almost equal (mismatch 87.5%): Array 1: [ -6.0617241e-15 -3.8268343e-01 -7.0710678e-01 -9.2387953e-01 -1.0000000e+00 -9.2387953e-01 -7.0710678e-01 -3.82... Array 2: [ -7.4128027e-15 6.4859714e-15 -1.8855373e-15 -1.1136318e-15 1.4745663e-15 -8.7537278e-16 -3.8067825e-16 1.27... ====================================================================== FAIL: check_random_even (scipy.fftpack.pseudo_diffs.test_pseudo_diffs.test_hilbert) ---------------------------------------------------------------------- Traceback (most recent call last): File "/sw/lib/python2.4/site-packages/scipy/fftpack/tests/ test_pseudo_diffs.py", line 335, in check_random_even assert_array_almost_equal(direct_hilbert(direct_ihilbert(f)),f) File "/sw/lib/python2.4/site-packages/scipy/test/testing.py", line 763, in assert_array_almost_equal assert cond,\ AssertionError: Arrays are not almost equal (mismatch 100.0%): Array 1: [ 7.8062556e-18+0.j 0.0000000e+00-0.j 6.7426270e-18-0.j 0.0000000e+00-0.j 4.2932216e-18-0.j 0.0000000e+00-0.... Array 2: [ 0.1637757 0.1730892 -0.5327494 -0.3623476 -0.1693549 -0.2254976 0.3936585 0.5272722 0.1489982 0.3217353 0.26324... ====================================================================== FAIL: check_definition (scipy.fftpack.pseudo_diffs.test_pseudo_diffs.test_shift) ---------------------------------------------------------------------- Traceback (most recent call last): File "/sw/lib/python2.4/site-packages/scipy/fftpack/tests/ test_pseudo_diffs.py", line 393, in check_definition assert_array_almost_equal(shift(sin(x),a),direct_shift(sin(x),a)) File "/sw/lib/python2.4/site-packages/scipy/test/testing.py", line 763, in assert_array_almost_equal assert cond,\ AssertionError: Arrays are not almost equal (mismatch 88.8888888889%): Array 1: [ 0.0998334 0.4341242 0.7160532 0.9116156 0.9972237 0.9625519 0.8117822 0.5630995 0.2464987 -0.0998334 -0.43412... Array 2: [ 0.0998334 0.0938127 0.0764768 0.0499167 0.0173359 -0.0173359 -0.0499167 -0.0764768 -0.0938127 -0.0998334 -0.09381... ====================================================================== FAIL: check_random_even (scipy.fftpack.pseudo_diffs.test_pseudo_diffs.test_tilbert) ---------------------------------------------------------------------- Traceback (most recent call last): File "/sw/lib/python2.4/site-packages/scipy/fftpack/tests/ test_pseudo_diffs.py", line 243, in check_random_even assert_array_almost_equal(direct_tilbert(direct_itilbert(f,h),h),f) File "/sw/lib/python2.4/site-packages/scipy/test/testing.py", line 763, in assert_array_almost_equal assert cond,\ AssertionError: Arrays are not almost equal (mismatch 100.0%): Array 1: [ -5.3741597e-18+0.j -3.1548626e-18-0.j -3.8001048e-18-0.j -1.3067869e-18-0.j 0.0000000e+00-0.j 1.3067869e-18-0.... Array 2: [-0.3992172 0.096423 -0.1631964 -0.3055548 0.2795349 -0.0209729 -0.3378428 -0.04089 -0.146339 -0.1760787 0.02989... ====================================================================== FAIL: check_definition (scipy.fftpack.basic.test_basic.test_fft) ---------------------------------------------------------------------- Traceback (most recent call last): File "/sw/lib/python2.4/site-packages/scipy/fftpack/tests/ test_basic.py", line 102, in check_definition assert_array_almost_equal(y,y1) File "/sw/lib/python2.4/site-packages/scipy/test/testing.py", line 763, in assert_array_almost_equal assert cond,\ AssertionError: Arrays are not almost equal (mismatch 100.0%): Array 1: [ 20.+0.j 0.+0.j -4.+4.j 0.+0.j -4.+0.j 0.-0.j -4.-4.j 0.-0.j] Array 2: [ 20. +3.j -0.7071068+0.7071068j -7. +4.j -0.7071068-0.7071068j -4. -3.j 0.707106... ====================================================================== FAIL: check_definition (scipy.fftpack.basic.test_basic.test_fftn) ---------------------------------------------------------------------- Traceback (most recent call last): File "/sw/lib/python2.4/site-packages/scipy/fftpack/tests/ test_basic.py", line 429, in check_definition assert_array_almost_equal(y,direct_dftn(x)) File "/sw/lib/python2.4/site-packages/scipy/test/testing.py", line 763, in assert_array_almost_equal assert cond,\ AssertionError: Arrays are not almost equal (mismatch 22.2222222222%): Array 1: [[ 45. +0.j -4.5+2.5980762j -4.5-2.5980762j] [-13.5+7.7942286j 0. +0.j 0. +0.j ] [-13.5-7.79... Array 2: [[ 45. +0.j -4.5+2.5980762j -4.5-2.5980762j] [-13.5+0.j -0. +0.j -0. -0.j ] [-13.5+0.j ... ====================================================================== FAIL: check_definition (scipy.fftpack.basic.test_basic.test_ifft) ---------------------------------------------------------------------- Traceback (most recent call last): File "/sw/lib/python2.4/site-packages/scipy/fftpack/tests/ test_basic.py", line 187, in check_definition assert_array_almost_equal(y,y1) File "/sw/lib/python2.4/site-packages/scipy/test/testing.py", line 763, in assert_array_almost_equal assert cond,\ AssertionError: Arrays are not almost equal (mismatch 100.0%): Array 1: [ 2.5+0.j 0. -0.j -0.5-0.5j 0. -0.j -0.5+0.j 0. +0.j -0.5+0.5j 0. +0.j ] Array 2: [ 2.5 +0.375j 0.0883883+0.0883883j -0.125 -0.5j 0.0883883-0.0883883j -0.5 -0.375j -0.0883883-0.0... ====================================================================== FAIL: check_random_real (scipy.fftpack.basic.test_basic.test_ifft) ---------------------------------------------------------------------- Traceback (most recent call last): File "/sw/lib/python2.4/site-packages/scipy/fftpack/tests/ test_basic.py", line 221, in check_random_real assert_array_almost_equal (ifft(fft(x)),x) File "/sw/lib/python2.4/site-packages/scipy/test/testing.py", line 763, in assert_array_almost_equal assert cond,\ AssertionError: Arrays are not almost equal (mismatch 98.0392156863%): Array 1: [ 0.795423 +0.0000000e+00j 0.1689491 -0.0000000e+00j 0.4194747 +4.1361250e-17j 0.8712436 -1.7415263e-17j 0.788789... Array 2: [ 0.795423 0.0771056 0.6592195 0.9114743 0.7102914 0.5489242 0.0900781 0.7954824 0.1029265 0.6601038 0.54681... ====================================================================== FAIL: check_definition (scipy.fftpack.basic.test_basic.test_ifftn) ---------------------------------------------------------------------- Traceback (most recent call last): File "/sw/lib/python2.4/site-packages/scipy/fftpack/tests/ test_basic.py", line 598, in check_definition assert_array_almost_equal(y,direct_idftn(x)) File "/sw/lib/python2.4/site-packages/scipy/test/testing.py", line 763, in assert_array_almost_equal assert cond,\ AssertionError: Arrays are not almost equal (mismatch 22.2222222222%): Array 1: [[ 5. +0.j -0.5-0.2886751j -0.5+0.2886751j] [-1.5-0.8660254j 0. +0.j 0. +0.j ] [-1.5+0.8660254j ... Array 2: [[ 5. +0.j -0.5-0.2886751j -0.5+0.2886751j] [-1.5+0.j -0. -0.j -0. +0.j ] [-1.5+0.j ... ====================================================================== FAIL: check_definition (scipy.fftpack.basic.test_basic.test_irfft) ---------------------------------------------------------------------- Traceback (most recent call last): File "/sw/lib/python2.4/site-packages/scipy/fftpack/tests/ test_basic.py", line 345, in check_definition assert_array_almost_equal(y,ifft(x1)) File "/sw/lib/python2.4/site-packages/scipy/test/testing.py", line 763, in assert_array_almost_equal assert cond,\ AssertionError: Arrays are not almost equal (mismatch 50.0%): Array 1: [ 2.625 -1.6856602 -0.375 -1.1856602 0.625 0.4356602 -0.375 0.9356602] Array 2: [ 2.625+0.j -0.375-0.j -0.375-0.j -0.375-0.j 0.625 +0.j -0.375+0.j -0.375+0.j -0.375+0.j] ====================================================================== FAIL: check_round (scipy.special.basic.test_basic.test_round) ---------------------------------------------------------------------- Traceback (most recent call last): File "/sw/lib/python2.4/site-packages/scipy/special/tests/ test_basic.py", line 1793, in check_round assert_array_equal(rnd,rndrl) File "/sw/lib/python2.4/site-packages/scipy/test/testing.py", line 738, in assert_array_equal assert cond,\ AssertionError: Arrays are not equal (mismatch 25.0%): Array 1: [10 10 10 11] Array 2: [10 10 11 11] ---------------------------------------------------------------------- Ran 1230 tests in 7.401s FAILED (failures=11) From schofield at ftw.at Sun Dec 18 07:29:30 2005 From: schofield at ftw.at (Ed Schofield) Date: Sun, 18 Dec 2005 12:29:30 +0000 Subject: [SciPy-user] Failed build (AGAIN) In-Reply-To: References: <8D420925-A26B-4E77-AC13-67ACD58A48ED@yahoo.com> <43A4DCC7.1060905@gmail.com> Message-ID: On 18/12/2005, at 4:26 AM, Frank wrote: > Oh my goodness, I have found the problem and it is so stupid I cannot > even believe it. I am so sorry for badgering folks on the list. > > You all have been very patient and helpful. > > Thank you so much, > Hi Frank. I'm glad you solved the problem. Would you mind telling us what you were missing? It's clearly not an easy process, and, even if we can't find a way to make it easier, perhaps we can start compiling an installation FAQ that answers questions like "Why am I getting this?" with "Check you did that". The good folks at Argonne have something like this for PETSc and TAO (which are even scarier to install). -- Ed From hgamboa at gmail.com Mon Dec 19 04:53:18 2005 From: hgamboa at gmail.com (Hugo Gamboa) Date: Mon, 19 Dec 2005 09:53:18 +0000 Subject: [SciPy-user] What is fastest load/save matrix methods? In-Reply-To: <43A0A31A.1000607@ieee.org> References: <43A0A31A.1000607@ieee.org> Message-ID: <43A6830E.6040704@gmail.com> Hi there, I need to work with large matrixes that come in ascii format. I have the functions to build the matrix from the ascii file but it takes too long. I can spend some time convert ingthis ascii files to some other format so that the re-readeing be fastened. What is the fastest (binary) format readly available in scipy to load/save matrixes? Thanks in advance for your attention. Hugo Gamboa From arnd.baecker at web.de Mon Dec 19 05:01:37 2005 From: arnd.baecker at web.de (Arnd Baecker) Date: Mon, 19 Dec 2005 11:01:37 +0100 (CET) Subject: [SciPy-user] What is fastest load/save matrix methods? In-Reply-To: <43A6830E.6040704@gmail.com> References: <43A0A31A.1000607@ieee.org> <43A6830E.6040704@gmail.com> Message-ID: On Mon, 19 Dec 2005, Hugo Gamboa wrote: > Hi there, > > I need to work with large matrixes that come in ascii format. > > I have the functions to build the matrix from the ascii file but it > takes too long. > I can spend some time convert ingthis ascii files to some other format > so that the re-readeing be fastened. > > What is the fastest (binary) format readly available in scipy to > load/save matrixes? I am not sure if it is *the* fastest way, but have you had a look at scipy.io? In particular scipy.io.fwrite and scipy.io.fread: In [1]:import scipy In [2]:scipy.io.fwrite? Type: builtin_function_or_method Base Class: String Form: Namespace: Interactive Docstring: numpyio.fwrite( fid, Num, myarray { write_type, byteswap} ) fid = open file stream Num = number of elements to write myarray = NumPy array holding the data to write (will be written as if ravel(myarray) was passed) OPTIONAL write_type = character ('cb1silfdFD') describing how to write the data (what datatype to use) Default = type of myarray. byteswap = 0 or 1 to determine if byteswapping occurs on write. Default = 0. In [3]:scipy.io.fread? Type: builtin_function_or_method Base Class: String Form: Namespace: Interactive Docstring: g = numpyio.fread( fid, Num, read_type { mem_type, byteswap}) fid = open file pointer object (i.e. from fid = open('filename') ) Num = number of elements to read of type read_type read_type = a character in 'cb1silfdFD' (PyArray types) describing how to interpret bytes on disk. OPTIONAL mem_type = a character (PyArray type) describing what kind of PyArray to return in g. Default = read_type byteswap = 0 for no byteswapping or a 1 to byteswap (to handle different endianness). Default = 0. HTH, Arnd From evan.monroig at gmail.com Mon Dec 19 07:43:23 2005 From: evan.monroig at gmail.com (Evan Monroig) Date: Mon, 19 Dec 2005 21:43:23 +0900 Subject: [SciPy-user] (almost all) lapack functions were already under 'scipy.linalg.flapack' Message-ID: Hi, I am not sure if here is the right place, but here is a piece of experience that others might find useful. I started to port my simulation framework from gnu octave to python/scipy, because I thought performance would be greatly improved, without too much coding effort (I already know python). For this I needed to factorize a reasonably big (1800 * 200) matrix using the QR decomposition. So I tried the function 'scipy.linalg.qr', and found that it took *minutes* to compute it where octave could do that within a few seconds. So I looked on the internet, on the scipy website, google, etc. for one or two hours looking for a way to get the LAPACK qr-factorization routine to work with scipy. Then by chance I found that it was already there, under 'scipy.linalg.flapack.dgeqrf' ! So I used it and the computation is now improved over octave ^^ (I did not benchmark but I would say 4~5 times faster) cheers, Evan From managan at llnl.gov Mon Dec 19 10:56:26 2005 From: managan at llnl.gov (Rob Managan) Date: Mon, 19 Dec 2005 07:56:26 -0800 Subject: [SciPy-user] what's wrong with radom.multivariate_normal In-Reply-To: <63C977C1-303C-456F-A1E4-5354EF765CF3@free.fr> References: <1134656612.43a17c644dc80@imp1-g19.free.fr> <43A18348.7030004@iname.com><43A1ED16.7010403@gmail.com> <43A2981D.4030406@gmail.com> <63C977C1-303C-456F-A1E4-5354EF765CF3@free.fr> Message-ID: At 12:56 PM +0100 12/18/05, Jaonary Rabarisoa wrote: >I've built the latest svn on a mac os 10.4.2, with python 2.4.2 and >FFTW installed with fink. It worked perfectly with gcc 3.3, broke >with gcc 4.0.1. The problem with the random.mutlivariate_normal seems >to be solved : > I see the same failures on OSX 10.3.9 and python 2.4.2. The problem shows up in the fftpack module and not the basic.fft functions. Haven't had time to try and figure out what goes wrong in fftpack. I see the same problem with fftw-2.1.5 and fftw-3. See http://www.scipy.org/mailinglists/mailman?fn=scipy-user/2005-December/006240.html for a simple test case. -- *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*- Rob Managan email managan at llnl.gov LLNL phone: 925-423-0903 P.O. Box 808, L-095 FAX: 925-422-3389 Livermore, CA 94551-0808 From michael.blazej at gmail.com Mon Dec 19 14:43:57 2005 From: michael.blazej at gmail.com (Michael Blazej) Date: Mon, 19 Dec 2005 14:43:57 -0500 Subject: [SciPy-user] why are the eigenvalues different Message-ID: <1e59dec00512191143g4dd01551y7b703fdaa91d6055@mail.gmail.com> for the 3x3 matrix [-2,2,-3;2,1,-6;-1,-2,0] why does matlab give me -3,5,-3 and scipy give me -2,3,-7.5 -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.blazej at gmail.com Mon Dec 19 15:16:10 2005 From: michael.blazej at gmail.com (Michael Blazej) Date: Mon, 19 Dec 2005 15:16:10 -0500 Subject: [SciPy-user] why are the eigenvalues different In-Reply-To: <1e59dec00512191143g4dd01551y7b703fdaa91d6055@mail.gmail.com> References: <1e59dec00512191143g4dd01551y7b703fdaa91d6055@mail.gmail.com> Message-ID: <1e59dec00512191216h62fa21cfwadcb2e7f7d4758ba@mail.gmail.com> nevermind, I'm an idiot, sorry. On 12/19/05, Michael Blazej wrote: > > for the 3x3 matrix [-2,2,-3;2,1,-6;-1,-2,0] > why does matlab give me -3,5,-3 and scipy give me -2,3,-7.5 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.huard at gmail.com Mon Dec 19 17:21:27 2005 From: david.huard at gmail.com (David Huard) Date: Mon, 19 Dec 2005 17:21:27 -0500 Subject: [SciPy-user] Stats method in scipy.stats Message-ID: <91cf711d0512191421t63a4bd83w@mail.gmail.com> Hi, Can someone explain this ? >>> stats.gamma.stats(1) (nan, nan) >>> stats.norm.stats(loc = 0, scale =1) (nan, nan) and so on for all the distributions I've tried (although other methods such as pdf, rvs and fit work just fine. ) Thanks, David Huard Using scipy version 0.4.3.1478 and scipy core version 0.8.0.1586 -------------- next part -------------- An HTML attachment was scrubbed... URL: From cournape at atr.jp Mon Dec 19 20:49:14 2005 From: cournape at atr.jp (Cournapeau David) Date: Tue, 20 Dec 2005 10:49:14 +0900 Subject: [SciPy-user] What is fastest load/save matrix methods? In-Reply-To: References: <43A0A31A.1000607@ieee.org> <43A6830E.6040704@gmail.com> Message-ID: <1135043354.5067.7.camel@localhost.localdomain> On Mon, 2005-12-19 at 11:01 +0100, Arnd Baecker wrote: > On Mon, 19 Dec 2005, Hugo Gamboa wrote: > > > Hi there, > > > > I need to work with large matrixes that come in ascii format. > > > > I have the functions to build the matrix from the ascii file but it > > takes too long. > > I can spend some time convert ingthis ascii files to some other format > > so that the re-readeing be fastened. > > > > What is the fastest (binary) format readly available in scipy to > > load/save matrixes? > > I am not sure if it is *the* fastest way, but have you had a look > at scipy.io? Did you take a look at pytables ? It is a python library built around the hdf5 file format """ HDF5 was created to address the data management needs of scientists and engineers working in high performance, data intensive computing environments. As a result, the HDF5 library and format emphasize storage and I/O efficiency. For instance, the HDF5 format can accommodate data in a variety of ways, such as compressed or chunked. And the library is tuned and adapted to read and write data efficiently on parallel computing systems. """ pytables uses hdf5 file format as a storage model, with a high level abstraction when you want to save a lot of data in one file. http://pytables.sourceforge.net/html/WelcomePage.html The lastest version can read a lot of native hdf5 files, not just pytables files, so a file created through the hdf5 C library should be usable under python with pytables. David From dkuhlman at cutter.rexx.com Mon Dec 19 23:27:05 2005 From: dkuhlman at cutter.rexx.com (Dave Kuhlman) Date: Mon, 19 Dec 2005 20:27:05 -0800 Subject: [SciPy-user] What is fastest load/save matrix methods? In-Reply-To: <1135043354.5067.7.camel@localhost.localdomain> References: <43A0A31A.1000607@ieee.org> <43A6830E.6040704@gmail.com> <1135043354.5067.7.camel@localhost.localdomain> Message-ID: <20051220042704.GA13476@cutter.rexx.com> On Tue, Dec 20, 2005 at 10:49:14AM +0900, Cournapeau David wrote: > On Mon, 2005-12-19 at 11:01 +0100, Arnd Baecker wrote: > > On Mon, 19 Dec 2005, Hugo Gamboa wrote: > > > > > Hi there, > > > > > > I need to work with large matrixes that come in ascii format. > > > [snip] > > pytables uses hdf5 file format as a storage model, with a high level > abstraction when you want to save a lot of data in one file. > > http://pytables.sourceforge.net/html/WelcomePage.html Good suggestion. Am I right that PyTables does not *directly* support scipy arrays? That's not a big problem. You can write a scipy array to an HDF5 file using PyTables with something like the following:: filename = 'testpytables1.h5' dataset1 = [[1,2],[3,4],[5,6]] h5file = tables.openFile(filename, mode = "w", title = "PyTables test file"$ datasets = h5file.createGroup(h5file.root, "datasets", "Test data sets") array1 = scipy.array(dataset1) # Write array after converting to a numarray array. h5file.createArray(datasets, 'dataset1', numarray.array(array1.tolist()), "Test data set #1") h5file.close() And, reading it back in: h5file = tables.openFile(filename, 'r') dataset1Obj = h5file.getNode('/datasets', 'dataset1') dataset1Array = scipy.array(dataset1Obj.read()) h5file.close() Is there a more efficient way? Has anyone tried to modify PyTables so that it supports scipy arrays directly? Dave -- Dave Kuhlman http://www.rexx.com/~dkuhlman From evan.monroig at gmail.com Mon Dec 19 23:49:23 2005 From: evan.monroig at gmail.com (Evan Monroig) Date: Tue, 20 Dec 2005 13:49:23 +0900 Subject: [SciPy-user] What is fastest load/save matrix methods? In-Reply-To: <43A6830E.6040704@gmail.com> References: <43A0A31A.1000607@ieee.org> <43A6830E.6040704@gmail.com> Message-ID: On 12/19/05, Hugo Gamboa wrote: > What is the fastest (binary) format readly available in scipy to > load/save matrixes? What I do is to pickle my objects, using the module 'cPickle'. I don't know about its efficiency compared to others, but it does the work ^^. Evan From oliphant at ee.byu.edu Tue Dec 20 00:18:27 2005 From: oliphant at ee.byu.edu (Travis Oliphant) Date: Mon, 19 Dec 2005 22:18:27 -0700 Subject: [SciPy-user] What is fastest load/save matrix methods? In-Reply-To: <43A6830E.6040704@gmail.com> References: <43A0A31A.1000607@ieee.org> <43A6830E.6040704@gmail.com> Message-ID: <43A79423.9040204@ee.byu.edu> Hugo Gamboa wrote: >Hi there, > >I need to work with large matrixes that come in ascii format. > >I have the functions to build the matrix from the ascii file but it >takes too long. >I can spend some time convert ingthis ascii files to some other format >so that the re-readeing be fastened. > > Look at the tofile method of scipy arrays and the fromfile function. You can read and write simple ascii files. But, the fastest approach would be to convert to (native) binary files and then read them using fromfile. (Actually, depending on what you are doing, the fastest approach may be to use a memory-mapped array). The tofile and fromfile approaches are very raw and you must understand the data on the disk. But, because of that, they would be the fastest, I think. -Travis From cournape at atr.jp Tue Dec 20 01:04:56 2005 From: cournape at atr.jp (Cournapeau David) Date: Tue, 20 Dec 2005 15:04:56 +0900 Subject: [SciPy-user] What is fastest load/save matrix methods? In-Reply-To: <20051220042704.GA13476@cutter.rexx.com> References: <43A0A31A.1000607@ieee.org> <43A6830E.6040704@gmail.com> <1135043354.5067.7.camel@localhost.localdomain> <20051220042704.GA13476@cutter.rexx.com> Message-ID: <1135058696.5067.23.camel@localhost.localdomain> On Mon, 2005-12-19 at 20:27 -0800, Dave Kuhlman wrote: > On Tue, Dec 20, 2005 at 10:49:14AM +0900, Cournapeau David wrote: > > On Mon, 2005-12-19 at 11:01 +0100, Arnd Baecker wrote: > > > On Mon, 19 Dec 2005, Hugo Gamboa wrote: > > > > > > > Hi there, > > > > > > > > I need to work with large matrixes that come in ascii format. > > > > > > [snip] > > > > > pytables uses hdf5 file format as a storage model, with a high level > > abstraction when you want to save a lot of data in one file. > > > > http://pytables.sourceforge.net/html/WelcomePage.html > > Good suggestion. > > Am I right that PyTables does not *directly* support scipy arrays? > That's not a big problem. You can write a scipy array to an HDF5 > file using PyTables with something like the following:: > > filename = 'testpytables1.h5' > dataset1 = [[1,2],[3,4],[5,6]] > h5file = tables.openFile(filename, mode = "w", > title = "PyTables test file"$ > datasets = h5file.createGroup(h5file.root, "datasets", "Test data sets") > array1 = scipy.array(dataset1) > # Write array after converting to a numarray array. > h5file.createArray(datasets, 'dataset1', > numarray.array(array1.tolist()), > "Test data set #1") > h5file.close() > > And, reading it back in: > > h5file = tables.openFile(filename, 'r') > dataset1Obj = h5file.getNode('/datasets', 'dataset1') > dataset1Array = scipy.array(dataset1Obj.read()) > h5file.close() > > Is there a more efficient way? Is there no way to convert numarray to scipy more directly than going through list ? Concerning implementing scipy array support, what is the difference between scipy array and numarray ? David From strawman at astraw.com Tue Dec 20 01:46:20 2005 From: strawman at astraw.com (Andrew Straw) Date: Mon, 19 Dec 2005 22:46:20 -0800 Subject: [SciPy-user] What is fastest load/save matrix methods? In-Reply-To: <1135058696.5067.23.camel@localhost.localdomain> References: <43A0A31A.1000607@ieee.org> <43A6830E.6040704@gmail.com> <1135043354.5067.7.camel@localhost.localdomain> <20051220042704.GA13476@cutter.rexx.com> <1135058696.5067.23.camel@localhost.localdomain> Message-ID: <43A7A8BC.8040004@astraw.com> Cournapeau David wrote: >On Mon, 2005-12-19 at 20:27 -0800, Dave Kuhlman wrote: > > >>On Tue, Dec 20, 2005 at 10:49:14AM +0900, Cournapeau David wrote: >> >> >>>On Mon, 2005-12-19 at 11:01 +0100, Arnd Baecker wrote: >>> >>> >>>>On Mon, 19 Dec 2005, Hugo Gamboa wrote: >>>> >>>> >>>> >>>>>Hi there, >>>>> >>>>>I need to work with large matrixes that come in ascii format. >>>>> >>>>> >>>>> >>[snip] >> >> >> >>>pytables uses hdf5 file format as a storage model, with a high level >>>abstraction when you want to save a lot of data in one file. >>> >>>http://pytables.sourceforge.net/html/WelcomePage.html >>> >>> >>Good suggestion. >> >>Am I right that PyTables does not *directly* support scipy arrays? >>That's not a big problem. You can write a scipy array to an HDF5 >>file using PyTables with something like the following:: >> >> filename = 'testpytables1.h5' >> dataset1 = [[1,2],[3,4],[5,6]] >> h5file = tables.openFile(filename, mode = "w", >> title = "PyTables test file"$ >> datasets = h5file.createGroup(h5file.root, "datasets", "Test data sets") >> array1 = scipy.array(dataset1) >> # Write array after converting to a numarray array. >> h5file.createArray(datasets, 'dataset1', >> numarray.array(array1.tolist()), >> "Test data set #1") >> h5file.close() >> >>And, reading it back in: >> >> h5file = tables.openFile(filename, 'r') >> dataset1Obj = h5file.getNode('/datasets', 'dataset1') >> dataset1Array = scipy.array(dataset1Obj.read()) >> h5file.close() >> >>Is there a more efficient way? >> >> > >Is there no way to convert numarray to scipy more directly than >going through list ? Concerning implementing scipy array support, what >is the difference between scipy array and numarray ? > > With sufficiently recent versions of scipy, Numeric, and numarray, y=numstar.asarray(x) will create a view of the array with no copying, which is pretty fast. "Sufficiently recent" means released within the last 2 months or so. From felis at Safe-mail.net Tue Dec 20 07:02:36 2005 From: felis at Safe-mail.net (felis at Safe-mail.net) Date: Tue, 20 Dec 2005 07:02:36 -0500 Subject: [SciPy-user] totally bogged down install on fedora core 4 Message-ID: hi list, i have trouble getting scipy 0.32 to run on a fc4 installation, i also tried in vain an OSX installation. What ever i try satifying dependencies (python, ATLAS, lapack, djbfft etc.etc.) every avenue seems blocked. Is there a way to install scipy on fc4? I would love to use it but it's a science to get it running in the first place. Get anyone point me to some description of things to do to get it working on fc4 or OSX? I must be missing something. thanks! From schofield at ftw.at Tue Dec 20 10:06:10 2005 From: schofield at ftw.at (Ed Schofield) Date: Tue, 20 Dec 2005 15:06:10 +0000 Subject: [SciPy-user] totally bogged down install on fedora core 4 In-Reply-To: References: Message-ID: <43A81DE2.60901@ftw.at> felis at Safe-mail.net wrote: >hi list, > >i have trouble getting scipy 0.32 to run on a fc4 installation, i also tried in vain an OSX installation. What ever i try satifying dependencies (python, ATLAS, lapack, djbfft etc.etc.) every avenue seems blocked. Is there a way to install scipy on fc4? I would love to use it but it's a science to get it running in the first place. > >Get anyone point me to some description of things to do to get it working on fc4 or OSX? I must be missing something. > > Hi Felis, Our website and documentation are a real mess at the moment. First off, you probably want the newer version 0.8.4 of scipy core. It's available from the Download link at http://numeric.scipy.org/. Get the file called scipy_core-0.8.4.tar.gz, unpack it, and run "python setup.py install" (as root) from the source directory. But before doing this completely remove the existing installation, e.g. with: rm -Rf /usr/lib/python2.4/site-packages/scipy as root. Then test it out with >>> import scipy >>> scipy.test() If all's well and you want to install full scipy (with the other modules), I suggest you get it from subversion: svn co http://svn.scipy.org/svn/scipy/trunk scipy cd scipy python setup.py install If you have any problems see the last few months' posts to this mailing list. Cheers, Ed From schofield at ftw.at Tue Dec 20 10:08:39 2005 From: schofield at ftw.at (Ed Schofield) Date: Tue, 20 Dec 2005 15:08:39 +0000 Subject: [SciPy-user] totally bogged down install on fedora core 4 In-Reply-To: References: Message-ID: <43A81E77.2020603@ftw.at> felis at Safe-mail.net wrote: >hi list, > >i have trouble getting scipy 0.32 to run on a fc4 installation, i also tried in vain an OSX installation. What ever i try satifying dependencies (python, ATLAS, lapack, djbfft etc.etc.) every avenue seems blocked. Is there a way to install scipy on fc4? I would love to use it but it's a science to get it running in the first place. > >Get anyone point me to some description of things to do to get it working on fc4 or OSX? I must be missing something. > > Hi Felis, Our website and documentation are a real mess at the moment. First off, you probably want the newer version 0.8.4 of scipy core. It's available from the Download link at http://numeric.scipy.org/. Get the file called scipy_core-0.8.4.tar.gz, unpack it, and run "python setup.py install" (as root) from the source directory. But before doing this completely remove the existing installation, e.g. with: rm -Rf /usr/lib/python2.4/site-packages/scipy as root. Then test it out with >>> import scipy >>> scipy.test() If all's well and you want to install full scipy too, I suggest you get it from subversion: svn co http://svn.scipy.org/svn/scipy/trunk scipy cd scipy python setup.py install If you have any problems see the last few months' posts to this mailing list. -- Ed From falted at pytables.org Tue Dec 20 10:10:19 2005 From: falted at pytables.org (Francesc Altet) Date: Tue, 20 Dec 2005 16:10:19 +0100 Subject: [SciPy-user] What is fastest load/save matrix methods? In-Reply-To: <20051220042704.GA13476@cutter.rexx.com> References: <43A0A31A.1000607@ieee.org> <1135043354.5067.7.camel@localhost.localdomain> <20051220042704.GA13476@cutter.rexx.com> Message-ID: <200512201610.21295.falted@pytables.org> A Dimarts 20 Desembre 2005 05:27, Dave Kuhlman va escriure: > Am I right that PyTables does not *directly* support scipy arrays? Not currently. But after the implementation of an efficient array protocol in all the basic numeric packages (numarray 1.5, Numeric 24.x and scipy_core), supporting scipy_core should be easy. Stay tuned :-) > That's not a big problem. You can write a scipy array to an HDF5 > file using PyTables with something like the following:: > > Is there a more efficient way? As Andrew has explained, use the array interface/protocol: # For scipy --> numarray numarray_array = numarray.asarray(scipy_array) # For numarray --> scipy scipy_array = scipy.base.asarray(numarray_array) I've taken the opportunity to run some elementary bencharmks to compare the speed of PyTables vs scipy (and numarray) .tofile() method (see the attachment). I've taken vector sizes from 10 elements up to 100 millions and run the benchmarks on a Opteron machine (BSD Unix), with 8 GB of RAM and with IDE disks @ 7200 RPM. The results are: % python speedcomp_pt_tofile.py scipy_core w Python 2.4.2 (#2, Oct 3 2005, 09:13:40) [GCC 3.4.2 [FreeBSD] 20040728] Optimization flags: -DNDEBUG -O -pipe -march=opteron -D__wchar_t=wchar_t -DTHREAD_STACK_SIZE=0x20000 getNCPUs is_32bit tables.__version__ --> 1.2 scipy_core.__version__--> 0.8.6.1687 --- PyTables, scipy_core, 10**1 time: 1.72 ms 46.514 KB/s tofile(), scipy_core, 10**1 time: 0.051 ms 1559.387 KB/s --- PyTables, scipy_core, 10**2 time: 1.727 ms 463.192 KB/s tofile(), scipy_core, 10**2 time: 0.051 ms 15596.702 KB/s --- PyTables, scipy_core, 10**3 time: 1.74 ms 4596.699 KB/s tofile(), scipy_core, 10**3 time: 0.066 ms 121065.204 KB/s --- PyTables, scipy_core, 10**4 time: 2.685 ms 29797.503 KB/s tofile(), scipy_core, 10**4 time: 0.358 ms 223171.018 KB/s --- PyTables, scipy_core, 10**5 time: 4.339 ms 184391.353 KB/s tofile(), scipy_core, 10**5 time: 19.243 ms 41573.555 KB/s --- PyTables, scipy_core, 10**6 time: 20.44 ms 391389.008 KB/s tofile(), scipy_core, 10**6 time: 159.981 ms 50005.959 KB/s --- PyTables, scipy_core, 10**7 time: 953.043 ms 83941.649 KB/s tofile(), scipy_core, 10**7 time: 2101.34 ms 38070.951 KB/s --- PyTables, scipy_core, 10**8 time: 16896.645 ms 47346.677 KB/s tofile(), scipy_core, 10**8 time: 18389.829 ms 43502.307 KB/s So, for writing, scipy.tofile() is faster for small arrays (as expected). However, for medium to large arrays, PyTables wins, being the crosspoint 10**5. For very large arrays, the disk becomes the bottleneck (both .tofile() and PyTables can reach this speed for this case). For reading, we have similar figures: % python speedcomp_pt_tofile.py scipy_core r Python 2.4.2 (#2, Oct 3 2005, 09:13:40) [GCC 3.4.2 [FreeBSD] 20040728] Optimization flags: -DNDEBUG -O -pipe -march=opteron -D__wchar_t=wchar_t -DTHREAD_STACK_SIZE=0x20000 getNCPUs is_32bit tables.__version__ --> 1.2 scipy_core.__version__--> 0.8.6.1687 --- PyTables, scipy_core, 10**1 time: 1.656 ms 48.3 KB/s tofile(), scipy_core, 10**1 time: 0.028 ms 2889.435 KB/s --- PyTables, scipy_core, 10**2 time: 1.583 ms 505.212 KB/s tofile(), scipy_core, 10**2 time: 0.04 ms 19814.244 KB/s --- PyTables, scipy_core, 10**3 time: 1.64 ms 4878.112 KB/s tofile(), scipy_core, 10**3 time: 0.053 ms 150373.9 KB/s --- PyTables, scipy_core, 10**4 time: 2.986 ms 26795.014 KB/s tofile(), scipy_core, 10**4 time: 0.126 ms 637093.339 KB/s --- PyTables, scipy_core, 10**5 time: 7.911 ms 101121.173 KB/s tofile(), scipy_core, 10**5 time: 5.663 ms 141268.138 KB/s --- PyTables, scipy_core, 10**6 time: 80.21 ms 99737.73 KB/s tofile(), scipy_core, 10**6 time: 71.455 ms 111958.572 KB/s --- PyTables, scipy_core, 10**7 time: 637.432 ms 125503.579 KB/s tofile(), scipy_core, 10**7 time: 682.141 ms 117277.74 KB/s --- PyTables, scipy_core, 10**8 time: 16455.255 ms 48616.688 KB/s tofile(), scipy_core, 10**8 time: 40503.035 ms 19751.606 KB/s Here the trends are similar. However, for very large arrays scipy_core starts to perform quite badly (I've run the benchmark twice, just to be sure). I don't know exactly the reasons for this, but it can be a good point to optimise ;-) Also interesting is that, for array sizes of 10**6 elements, PyTables can go faster writing (400 MB/s) than reading (100 MB/s), which of course, also offers a good point to look at it . Just for the sake of comparison, here are the results for numarray: % python speedcomp_pt_tofile.py numarray w Python 2.4.2 (#2, Oct 3 2005, 09:13:40) [GCC 3.4.2 [FreeBSD] 20040728] Optimization flags: -DNDEBUG -O -pipe -march=opteron -D__wchar_t=wchar_t -DTHREAD_STACK_SIZE=0x20000 getNCPUs is_32bit tables.__version__ --> 1.2 numarray.__version__--> 1.5.0 --- PyTables, numarray, 10**1 time: 1.697 ms 47.132 KB/s tofile(), numarray, 10**1 time: 0.089 ms 898.443 KB/s --- PyTables, numarray, 10**2 time: 1.715 ms 466.589 KB/s tofile(), numarray, 10**2 time: 0.092 ms 8721.621 KB/s --- PyTables, numarray, 10**3 time: 1.712 ms 4672.512 KB/s tofile(), numarray, 10**3 time: 0.125 ms 64004.639 KB/s --- PyTables, numarray, 10**4 time: 2.618 ms 30561.652 KB/s tofile(), numarray, 10**4 time: 0.604 ms 132555.482 KB/s --- PyTables, numarray, 10**5 time: 4.291 ms 186422.832 KB/s tofile(), numarray, 10**5 time: 26.183 ms 30554.667 KB/s --- PyTables, numarray, 10**6 time: 19.51 ms 410038.803 KB/s tofile(), numarray, 10**6 time: 162.777 ms 49146.889 KB/s --- PyTables, numarray, 10**7 time: 1131.729 ms 70688.323 KB/s tofile(), numarray, 10**7 time: 2185.191 ms 36610.077 KB/s --- PyTables, numarray, 10**8 time: 17065.664 ms 46877.755 KB/s tofile(), numarray, 10**8 time: 18673.172 ms 42842.212 KB/s The figures for PyTables are very similar to those of scipy, despite the fact that numarray is at the core of PyTables (and not scipy). This means that the array interface implementation is very efficient. On the other hand, the figures for numarray.tofile() are generally slower than scipy.tofile(), specially for small array sizes. For reading: % python speedcomp_pt_tofile.py numarray r Python 2.4.2 (#2, Oct 3 2005, 09:13:40) [GCC 3.4.2 [FreeBSD] 20040728] Optimization flags: -DNDEBUG -O -pipe -march=opteron -D__wchar_t=wchar_t -DTHREAD_STACK_SIZE=0x20000 getNCPUs is_32bit tables.__version__ --> 1.2 numarray.__version__--> 1.5.0 --- PyTables, numarray, 10**1 time: 1.598 ms 50.072 KB/s tofile(), numarray, 10**1 time: 0.078 ms 1028.914 KB/s --- PyTables, numarray, 10**2 time: 1.532 ms 522.14 KB/s tofile(), numarray, 10**2 time: 0.078 ms 10285.167 KB/s --- PyTables, numarray, 10**3 time: 1.63 ms 4909.243 KB/s tofile(), numarray, 10**3 time: 0.144 ms 55448.124 KB/s --- PyTables, numarray, 10**4 time: 3.003 ms 26641.708 KB/s tofile(), numarray, 10**4 time: 0.458 ms 174787.246 KB/s --- PyTables, numarray, 10**5 time: 6.208 ms 128863.699 KB/s tofile(), numarray, 10**5 time: 7.264 ms 110128.993 KB/s --- PyTables, numarray, 10**6 time: 68.284 ms 117157.148 KB/s tofile(), numarray, 10**6 time: 84.222 ms 94987.418 KB/s --- PyTables, numarray, 10**7 time: 640.721 ms 124859.399 KB/s tofile(), numarray, 10**7 time: 795.182 ms 100605.9 KB/s --- PyTables, numarray, 10**8 time: 17064.221 ms 46881.718 KB/s tofile(), numarray, 10**8 time: 39898.904 ms 20050.676 KB/s In this case, PyTables performs slightly better than before because it does not have to perform the additional conversion to scipy objects. However both performances (with numarray and scipy_core) are *very* close. Regarding numarray.fromfile() performance, one can again see that it is generally slower than scipy.fromfile(). Interestingly enough, for very large arrays (10**8 entry), numarray.fromfile() is also quite slow when compared with smaller sizes (10**7), i.e. it exhibits the very same symptom than scipy. In summary: - PyTables cannot compete in speed for small arrays (<10000 elements). However, the latency for saving/reading these objects is quite low (< 5 ms). - For larger arrays, PyTables (and hence, HDF5) always exposes better speed, even in the case of dealing with extremely large datasets (which is the field were it is supposed it has been designed for). Regards, -- >0,0< Francesc Altet ? ? http://www.carabos.com/ V V C?rabos Coop. V. ??Enjoy Data "-" -------------- next part -------------- A non-text attachment was scrubbed... Name: speedcomp_pt_tofile.py Type: application/x-python Size: 4380 bytes Desc: not available URL: From alopez at imim.es Tue Dec 20 11:08:50 2005 From: alopez at imim.es (LOPEZ GARCIA DE LOMANA, ADRIAN) Date: Tue, 20 Dec 2005 17:08:50 +0100 Subject: [SciPy-user] fmin_bfgs Message-ID: <66373AD054447F47851FCC5EB49B361101490AC9@basquet.imim.es> Hi all, I'm testing the routine fmin_bfgs from scipy.optimize and I have some problems. I do not understand why it gives me this warning. Warning: Desired error not necessarily achieved due to precision loss <---------------------------- Current function value: 152.114542 Iterations: 5 Function evaluations: 23 Gradient evaluations: 13 ?Because of the machine (quite new, dual Intel XEON 3.0)? The python is version 2.4.1 The code I'm using is at: http://diana.imim.es/~alopez/questions/code.py Also I plot a graph showing the last value of the function against the norm of the gradient, as you can see at http://diana.imim.es/~alopez/questions/figure.png most of the times is stopping at very low gradient norm values, but other times is stopping while the norm gradient AND the function value is higher than the stopping conditions. Red crosses come from the optimizations given the gradient analytically and green ones from the same optimizations where the gradient has been calculated numerically . Does anyone face the same problem? Is there any problem with the fmin_bfgs routine? Why is stopping while the gradient norm is bigger than gtol? What does it mean that the precission was lost? Any help or commentary will be welcomed, thanks, Adri?n. From jadelman at OCF.Berkeley.EDU Tue Dec 20 11:19:59 2005 From: jadelman at OCF.Berkeley.EDU (Joshua L. Adelman) Date: Tue, 20 Dec 2005 08:19:59 -0800 Subject: [SciPy-user] totally bogged down install on fedora core 4 In-Reply-To: <43A81E77.2020603@ftw.at> References: <43A81E77.2020603@ftw.at> Message-ID: <45D67944-5C1C-4CBF-BCB4-B7EBA2539A8B@ocf.berkeley.edu> What's the difference between the scipy_core version 0.8.4 that's available at sourceforge vs the one that's on the svn? According to Chris's installation instructions on the scipy website, he recommends getting both the core and the full scipy from svn. Josh On Dec 20, 2005, at 7:08 AM, Ed Schofield wrote: > Our website and documentation are a real mess at the moment. First > off, > you probably want the newer version 0.8.4 of scipy core. It's > available > from the Download link at http://numeric.scipy.org/. Get the file > called scipy_core-0.8.4.tar.gz, unpack it, and run "python setup.py > install" (as root) from the source directory. But before doing this > completely remove the existing installation, e.g. with: > > rm -Rf /usr/lib/python2.4/site-packages/scipy > > as root. > > Then test it out with > >>>> import scipy > >>>> scipy.test() > > If all's well and you want to install full scipy too, I suggest you > get > it from subversion: > > svn co http://svn.scipy.org/svn/scipy/trunk scipy > cd scipy > python setup.py install > > If you have any problems see the last few months' posts to this > mailing > list. > > -- Ed ------------------------------------------------------------------------ ------------------------------ Joshua L. Adelman Biophysics Graduate Group Lab: 510.643.2159 218 Wellman Hall Fax: 510.642.7428 University of California, Berkeley http://www.ocf.berkeley.edu/ ~jadelman Berkeley, CA 94720 USA jadelman at ocf.berkeley.edu ------------------------------------------------------------------------ ------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: From schofield at ftw.at Tue Dec 20 12:05:24 2005 From: schofield at ftw.at (Ed Schofield) Date: Tue, 20 Dec 2005 17:05:24 +0000 Subject: [SciPy-user] totally bogged down install on fedora core 4 In-Reply-To: <45D67944-5C1C-4CBF-BCB4-B7EBA2539A8B@ocf.berkeley.edu> References: <43A81E77.2020603@ftw.at> <45D67944-5C1C-4CBF-BCB4-B7EBA2539A8B@ocf.berkeley.edu> Message-ID: <43A839D4.9010209@ftw.at> Joshua L. Adelman wrote: > What's the difference between the scipy_core version 0.8.4 that's > available at sourceforge vs the one that's on the svn? According to > Chris's installation instructions on the scipy website, he recommends > getting both the core and the full scipy from svn. They're similar, since version 0.8.4 is a snapshot from last week. Both versions should be fine, but there's a small chance of breakage with the SVN tree if someone's in the middle of changes. -- Ed From dalembertian at yahoo.com Tue Dec 20 13:37:24 2005 From: dalembertian at yahoo.com (Frank) Date: Tue, 20 Dec 2005 12:37:24 -0600 Subject: [SciPy-user] As requested, a the OSX install odyssey Message-ID: <59749491-8CAE-452F-B7C2-464C41EED265@yahoo.com> In response to Ed's request of me several days ago, this seems like a good time (recalling Felis' recent trouble with the scipy_core install on OSX) to relate my troubles with the scipy install on OSX. Before I go on, I should say that I ultimately had no trouble installing from the newly updated instructions at Chris' site after I deleted the directory (thank you, Robert): /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/site-packages/ and used the gcc 3.3 compiler. Incidentally, according to the instructions, the latter step seems optional - it is not. I have never gotten anything close to a correct build with gcc 4. Also, I think the former step should be explicitly included in the instructions. Something to the effect of "if you screw it up, then delete this directory." That was a source of pain for me, I had figured (foolishly) that a new build from SVN would just "fix" whatever was wrong in that directory. Of course, it did not. Building from SVN (from the OLDER OSX instructions) was painful and never fully worked. First, install Numeric, however, you see on the numpy sourceforge site a download of the scipy_core "Numeric replacement." That should be better, right? No, it doesn't install without distutils. Oh, there is no mention of those anywhere in the instructions. Back to installing Numeric. Oh, that doesn't work on Tiger without a modification to "customize.py." The readme claims that the installer will just "know" that it is an OSX system and thus "know" where the lapack (vecLib) directories are. That did not work for me so it took me awhile to figure out how just to get Numeric going. No mention of such troubles on the site. In the next step, I see (on the F2PY website, only) that F2PY requires scipy_distutils. The only link I ever found to get them was on the F2PY website. Ok, distutils and F2PY installed. I then followed the CVS link (which linked to SVN instructions) and dutifully downloaded the core and started my build/install. For whatever reason (possibly a bad link from installing some piece along the way via gcc4?), that never worked and I had to download the full scipy from the link on the OSX instruction site. Only after fighting through the many configuration changes (e.g., extra link args) was I able to get anything going. The worst bit was (again, probably due to crap from broken installs stuck in my site_packages directory) that after the core claimed to install, the scipy build/install never finished without errors. The only way I got anything going was to go into the CORE directory (yes, I wrote core; yes, I know it was wrong to do) and cd into the scipy directory and build/install scipy from there. Of course, this is wrong but please let me point out two key bits: 1) the build/install of scipy the correct way never completed (always citing missing core and/or distutils components) 2) I have read on forums (and even the archives of this mailing list) that the numeric replacement core and the core downloadable tarball (linked on the instruction page) are different. When I combined these bits, I arrived at "oh, they must have meant this" type of install of scipy. Viola! It actually worked! I tested out the only function I needed at the time linalg.eig() - success! Of course, this left me with the (now infamous?) installation without interpolate or integrate but a working linalg and fft. I hope I don't sound unappreciative. SciPy is truly great and I look forward to supporting its further development via spreading the word and contributing when I can. Sorry this message was so long, but hey, you (Ed) asked. Thanks, Frank From robert.kern at gmail.com Tue Dec 20 13:48:52 2005 From: robert.kern at gmail.com (Robert Kern) Date: Tue, 20 Dec 2005 13:48:52 -0500 Subject: [SciPy-user] As requested, a the OSX install odyssey In-Reply-To: <59749491-8CAE-452F-B7C2-464C41EED265@yahoo.com> References: <59749491-8CAE-452F-B7C2-464C41EED265@yahoo.com> Message-ID: <43A85214.20305@gmail.com> Frank wrote: > In response to Ed's request of me several days ago, this seems like a > good time (recalling Felis' recent trouble with the scipy_core > install on OSX) to relate my troubles with the scipy install on OSX. > > Before I go on, I should say that I ultimately had no trouble > installing from the newly updated instructions at Chris' site after I > deleted the directory (thank you, Robert): > > /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ > python2.3/site-packages/ No, don't delete that directory! You had a broken or old scipy/ directory under that one. That's the directory I asked you to delete. -- Robert Kern robert.kern at gmail.com "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter From dalembertian at yahoo.com Tue Dec 20 13:54:10 2005 From: dalembertian at yahoo.com (Frank) Date: Tue, 20 Dec 2005 12:54:10 -0600 Subject: [SciPy-user] As requested, a the OSX install odyssey In-Reply-To: <43A85214.20305@gmail.com> References: <59749491-8CAE-452F-B7C2-464C41EED265@yahoo.com> <43A85214.20305@gmail.com> Message-ID: Oh whoops, my bad. You are correct. I meant: > /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ > python2.3/site-packages/scipy Apparently, I cannot copy/paste either. From felis at Safe-mail.net Tue Dec 20 13:59:14 2005 From: felis at Safe-mail.net (felis at Safe-mail.net) Date: Tue, 20 Dec 2005 13:59:14 -0500 Subject: [SciPy-user] totally bogged down install on fedora core 4 Message-ID: Hi Ed, thank you for pointing me in the right direction. I must say it is difficult when you start using this software to find which versions to use and what to do. Probably more common with packages in transition. I'll try and remove previous attempts and install this version, but i'm not sure where succesful installation of scipy_core will leave me, is it the SciPy, or is it a prerequisite to Scipy? On OSX installation of scipy_core went okay it seems. Thanks, now hopefully on to the GA examples ... felis -------- Original Message -------- From: Ed Schofield Apparently from: scipy-user-bounces at scipy.net To: SciPy Users List Subject: Re: [SciPy-user] totally bogged down install on fedora core 4 Date: Tue, 20 Dec 2005 17:05:24 +0000 > Joshua L. Adelman wrote: > > > What's the difference between the scipy_core version 0.8.4 that's > > available at sourceforge vs the one that's on the svn? According to > > Chris's installation instructions on the scipy website, he recommends > > getting both the core and the full scipy from svn. > > They're similar, since version 0.8.4 is a snapshot from last week. Both > versions should be fine, but there's a small chance of breakage with the > SVN tree if someone's in the middle of changes. > > -- Ed > > _______________________________________________ > SciPy-user mailing list > SciPy-user at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-user From robert.kern at gmail.com Tue Dec 20 14:15:03 2005 From: robert.kern at gmail.com (Robert Kern) Date: Tue, 20 Dec 2005 14:15:03 -0500 Subject: [SciPy-user] totally bogged down install on fedora core 4 In-Reply-To: References: Message-ID: <43A85837.6010001@gmail.com> felis at Safe-mail.net wrote: > Hi Ed, > > thank you for pointing me in the right direction. I must say it is difficult when you start using this software to find which versions to use and what to do. Probably more common with packages in transition. I'll try and remove previous attempts and install this version, but i'm not sure where succesful installation of scipy_core will leave me, is it the SciPy, or is it a prerequisite to Scipy? As the name suggests, it is a core subset of scipy that provides the array object and some other basic functionality. What we call "full scipy" is scipy_core plus the other subpackages like scipy.io and scipy.special. > On OSX installation of scipy_core went okay it seems. > Thanks, now hopefully on to the GA examples ... Do you mean the genetic algorithms package? If so, then you should know that that package has been moved to scipy.sandbox.ga and is not built by default. It has not received much attention over the years and probably does not work out-of-box. -- Robert Kern robert.kern at gmail.com "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter From dkuhlman at cutter.rexx.com Tue Dec 20 14:22:29 2005 From: dkuhlman at cutter.rexx.com (Dave Kuhlman) Date: Tue, 20 Dec 2005 11:22:29 -0800 Subject: [SciPy-user] What is fastest load/save matrix methods? In-Reply-To: <43A7A8BC.8040004@astraw.com> References: <43A0A31A.1000607@ieee.org> <43A6830E.6040704@gmail.com> <1135043354.5067.7.camel@localhost.localdomain> <20051220042704.GA13476@cutter.rexx.com> <1135058696.5067.23.camel@localhost.localdomain> <43A7A8BC.8040004@astraw.com> Message-ID: <20051220192229.GA27078@cutter.rexx.com> On Mon, Dec 19, 2005 at 10:46:20PM -0800, Andrew Straw wrote: > Cournapeau David wrote: [snip] > >Is there no way to convert numarray to scipy more directly than > >going through list ? Concerning implementing scipy array support, what > >is the difference between scipy array and numarray ? > > > > > > With sufficiently recent versions of scipy, Numeric, and numarray, > y=numstar.asarray(x) will create a view of the array with no copying, > which is pretty fast. > > "Sufficiently recent" means released within the last 2 months or so. Thanks for helping me with this. To give a little more information on what "Sufficiently recent" means: 1. numarray-1.4.1 supports that numarray.asarray() function, but gives a warning message the first time it is called on a scipy array and produces a type error when used to pass a scipy array to PyTables. 2. numarray-1.5.0 works just fine. It is available at: http://sourceforge.net/projects/numpy http://sourceforge.net/forum/forum.php?forum_id=518279 Dave -- Dave Kuhlman http://www.rexx.com/~dkuhlman From ckkart at hoc.net Tue Dec 20 17:19:14 2005 From: ckkart at hoc.net (Christian Kristukat) Date: Tue, 20 Dec 2005 23:19:14 +0100 Subject: [SciPy-user] mixing scipy and Numeric Message-ID: <43A88362.3050501@hoc.net> Hi, again I've got problems with old code that relies on Numeric when imported in some other program that uses scipy_core. Numeric.log10 has problems with a type called . A ValueError is raised when passing a variable of that type. The strange thing is that that variable has been created by pure Numeric code. Where does that type belong to? scipy or Numeric or plain python? What does the suffix _arrtype suggest since it seems to be an ordinary float? Regards, Christian From dkuhlman at cutter.rexx.com Tue Dec 20 18:16:48 2005 From: dkuhlman at cutter.rexx.com (Dave Kuhlman) Date: Tue, 20 Dec 2005 15:16:48 -0800 Subject: [SciPy-user] What is fastest load/save matrix methods? In-Reply-To: <200512201610.21295.falted@pytables.org> References: <43A0A31A.1000607@ieee.org> <1135043354.5067.7.camel@localhost.localdomain> <20051220042704.GA13476@cutter.rexx.com> <200512201610.21295.falted@pytables.org> Message-ID: <20051220231648.GA30844@cutter.rexx.com> On Tue, Dec 20, 2005 at 04:10:19PM +0100, Francesc Altet wrote: [snip] > > In summary: > > - PyTables cannot compete in speed for small arrays (<10000 elements). > However, the latency for saving/reading these objects is quite low > (< 5 ms). > > - For larger arrays, PyTables (and hence, HDF5) always exposes better > speed, even in the case of dealing with extremely large datasets > (which is the field were it is supposed it has been designed for). > Francesc - Thanks very much for the detailed benchmarks and the summary. But, for those of you considering use of my_array.tofile() and scipy.fromfile(), consider the following: 1. There is a warning message: >>> help(io.fromfile) ... WARNING: This function should be used sparingly, as it is not a robust method of persistence. But it can be useful to read in simply-formatted or binary data quickly. 2. tofile() and fromfile() do not seem to preserve the shape of the array. Consider: IPython profile: scipy In [1]:a1 = zeros((100,100)) In [2]:a1 Out[2]:NumPy array, format: long [[0 0 0 ..., 0 0 0] [0 0 0 ..., 0 0 0] [0 0 0 ..., 0 0 0] ..., [0 0 0 ..., 0 0 0] [0 0 0 ..., 0 0 0] [0 0 0 ..., 0 0 0]] In [3]:a1.tofile('tmp1.data') In [4]:a2 = fromfile('tmp1.data') In [5]:a1 Out[5]:NumPy array, format: long [[0 0 0 ..., 0 0 0] [0 0 0 ..., 0 0 0] [0 0 0 ..., 0 0 0] ..., [0 0 0 ..., 0 0 0] [0 0 0 ..., 0 0 0] [0 0 0 ..., 0 0 0]] In [6]:a2 Out[6]:NumPy array, format: long [0 0 0 ..., 0 0 0] In [7]:a1.shape Out[7]:(100, 100) In [8]:a2.shape Out[8]:(10000,) A two dimension array seems to have been collapsed into a one dimension array. Or, did I not use tofile() or fromfile() correctly? I modified Francesc's script so that it uses io.write_array() and scipy.io.read_array(), instead. The modified script is attached. Below are results from my machine using this modified script. Note that I also modified the number of interations (and eliminated the last one altogether). # Sizes for the arrays. #array_sizes = (10, 10**2, 10**3, 10**4, 10**5, 10**6, 10**7, 10**8) array_sizes = (10, 10**2, 10**3, 10**4, 10**5, 10**6, 10**7, ) # Number of iterations for each array size. #niters = (1000, 1000, 100, 100, 10, 3, 3, 1) niters = (1000, 1000, 100, 100, 10, 1, 1, ) Writing: $ python ../speedcomp_pt_write_array.py scipy_core w Python 2.4.2 (#1, Oct 31 2005, 11:22:05) [GCC 4.0.2 20050808 (prerelease) (Ubuntu 4.0.1-4ubuntu9)] Optimization flags: -DNDEBUG -g -O3 -Wall -Wstrict-prototypes getNCPUs has_3dnow has_3dnowext has_mmx has_sse is_32bit is_AMD is_singleCPU tables.__version__ --> 1.1.1 scipy_core.__version__--> 0.8.6.1663 --- PyTables, scipy_core, 10**1 time: 5.816 ms 6.878 KB/s write_array(), scipy_core, 10**1 time: 0.548 ms 72.947 KB/s --- PyTables, scipy_core, 10**2 time: 5.624 ms 71.119 KB/s write_array(), scipy_core, 10**2 time: 1.966 ms 203.467 KB/s --- PyTables, scipy_core, 10**3 time: 5.2 ms 769.199 KB/s write_array(), scipy_core, 10**3 time: 15.171 ms 263.66 KB/s --- PyTables, scipy_core, 10**4 time: 5.892 ms 6788.707 KB/s write_array(), scipy_core, 10**4 time: 140.505 ms 284.687 KB/s --- PyTables, scipy_core, 10**5 time: 9.298 ms 43021.812 KB/s write_array(), scipy_core, 10**5 time: 1400.494 ms 285.614 KB/s --- PyTables, scipy_core, 10**6 time: 35.056 ms 114102.778 KB/s write_array(), scipy_core, 10**6 time: 14222.73 ms 281.24 KB/s --- PyTables, scipy_core, 10**7 time: 296.545 ms 134886.766 KB/s write_array(), scipy_core, 10**7 time: 149788.421 ms 267.043 KB/s And, reading: $ python ../speedcomp_pt_write_array.py scipy_core r Python 2.4.2 (#1, Oct 31 2005, 11:22:05) [GCC 4.0.2 20050808 (prerelease) (Ubuntu 4.0.1-4ubuntu9)] Optimization flags: -DNDEBUG -g -O3 -Wall -Wstrict-prototypes getNCPUs has_3dnow has_3dnowext has_mmx has_sse is_32bit is_AMD is_singleCPU tables.__version__ --> 1.1.1 scipy_core.__version__--> 0.8.6.1663 --- PyTables, scipy_core, 10**1 time: 5.693 ms 7.026 KB/s read_array(), scipy_core, 10**1 time: 2.162 ms 18.498 KB/s --- PyTables, scipy_core, 10**2 time: 5.603 ms 71.396 KB/s read_array(), scipy_core, 10**2 time: 13.386 ms 29.882 KB/s --- PyTables, scipy_core, 10**3 time: 5.748 ms 695.835 KB/s read_array(), scipy_core, 10**3 time: 122.681 ms 32.605 KB/s --- PyTables, scipy_core, 10**4 time: 5.617 ms 7121.265 KB/s read_array(), scipy_core, 10**4 time: 1228.732 ms 32.554 KB/s --- PyTables, scipy_core, 10**5 time: 15.066 ms 26550.387 KB/s read_array(), scipy_core, 10**5 time: 12816.663 ms 31.209 KB/s --- PyTables, scipy_core, 10**6 time: 178.613 ms 22394.793 KB/s read_array(), scipy_core, 10**6 time: 137079.957 ms 29.18 KB/s --- PyTables, scipy_core, 10**7 time: 1015.1 ms 39404.985 KB/s read_array(), scipy_core, 10**7 time: 1456921.132 ms 27.455 KB/s Looks like io.write_array() and io.read_array() are usable *only* on moderate size arrays. And here are the resulting file sizes: 20 test_1.bin 4.1K test_1.h5 290 test_2.bin 4.4K test_2.h5 3.8K test_3.bin 8.0K test_3.h5 48K test_4.bin 44K test_4.h5 576K test_5.bin 395K test_5.h5 6.6M test_6.bin 3.9M test_6.h5 76M test_7.bin 39M test_7.h5 Oops. The .bin files were created by io.write_array(). They are actually text files. I should have changed the names to .txt or something similar. I'm only starting to learn PyTables, but I believe that it provides additional features over and above the tofile/fromfile and write_array/read_array strategies. In particular, PyTables gives you the ability to store and organize multiple arrays in nested groups (folders) within a single HDF5 file. Dave -- Dave Kuhlman http://www.rexx.com/~dkuhlman -------------- next part -------------- import tables import numarray import scipy.base from time import time import math from distutils.sysconfig import get_config_var from scipy.distutils.cpuinfo import cpu # Sizes for the arrays. #array_sizes = (10, 10**2, 10**3, 10**4, 10**5, 10**6, 10**7, 10**8) array_sizes = (10, 10**2, 10**3, 10**4, 10**5, 10**6, 10**7, ) # Number of iterations for each array size. #niters = (1000, 1000, 100, 100, 10, 3, 3, 1) niters = (1000, 1000, 100, 100, 10, 1, 1, ) def pytables_write(dset, lsize): filename = "test_"+str(lsize)+'.h5' h5file = tables.openFile(filename, mode = "w") # Write array after converting to a numarray array. dset = numarray.asarray(dset) h5file.createArray(h5file.root, 'dataset', dset) h5file.close() def pytables_read(numlib, lsize): filename = "test_"+str(lsize)+'.h5' h5file = tables.openFile(filename, mode = "r") # Read array and then convert to a numlib array. dset = h5file.root.dataset[:] if numlib == "scipy_core": dset = scipy.base.asarray(dset) h5file.close() return dset def write_array_write(dset, lsize): filename = "test_"+str(lsize)+'.txt' scipy.io.write_array(filename, dset) def write_array_read(numlib, lsize): filename = "test_"+str(lsize)+'.txt' if numlib == "scipy_core": return scipy.io.read_array(filename) else: return numarray.fromfile(filename) def test_write(numlib): j = 0 for size in array_sizes: lsize = int(math.log10(size)) niter = niters[j] j += 1 if numlib == "scipy_core": dset = scipy.base.arange(size) itemsize = dset.itemsize else: dset = numarray.arange(size) itemsize = dset.itemsize() # Time pytables t1=time() for i in range(niter): pytables_write(dset, lsize) print "---" print "PyTables, %s, 10**%s time:" % (numlib, lsize), tms = ((time()-t1)/niter)*1000 print round(tms, 3), "ms", print "\t", round((size*itemsize)/tms, 3), "KB/s" # time .tofile() t1=time() for i in range(niter): write_array_write(dset, lsize) print "write_array(), %s, 10**%s time:" % (numlib, lsize), tms = ((time()-t1)/niter)*1000 print round(tms, 3), "ms", print "\t", round((size*itemsize)/tms, 3), "KB/s" def test_read(numlib): j = 0 for size in array_sizes: lsize = int(math.log10(size)) niter = niters[j] j += 1 # Time pytables t1=time() for i in range(niter): dset = pytables_read(numlib, lsize) if numlib == "scipy_core": itemsize = dset.itemsize else: itemsize = dset.itemsize() print "---" print "PyTables, %s, 10**%s time:" % (numlib, lsize), tms = ((time()-t1)/niter)*1000 print round(tms, 3), "ms", print "\t", round((size*itemsize)/tms, 3), "KB/s" # time .tofile() t1=time() for i in range(niter): dset = write_array_read(numlib, lsize) print "read_array(), %s, 10**%s time:" % (numlib, lsize), tms = ((time()-t1)/niter)*1000 print round(tms, 3), "ms", print "\t", round((size*itemsize)/tms, 3), "KB/s" # main program import sys usage = "%s [scipy_core|numarray] [w|r]" % sys.argv[0] if len(sys.argv) < 3: print "Usage:", usage sys.exit(1) numlib = sys.argv[1] test_mode = sys.argv[2] if numlib not in ["numarray", "scipy_core"]: print "Only libraries numarray and scipy_core supported" sys.exit(1) if test_mode not in ['r', 'w']: print "Only modes 'w'rite and 'r'ead supported" sys.exit(1) print 'Python', sys.version print 'Optimization flags:', get_config_var('OPT') for name in dir(cpu): if name[0]=='_' and name[1]!='_': r = getattr(cpu,name[1:])() if r: if r!=1: print '%s=%s' %(name[1:],r), else: print name[1:], print print "tables.__version__ -->", tables.__version__ if numlib == "scipy_core": print "scipy_core.__version__-->", scipy.base.__version__ else: print "numarray.__version__-->", numarray.__version__ if test_mode == 'w': test_write(numlib) else: import os.path if (not os.path.exists("test_1.h5") or not os.path.exists("test_1.txt")): print "Please, run first the benchmark in 'w'rite mode." sys.exit(1) test_read(numlib) From Alexander.Olivas at usap.gov Tue Dec 20 18:28:24 2005 From: Alexander.Olivas at usap.gov (Alex Olivas) Date: Wed, 21 Dec 2005 12:28:24 +1300 Subject: [SciPy-user] scipy.test() runs for >6hrs Message-ID: <065DFA52-E48B-47C1-A62D-940C7BD2C948@usap.gov> I just installed SciPy on a Mac(10.4) lastnight. I'm looking for an alternative to ROOT and if anyone's familiar with that I'd appreciate any comparisons (i.e. what's better, what's worse?) In any case, after installing, the first thing I did was run the test 'scipy.test()' and went to sleep. When I woke up (6hrs later) the tests were still running. I'm assuming this isn't normal? Thanks, Alex. From travis.brady at gmail.com Tue Dec 20 18:47:52 2005 From: travis.brady at gmail.com (Travis Brady) Date: Tue, 20 Dec 2005 15:47:52 -0800 Subject: [SciPy-user] scipy.test() runs for >6hrs In-Reply-To: <065DFA52-E48B-47C1-A62D-940C7BD2C948@usap.gov> References: <065DFA52-E48B-47C1-A62D-940C7BD2C948@usap.gov> Message-ID: This email prompted me to test my SVN build of scipy (updated yesterday) and encountered this: ====================================================================== FAIL: check_round (scipy.special.basic.test_basic.test_round) ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\Python24\lib\site-packages\scipy\special\tests\test_basic.py", line 1 793, in check_round assert_array_equal(rnd,rndrl) File "C:\Python24\Lib\site-packages\scipy\test\testing.py", line 738, in asser t_array_equal assert cond,\ AssertionError: Arrays are not equal (mismatch 25.0%): Array 1: [10 10 10 11] Array 2: [10 10 11 11] ---------------------------------------------------------------------- Ran 1372 tests in 7.671s FAILED (failures=1) Travis On 12/20/05, Alex Olivas wrote: > > I just installed SciPy on a Mac(10.4) lastnight. > I'm looking for an alternative to ROOT and if anyone's > familiar with that I'd appreciate any comparisons > (i.e. what's better, what's worse?) > > In any case, after installing, the first thing I did was > run the test 'scipy.test()' and went to sleep. When I > woke up (6hrs later) the tests were still running. > I'm assuming this isn't normal? > Thanks, > Alex. > > _______________________________________________ > SciPy-user mailing list > SciPy-user at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.kern at gmail.com Tue Dec 20 19:25:19 2005 From: robert.kern at gmail.com (Robert Kern) Date: Tue, 20 Dec 2005 19:25:19 -0500 Subject: [SciPy-user] scipy.special.round [was: Re: scipy.test() runs for >6hrs] In-Reply-To: References: <065DFA52-E48B-47C1-A62D-940C7BD2C948@usap.gov> Message-ID: <43A8A0EF.2050709@gmail.com> Travis Brady wrote: > This email prompted me to test my SVN build of scipy (updated yesterday) > and encountered this: > > ====================================================================== > FAIL: check_round (scipy.special.basic.test_basic.test_round ) > ---------------------------------------------------------------------- > Traceback (most recent call last): > File > "C:\Python24\lib\site-packages\scipy\special\tests\test_basic.py", line 1 > 793, in check_round > assert_array_equal(rnd,rndrl) > File "C:\Python24\Lib\site-packages\scipy\test\testing.py", line 738, > in asser > t_array_equal > assert cond,\ > AssertionError: > Arrays are not equal (mismatch 25.0%): > Array 1: [10 10 10 11] > Array 2: [10 10 11 11] Okay, this is a platform-dependent bug that we've discussed several times before. scipy.special.round is documented to round numbers which have a fractional part of exactly 0.5 to the nearest even number. On some platforms (like OS X and whatever combination of Windows and CPU you have) this works fine. On other platforms (like some combinations of Linux and Intel CPUs), this does not work. I have committed the proper unit test and a comment on why it is the proper test. If you are actually getting [10 10 11 11] in Array 1, then you have a bug in Cephes' round function, *not* the unit test. -- Robert Kern robert.kern at gmail.com "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter From Alexander.Olivas at usap.gov Tue Dec 20 19:46:14 2005 From: Alexander.Olivas at usap.gov (Alex Olivas) Date: Wed, 21 Dec 2005 13:46:14 +1300 Subject: [SciPy-user] scipy.test() runs for >6hrs In-Reply-To: References: <065DFA52-E48B-47C1-A62D-940C7BD2C948@usap.gov> Message-ID: <245DA89B-51E8-4675-9821-F52AD2F3F01B@usap.gov> OK, so I reran the tests and it seems much more reasonable, only fewer tests are run than below. Ran 972 tests in 5.009s OK I seem to be missing about 400 tests. I do get a lot of "!! No test file ..." warnings. !! No test file 'test_Mplot.py' found for !! No test file 'test_lena.py' found for I haven't counted, but there could be 400 of these. Alex. On Dec 21, 2005, at 12:47 PM, Travis Brady wrote: > This email prompted me to test my SVN build of scipy (updated > yesterday) and encountered this: > > ====================================================================== > FAIL: check_round (scipy.special.basic.test_basic.test_round ) > ---------------------------------------------------------------------- > Traceback (most recent call last): > File "C:\Python24\lib\site-packages\scipy\special\tests > \test_basic.py", line 1 > 793, in check_round > assert_array_equal(rnd,rndrl) > File "C:\Python24\Lib\site-packages\scipy\test\testing.py", line > 738, in asser > t_array_equal > assert cond,\ > AssertionError: > Arrays are not equal (mismatch 25.0%): > Array 1: [10 10 10 11] > Array 2: [10 10 11 11] > > > ---------------------------------------------------------------------- > Ran 1372 tests in 7.671s > > FAILED (failures=1) > > > Travis > > On 12/20/05, Alex Olivas wrote: > I just installed SciPy on a Mac(10.4) lastnight. > I'm looking for an alternative to ROOT and if anyone's > familiar with that I'd appreciate any comparisons > (i.e. what's better, what's worse?) > > In any case, after installing, the first thing I did was > run the test 'scipy.test()' and went to sleep. When I > woke up (6hrs later) the tests were still running. > I'm assuming this isn't normal? > Thanks, > Alex. > > _______________________________________________ > SciPy-user mailing list > SciPy-user at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-user > > _______________________________________________ > SciPy-user mailing list > SciPy-user at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-user -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alexander.Olivas at usap.gov Tue Dec 20 19:50:02 2005 From: Alexander.Olivas at usap.gov (Alex Olivas) Date: Wed, 21 Dec 2005 13:50:02 +1300 Subject: [SciPy-user] scipy.test() runs for >6hrs In-Reply-To: References: <065DFA52-E48B-47C1-A62D-940C7BD2C948@usap.gov> Message-ID: OK, so I think I was slightly mistaken about what the problem was. I sent my first email before morning coffee. Turns out the tests seem to lock up python. The only thing I can do is kill python from another shell. Alex. On Dec 21, 2005, at 12:47 PM, Travis Brady wrote: > This email prompted me to test my SVN build of scipy (updated > yesterday) and encountered this: > > ====================================================================== > FAIL: check_round (scipy.special.basic.test_basic.test_round ) > ---------------------------------------------------------------------- > Traceback (most recent call last): > File "C:\Python24\lib\site-packages\scipy\special\tests > \test_basic.py", line 1 > 793, in check_round > assert_array_equal(rnd,rndrl) > File "C:\Python24\Lib\site-packages\scipy\test\testing.py", line > 738, in asser > t_array_equal > assert cond,\ > AssertionError: > Arrays are not equal (mismatch 25.0%): > Array 1: [10 10 10 11] > Array 2: [10 10 11 11] > > > ---------------------------------------------------------------------- > Ran 1372 tests in 7.671s > > FAILED (failures=1) > > > Travis > > On 12/20/05, Alex Olivas wrote: > I just installed SciPy on a Mac(10.4) lastnight. > I'm looking for an alternative to ROOT and if anyone's > familiar with that I'd appreciate any comparisons > (i.e. what's better, what's worse?) > > In any case, after installing, the first thing I did was > run the test 'scipy.test()' and went to sleep. When I > woke up (6hrs later) the tests were still running. > I'm assuming this isn't normal? > Thanks, > Alex. > > _______________________________________________ > SciPy-user mailing list > SciPy-user at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-user > > _______________________________________________ > SciPy-user mailing list > SciPy-user at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-user -------------- next part -------------- An HTML attachment was scrubbed... URL: From hgamboa at gmail.com Tue Dec 20 20:57:20 2005 From: hgamboa at gmail.com (Hugo Gamboa) Date: Wed, 21 Dec 2005 01:57:20 +0000 Subject: [SciPy-user] What is fastest load/save matrix methods? In-Reply-To: <20051220231648.GA30844@cutter.rexx.com> References: <43A0A31A.1000607@ieee.org> <1135043354.5067.7.camel@localhost.localdomain> <20051220042704.GA13476@cutter.rexx.com> <200512201610.21295.falted@pytables.org> <20051220231648.GA30844@cutter.rexx.com> Message-ID: <86522b1a0512201757g6a43a2fh6b8f2013e561e46e@mail.gmail.com> I want thank you for the interresting discussions, that more than answering to my question, gave me a very good impression of this community, and lots of ideas to explore. I was able to get very good results with the fread/fwrite functions which are quite simple to use, but I'm inclined to study the PyTables package in order to get everything better organized and with faster acess since the size of my data already sets advantages in the Pytables usage, following the Francesc benchmark. Thanks again. Hugo Gamboa -------------- next part -------------- An HTML attachment was scrubbed... URL: From hgamboa at gmail.com Tue Dec 20 21:11:53 2005 From: hgamboa at gmail.com (Hugo Gamboa) Date: Wed, 21 Dec 2005 02:11:53 +0000 Subject: [SciPy-user] Install problem - Overwriting message when importing scipy Message-ID: <86522b1a0512201811y7ac2b192yc5fb4923827029e9@mail.gmail.com> Hi to all, I decided to make the effort to use the svn version of scipy. After adding the requested libraries to my kubuntu box, the core/scipy install process gave some warnings but managed to finish. The problem appears when the import is done where the following messages appear: >> import scipy Overwriting test = with > Overwriting utils = with Overwriting fftpack = with Overwriting fft = with Overwriting ifft = with Overwriting randn = with Some code that used to work with scipy managed to give a segmentation fault. Since is my first scipy installation I may missing some very basic step. Have anyone experienced and solved a similar problem? Are more details needed? Thanks in advance for your help. Hugo Gamboa -------------- next part -------------- An HTML attachment was scrubbed... URL: From cournape at atr.jp Tue Dec 20 22:01:59 2005 From: cournape at atr.jp (Cournapeau David) Date: Wed, 21 Dec 2005 12:01:59 +0900 Subject: [SciPy-user] What is fastest load/save matrix methods? In-Reply-To: <20051220231648.GA30844@cutter.rexx.com> References: <43A0A31A.1000607@ieee.org> <1135043354.5067.7.camel@localhost.localdomain> <20051220042704.GA13476@cutter.rexx.com> <200512201610.21295.falted@pytables.org> <20051220231648.GA30844@cutter.rexx.com> Message-ID: <1135134119.4997.5.camel@localhost.localdomain> > > I'm only starting to learn PyTables, but I believe that it > provides additional features over and above the tofile/fromfile > and write_array/read_array strategies. In particular, PyTables > gives you the ability to store and organize multiple arrays in > nested groups (folders) within a single HDF5 file. An other really important point is that you can easily import the pytables files from other languages, such as C (I am using pytables/hdf5 to transfer data between python and matlab), which may be crucial depending on your working environment. I am not sure it is possible with "pure scipy" methods (at least in a reasonable way). I may be totally wrong, though, as I don't much on the implementation of the array protocol in scipy, and on the write/read methods. David From fonnesbeck at gmail.com Tue Dec 20 22:03:15 2005 From: fonnesbeck at gmail.com (Chris Fonnesbeck) Date: Tue, 20 Dec 2005 22:03:15 -0500 Subject: [SciPy-user] Mac installers for scipy, etc. Message-ID: <723eb6930512201903q7c4eb96el7ae0e5bfb6cf246b@mail.gmail.com> For interested OS X users, I have provided mpkg installers for scipy_core and scipy from svn, as well as matplotlib 0.85.1 (cvs) and numarray 1.5.1. These were all built on OS X 10.4 on Python 2.4.2. http://trichech.us/mac Enjoy. -- Chris Fonnesbeck Atlanta, GA From strawman at astraw.com Tue Dec 20 22:41:37 2005 From: strawman at astraw.com (Andrew Straw) Date: Tue, 20 Dec 2005 19:41:37 -0800 Subject: [SciPy-user] Mac installers for scipy, etc. In-Reply-To: <723eb6930512201903q7c4eb96el7ae0e5bfb6cf246b@mail.gmail.com> References: <723eb6930512201903q7c4eb96el7ae0e5bfb6cf246b@mail.gmail.com> Message-ID: <43A8CEF1.2020905@astraw.com> Hi Chris, I've added a link to the nascent website-to-be: http://new.scipy.org/Wiki/Download (Actually, I've added the page, too!) Chris Fonnesbeck wrote: >For interested OS X users, I have provided mpkg installers for >scipy_core and scipy from svn, as well as matplotlib 0.85.1 (cvs) and >numarray 1.5.1. These were all built on OS X 10.4 on Python 2.4.2. > >http://trichech.us/mac > > From jadelman at OCF.Berkeley.EDU Tue Dec 20 23:46:29 2005 From: jadelman at OCF.Berkeley.EDU (Joshua L. Adelman) Date: Tue, 20 Dec 2005 20:46:29 -0800 Subject: [SciPy-user] Mac installers for scipy, etc. In-Reply-To: <723eb6930512201903q7c4eb96el7ae0e5bfb6cf246b@mail.gmail.com> References: <723eb6930512201903q7c4eb96el7ae0e5bfb6cf246b@mail.gmail.com> Message-ID: This is great to have, but when I used the installers and then ran test(), I got: Ran 1372 tests in 11.675s FAILED (failures=131, errors=6) and then when trying to run matplotlib: >>> from pylab import * Traceback (most recent call last): File "", line 1, in ? File "/Library/Frameworks/Python.framework/Versions/2.4/lib/ python2.4/site-packages/pylab.py", line 1, in ? from matplotlib.pylab import * File "/Library/Frameworks/Python.framework/Versions/2.4/lib/ python2.4/site-packages/matplotlib/__init__.py", line 593, in ? defaultParams = { File "/Library/Frameworks/Python.framework/Versions/2.4/lib/ python2.4/site-packages/matplotlib/__init__.py", line 261, in wrapper ret = func(*args, **kwargs) File "/Library/Frameworks/Python.framework/Versions/2.4/lib/ python2.4/site-packages/matplotlib/__init__.py", line 400, in _get_data_path raise RuntimeError('Could not find the matplotlib data files') RuntimeError: Could not find the matplotlib data files I'm running Tiger OS X 10.4.3 and had already installed scipy and scipy_core semi-successfully using the OS X tutorial at scipy.org (although had been having problems with matplotlib). I assume I should just be able to run the installers and it should just work. There weren't any readme's, so did I miss something? Josh On Dec 20, 2005, at 7:03 PM, Chris Fonnesbeck wrote: > For interested OS X users, I have provided mpkg installers for > scipy_core and scipy from svn, as well as matplotlib 0.85.1 (cvs) and > numarray 1.5.1. These were all built on OS X 10.4 on Python 2.4.2. > > http://trichech.us/mac > > Enjoy. > > -- > Chris Fonnesbeck > Atlanta, GA > > _______________________________________________ > SciPy-user mailing list > SciPy-user at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-user ------------------------------------------------------------------------ ------------------------------ Joshua L. Adelman Biophysics Graduate Group Lab: 510.643.2159 218 Wellman Hall Fax: 510.642.7428 University of California, Berkeley http://www.ocf.berkeley.edu/ ~jadelman Berkeley, CA 94720 USA jadelman at ocf.berkeley.edu ------------------------------------------------------------------------ ------------------------------ From fonnesbeck at gmail.com Tue Dec 20 23:57:24 2005 From: fonnesbeck at gmail.com (Chris Fonnesbeck) Date: Tue, 20 Dec 2005 23:57:24 -0500 Subject: [SciPy-user] Mac installers for scipy, etc. In-Reply-To: References: <723eb6930512201903q7c4eb96el7ae0e5bfb6cf246b@mail.gmail.com> Message-ID: <723eb6930512202057yf3e2aeo82da90076f91eda@mail.gmail.com> Josh, Thanks. I will look into this and get back to you. C. On 12/20/05, Joshua L. Adelman wrote: > This is great to have, but when I used the installers and then ran > test(), I got: > > Ran 1372 tests in 11.675s > > FAILED (failures=131, errors=6) > > > and then when trying to run matplotlib: > > >>> from pylab import * > Traceback (most recent call last): > File "", line 1, in ? > File "/Library/Frameworks/Python.framework/Versions/2.4/lib/ > python2.4/site-packages/pylab.py", line 1, in ? > from matplotlib.pylab import * > File "/Library/Frameworks/Python.framework/Versions/2.4/lib/ > python2.4/site-packages/matplotlib/__init__.py", line 593, in ? > defaultParams = { > File "/Library/Frameworks/Python.framework/Versions/2.4/lib/ > python2.4/site-packages/matplotlib/__init__.py", line 261, in wrapper > ret = func(*args, **kwargs) > File "/Library/Frameworks/Python.framework/Versions/2.4/lib/ > python2.4/site-packages/matplotlib/__init__.py", line 400, in > _get_data_path > raise RuntimeError('Could not find the matplotlib data files') > RuntimeError: Could not find the matplotlib data files > > I'm running Tiger OS X 10.4.3 and had already installed scipy and > scipy_core semi-successfully using the OS X tutorial at scipy.org > (although had been having problems with matplotlib). I assume I > should just be able to run the installers and it should just work. > There weren't any readme's, so did I miss something? > > Josh > > > On Dec 20, 2005, at 7:03 PM, Chris Fonnesbeck wrote: > > > For interested OS X users, I have provided mpkg installers for > > scipy_core and scipy from svn, as well as matplotlib 0.85.1 (cvs) and > > numarray 1.5.1. These were all built on OS X 10.4 on Python 2.4.2. > > > > http://trichech.us/mac > > > > Enjoy. > > > > -- > > Chris Fonnesbeck > > Atlanta, GA > > > > _______________________________________________ > > SciPy-user mailing list > > SciPy-user at scipy.net > > http://www.scipy.net/mailman/listinfo/scipy-user > > ------------------------------------------------------------------------ > ------------------------------ > Joshua L. Adelman > Biophysics Graduate Group Lab: 510.643.2159 > 218 Wellman Hall Fax: 510.642.7428 > University of California, Berkeley http://www.ocf.berkeley.edu/ > ~jadelman > Berkeley, CA 94720 USA jadelman at ocf.berkeley.edu > ------------------------------------------------------------------------ > ------------------------------ > > > > _______________________________________________ > SciPy-user mailing list > SciPy-user at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-user > -- Chris Fonnesbeck Atlanta, GA From oliphant at ee.byu.edu Wed Dec 21 01:29:42 2005 From: oliphant at ee.byu.edu (Travis Oliphant) Date: Tue, 20 Dec 2005 23:29:42 -0700 Subject: [SciPy-user] As requested, a the OSX install odyssey In-Reply-To: <59749491-8CAE-452F-B7C2-464C41EED265@yahoo.com> References: <59749491-8CAE-452F-B7C2-464C41EED265@yahoo.com> Message-ID: <43A8F656.6010009@ee.byu.edu> Frank wrote: >In response to Ed's request of me several days ago, this seems like a >good time (recalling Felis' recent trouble with the scipy_core >install on OSX) to relate my troubles with the scipy install on OSX. > > > My impression is that a lot of trouble with install is actually the instructions for older versions of both Numeric and scipy being used and followed for the new scipy install. I hear a lot of noise from people who are having trouble, but it is hard to dissect exactly what is wrong that we can fix besides "I followed the wrong set of instructions." I agree that there is a bit of confusion out there because of the dated website (I think Andrew is heroically fixing that problem). Remember that google is your friend (as long as you throw away information from longer than about 3 months ago). I'm very interested in and excited to see all the instructions that are coming forward on the "keys" to successful building of the package on the various platform. Building a software package is never trivial. The distutils try to help but they are not a cureall for getting the right prequisites and having clean places to install the final result. >Before I go on, I should say that I ultimately had no trouble >installing from the newly updated instructions at Chris' site after I >deleted the directory (thank you, Robert): > > This is good to know. Good instructions are very helpful for the newcomer. I think the gcc 3.3 requirement is very important to tell people about. It would be nice to know what the problem is with gcc 4.0 so that perhaps it can be fixed. >I hope I don't sound unappreciative. SciPy is truly great and I look >forward to supporting its further development via spreading the word >and contributing when I can. > > I really think a new webpage will fix this, but fixing the web page has been out of my control. Hopefully the old website (with all of its dated instructions) will disappear very soon. We are in transition and the confusion is hard. It should clear up in a few months. -Travis From oliphant at ee.byu.edu Wed Dec 21 01:53:06 2005 From: oliphant at ee.byu.edu (Travis Oliphant) Date: Tue, 20 Dec 2005 23:53:06 -0700 Subject: [SciPy-user] fmin_bfgs In-Reply-To: <66373AD054447F47851FCC5EB49B361101490AC9@basquet.imim.es> References: <66373AD054447F47851FCC5EB49B361101490AC9@basquet.imim.es> Message-ID: <43A8FBD2.3080809@ee.byu.edu> LOPEZ GARCIA DE LOMANA, ADRIAN wrote: >Hi all, > >I'm testing the routine fmin_bfgs from scipy.optimize and I have some problems. I do not understand why it gives me this warning. > >Warning: Desired error not necessarily achieved due to precision loss <---------------------------- > Current function value: 152.114542 > Iterations: 5 > Function evaluations: 23 > Gradient evaluations: 13 > > > > This is a potential problem with the Quasi-Newton minimizers. If you look in the code at where this error shows up you will see that it happens because of a divide-by-zero problem. In practice either the gradient is getting updated or the function value isn't getting updated on an iteration. I'm not sure what to do in this situation as it theoretically shouldn't happen and so is perhaps due to the fact that the function is not able to change in sufficiently small ways (thus the precision-loss error). One approach is to reset the Hessian calculation and move on (but I did not like that result on some problems I was working with). Another approach is to set rhok = some large number and move on. You could edit optimize.py to do that. Right now, the code is not guessing what to do but stopping and letting you know of the failure of the quasi-Newton method on your function. I don't think anything is wrong with fmin_bfgs per-say (except for a better way to deal with this situation). >Does anyone face the same problem? Is there any problem with the fmin_bfgs routine? Why is stopping while the gradient norm is bigger than gtol? What does it mean that the precission was lost? > > The stoppage is occuring not because you've found a minimum but because the method has essentially failed. You could try again from a different starting location or try a different optimizer. There is no "always best" optimizer that I know of. Thus, the family of optimizers that exists in scipy. Try them and see if they work for you. Best, -Travis From pearu at scipy.org Wed Dec 21 00:53:05 2005 From: pearu at scipy.org (Pearu Peterson) Date: Tue, 20 Dec 2005 23:53:05 -0600 (CST) Subject: [SciPy-user] Install problem - Overwriting message when importing scipy In-Reply-To: <86522b1a0512201811y7ac2b192yc5fb4923827029e9@mail.gmail.com> References: <86522b1a0512201811y7ac2b192yc5fb4923827029e9@mail.gmail.com> Message-ID: On Wed, 21 Dec 2005, Hugo Gamboa wrote: > Hi to all, > > I decided to make the effort to use the svn version of scipy. > > After adding the requested libraries to my kubuntu box, the core/scipy > install process gave some warnings but managed to finish. > > The problem appears when the import is done where the following messages > appear: > >>> import scipy > Overwriting test = '/usr/lib/python2.4/site-packages/scipy/test/__init__.pyc'> with method ScipyTest.test of 0xb4eec58c>> > Overwriting utils = '/usr/lib/python2.4/site-packages/scipy/base/utils.pyc'> with scipy.utils' from > '/usr/lib/python2.4/site-packages/scipy/utils/__init__.pyc'> > Overwriting fftpack = '/usr/lib/python2.4/site-packages/scipy/basic/fftpack.pyc'> with scipy.fftpack' from > '/usr/lib/python2.4/site-packages/scipy/fftpack/__init__.pyc'> > Overwriting fft = with 0xb48d23e4> > Overwriting ifft = with at 0xb48d241c> > Overwriting randn = 0xb7e58190> with These messages are ok, for now, I'll suppress these warnings once we have pkgload hooks finished. They report what earlier scipy (pre-pkgload scipy) had done silently. > Some code that used to work with scipy managed to give a segmentation fault. Does scipy.test(1,2) succeed? If not, could you send the failure report? Pearu From alopez at imim.es Wed Dec 21 05:07:39 2005 From: alopez at imim.es (LOPEZ GARCIA DE LOMANA, ADRIAN) Date: Wed, 21 Dec 2005 11:07:39 +0100 Subject: [SciPy-user] fmin_bfgs Message-ID: <66373AD054447F47851FCC5EB49B361101490ACB@basquet.imim.es> Thanks for your answer. I've found the variable "rhok" at the optimize.py, and I would like to run it again setting a larger number, but, what is large? rhok = 1 / Num.dot(yk,sk) ------> rhok = 0.1?, rhok = 1000000.0? Thanks, Adri?n. -----Original Message----- From: scipy-user-bounces at scipy.net on behalf of Travis Oliphant Sent: Wed 21/12/2005 06:53 To: SciPy Users List Subject: Re: [SciPy-user] fmin_bfgs LOPEZ GARCIA DE LOMANA, ADRIAN wrote: >Hi all, > >I'm testing the routine fmin_bfgs from scipy.optimize and I have some problems. I do not understand why it gives me this warning. > >Warning: Desired error not necessarily achieved due to precision loss <---------------------------- > Current function value: 152.114542 > Iterations: 5 > Function evaluations: 23 > Gradient evaluations: 13 > > > > This is a potential problem with the Quasi-Newton minimizers. If you look in the code at where this error shows up you will see that it happens because of a divide-by-zero problem. In practice either the gradient is getting updated or the function value isn't getting updated on an iteration. I'm not sure what to do in this situation as it theoretically shouldn't happen and so is perhaps due to the fact that the function is not able to change in sufficiently small ways (thus the precision-loss error). One approach is to reset the Hessian calculation and move on (but I did not like that result on some problems I was working with). Another approach is to set rhok = some large number and move on. You could edit optimize.py to do that. Right now, the code is not guessing what to do but stopping and letting you know of the failure of the quasi-Newton method on your function. I don't think anything is wrong with fmin_bfgs per-say (except for a better way to deal with this situation). >Does anyone face the same problem? Is there any problem with the fmin_bfgs routine? Why is stopping while the gradient norm is bigger than gtol? What does it mean that the precission was lost? > > The stoppage is occuring not because you've found a minimum but because the method has essentially failed. You could try again from a different starting location or try a different optimizer. There is no "always best" optimizer that I know of. Thus, the family of optimizers that exists in scipy. Try them and see if they work for you. Best, -Travis _______________________________________________ SciPy-user mailing list SciPy-user at scipy.net http://www.scipy.net/mailman/listinfo/scipy-user From elcorto at gmx.net Wed Dec 21 07:10:38 2005 From: elcorto at gmx.net (Steve Schmerler) Date: Wed, 21 Dec 2005 13:10:38 +0100 Subject: [SciPy-user] numerical accuracy In-Reply-To: <66373AD054447F47851FCC5EB49B361101490ACB@basquet.imim.es> References: <66373AD054447F47851FCC5EB49B361101490ACB@basquet.imim.es> Message-ID: <43A9463E.40808@gmx.net> Hi I think this is a general Python and not pure scipy topic: ############################################################################################# In [26]: from scipy import arange In [27]: ar = arange(0, 0.5, 0.05); a = ar[4] In [28]: a Out[28]: 0.20000000000000001 In [29]: b = 0.2 In [30]: b Out[30]: 0.20000000000000001 In [31]: a == b Out[31]: True In [32]: c = 1.0 - 0.8 In [33]: c Out[33]: 0.19999999999999996 In [34]: a == c Out[34]: False In [35]: a - b Out[35]: 0.0 In [36]: a - c Out[36]: 5.5511151231257827e-17 ############################################################################################# If a and c are "equal" regarding the numerical accury (a - c < 1e-16), aren't they supposed to be considered equal when comparing them? cheers, steve -- Should array indices start at 0 or 1? My compromise of 0.5 was rejected without, I thought, proper consideration. -- Stan Kelly-Bootle From robert.kern at gmail.com Wed Dec 21 07:29:36 2005 From: robert.kern at gmail.com (Robert Kern) Date: Wed, 21 Dec 2005 07:29:36 -0500 Subject: [SciPy-user] numerical accuracy In-Reply-To: <43A9463E.40808@gmx.net> References: <66373AD054447F47851FCC5EB49B361101490ACB@basquet.imim.es> <43A9463E.40808@gmx.net> Message-ID: <43A94AB0.2090002@gmail.com> Steve Schmerler wrote: > If a and c are "equal" regarding the numerical accury (a - c < 1e-16), > aren't they supposed to be considered equal when comparing them? No, for floating point numbers there are several possible ways to define "equality". Python uses "the bit patterns are equal". You also probably want to use a relative tolerance (roughly, (a-c)/a < eps) rather than the absolute tolerance that you describe. Use scipy.allclose() for full control. -- Robert Kern robert.kern at gmail.com "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter From hgamboa at gmail.com Wed Dec 21 07:38:21 2005 From: hgamboa at gmail.com (Hugo Gamboa) Date: Wed, 21 Dec 2005 12:38:21 +0000 Subject: [SciPy-user] Install problem - Overwriting message when importing scipy In-Reply-To: References: <86522b1a0512201811y7ac2b192yc5fb4923827029e9@mail.gmail.com> Message-ID: <86522b1a0512210438v7490a0aclc619990af372b61b@mail.gmail.com> > > Does scipy.test(1,2) succeed? If not, could you send the failure report? > > Pearu > > _______________________________________________ > SciPy-user mailing list > SciPy-user at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-user > The test gives the following result: ====================================================================== FAIL: check_round (scipy.special.basic.test_basic.test_round) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.4/site-packages/scipy/special/tests/test_basic.py", line 1799, in check_round assert_array_equal(rnd,rndrl) File "/usr/lib/python2.4/site-packages/scipy/test/testing.py", line 738, in assert_array_equal assert cond,\ AssertionError: Arrays are not equal (mismatch 25.0%): Array 1: [10 10 11 11] Array 2: [10 10 10 11] ---------------------------------------------------------------------- Ran 1372 tests in 15.726s FAILED (failures=1) --------------------------------------- I managed to detect that pyhton gives segmentation fault when scipy.io.freadis called. A simple script like the following manage to break python with my scipy installation: from scipy import * import timing def tic(): timing.start() def tac(s=""): timing.finish() print(':ms:'+str(timing.milli())+" "+s) tic() a=randn(1000,1000) tac("Generate data") tic() f=open("fwrite.mat","w") io.fwrite(f,size(a),a,"d",) tac("Write") tic() f=open("fwrite.mat","r") b=io.fread(f,size(a),"d") #FAILS tac("Read") Hugo Gamboa -------------- next part -------------- An HTML attachment was scrubbed... URL: From falted at pytables.org Wed Dec 21 07:44:58 2005 From: falted at pytables.org (Francesc Altet) Date: Wed, 21 Dec 2005 13:44:58 +0100 Subject: [SciPy-user] What is fastest load/save matrix methods? In-Reply-To: <20051220231648.GA30844@cutter.rexx.com> References: <43A0A31A.1000607@ieee.org> <200512201610.21295.falted@pytables.org> <20051220231648.GA30844@cutter.rexx.com> Message-ID: <200512211345.00025.falted@pytables.org> A Dimecres 21 Desembre 2005 00:16, Dave Kuhlman va escriure: > A two dimension array seems to have been collapsed into a one > dimension array. > > Or, did I not use tofile() or fromfile() correctly? You did. As documentation says, tofile() is a very terse function that just saves data, not metadata (like the shape or type). It is your responsability to read the data and then assign it to a proper container (with the adequate shape and type). On his part, PyTables does save the metadata (this is one of the reasons it performs slower on small arrays), and you don't need to worry about retrieving the correct shape and type by hand. > Oops. The .bin files were created by io.write_array(). They are > actually text files. I should have changed the names to .txt or > something similar. Well, comparing PyTables with io.write_array is not fair because ASCII files are really slow to read and write. A more appropriate contender for PyTables would be the excellent NetCDF interface that comes with Scientific Python (http://starship.python.net/~hinsen/ScientificPython/). It is generally more limited in terms of features than PyTables, but I've made no speed comparisons between both (and that would be really interesting to know about them). Cheers, -- >0,0< Francesc Altet ? ? http://www.carabos.com/ V V C?rabos Coop. V. ??Enjoy Data "-" From robert.kern at gmail.com Wed Dec 21 07:46:37 2005 From: robert.kern at gmail.com (Robert Kern) Date: Wed, 21 Dec 2005 07:46:37 -0500 Subject: [SciPy-user] Install problem - Overwriting message when importing scipy In-Reply-To: <86522b1a0512210438v7490a0aclc619990af372b61b@mail.gmail.com> References: <86522b1a0512201811y7ac2b192yc5fb4923827029e9@mail.gmail.com> <86522b1a0512210438v7490a0aclc619990af372b61b@mail.gmail.com> Message-ID: <43A94EAD.2020301@gmail.com> Hugo Gamboa wrote: > ====================================================================== > FAIL: check_round (scipy.special.basic.test_basic.test_round) > ---------------------------------------------------------------------- > Traceback (most recent call last): > File > "/usr/lib/python2.4/site-packages/scipy/special/tests/test_basic.py", > line 1799, in check_round > assert_array_equal(rnd,rndrl) > File "/usr/lib/python2.4/site-packages/scipy/test/testing.py", line > 738, in assert_array_equal > assert cond,\ > AssertionError: > Arrays are not equal (mismatch 25.0%): > Array 1: [10 10 11 11] > Array 2: [10 10 10 11] Yes, this is a known, platform-dependent bug. Please read the comment in the code for the unit test. -- Robert Kern robert.kern at gmail.com "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter From souheil.inati at nyu.edu Wed Dec 21 07:58:12 2005 From: souheil.inati at nyu.edu (Souheil Inati) Date: Wed, 21 Dec 2005 07:58:12 -0500 Subject: [SciPy-user] Possible bug in loadmat and savemat use of fread and fwrite Message-ID: <7F8BE62B-86E7-4A94-830E-575C08963353@nyu.edu> Hi all, I am new to the scipy (and python). I have just gotten scipy working on a mac G4 OS X 10.4.4 with python 2.4.2, thanks to Chris Fonnesbeck's instructions. Apologies in advance for the long post and if I am asking a question previously answered on the mailing list. I can't figure out how to search the mailing list properly. Mailman itself (scipy.net) doesn't have a search and the plone interface to mailman on scipy.org does nothing for searching. Google is not terrible. Anyway.... I'm having problems with io functions loadmat and savemat. I've dug as far as my limited python knowledge can get me and my current working hypothesis is that there is a bug in the low-level fread and fwrite functions, or maybe the way in which the loadmat and savemat functions call them. The code in io/examples works fine and the reading and writing of binary files via a combination of fopen and fwrite works fine as well. Any help or nudge in the proper direction would be greatly appreciated. Thanks, Souheil --------------------------------- Souheil Inati, PhD Assistant Professor Center for Neural Science and Department of Psychology New York University 4 Washington Place, Room 809 New York, N.Y., 10003-6621 Office: (212) 998-3741 Email: souheil.inati at nyu.edu ------------------------------------ ------------------------------------ Here's the behavior that i see for loadmat I created a file in Matlab 7.1 >> A = randn(4) >> save -V6 foo A In python: from scipy import * b = io.loadmat('foo.mat') gives a bus error. Reading through io/mio.py at around line 744 in the the beginning of the loadmat function is this bit of code: fid = fopen(full_name,'rb') test_vals = fid.fread(4,'byte') If I try to run this directly from python, like this: from scipy import * fid = fopen('foo.mat','rb') test_vals = fid.fread(4,'byte') I get the same bus error. Using the lower level python file functions directly works: fid = file('foo.mat','rb') b = fid.fread(4) returns a string b = 'MATL' as expected. So presumable there is an error in fread. ------------------------------------ ------------------------------------ For the savemat function the problem looks like this: from scipy import * io.savemat('foo2.mat',{'a': array([1.,2.,3.])}) ------------------------------------------------------------------------ --- exceptions.TypeError Traceback (most recent call last) /Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site- packages/scipy/io/mio.py in savemat(filename, dict) 871 imagf = var.dtypechar in ['F', 'D'] 872 fid.fwrite([var.shape[1], var.shape[0], imagf, len (variable)+1],'int') --> 873 fid.fwrite(variable+'\x00','char') 874 if imagf: 875 fid.fwrite(var.real) /Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site- packages/scipy/io/mio.py in write(self, data, mtype, bs) 219 howmany,mtype = getsize_type(mtype) 220 count = product(data.shape) --> 221 numpyio.fwrite(self,count,data,mtype,bs) 222 return 223 TypeError: argument 4 must be char, not None From falted at pytables.org Wed Dec 21 08:04:21 2005 From: falted at pytables.org (Francesc Altet) Date: Wed, 21 Dec 2005 14:04:21 +0100 Subject: [SciPy-user] What is fastest load/save matrix methods? In-Reply-To: <1135134119.4997.5.camel@localhost.localdomain> References: <43A0A31A.1000607@ieee.org> <20051220231648.GA30844@cutter.rexx.com> <1135134119.4997.5.camel@localhost.localdomain> Message-ID: <200512211404.21824.falted@pytables.org> A Dimecres 21 Desembre 2005 04:01, Cournapeau David va escriure: > An other really important point is that you can easily import the > pytables files from other languages, such as C (I am using pytables/hdf5 > to transfer data between python and matlab), which may be crucial > depending on your working environment. > > I am not sure it is possible with "pure scipy" methods (at least in a > reasonable way). I may be totally wrong, though, as I don't much on the > implementation of the array protocol in scipy, and on the write/read > methods. I'm aware that there exist machinery in scipy to read matlab files (see io.loadmat). However, I think that this format it is not meant to become a standard (although it might become a 'de facto' standard, a la Microsoft Office), and in fact, MathWorks does change the format from time to time to accomodate more features. Contrarily, HDF5 is designed to be an standard, and the people behind it tries hard to ensure not only backward compatibility, but also forward compatibility (to the extend that this is reasonably feasible). Cheers, -- Francesc Altet From pearu at scipy.org Wed Dec 21 07:38:35 2005 From: pearu at scipy.org (Pearu Peterson) Date: Wed, 21 Dec 2005 06:38:35 -0600 (CST) Subject: [SciPy-user] Install problem - Overwriting message when importing scipy In-Reply-To: <43A94EAD.2020301@gmail.com> References: <86522b1a0512201811y7ac2b192yc5fb4923827029e9@mail.gmail.com> <86522b1a0512210438v7490a0aclc619990af372b61b@mail.gmail.com> <43A94EAD.2020301@gmail.com> Message-ID: On Wed, 21 Dec 2005, Robert Kern wrote: > Hugo Gamboa wrote: > >> ====================================================================== >> FAIL: check_round (scipy.special.basic.test_basic.test_round) >> ---------------------------------------------------------------------- >> Traceback (most recent call last): >> File >> "/usr/lib/python2.4/site-packages/scipy/special/tests/test_basic.py", >> line 1799, in check_round >> assert_array_equal(rnd,rndrl) >> File "/usr/lib/python2.4/site-packages/scipy/test/testing.py", line >> 738, in assert_array_equal >> assert cond,\ >> AssertionError: >> Arrays are not equal (mismatch 25.0%): >> Array 1: [10 10 11 11] >> Array 2: [10 10 10 11] > > Yes, this is a known, platform-dependent bug. Please read the comment in the > code for the unit test. Ok, but what code has the bug? And can we fix it, say, by patching cephes/round.c? Pearu From pearu at scipy.org Wed Dec 21 08:08:09 2005 From: pearu at scipy.org (Pearu Peterson) Date: Wed, 21 Dec 2005 07:08:09 -0600 (CST) Subject: [SciPy-user] Install problem - Overwriting message when importing scipy In-Reply-To: References: <86522b1a0512201811y7ac2b192yc5fb4923827029e9@mail.gmail.com> <86522b1a0512210438v7490a0aclc619990af372b61b@mail.gmail.com> <43A94EAD.2020301@gmail.com> Message-ID: On Wed, 21 Dec 2005, Pearu Peterson wrote: >>> Arrays are not equal (mismatch 25.0%): >>> Array 1: [10 10 11 11] >>> Array 2: [10 10 10 11] >> >> Yes, this is a known, platform-dependent bug. Please read the comment in the >> code for the unit test. > > Ok, but what code has the bug? And can we fix it, say, by patching > cephes/round.c? It turns out that round function that is defined in cephes/round.c, is never called. When I renamed round to cephes_round, and modified cephes.h and _cephesmodule.c accordingly, correct round functions is called and all special tests pass succesfully. But before applying this patch, I would like to understand why cephes round function in not effective. Anyone have any ideas? Oearu From robert.kern at gmail.com Wed Dec 21 10:16:26 2005 From: robert.kern at gmail.com (Robert Kern) Date: Wed, 21 Dec 2005 10:16:26 -0500 Subject: [SciPy-user] Install problem - Overwriting message when importing scipy In-Reply-To: References: <86522b1a0512201811y7ac2b192yc5fb4923827029e9@mail.gmail.com> <86522b1a0512210438v7490a0aclc619990af372b61b@mail.gmail.com> <43A94EAD.2020301@gmail.com> Message-ID: <43A971CA.2050207@gmail.com> Pearu Peterson wrote: > It turns out that round function that is defined in cephes/round.c, is > never called. When I renamed round to cephes_round, and modified cephes.h > and _cephesmodule.c accordingly, correct round functions is called and all > special tests pass succesfully. > > But before applying this patch, I would like to understand why cephes > round function in not effective. Anyone have any ideas? I suspect that there is some other round() function which gets picked up during linking on Linux. Linking behaves differently on OS X and Windows so the Cephes routine gets used there. Also, be sure to update uses of round() in the other Cephes routines, too. Thank you! -- Robert Kern robert.kern at gmail.com "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter From bgranger at scu.edu Wed Dec 21 10:21:07 2005 From: bgranger at scu.edu (Brian Granger) Date: Wed, 21 Dec 2005 07:21:07 -0800 Subject: [SciPy-user] Mac installers for scipy, etc. Message-ID: What dependencies are there for these (like fortran and fftw)? Also, how are you using gcc 4.0? I thought nobody had gotten it to work on the Mac yet? Thanks Brian Granger Brian Granger, Ph.D. Assistant Professor of Physics Santa Clara University bgranger at scu.edu Phone: 408-551-1891 Fax: 408-554-6965 >>> fonnesbeck at gmail.com 12/20/05 7:03 PM >>> For interested OS X users, I have provided mpkg installers for scipy_core and scipy from svn, as well as matplotlib 0.85.1 (cvs) and numarray 1.5.1. These were all built on OS X 10.4 on Python 2.4.2. http://trichech.us/mac Enjoy. -- Chris Fonnesbeck Atlanta, GA _______________________________________________ SciPy-user mailing list SciPy-user at scipy.net http://www.scipy.net/mailman/listinfo/scipy-user This message scanned for viruses and SPAM by GWGuardian at SCU (MGW1) From pearu at scipy.org Wed Dec 21 09:25:47 2005 From: pearu at scipy.org (Pearu Peterson) Date: Wed, 21 Dec 2005 08:25:47 -0600 (CST) Subject: [SciPy-user] Install problem - Overwriting message when importing scipy In-Reply-To: <43A971CA.2050207@gmail.com> References: <86522b1a0512201811y7ac2b192yc5fb4923827029e9@mail.gmail.com> <86522b1a0512210438v7490a0aclc619990af372b61b@mail.gmail.com> <43A94EAD.2020301@gmail.com> <43A971CA.2050207@gmail.com> Message-ID: On Wed, 21 Dec 2005, Robert Kern wrote: > Pearu Peterson wrote: > >> It turns out that round function that is defined in cephes/round.c, is >> never called. When I renamed round to cephes_round, and modified cephes.h >> and _cephesmodule.c accordingly, correct round functions is called and all >> special tests pass succesfully. >> >> But before applying this patch, I would like to understand why cephes >> round function in not effective. Anyone have any ideas? > > I suspect that there is some other round() function which gets picked up during > linking on Linux. Linking behaves differently on OS X and Windows so the Cephes > routine gets used there. > > Also, be sure to update uses of round() in the other Cephes routines, too. Right, I figured something like that can be happening but not how to fix it. However, I have tested succesfully the following patch for Linux: pearu at p4:~/svn/scipy/Lib/special$ svn diff Index: setup.py =================================================================== --- setup.py (revision 1491) +++ setup.py (working copy) @@ -12,6 +12,8 @@ # define_macros.append(('NOINFINITIES',None)) # define_macros.append(('NONANS',None)) + # Force using cephes round. + define_macros.append(('round','cephes_round')) # C libraries config.add_library('c_misc',sources=[join('c_misc','*.c')]) Could someone on OS X and Windows systems test if the patch works on these platforms as well? Thanks, Pearu From fonnesbeck at gmail.com Wed Dec 21 10:45:01 2005 From: fonnesbeck at gmail.com (Chris Fonnesbeck) Date: Wed, 21 Dec 2005 10:45:01 -0500 Subject: [SciPy-user] Mac installers for scipy, etc. In-Reply-To: References: Message-ID: <723eb6930512210745s179027a5pb68746774e6b053b@mail.gmail.com> Hi Brian, If you plan on using f2py, you should have a FORTRAN compiler, and fftw 2.1.5 seems to work (although there have been reports of spurious output recently on both Mac and Windows). I have built and installed scipy_core and scipy on my powerbook with gcc 4.0 without a hitch. A month ago this did not work, but appears to now. Let me know if it causes any problems for you. C. On 12/21/05, Brian Granger wrote: > What dependencies are there for these (like fortran and fftw)? > > Also, how are you using gcc 4.0? I thought nobody had gotten it to work on the Mac yet? > > Thanks > > Brian Granger > > > Brian Granger, Ph.D. > Assistant Professor of Physics > Santa Clara University > bgranger at scu.edu > Phone: 408-551-1891 > Fax: 408-554-6965 > >>> fonnesbeck at gmail.com 12/20/05 7:03 PM >>> > For interested OS X users, I have provided mpkg installers for > scipy_core and scipy from svn, as well as matplotlib 0.85.1 (cvs) and > numarray 1.5.1. These were all built on OS X 10.4 on Python 2.4.2. > > http://trichech.us/mac > > Enjoy. > > -- > Chris Fonnesbeck > Atlanta, GA > > _______________________________________________ > SciPy-user mailing list > SciPy-user at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-user > > > This message scanned for viruses and SPAM by GWGuardian at SCU (MGW1) > > _______________________________________________ > SciPy-user mailing list > SciPy-user at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-user > -- Chris Fonnesbeck Atlanta, GA From souheil.inati at nyu.edu Wed Dec 21 10:58:35 2005 From: souheil.inati at nyu.edu (Souheil Inati) Date: Wed, 21 Dec 2005 10:58:35 -0500 Subject: [SciPy-user] Mac installers for scipy, etc. In-Reply-To: <723eb6930512210745s179027a5pb68746774e6b053b@mail.gmail.com> References: <723eb6930512210745s179027a5pb68746774e6b053b@mail.gmail.com> Message-ID: <66F59445-35FE-4B88-9DFF-3EBE18E9062A@nyu.edu> Hi Chris, When you say gcc 4.0, are you including the gcc 4.0 fortran compiler i.e. gfortran? Or are you using a combination of gcc 4.0 for C,C++ and gcc 3.4 (ie g77) for Fortran. -SI On Dec 21, 2005, at 10:45 AM, Chris Fonnesbeck wrote: > Hi Brian, > > If you plan on using f2py, you should have a FORTRAN compiler, and > fftw 2.1.5 seems to work (although there have been reports of spurious > output recently on both Mac and Windows). > > I have built and installed scipy_core and scipy on my powerbook with > gcc 4.0 without a hitch. A month ago this did not work, but appears to > now. Let me know if it causes any problems for you. > > C. > > On 12/21/05, Brian Granger wrote: >> What dependencies are there for these (like fortran and fftw)? >> >> Also, how are you using gcc 4.0? I thought nobody had gotten it >> to work on the Mac yet? >> >> Thanks >> >> Brian Granger >> >> >> Brian Granger, Ph.D. >> Assistant Professor of Physics >> Santa Clara University >> bgranger at scu.edu >> Phone: 408-551-1891 >> Fax: 408-554-6965 >>>>> fonnesbeck at gmail.com 12/20/05 7:03 PM >>> >> For interested OS X users, I have provided mpkg installers for >> scipy_core and scipy from svn, as well as matplotlib 0.85.1 (cvs) and >> numarray 1.5.1. These were all built on OS X 10.4 on Python 2.4.2. >> >> http://trichech.us/mac >> >> Enjoy. From hgamboa at gmail.com Wed Dec 21 11:04:11 2005 From: hgamboa at gmail.com (Hugo Gamboa) Date: Wed, 21 Dec 2005 16:04:11 +0000 Subject: [SciPy-user] Install problem - Overwriting message when importing scipy In-Reply-To: References: <86522b1a0512201811y7ac2b192yc5fb4923827029e9@mail.gmail.com> <86522b1a0512210438v7490a0aclc619990af372b61b@mail.gmail.com> <43A94EAD.2020301@gmail.com> <43A971CA.2050207@gmail.com> Message-ID: <86522b1a0512210804x789eb366w755ce5282436a6fe@mail.gmail.com> Has anyone been able to reproduce the segmentation fault caused by fread? Hugo Gamboa from scipy import * import timing def tic(): timing.start() def tac(s=""): timing.finish() print(':ms:'+str(timing.milli())+" "+s) tic() a=randn(1000,1000) tac("Generate data") tic() f=open("fwrite.mat","w") io.fwrite(f,size(a),a,"d",) tac("Write") tic() f=open("fwrite.mat","r") b=io.fread(f,size(a),"d") #FAILS - SEGMENTATION FAULT tac("Read") Hugo Gamboa -------------- next part -------------- An HTML attachment was scrubbed... URL: From dd55 at cornell.edu Wed Dec 21 11:33:03 2005 From: dd55 at cornell.edu (Darren Dale) Date: Wed, 21 Dec 2005 11:33:03 -0500 Subject: [SciPy-user] fft numerical precision Message-ID: <200512211133.03969.dd55@cornell.edu> I am running into problems related, I think, to numerical precision of fast Fourier transforms. If I Fourier transform a gaussian distribution: absolute(fft(stats.norm.pdf(linspace(-10,10,512), loc=0, scale=1))) I find a floor of about 1e-16. Does anyone know of a way to improve the precision? Thanks, Darren From robert.kern at gmail.com Wed Dec 21 11:38:17 2005 From: robert.kern at gmail.com (Robert Kern) Date: Wed, 21 Dec 2005 11:38:17 -0500 Subject: [SciPy-user] fft numerical precision In-Reply-To: <200512211133.03969.dd55@cornell.edu> References: <200512211133.03969.dd55@cornell.edu> Message-ID: <43A984F9.4090809@gmail.com> Darren Dale wrote: > I am running into problems related, I think, to numerical precision of fast > Fourier transforms. If I Fourier transform a gaussian distribution: > > absolute(fft(stats.norm.pdf(linspace(-10,10,512), loc=0, scale=1))) > > I find a floor of about 1e-16. Does anyone know of a way to improve the > precision? 1e-16 is the best you can do with double precision. -- Robert Kern robert.kern at gmail.com "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter From managan at llnl.gov Wed Dec 21 11:43:01 2005 From: managan at llnl.gov (Rob Managan) Date: Wed, 21 Dec 2005 08:43:01 -0800 Subject: [SciPy-user] Install problem - Overwriting message when importing scipy In-Reply-To: References: <86522b1a0512201811y7ac2b192yc5fb4923827029e9@mail.gmail.com> <86522b1a0512210438v7490a0aclc619990af372b61b@mail.gmail.com> <43A94EAD.2020301@gmail.com> Message-ID: My suspicion is this. On Mac OSX if I do a 'man round' I find that there is a function named round() in . It is defined to round all 0.5 cases to the integer away from zero; not the same as the cephes definition. I suspect that the standard library versino of round is getting linked to instead of the cephes version. Can this be due to the ordering of libraries on the link commands? I suppose that cephes should use a unique name if we want to be sure that the cephes version of round is called. At 7:08 AM -0600 12/21/05, Pearu Peterson wrote: >On Wed, 21 Dec 2005, Pearu Peterson wrote: > >>>> Arrays are not equal (mismatch 25.0%): >>>> Array 1: [10 10 11 11] >>>> Array 2: [10 10 10 11] >>> >>> Yes, this is a known, platform-dependent bug. Please read the >>>comment in the >>> code for the unit test. >> >> Ok, but what code has the bug? And can we fix it, say, by patching >> cephes/round.c? > >It turns out that round function that is defined in cephes/round.c, is >never called. When I renamed round to cephes_round, and modified cephes.h >and _cephesmodule.c accordingly, correct round functions is called and all >special tests pass succesfully. > >But before applying this patch, I would like to understand why cephes >round function in not effective. Anyone have any ideas? > >Oearu > >_______________________________________________ >SciPy-user mailing list >SciPy-user at scipy.net >http://www.scipy.net/mailman/listinfo/scipy-user -- *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*- Rob Managan email managan at llnl.gov LLNL phone: 925-423-0903 P.O. Box 808, L-095 FAX: 925-422-3389 Livermore, CA 94551-0808 From managan at llnl.gov Wed Dec 21 11:44:21 2005 From: managan at llnl.gov (Rob Managan) Date: Wed, 21 Dec 2005 08:44:21 -0800 Subject: [SciPy-user] Install problem - Overwriting message when importing scipy In-Reply-To: References: <86522b1a0512201811y7ac2b192yc5fb4923827029e9@mail.gmail.com> <86522b1a0512210438v7490a0aclc619990af372b61b@mail.gmail.com> <43A94EAD.2020301@gmail.com> <43A971CA.2050207@gmail.com> Message-ID: Let me add to my previous comment. I am getting the same failure on mac OSX 10.3.9. So I am not sure what platforms the round does work on!! At 8:25 AM -0600 12/21/05, Pearu Peterson wrote: >On Wed, 21 Dec 2005, Robert Kern wrote: > >> Pearu Peterson wrote: >> >>> It turns out that round function that is defined in cephes/round.c, is >>> never called. When I renamed round to cephes_round, and modified cephes.h >>> and _cephesmodule.c accordingly, correct round functions is called and all >>> special tests pass succesfully. >>> >>> But before applying this patch, I would like to understand why cephes >>> round function in not effective. Anyone have any ideas? >> >> I suspect that there is some other round() function which gets >>picked up during >> linking on Linux. Linking behaves differently on OS X and Windows >>so the Cephes >> routine gets used there. >> >> Also, be sure to update uses of round() in the other Cephes routines, too. > >Right, I figured something like that can be happening but not how to fix >it. > -- *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*- Rob Managan email managan at llnl.gov LLNL phone: 925-423-0903 P.O. Box 808, L-095 FAX: 925-422-3389 Livermore, CA 94551-0808 From cookedm at physics.mcmaster.ca Wed Dec 21 11:44:55 2005 From: cookedm at physics.mcmaster.ca (David M. Cooke) Date: Wed, 21 Dec 2005 08:44:55 -0800 Subject: [SciPy-user] question about scipy.polynomial.poly1d In-Reply-To: <43A33401.2000605@ieee.org> References: <1e59dec00512161254j55dd03f6k6b238c3bc1edcfec@mail.gmail.com> <43A33401.2000605@ieee.org> Message-ID: <7054D414-3FD8-4F79-9664-448E127AB962@physics.mcmaster.ca> On Dec 16, 2005, at 13:39 , Travis Oliphant wrote: > Alan G Isaac wrote: > >> On Fri, 16 Dec 2005, Michael Blazej apparently wrote: >> >> >>> Is there a way to get different variables into poly1d such >>> as 'y' or 'lamda'. >>> >>> >> >> >> > I think he may mean in printing. In other-words can you get it to > print > with a different variable. Right now, no. But, it wouldn't be that > hard to change (at least for single-character replacements). Quite simple, actually. The _raise_power() helper routine doesn't need to know the length of the variable, so it's s a simple matter of using a different string for it: >>> q = poly1d([1.,2,3], variable='y') >>> print q 2 1 y + 2 y + 3 >>> q = poly1d(q, variable='lambda') >>> print q 2 1 lambda + 2 lambda + 3 This is in the current SVN now. -- |>|\/|< /------------------------------------------------------------------\ |David M. Cooke http://arbutus.physics.mcmaster.ca/dmc/ |cookedm at physics.mcmaster.ca From robert.kern at gmail.com Wed Dec 21 11:53:58 2005 From: robert.kern at gmail.com (Robert Kern) Date: Wed, 21 Dec 2005 11:53:58 -0500 Subject: [SciPy-user] Install problem - Overwriting message when importing scipy In-Reply-To: References: <86522b1a0512201811y7ac2b192yc5fb4923827029e9@mail.gmail.com> <86522b1a0512210438v7490a0aclc619990af372b61b@mail.gmail.com> <43A94EAD.2020301@gmail.com> <43A971CA.2050207@gmail.com> Message-ID: <43A988A6.8080507@gmail.com> Rob Managan wrote: > Let me add to my previous comment. I am getting the same failure on > mac OSX 10.3.9. So I am not sure what platforms the round does work > on!! OS X and Windows were always fine. Linux was causing the problem. If you saw a failure on OS X, it was because the test was wrong. The test currently in SVN is correct. -- Robert Kern robert.kern at gmail.com "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter From managan at llnl.gov Wed Dec 21 11:55:50 2005 From: managan at llnl.gov (Rob Managan) Date: Wed, 21 Dec 2005 08:55:50 -0800 Subject: [SciPy-user] Install problem - Overwriting message when importing scipy In-Reply-To: <86522b1a0512210804x789eb366w755ce5282436a6fe@mail.gmail.com> References: <86522b1a0512201811y7ac2b192yc5fb4923827029e9@mail.gmail.com> <86522b1a0512210438v7490a0aclc619990af372b61b@mail.gmail.com> <43A94EAD.2020301@gmail.com> <43A971CA.2050207@gmail.com> <86522b1a0512210804x789eb366w755ce5282436a6fe@mail.gmail.com> Message-ID: I see the same thing on Mac OSX 10.3.9. I also see after the fact that the file fwrite.mat has zero length. This implies that the fwrite failed! At 4:04 PM +0000 12/21/05, Hugo Gamboa wrote: >Has anyone been able to reproduce the segmentation fault caused by fread? > >Hugo Gamboa > > > >from scipy import * >import timing > >def tic(): > timing.start() > >def tac(s=""): > timing.finish() > print(':ms:'+str(timing.milli())+" "+s) > >tic() >a=randn(1000,1000) >tac("Generate data") > > >tic() >f=open("fwrite.mat","w") >io.fwrite(f,size(a),a,"d",) >tac("Write") > >tic() >f=open("fwrite.mat","r") >b=io.fread(f,size(a),"d") #FAILS - SEGMENTATION FAULT >tac("Read") > > >Hugo Gamboa -- *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*- Rob Managan email managan at llnl.gov LLNL phone: 925-423-0903 P.O. Box 808, L-095 FAX: 925-422-3389 Livermore, CA 94551-0808 From nwagner at mecha.uni-stuttgart.de Wed Dec 21 11:57:16 2005 From: nwagner at mecha.uni-stuttgart.de (Nils Wagner) Date: Wed, 21 Dec 2005 17:57:16 +0100 Subject: [SciPy-user] Install problem - Overwriting message when importing scipy In-Reply-To: <86522b1a0512210804x789eb366w755ce5282436a6fe@mail.gmail.com> References: <86522b1a0512201811y7ac2b192yc5fb4923827029e9@mail.gmail.com> <86522b1a0512210438v7490a0aclc619990af372b61b@mail.gmail.com> <43A94EAD.2020301@gmail.com> <43A971CA.2050207@gmail.com> <86522b1a0512210804x789eb366w755ce5282436a6fe@mail.gmail.com> Message-ID: On Wed, 21 Dec 2005 16:04:11 +0000 Hugo Gamboa wrote: > Has anyone been able to reproduce the segmentation fault >caused by fread? Yes, and here is the backtrace [Thread debugging using libthread_db enabled] [New Thread 1076175008 (LWP 12819)] :ms:580 Generate data :ms:56 Write Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1076175008 (LWP 12819)] 0x40da902d in numpyio_fromfile (self=0x0, args=0x402b60f4) at numpyiomodule.c:154 154 Py_DECREF(indescr); (gdb) bt #0 0x40da902d in numpyio_fromfile (self=0x0, args=0x402b60f4) at numpyiomodule.c:154 #1 0x0811eb56 in PyCFunction_Call (func=0x40dfd2ec, arg=0x402b60f4, kw=0x0) at methodobject.c:93 #2 0x080c74ed in PyEval_EvalFrame (f=0x816d8f4) at ceval.c:1499 #3 0x080c8bb4 in PyEval_EvalCodeEx (co=0x4029a660, globals=0x4026c824, locals=0x4026c824, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at ceval.c:2736 #4 0x080c8de5 in PyEval_EvalCode (co=0x4029a660, globals=0x4026c824, locals=0x4026c824) at ceval.c:484 #5 0x080f77f8 in PyRun_SimpleFileExFlags (fp=0x8160008, filename=0xbffff015 "gamboa.py", closeit=1, flags=0xbfffecf4) at pythonrun.c:1265 #6 0x08055917 in Py_Main (argc=1, argv=0xbfffedc4) at main.c:484 #7 0x08054fc8 in main (argc=2, argv=0xbfffedc4) at python.c:23 > > Hugo Gamboa > > > > from scipy import * > import timing > > def tic(): > timing.start() > > def tac(s=""): > timing.finish() > print(':ms:'+str(timing.milli())+" "+s) > > tic() > a=randn(1000,1000) > tac("Generate data") > > > tic() > f=open("fwrite.mat","w") > io.fwrite(f,size(a),a,"d",) > tac("Write") > > tic() > f=open("fwrite.mat","r") > b=io.fread(f,size(a),"d") #FAILS - SEGMENTATION FAULT > tac("Read") > > > > Hugo Gamboa From managan at llnl.gov Wed Dec 21 12:00:05 2005 From: managan at llnl.gov (Rob Managan) Date: Wed, 21 Dec 2005 09:00:05 -0800 Subject: [SciPy-user] Install problem - Overwriting message when importing scipy In-Reply-To: <86522b1a0512210804x789eb366w755ce5282436a6fe@mail.gmail.com> References: <86522b1a0512201811y7ac2b192yc5fb4923827029e9@mail.gmail.com> <86522b1a0512210438v7490a0aclc619990af372b61b@mail.gmail.com> <43A94EAD.2020301@gmail.com> <43A971CA.2050207@gmail.com> <86522b1a0512210804x789eb366w755ce5282436a6fe@mail.gmail.com> Message-ID: I have to retract that previous email. I can't type and that caused the file to not be written. When I type correctly I simply get numpyio.error: There was an error reading from the file At 4:04 PM +0000 12/21/05, Hugo Gamboa wrote: >Has anyone been able to reproduce the segmentation fault caused by fread? > >Hugo Gamboa > > > >from scipy import * >import timing > >def tic(): > timing.start() > >def tac(s=""): > timing.finish() > print(':ms:'+str(timing.milli())+" "+s) > >tic() >a=randn(1000,1000) >tac("Generate data") > > >tic() >f=open("fwrite.mat","w") >io.fwrite(f,size(a),a,"d",) >tac("Write") > >tic() >f=open("fwrite.mat","r") >b=io.fread(f,size(a),"d") #FAILS - SEGMENTATION FAULT >tac("Read") > -- *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*- Rob Managan email managan at llnl.gov LLNL phone: 925-423-0903 P.O. Box 808, L-095 FAX: 925-422-3389 Livermore, CA 94551-0808 From managan at llnl.gov Wed Dec 21 12:15:56 2005 From: managan at llnl.gov (Rob Managan) Date: Wed, 21 Dec 2005 09:15:56 -0800 Subject: [SciPy-user] Install problem - Overwriting message when importing scipy In-Reply-To: <43A988A6.8080507@gmail.com> References: <86522b1a0512201811y7ac2b192yc5fb4923827029e9@mail.gmail.com> <86522b1a0512210438v7490a0aclc619990af372b61b@mail.gmail.com> <43A94EAD.2020301@gmail.com> <43A971CA.2050207@gmail.com> <43A988A6.8080507@gmail.com> Message-ID: At 11:53 AM -0500 12/21/05, Robert Kern wrote: >Rob Managan wrote: >> Let me add to my previous comment. I am getting the same failure on >> mac OSX 10.3.9. So I am not sure what platforms the round does work >> on!! > >OS X and Windows were always fine. Linux was causing the problem. If you saw a >failure on OS X, it was because the test was wrong. The test >currently in SVN is >correct. I reran with today's svn and confirm that I no longer see this on OSX 10.3.9. How recently was this fixed in svn? I recall seeing the failure within the last 2 weeks or so. I looked through the output Chris Fonnesbeck sent me and he gets this on OSX 10.4.?, gcc 4.0. FAIL: check_round (scipy.special.basic.test_basic.test_round) ---------------------------------------------------------------------- Traceback (most recent call last): File "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/scipy/special/tests/test_basic.py", line 1793, in check_round assert_array_equal(rnd,rndrl) File "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/scipy/test/testing.py", line 738, in assert_array_equal assert cond,\ AssertionError: Arrays are not equal (mismatch 25.0%): Array 1: [10 10 10 11] Array 2: [10 10 11 11] -- *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*- Rob Managan email managan at llnl.gov LLNL phone: 925-423-0903 P.O. Box 808, L-095 FAX: 925-422-3389 Livermore, CA 94551-0808 From robert.kern at gmail.com Wed Dec 21 12:26:12 2005 From: robert.kern at gmail.com (Robert Kern) Date: Wed, 21 Dec 2005 12:26:12 -0500 Subject: [SciPy-user] Install problem - Overwriting message when importing scipy In-Reply-To: References: <86522b1a0512201811y7ac2b192yc5fb4923827029e9@mail.gmail.com> <86522b1a0512210438v7490a0aclc619990af372b61b@mail.gmail.com> <43A94EAD.2020301@gmail.com> <43A971CA.2050207@gmail.com> <43A988A6.8080507@gmail.com> Message-ID: <43A99034.4040706@gmail.com> Rob Managan wrote: >> At 11:53 AM -0500 12/21/05, Robert Kern wrote: > >>>> Rob Managan wrote: >>>> >>>>>> Let me add to my previous comment. I am getting the same failure on >>>>>> mac OSX 10.3.9. So I am not sure what platforms the round does work >>>>>> on!! >>>> >>>> OS X and Windows were always fine. Linux was causing the problem. If >>>> you saw a >>>> failure on OS X, it was because the test was wrong. The test currently >>>> in SVN is >>>> correct. > >> I reran with today's svn and confirm that I no longer see this on OSX >> 10.3.9. How recently was this fixed in svn? I recall seeing the failure >> within the last 2 weeks or so. I fixed the test yesterday. >> I looked through the output Chris Fonnesbeck sent me and he gets this on >> OSX 10.4.?, gcc 4.0. >> >> FAIL: check_round (scipy.special.basic.test_basic.test_round) >> ---------------------------------------------------------------------- >> Traceback (most recent call last): >> File >> "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/scipy/special/tests/test_basic.py", >> >> line 1793, in check_round >> assert_array_equal(rnd,rndrl) >> File >> "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/scipy/test/testing.py", >> >> line 738, in assert_array_equal >> assert cond,\ >> AssertionError: >> Arrays are not equal (mismatch 25.0%): >> Array 1: [10 10 10 11] >> Array 2: [10 10 11 11] That's before I fixed the test. -- Robert Kern robert.kern at gmail.com "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter From christianson2 at llnl.gov Wed Dec 21 12:26:51 2005 From: christianson2 at llnl.gov (George Christianson) Date: Wed, 21 Dec 2005 09:26:51 -0800 Subject: [SciPy-user] Building scipy_core 0.6.1 and 0.8.4 from source fails on Windows XP Pro / cygwin Message-ID: <6.2.1.2.2.20051221090832.05a1bd70@mail.llnl.gov> Good morning, I tried to build scipy_core versions 0.6.1 and 0.8.4 from SourceForge sources. My platform runs Windows XP version 2002, service pack 2, with a 4 processor 3GHZ pentium. I build under cygwin 1.5.18, gcc version 3.4.4, python 2.4.1. In each of the two versions, I unpacked the gzipped source files and ran 'python setup.py build. In eack case, the builds proceeded normally until this point: customize GnuFCompiler using build_ext building 'scipy.base.umath' extension compiling C sources gcc options: '-fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes' compile options: '-Ibuild/src/scipy/base/src -Iscipy/base/include -Ibuild/src/sc ipy/base -Iscipy/base/src -I/usr/include/python2.4 -c' gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.5.18-i686-2.4/build /src/scipy/base/src/umathmodule.o -L/usr/lib/python2.4/config -lpython2.4 -o bui ld/lib.cygwin-1.5.18-i686-2.4/scipy/base/umath.dll build/temp.cygwin-1.5.18-i686-2.4/build/src/scipy/base/src/umathmodule.o: In fun ction `UBYTE_multiply': ... (many undefined references ) /tmp/scipy_core-0.8.4/scipy/base/src/ufuncobject.c:528: undefined reference to ` _feclearexcept' build/temp.cygwin-1.5.18-i686-2.4/build/src/scipy/base/src/umathmodule.o: In fun ction `construct_reduce': /tmp/scipy_core-0.8.4/scipy/base/src/ufuncobject.c:528: undefined reference to ` _fetestexcept' /tmp/scipy_core-0.8.4/scipy/base/src/ufuncobject.c:528: undefined reference to ` _feclearexcept' collect2: ld returned 1 exit status Could somebody suggest where I should look to resolve these references? Thanks George Christianson From fonnesbeck at gmail.com Wed Dec 21 13:18:29 2005 From: fonnesbeck at gmail.com (Chris Fonnesbeck) Date: Wed, 21 Dec 2005 13:18:29 -0500 Subject: [SciPy-user] Mac installers for scipy, etc. In-Reply-To: References: <723eb6930512201903q7c4eb96el7ae0e5bfb6cf246b@mail.gmail.com> Message-ID: <723eb6930512211018v6b7ad0e7gfb48fd5331e64164@mail.gmail.com> The new binaries posted (just now) are using gcc 3.3, rather than 4.0, and so the number of test failures is greatly reduced. As for the matplotlib error, I cannot replicate it. You might want to post that error to the matplotlib user's list for help. Which Python 2.4 are you using? These were built with ActivePython 2.4.2 (though they should work with any 2.4). C. -- Chris Fonnesbeck Atlanta, GA From ryanlists at gmail.com Wed Dec 21 14:53:30 2005 From: ryanlists at gmail.com (Ryan Krauss) Date: Wed, 21 Dec 2005 14:53:30 -0500 Subject: [SciPy-user] fft numerical precision In-Reply-To: <43A984F9.4090809@gmail.com> References: <200512211133.03969.dd55@cornell.edu> <43A984F9.4090809@gmail.com> Message-ID: I have run into this as well. 1e-16 seems large to me for double precision. Robert can you explain this a bit more please. Is there an IEEE spec or something that specifies how much of the 64bits is for exponent and how much is for the mantissa (I think that is the right word)? I was playing with some FORTRAN code and it seems like there was a big difference with complex vs. double complex. It seems like 1e-16 was the magnitude floor of complex and double complex was better. Ryan On 12/21/05, Robert Kern wrote: > Darren Dale wrote: > > I am running into problems related, I think, to numerical precision of fast > > Fourier transforms. If I Fourier transform a gaussian distribution: > > > > absolute(fft(stats.norm.pdf(linspace(-10,10,512), loc=0, scale=1))) > > > > I find a floor of about 1e-16. Does anyone know of a way to improve the > > precision? > > 1e-16 is the best you can do with double precision. > > -- > Robert Kern > robert.kern at gmail.com > > "In the fields of hell where the grass grows high > Are the graves of dreams allowed to die." > -- Richard Harter > > _______________________________________________ > SciPy-user mailing list > SciPy-user at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-user > From sransom at nrao.edu Wed Dec 21 14:58:23 2005 From: sransom at nrao.edu (Scott Ransom) Date: Wed, 21 Dec 2005 14:58:23 -0500 Subject: [SciPy-user] fft numerical precision In-Reply-To: References: <200512211133.03969.dd55@cornell.edu> <43A984F9.4090809@gmail.com> Message-ID: <200512211458.25284.sransom@nrao.edu> Hi Ryan, Note that 1e-16 is the approximate _fractional_ precision of double precision floats. You can get absolute numbers much smaller than that. There are a bunch of good references to floating point accuracy etc. Some of them are linked here: http://babbage.cs.qc.edu/courses/cs341/IEEE-754references.html Note that the FFTW website lists FFT accuracies in both single and double precision here: http://www.fftw.org/accuracy/ Scott On Wednesday 21 December 2005 02:53 pm, Ryan Krauss wrote: > I have run into this as well. 1e-16 seems large to me for double > precision. Robert can you explain this a bit more please. Is there > an IEEE spec or something that specifies how much of the 64bits is > for exponent and how much is for the mantissa (I think that is the > right word)? I was playing with some FORTRAN code and it seems like > there was a big difference with complex vs. double complex. It seems > like 1e-16 was the magnitude floor of complex and double complex was > better. > > Ryan > > On 12/21/05, Robert Kern wrote: > > Darren Dale wrote: > > > I am running into problems related, I think, to numerical > > > precision of fast Fourier transforms. If I Fourier transform a > > > gaussian distribution: > > > > > > absolute(fft(stats.norm.pdf(linspace(-10,10,512), loc=0, > > > scale=1))) > > > > > > I find a floor of about 1e-16. Does anyone know of a way to > > > improve the precision? > > > > 1e-16 is the best you can do with double precision. > > > > -- > > Robert Kern > > robert.kern at gmail.com > > > > "In the fields of hell where the grass grows high > > Are the graves of dreams allowed to die." > > -- Richard Harter > > > > _______________________________________________ > > SciPy-user mailing list > > SciPy-user at scipy.net > > http://www.scipy.net/mailman/listinfo/scipy-user > > _______________________________________________ > SciPy-user mailing list > SciPy-user at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-user -- Scott M. Ransom Address: NRAO Phone: (434) 296-0320 520 Edgemont Rd. email: sransom at nrao.edu Charlottesville, VA 22903 USA GPG Fingerprint: 06A9 9553 78BE 16DB 407B FFCA 9BFA B6FF FFD3 2989 From robert.kern at gmail.com Wed Dec 21 15:03:46 2005 From: robert.kern at gmail.com (Robert Kern) Date: Wed, 21 Dec 2005 15:03:46 -0500 Subject: [SciPy-user] fft numerical precision In-Reply-To: References: <200512211133.03969.dd55@cornell.edu> <43A984F9.4090809@gmail.com> Message-ID: <43A9B522.7020109@gmail.com> Ryan Krauss wrote: > I have run into this as well. 1e-16 seems large to me for double > precision. Robert can you explain this a bit more please. Is there > an IEEE spec or something that specifies how much of the 64bits is for > exponent and how much is for the mantissa (I think that is the right > word)? I was playing with some FORTRAN code and it seems like there > was a big difference with complex vs. double complex. It seems like > 1e-16 was the magnitude floor of complex and double complex was > better. IEEE-754 double precision has 11 bits for exponent, 1 bit for sign, and 52 for the rest of the mantissa. 2.**-52 ~= 2.22e-16 Goldberg, David. What Every Computer Scientist Should Know About Floating Point Arithmetic. 1991. http://www.physics.ohio-state.edu/~dws/grouplinks/floating_point_math.pdf -- Robert Kern robert.kern at gmail.com "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter From ted.horst at earthlink.net Wed Dec 21 18:12:12 2005 From: ted.horst at earthlink.net (Ted Horst) Date: Wed, 21 Dec 2005 17:12:12 -0600 Subject: [SciPy-user] polynomial division problems Message-ID: Polynomial division seems not to be working for me: >>> import scipy >>> scipy.__core_version__ '0.8.6.1693' >>> x2m1 = scipy.poly1d([1,0,-1]) >>> xp1 = scipy.poly1d([1,1]) >>> xm1 = scipy.poly1d([1,-1]) >>> x2m1/xp1 hangs, it seems the args in polydiv are backwards, so: >>> xp1/x2m1 [poly1d([ 0.]), poly1d([1, 1])] but even with args reversed, this should be poly1d([1, -1]) Hopefully this is an easy fix for somebody. Ted From cournape at atr.jp Wed Dec 21 20:48:41 2005 From: cournape at atr.jp (Cournapeau David) Date: Thu, 22 Dec 2005 10:48:41 +0900 Subject: [SciPy-user] What is fastest load/save matrix methods? In-Reply-To: <200512211404.21824.falted@pytables.org> References: <43A0A31A.1000607@ieee.org> <20051220231648.GA30844@cutter.rexx.com> <1135134119.4997.5.camel@localhost.localdomain> <200512211404.21824.falted@pytables.org> Message-ID: <1135216121.5420.4.camel@localhost.localdomain> On Wed, 2005-12-21 at 14:04 +0100, Francesc Altet wrote: > A Dimecres 21 Desembre 2005 04:01, Cournapeau David va escriure: > > An other really important point is that you can easily import the > > pytables files from other languages, such as C (I am using pytables/hdf5 > > to transfer data between python and matlab), which may be crucial > > depending on your working environment. > > > > I am not sure it is possible with "pure scipy" methods (at least in a > > reasonable way). I may be totally wrong, though, as I don't much on the > > implementation of the array protocol in scipy, and on the write/read > > methods. > > I'm aware that there exist machinery in scipy to read matlab files > (see io.loadmat). However, I think that this format it is not meant to > become a standard (although it might become a 'de facto' standard, a > la Microsoft Office), and in fact, MathWorks does change the format > from time to time to accomodate more features. Maybe I was not clear: I am using hdf5 files to transfer data between matlab and python, and not matfile. matfile, though documented, can change any time, and the official library to read them from C is not free in any sense. matlab, in recent versions (> 6.5), can read hdf5 files (having an old version, I had to program my own matlab interface to the C hdf5 api). I intend to use this technique to make the transition from matlab to scipy less painful and more graduate. David From aisaac at american.edu Thu Dec 22 08:59:48 2005 From: aisaac at american.edu (Alan G Isaac) Date: Thu, 22 Dec 2005 08:59:48 -0500 Subject: [SciPy-user] =?utf-8?q?=28almost_all=29_lapack_functions_were_alr?= =?utf-8?b?ZWFkeQl1bmRlcgknc2NpcHkubGluYWxnLmZsYXBhY2sn?= In-Reply-To: References: Message-ID: On Mon, 19 Dec 2005, Evan Monroig apparently wrote: > I am not sure if here is the right place, but here is > a piece of experience that others might find useful. Yes. Thanks! Alan Isaac From aisaac at american.edu Thu Dec 22 13:21:55 2005 From: aisaac at american.edu (Alan G Isaac) Date: Thu, 22 Dec 2005 13:21:55 -0500 Subject: [SciPy-user] polynomial division problems In-Reply-To: References: Message-ID: On Wed, 21 Dec 2005, Ted Horst apparently wrote: > Polynomial division seems not to be working for me: > >>> import scipy > >>> scipy.__core_version__ > '0.8.6.1693' > >>> x2m1 = scipy.poly1d([1,0,-1]) > >>> xp1 = scipy.poly1d([1,1]) > >>> xm1 = scipy.poly1d([1,-1]) > >>> x2m1/xp1 > hangs, it seems the args in polydiv are backwards, so: > >>> xp1/x2m1 > [poly1d([ 0.]), poly1d([1, 1])] > but even with args reversed, this should be poly1d([1, -1]) Confirmed: poly1d division is broken. Report below. Cheers, Alan Isaac >>> import scipy as S >>> S.base.__version__ '0.8.4' >>> x = S.poly1d([1,0,-1]) >>> x1 = S.poly1d([1,1]) >>> x/x1 Traceback (most recent call last): File "", line 1, in ? File "C:\Python24\Lib\site-packages\scipy\base\polynomial.py", line 494, in __ div__ return map(poly1d, polydiv(self.coeffs, other.coeffs)) File "C:\Python24\Lib\site-packages\scipy\base\polynomial.py", line 316, in po lydiv r = polysub(r, polymul(q, monDivisor))[1:] File "C:\Python24\Lib\site-packages\scipy\base\polynomial.py", line 282, in po lymul val = NX.convolve(a1, a2) File "C:\Python24\Lib\site-packages\scipy\base\numeric.py", line 130, in convo lve return multiarray.correlate(a,asarray(v)[::-1],mode) KeyboardInterrupt >>> x1/x [poly1d([ 0.]), poly1d([1, 1])] From jdhunter at ace.bsd.uchicago.edu Thu Dec 22 13:10:01 2005 From: jdhunter at ace.bsd.uchicago.edu (John Hunter) Date: Thu, 22 Dec 2005 12:10:01 -0600 Subject: [SciPy-user] boxcar problem Message-ID: <87u0d1f1fq.fsf@peds-pc311.bsd.uchicago.edu> Any ideas on this one? In [1]: import scipy In [2]: scipy.__version__ Out[2]: '0.3.0_266.4239' In [3]: scipy.stats.boxcox(scipy.rand(100)) --------------------------------------------------------------------------- exceptions.ValueError Traceback (most recent call last) /home/titan/johnh/ /opt/lang/python-2.3.4/lib/python2.3/site-packages/scipy/stats/morestats.py in boxcox(x, lmbda, alpha) 279 return -boxcox_llf(lmb,data) 280 lmax = optimize.brent(tempfunc, brack=(-2.0,2.0),args=(x,)) --> 281 y, lmax = boxcox(x, lmax) 282 if alpha is None: 283 return y, lmax ValueError: too many values to unpack In [4]: From cookedm at physics.mcmaster.ca Thu Dec 22 14:06:04 2005 From: cookedm at physics.mcmaster.ca (David M.Cooke) Date: Thu, 22 Dec 2005 11:06:04 -0800 Subject: [SciPy-user] polynomial division problems In-Reply-To: References: Message-ID: <1CEF3A11-3C6B-4089-96D0-FD0E61E8B453@physics.mcmaster.ca> On Dec 21, 2005, at 15:12 , Ted Horst wrote: > Polynomial division seems not to be working for me: > >>>> import scipy >>>> scipy.__core_version__ > '0.8.6.1693' >>>> x2m1 = scipy.poly1d([1,0,-1]) >>>> xp1 = scipy.poly1d([1,1]) >>>> xm1 = scipy.poly1d([1,-1]) >>>> x2m1/xp1 > > hangs, it seems the args in polydiv are backwards, so: Yes, this is bad :) I'm working on it. >>>> xp1/x2m1 > [poly1d([ 0.]), poly1d([1, 1])] > > but even with args reversed, this should be poly1d([1, -1]) eh? (x+1)/(x**2-1) should have a quotient of 0, and a remainder of x+1. -- |>|\/|< /------------------------------------------------------------------\ |David M. Cooke http://arbutus.physics.mcmaster.ca/dmc/ |cookedm at physics.mcmaster.ca From jaonary at free.fr Thu Dec 22 14:07:29 2005 From: jaonary at free.fr (Jaonary Rabarisoa) Date: Thu, 22 Dec 2005 20:07:29 +0100 Subject: [SciPy-user] Mac installers for scipy, etc. In-Reply-To: <723eb6930512210745s179027a5pb68746774e6b053b@mail.gmail.com> References: <723eb6930512210745s179027a5pb68746774e6b053b@mail.gmail.com> Message-ID: > > I have built and installed scipy_core and scipy on my powerbook with > gcc 4.0 without a hitch. A month ago this did not work, but appears to > now. Let me know if it causes any problems for you. > Hi Chris, I've tried to build scipy_core and scipy, also on my powerbook. scipy_core is correctly built but scipy failed. I have os x 10.4.3 with xcode 2.2, gcc 4.0.1, Python 2.4.2 installed with fink, fftw installed with fink. I get an error with "-lcc_dynamic". With gcc 3.4, the built and the installation work fine. Jaonary, From ted.horst at earthlink.net Thu Dec 22 20:40:55 2005 From: ted.horst at earthlink.net (Ted Horst) Date: Thu, 22 Dec 2005 19:40:55 -0600 Subject: [SciPy-user] polynomial division problems In-Reply-To: <1CEF3A11-3C6B-4089-96D0-FD0E61E8B453@physics.mcmaster.ca> References: <1CEF3A11-3C6B-4089-96D0-FD0E61E8B453@physics.mcmaster.ca> Message-ID: <2d46d8c01d9f06fcf57147271e470159@earthlink.net> On Dec 22, 2005, at 13:06, David M.Cooke wrote: > On Dec 21, 2005, at 15:12 , Ted Horst wrote: > >> Polynomial division seems not to be working for me: >> >>>>> import scipy >>>>> scipy.__core_version__ >> '0.8.6.1693' >>>>> x2m1 = scipy.poly1d([1,0,-1]) >>>>> xp1 = scipy.poly1d([1,1]) >>>>> xm1 = scipy.poly1d([1,-1]) >>>>> x2m1/xp1 >> >> hangs, it seems the args in polydiv are backwards, so: > > Yes, this is bad :) I'm working on it. > >>>>> xp1/x2m1 >> [poly1d([ 0.]), poly1d([1, 1])] >> >> but even with args reversed, this should be poly1d([1, -1]) > > eh? (x+1)/(x**2-1) should have a quotient of 0, and a remainder of x+1. Sorry, this was based on a guess that the problem had something to do with the args to polydiv being backwards, so I thought that (x+1)/(x**2-1) was being interpreted as (x**2-1)/(x+1). I have no idea why I thought that, so just ignore me. > -- > |>|\/|< > /------------------------------------------------------------------\ > |David M. Cooke http://arbutus.physics.mcmaster.ca/dmc/ > |cookedm at physics.mcmaster.ca From stephen.walton at csun.edu Thu Dec 22 21:10:44 2005 From: stephen.walton at csun.edu (Stephen Walton) Date: Thu, 22 Dec 2005 18:10:44 -0800 Subject: [SciPy-user] boxcar problem In-Reply-To: <87u0d1f1fq.fsf@peds-pc311.bsd.uchicago.edu> References: <87u0d1f1fq.fsf@peds-pc311.bsd.uchicago.edu> Message-ID: <43AB5CA4.6000601@csun.edu> John Hunter wrote: >Any ideas on this one? > > >In [1]: import scipy > >In [2]: scipy.__version__ >Out[2]: '0.3.0_266.4239' > >In [3]: scipy.stats.boxcox(scipy.rand(100)) >--------------------------------------------------------------------------- >exceptions.ValueError Traceback (most >recent call last) > >/home/titan/johnh/ > >/opt/lang/python-2.3.4/lib/python2.3/site-packages/scipy/stats/morestats.py >in boxcox(x, lmbda, alpha) > 279 return -boxcox_llf(lmb,data) > 280 lmax = optimize.brent(tempfunc, > brack=(-2.0,2.0),args=(x,)) >--> 281 y, lmax = boxcox(x, lmax) > 282 if alpha is None: > 283 return y, lmax > >ValueError: too many values to unpack > > I'm practicing my Python debugging skills ;-) . It looks to me like the problem is a few lines before: if lmbda is not None: # single transformation lmbda = lmbda*(x==x) y = where(lmbda == 0, log(x), (x**lmbda - 1)/lmbda) return y So, what happens is that you call boxcox() with no lmbda value (so it defaults to none), boxcox determines lmax, calls itself as boxcox(y,lmax) but because of the code copied above the recursive call only returns the value y. Hence there is no lmax value to unpack. I think the fix is simple: change line 354 to y = boxcox(x, lmax) Steve (I'm not sure why the offending line is listed as line 281 in John's output; it is line 354 on my machine.) From strawman at astraw.com Fri Dec 23 07:25:40 2005 From: strawman at astraw.com (Andrew Straw) Date: Fri, 23 Dec 2005 04:25:40 -0800 Subject: [SciPy-user] Possible bug in loadmat and savemat use of fread and fwrite In-Reply-To: <7F8BE62B-86E7-4A94-830E-575C08963353@nyu.edu> References: <7F8BE62B-86E7-4A94-830E-575C08963353@nyu.edu> Message-ID: Hi Souheil, I wrote the following email to scipy-dev last week. There is certainly something wrong with the low-level code at the moment (unless it's been fixed very recently). Nevertheless, I got beyond the bug you posted (see the attached patch) only to find another... From: strawman at astraw.com Subject: [SciPy-dev] getting scipy.io.mio / numpyio working again Date: December 15, 2005 2:22:22 PM PST To: scipy-dev at scipy.net Reply-To: scipy-dev at scipy.net Hi, I'm trying to get the following working: import scipy a={'a':scipy.arange(10)} scipy.io.mio.savemat('test.mat',a) b = scipy.io.mio.loadmat('test.mat') print b If I apply the following patch: Index: mio.py =================================================================== --- mio.py (revision 1485) +++ mio.py (working copy) @@ -870,7 +870,7 @@ imagf = var.dtypechar in ['F', 'D'] fid.fwrite([var.shape[1], var.shape[0], imagf, len(variable)+1],'int') - fid.fwrite(variable+'\x00','char') + fid.fwrite(variable+'\x00','uchar') if imagf: fid.fwrite(var.real) fid.fwrite(var.imag) I can get as far as the following traceback. I don't have time right now to delve deeper. Traceback (most recent call last): File "numpyiotest.py", line 4, in ? scipy.io.mio.savemat('test.mat',a) File "/usr/lib/python2.3/site-packages/scipy/io/mio.py", line 873, in savemat fid.fwrite(variable+'\x00','uchar') File "/usr/lib/python2.3/site-packages/scipy/io/mio.py", line 221, in write numpyio.fwrite(self,count,data,mtype,bs) numpyio.error: Does not support extended types. On Dec 21, 2005, at 4:58 AM, Souheil Inati wrote: > Hi all, > > I am new to the scipy (and python). I have just gotten scipy working > on a mac G4 OS X 10.4.4 with python 2.4.2, thanks to Chris > Fonnesbeck's instructions. Apologies in advance for the long post > and if I am asking a question previously answered on the mailing > list. I can't figure out how to search the mailing list properly. > Mailman itself (scipy.net) doesn't have a search and the plone > interface to mailman on scipy.org does nothing for searching. Google > is not terrible. Anyway.... > > I'm having problems with io functions loadmat and savemat. I've dug > as far as my limited python knowledge can get me and my current > working hypothesis is that there is a bug in the low-level fread and > fwrite functions, or maybe the way in which the loadmat and savemat > functions call them. The code in io/examples works fine and the > reading and writing of binary files via a combination of fopen and > fwrite works fine as well. > > Any help or nudge in the proper direction would be greatly > appreciated. > > Thanks, > Souheil > > > --------------------------------- > > Souheil Inati, PhD > Assistant Professor > Center for Neural Science and Department of Psychology > New York University > 4 Washington Place, Room 809 > New York, N.Y., 10003-6621 > Office: (212) 998-3741 > Email: souheil.inati at nyu.edu > > > ------------------------------------ > ------------------------------------ > Here's the behavior that i see for loadmat > > I created a file in Matlab 7.1 > >>> A = randn(4) >>> save -V6 foo A >>> > > In python: > from scipy import * > b = io.loadmat('foo.mat') > gives a bus error. > > Reading through io/mio.py at around line 744 in the the beginning of > the loadmat function is this bit of code: > fid = fopen(full_name,'rb') > test_vals = fid.fread(4,'byte') > > If I try to run this directly from python, like this: > from scipy import * > fid = fopen('foo.mat','rb') > test_vals = fid.fread(4,'byte') > I get the same bus error. > > Using the lower level python file functions directly works: > fid = file('foo.mat','rb') > b = fid.fread(4) > returns a string b = 'MATL' as expected. So presumable there is an > error in fread. > > ------------------------------------ > ------------------------------------ > For the savemat function the problem looks like this: > from scipy import * > io.savemat('foo2.mat',{'a': array([1.,2.,3.])}) > > ---------------------------------------------------------------------- > -- > --- > exceptions.TypeError Traceback (most > recent call last) > > /Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site- > packages/scipy/io/mio.py in savemat(filename, dict) > 871 imagf = var.dtypechar in ['F', 'D'] > 872 fid.fwrite([var.shape[1], var.shape[0], imagf, len > (variable)+1],'int') > --> 873 fid.fwrite(variable+'\x00','char') > 874 if imagf: > 875 fid.fwrite(var.real) > > /Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site- > packages/scipy/io/mio.py in write(self, data, mtype, bs) > 219 howmany,mtype = getsize_type(mtype) > 220 count = product(data.shape) > --> 221 numpyio.fwrite(self,count,data,mtype,bs) > 222 return > 223 > > TypeError: argument 4 must be char, not None > > > > > _______________________________________________ > SciPy-user mailing list > SciPy-user at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-user > From a.h.jaffe at gmail.com Sat Dec 24 04:45:08 2005 From: a.h.jaffe at gmail.com (Andrew Jaffe) Date: Sat, 24 Dec 2005 09:45:08 +0000 Subject: [SciPy-user] output formatting of scipy arrays Message-ID: Hi all- Sorry as usual if this is a faq, but is there any easy way to change the way arrays appear when printed (presumably, this means affecting the behavior of __str__?). Currently, I get things like [[ 1. 0.71375029 0.01215192 -0.90644004 0.02740346 0.66145675 0.85629017 0.96413003 0.65755463] [... when what I'd really prefer is something like [[ 1. 0.714 0.012 -0.906 0.027 0.661 0.856 0.964 0.658] [... Specifically, I'd like to get - less wide floating-point numbers - more entries per line Thanks, Andrew p.s. I wonder if the first part of the request is something that's possible to change more-or-less globally -- i.e. for all float -> string conversions -- in python? From ted.horst at earthlink.net Sat Dec 24 13:55:51 2005 From: ted.horst at earthlink.net (Ted Horst) Date: Sat, 24 Dec 2005 12:55:51 -0600 Subject: [SciPy-user] polynomial division problems In-Reply-To: <1CEF3A11-3C6B-4089-96D0-FD0E61E8B453@physics.mcmaster.ca> References: <1CEF3A11-3C6B-4089-96D0-FD0E61E8B453@physics.mcmaster.ca> Message-ID: <084c149e826662fa559ef21a497f53b7@earthlink.net> Thanks for fixing this. On Dec 22, 2005, at 13:06, David M.Cooke wrote: > Yes, this is bad :) I'm working on it. From oliphant.travis at ieee.org Sun Dec 25 00:49:52 2005 From: oliphant.travis at ieee.org (Travis Oliphant) Date: Sat, 24 Dec 2005 22:49:52 -0700 Subject: [SciPy-user] fmin_bfgs In-Reply-To: <66373AD054447F47851FCC5EB49B361101490ACB@basquet.imim.es> References: <66373AD054447F47851FCC5EB49B361101490ACB@basquet.imim.es> Message-ID: <43AE3300.4080906@ieee.org> LOPEZ GARCIA DE LOMANA, ADRIAN wrote: >Thanks for your answer. > >I've found the variable "rhok" at the optimize.py, and I would like to run it again setting a larger number, but, what is large? > >rhok = 1 / Num.dot(yk,sk) ------> rhok = 0.1?, rhok = 1000000.0? > > There is really no way to tell, but I'd try rhok > 1, maybe rhok=10**3 or rhok=10**6. -Travis From oliphant.travis at ieee.org Sun Dec 25 01:29:18 2005 From: oliphant.travis at ieee.org (Travis Oliphant) Date: Sat, 24 Dec 2005 23:29:18 -0700 Subject: [SciPy-user] output formatting of scipy arrays In-Reply-To: References: Message-ID: <43AE3C3E.8050007@ieee.org> Andrew Jaffe wrote: >Hi all- > >Sorry as usual if this is a faq, but is there any easy way to change the >way arrays appear when printed (presumably, this means affecting the >behavior of __str__?). > >Currently, I get things like > >[[ 1. 0.71375029 0.01215192 -0.90644004 0.02740346 0.66145675 > 0.85629017 0.96413003 0.65755463] > [... > >when what I'd really prefer is something like > >[[ 1. 0.714 0.012 -0.906 0.027 0.661 0.856 0.964 0.658] > [... > >Specifically, I'd like to get > - less wide floating-point numbers > > > - more entries per line > > Try: scipy.set_printoptions(precision=4, linewidth=100) -Travis From oliphant.travis at ieee.org Sun Dec 25 01:05:39 2005 From: oliphant.travis at ieee.org (Travis Oliphant) Date: Sat, 24 Dec 2005 23:05:39 -0700 Subject: [SciPy-user] Building scipy_core 0.6.1 and 0.8.4 from source fails on Windows XP Pro / cygwin In-Reply-To: <6.2.1.2.2.20051221090832.05a1bd70@mail.llnl.gov> References: <6.2.1.2.2.20051221090832.05a1bd70@mail.llnl.gov> Message-ID: <43AE36B3.4090301@ieee.org> George Christianson wrote: >Good morning, > I tried to build scipy_core versions 0.6.1 and 0.8.4 from SourceForge >sources. My platform runs Windows XP version 2002, service pack 2, with a >4 processor 3GHZ pentium. I build under cygwin 1.5.18, gcc version 3.4.4, >python 2.4.1. In each of the two versions, I unpacked the gzipped source >files and ran 'python setup.py build. In eack case, the builds proceeded >normally until this point: > > These errors are due to the fact that cygwin support is not present yet. The section of code that handles the IEEE flags is platform dependent. I borrowed numarray's work for several platforms and made sure that mingw32 worked (since that is what I use to compile on Windows). However, I don't know the right combination of detection and include files to use for cygwin. It should be possible and not a difficult thing to do. Look in base/include/scipy/ufuncobject.h for examples of the platform dependent ifdef statements. -Travis From oliphant.travis at ieee.org Sun Dec 25 05:18:45 2005 From: oliphant.travis at ieee.org (Travis Oliphant) Date: Sun, 25 Dec 2005 03:18:45 -0700 Subject: [SciPy-user] Packaging Changes to Core in SVN Message-ID: <43AE7205.3050807@ieee.org> Hi folks and Merry Christmas, I hope this is the last of the major changes to the scipy core structure. After playing around with various alternative homes for the fft, linear algebra, and random number routines, I think (with Robert's suggestiong) we've found a permanent home for them under scipy.corefft scipy.corelinalg scipy.corerandom In these packages we will try to import the full scipy versions of any routines (fft and inv in particular) so that full scipy installs can have improved (but possibly difficult to install) versions of these basic routines. I am of a mind to get rid of lib out of scipy_core and move mtrand to scipy. Then move dotblas to base and be done with the lib directory in scipy_core. I'm beginning to see the wisdom in "flat is better than nested" If we can get the any wrinkles out of the new structure, I'd like to make another release after the new year so that the improved packaging can start getting used. Best, -Travis From robert.kern at gmail.com Sun Dec 25 22:29:55 2005 From: robert.kern at gmail.com (Robert Kern) Date: Sun, 25 Dec 2005 22:29:55 -0500 Subject: [SciPy-user] Packaging Changes to Core in SVN In-Reply-To: <43AE7205.3050807@ieee.org> References: <43AE7205.3050807@ieee.org> Message-ID: <43AF63B3.5050901@gmail.com> Travis Oliphant wrote: > Hi folks and Merry Christmas, > > I hope this is the last of the major changes to the scipy core > structure. After playing around with various alternative homes for the > fft, linear algebra, and random number routines, I think (with Robert's > suggestiong) we've found a permanent home for them under > > scipy.corefft > scipy.corelinalg > scipy.corerandom We don't have any "enhanced" scipy.random, so I think we can leave the scipy_core version as scipy.random. I think that anything that might fit into there in full scipy will either deserve its own subpackage (scipy.mcmc, scipy.aesprng) or will fit comfortably into scipy.stats. We only moved it under scipy.basic because it was an "orphan" module rather than a package. That's no longer a problem. -- Robert Kern robert.kern at gmail.com "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter From oliphant.travis at ieee.org Sun Dec 25 23:00:37 2005 From: oliphant.travis at ieee.org (Travis Oliphant) Date: Sun, 25 Dec 2005 21:00:37 -0700 Subject: [SciPy-user] Packaging Changes to Core in SVN In-Reply-To: <43AF63B3.5050901@gmail.com> References: <43AE7205.3050807@ieee.org> <43AF63B3.5050901@gmail.com> Message-ID: <43AF6AE5.7080006@ieee.org> Robert Kern wrote: >Travis Oliphant wrote: > > >>Hi folks and Merry Christmas, >> >>I hope this is the last of the major changes to the scipy core >>structure. After playing around with various alternative homes for the >>fft, linear algebra, and random number routines, I think (with Robert's >>suggestiong) we've found a permanent home for them under >> >>scipy.corefft >>scipy.corelinalg >>scipy.corerandom >> >> > >We don't have any "enhanced" scipy.random, so I think we can leave the >scipy_core version as scipy.random. I think that anything that might fit into >there in full scipy will either deserve its own subpackage (scipy.mcmc, >scipy.aesprng) or will fit comfortably into scipy.stats. We only moved it under >scipy.basic because it was an "orphan" module rather than a package. That's no >longer a problem. > > > That's probably a good idea. Although there's a certain symmetry to the naming in SVN, I'm not wedded to it. I think keeping it a package is a good idea for now so we can possibly move mtrand underneath it and get rid of lib from scipy_core. I'm waiting for more feedback on that idea before doing anything though. -Travis From robert.kern at gmail.com Sun Dec 25 23:17:40 2005 From: robert.kern at gmail.com (Robert Kern) Date: Sun, 25 Dec 2005 23:17:40 -0500 Subject: [SciPy-user] Packaging Changes to Core in SVN In-Reply-To: <43AF6AE5.7080006@ieee.org> References: <43AE7205.3050807@ieee.org> <43AF63B3.5050901@gmail.com> <43AF6AE5.7080006@ieee.org> Message-ID: <43AF6EE4.2090902@gmail.com> Travis Oliphant wrote: > Robert Kern wrote: > >>Travis Oliphant wrote: >> >>>Hi folks and Merry Christmas, >>> >>>I hope this is the last of the major changes to the scipy core >>>structure. After playing around with various alternative homes for the >>>fft, linear algebra, and random number routines, I think (with Robert's >>>suggestiong) we've found a permanent home for them under >>> >>>scipy.corefft >>>scipy.corelinalg >>>scipy.corerandom >> >>We don't have any "enhanced" scipy.random, so I think we can leave the >>scipy_core version as scipy.random. I think that anything that might fit into >>there in full scipy will either deserve its own subpackage (scipy.mcmc, >>scipy.aesprng) or will fit comfortably into scipy.stats. We only moved it under >>scipy.basic because it was an "orphan" module rather than a package. That's no >>longer a problem. > > That's probably a good idea. Although there's a certain symmetry to the > naming in SVN, I'm not wedded to it. I think keeping it a package is a > good idea for now so we can possibly move mtrand underneath it and get > rid of lib from scipy_core. I'm waiting for more feedback on that idea > before doing anything though. Oh yes, keep it as a package. It should just be named scipy.random, not scipy.corerandom since it isn't at all analogous to the other two packages. -- Robert Kern robert.kern at gmail.com "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter From oliphant.travis at ieee.org Mon Dec 26 01:05:32 2005 From: oliphant.travis at ieee.org (Travis E. Oliphant) Date: Sun, 25 Dec 2005 23:05:32 -0700 Subject: [SciPy-user] mixing scipy and Numeric In-Reply-To: <43A88362.3050501@hoc.net> References: <43A88362.3050501@hoc.net> Message-ID: Christian Kristukat wrote: > Hi, > again I've got problems with old code that relies on Numeric when imported in > some other program that uses scipy_core. > Numeric.log10 has problems with a type called > . > A ValueError is raised when passing a variable of that type. The strange thing > is that that variable has been created by pure Numeric code. > Where does that type belong to? scipy or Numeric or plain python? What does the > suffix _arrtype suggest since it seems to be an ordinary float? > This type definitely belongs to scipy_core. Scipy_core contains array scalars which are special scalars that have the methods and attributes of arrays but inherit from Python scalars where they can. You get one whenever you access the elements of an array. Here, the float64 should act like a Python float (because it inherits from it). On my system Numeric.log10 works fine with these array scalars, so perhaps something else is causing the problem. -Travis From oliphant.travis at ieee.org Mon Dec 26 04:00:20 2005 From: oliphant.travis at ieee.org (Travis Oliphant) Date: Mon, 26 Dec 2005 02:00:20 -0700 Subject: [SciPy-user] Example of power of new data-type descriptors. Message-ID: <43AFB124.9060507@ieee.org> I'd like more people to know about the new power that is in scipy core due to the general data-type descriptors that can now be used to define numeric arrays. Towards that effort here is a simple example (be sure to use latest SVN -- there were a coupld of minor changes that improve usability made recently). Notice this example does not use a special "record" array subclass. This is just a regular array. I'm kind of intrigued (though not motivated to pursue) the possibility of accessing (or defining) databases directly into scipy_core arrays using the record functionality. # Define a new data-type descriptor >>> import scipy >>> dtype = scipy.dtypedescr({'names': ['name', 'age', 'weight'], 'formats': ['S30', 'i2', 'f4']}) >>> a = scipy.array([('Bill',31,260),('Fred',15,135)], dtype=dtype) # the argument to dtypedescr could have also been placed here as the argument to dtype >>> print a['name'] [Bill Fred] >>> print a['age'] [31 15] >>> print a['weight'] [ 260. 135.] >>> print a[0] ('Bill', 31, 260.0) >>> print a[1] ('Fred', 15, 135.0) It seems to me there are some very interesting possibilities with this new ability. The record array subclass adds an improved scalar type (the record) and attribute access to get at the fields: (e.g. a.name, a.age, and a.weight). But, if you don't need attribute access you can use regular arrays to do a lot of what you might need a record array to accomplish for you. I'd love to see what people come up with using this new facility. The new array PEP for Python basically proposes adding a very simple array object (just the basic PyArrayObject * of Numeric with a bare-bones type-object table) plus this new data-type descriptor object to Python and a very few builtin data-type descriptors (perhaps just object initially). This would basically add the array interface to Python directly and allow people to start using it generally. The PEP is slow going because it is not on my priority list right now because it is not essential to making scipy_core work well. But, I would love to have more people ruminating on the basic ideas which I think are crystallizing. Best wishes for a new year, -Travis Oliphant From evan at monroig.net Mon Dec 26 05:14:00 2005 From: evan at monroig.net (Evan Monroig) Date: Mon, 26 Dec 2005 19:14:00 +0900 Subject: [SciPy-user] scipy install on mac os x Message-ID: Hi, summary: almost successful install on Tiger, only clapack/cblas/fftpack seem not to work properly I have already installed scipy on my linux box, and now I am trying also to use it on a Mac Os X Tiger. I followed the recent discussions on the mailing list, and tried to use them and here is my experience. 1) I used the python2.4.1 mac installer from here http://python.org/ftp/python/2.4.1/MacPython-OSX-2.4.1-1.dmg 2) I used the python2.4 fix for Tiger http://pythonmac.org/packages/TigerPython24Fix-r2.zip 3) I changed my path so that /usr/local/bin appears before /usr/bin (the objective being that launching "python" in the shell goes to python2.4 and not python2.3) 4) I used the 4 installers provided by on http://trichech.us/mac http://fisher.forestry.uga.edu/files/scipy_core-0.8.6.1693-py2.4-macosx10.4.dmg http://fisher.forestry.uga.edu/files/scipy-0.4.3.1493-py2.4-macosx10.4.dmg http://fisher.forestry.uga.edu/files/matplotlib-0.85.1.cvs.dmg http://fisher.forestry.uga.edu/files/numarray-1.5.0.dmg One possible concern is that they were built for python2.4.2 and not python2.4.1 but I think this should not pose problems 5) I ran the tests in the command line: ---- EvanL:~ evanmonroig$ python Python 2.4.1 (#2, Mar 31 2005, 00:05:10) [GCC 3.3 20030304 (Apple Computer, Inc. build 1666)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> from scipy import * >>> test() [.....] Ran 1372 tests in 8.686s FAILED (failures=11) ---- I put all details in the attached files, but to sum up the failures are mostly due to: a) clapack module is empty b) cblas module is empty c) fftpack gives wrong results Any thoughts? Should I install the lapack and blas library by myself, or are they already on my system (it is likely so because I previously installed Octave)? Thanks, Evan -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: MACOS10.4 Scipy Test.txt URL: From a.h.jaffe at gmail.com Mon Dec 26 05:21:39 2005 From: a.h.jaffe at gmail.com (Andrew Jaffe) Date: Mon, 26 Dec 2005 10:21:39 +0000 Subject: [SciPy-user] output formatting of scipy arrays In-Reply-To: <43AE3C3E.8050007@ieee.org> References: <43AE3C3E.8050007@ieee.org> Message-ID: Travis- Travis Oliphant wrote: > Andrew Jaffe wrote: >> >>Sorry as usual if this is a faq, but is there any easy way to change the >>way arrays appear when printed (presumably, this means affecting the >>behavior of __str__?). >> >>Currently, I get things like >> >>[[ 1. 0.71375029 0.01215192 -0.90644004 0.02740346 0.66145675 >> 0.85629017 0.96413003 0.65755463] >> [... >> >>when what I'd really prefer is something like >> >>[[ 1. 0.714 0.012 -0.906 0.027 0.661 0.856 0.964 0.658] >> [... >> >>Specifically, I'd like to get >> - less wide floating-point numbers >> - more entries per line > > Try: > > scipy.set_printoptions(precision=4, linewidth=100) > Exactly what I was looking for. Brilliant... OK, you've convinced me to buy the book. Happy Hannukah, Christmas, Kwanzaa, etc! A From pajer at iname.com Mon Dec 26 22:55:46 2005 From: pajer at iname.com (Gary) Date: Mon, 26 Dec 2005 22:55:46 -0500 Subject: [SciPy-user] WinXP python 2.4.2 upgrade: scipy build fails In-Reply-To: <43AFB124.9060507@ieee.org> References: <43AFB124.9060507@ieee.org> Message-ID: <43B0BB42.6030307@iname.com> I'm upgrading from python 2.3 to 2.4.2. I refreshed my svn's, deleted the previous build directories. scipy_core installed fine. scipy fails. What did I do wrong? (one thing: I didn't try the latest scipy with the old python before changing both at the same time :) ) -gary -------------------------------------------------- C:\Documents and Settings\Gary\My Documents\python\scipy\svn>python setup.py con fig --compiler=mingw32 build --compiler=mingw32 install Skip importing scipy packages (NO_SCIPY_IMPORT=SciPy/setup.py) Appending scipy.sandbox configuration to scipy Assuming default configuration (Lib\utils/{setup_utils,setup}.py was not found) Appending scipy.utils configuration to scipy Appending scipy.io configuration to scipy fftw_info: fftw3 not found fftw2 not found NOT AVAILABLE dfftw_info: dfftw not found NOT AVAILABLE FFTW (http://www.fftw.org/) libraries not found. Directories to search for the libraries can be specified in the scipy_distutils/site.cfg file (section [fftw]) or by setting the FFTW environment variable. djbfft_info: NOT AVAILABLE DJBFFT (http://cr.yp.to/djbfft.html) libraries not found. Directories to search for the libraries can be specified in the scipy_distutils/site.cfg file (section [djbfft]) or by setting the DJBFFT environment variable. Appending scipy.fftpack configuration to scipy Appending scipy.signal configuration to scipy blas_opt_info: blas_mkl_info: NOT AVAILABLE atlas_blas_threads_info: Setting PTATLAS=ATLAS NOT AVAILABLE atlas_blas_info: NOT AVAILABLE c:\python24\lib\site-packages\scipy\distutils\system_info.py:1174: UserWarning: Atlas (http://math-atlas.sourceforge.net/) libraries not found. Directories to search for the libraries can be specified in the scipy_distutils/site.cfg file (section [atlas]) or by setting the ATLAS environment variable. warnings.warn(AtlasNotFoundError.__doc__) blas_info: NOT AVAILABLE c:\python24\lib\site-packages\scipy\distutils\system_info.py:1183: UserWarning: Blas (http://www.netlib.org/blas/) libraries not found. Directories to search for the libraries can be specified in the scipy_distutils/site.cfg file (section [blas]) or by setting the BLAS environment variable. warnings.warn(BlasNotFoundError.__doc__) blas_src_info: NOT AVAILABLE c:\python24\lib\site-packages\scipy\distutils\system_info.py:1186: UserWarning: Blas (http://www.netlib.org/blas/) sources not found. Directories to search for the sources can be specified in the scipy_distutils/site.cfg file (section [blas_src]) or by setting the BLAS_SRC environment variable. warnings.warn(BlasSrcNotFoundError.__doc__) Traceback (most recent call last): File "setup.py", line 42, in ? setup_package() File "setup.py", line 28, in setup_package config.add_subpackage('Lib') File "c:\python24\Lib\site-packages\scipy\distutils\misc_util.py", line 399, i n add_subpackage config = self.get_subpackage(subpackage_name,subpackage_path) File "c:\python24\Lib\site-packages\scipy\distutils\misc_util.py", line 389, i n get_subpackage config = setup_module.configuration(*args) File "C:\Documents and Settings\Gary\My Documents\python\scipy\svn\Lib\setup.p y", line 10, in configuration config.add_subpackage('integrate') File "c:\python24\Lib\site-packages\scipy\distutils\misc_util.py", line 399, i n add_subpackage config = self.get_subpackage(subpackage_name,subpackage_path) File "c:\python24\Lib\site-packages\scipy\distutils\misc_util.py", line 389, i n get_subpackage config = setup_module.configuration(*args) File "Lib\integrate\setup.py", line 11, in configuration blas_opt = get_info('blas_opt',notfound_action=2) File "c:\python24\Lib\site-packages\scipy\distutils\system_info.py", line 200, in get_info return cl().get_info(notfound_action) File "c:\python24\Lib\site-packages\scipy\distutils\system_info.py", line 348, in get_info raise self.notfounderror,self.notfounderror.__doc__ scipy.distutils.system_info.NotFoundError: Some third-party program or library i s not found. C:\Documents and Settings\Gary\My Documents\python\scipy\svn>python setup.py con fig --compiler=mingw32 build --compiler=mingw32 install Skip importing scipy packages (NO_SCIPY_IMPORT=SciPy/setup.py) Appending scipy.sandbox configuration to scipy Assuming default configuration (Lib\utils/{setup_utils,setup}.py was not found) Appending scipy.utils configuration to scipy Appending scipy.io configuration to scipy fftw_info: fftw3 not found fftw2 not found NOT AVAILABLE dfftw_info: dfftw not found NOT AVAILABLE FFTW (http://www.fftw.org/) libraries not found. Directories to search for the libraries can be specified in the scipy_distutils/site.cfg file (section [fftw]) or by setting the FFTW environment variable. djbfft_info: NOT AVAILABLE DJBFFT (http://cr.yp.to/djbfft.html) libraries not found. Directories to search for the libraries can be specified in the scipy_distutils/site.cfg file (section [djbfft]) or by setting the DJBFFT environment variable. Appending scipy.fftpack configuration to scipy Appending scipy.signal configuration to scipy blas_opt_info: blas_mkl_info: NOT AVAILABLE atlas_blas_threads_info: Setting PTATLAS=ATLAS NOT AVAILABLE atlas_blas_info: NOT AVAILABLE c:\python24\lib\site-packages\scipy\distutils\system_info.py:1174: UserWarning: Atlas (http://math-atlas.sourceforge.net/) libraries not found. Directories to search for the libraries can be specified in the scipy_distutils/site.cfg file (section [atlas]) or by setting the ATLAS environment variable. warnings.warn(AtlasNotFoundError.__doc__) blas_info: NOT AVAILABLE c:\python24\lib\site-packages\scipy\distutils\system_info.py:1183: UserWarning: Blas (http://www.netlib.org/blas/) libraries not found. Directories to search for the libraries can be specified in the scipy_distutils/site.cfg file (section [blas]) or by setting the BLAS environment variable. warnings.warn(BlasNotFoundError.__doc__) blas_src_info: NOT AVAILABLE c:\python24\lib\site-packages\scipy\distutils\system_info.py:1186: UserWarning: Blas (http://www.netlib.org/blas/) sources not found. Directories to search for the sources can be specified in the scipy_distutils/site.cfg file (section [blas_src]) or by setting the BLAS_SRC environment variable. warnings.warn(BlasSrcNotFoundError.__doc__) Traceback (most recent call last): File "setup.py", line 42, in ? setup_package() File "setup.py", line 28, in setup_package config.add_subpackage('Lib') File "c:\python24\Lib\site-packages\scipy\distutils\misc_util.py", line 399, i n add_subpackage config = self.get_subpackage(subpackage_name,subpackage_path) File "c:\python24\Lib\site-packages\scipy\distutils\misc_util.py", line 389, i n get_subpackage config = setup_module.configuration(*args) File "C:\Documents and Settings\Gary\My Documents\python\scipy\svn\Lib\setup.p y", line 10, in configuration config.add_subpackage('integrate') File "c:\python24\Lib\site-packages\scipy\distutils\misc_util.py", line 399, i n add_subpackage config = self.get_subpackage(subpackage_name,subpackage_path) File "c:\python24\Lib\site-packages\scipy\distutils\misc_util.py", line 389, i n get_subpackage config = setup_module.configuration(*args) File "Lib\integrate\setup.py", line 11, in configuration blas_opt = get_info('blas_opt',notfound_action=2) File "c:\python24\Lib\site-packages\scipy\distutils\system_info.py", line 200, in get_info return cl().get_info(notfound_action) File "c:\python24\Lib\site-packages\scipy\distutils\system_info.py", line 348, in get_info raise self.notfounderror,self.notfounderror.__doc__ scipy.distutils.system_info.NotFoundError: Some third-party program or library i s not found. From oliphant.travis at ieee.org Mon Dec 26 23:31:58 2005 From: oliphant.travis at ieee.org (Travis Oliphant) Date: Mon, 26 Dec 2005 21:31:58 -0700 Subject: [SciPy-user] WinXP python 2.4.2 upgrade: scipy build fails In-Reply-To: <43B0BB42.6030307@iname.com> References: <43AFB124.9060507@ieee.org> <43B0BB42.6030307@iname.com> Message-ID: <43B0C3BE.9070006@ieee.org> Gary wrote: >I'm upgrading from python 2.3 to 2.4.2. > >I refreshed my svn's, deleted the previous build directories. > >scipy_core installed fine. scipy fails. What did I do wrong? >(one thing: I didn't try the latest scipy with the old python before >changing both at the same time :) ) > >-gary > > >-------------------------------------------------- >C:\Documents and Settings\Gary\My Documents\python\scipy\svn>python >setup.py con >fig --compiler=mingw32 build --compiler=mingw32 install >Skip importing scipy packages (NO_SCIPY_IMPORT=SciPy/setup.py) >Appending scipy.sandbox configuration to scipy >Assuming default configuration (Lib\utils/{setup_utils,setup}.py was not >found) >Appending scipy.utils configuration to scipy >Appending scipy.io configuration to scipy >fftw_info: > fftw3 not found > fftw2 not found > NOT AVAILABLE > >dfftw_info: > dfftw not found > NOT AVAILABLE > > > FFTW (http://www.fftw.org/) libraries not found. > Directories to search for the libraries can be specified in the > scipy_distutils/site.cfg file (section [fftw]) or by setting > the FFTW environment variable. >djbfft_info: > NOT AVAILABLE > > > DJBFFT (http://cr.yp.to/djbfft.html) libraries not found. > Directories to search for the libraries can be specified in the > scipy_distutils/site.cfg file (section [djbfft]) or by setting > the DJBFFT environment variable. >Appending scipy.fftpack configuration to scipy >Appending scipy.signal configuration to scipy >blas_opt_info: >blas_mkl_info: > NOT AVAILABLE > >atlas_blas_threads_info: >Setting PTATLAS=ATLAS > NOT AVAILABLE > >atlas_blas_info: > NOT AVAILABLE > >c:\python24\lib\site-packages\scipy\distutils\system_info.py:1174: >UserWarning: > > Atlas (http://math-atlas.sourceforge.net/) libraries not found. > Directories to search for the libraries can be specified in the > scipy_distutils/site.cfg file (section [atlas]) or by setting > the ATLAS environment variable. > warnings.warn(AtlasNotFoundError.__doc__) >blas_info: > NOT AVAILABLE > >c:\python24\lib\site-packages\scipy\distutils\system_info.py:1183: >UserWarning: > > Blas (http://www.netlib.org/blas/) libraries not found. > Directories to search for the libraries can be specified in the > scipy_distutils/site.cfg file (section [blas]) or by setting > the BLAS environment variable. > warnings.warn(BlasNotFoundError.__doc__) >blas_src_info: > NOT AVAILABLE > >c:\python24\lib\site-packages\scipy\distutils\system_info.py:1186: >UserWarning: > > Blas (http://www.netlib.org/blas/) sources not found. > Directories to search for the sources can be specified in the > scipy_distutils/site.cfg file (section [blas_src]) or by setting > the BLAS_SRC environment variable. > warnings.warn(BlasSrcNotFoundError.__doc__) >Traceback (most recent call last): > File "setup.py", line 42, in ? > setup_package() > File "setup.py", line 28, in setup_package > config.add_subpackage('Lib') > File "c:\python24\Lib\site-packages\scipy\distutils\misc_util.py", >line 399, i >n add_subpackage > config = self.get_subpackage(subpackage_name,subpackage_path) > File "c:\python24\Lib\site-packages\scipy\distutils\misc_util.py", >line 389, i >n get_subpackage > config = setup_module.configuration(*args) > File "C:\Documents and Settings\Gary\My >Documents\python\scipy\svn\Lib\setup.p >y", line 10, in configuration > config.add_subpackage('integrate') > File "c:\python24\Lib\site-packages\scipy\distutils\misc_util.py", >line 399, i >n add_subpackage > config = self.get_subpackage(subpackage_name,subpackage_path) > File "c:\python24\Lib\site-packages\scipy\distutils\misc_util.py", >line 389, i >n get_subpackage > config = setup_module.configuration(*args) > File "Lib\integrate\setup.py", line 11, in configuration > blas_opt = get_info('blas_opt',notfound_action=2) > File "c:\python24\Lib\site-packages\scipy\distutils\system_info.py", >line 200, > in get_info > return cl().get_info(notfound_action) > File "c:\python24\Lib\site-packages\scipy\distutils\system_info.py", >line 348, > in get_info > raise self.notfounderror,self.notfounderror.__doc__ >scipy.distutils.system_info.NotFoundError: Some third-party program or >library i >s not found. > >C:\Documents and Settings\Gary\My Documents\python\scipy\svn>python >setup.py con >fig --compiler=mingw32 build --compiler=mingw32 install >Skip importing scipy packages (NO_SCIPY_IMPORT=SciPy/setup.py) >Appending scipy.sandbox configuration to scipy >Assuming default configuration (Lib\utils/{setup_utils,setup}.py was not >found) >Appending scipy.utils configuration to scipy >Appending scipy.io configuration to scipy >fftw_info: > fftw3 not found > fftw2 not found > NOT AVAILABLE > >dfftw_info: > dfftw not found > NOT AVAILABLE > > > FFTW (http://www.fftw.org/) libraries not found. > Directories to search for the libraries can be specified in the > scipy_distutils/site.cfg file (section [fftw]) or by setting > the FFTW environment variable. >djbfft_info: > NOT AVAILABLE > > > DJBFFT (http://cr.yp.to/djbfft.html) libraries not found. > Directories to search for the libraries can be specified in the > scipy_distutils/site.cfg file (section [djbfft]) or by setting > the DJBFFT environment variable. >Appending scipy.fftpack configuration to scipy >Appending scipy.signal configuration to scipy >blas_opt_info: >blas_mkl_info: > NOT AVAILABLE > >atlas_blas_threads_info: >Setting PTATLAS=ATLAS > NOT AVAILABLE > >atlas_blas_info: > NOT AVAILABLE > >c:\python24\lib\site-packages\scipy\distutils\system_info.py:1174: >UserWarning: > > Atlas (http://math-atlas.sourceforge.net/) libraries not found. > Directories to search for the libraries can be specified in the > scipy_distutils/site.cfg file (section [atlas]) or by setting > the ATLAS environment variable. > warnings.warn(AtlasNotFoundError.__doc__) >blas_info: > NOT AVAILABLE > >c:\python24\lib\site-packages\scipy\distutils\system_info.py:1183: >UserWarning: > > Blas (http://www.netlib.org/blas/) libraries not found. > Directories to search for the libraries can be specified in the > scipy_distutils/site.cfg file (section [blas]) or by setting > the BLAS environment variable. > warnings.warn(BlasNotFoundError.__doc__) >blas_src_info: > NOT AVAILABLE > >c:\python24\lib\site-packages\scipy\distutils\system_info.py:1186: >UserWarning: > > Blas (http://www.netlib.org/blas/) sources not found. > Directories to search for the sources can be specified in the > scipy_distutils/site.cfg file (section [blas_src]) or by setting > the BLAS_SRC environment variable. > warnings.warn(BlasSrcNotFoundError.__doc__) >Traceback (most recent call last): > File "setup.py", line 42, in ? > setup_package() > File "setup.py", line 28, in setup_package > config.add_subpackage('Lib') > File "c:\python24\Lib\site-packages\scipy\distutils\misc_util.py", >line 399, i >n add_subpackage > config = self.get_subpackage(subpackage_name,subpackage_path) > File "c:\python24\Lib\site-packages\scipy\distutils\misc_util.py", >line 389, i >n get_subpackage > config = setup_module.configuration(*args) > File "C:\Documents and Settings\Gary\My >Documents\python\scipy\svn\Lib\setup.p >y", line 10, in configuration > config.add_subpackage('integrate') > File "c:\python24\Lib\site-packages\scipy\distutils\misc_util.py", >line 399, i >n add_subpackage > config = self.get_subpackage(subpackage_name,subpackage_path) > File "c:\python24\Lib\site-packages\scipy\distutils\misc_util.py", >line 389, i >n get_subpackage > config = setup_module.configuration(*args) > File "Lib\integrate\setup.py", line 11, in configuration > blas_opt = get_info('blas_opt',notfound_action=2) > File "c:\python24\Lib\site-packages\scipy\distutils\system_info.py", >line 200, > in get_info > return cl().get_info(notfound_action) > File "c:\python24\Lib\site-packages\scipy\distutils\system_info.py", >line 348, > in get_info > raise self.notfounderror,self.notfounderror.__doc__ >scipy.distutils.system_info.NotFoundError: Some third-party program or >library i >s not found. > >_______________________________________________ >SciPy-user mailing list >SciPy-user at scipy.net >http://www.scipy.net/mailman/listinfo/scipy-user > > From oliphant.travis at ieee.org Mon Dec 26 23:37:10 2005 From: oliphant.travis at ieee.org (Travis Oliphant) Date: Mon, 26 Dec 2005 21:37:10 -0700 Subject: [SciPy-user] WinXP python 2.4.2 upgrade: scipy build fails In-Reply-To: <43B0BB42.6030307@iname.com> References: <43AFB124.9060507@ieee.org> <43B0BB42.6030307@iname.com> Message-ID: <43B0C4F6.8070403@ieee.org> Gary wrote: >I'm upgrading from python 2.3 to 2.4.2. > >I refreshed my svn's, deleted the previous build directories. > >scipy_core installed fine. > Let's emphasize this part lest people confuse full scipy install difficulties with sicpy_core install difficulties :-) >scipy fails. What did I do wrong? >(one thing: I didn't try the latest scipy with the old python before >changing both at the same time :) ) > > That shouldn't matter. What BLAS libraries are you using for scipy. It looks like scipy is not finding your blas and/or lapack libraries. SciPy core can use them but does not require them. Full SciPy, however, requires them. -Travis >c:\python24\lib\site-packages\scipy\distutils\system_info.py:1174: >UserWarning: > > Atlas (http://math-atlas.sourceforge.net/) libraries not found. > Directories to search for the libraries can be specified in the > scipy_distutils/site.cfg file (section [atlas]) or by setting > the ATLAS environment variable. > warnings.warn(AtlasNotFoundError.__doc__) >blas_info: > NOT AVAILABLE > >c:\python24\lib\site-packages\scipy\distutils\system_info.py:1183: >UserWarning: > > Blas (http://www.netlib.org/blas/) libraries not found. > Directories to search for the libraries can be specified in the > scipy_distutils/site.cfg file (section [blas]) or by setting > the BLAS environment variable. > warnings.warn(BlasNotFoundError.__doc__) >blas_src_info: > NOT AVAILABLE > >c:\python24\lib\site-packages\scipy\distutils\system_info.py:1186: >UserWarning: > > Blas (http://www.netlib.org/blas/) sources not found. > Directories to search for the sources can be specified in the > scipy_distutils/site.cfg file (section [blas_src]) or by setting > the BLAS_SRC environment variable. > > These warnings indicate that no blas can be found. You need some BLAS library for full scipy. Even the sources from netlib would be something but most really want a faster BLAS for their system. There are similar warnings for LAPACK, I think. Make sure you have some BLAS and LAPACK installed (like ATLAS), and then try to install full scipy again. -Travis From pajer at iname.com Tue Dec 27 10:11:10 2005 From: pajer at iname.com (Gary) Date: Tue, 27 Dec 2005 10:11:10 -0500 Subject: [SciPy-user] WinXP python 2.4.2 upgrade: scipy build fails In-Reply-To: <43B0C4F6.8070403@ieee.org> References: <43AFB124.9060507@ieee.org> <43B0BB42.6030307@iname.com> <43B0C4F6.8070403@ieee.org> Message-ID: <43B1598E.9050603@iname.com> Travis Oliphant wrote: >Gary wrote: > > > >>I'm upgrading from python 2.3 to 2.4.2. >> >>I refreshed my svn's, deleted the previous build directories. >> >>scipy_core installed fine. >> >> >> >Let's emphasize this part lest people confuse full scipy install >difficulties with sicpy_core install difficulties :-) > > > >>scipy fails. What did I do wrong? >>(one thing: I didn't try the latest scipy with the old python before >>changing both at the same time :) ) >> >> >> >> >That shouldn't matter. > >What BLAS libraries are you using for scipy. It looks like scipy is not >finding your blas and/or lapack libraries. SciPy core can use them but >does not require them. Full SciPy, however, requires them. > >-Travis > > > Thanks for you patience. Everything works this morning after starting from scratch. By now, with your gentle prodding, I should know better. The only thing I can think of was that I must have had a typo in my ATLAS environment variable. I set it by hand in the command window each time I recompile. The reason I do it that way is that I need ATLAS *only* when compiling scipy, so I define it only when needed, rather than have it cluttering up the space. Obviously, there is danger of making a mistake this way. But I did learn something: atlas is not needed for scipy_core. If I had figured that out, I would have figured out my problem. sorry about the noise, -gary > > >>c:\python24\lib\site-packages\scipy\distutils\system_info.py:1174: >>UserWarning: >> >> Atlas (http://math-atlas.sourceforge.net/) libraries not found. >> Directories to search for the libraries can be specified in the >> scipy_distutils/site.cfg file (section [atlas]) or by setting >> the ATLAS environment variable. >> warnings.warn(AtlasNotFoundError.__doc__) >>blas_info: >> NOT AVAILABLE >> >>c:\python24\lib\site-packages\scipy\distutils\system_info.py:1183: >>UserWarning: >> >> Blas (http://www.netlib.org/blas/) libraries not found. >> Directories to search for the libraries can be specified in the >> scipy_distutils/site.cfg file (section [blas]) or by setting >> the BLAS environment variable. >> warnings.warn(BlasNotFoundError.__doc__) >>blas_src_info: >> NOT AVAILABLE >> >>c:\python24\lib\site-packages\scipy\distutils\system_info.py:1186: >>UserWarning: >> >> Blas (http://www.netlib.org/blas/) sources not found. >> Directories to search for the sources can be specified in the >> scipy_distutils/site.cfg file (section [blas_src]) or by setting >> the BLAS_SRC environment variable. >> >> >> >> > >These warnings indicate that no blas can be found. You need some BLAS >library for full scipy. Even the sources from netlib would be something >but most really want a faster BLAS for their system. > >There are similar warnings for LAPACK, I think. Make sure you have some >BLAS and LAPACK installed (like ATLAS), and then try to install full >scipy again. > >-Travis > >_______________________________________________ >SciPy-user mailing list >SciPy-user at scipy.net >http://www.scipy.net/mailman/listinfo/scipy-user > > > From rshepard at appl-ecosys.com Tue Dec 27 19:55:47 2005 From: rshepard at appl-ecosys.com (Rich Shepard) Date: Tue, 27 Dec 2005 16:55:47 -0800 (PST) Subject: [SciPy-user] Manipulating Bit-Masked Data Message-ID: I need to read bit-masked bytes from an Optical Mark Recognition card reader. I'm quite new to Python and haven't found any documentation on how to manipulate bits. NumPy has masked arrays, but that's a different situation. My rummaging around the SciPy wiki and a search of the mail list archives turned up nothing. I'd appreciate a pointer to documentation that will show me how to manipulate bit-masks in Python. Thanks, Rich -- Richard B. Shepard, Ph.D. | Author of "Quantifying Environmental Applied Ecosystem Services, Inc. (TM) | Impact Assessments Using Fuzzy Logic" Voice: 503-667-4517 Fax: 503-667-8863 From oliphant.travis at ieee.org Tue Dec 27 23:17:09 2005 From: oliphant.travis at ieee.org (Travis Oliphant) Date: Tue, 27 Dec 2005 21:17:09 -0700 Subject: [SciPy-user] Manipulating Bit-Masked Data In-Reply-To: References: Message-ID: <43B211C5.8060805@ieee.org> Rich Shepard wrote: > I need to read bit-masked bytes from an Optical Mark Recognition card >reader. I'm quite new to Python and haven't found any documentation on how to >manipulate bits. NumPy has masked arrays, but that's a different situation. >My rummaging around the SciPy wiki and a search of the mail list archives >turned up nothing. > > I'd appreciate a pointer to documentation that will show me how to >manipulate bit-masks in Python. > > > There are not intrinsic bit-fields in scipy, but you can easily access bits of interest using an integer type, bit-masks, and the bit-operators. >> (right-shift) << (left-shift) & (bit-wise and) | (bit-wise or) ^ (bit-wise xor) Then: bit0 = 1 bit1 = 2 bit2 = 4 bit3 = 8 bit4 = 16 bit5 = 32 bit6 = 64 bit7 = 128 would give you bit masks you could check using var & bitn Perhaps you could show an example of what you would like to do. I'd love to give a more specific response. Best, -Travis From dkuhlman at cutter.rexx.com Tue Dec 27 23:18:19 2005 From: dkuhlman at cutter.rexx.com (Dave Kuhlman) Date: Tue, 27 Dec 2005 20:18:19 -0800 Subject: [SciPy-user] Manipulating Bit-Masked Data In-Reply-To: References: Message-ID: <20051228041819.GA57627@cutter.rexx.com> On Tue, Dec 27, 2005 at 04:55:47PM -0800, Rich Shepard wrote: > I need to read bit-masked bytes from an Optical Mark Recognition card > reader. I'm quite new to Python and haven't found any documentation on how to > manipulate bits. NumPy has masked arrays, but that's a different situation. > My rummaging around the SciPy wiki and a search of the mail list archives > turned up nothing. > > I'd appreciate a pointer to documentation that will show me how to > manipulate bit-masks in Python. Define your hex masks with things like 0x1f. See: http://docs.python.org/ref/integers.html. And, I believe, the bit-wise operators you want are "&", "^", and "|" (and, xor, and or). See: http://docs.python.org/ref/bitwise.html. Also, the built-in functions ord() and hex() may be useful. See: http://docs.python.org/lib/built-in-funcs.html. If you need lots of speed while doing this, you may want to look into Pyrex. But, that's an advanced topic. Hope this helps. Dave -- Dave Kuhlman http://www.rexx.com/~dkuhlman From wjdandreta at att.net Tue Dec 27 23:20:04 2005 From: wjdandreta at att.net (Bill Dandreta) Date: Tue, 27 Dec 2005 23:20:04 -0500 Subject: [SciPy-user] Manipulating Bit-Masked Data In-Reply-To: References: Message-ID: <43B21274.5050004@att.net> Rich Shepard wrote: >I'm quite new to Python and haven't found any documentation on how to >manipulate bits. > See: Python Library Reference 2.3.4.1 Bit-string Operations on Integer Types Example: >>>x=0xffff >>>y=0x0001 >>> hex(x^y) #x (exclusive or) y '0xfffe' >>> hex(x&y) #x and y '0x1' Bill From rcsqtc at iiqab.csic.es Wed Dec 28 15:27:20 2005 From: rcsqtc at iiqab.csic.es (rcsqtc at iiqab.csic.es) Date: Wed, 28 Dec 2005 20:27:20 +0000 Subject: [SciPy-user] Does the new (Travis') scipy_core need Numeric? Message-ID: <20051228202720.7FC87E14B4@limonero.csic.es> An embedded and charset-unspecified text was scrubbed... Name: not available URL: From oliphant at ee.byu.edu Wed Dec 28 18:27:09 2005 From: oliphant at ee.byu.edu (Travis Oliphant) Date: Wed, 28 Dec 2005 16:27:09 -0700 Subject: [SciPy-user] ***[Possible UCE]*** Does the new (Travis') scipy_core need Numeric? In-Reply-To: <20051228202720.7FC87E14B4@limonero.csic.es> References: <20051228202720.7FC87E14B4@limonero.csic.es> Message-ID: <43B31F4D.4060800@ee.byu.edu> rcsqtc at iiqab.csic.es wrote: >Hi all, >I may be asking a very simple question, but I could not find a clear >explanation anyware on the scipy web or the new scipy_core web. >I've installed Travis scipy_core 0.8.4, which is supposed to substitute >the Numeric package (or that's what I understood). But scipy_core does >not provide scipy.linalg, scipy.stats, etc which are still in the scipy >distribution (scipy-0.3.2 in my case). Now, reading the documentation >(and trying as well) it seems that I need Numeric to install scipy-0.3.2. >So do I need to install Numeric AND scipy_core 0.8.4? Is this because the >transition is not over yet? > > Scipy 0.3.2 requires Numeric Scipy 0.4.X requires scipy_core Right now, there is no real release of scipy 0.4.X (you have to build it from SVN). Hopefully this will change by the first of the year. I hope to get a release of scipy_core out by then with the new and improved package structure and package loader, with a release of scipy to follow. >Maybe I misunderstood something. It's a pity that the documentation is >split into two different pages: >http://numeric.scipy.org/ and http://www.scipy.org/.Thanks for your consideration, > > Agreed. The www.scipy.org is undergoing much-needed renovation. When that happens things should be more comprehensible. Right now, the numeric.scipy.org site is really the site for scipy_core / Numeric / numarray. While the www.scipy.org site is the site for (full) scipy. -Travis From rshepard at appl-ecosys.com Wed Dec 28 19:01:54 2005 From: rshepard at appl-ecosys.com (Rich Shepard) Date: Wed, 28 Dec 2005 16:01:54 -0800 (PST) Subject: [SciPy-user] Manipulating Bit-Masked Data In-Reply-To: <43B211C5.8060805@ieee.org> References: <43B211C5.8060805@ieee.org> Message-ID: On Tue, 27 Dec 2005, Travis Oliphant wrote: > There are not intrinsic bit-fields in scipy, but you can easily access bits > of interest using an integer type, bit-masks, and the bit-operators. > Perhaps you could show an example of what you would like to do. I'd love > to give a more specific response. Travis, Thanks (to you and the others who responded). I think the situation is simpler than I realized, now that I've found and read the technical manual. The point of the exercise is to read OMR (Optical Mark Recognition) cards and store the data in a SQLite database for analyses. The card has 12 rows (when held with the short ends on either side and the long sides on top and bottom). Rows are numbered from 0-12, and data are returned at two bytes. The right half of the card (rows 12, 11, 0, 1, 2, and 3 from LSB to MSB) is the first byte and the left half (rows 4, 5, 6, 7, 8, and 9) are the second byte. In both bytes, the 6th bit is forced true so the value of each byte is 32 when that "column" (or row if the card's held upright) is blank. The maximum value would be 127 if all 12 boxes are filled. So, for my needs, the byte values will tell me which boxes were filled, and I don't need to twiddle bits to get the required data. I still need to check with the vendor, but I believe that the number of two-bytes-plus-CR represent all possible "rows" on the card ("columns" in the vendor's orientation). So, by using the strobe marks to count, I can tell which bubbles were filled and associate them with the data being scored. FWIW, I'm developing the form in LaTeX which is an interesting exercise in itself. :-) Rich -- Richard B. Shepard, Ph.D. | Author of "Quantifying Environmental Applied Ecosystem Services, Inc. (TM) | Impact Assessments Using Fuzzy Logic" Voice: 503-667-4517 Fax: 503-667-8863 From schofield at ftw.at Thu Dec 29 06:20:13 2005 From: schofield at ftw.at (Ed Schofield) Date: Thu, 29 Dec 2005 11:20:13 +0000 Subject: [SciPy-user] Does the new (Travis') scipy_core need Numeric? In-Reply-To: <20051228202720.7FC87E14B4@limonero.csic.es> References: <20051228202720.7FC87E14B4@limonero.csic.es> Message-ID: <09D46B81-4F74-44C2-B04F-8F9CC6BFD059@ftw.at> Hi Ramon, The best documentation currently available for the new scipy (core and full packages) is here: http://new.scipy.org/Wiki/FrontPage Best wishes, Ed On 28/12/2005, at 8:27 PM, rcsqtc at iiqab.csic.es wrote: > Hi all, > I may be asking a very simple question, but I could not find a clear > explanation anyware on the scipy web or the new scipy_core web. > I've installed Travis scipy_core 0.8.4, which is supposed to > substitute > the Numeric package (or that's what I understood). But scipy_core does > not provide scipy.linalg, scipy.stats, etc which are still in the > scipy > distribution (scipy-0.3.2 in my case). Now, reading the documentation > (and trying as well) it seems that I need Numeric to install > scipy-0.3.2. > So do I need to install Numeric AND scipy_core 0.8.4? Is this > because the > transition is not over yet? > Maybe I misunderstood something. It's a pity that the documentation is > split into two different pages: > http://numeric.scipy.org/ and http://www.scipy.org/.Thanks for your > consideration, > Ramon > > > _______________________________________________ > SciPy-user mailing list > SciPy-user at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-user From Paul.Ray at nrl.navy.mil Thu Dec 29 10:22:38 2005 From: Paul.Ray at nrl.navy.mil (Paul Ray) Date: Thu, 29 Dec 2005 10:22:38 -0500 Subject: [SciPy-user] Bug in scipy.io.fread? Message-ID: <2C2206D5-F4DC-4A89-95F8-A36539B8AFD1@nrl.navy.mil> Hi, I've compiled scipy_core and scipy from the current (yesterday, Rev 1502) svn versions. I'm running Mac OS X 10.4.3, with a fink-installed python2.4. The new scipy builds and installs just fine, and all the unit tests I tried worked fine. However, I get a Bus Error from the following simple program: =================================================== import scipy import scipy.io print 'Opening test.dat for writing' outfile = open('test.dat', mode='wb') a = scipy.arange(1024.0,dtype='f') print 'Writing array' scipy.io.fwrite(outfile, 1024, a, 'f') print 'Closing file' outfile.close() print 'Opening test.dat for reading' infile = open('test.dat', mode='rb') print 'Reading chunk' tmpchunk = scipy.io.fread(infile, 1024, 'f') print 'Done :',tmpchunk[0:10] =================================================== Here is the run: > mcxr2 : 192>python2.4 freadtest.py > Opening test.dat for writing > Writing array > Closing file > Opening test.dat for reading > Reading chunk > Bus error The written file looks fine... > mcxr2 : 193>od -f test.dat |head > 0000000 0.000000e+00 1.000000e+00 2.000000e+00 > 3.000000e+00 > 0000020 4.000000e+00 5.000000e+00 6.000000e+00 > 7.000000e+00 > 0000040 8.000000e+00 9.000000e+00 1.000000e+01 > 1.100000e+01 > 0000060 1.200000e+01 1.300000e+01 1.400000e+01 > 1.500000e+01 > 0000100 1.600000e+01 1.700000e+01 1.800000e+01 > 1.900000e+01 > 0000120 2.000000e+01 2.100000e+01 2.200000e+01 > 2.300000e+01 > 0000140 2.400000e+01 2.500000e+01 2.600000e+01 > 2.700000e+01 > 0000160 2.800000e+01 2.900000e+01 3.000000e+01 > 3.100000e+01 > 0000200 3.200000e+01 3.300000e+01 3.400000e+01 > 3.500000e+01 > 0000220 3.600000e+01 3.700000e+01 3.800000e+01 > 3.900000e+01 Cheers, -- Paul -- Dr. Paul S. Ray E-mail: Paul.Ray at nrl.navy.mil Naval Research Laboratory WWW : http://xweb.nrl.navy.mil/ personnel/paulr/ Code 7655 Phone : (202) 404-1619 Washington, DC 20375 AIM : NRLPSR From Paul.Ray at nrl.navy.mil Thu Dec 29 10:29:27 2005 From: Paul.Ray at nrl.navy.mil (Paul Ray) Date: Thu, 29 Dec 2005 10:29:27 -0500 Subject: [SciPy-user] Where is arrayobject.h supposed to be? Message-ID: <2D1116B4-A27B-4425-9451-AADF331BF699@nrl.navy.mil> Hi, I've compiled scipy_core and scipy from the current (yesterday, Rev 1502) svn versions. I'm running Mac OS X 10.4.3, with a fink-installed python2.4. I'd like to compile a C extension (ppgplot in particular) against the new scipy_core, and I'm wondering where arrayobject.h is supposed to get installed? Given an earlier comment on the list, it looks like #include "scipy/ arrayobject.h" should get it, which would imply to me that it would get put into /sw/include/python2.4/scipy/arrayobject.h, but that is not what happens. Here is the result of a "find": > mcxr2 : 17>find /sw -name arrayobject.h -print > /sw/include/python2.4/numarray/arrayobject.h > /sw/include/python2.4/Numeric/arrayobject.h > /sw/lib/python2.4/site-packages/scipy/base/include/scipy/arrayobject.h Is there a problem with the scipy_core installer? Shouldn't it create /sw/include/python2.4/scipy and populate it? Or, do I need to add /sw/lib/python2.4/site-packages/scipy/base/include/scipy to my include search path when building C extensions against the new scipy_core? Also, if anyone has successfully built ppgplot against the new scipy_core (it normally builds against Numeric or numarray), I'd love to know the code changes required. Cheers, -- Paul -- Dr. Paul S. Ray E-mail: Paul.Ray at nrl.navy.mil Naval Research Laboratory WWW : http://xweb.nrl.navy.mil/ personnel/paulr/ Code 7655 Phone : (202) 404-1619 Washington, DC 20375 AIM : NRLPSR From strawman at astraw.com Thu Dec 29 11:44:26 2005 From: strawman at astraw.com (Andrew Straw) Date: Thu, 29 Dec 2005 08:44:26 -0800 Subject: [SciPy-user] Where is arrayobject.h supposed to be? In-Reply-To: <2D1116B4-A27B-4425-9451-AADF331BF699@nrl.navy.mil> References: <2D1116B4-A27B-4425-9451-AADF331BF699@nrl.navy.mil> Message-ID: <43B4126A.6030000@astraw.com> Paul Ray wrote: >Hi, > >I've compiled scipy_core and scipy from the current (yesterday, Rev >1502) svn versions. >I'm running Mac OS X 10.4.3, with a fink-installed python2.4. > >I'd like to compile a C extension (ppgplot in particular) against the >new scipy_core, and I'm wondering where arrayobject.h is supposed to >get installed? > > For scipy_core, in your setup.py, do this: import scipy.base scipy_include_dirs = [scipy.base.get_scipy_include()] Now, you use pass this list to the include_dirs argument Extension() command in distutils. This way is easier when Python is installed as root but where you don't have a root scipy install. From stephen.walton at csun.edu Thu Dec 29 14:20:58 2005 From: stephen.walton at csun.edu (Stephen Walton) Date: Thu, 29 Dec 2005 11:20:58 -0800 Subject: [SciPy-user] Bug in scipy.io.fread? In-Reply-To: <2C2206D5-F4DC-4A89-95F8-A36539B8AFD1@nrl.navy.mil> References: <2C2206D5-F4DC-4A89-95F8-A36539B8AFD1@nrl.navy.mil> Message-ID: <43B4371A.9000603@csun.edu> Paul Ray wrote: >Hi, > >I've compiled scipy_core and scipy from the current (yesterday, Rev >1502) svn versions. >I'm running Mac OS X 10.4.3, with a fink-installed python2.4. >The new scipy builds and installs just fine, and all the unit tests I >tried worked fine. However, I get a Bus Error from the following >simple program: > > I get a segfault on Fedora Core 4 from Paul's program. It looks like numpyio_fromfile needs some attention? From oliphant.travis at ieee.org Thu Dec 29 14:29:15 2005 From: oliphant.travis at ieee.org (Travis Oliphant) Date: Thu, 29 Dec 2005 12:29:15 -0700 Subject: [SciPy-user] Bug in scipy.io.fread? In-Reply-To: <2C2206D5-F4DC-4A89-95F8-A36539B8AFD1@nrl.navy.mil> References: <2C2206D5-F4DC-4A89-95F8-A36539B8AFD1@nrl.navy.mil> Message-ID: <43B4390B.5080105@ieee.org> Paul Ray wrote: >Hi, > >I've compiled scipy_core and scipy from the current (yesterday, Rev >1502) svn versions. >I'm running Mac OS X 10.4.3, with a fink-installed python2.4. >The new scipy builds and installs just fine, and all the unit tests I >tried worked fine. However, I get a Bus Error from the following >simple program: >=================================================== >import scipy >import scipy.io > >print 'Opening test.dat for writing' >outfile = open('test.dat', mode='wb') >a = scipy.arange(1024.0,dtype='f') >print 'Writing array' >scipy.io.fwrite(outfile, 1024, a, 'f') >print 'Closing file' >outfile.close() > >print 'Opening test.dat for reading' >infile = open('test.dat', mode='rb') >print 'Reading chunk' >tmpchunk = scipy.io.fread(infile, 1024, 'f') >print 'Done :',tmpchunk[0:10] > > Thanks for catching this. It was a faulty DECREF of the data-type descriptor (new feature added in the past two weeks) which should have been XDECREF. There were actually a few more fixes to data-type descriptors needed. They are objects now and should be reference counted. I checked in the changes. The file was reading and writing fine, the problem happened right before returning when a NULL pointer was being DECREF'd. -Travis From Paul.Ray at nrl.navy.mil Thu Dec 29 18:16:50 2005 From: Paul.Ray at nrl.navy.mil (Paul Ray) Date: Thu, 29 Dec 2005 18:16:50 -0500 Subject: [SciPy-user] Bug in scipy.io.fread? In-Reply-To: <43B4390B.5080105@ieee.org> References: <2C2206D5-F4DC-4A89-95F8-A36539B8AFD1@nrl.navy.mil> <43B4390B.5080105@ieee.org> Message-ID: <5E85FD10-A08F-47AC-8D98-9A51F66A8AFC@nrl.navy.mil> On Dec 29, 2005, at 2:29 PM, Travis Oliphant wrote: > Thanks for catching this. It was a faulty DECREF of the data-type > descriptor (new feature added in the past two weeks) which should have > been XDECREF. There were actually a few more fixes to data-type > descriptors needed. They are objects now and should be reference > counted. I checked in the changes. The file was reading and writing > fine, the problem happened right before returning when a NULL pointer > was being DECREF'd. Wonderful. The problem is now fixed. I'm very much looking forward to released versions of scipy_core and scipy so that I can stop living on the bleeding edge with the svn versions. This will make it much easier to maintain consistent versions of scipy on different machines used by different developers. Thanks for all the hard work! I think I'll go buy a copy of the book now. Cheers, -- Paul -- Dr. Paul S. Ray E-mail: Paul.Ray at nrl.navy.mil Naval Research Laboratory WWW : http://xweb.nrl.navy.mil/ personnel/paulr/ Code 7655 Phone : (202) 404-1619 Washington, DC 20375 AIM : NRLPSR From hgamboa at gmail.com Thu Dec 29 19:03:13 2005 From: hgamboa at gmail.com (Hugo Gamboa) Date: Fri, 30 Dec 2005 00:03:13 +0000 Subject: [SciPy-user] Bug report - unwrap function error Message-ID: <86522b1a0512291603l44c5873mcd070fe312da346b@mail.gmail.com> Hello, I have the a recent svn version (1501), and when trying to use the unwrap function it gave me the error transcribed above. In a move to correct the bug to continue my work, I could not found the definition of the mod function. I know that it exists in scipy.mod but was unable to track the function. If someone could help this beginner to simply track a function in scipy, I would be very appreciated. Thanks in advance for your help. Hugo Gamboa The error reported in a ipython session In [13]: scipy.unwrap([1,2,3,4]) --------------------------------------------------------------------------- exceptions.NameError Traceback (most recent call last) /usr/lib/python2.4/site-packages/scipy/base/function_base.py in unwrap(p, discont, axis) 480 slice1 = [slice(None, None)]*nd # full slices 481 slice1[axis] = slice(1, None) --> 482 ddmod = mod(dd+pi, 2*pi)-pi 483 _nx.putmask(ddmod, (ddmod==-pi) & (dd > 0), pi) 484 ph_correct = ddmod - dd; NameError: global name 'mod' is not defined From oliphant at ee.byu.edu Thu Dec 29 19:08:59 2005 From: oliphant at ee.byu.edu (Travis Oliphant) Date: Thu, 29 Dec 2005 17:08:59 -0700 Subject: [SciPy-user] Bug report - unwrap function error In-Reply-To: <86522b1a0512291603l44c5873mcd070fe312da346b@mail.gmail.com> References: <86522b1a0512291603l44c5873mcd070fe312da346b@mail.gmail.com> Message-ID: <43B47A9B.7030709@ee.byu.edu> Hugo Gamboa wrote: >Hello, > >I have the a recent svn version (1501), and when trying to use the >unwrap function it gave me the error transcribed above. > >In a move to correct the bug to continue my work, I could not found >the definition of the mod function. I know that it exists in scipy.mod >but was unable to track the function. > > > mod is in umath. Should be present as scipy.mod (scipy.base.umath is the complete module name but you should be fine importing scipy alone): from scipy import mod Thanks for the tests. I've fixed SVN. -Travis From evemariedevaliere at yahoo.fr Thu Dec 29 20:19:47 2005 From: evemariedevaliere at yahoo.fr (=?iso-8859-1?q?Devali=E8re=20Eve-Marie?=) Date: Fri, 30 Dec 2005 02:19:47 +0100 (CET) Subject: [SciPy-user] newbie...info doesn't work... In-Reply-To: <86522b1a0512291603l44c5873mcd070fe312da346b@mail.gmail.com> Message-ID: <20051230011947.51030.qmail@web25806.mail.ukl.yahoo.com> Hi all, I feel kind of stupid but I have just installed python and stuff for scipy and just my 'info' function doesn't work...other functions seems to work but seeing how week is the scipy doc on the web I am worrying... Would anyone have an idea on what's happening? Also, is there any working search among scipy threads...the search mailing list doesn't give me any result even typing smth like 'matrix'... so I went into the archive of each month but that's not handy... Any help would be greatly appreciated, Thanks a lot!!! Eve --- Hugo Gamboa a ?crit : > Hello, > > I have the a recent svn version (1501), and when > trying to use the > unwrap function it gave me the error transcribed > above. > > In a move to correct the bug to continue my work, I > could not found > the definition of the mod function. I know that it > exists in scipy.mod > but was unable to track the function. > > If someone could help this beginner to simply track > a function in > scipy, I would be very appreciated. > > Thanks in advance for your help. > > > Hugo Gamboa > > > > The error reported in a ipython session > > In [13]: scipy.unwrap([1,2,3,4]) > --------------------------------------------------------------------------- > exceptions.NameError > Traceback (most > recent call last) > > /usr/lib/python2.4/site-packages/scipy/base/function_base.py > in > unwrap(p, discont, axis) > 480 slice1 = [slice(None, None)]*nd # > full slices > 481 slice1[axis] = slice(1, None) > --> 482 ddmod = mod(dd+pi, 2*pi)-pi > 483 _nx.putmask(ddmod, (ddmod==-pi) & (dd > > 0), pi) > 484 ph_correct = ddmod - dd; > > NameError: global name 'mod' is not defined > > _______________________________________________ > SciPy-user mailing list > SciPy-user at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-user > ___________________________________________________________________________ Nouveau : t?l?phonez moins cher avec Yahoo! Messenger ! D?couvez les tarifs exceptionnels pour appeler la France et l'international. T?l?chargez sur http://fr.messenger.yahoo.com From evan.monroig at gmail.com Thu Dec 29 20:43:23 2005 From: evan.monroig at gmail.com (Evan Monroig) Date: Fri, 30 Dec 2005 10:43:23 +0900 Subject: [SciPy-user] newbie...info doesn't work... In-Reply-To: <20051230011947.51030.qmail@web25806.mail.ukl.yahoo.com> References: <86522b1a0512291603l44c5873mcd070fe312da346b@mail.gmail.com> <20051230011947.51030.qmail@web25806.mail.ukl.yahoo.com> Message-ID: <20051230014323.GA9340@localhost.localdomain> On Dec.30 02h19, Devali?re Eve-Marie wrote : > I feel kind of stupid but I have just installed > python and stuff for scipy and just my 'info' function > doesn't work...other functions seems to work but > seeing how week is the scipy doc on the web I am > worrying... Hi, I'm not sure how you use scipy, but there are two cases If you use the command 'import scipy' to import scipy, then the info function will be available as scipy.info On the other hand, if you use the command 'from scipy import *' to import scipy, then info should be available directly. (and if it is not, I don't know what to do..) > Would anyone have an idea on what's happening? > Also, is there any working search among scipy > threads...the search mailing list doesn't give me any > result even typing smth like 'matrix'... so I went > into the archive of each month but that's not handy... I don't really know about scipy's website, but another solution is to use google and enter this in the box when you look for 'matrix': site:www.scipy.org/mailinglists matrix Hope this helped ^^ Evan ps: when you ask a question on the mailing-list you should write an entirely new mail, not just reply to a mail and change the subject ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From aisaac at american.edu Fri Dec 30 12:26:31 2005 From: aisaac at american.edu (Alan G Isaac) Date: Fri, 30 Dec 2005 12:26:31 -0500 Subject: [SciPy-user] default dtype Message-ID: Is an integer data type the obvious default for 'empty'? I expected float. Thanks, Alan Isaac using scipy core version 0.8.4 From dkuhlman at cutter.rexx.com Fri Dec 30 12:24:35 2005 From: dkuhlman at cutter.rexx.com (Dave Kuhlman) Date: Fri, 30 Dec 2005 09:24:35 -0800 Subject: [SciPy-user] newbie...info doesn't work... In-Reply-To: <20051230011947.51030.qmail@web25806.mail.ukl.yahoo.com> References: <86522b1a0512291603l44c5873mcd070fe312da346b@mail.gmail.com> <20051230011947.51030.qmail@web25806.mail.ukl.yahoo.com> Message-ID: <20051230172434.GA93502@cutter.rexx.com> On Fri, Dec 30, 2005 at 02:19:47AM +0100, Devali?re Eve-Marie wrote: > Hi all, > > I feel kind of stupid but I have just installed > python and stuff for scipy and just my 'info' function > doesn't work...other functions seems to work but > seeing how week is the scipy doc on the web I am > worrying... > Would anyone have an idea on what's happening? > Also, is there any working search among scipy > threads...the search mailing list doesn't give me any > result even typing smth like 'matrix'... so I went > into the archive of each month but that's not handy... You are right. It would be nice to be able to search at the scipy mailing list site. But, here is another solution -- Go to: http://gmane.org/ Click on "Lists" in the left-hand column. Then search for "scipy". You will find a link to: http://dir.gmane.org/gmane.comp.python.scientific.user That page will enable you to search the scipy-user list. And, you can browse through messages. There are several reader styles: frames/threaded and flat. You may even decide that you prefer to do your list reading there. Hope this helps. Dave [snip] -- Dave Kuhlman http://www.rexx.com/~dkuhlman From pajer at iname.com Fri Dec 30 12:53:00 2005 From: pajer at iname.com (Gary) Date: Fri, 30 Dec 2005 12:53:00 -0500 Subject: [SciPy-user] gaussian_kde bandwidth? In-Reply-To: References: Message-ID: <43B573FC.50803@iname.com> Can one specify a bandwidth for the kernel in scipy.stats.gaussian_kde? What is the default bandwidth? I checked the source code, but it was too obscure for me. If it is fixed, what is the reasoning? Don't I *want* to be able to adjust it? -gary From pajer at iname.com Fri Dec 30 13:08:08 2005 From: pajer at iname.com (Gary) Date: Fri, 30 Dec 2005 13:08:08 -0500 Subject: [SciPy-user] histogram bug ? In-Reply-To: References: Message-ID: <43B57788.6080900@iname.com> WinXP, scipy_core version 0.9.0.1713 tried to call scipy.histogram with the default bins=10. See below. It works ok if I make my own bins. ======================================== In [288]: f Out[288]: array([ 46., 59., 77., 87., 50., 97., 84., 73., 100., 34., 86., 67., 68., 100., 74., 81., 94., 66., 52., 66., 69., 54., 85., 97., 31., 49.]) In [289]: scipy.histogram(f) --------------------------------------------------------------------------- exceptions.TypeError Traceback (most recent call last) c:\python24\Lib\site-packages\scipy\base\function_base.py in histogram(a, bins, range, normed) 116 117 n = a.sort().searchsorted(bins) --> 118 n = concatenate([n, [len(a)]]) 119 n = n[1:]-n[:-1] 120 TypeError: len() of unsized object From hgamboa at gmail.com Fri Dec 30 14:09:38 2005 From: hgamboa at gmail.com (Hugo Gamboa) Date: Fri, 30 Dec 2005 19:09:38 +0000 Subject: [SciPy-user] histogram bug ? In-Reply-To: <43B57788.6080900@iname.com> References: <43B57788.6080900@iname.com> Message-ID: <86522b1a0512301109o4c7a4094na8e6e8a12d26e99d@mail.gmail.com> I encountered the same error, and It seems that the variable "a" is used to receive the data and to generate the bins. I've changed the name of the variable "a" to something else in line 115 of function_base.py and it solved the problem. But when looking at the created bins it produced unbalanced bins in the borders. Example: In [17]: histogram(linspace(-1,1,100)) Out[17]: (array([11, 11, 11, 11, 11, 11, 11, 11, 11, 1]), array([-1. , -0.77777778, -0.55555556, -0.33333333, -0.11111111, 0.11111111, 0.33333333, 0.55555556, 0.77777778, 1. ])) Each bin should have 10 counts instead of 11 leaving the last bin with 1. Will check the code to see if I can suggest a fix. Hugo Gamboa On 12/30/05, Gary wrote: > > WinXP, scipy_core version 0.9.0.1713 > > tried to call scipy.histogram with the default bins=10. See below. > > > It works ok if I make my own bins. > > > > ======================================== > > In [288]: f > Out[288]: > array([ 46., 59., 77., 87., 50., 97., 84., 73., 100., > 34., 86., 67., 68., 100., 74., 81., 94., 66., > 52., 66., 69., 54., 85., 97., 31., 49.]) > > In [289]: scipy.histogram(f) > > --------------------------------------------------------------------------- > exceptions.TypeError Traceback (most > recent call > last) > > > c:\python24\Lib\site-packages\scipy\base\function_base.py in > histogram(a, bins, > range, normed) > 116 > 117 n = a.sort().searchsorted(bins) > --> 118 n = concatenate([n, [len(a)]]) > 119 n = n[1:]-n[:-1] > 120 > > TypeError: len() of unsized object > > _______________________________________________ > SciPy-user mailing list > SciPy-user at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: From oliphant.travis at ieee.org Fri Dec 30 14:14:01 2005 From: oliphant.travis at ieee.org (Travis Oliphant) Date: Fri, 30 Dec 2005 12:14:01 -0700 Subject: [SciPy-user] default dtype In-Reply-To: References: Message-ID: <43B586F9.1020904@ieee.org> Alan G Isaac wrote: >Is an integer data type the obvious >default for 'empty'? I expected float. > > > This question comes up occasionally. The reason for int is largely historical --- that's what was decided long ago when Numeric came out. Changing this in some places would break a lot of code, I'm afraid. And the default for empty is done for consistency. I felt it better to have one default rather than many. The default can be changed in one place in the C-code if we did decide to change it. Now's the time because version 1.0 is approaching in the next couple of months. Version 0.9 will be the first-of-the-year release. -Travis From elcorto at gmx.net Fri Dec 30 14:58:17 2005 From: elcorto at gmx.net (Steve Schmerler) Date: Fri, 30 Dec 2005 20:58:17 +0100 Subject: [SciPy-user] docstrings; corefft, corelinalg In-Reply-To: <43B586F9.1020904@ieee.org> References: <43B586F9.1020904@ieee.org> Message-ID: <43B59159.6010007@gmx.net> Hi I just installed the latest svn versions. 1) Trying to have a look at the doc gives me this ##################################################################################################################################### In [19]: ?scipy Type: module Base Class: String Form: Namespace: Interactive File: /usr/lib/python2.3/site-packages/scipy/__init__.py Docstring: SciPy Core ========== You can support the development of SciPy by purchasing documentation at http://www.trelgol.com It is being distributed for a fee for a limited time to try and raise money for development. Documentation is also available in the docstrings. Available subpackages --------------------- SciPy: A scientific computing package for Python ================================================ Available subpackages --------------------- In [20]: ##################################################################################################################################### ... no infos about scipy subpackages (of course `help(scipy)` has some infos). 2) I think the doc strings of corefft and corelinalg should contain some words explaining their existence. New scipy users would wonder * why there is e.g. linalg.inv and corelinalg.inv and why they are the same function from .../scipy/linalg/basic.py; same with corefft.fft and fftpack.fft and so on * what the difference between corelinalg.det and corelinalg.determinant is (there is none as a look in .../scipy/corelinalg/linalg.py reveals) and why there are two names for the same function * .... Is it possible to move all additional functionality of corefft and corelinalg to linalg and fftpack (e.g corelinalg.eigh which seems to have no equivalent function in linalg). cheers, steve -- "People like Blood Sausage too. People are Morons!" -- Phil Connors, Groundhog Day From aisaac at american.edu Fri Dec 30 15:11:03 2005 From: aisaac at american.edu (Alan G Isaac) Date: Fri, 30 Dec 2005 15:11:03 -0500 Subject: [SciPy-user] histogram bug ? In-Reply-To: <43B57788.6080900@iname.com> References: <43B57788.6080900@iname.com> Message-ID: On Fri, 30 Dec 2005, Gary apparently wrote: > In [288]: f > Out[288]: > array([ 46., 59., 77., 87., 50., 97., 84., 73., 100., > 34., 86., 67., 68., 100., 74., 81., 94., 66., > 52., 66., 69., 54., 85., 97., 31., 49.]) > In [289]: scipy.histogram(f) > --------------------------------------------------------------------------- > exceptions.TypeError It is a scoping problem. (See comments below.) This also reminded me of a question: should a.sort() violate Pythonic expectations by returning a? Alan Isaac PS Possible rewrite of `histogram` offered at the end. Fixes this problem, eliminates the use of the built-in name `range`, and sets endpoint=False in the linspace call. See the end of this message. ################ The Current Def with Problem Highlighted ############### def histogram(a, bins=10, range=None, normed=False): a = asarray(a).ravel() #<- here `a` is an array if not iterable(bins): if range is None: range = (a.min(), a.max()) mn, mx = [a+0.0 for a in range] #<- now `a` is a number! if mn == mx: mn -= 0.5 mx += 0.5 bins = linspace(mn, mx, bins) n = a.sort().searchsorted(bins) #<- not caught here because type(a) is int32_arrtype!! n = concatenate([n, [len(a)]]) n = n[1:]-n[:-1] if normed: db = bins[1] - bins[0] return 1.0/(a.size*db) * n, bins else: return n, bins ################ Proposed Rewrite of histogram ################ def histogram(a, bins=10, minmax=None, normed=False, copy=True): '''Returns `n`,`bins` as arrays, where `n` contains the number of items in each bin, and `bins` contains the bin cutoffs (cutoff<=value) ''' a = array(a,copy=copy).ravel() if not iterable(bins): if minmax is None: minmax = (a.min(), a.max()) mn, mx = [mi+0.0 for mi in minmax] if mn == mx: mn -= 0.5 mx += 0.5 bins = linspace(mn, mx, bins, endpoint=False) n = a.sort().searchsorted(bins) n = concatenate([n, [len(a)]]) n = n[1:]-n[:-1] if normed: db = bins[1] - bins[0] return 1.0/(a.size*db) * n, bins else: return n, bins From aisaac at american.edu Fri Dec 30 15:32:00 2005 From: aisaac at american.edu (Alan G Isaac) Date: Fri, 30 Dec 2005 15:32:00 -0500 Subject: [SciPy-user] histogram bug ? In-Reply-To: References: <43B57788.6080900@iname.com> Message-ID: On Fri, 30 Dec 2005, Alan G Isaac apparently wrote: > should a.sort() violate Pythonic expectations by returning a? Rephrasing: Currently scipy core does not follow the Python or numarray convention of having the sort method sort the array in place and return None. Instead it returns a sorted copy of the old array, and leaves the old array untouched. This seems like a sure "gotcha". Perhaps it would be better to follow the Python and numarray convention for the `sort` method and have a new sorted() method handle the current behavior. fwiw, Alan Isaac From aisaac at american.edu Fri Dec 30 15:56:11 2005 From: aisaac at american.edu (Alan G Isaac) Date: Fri, 30 Dec 2005 15:56:11 -0500 Subject: [SciPy-user] default dtype In-Reply-To: <43B586F9.1020904@ieee.org> References: <43B586F9.1020904@ieee.org> Message-ID: On Fri, 30 Dec 2005, Travis Oliphant apparently wrote: > The default can be changed in one place in the C-code if > we did decide to change it. Now's the time because > version 1.0 is approaching in the next couple of months. Once discovered, it does not matter much of course. My only argument for the change is the effect on prospective users as opposed to the existing base of knowledgeable users: most I suspect will come from environments where every number containing object is filled with floats by default. (I think GAUSS and Matlab work this way.) Any ordinary user who creates an array of zeros (or empty) and then assigns floats to a few elements is likely to be surprised by the outcome, I believe. Cheers, Alan Isaac From strawman at astraw.com Fri Dec 30 16:13:10 2005 From: strawman at astraw.com (Andrew Straw) Date: Fri, 30 Dec 2005 13:13:10 -0800 Subject: [SciPy-user] default dtype In-Reply-To: References: <43B586F9.1020904@ieee.org> Message-ID: <43B5A2E6.2090205@astraw.com> Seeing as this question comes up fairly often, I've made a FAQ for it in the new wiki: http://new.scipy.org/Wiki/FAQ#head-c366238b249beadfb51fc716bb440a6ad527dba9 Please edit (as is the wiki way) as you see fit. Alan G Isaac wrote: >On Fri, 30 Dec 2005, Travis Oliphant apparently wrote: > > >>The default can be changed in one place in the C-code if >>we did decide to change it. Now's the time because >>version 1.0 is approaching in the next couple of months. >> >> > >Once discovered, it does not matter much of course. >My only argument for the change is the effect on prospective >users as opposed to the existing base of knowledgeable >users: most I suspect will come from environments where >every number containing object is filled with floats by >default. (I think GAUSS and Matlab work this way.) Any >ordinary user who creates an array of zeros (or empty) and >then assigns floats to a few elements is likely to be >surprised by the outcome, I believe. > >Cheers, >Alan Isaac > > >_______________________________________________ >SciPy-user mailing list >SciPy-user at scipy.net >http://www.scipy.net/mailman/listinfo/scipy-user > > From aisaac at american.edu Fri Dec 30 16:26:02 2005 From: aisaac at american.edu (Alan G Isaac) Date: Fri, 30 Dec 2005 16:26:02 -0500 Subject: [SciPy-user] histogram bug ? In-Reply-To: <43B59A91.9070005@ieee.org> References: <43B57788.6080900@iname.com> <43B59A91.9070005@ieee.org> Message-ID: On Fri, 30 Dec 2005, Travis Oliphant apparently wrote: > So, clearly the sort function could still return a copy > while the sort method does the in-place sort. I had > forgotten that sort was not a method in Numeric. ... I'll > do this as part of the change of inlining the sorting > methods. Great! I think this is important because of Python's behavior. Making the function name `sort` instead of `sorted` also leaves Python's built-in usable even if the scipy namespace is imported, which might be useful. I will also mention another case: ravel. I do not have an opinion on this one. But a parallel makes this seem worth mentioning: Numeric only had the function, while (in conflict with the current ndarray) the numarray ravel method worked in place and returned None. Cheers, Alan Isaac From oliphant.travis at ieee.org Fri Dec 30 15:37:37 2005 From: oliphant.travis at ieee.org (Travis Oliphant) Date: Fri, 30 Dec 2005 13:37:37 -0700 Subject: [SciPy-user] histogram bug ? In-Reply-To: References: <43B57788.6080900@iname.com> Message-ID: <43B59A91.9070005@ieee.org> Alan G Isaac wrote: >On Fri, 30 Dec 2005, Alan G Isaac apparently wrote: > > >>should a.sort() violate Pythonic expectations by returning a? >> >> > >Rephrasing: > >Currently scipy core does not follow the Python or numarray >convention of having the sort method sort the array in place >and return None. Instead it returns a sorted copy of the >old array, and leaves the old array untouched. > > This makes sense. The reason for the current behavior is that it was Numeric's behavior -- but sort was a function. So, clearly the sort function could still return a copy while the sort method does the in-place sort. I had forgotten that sort was not a method in Numeric. I think this is the right thing to do. I don't think we need another .sorted method either: sort(a) will return the sorted copy just as it did in Numeric. I'll do this as part of the change of inlining the sorting methods. -Travis From oliphant.travis at ieee.org Fri Dec 30 15:05:32 2005 From: oliphant.travis at ieee.org (Travis Oliphant) Date: Fri, 30 Dec 2005 13:05:32 -0700 Subject: [SciPy-user] docstrings; corefft, corelinalg In-Reply-To: <43B59159.6010007@gmx.net> References: <43B586F9.1020904@ieee.org> <43B59159.6010007@gmx.net> Message-ID: <43B5930C.2060900@ieee.org> Steve Schmerler wrote: > Available subpackages > --------------------- > > > SciPy: A scientific computing package for Python > ================================================ > > Available subpackages > --------------------- > > >In [20]: >##################################################################################################################################### > >... no infos about scipy subpackages (of course `help(scipy)` has some >infos) > > These subpackage docs were at one time auto-generated. I'm not sure what the status of that is right now. It could be that the info.py file is wrong in the sub-packages. > >2) I think the doc strings of corefft and corelinalg should contain some > words explaining their existence. New scipy users would wonder > > > Good idea. >Is it possible to move all additional functionality of corefft and >corelinalg to linalg and fftpack (e.g corelinalg.eigh which seems to >have no equivalent function in linalg). > > Should be possible. The linalg approach uses f2py blas wrappers. I'm sure there is already a wrapper around the underlying function that handles eigh. Lots of little things to do so dive on in :-) Thanks for the feedback and suggestions. -Travis From agn at noc.soton.ac.uk Fri Dec 30 17:43:31 2005 From: agn at noc.soton.ac.uk (George Nurser) Date: Fri, 30 Dec 2005 22:43:31 +0000 Subject: [SciPy-user] Import probs with rev 1735 svn scipy core In-Reply-To: <20051230172434.GA93502@cutter.rexx.com> References: <86522b1a0512291603l44c5873mcd070fe312da346b@mail.gmail.com> <20051230011947.51030.qmail@web25806.mail.ukl.yahoo.com> <20051230172434.GA93502@cutter.rexx.com> Message-ID: <429CBCA7-E71A-41B1-8A63-497130A7EEFC@noc.soton.ac.uk> Just tried to get rev 1735 svn scipy core going on an Opteron. Non root install of Scipy, site.cfg to use acml libraries for lapack and blas. LD_LIBRARY_PATH includes acml directory. Otherwise default. python setup.py install --home=... seems to work fine. But when I try python >>> import scipy Importing ScipyTest of testing to scipy Failed to import base cannot import name ccompiler Importing fft of corefft to scipy Importing ifft of corefft to scipy Failed to import random 'module' object has no attribute 'dtypedescr' Puzzled about ccompiler message, as ccompile.py seems to be in distutils directory, not base subdirectory. George Nurser. From oliphant.travis at ieee.org Fri Dec 30 17:55:17 2005 From: oliphant.travis at ieee.org (Travis Oliphant) Date: Fri, 30 Dec 2005 15:55:17 -0700 Subject: [SciPy-user] Import probs with rev 1735 svn scipy core In-Reply-To: <429CBCA7-E71A-41B1-8A63-497130A7EEFC@noc.soton.ac.uk> References: <86522b1a0512291603l44c5873mcd070fe312da346b@mail.gmail.com> <20051230011947.51030.qmail@web25806.mail.ukl.yahoo.com> <20051230172434.GA93502@cutter.rexx.com> <429CBCA7-E71A-41B1-8A63-497130A7EEFC@noc.soton.ac.uk> Message-ID: <43B5BAD5.4010107@ieee.org> George Nurser wrote: >Just tried to get rev 1735 svn scipy core going on an Opteron. > >Non root install of Scipy, site.cfg to use acml libraries for lapack >and blas. >LD_LIBRARY_PATH includes acml directory. > >Otherwise default. > >python setup.py install --home=... seems to work fine. > >But when I try >python > >>> import scipy >Importing ScipyTest of testing to scipy >Failed to import base >cannot import name ccompiler >Importing fft of corefft to scipy >Importing ifft of corefft to scipy >Failed to import random >'module' object has no attribute 'dtypedescr' > >Puzzled about ccompiler message, as ccompile.py seems to be in >distutils directory, not base subdirectory. > > Is this a fresh install on the system or are their older installations. Enough has changed in the package loading that I would delete any old install and the build directory (if you had a previous check-out) and install again. Otherwise, I'm not sure what is going on. -Travis From pau.gargallo at gmail.com Fri Dec 30 19:30:37 2005 From: pau.gargallo at gmail.com (Pau Gargallo) Date: Sat, 31 Dec 2005 01:30:37 +0100 Subject: [SciPy-user] scipy to vtk conversion? Message-ID: <6ef8f3380512301630r3689d27fp8efb0271cf02b2dc@mail.gmail.com> hi, is there a simple way to convert a scipy array to a vtk array? is there a way to do that without writing a explicit python loop over the data? thanks, pau From prabhu_r at users.sf.net Fri Dec 30 23:45:00 2005 From: prabhu_r at users.sf.net (Prabhu Ramachandran) Date: Sat, 31 Dec 2005 10:15:00 +0530 Subject: [SciPy-user] scipy to vtk conversion? In-Reply-To: <6ef8f3380512301630r3689d27fp8efb0271cf02b2dc@mail.gmail.com> References: <6ef8f3380512301630r3689d27fp8efb0271cf02b2dc@mail.gmail.com> Message-ID: <17334.3276.161402.916049@monster.iitb.ac.in> >>>>> "Pau" == Pau Gargallo writes: Pau> hi, is there a simple way to convert a scipy array to a vtk Pau> array? is there a way to do that without writing a explicit Pau> python loop over the data? You can do this easily with TVTK: http://www.enthought.com/enthought/wiki/TVTK Currently TVTK uses "numerix" to support numeric/numarray and scipy. For reasons too long to elaborate here, it defaults to numeric and will use scipy if you set the environment variable NUMERIX to 'scipy'. Full support for scipy in tvtk or mayavi2 requires a patch to traits which is available here: http://www.enthought.com/enthought/ticket/326 However, when you build traits you might run into difficulties since it uses scipy_distutils which is part of old scipy. I know that this is not ideal but there is little I can do about it. cheers, prabhu From Fernando.Perez at colorado.edu Sat Dec 31 00:07:58 2005 From: Fernando.Perez at colorado.edu (Fernando Perez) Date: Fri, 30 Dec 2005 22:07:58 -0700 Subject: [SciPy-user] scipy to vtk conversion? In-Reply-To: <17334.3276.161402.916049@monster.iitb.ac.in> References: <6ef8f3380512301630r3689d27fp8efb0271cf02b2dc@mail.gmail.com> <17334.3276.161402.916049@monster.iitb.ac.in> Message-ID: <43B6122E.3080806@colorado.edu> Prabhu Ramachandran wrote: >>>>>>"Pau" == Pau Gargallo writes: > > > Pau> hi, is there a simple way to convert a scipy array to a vtk > Pau> array? is there a way to do that without writing a explicit > Pau> python loop over the data? > > You can do this easily with TVTK: > > http://www.enthought.com/enthought/wiki/TVTK While TVTK is certainly the 'way of the future', I think it's worth mentioning that using pyvtk http://cens.ioc.ee/projects/pyvtk/ from our very own Pearu, for certain simple cases the conversion is very straightforward. For example: def make_vtk(arr): """Build a vtk data obj from a Numeric 3d array""" dims = list(arr.shape) # We need to give the dims as (x,y,z), not (z,y,x): dims.reverse() grid = pyvtk.StructuredPoints(dims) # RectilinearGrid is another option for this [use (x,y,z) order]: #grid = pyvtk.RectilinearGrid(range(dims[2]),range(dims[1]),range(dims[0])) if arr.iscontiguous(): dat = arr.flat else: dat = N.ravel(arr) header = 'Data array' point_data = pyvtk.PointData(pyvtk.Scalars(dat, 'Data Array: ','default')) return pyvtk.VtkData(grid,header,point_data) =========== I know this doesn't have anywhere near the functionality and cleanliness of TVTK, but it may be good enough for cases where the data has simple geometry. hth, f From evan.monroig at gmail.com Sat Dec 31 01:52:13 2005 From: evan.monroig at gmail.com (Evan Monroig) Date: Sat, 31 Dec 2005 15:52:13 +0900 Subject: [SciPy-user] using with with blitz: errors Message-ID: <20051231065213.GA11404@localhost.localdomain> Hi, I am trying to use weave to speed up my code with inline c++ code, but I can't find any working sample. I found a very simple one [1] to return the trace of a matrix, but I can't find how to incorporate the c++ code. I attached the compile errors. I also tried to remove the "type_converters" parameter in inline and change the array parentheses () into brackets [], then it compiles but gives wrong results... I am running on Ubuntu with python2.4-scipy-core=0.3.2-2ubuntu1 python2.4-scipy=0.3.2-3ubuntu2 python2.4-numeric=23.8-4 python2.4-numeric-ext=23.8-4 blitz++=1:0.8-4 (just in case) gcc version is 4.0.2 Any ideas? Evan [1] http://amath.colorado.edu/faculty/fperez/python/weave_examples.html ps: here is the code that I ran ---- import scipy from weave import converters, inline def trace(mat): """Return the trace of a matrix. """ nrow,ncol = mat.shape code = \ """ double tr=0.0; for(int i=0;i? /usr/include/c++/4.0.2/limits:286: erreur: previous definition of ?class std::numeric_limits<_Tp>? /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/limits-hack.h:317: erreur: redefinition of ?class std::numeric_limits? /usr/include/c++/4.0.2/limits:316: erreur: previous definition of ?class std::numeric_limits? /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/limits-hack.h:324: erreur: redefinition of ?class std::numeric_limits? /usr/include/c++/4.0.2/limits:370: erreur: previous definition of ?class std::numeric_limits? /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/limits-hack.h:329: erreur: redefinition of ?class std::numeric_limits? /usr/include/c++/4.0.2/limits:421: erreur: previous definition of ?class std::numeric_limits? /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/limits-hack.h:334: erreur: redefinition of ?class std::numeric_limits? /usr/include/c++/4.0.2/limits:472: erreur: previous definition of ?class std::numeric_limits? /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/limits-hack.h:348: erreur: redefinition of ?class std::numeric_limits? /usr/include/c++/4.0.2/limits:574: erreur: previous definition of ?class std::numeric_limits? /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/limits-hack.h:353: erreur: redefinition of ?class std::numeric_limits? /usr/include/c++/4.0.2/limits:625: erreur: previous definition of ?class std::numeric_limits? /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/limits-hack.h:358: erreur: redefinition of ?class std::numeric_limits? /usr/include/c++/4.0.2/limits:676: erreur: previous definition of ?class std::numeric_limits? /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/limits-hack.h:363: erreur: redefinition of ?class std::numeric_limits? /usr/include/c++/4.0.2/limits:727: erreur: previous definition of ?class std::numeric_limits? /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/limits-hack.h:368: erreur: redefinition of ?class std::numeric_limits? /usr/include/c++/4.0.2/limits:778: erreur: previous definition of ?class std::numeric_limits? /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/limits-hack.h:373: erreur: redefinition of ?class std::numeric_limits? /usr/include/c++/4.0.2/limits:829: erreur: previous definition of ?class std::numeric_limits? /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/limits-hack.h:399: erreur: redefinition of ?class std::numeric_limits? /usr/include/c++/4.0.2/limits:982: erreur: previous definition of ?class std::numeric_limits? /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/limits-hack.h:421: erreur: redefinition of ?class std::numeric_limits? /usr/include/c++/4.0.2/limits:1039: erreur: previous definition of ?class std::numeric_limits? /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/limits-hack.h:443: erreur: redefinition of ?class std::numeric_limits? /usr/include/c++/4.0.2/limits:1096: erreur: previous definition of ?class std::numeric_limits? /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/array/slice.h: In instantiation of ?blitz::SliceInfo?: /home/evan/.python24_compiled/sc_92b558abbb3baf45c5de2284178e42075.cpp:705: instantiated from here /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/array/slice.h:137: erreur: ?blitz::ArraySectionInfo::? is/uses anonymous type /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/array/slice.h:137: erreur: trying to instantiate ?template T blitz::operator+(const T&, blitz::_bz_meta_nullOperand)? /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/array/slice.h:137: erreur: ?blitz::ArraySectionInfo::? is/uses anonymous type /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/array/slice.h:137: erreur: trying to instantiate ?template T blitz::operator+(const T&, blitz::_bz_meta_nullOperand)? /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/array/slice.h:137: erreur: ?blitz::ArraySectionInfo::? is/uses anonymous type /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/array/slice.h:137: erreur: trying to instantiate ?template T blitz::operator+(const T&, blitz::_bz_meta_nullOperand)? /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/meta/product.h: In static member function ?static typename blitz::NumericTypeTraits::T_sumtype blitz::_bz_meta_vectorProduct::f(const T_expr1&) [with T_expr1 = blitz::TinyVector, int N = 2, int I = 0]?: /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/tvecglobs.h:127: instantiated from ?typename blitz::NumericTypeTraits::T_sumtype blitz::product(const blitz::TinyVector&) [with T_numtype1 = int, int N_length = 2]? /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/array-impl.h:520: instantiated from ?blitz::Array::Array(P_numtype*, blitz::TinyVector, blitz::TinyVector, blitz::preexistingMemoryPolicy, blitz::GeneralArrayStorage) [with P_numtype = double, int N_rank = 2]? /home/evan/.python24_compiled/sc_92b558abbb3baf45c5de2284178e42075.cpp:654: instantiated from ?blitz::Array convert_to_blitz(PyArrayObject*, const char*) [with T = double, int N = 2]? /home/evan/.python24_compiled/sc_92b558abbb3baf45c5de2284178e42075.cpp:694: instantiated from here /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/meta/product.h:111: erreur: ?blitz::_bz_meta_vectorProduct<2, 0>::? is/uses anonymous type /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/meta/product.h:111: erreur: trying to instantiate ?template T blitz::operator*(const T&, blitz::_bz_meta_nullOperand)? /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/meta/product.h:111: erreur: ?blitz::_bz_meta_vectorProduct<2, 0>::? is/uses anonymous type /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/meta/product.h:111: erreur: trying to instantiate ?template T blitz::operator*(const T&, blitz::_bz_meta_nullOperand)? /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/meta/product.h: In static member function ?static typename blitz::NumericTypeTraits::T_sumtype blitz::_bz_meta_vectorProduct::f(const T_expr1&) [with T_expr1 = blitz::TinyVector, int N = 2, int I = 1]?: /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/meta/product.h:111: instantiated from ?static typename blitz::NumericTypeTraits::T_sumtype blitz::_bz_meta_vectorProduct::f(const T_expr1&) [with T_expr1 = blitz::TinyVector, int N = 2, int I = 0]? /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/tvecglobs.h:127: instantiated from ?typename blitz::NumericTypeTraits::T_sumtype blitz::product(const blitz::TinyVector&) [with T_numtype1 = int, int N_length = 2]? /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/array-impl.h:520: instantiated from ?blitz::Array::Array(P_numtype*, blitz::TinyVector, blitz::TinyVector, blitz::preexistingMemoryPolicy, blitz::GeneralArrayStorage) [with P_numtype = double, int N_rank = 2]? /home/evan/.python24_compiled/sc_92b558abbb3baf45c5de2284178e42075.cpp:654: instantiated from ?blitz::Array convert_to_blitz(PyArrayObject*, const char*) [with T = double, int N = 2]? /home/evan/.python24_compiled/sc_92b558abbb3baf45c5de2284178e42075.cpp:694: instantiated from here /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/meta/product.h:111: erreur: ?blitz::_bz_meta_vectorProduct<2, 1>::? is/uses anonymous type /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/meta/product.h:111: erreur: trying to instantiate ?template T blitz::operator*(const T&, blitz::_bz_meta_nullOperand)? /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/meta/product.h:111: erreur: ?blitz::_bz_meta_vectorProduct<2, 1>::? is/uses anonymous type /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/meta/product.h:111: erreur: trying to instantiate ?template T blitz::operator*(const T&, blitz::_bz_meta_nullOperand)? /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/meta/dot.h: In static member function ?static typename blitz::promote_trait::T_promote blitz::_bz_meta_vectorDot::f(const T_expr1&, const T_expr2&) [with T_expr1 = blitz::TinyVector, T_expr2 = blitz::TinyVector, int N = 2, int I = 0]?: /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/tvecglobs.h:106: instantiated from ?typename blitz::promote_trait::T_promote blitz::dot(const blitz::TinyVector&, const blitz::TinyVector&) [with T_numtype1 = int, T_numtype2 = int, int N_length = 2]? /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/array-impl.h:994: instantiated from ?int blitz::Array::dataOffset() const [with P_numtype = double, int N_rank = 2]? /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/array-impl.h:998: instantiated from ?const P_numtype* __restrict__ blitz::Array::data() const [with P_numtype = double, int N_rank = 2]? /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/array/fastiter.h:142: instantiated from ?blitz::FastArrayIterator::FastArrayIterator(const blitz::Array&) [with P_numtype = double, int N_rank = 2]? /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/array-impl.h:970: instantiated from ?blitz::FastArrayIterator blitz::Array::beginFast() const [with P_numtype = double, int N_rank = 2]? /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/array/ops.cc:127: instantiated from ?blitz::Array& blitz::Array::operator=(const blitz::Array&) [with P_numtype = double, int N_rank = 2]? /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/array/methods.cc:352: instantiated from ?blitz::Array blitz::Array::copy() const [with P_numtype = double, int N_rank = 2]? /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/array-impl.h:530: instantiated from ?blitz::Array::Array(P_numtype*, blitz::TinyVector, blitz::TinyVector, blitz::preexistingMemoryPolicy, blitz::GeneralArrayStorage) [with P_numtype = double, int N_rank = 2]? /home/evan/.python24_compiled/sc_92b558abbb3baf45c5de2284178e42075.cpp:654: instantiated from ?blitz::Array convert_to_blitz(PyArrayObject*, const char*) [with T = double, int N = 2]? /home/evan/.python24_compiled/sc_92b558abbb3baf45c5de2284178e42075.cpp:694: instantiated from here /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/meta/dot.h:112: erreur: ?blitz::_bz_meta_vectorDot<2, 0>::? is/uses anonymous type /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/meta/dot.h:112: erreur: trying to instantiate ?template T blitz::operator*(const T&, blitz::_bz_meta_nullOperand)? /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/meta/dot.h:112: erreur: ?blitz::_bz_meta_vectorDot<2, 0>::? is/uses anonymous type /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/meta/dot.h:112: erreur: trying to instantiate ?template T blitz::operator*(const T&, blitz::_bz_meta_nullOperand)? /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/meta/dot.h: In static member function ?static typename blitz::promote_trait::T_promote blitz::_bz_meta_vectorDot::f(const T_expr1&, const T_expr2&) [with T_expr1 = blitz::TinyVector, T_expr2 = blitz::TinyVector, int N = 2, int I = 1]?: /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/meta/dot.h:112: instantiated from ?static typename blitz::promote_trait::T_promote blitz::_bz_meta_vectorDot::f(const T_expr1&, const T_expr2&) [with T_expr1 = blitz::TinyVector, T_expr2 = blitz::TinyVector, int N = 2, int I = 0]? /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/tvecglobs.h:106: instantiated from ?typename blitz::promote_trait::T_promote blitz::dot(const blitz::TinyVector&, const blitz::TinyVector&) [with T_numtype1 = int, T_numtype2 = int, int N_length = 2]? /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/array-impl.h:994: instantiated from ?int blitz::Array::dataOffset() const [with P_numtype = double, int N_rank = 2]? /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/array-impl.h:998: instantiated from ?const P_numtype* __restrict__ blitz::Array::data() const [with P_numtype = double, int N_rank = 2]? /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/array/fastiter.h:142: instantiated from ?blitz::FastArrayIterator::FastArrayIterator(const blitz::Array&) [with P_numtype = double, int N_rank = 2]? /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/array-impl.h:970: instantiated from ?blitz::FastArrayIterator blitz::Array::beginFast() const [with P_numtype = double, int N_rank = 2]? /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/array/ops.cc:127: instantiated from ?blitz::Array& blitz::Array::operator=(const blitz::Array&) [with P_numtype = double, int N_rank = 2]? /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/array/methods.cc:352: instantiated from ?blitz::Array blitz::Array::copy() const [with P_numtype = double, int N_rank = 2]? /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/array-impl.h:530: instantiated from ?blitz::Array::Array(P_numtype*, blitz::TinyVector, blitz::TinyVector, blitz::preexistingMemoryPolicy, blitz::GeneralArrayStorage) [with P_numtype = double, int N_rank = 2]? /home/evan/.python24_compiled/sc_92b558abbb3baf45c5de2284178e42075.cpp:654: instantiated from ?blitz::Array convert_to_blitz(PyArrayObject*, const char*) [with T = double, int N = 2]? /home/evan/.python24_compiled/sc_92b558abbb3baf45c5de2284178e42075.cpp:694: instantiated from here /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/meta/dot.h:112: erreur: ?blitz::_bz_meta_vectorDot<2, 1>::? is/uses anonymous type /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/meta/dot.h:112: erreur: trying to instantiate ?template T blitz::operator*(const T&, blitz::_bz_meta_nullOperand)? /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/meta/dot.h:112: erreur: ?blitz::_bz_meta_vectorDot<2, 1>::? is/uses anonymous type /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/meta/dot.h:112: erreur: trying to instantiate ?template T blitz::operator*(const T&, blitz::_bz_meta_nullOperand)? cc1plus: attention : l'option de la ligne de commande "-Wstrict-prototypes" est valide pour Ada/C/ObjC mais pas pour C++ Dans le fichier inclus ? partir de /usr/include/python2.4/Python.h:8, ? partir de /home/evan/.python24_compiled/sc_92b558abbb3baf45c5de2284178e42075.cpp:4: /usr/include/python2.4/pyconfig.h:835:1: attention : ? _POSIX_C_SOURCE ? red?fini Dans le fichier inclus ? partir de /usr/include/c++/4.0.2/i486-linux-gnu/bits/os_defines.h:39, ? partir de /usr/include/c++/4.0.2/i486-linux-gnu/bits/c++config.h:35, ? partir de /usr/include/c++/4.0.2/string:44, ? partir de /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/blitz.h:153, ? partir de /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/array-impl.h:154, ? partir de /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/array.h:94, ? partir de /home/evan/.python24_compiled/sc_92b558abbb3baf45c5de2284178e42075.cpp:3: /usr/include/features.h:150:1: attention : ceci est la localisation d'une pr?c?dente d?finition /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/limits-hack.h:82: erreur: multiple definition of ?enum std::float_round_style? /usr/include/c++/4.0.2/limits:156: erreur: d?finition pr?c?dente ici /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/limits-hack.h:83: erreur: conflicting declaration ?round_indeterminate? /usr/include/c++/4.0.2/limits:158: erreur: ?std::round_indeterminate? has a previous declaration as ?std::float_round_style std::round_indeterminate? /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/limits-hack.h:84: erreur: conflicting declaration ?round_toward_zero? /usr/include/c++/4.0.2/limits:159: erreur: ?std::round_toward_zero? has a previous declaration as ?std::float_round_style std::round_toward_zero? /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/limits-hack.h:85: erreur: conflicting declaration ?round_to_nearest? /usr/include/c++/4.0.2/limits:160: erreur: ?std::round_to_nearest? has a previous declaration as ?std::float_round_style std::round_to_nearest? /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/limits-hack.h:86: erreur: conflicting declaration ?round_toward_infinity? /usr/include/c++/4.0.2/limits:161: erreur: ?std::round_toward_infinity? has a previous declaration as ?std::float_round_style std::round_toward_infinity? /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/limits-hack.h:87: erreur: conflicting declaration ?round_toward_neg_infinity? /usr/include/c++/4.0.2/limits:162: erreur: ?std::round_toward_neg_infinity? has a previous declaration as ?std::float_round_style std::round_toward_neg_infinity? /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/limits-hack.h:90: erreur: multiple definition of ?enum std::float_denorm_style? /usr/include/c++/4.0.2/limits:171: erreur: d?finition pr?c?dente ici /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/limits-hack.h:91: erreur: conflicting declaration ?denorm_indeterminate? /usr/include/c++/4.0.2/limits:174: erreur: ?std::denorm_indeterminate? has a previous declaration as ?std::float_denorm_style std::denorm_indeterminate? /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/limits-hack.h:92: erreur: conflicting declaration ?denorm_absent? /usr/include/c++/4.0.2/limits:176: erreur: ?std::denorm_absent? has a previous declaration as ?std::float_denorm_style std::denorm_absent? /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/limits-hack.h:93: erreur: conflicting declaration ?denorm_present? /usr/include/c++/4.0.2/limits:178: erreur: ?std::denorm_present? has a previous declaration as ?std::float_denorm_style std::denorm_present? /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/limits-hack.h:310: erreur: redefinition of ?class std::numeric_limits<_Tp>? /usr/include/c++/4.0.2/limits:286: erreur: previous definition of ?class std::numeric_limits<_Tp>? /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/limits-hack.h:317: erreur: redefinition of ?class std::numeric_limits? /usr/include/c++/4.0.2/limits:316: erreur: previous definition of ?class std::numeric_limits? /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/limits-hack.h:324: erreur: redefinition of ?class std::numeric_limits? /usr/include/c++/4.0.2/limits:370: erreur: previous definition of ?class std::numeric_limits? /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/limits-hack.h:329: erreur: redefinition of ?class std::numeric_limits? /usr/include/c++/4.0.2/limits:421: erreur: previous definition of ?class std::numeric_limits? /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/limits-hack.h:334: erreur: redefinition of ?class std::numeric_limits? /usr/include/c++/4.0.2/limits:472: erreur: previous definition of ?class std::numeric_limits? /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/limits-hack.h:348: erreur: redefinition of ?class std::numeric_limits? /usr/include/c++/4.0.2/limits:574: erreur: previous definition of ?class std::numeric_limits? /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/limits-hack.h:353: erreur: redefinition of ?class std::numeric_limits? /usr/include/c++/4.0.2/limits:625: erreur: previous definition of ?class std::numeric_limits? /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/limits-hack.h:358: erreur: redefinition of ?class std::numeric_limits? /usr/include/c++/4.0.2/limits:676: erreur: previous definition of ?class std::numeric_limits? /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/limits-hack.h:363: erreur: redefinition of ?class std::numeric_limits? /usr/include/c++/4.0.2/limits:727: erreur: previous definition of ?class std::numeric_limits? /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/limits-hack.h:368: erreur: redefinition of ?class std::numeric_limits? /usr/include/c++/4.0.2/limits:778: erreur: previous definition of ?class std::numeric_limits? /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/limits-hack.h:373: erreur: redefinition of ?class std::numeric_limits? /usr/include/c++/4.0.2/limits:829: erreur: previous definition of ?class std::numeric_limits? /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/limits-hack.h:399: erreur: redefinition of ?class std::numeric_limits? /usr/include/c++/4.0.2/limits:982: erreur: previous definition of ?class std::numeric_limits? /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/limits-hack.h:421: erreur: redefinition of ?class std::numeric_limits? /usr/include/c++/4.0.2/limits:1039: erreur: previous definition of ?class std::numeric_limits? /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/limits-hack.h:443: erreur: redefinition of ?class std::numeric_limits? /usr/include/c++/4.0.2/limits:1096: erreur: previous definition of ?class std::numeric_limits? /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/array/slice.h: In instantiation of ?blitz::SliceInfo?: /home/evan/.python24_compiled/sc_92b558abbb3baf45c5de2284178e42075.cpp:705: instantiated from here /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/array/slice.h:137: erreur: ?blitz::ArraySectionInfo::? is/uses anonymous type /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/array/slice.h:137: erreur: trying to instantiate ?template T blitz::operator+(const T&, blitz::_bz_meta_nullOperand)? /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/array/slice.h:137: erreur: ?blitz::ArraySectionInfo::? is/uses anonymous type /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/array/slice.h:137: erreur: trying to instantiate ?template T blitz::operator+(const T&, blitz::_bz_meta_nullOperand)? /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/array/slice.h:137: erreur: ?blitz::ArraySectionInfo::? is/uses anonymous type /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/array/slice.h:137: erreur: trying to instantiate ?template T blitz::operator+(const T&, blitz::_bz_meta_nullOperand)? /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/meta/product.h: In static member function ?static typename blitz::NumericTypeTraits::T_sumtype blitz::_bz_meta_vectorProduct::f(const T_expr1&) [with T_expr1 = blitz::TinyVector, int N = 2, int I = 0]?: /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/tvecglobs.h:127: instantiated from ?typename blitz::NumericTypeTraits::T_sumtype blitz::product(const blitz::TinyVector&) [with T_numtype1 = int, int N_length = 2]? /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/array-impl.h:520: instantiated from ?blitz::Array::Array(P_numtype*, blitz::TinyVector, blitz::TinyVector, blitz::preexistingMemoryPolicy, blitz::GeneralArrayStorage) [with P_numtype = double, int N_rank = 2]? /home/evan/.python24_compiled/sc_92b558abbb3baf45c5de2284178e42075.cpp:654: instantiated from ?blitz::Array convert_to_blitz(PyArrayObject*, const char*) [with T = double, int N = 2]? /home/evan/.python24_compiled/sc_92b558abbb3baf45c5de2284178e42075.cpp:694: instantiated from here /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/meta/product.h:111: erreur: ?blitz::_bz_meta_vectorProduct<2, 0>::? is/uses anonymous type /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/meta/product.h:111: erreur: trying to instantiate ?template T blitz::operator*(const T&, blitz::_bz_meta_nullOperand)? /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/meta/product.h:111: erreur: ?blitz::_bz_meta_vectorProduct<2, 0>::? is/uses anonymous type /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/meta/product.h:111: erreur: trying to instantiate ?template T blitz::operator*(const T&, blitz::_bz_meta_nullOperand)? /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/meta/product.h: In static member function ?static typename blitz::NumericTypeTraits::T_sumtype blitz::_bz_meta_vectorProduct::f(const T_expr1&) [with T_expr1 = blitz::TinyVector, int N = 2, int I = 1]?: /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/meta/product.h:111: instantiated from ?static typename blitz::NumericTypeTraits::T_sumtype blitz::_bz_meta_vectorProduct::f(const T_expr1&) [with T_expr1 = blitz::TinyVector, int N = 2, int I = 0]? /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/tvecglobs.h:127: instantiated from ?typename blitz::NumericTypeTraits::T_sumtype blitz::product(const blitz::TinyVector&) [with T_numtype1 = int, int N_length = 2]? /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/array-impl.h:520: instantiated from ?blitz::Array::Array(P_numtype*, blitz::TinyVector, blitz::TinyVector, blitz::preexistingMemoryPolicy, blitz::GeneralArrayStorage) [with P_numtype = double, int N_rank = 2]? /home/evan/.python24_compiled/sc_92b558abbb3baf45c5de2284178e42075.cpp:654: instantiated from ?blitz::Array convert_to_blitz(PyArrayObject*, const char*) [with T = double, int N = 2]? /home/evan/.python24_compiled/sc_92b558abbb3baf45c5de2284178e42075.cpp:694: instantiated from here /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/meta/product.h:111: erreur: ?blitz::_bz_meta_vectorProduct<2, 1>::? is/uses anonymous type /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/meta/product.h:111: erreur: trying to instantiate ?template T blitz::operator*(const T&, blitz::_bz_meta_nullOperand)? /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/meta/product.h:111: erreur: ?blitz::_bz_meta_vectorProduct<2, 1>::? is/uses anonymous type /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/meta/product.h:111: erreur: trying to instantiate ?template T blitz::operator*(const T&, blitz::_bz_meta_nullOperand)? /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/meta/dot.h: In static member function ?static typename blitz::promote_trait::T_promote blitz::_bz_meta_vectorDot::f(const T_expr1&, const T_expr2&) [with T_expr1 = blitz::TinyVector, T_expr2 = blitz::TinyVector, int N = 2, int I = 0]?: /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/tvecglobs.h:106: instantiated from ?typename blitz::promote_trait::T_promote blitz::dot(const blitz::TinyVector&, const blitz::TinyVector&) [with T_numtype1 = int, T_numtype2 = int, int N_length = 2]? /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/array-impl.h:994: instantiated from ?int blitz::Array::dataOffset() const [with P_numtype = double, int N_rank = 2]? /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/array-impl.h:998: instantiated from ?const P_numtype* __restrict__ blitz::Array::data() const [with P_numtype = double, int N_rank = 2]? /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/array/fastiter.h:142: instantiated from ?blitz::FastArrayIterator::FastArrayIterator(const blitz::Array&) [with P_numtype = double, int N_rank = 2]? /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/array-impl.h:970: instantiated from ?blitz::FastArrayIterator blitz::Array::beginFast() const [with P_numtype = double, int N_rank = 2]? /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/array/ops.cc:127: instantiated from ?blitz::Array& blitz::Array::operator=(const blitz::Array&) [with P_numtype = double, int N_rank = 2]? /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/array/methods.cc:352: instantiated from ?blitz::Array blitz::Array::copy() const [with P_numtype = double, int N_rank = 2]? /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/array-impl.h:530: instantiated from ?blitz::Array::Array(P_numtype*, blitz::TinyVector, blitz::TinyVector, blitz::preexistingMemoryPolicy, blitz::GeneralArrayStorage) [with P_numtype = double, int N_rank = 2]? /home/evan/.python24_compiled/sc_92b558abbb3baf45c5de2284178e42075.cpp:654: instantiated from ?blitz::Array convert_to_blitz(PyArrayObject*, const char*) [with T = double, int N = 2]? /home/evan/.python24_compiled/sc_92b558abbb3baf45c5de2284178e42075.cpp:694: instantiated from here /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/meta/dot.h:112: erreur: ?blitz::_bz_meta_vectorDot<2, 0>::? is/uses anonymous type /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/meta/dot.h:112: erreur: trying to instantiate ?template T blitz::operator*(const T&, blitz::_bz_meta_nullOperand)? /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/meta/dot.h:112: erreur: ?blitz::_bz_meta_vectorDot<2, 0>::? is/uses anonymous type /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/meta/dot.h:112: erreur: trying to instantiate ?template T blitz::operator*(const T&, blitz::_bz_meta_nullOperand)? /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/meta/dot.h: In static member function ?static typename blitz::promote_trait::T_promote blitz::_bz_meta_vectorDot::f(const T_expr1&, const T_expr2&) [with T_expr1 = blitz::TinyVector, T_expr2 = blitz::TinyVector, int N = 2, int I = 1]?: /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/meta/dot.h:112: instantiated from ?static typename blitz::promote_trait::T_promote blitz::_bz_meta_vectorDot::f(const T_expr1&, const T_expr2&) [with T_expr1 = blitz::TinyVector, T_expr2 = blitz::TinyVector, int N = 2, int I = 0]? /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/tvecglobs.h:106: instantiated from ?typename blitz::promote_trait::T_promote blitz::dot(const blitz::TinyVector&, const blitz::TinyVector&) [with T_numtype1 = int, T_numtype2 = int, int N_length = 2]? /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/array-impl.h:994: instantiated from ?int blitz::Array::dataOffset() const [with P_numtype = double, int N_rank = 2]? /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/array-impl.h:998: instantiated from ?const P_numtype* __restrict__ blitz::Array::data() const [with P_numtype = double, int N_rank = 2]? /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/array/fastiter.h:142: instantiated from ?blitz::FastArrayIterator::FastArrayIterator(const blitz::Array&) [with P_numtype = double, int N_rank = 2]? /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/array-impl.h:970: instantiated from ?blitz::FastArrayIterator blitz::Array::beginFast() const [with P_numtype = double, int N_rank = 2]? /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/array/ops.cc:127: instantiated from ?blitz::Array& blitz::Array::operator=(const blitz::Array&) [with P_numtype = double, int N_rank = 2]? /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/array/methods.cc:352: instantiated from ?blitz::Array blitz::Array::copy() const [with P_numtype = double, int N_rank = 2]? /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/array-impl.h:530: instantiated from ?blitz::Array::Array(P_numtype*, blitz::TinyVector, blitz::TinyVector, blitz::preexistingMemoryPolicy, blitz::GeneralArrayStorage) [with P_numtype = double, int N_rank = 2]? /home/evan/.python24_compiled/sc_92b558abbb3baf45c5de2284178e42075.cpp:654: instantiated from ?blitz::Array convert_to_blitz(PyArrayObject*, const char*) [with T = double, int N = 2]? /home/evan/.python24_compiled/sc_92b558abbb3baf45c5de2284178e42075.cpp:694: instantiated from here /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/meta/dot.h:112: erreur: ?blitz::_bz_meta_vectorDot<2, 1>::? is/uses anonymous type /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/meta/dot.h:112: erreur: trying to instantiate ?template T blitz::operator*(const T&, blitz::_bz_meta_nullOperand)? /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/meta/dot.h:112: erreur: ?blitz::_bz_meta_vectorDot<2, 1>::? is/uses anonymous type /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz/meta/dot.h:112: erreur: trying to instantiate ?template T blitz::operator*(const T&, blitz::_bz_meta_nullOperand)? Traceback (most recent call last): File "weavetest.py", line 20, in ? trace(M) File "weavetest.py", line 17, in trace type_converters = converters.blitz) File "/usr/lib/python2.4/site-packages/weave/inline_tools.py", line 335, in inline auto_downcast = auto_downcast, File "/usr/lib/python2.4/site-packages/weave/inline_tools.py", line 439, in compile_function verbose=verbose, **kw) File "/usr/lib/python2.4/site-packages/weave/ext_tools.py", line 340, in compile verbose = verbose, **kw) File "/usr/lib/python2.4/site-packages/weave/build_tools.py", line 274, in build_extension setup(name = module_name, ext_modules = [ext],verbose=verb) File "/usr/lib/python2.4/site-packages/scipy_distutils/core.py", line 73, in setup return old_setup(**new_attr) File "/usr/lib/python2.4/distutils/core.py", line 166, in setup raise SystemExit, "error: " + str(msg) weave.build_tools.CompileError: error: Command "g++ -pthread -fno-strict-aliasing -DNDEBUG -g -O3 -Wstrict-prototypes -fPIC -I/usr/lib/python2.4/site-packages/weave -I/usr/lib/python2.4/site-packages/weave/scxx -I/usr/lib/python2.4/site-packages/weave/blitz-20001213 -I/usr/include/python2.4 -c /home/evan/.python24_compiled/sc_92b558abbb3baf45c5de2284178e42075.cpp -o /tmp/evan/python24_intermediate/compiler_fcf4821de2ee87a8ad4d6579aeaebbc9/home/evan/.python24_compiled/sc_92b558abbb3baf45c5de2284178e42075.o" failed with exit status 1 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From Fernando.Perez at colorado.edu Sat Dec 31 01:58:05 2005 From: Fernando.Perez at colorado.edu (Fernando Perez) Date: Fri, 30 Dec 2005 23:58:05 -0700 Subject: [SciPy-user] using with with blitz: errors In-Reply-To: <20051231065213.GA11404@localhost.localdomain> References: <20051231065213.GA11404@localhost.localdomain> Message-ID: <43B62BFD.3060400@colorado.edu> Evan Monroig wrote: > Hi, > > I am trying to use weave to speed up my code with inline c++ code, but > I can't find any working sample. > > I found a very simple one [1] to return the trace of a matrix, but > I can't find how to incorporate the c++ code. I attached the compile > errors. I also tried to remove the "type_converters" parameter in inline > and change the array parentheses () into brackets [], then it compiles > but gives wrong results... > > I am running on Ubuntu with > python2.4-scipy-core=0.3.2-2ubuntu1 > python2.4-scipy=0.3.2-3ubuntu2 > python2.4-numeric=23.8-4 > python2.4-numeric-ext=23.8-4 > blitz++=1:0.8-4 (just in case) > > gcc version is 4.0.2 ^^^^^^^^^^^^^^^^^^^^ This is your problem: only blitz 0.9 compiles with gcc4. You need to download the newer blitz, and put it by hand in the /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz directory. > Any ideas? > > Evan > > [1] http://amath.colorado.edu/faculty/fperez/python/weave_examples.html From evan.monroig at gmail.com Sat Dec 31 02:03:33 2005 From: evan.monroig at gmail.com (Evan Monroig) Date: Sat, 31 Dec 2005 16:03:33 +0900 Subject: [SciPy-user] using with with blitz: errors In-Reply-To: <43B62BFD.3060400@colorado.edu> References: <20051231065213.GA11404@localhost.localdomain> <43B62BFD.3060400@colorado.edu> Message-ID: <20051231070333.GA12542@localhost.localdomain> On Dec.30 23h58, Fernando Perez wrote : > Evan Monroig wrote: > > Hi, > > > > I am trying to use weave to speed up my code with inline c++ code, but > > I can't find any working sample. > > [snip] > > > > gcc version is 4.0.2 > ^^^^^^^^^^^^^^^^^^^^ > > This is your problem: only blitz 0.9 compiles with gcc4. You need to download > the newer blitz, and put it by hand in the > > /usr/lib/python2.4/site-packages/weave/blitz-20001213/blitz > > directory. Thanks ! In fact after I checked my gcc version I just installed gcc-3.4 and changed the link in /usr/bin and it worked ^^. So I will get the newer blitz :). By the way, is there a way to specify the version of gcc to use with weave? Evan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From Fernando.Perez at colorado.edu Sat Dec 31 02:37:38 2005 From: Fernando.Perez at colorado.edu (Fernando Perez) Date: Sat, 31 Dec 2005 00:37:38 -0700 Subject: [SciPy-user] using with with blitz: errors In-Reply-To: <20051231070333.GA12542@localhost.localdomain> References: <20051231065213.GA11404@localhost.localdomain> <43B62BFD.3060400@colorado.edu> <20051231070333.GA12542@localhost.localdomain> Message-ID: <43B63542.5040404@colorado.edu> Evan Monroig wrote: > Thanks ! > > In fact after I checked my gcc version I just installed gcc-3.4 and > changed the link in /usr/bin and it worked ^^. good. > > So I will get the newer blitz :). > > By the way, is there a way to specify the version of gcc to use with > weave? there is (use compiler='franken-gcc' in your weave call), but it's NOT a good idea to try to build extension modules (what weave is doing for you under the hood) with a different compiler than python itself was built, unless the two compilers are known to be extremely compatible. gcc3 and gcc4 (what I assume ubuntu built python with) won't play well together: the C++ ABI changed with gcc4. Cheers, f From oliphant.travis at ieee.org Sat Dec 31 02:39:24 2005 From: oliphant.travis at ieee.org (Travis Oliphant) Date: Sat, 31 Dec 2005 00:39:24 -0700 Subject: [SciPy-user] Changes allow string -> number casting Message-ID: <43B635AC.80306@ieee.org> I just checked in to SVN, the changes needed to allow strings (and unicode) to be converted to numbers: >>> print array(['3.0','4','5','6']).astype(float) array([ 3., 4., 5., 6.]) It is not the fastest-possible approach (it goes through the Python int, long, float, and complex __new__ methods), but it works. -Travis From robert.kern at gmail.com Sat Dec 31 20:33:07 2005 From: robert.kern at gmail.com (Robert Kern) Date: Sat, 31 Dec 2005 19:33:07 -0600 Subject: [SciPy-user] gaussian_kde bandwidth? In-Reply-To: <43B573FC.50803@iname.com> References: <43B573FC.50803@iname.com> Message-ID: <3d375d730512311733t16561796v5f1e116c113038f5@mail.gmail.com> On 12/30/05, Gary wrote: > Can one specify a bandwidth for the kernel in scipy.stats.gaussian_kde? > > What is the default bandwidth? I checked the source code, but it was > too obscure for me. > > If it is fixed, what is the reasoning? Don't I *want* to be able to > adjust it? The default uses Scott's Rule to calculate an "optimal" bandwidth (minimum asymptotic mean integrated square error for Gaussian true densities, I believe). You can change the method that calculates the bandwidth by overriding the method covariance_factor. The module was written for an application for which this was sufficient, and then it was contributed to scipy. There is certainly room for making it more sophisticated. There are endless numbers of ways to do bandwidth selection. This is frequently a bad thing. Here's the TODO list for kde.py: * Split out univariate from multivariate; there are some approaches that are much easier (or simply possible) for univariate KDE than multivariate. * Provide more ways to select a bandwidth including k-nearest neighbors (univariate only). * Add more kernels besides Gaussians. I probably won't be getting to all of these, so contributions are welcome. -- Robert Kern robert.kern at gmail.com