From johng at labs.mot.com Tue Sep 2 13:02:22 2003 From: johng at labs.mot.com (John Grosspietsch) Date: Tue, 02 Sep 2003 12:02:22 -0500 Subject: [SciPy-user] re: tutorial problems Message-ID: <3F54CD1E.7040001@labs.mot.com> This python program works on WIN-XP as a simple stand alone, command line test of the plt library. from scipy import plt import gui_thread gui_thread.start() a=[1,1,2,3,4,3,4,5,6,7,8,7,6,5,4] plt.plot(a) n=input("enter n") # to prevent program from immediately exiting --john grosspietsch From WILLIAM.GRIFFIN at asu.edu Tue Sep 2 13:49:35 2003 From: WILLIAM.GRIFFIN at asu.edu (William Griffin) Date: Tue, 02 Sep 2003 10:49:35 -0700 Subject: [SciPy-user] re: tutorial problems Message-ID: <3996AE5EBEF964418D80953BDCABFF560B4051D5@ex1.asurite.ad.asu.edu> I think that the basic scipy plt calls the gnu plt and not the tk plt or the chaco plt. I have, in fact, had very good luck with the gnu plt. bill griffin > -----Original Message----- > From: John Grosspietsch [mailto:johng at labs.mot.com] > Sent: Tuesday, September 02, 2003 10:02 AM > To: scipy-user at scipy.net > Subject: [SciPy-user] re: tutorial problems > > > This python program works on WIN-XP as a simple stand alone, command > line test of the plt library. > > from scipy import plt > import gui_thread > gui_thread.start() > > a=[1,1,2,3,4,3,4,5,6,7,8,7,6,5,4] > > plt.plot(a) > > n=input("enter n") > # to prevent program from immediately exiting > > --john grosspietsch > > _______________________________________________ > 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 fperez at colorado.edu Tue Sep 2 17:28:00 2003 From: fperez at colorado.edu (Fernando Perez) Date: Tue, 02 Sep 2003 15:28:00 -0600 Subject: [SciPy-user] Low-level code integration discussion at scipy'03? Message-ID: <3F550B60.5060108@colorado.edu> Hi everyone, as I mentioned before, I think it would be great to have a bit of an open discussion on methods and techniques for plugging low-level code into python at Scipy'03. I don't mean to teach people how to write an extension module, but rather what the best/easiest approaches are for writing time-critical code which manipulates Numpy/numarray arrays. A brief summary of the alternatives: * Scipy's weave relies on blitz, which is extremely nice and maps surprisingly well to python arrays. Blitz arrays have slices, ranges, overloaded arithmetic operators and math functions, etc. In fact, writing blitz C++ feels almost like writing python code, with the caveats of handling compile-time type information. But blitz development seems to be rather slow these days, and the issue of access to Blas/lapack from blitz isn't fully settled (i.e., it's not out-of-the box easy). * The ublas library (http://www.boost.org/libs/numeric/ublas/doc/overview.htm). It has direct blas support, but it seems to focus strictly on vectors and matrices, and as far as I see it doesn't support higher rank objects (I could be wrong, though: I've been using blitz for 'real' and only looked at the ublas webpage). * Writing low-level code in fortran and using Pearu's f2py. I love f2py, but I'd prefer my low-level code to have the ability to also use more information from the python side of things if needed. I think f2py is a great tool for wrapping existing fortran codes, but not so much for extending a python program with a few low-level routines. And there is always the potential need for transposition operations when going to Fortran because of the row/column memory ordering discrepancy between C and Fortran. * Complete roll-your-own solutions using the Numarray C api. This is doable, but after using blitz arrays, it feels really low-level. Call me lazy, but after using python I've become fully enamored of writing code which reads as cleanly as possible. What I'd like to know is if there is any interest in organizing a bit of a discussion on this. If an hour can be squeezed in for this in the schedule, great (and I volunteer to moderate if nobody else wants to). If not, perhaps some of people involved with these topics (Eric, Travis, Konrad, Todd and Perry at least, plus whoever else is interested) might be willing to commit to a lunch/dinner to be spent talking about this. It would be nice to know something in advance, because one of blitz's current developers (Julian Cummings) is at Caltech. Perhaps we could ask him to come in and answer some questions about Blitz's future. Blitz feels like the lowest-impedance fit to python's semantics, but I'd like to know more about its long-term feasibility before committing to use it too much. If we set any kind of schedule for this discussion, I can try to contact Julian. Regards, Fernando. From dmorrill at enthought.com Tue Sep 2 20:01:21 2003 From: dmorrill at enthought.com (David C. Morrill) Date: Tue, 2 Sep 2003 19:01:21 -0500 Subject: [SciPy-user] Announce: Python 2.3 for Windows (Enthought Edition) now available Message-ID: <002101c371ae$826dd4b0$8201a8c0@dellbert> Just a quick heads up that Python 2.3 for Windows (Enthought Edition) is now available at: http://www.enthought.com This is in addition to the Python 2.2.3 for Windows (Enthought Edition) that was previously announced. Besides the obvious feature of being based on Python 2.3, this new version also includes updates to several other packages, such as wxPython So if you've been putting off giving Python 2.3 a spin, now might be a good time to upgrade. And if you do decide to give it a try, we'd also appreciate hearing from you either on the mailing lists or on the bug tracker concerning what you think about the new Python distribution. Enjoy! The Python guys at Enthought, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pajer at iname.com Tue Sep 2 23:07:33 2003 From: pajer at iname.com (Gary Pajer) Date: Tue, 2 Sep 2003 23:07:33 -0400 Subject: [SciPy-user] Announce: Python 2.3 for Windows (Enthought Edition) now available References: <002101c371ae$826dd4b0$8201a8c0@dellbert> Message-ID: <000801c371c8$8541b660$01fd5644@playroom> Just gave it a whirl. Some problems. The first thing I did was, from a DOS window python session: from scipy import plt plt.plot((1,2,3)) pythonw.exe crash, asking me if I want to send a note to Microsoft. Then tried PyCrust shell. from scipy import plt plt.plot((1,2,3)) This time the plot appeared, along with an error dialog: C:\Python23\lib\site-packages\wxPython\gdi.py:600: DeprecationWarning: integer argument expected, got float val = gdic.wxDC_DrawEllipse(self, *_args, **_kwargs) This looks like it might be a wxPython warning. Nonetheless... Finally from chaco import wxplt wxplt.plot((1,2,3)) Plots the data, but again an error dialog: C:\Python23\lib\site-packages\kiva\agg\agg.py:611: DeprecationWarning: integer argument expected, got float def draw_glyphs(*args): return apply(_agg._GraphicsContextArray_draw_glyphs,args) Again, it looks like a warning, but ... so far I'm 0 for 3. bugs? or am I buggy? -gary ----- Original Message ----- From: "David C. Morrill" To: ; ; Sent: Tuesday, September 02, 2003 8:01 PM Subject: [SciPy-user] Announce: Python 2.3 for Windows (Enthought Edition) now available Just a quick heads up that Python 2.3 for Windows (Enthought Edition) is now available at: http://www.enthought.com This is in addition to the Python 2.2.3 for Windows (Enthought Edition) that was previously announced. Besides the obvious feature of being based on Python 2.3, this new version also includes updates to several other packages, such as wxPython So if you've been putting off giving Python 2.3 a spin, now might be a good time to upgrade. And if you do decide to give it a try, we'd also appreciate hearing from you either on the mailing lists or on the bug tracker concerning what you think about the new Python distribution. Enjoy! The Python guys at Enthought, Inc. From alnesbit at students.cs.mu.OZ.AU Wed Sep 3 01:29:01 2003 From: alnesbit at students.cs.mu.OZ.AU (Andrew Nesbit) Date: Wed, 3 Sep 2003 15:29:01 +1000 (EST) Subject: [SciPy-user] STFT implementations in Python Message-ID: Does anybody know if there exist any Python implementations for STFT and inverse STFT? I can code it myself, but I just wanted to know if anybody has already done this, as it seems like it would be a pretty common thing. Thanks. Andrew. From prabhu at aero.iitm.ernet.in Wed Sep 3 02:25:16 2003 From: prabhu at aero.iitm.ernet.in (Prabhu Ramachandran) Date: Wed, 3 Sep 2003 11:55:16 +0530 Subject: [SciPy-user] Low-level code integration discussion at scipy'03? In-Reply-To: <3F550B60.5060108@colorado.edu> References: <3F550B60.5060108@colorado.edu> Message-ID: <16213.35148.87968.555025@monster.linux.in> Hi, I have a few opinions on the subject. >>>>> "FP" == Fernando Perez writes: [snip] FP> A brief summary of the alternatives: FP> * Scipy's weave relies on blitz, which is extremely nice and FP> maps surprisingly FP> well to python arrays. Blitz arrays have slices, ranges, FP> overloaded arithmetic operators and math functions, etc. In FP> fact, writing blitz C++ feels almost like writing python code, FP> with the caveats of handling compile-time type information. FP> But blitz development seems to be rather slow these days, and FP> the issue of access to Blas/lapack from blitz isn't fully FP> settled (i.e., it's not out-of-the box easy). AFAIK, the other problems with blitz++ and weave are: 1. Blitz is not as fast as a hand coded inline C version. More on ugliness of code later. 2. Blitz compile times are large. 3. An extra layer of complexity for weave, one more package to keep track of -- the blitz sources are bundled with weave. 4. With all due respect, not many C++ programmers (forget Python programmers) would be able to understand/code anything with the techniques used inside Blitz. Agreed, this is transparent to the user in the present context but its still worth noting. [snip] FP> * Complete roll-your-own solutions using the Numarray C api. FP> This is doable, FP> but after using blitz arrays, it feels really low-level. Call FP> me lazy, but after using python I've become fully enamored of FP> writing code which reads as cleanly as possible. Here is my take. I've always felt that there should be a way to seamlessly handle Python/C/C++ Numeric arrays using a standard API for each language. I don't believe I've mentioned it anywhere though and I am not sure if such a thing exists or not. Numeric/numarray offer the most commonly used, maintained and popular API for arrays for numerics in Python. It would be best if a clean C/C++ API would exist. I'm thinking of a higher level wrapper like class that gives the C/C++ user a nice API. No re-implementation of the Numeric/numarray API should be neccessary. If this were done, the following becomes easily possible: 1. Its easy for C/C++ programmers to use the API and not have to worry about translating their C code to Python. The translation should be easy since they are using the standard wrapper API that uses the raw numeric API underneath. 2. Performance is not too much of an issue since there is no copying of data back and forth between C/Python and the C++ layer would most probably be entirely inlined. 3. Writing weave.inline code should be almost as easy as the blitz version. Agreed blitz is extremely easy to use but if we had a fairly powerful wrapper API most of the common stuff could be easily done via this API. Agreed, getting slices to work would be some work but if there is significant interest, this should also be possible. In any case the API could be made sufficiently useable without the need for blitz conversions. 4. Compile times should drop since we aren't really looking to redo blitz but simply provide a clean Numeric API for C/C++. >From what I can tell this should solve most problems satisfactorily and should be useful outside of weave. cheers, prabhu From pajer at iname.com Wed Sep 3 08:46:38 2003 From: pajer at iname.com (Gary Pajer) Date: Wed, 3 Sep 2003 08:46:38 -0400 Subject: [SciPy-user] Announce: Python 2.3 for Windows (Enthought Edition)now available References: <002101c371ae$826dd4b0$8201a8c0@dellbert> <000801c371c8$8541b660$01fd5644@playroom> Message-ID: <000401c37219$efb2b0c0$01fd5644@playroom> I had a thought ... maybe I didn't install it correctly. I checked the registry, and there are a bunch of references to c\python22, mostly in relation to other packages. Should I uninstall python22 and uninstal / reinstall the other packages? > Just gave it a whirl. Some problems. > > The first thing I did was, from a DOS window python session: > from scipy import plt > plt.plot((1,2,3)) > > pythonw.exe crash, asking me if I want to send a note to Microsoft. > > > Then tried PyCrust shell. > from scipy import plt > plt.plot((1,2,3)) > > This time the plot appeared, along with an error dialog: > C:\Python23\lib\site-packages\wxPython\gdi.py:600: DeprecationWarning: > integer argument expected, got float > val = gdic.wxDC_DrawEllipse(self, *_args, **_kwargs) > > > This looks like it might be a wxPython warning. Nonetheless... > > Finally > from chaco import wxplt > wxplt.plot((1,2,3)) > > Plots the data, but again an error dialog: > C:\Python23\lib\site-packages\kiva\agg\agg.py:611: DeprecationWarning: > integer argument expected, got float > def draw_glyphs(*args): return > apply(_agg._GraphicsContextArray_draw_glyphs,args) > > Again, it looks like a warning, but ... > > so far I'm 0 for 3. > > bugs? or am I buggy? > > -gary > > ----- Original Message ----- > From: "David C. Morrill" > To: ; ; > Sent: Tuesday, September 02, 2003 8:01 PM > Subject: [SciPy-user] Announce: Python 2.3 for Windows (Enthought Edition) > now available > > > Just a quick heads up that Python 2.3 for Windows (Enthought Edition) is now > available at: > > http://www.enthought.com > > This is in addition to the Python 2.2.3 for Windows (Enthought Edition) that > was previously announced. Besides the obvious feature of being based on > Python 2.3, this new version also includes updates to several other > packages, such as wxPython > > So if you've been putting off giving Python 2.3 a spin, now might be a good > time to upgrade. And if you do decide to give it a try, we'd also appreciate > hearing from you either on the mailing lists or on the bug tracker > concerning what you think about the new Python distribution. > > Enjoy! > > The Python guys at Enthought, Inc. > > _______________________________________________ > SciPy-user mailing list > SciPy-user at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-user From fperez at colorado.edu Wed Sep 3 10:15:35 2003 From: fperez at colorado.edu (Fernando Perez) Date: Wed, 03 Sep 2003 08:15:35 -0600 Subject: [SciPy-user] Low-level code integration discussion at scipy'03? In-Reply-To: <16213.35148.87968.555025@monster.linux.in> References: <3F550B60.5060108@colorado.edu> <16213.35148.87968.555025@monster.linux.in> Message-ID: <3F55F787.3080809@colorado.edu> Prabhu Ramachandran wrote: > AFAIK, the other problems with blitz++ and weave are: > > 1. Blitz is not as fast as a hand coded inline C version. More on > ugliness of code later. From my experience, this is definitely true. Depending on how much one uses Blitz's abstractions, the overhead can be rather high. This is one of the things I'd like to discuss with J. Cummings at Caltech, since he works on the blitz internals. > 2. Blitz compile times are large. True. > 3. An extra layer of complexity for weave, one more package to keep > track of -- the blitz sources are bundled with weave. > 4. With all due respect, not many C++ programmers (forget Python > programmers) would be able to understand/code anything with the > techniques used inside Blitz. Agreed, this is transparent to the > user in the present context but its still worth noting. True. Using it, however, is a dream :) > Here is my take. I've always felt that there should be a way to > seamlessly handle Python/C/C++ Numeric arrays using a standard API for > each language. I don't believe I've mentioned it anywhere though and > I am not sure if such a thing exists or not. Numeric/numarray offer > the most commonly used, maintained and popular API for arrays for > numerics in Python. It would be best if a clean C/C++ API would > exist. I'm thinking of a higher level wrapper like class that gives > the C/C++ user a nice API. No re-implementation of the > Numeric/numarray API should be neccessary. If this were done, the > following becomes easily possible: > > 1. Its easy for C/C++ programmers to use the API and not have to > worry about translating their C code to Python. The translation > should be easy since they are using the standard wrapper API that > uses the raw numeric API underneath. > 2. Performance is not too much of an issue since there is no copying > of data back and forth between C/Python and the C++ layer would > most probably be entirely inlined. > 3. Writing weave.inline code should be almost as easy as the blitz > version. Agreed blitz is extremely easy to use but if we had a > fairly powerful wrapper API most of the common stuff could be > easily done via this API. Agreed, getting slices to work would be > some work but if there is significant interest, this should also > be possible. In any case the API could be made sufficiently > useable without the need for blitz conversions. > 4. Compile times should drop since we aren't really looking to redo > blitz but simply provide a clean Numeric API for C/C++. Well, I'm quite afraid that in order to get something like this done right, one would probably end up quite close to blitz (or something similar). The big problem with getting an efficient, low-level class representation for arrays is avoiding temporaries and extra copies in array expressions. As far as I know, the only way to achieve that is to use expression templates, a la blitz. This is just hard. So yes, perhaps there is a way to do this without blitz/ublas. But if one ends up faced with the prospect of writing a full expression template system, might as well use one of the existing ones. I am not saying that blitz has to be used. It's just that from what I've seen, it seems to satisfy the following requirements: - trivial to get a blitz array from a numarray -> no need to change anything in numarray's design to use it. - it tackled the problem of expression analysis to avoid temporaries and extra copying. The technique used was expression templates (very complex code), but I don't know of any simpler solution for this problem. So if you think that it is possible to obtain something similar with much less work, and lower compilation times/simpler code, great. Let's then have this discussion session at Scipy'03! (hint to the organizers: drop us a word about scheduling options, or we can plan for a lunch/dinner/beers time for this :) Best, f. From schaffer at optonline.net Wed Sep 3 10:25:47 2003 From: schaffer at optonline.net (Les Schaffer) Date: Wed, 03 Sep 2003 10:25:47 -0400 Subject: [SciPy-user] Announce: Python 2.3 for Windows (Enthought Edition) now available In-Reply-To: <002101c371ae$826dd4b0$8201a8c0@dellbert> References: <002101c371ae$826dd4b0$8201a8c0@dellbert> Message-ID: <16213.63979.890000.112882@gargle.gargle.HOWL> any chance of getting an installer WITHOUT all the extra stuff. some of us WILL HAVE already installed wxPython, VTK, PIL, Numeric, etc thanks les schaffer From eric at enthought.com Wed Sep 3 11:46:11 2003 From: eric at enthought.com (eric jones) Date: Wed, 03 Sep 2003 09:46:11 -0600 Subject: [SciPy-user] Announce: Python 2.3 for Windows (Enthought Edition) now available In-Reply-To: <16213.63979.890000.112882@gargle.gargle.HOWL> References: <002101c371ae$826dd4b0$8201a8c0@dellbert> <16213.63979.890000.112882@gargle.gargle.HOWL> Message-ID: <3F560CC3.3060804@enthought.com> Hey Les, Actually, the primary purpose of the package is to provide a single click install with all these tools bundled together. Other than that, the Enthought Edition is pretty much a stock version of Python 2.3. For those interested in installing the packages individually, they'll be just as well of starting with the standard Python download at www.python.org and building up from there. eric Les Schaffer wrote: >any chance of getting an installer WITHOUT all the extra stuff. some >of us WILL HAVE already installed wxPython, VTK, PIL, Numeric, etc > >thanks > >les schaffer > > >_______________________________________________ >SciPy-user mailing list >SciPy-user at scipy.net >http://www.scipy.net/mailman/listinfo/scipy-user > > From ferrell at diablotech.com Wed Sep 3 10:49:06 2003 From: ferrell at diablotech.com (Robert Ferrell) Date: Wed, 3 Sep 2003 14:49:06 -0000 (GMT) Subject: [SciPy-user] Low-level code integration discussion at scipy'03? In-Reply-To: <3F550B60.5060108@colorado.edu> References: <3F550B60.5060108@colorado.edu> Message-ID: <2112.128.165.144.120.1062600546.squirrel@webmail.pair.com> I am very interested in such a discussion. I won't have much to contribute, but I'd like to learn. -robert > Hi everyone, > > as I mentioned before, I think it would be great to have a bit of an > open discussion on methods and techniques for plugging low-level code > into python at Scipy'03. I don't mean to teach people how to write an > extension module, but rather what the best/easiest approaches are for > writing time-critical code which manipulates Numpy/numarray arrays. > > A brief summary of the alternatives: > > * Scipy's weave relies on blitz, which is extremely nice and maps > surprisingly well to python arrays. Blitz arrays have slices, ranges, > overloaded arithmetic operators and math functions, etc. In fact, > writing blitz C++ feels almost like writing python code, with the > caveats of handling compile-time type information. > > But blitz development seems to be rather slow these days, and the issue > of access to Blas/lapack from blitz isn't fully settled (i.e., it's not > out-of-the box easy). > > * The ublas library > (http://www.boost.org/libs/numeric/ublas/doc/overview.htm). It has > direct blas support, but it seems to focus strictly on vectors and > matrices, and as far as I see it doesn't support higher rank objects (I > could be wrong, though: > I've been using blitz for 'real' and only looked at the ublas > webpage). > > * Writing low-level code in fortran and using Pearu's f2py. I love > f2py, but I'd prefer my low-level code to have the ability to also use > more information from the python side of things if needed. I think > f2py is a great tool for wrapping existing fortran codes, but not so > much for extending a python program with a few low-level routines. > And there is always the potential need for transposition operations > when going to Fortran because of the row/column memory ordering > discrepancy between C and Fortran. > > * Complete roll-your-own solutions using the Numarray C api. This is > doable, but after using blitz arrays, it feels really low-level. Call > me lazy, but after using python I've become fully enamored of writing > code which reads as cleanly as possible. > > > What I'd like to know is if there is any interest in organizing a bit of > a discussion on this. If an hour can be squeezed in for this in the > schedule, great (and I volunteer to moderate if nobody else wants to). > If not, perhaps some of people involved with these topics (Eric, > Travis, Konrad, Todd and Perry at least, plus whoever else is > interested) might be willing to commit to a lunch/dinner to be spent > talking about this. > > It would be nice to know something in advance, because one of blitz's > current developers (Julian Cummings) is at Caltech. Perhaps we could > ask him to come in and answer some questions about Blitz's future. > Blitz feels like the lowest-impedance fit to python's semantics, but > I'd like to know more about its long-term feasibility before committing > to use it too much. If we set any kind of schedule for this > discussion, I can try to contact Julian. > > Regards, > > Fernando. > > _______________________________________________ > SciPy-user mailing list > SciPy-user at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-user From prabhu at aero.iitm.ernet.in Wed Sep 3 11:52:48 2003 From: prabhu at aero.iitm.ernet.in (Prabhu Ramachandran) Date: Wed, 3 Sep 2003 21:22:48 +0530 Subject: [SciPy-dev] Re: [SciPy-user] Low-level code integration discussion at scipy'03? In-Reply-To: <3F55F787.3080809@colorado.edu> References: <3F550B60.5060108@colorado.edu> <16213.35148.87968.555025@monster.linux.in> <3F55F787.3080809@colorado.edu> Message-ID: <16214.3664.675029.734813@monster.linux.in> >>>>> "FP" == Fernando Perez writes: [ PR on nice C++/C API for Numeric ] FP> Well, I'm quite afraid that in order to get something like FP> this done right, one would probably end up quite close to FP> blitz (or something similar). The big problem with getting an FP> efficient, low-level class representation for arrays is FP> avoiding temporaries and extra copies in array expressions. FP> As far as I know, the only way to achieve that is to use FP> expression templates, a la blitz. This is just hard. So yes, FP> perhaps there is a way to do this without blitz/ublas. But if FP> one ends up faced with the prospect of writing a full FP> expression template system, might as well use one of the FP> existing ones. FP> I am not saying that blitz has to be used. It's just that FP> from what I've seen, it seems to satisfy the following FP> requirements: Sure, if you want all the machinery that blitz provides you'll probably need all that power and complexity internally. However, I still think that having a simpler and easy to use C++ API will help tons. I'm not asking for all the expression template and curiously recursive templated definition stuff. If one can write C++ code that is a lot like Python or simple C and manipulate numeric arrays, it would be really nice. Other points: 1. I guess that weave code will usually be used to optimize the slowest loops. Typically eliminating 'for/while' loops. The trivial (and ancient) Laplacian examples on the SciPy pages demonstrate one such case. My guess is most other uses would be similar. In such cases merely having slices working is not good enough. You might also need to do something non-trivial to the array. At that point I'm not sure how much the niceties of blitz would be used (efficiently)? Could you provide a more illustrative example of what blitz does that could not be done by a simple C++ loop or something? 2. Given the above I don't see a C++ user really worrying about how long the code is so long as the speed advantage is there. 3. If plain old inlined C code does indeed perform better than the blitz equivalents, it sure would be useful to have the cleaner API anyway. Afterall performance is a key issue here. Having a cleaner API (without fancy expression templates but without having to convert between C++ and Python data) would really be useful in any case. Of course, if blitz could still work along with blas support etc. thats great too. :) [snip] FP> - it tackled the problem of expression analysis to avoid FP> temporaries and extra FP> copying. The technique used was expression templates (very FP> complex code), but I don't know of any simpler solution for FP> this problem. Well, I'm sure I would not mind writing this kind of loop (taken from here http://www.scipy.org/site_content/weave/python_performance.html): double tmp, err, diff; err = 0.0; for (int i=1; i times/simpler code, great. Let's then have this discussion FP> session at Scipy'03! (hint to the organizers: drop us a word Sure. cheers, prabhu From fperez at colorado.edu Wed Sep 3 12:42:28 2003 From: fperez at colorado.edu (Fernando Perez) Date: Wed, 03 Sep 2003 10:42:28 -0600 Subject: [SciPy-dev] Re: [SciPy-user] Low-level code integration discussion at scipy'03? In-Reply-To: <16214.3664.675029.734813@monster.linux.in> References: <3F550B60.5060108@colorado.edu> <16213.35148.87968.555025@monster.linux.in> <3F55F787.3080809@colorado.edu> <16214.3664.675029.734813@monster.linux.in> Message-ID: <3F5619F4.9060003@colorado.edu> Prabhu Ramachandran wrote: > 1. I guess that weave code will usually be used to optimize the > slowest loops. Typically eliminating 'for/while' loops. The > trivial (and ancient) Laplacian examples on the SciPy pages > demonstrate one such case. My guess is most other uses would be > similar. In such cases merely having slices working is not good > enough. You might also need to do something non-trivial to the > array. At that point I'm not sure how much the niceties of blitz > would be used (efficiently)? Could you provide a more > illustrative example of what blitz does that could not be done by > a simple C++ loop or something? It's not a matter of being impossible in loops, just that the blitz syntax is incredibly compact. Consider computing Numeric's innerproduct() operation for a rank-2 array M and a rank-6 one T, storing the result in U. In blitz, the code reads: // 6d version void mat_ten_inner(Array& M, Array& T, Array& U ) { firstIndex i1; secondIndex i2; thirdIndex i3; fourthIndex i4; fifthIndex i5; sixthIndex i6; seventhIndex j; U = sum(M(i1,j)*T(i2,i3,i4,i5,i6,j),j); } That's it. ONE line of actual code! A version of this done with hand loops requires obviously 7 nested for loops. Since I needed similar code for dimensions 1..6, I wrote preprocessor macros to generate all versions from a 'template' (meaning, another macro, not a C++ template<>). This is, of course, ugly. Having said that, the above one-liner performs about 3 times slower than the loop macro version for d=6. For d=1 they are about even, the blitz one-liner gets worse as d increases. I posted to the blitz list asking about this, but no response so far. So, in the end, I'm writing my own loops too :) This is just to point that I'm ok with writing loops too, even though I'd love blitz to handle things like the above better. What blitz DOES buy you is A(i,j,k,l...) type indexing of high-rank arrays, which is not trivial with the C Numeric API. And that is important. Writing loops isn't bad, but all the manual pointer arithmetic currently necessary with the existing APIs is rather annoying. It's a matter of balancing abstraction with performance. Blitz provides a lot of abstraction, but performance isn't very good. The subset of blitz which gives just indexing (you do the rest yourself) seems to maintain pretty good performance in many cases (though I need to do more precise benchmarks against fortran). > 3. If plain old inlined C code does indeed perform better than the > blitz equivalents, it sure would be useful to have the cleaner API > anyway. Afterall performance is a key issue here. Having a > cleaner API (without fancy expression templates but without having > to convert between C++ and Python data) would really be useful in > any case. This, we agree 100% on. In fact, if the C API offered a way to index high rank arrays without manually computing stride offsets on every access, that would probably satisfy a significant fraction of usage cases. I consider one-liners like the above icing on the cake, but A(i,j,k) indexing is really a significant change which makes development far more productive. > Well, I'm sure I would not mind writing this kind of loop (taken from > here http://www.scipy.org/site_content/weave/python_performance.html): > > double tmp, err, diff; > err = 0.0; > for (int i=1; i for (int j=1; j tmp = u(i,j); > u(i,j) = ((u(i-1,j) + u(i+1,j))*dy2 + > (u(i,j-1) + u(i,j+1))*dx2)*dnr_inv; > diff = u(i,j) - tmp; > err += diff*diff; > } > } I don't either. As I said, the main consideration for me is clean indexing of rank2+ arrays. Everything else I take as extra credit, and I can live without. For example, blitz has 'stencils' to do the above, and in 3d cases they do simplify writing the code a lot. But I haven't tested their performance, and after seeing my innerproduct() example above, I'd be at least a bit skeptical. So loops are fine with me. Best, f. From prabhu at aero.iitm.ernet.in Wed Sep 3 13:56:59 2003 From: prabhu at aero.iitm.ernet.in (Prabhu Ramachandran) Date: Wed, 3 Sep 2003 23:26:59 +0530 Subject: [SciPy-dev] Re: [SciPy-user] Low-level code integration discussion at scipy'03? In-Reply-To: <3F5619F4.9060003@colorado.edu> References: <3F550B60.5060108@colorado.edu> <16213.35148.87968.555025@monster.linux.in> <3F55F787.3080809@colorado.edu> <16214.3664.675029.734813@monster.linux.in> <3F5619F4.9060003@colorado.edu> Message-ID: <16214.11115.945651.476138@monster.linux.in> >>>>> "FP" == Fernando Perez writes: [ FP's nice 6d example ] FP> That's it. ONE line of actual code! A version of this done FP> with hand loops requires obviously 7 nested for loops. Since FP> I needed similar code for dimensions 1..6, I wrote FP> preprocessor macros to generate all versions from a 'template' FP> (meaning, another macro, not a C++ template<>). This is, of FP> course, ugly. Interesting example but I'd imagine that apart from you and some string theorists (are there any here?) most of us mere mortals would deal with 3 to 4 d data. ;-) Agreed a one liner is a lot nicer but 3 nested loops are quite normal. So indeed blitz does have lots of advantages. In fact its the fastest way to get a 3 fold increase over plain Python Numeric. FP> Having said that, the above one-liner performs about 3 times FP> slower than the loop macro version for d=6. For d=1 they are FP> about even, the blitz one-liner gets worse as d increases. I FP> posted to the blitz list asking about this, but no response so FP> far. Ahh. :) [snip] >> 3. If plain old inlined C code does indeed perform better than >> the >> blitz equivalents, it sure would be useful to have the cleaner >> API anyway. Afterall performance is a key issue here. Having >> a cleaner API (without fancy expression templates but without >> having to convert between C++ and Python data) would really be >> useful in any case. FP> This, we agree 100% on. In fact, if the C API offered a way FP> to index high rank arrays without manually computing stride FP> offsets on every access, that would probably satisfy a FP> significant fraction of usage cases. I consider one-liners FP> like the above icing on the cake, but A(i,j,k) indexing is FP> really a significant change which makes development far more FP> productive. Great! So we have three strong votes on this on this. cheers, prabhu From perry at stsci.edu Wed Sep 3 14:01:44 2003 From: perry at stsci.edu (Perry Greenfield) Date: Wed, 3 Sep 2003 14:01:44 -0400 Subject: [SciPy-dev] Re: [SciPy-user] Low-level code integrationdiscussion at scipy'03? In-Reply-To: <16214.11115.945651.476138@monster.linux.in> Message-ID: > > FP> This, we agree 100% on. In fact, if the C API offered a way > FP> to index high rank arrays without manually computing stride > FP> offsets on every access, that would probably satisfy a > FP> significant fraction of usage cases. I consider one-liners > FP> like the above icing on the cake, but A(i,j,k) indexing is > FP> really a significant change which makes development far more > FP> productive. > Are you just talking about C macros to do the indexing (including strides? Perry From cnetzer at sonic.net Thu Sep 4 02:39:47 2003 From: cnetzer at sonic.net (Chad Netzer) Date: Wed, 03 Sep 2003 23:39:47 -0700 Subject: [SciPy-user] STFT implementations in Python In-Reply-To: References: Message-ID: <1062657587.8001.3.camel@adsl-209.204.179.133.sonic.net> On Tue, 2003-09-02 at 22:29, Andrew Nesbit wrote: > Does anybody know if there exist any Python implementations for STFT > and inverse STFT? I can code it myself, but I just wanted to know if > anybody has already done this, as it seems like it would be a pretty > common thing. Will wavelets do? They are on their way... Email if you need something now. -- Chad Netzer From alnesbit at students.cs.mu.oz.au Thu Sep 4 10:57:37 2003 From: alnesbit at students.cs.mu.oz.au (Andrew Nesbit) Date: Fri, 05 Sep 2003 00:57:37 +1000 Subject: [SciPy-user] STFT implementations in Python In-Reply-To: <1062657587.8001.3.camel@adsl-209.204.179.133.sonic.net> (Chad Netzer's message of "Wed, 03 Sep 2003 23:39:47 -0700") References: <1062657587.8001.3.camel@adsl-209.204.179.133.sonic.net> Message-ID: Chad Netzer writes: [snip... STFT implementation desired] > Will wavelets do? They are on their way... Email if you need something > now. Thanks for the reply, Chad. I'd better stick with the standard windowed STFT for now, as the rest of the system is designed around that. But I'll be looking forward to playing with wavelet transforms in the future, for sure. Cheers, Andrew. From chris at fonnesbeck.org Fri Sep 5 15:17:26 2003 From: chris at fonnesbeck.org (Christopher Fonnesbeck) Date: Fri, 5 Sep 2003 15:17:26 -0400 Subject: [SciPy-user] unhelpful error messages in weave Message-ID: <95D0E08C-DFD5-11D7-BB1D-000A956FDAC0@fonnesbeck.org> Hi Everyone, I'm trying to move some C++ code over to weave, but am running into some problems that are difficult to debug. Specifically, there are try/catch messages referring to lines of code in my module that do not exist. Here is the error message: [Histrionicus:python/Biometric/tmp] chris% python2.3 Blackduck.py file changed Compiling code... Blackduck.py: In function `PyObject* compiled_func(PyObject*, PyObject*)': Blackduck.py:426: parse error before `catch' Blackduck.py:432: must have at least one catch per try block Traceback (most recent call last): File "Blackduck.py", line 833, in ? nxt_state = weave.inline(sd_code,['cur_state','dec','wtp'],verbose=1) File "/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site- packages/weave/inline_tools.py", line 335, in inline auto_downcast = auto_downcast, File "/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site- packages/weave/inline_tools.py", line 439, in compile_function verbose=verbose, **kw) File "/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site- packages/weave/ext_tools.py", line 340, in compile verbose = verbose, **kw) File "/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site- packages/weave/build_tools.py", line 272, in build_extension setup(name = module_name, ext_modules = [ext],verbose=verb) File "/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site- packages/scipy_distutils/core.py", line 42, in setup return old_setup(**new_attr) File "/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/ distutils/core.py", line 166, in setup raise SystemExit, "error: " + str(msg) weave.build_tools.CompileError: error: command 'gcc' failed with exit status 1 My inline code ends at line 420, but I get error messages from weave outside those lines. I dont use 'catch' anywhere in my code, yet I am given an error message referring to it. Here is the call and the code for those willing to look into this: sd_code = ''' #line 56 "Blackduck.py" #define NPOP 3 #define NPROD 2 #define NSURV 2 #define NAGE 2 #define NSEX 2 #define NHARV 6 py::list nxt_state(NPOP); double Harv[NHARV][NPROD][NAGE][NSEX][NPOP], Spr_A[NSEX][NPOP],ss[NSEX], wts[NSURV] = {0.881, 0.119},//production model weights Harv_S[NPROD][NAGE][NSEX][NPOP], Harv_N[NPROD][NAGE][NSEX][NPOP], next[NPROD][NSURV][NAGE][NSEX][NPOP], Fall_Pre[NPROD][NAGE][NSEX][NPOP], Fall_N[NPROD][NAGE][NSEX][NPOP], movekill[NAGE][NSEX][NPOP][NHARV], //objective function values Value [2] = {1., 0.} , //values for bd and mallard harvest cripple [2] = {0.20, 0.20} ; int i = 0, j = 0, k = 0, q = 0, m = 0, n = 0, age = 0, sex = 0, pop = 0, pop0 = 0, pop1 = 0, harv = 0, prod = 0, surv = 0, init = 1, done = 0, debug = 0; static const double P_am = 0.543 , DV[NAGE][NSEX]={ {1,0.94}, {2.03, 1.88} }, b[NPROD][NPOP][3] ={ { {1.755, -0.2455, -0.2345}, { 1.164, -0.2455, -0.2345}, {0.9171, -0.2455, -0.2345} }, { {1.463, -0.2392, 0}, {1.674, -0.7436, 0}, {0.8289, -0.2009, 0} } }, Ac[NSURV][2]= { {1.033288, 0}, {1.033288, -0.000001} }, move_n[NAGE][NSEX][NPOP][3] ={ { { {0.984, .016, 0}, {.081, 0.904, .015}, {0, .026, .974} }, { {.974, .026, 0}, {.052, .93, .018}, {0 ,.014 ,.986} } }, { { {0.984, .016, 0}, {.081, 0.904, .015}, {0, .026, .974} }, { {.974, .026, 0}, {.052, .93, .018}, {0 ,.014 ,.986} } } }, move_s[NAGE][NSEX][NPOP][3]= { { { {.506, .214, .280}, {.048, .689, .263}, {.002, .914, .084} }, { {.451, .262, 0.287}, {.062, .686, .252}, { 0.002, .89, .108} } }, { { {.506, .214, .280}, {.048, .689, .263}, {.002, .914, .084} }, { {.451, .262, 0.287}, {.062, .686, .252}, { 0.002, .89, .108} } } }, fidel[NAGE][NSEX][NPOP][NPOP]= { { { {0.89,0.055,0.055}, {0.065,0.87,0.065}, {0.06,0.06,0.88} }, { {0.88,0.06,0.06}, {0.07,0.86,0.07}, {0.075,0.075,0.85} } }, { { {0.39,0.305,0.305}, {0.32,0.36,0.32}, {0.325,0.325, 0.35} }, { {0.41,0.295,0.295}, {0.31,0.38,0.31}, {0.295,0.295, 0.41} } } }, ssf=0.75; double temp; double N[NPOP],M[NPOP], A[NPROD][NPOP], H[NHARV][NAGE][NSEX], K[NHARV][NAGE][NSEX], Kill_N[NPROD][NAGE][NSEX][NPOP], Kill_S[NPROD][NAGE][NSEX][NPOP], Wint[NPROD][NAGE][NSEX][NPOP], Wint_T[NPROD][NPOP], SS_m[NPROD][NSURV][NPOP], SS[NPROD][NSURV][NPOP][NAGE][NSEX], surv_joint[NPROD][NSURV][NAGE][NSEX][NPOP], spring_pre[NPROD][NSURV][NAGE][NSEX][NPOP], next_[NPROD][NSURV][NAGE][NSEX][NPOP][NPOP], pwt,nval,mval,harv_dec,state, wnext[NPROD][NSURV][NAGE][NSEX][NPOP], hss[NAGE][NSEX][NPOP]; // Index constant values. //Jianping add ss[1]=ssf; ss[0]=ssf*(P_am/(1.-P_am)); //Loop over breeding populations for (pop=0;pop<3;pop++) { // Scaled population sizes nval = py_to_float(PyList_GetItem(cur_state,pop),"nval"); N[pop] = nval; mval = py_to_float(PyList_GetItem(cur_state,pop+3),"mval"); M[pop] = mval; // Spring adults Spr_A [0][pop]=P_am *N[pop]; Spr_A [1][pop]=(1-P_am)*N[pop]; //Fall adults -- loop over production models for (prod=0;prod<2;prod++) { // Calculate fall age ratio A[prod][pop]= b[prod][pop][0] + b[prod][pop][1]*N[pop]/100000. + b[prod][pop][2]*M[pop]/100000. ; A[prod][pop] =exp(A[prod][pop]); for (sex=0;sex<2;sex++) { // Spring survival Fall_Pre[prod][0][sex][pop] =Spr_A[sex][pop]*ss[sex]; // Recruitment Fall_Pre[prod][1][sex][pop]= 0.5*A[prod][pop]* (Fall_Pre[prod][0][0][pop]+Fall_Pre[prod][0][1][pop]); } } for (k=0;k<6;k++) { for (age=0;age<2;age++) { for (sex=0;sex<2;sex++) { // Harvest rates harv_dec = py_to_float(PyList_GetItem(dec,k),"harv_dec"); H[k][age][sex]=DV[age][sex]*harv_dec; K[k][age][sex]=H[k][age][sex]/(1-cripple[0]); } } } //Joint movement and kill rates for (age=0;age<2;age++) { for (sex=0;sex<2;sex++) { // Loop over breeding areas for (pop=0;pop<3;pop++) { // Loop over harvest areas for (harv=0;harv<3;harv++) { movekill[age][sex][pop][harv]=move_n[age][sex][pop][harv] *K[harv][age][sex]; // age and sex specific? } for (harv=0;harv<3;harv++) { movekill[age][sex][pop][harv+3]= move_s[age][sex][pop][harv]*K[harv+3][age][sex]; } //Suvival of southern hunting hss[age][sex][pop]=1- (movekill[age][sex][pop][3]+movekill[age][sex][pop][4] +movekill[age][sex][pop][5]); } } } // Movement to northern harvest areas and harvest // Loop over production models for (prod=0;prod<2;prod++) { for (age=0;age<2;age++) { for (sex=0;sex<2;sex++) { //Loop over pop areas // these are survivors of northern breeding areas for (pop=0;pop<3;pop++) { // Loop over northern harvest areas Kill_N[prod][age][sex][pop]=0; Kill_S[prod][age][sex][pop]=0; //Nothern kill Kill_N[prod][age][sex][pop]=Fall_Pre[prod][age][sex][pop]* (movekill[age][sex][pop][0]+movekill[age][sex][pop][1]+movekill[age][sex ][pop][2]); for(harv=0;harv<3;harv++) { Harv[harv][prod][age][sex][pop]=Fall_Pre[prod][age][sex][pop]* movekill[age][sex][pop][harv]*(1-cripple[0]); } //population after northern harvest with respect to breeding area Fall_N[prod][age][sex][pop]=Fall_Pre[prod][age][sex][pop]- Kill_N[prod][age][sex][pop]; //Convert kill to harvest Harv_N[prod][age][sex][pop]=Kill_N[prod][age][sex][pop]*(1- cripple[0]); //Southern kill Kill_S[prod][age][sex][pop]=Fall_N[prod][age][sex][pop]* (movekill[age][sex][pop][3]+movekill[age][sex][pop][4]+movekill[age][sex ][pop][5]); for(harv=3;harv<6;harv++) { Harv[harv][prod][age][sex][pop]=Fall_Pre[prod][age][sex][pop]* movekill[age][sex][pop][harv]*(1-cripple[1]); } //population after southern harvest Wint[prod][age][sex][pop]=Fall_N[prod][age][sex][pop]- Kill_S[prod][age][sex][pop]; //convert kill to harvest Harv_S[prod][age][sex][pop]=Kill_S[prod][age][sex][pop]*(1- cripple[1]); } }//end of for (sex=0;sex<2;sex++) } //end of for (age=0;age<2;age++) for (pop=0; pop < NPOP; pop++) { Wint_T[prod][pop]=0; for (age=0;age<2;age++) { for (sex=0;sex<2;sex++) { // Sum populations over age and sex, Wint_T[prod][pop]+=Wint[prod][age][sex][pop]; } } } for (surv=0;surv<2;surv++) { for (pop=0;pop<3;pop++) { // Winter survival, males SS_m[prod][surv][pop] = Ac[surv][0] + Ac[surv][1]*3*Wint_T[prod][pop]; temp=SS_m[prod][surv][pop]; SS_m[prod][surv][pop]=exp(temp)/(1+exp(temp)); for (age=0;age<2;age++) { for (sex=0;sex<2;sex++) { // # Survival by age and sex SS[prod][surv][pop][age][sex] =SS_m[prod][surv][pop]/ss[sex]; // # Joint survival of Southern hunting surv_joint[prod][surv][age][sex][pop] =SS[prod][surv][pop][age][sex] * hss[age][sex][pop]; // # Spring population pre-movement spring_pre[prod][surv][age][sex][pop] = Fall_N[prod][age][sex][pop] * surv_joint[prod][surv][age][sex][pop] ; }//for(sex= }//for age= }//for pop= for (age=0;age<2;age++) { for (sex=0;sex<2;sex++) { // # Migrate back to breeding areas to determine next years populations for (pop1=0;pop1<3; pop1++) { //next_[pop][prod][surv][age][sex]=0; for (pop0=0;pop0<3; pop0++) { next_[prod][surv][age][sex][pop1][pop0]=spring_pre[prod][surv][age][sex] [pop0] * fidel[age][sex][pop0][pop1]; } //aggregate t return breeding area next[prod][surv][age][sex][pop1]=next_[prod][surv][age][sex][pop1][0]+ next_[prod][surv][age][sex][pop1][1]+ next_[prod][surv][age][sex][pop1][2]; //# Weighted next year pwt = py_to_float(PyList_GetItem(wtp,prod),"pwt"); wnext[prod][surv][age][sex][pop1]=next[prod][surv][age][sex][pop1]*pwt*w ts[surv]; }//edn pop1 }//end of for (sex=0;sex<2;sex++) }//end of for (age=0;age<2;age++) }//end of for (surv=0;surv<3;surv++) }//end of for (prod=0;prod<2;prod++) // # Sum across age sex and models to get next year's populations for (pop=0;pop < NPOP;pop++) { //nxt_state[pop]=0; for (prod=0;prod < NPROD;prod++) { for (age=0;age < NAGE;age++) { for(surv=0;surv<2;surv++) { for (sex=0;sex < NSEX;sex++) { state = py_to_float(PyList_GetItem(nxt_state,pop),"state"); PyList_SetItem(nxt_state,pop,PyFloat_FromDouble(state + wnext[prod][surv][age][sex][pop])); } } } } } return_val = nxt_state; ''' if __name__=='__main__': n = [100000,100000,100000] m = [10000,1000,1000] cur_state = n+m dec = [0.1]*6 wtp = [0.5,0.5] nxt_state = weave.inline(sd_code,['cur_state','dec','wtp'],verbose=1) print nxt_state thanks a bunch in advance, cjf -- Christopher J. Fonnesbeck (chris at fonnesbeck dot org) GA Coop. Fish & Wildlife Research Unit, University of Georgia From fperez at colorado.edu Fri Sep 5 15:24:17 2003 From: fperez at colorado.edu (Fernando Perez) Date: Fri, 05 Sep 2003 13:24:17 -0600 Subject: [SciPy-user] unhelpful error messages in weave In-Reply-To: <95D0E08C-DFD5-11D7-BB1D-000A956FDAC0@fonnesbeck.org> References: <95D0E08C-DFD5-11D7-BB1D-000A956FDAC0@fonnesbeck.org> Message-ID: <3F58E2E1.3060909@colorado.edu> Christopher Fonnesbeck wrote: > Hi Everyone, > > I'm trying to move some C++ code over to weave, but am running into > some problems that are difficult to debug. Specifically, there are > try/catch messages referring to lines of code in my module that do not > exist. Here is the error message: A couple of general tips: 1. try first with python 2.2. I've seen weird messages pop up using py2.3 which don't appear with 2.2 (and weave.inline, of course). I haven't had the time to make a small, clean test case to submit for Eric to look at, though. 2. use the verbose option in inline() and look directly at the ~/.python_compiled2.2/NNNNNNNNNNNNNNNNNNN.cpp file which weave auto-generates. It's big, but once you learn how it gets organized, you'll navigate it pretty quickly. You can try to compile it separately yourself. I've debugged weave.inlined modules this way before. Best, f. From chris at fonnesbeck.org Fri Sep 5 18:04:54 2003 From: chris at fonnesbeck.org (Christopher Fonnesbeck) Date: Fri, 5 Sep 2003 18:04:54 -0400 Subject: [SciPy-user] unhelpful error messages in weave Message-ID: Thanks for the help. Unfortunately, I need to be working in Python2.3, so perhaps I will try coding the thing in Fortran and use f2py. Incidentally, following your second point, there is wierd stuff in the .cpp file, namely the following: catch(...) { return_val = py::object(); exception_occured = 1; } which appears without a try statement. cjf Christopher Fonnesbeck wrote: > Hi Everyone, >>I'm trying to move some C++ code over to weave, but am running into >some problems that are difficult to debug. Specifically, there are >try/catch messages referring to lines of code in my module that do not >exist. Here is the error message: A couple of general tips: 1. try first with python 2.2. I've seen weird messages pop up using py2.3 which don't appear with 2.2 (and weave.inline, of course). I haven't had the time to make a small, clean test case to submit for Eric to look at, though. 2. use the verbose option in inline() and look directly at the ~/.python_compiled2.2/NNNNNNNNNNNNNNNNNNN.cpp file which weave auto-generates. It's big, but once you learn how it gets organized, you'll navigate it pretty quickly. You can try to compile it separately yourself. I've debugged weave.inlined modules this way before. Best, f. -- Christopher J. Fonnesbeck (chris at fonnesbeck dot org) GA Coop. Fish & Wildlife Research Unit, University of Georgia -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 1619 bytes Desc: not available URL: From al.danial at ngc.com Fri Sep 5 18:17:34 2003 From: al.danial at ngc.com (al.danial at ngc.com) Date: Fri, 5 Sep 2003 15:17:34 -0700 Subject: [SciPy-user] how to build with NetCDF? Message-ID: <48C9AB115A3DEB44AA5CA4B56BB6E4B5E1495A@MBSP02.services.sp.trw.com> Hello, I'm an old-time Perl guy trying out Python. I'm not having luck building SciPy with NetCDF support. The "python setup.py install" step goes fine and scipy.test(level=1) within Python looks pretty good, +700 tests pass and two failures. However it did not build the NetCDF IO stuff because "from Scientific.IO.NetCDF import NetCDFFile" produces: Traceback (most recent call last): File "./cmp_nc.py", line 32, in ? from Scientific.IO.NetCDF import NetCDFFile ImportError: No module named Scientific.IO.NetCDF (I'm using cmp_nc.py from http://starship.python.net/~hinsen/ScientificPython/netcdf_example2.tar.gz to check the NetCDF module witin SciPy.) Can any one give me clues on how to make the build process see my NetCDF lib and include directories? They are not in the usual places like /usr/lib or /usr/local/lib so I figure I need to help SciPy find them but don't know. The INSTALL.txt file doesn't give any hints on how to make extra packages visible during the build. Details: x86 RedHat Linux v8.0 Python v2.3 GCC v3.2 netcdf-3.5.1-beta13 SciPy-0.2.0_alpha_200.4161_src.tar.gz -- Al From wdbouk at hotmail.com Fri Sep 5 18:40:07 2003 From: wdbouk at hotmail.com (Wassim Dbouk) Date: Fri, 5 Sep 2003 18:40:07 -0400 Subject: [SciPy-user] Nelson and siegel codes Message-ID: Hello Daniel, I need to use matlab to compute the yield curve using Nelson and siegel approach. However, i don't find enough resources to the the matlab codes for such a topic.I am starting from scratch with matlab and i am facing difficulties in progressing. I was searching the web and I found your post where you were saying that you have used matlab with Nelson and Siegel. I am wondering if you can email me the M-file. I hope I am not asking too much but this would really help me a lot. Best wishes wassim -------------- next part -------------- An HTML attachment was scrubbed... URL: From pajer at iname.com Sat Sep 6 19:42:20 2003 From: pajer at iname.com (Gary Pajer) Date: Sat, 6 Sep 2003 19:42:20 -0400 Subject: [SciPy-user] Batteries missing from Python 2.3 for Windows (Enthought Edition) References: <002101c371ae$826dd4b0$8201a8c0@dellbert> Message-ID: <000b01c374d0$8404c2f0$01fd5644@playroom> This package is not entirely click-and-run. At least on my machine. OpenGL is missing, so chaco.tkplt won't even import. I can't find a python 2.3 binary installer for pyopengl. Something is screwy with wxPython. I get frequent deprecation warnings using boa-constructor, scipy.plt.plot, and chaco.wxplt.plot. The warnings completely choke my boa-assisted application. Anyone else have these problems, or am I screwed up individually? -Gary ----- Original Message ----- From: "David C. Morrill" To: ; ; Sent: Tuesday, September 02, 2003 8:01 PM Subject: [SciPy-user] Announce: Python 2.3 for Windows (Enthought Edition) now available Just a quick heads up that Python 2.3 for Windows (Enthought Edition) is now available at: http://www.enthought.com This is in addition to the Python 2.2.3 for Windows (Enthought Edition) that was previously announced. Besides the obvious feature of being based on Python 2.3, this new version also includes updates to several other packages, such as wxPython So if you've been putting off giving Python 2.3 a spin, now might be a good time to upgrade. And if you do decide to give it a try, we'd also appreciate hearing from you either on the mailing lists or on the bug tracker concerning what you think about the new Python distribution. Enjoy! The Python guys at Enthought, Inc. From ChuckEsterbrook at yahoo.com Mon Sep 8 06:33:46 2003 From: ChuckEsterbrook at yahoo.com (ChuckEsterbrook at yahoo.com) Date: Mon, 8 Sep 2003 03:33:46 -0700 Subject: [SciPy-user] SciPy 2003 Parking? Message-ID: <20039833346.168255@workstation> Can anyone tell me what SciPy 2003 parking is going to be like? The CalTech site has a parking form, but I don't know if I'm supposed to get back a sticker or what... Do I just snail mail them the form here? http://atc.caltech.edu/CIT_parking/visit_reg.pdf -Chuck -- http://ChuckEsterbrook.com/ From jb.richet at areas.asso.fr Mon Sep 8 11:49:36 2003 From: jb.richet at areas.asso.fr (Jean-Baptiste Richet - AREAS) Date: Mon, 08 Sep 2003 16:49:36 +0100 Subject: [SciPy-user] [weave] newbie : installation problem Message-ID: <3F5CA510.1030702@areas.asso.fr> Hello, weave could be highly usefull to me, but I can't have it work correctly on my PC, and I don't know what to do. Could you help me ? I installed the latest zip package by "python setup.py install", on a python 2.3 installation (OS = Windows ME), and here is a result when trying it : ========================= IDLE 1.0 >>> import weave >>> a = 123 >>> weave.inline('printf("%d\\n",a);',['a']) Exception exceptions.AttributeError: "DbfilenameShelf instance has no attribute 'writeback'" in Traceback (most recent call last): File "", line 1, in -toplevel- weave.inline('printf("%d\\n",a);',['a']) File "C:\DEVELOPPEMENT\PYTHON23\Lib\site-packages\weave\inline_tools.py", line 327, in inline auto_downcast = auto_downcast, File "C:\DEVELOPPEMENT\PYTHON23\Lib\site-packages\weave\inline_tools.py", line 426, in compile_function verbose=verbose, **kw) File "C:\DEVELOPPEMENT\PYTHON23\Lib\site-packages\weave\ext_tools.py", line 349, in compile verbose = verbose, **kw) File "C:\DEVELOPPEMENT\PYTHON23\Lib\site-packages\weave\build_tools.py", line 194, in build_extension setup(name = module_name, ext_modules = [ext],verbose=verb) File "c:\developpement\python23\lib\distutils\core.py", line 166, in setup raise SystemExit, "error: " + str(msg) CompileError: error: command 'g++' failed with exit status 1 >>> =========================== The gcc I use comes from MinGW and is version 3.2. I tried out gcc 2.95, and it was nearly the same (error at the same place, but 'cc' was blaimed). I tried cygwin, and it was not different. I tried python 2.2, and the result was similar. Any idea ? thanks a lot for your help. -- Jean-Baptiste Richet AREAS _________________________________ Association r?gionale pour l'?tude et l'am?lioration des sols 2, avenue Foch 76460 Saint Val?ry en Caux t?l : +33 2 35 97 25 12 fax : +33 2 35 97 25 73 _________________________________ From jcollins at boulder.net Mon Sep 8 17:04:18 2003 From: jcollins at boulder.net (Jeffery D. Collins) Date: Mon, 08 Sep 2003 15:04:18 -0600 Subject: [SciPy-user] IPython completion Message-ID: <3F5CEED2.3010806@boulder.net> Filename completion for IPython does not work for me under Python-2.3, but does for Python-2.2. That is, typing a does nothing. It seems to work fine for everything else. Startup dialog: Python 2.3 (#11, Sep 5 2003, 13:12:43) Type "copyright", "credits" or "license" for more information. IPython 0.4.0 -- 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. IPython profile: numeric Activating auto-logging. Current session state plus future input saved to: ipython.log Logging mode: rotate *** Your version of Gnuplot appears not to have mouse support. *** Type `gphelp` for help on the Gnuplot integration features. -- Jeffery Collins From fperez at colorado.edu Mon Sep 8 18:16:26 2003 From: fperez at colorado.edu (Fernando Perez) Date: Mon, 08 Sep 2003 16:16:26 -0600 Subject: [SciPy-user] IPython completion In-Reply-To: <3F5CEED2.3010806@boulder.net> References: <3F5CEED2.3010806@boulder.net> Message-ID: <3F5CFFBA.8040600@colorado.edu> Jeffery D. Collins wrote: > Filename completion for IPython does not work for me under Python-2.3, > but does for Python-2.2. That is, typing a does nothing. It > seems to work fine for everything else. > > Startup dialog: > > Python 2.3 (#11, Sep 5 2003, 13:12:43) > Type "copyright", "credits" or "license" for more information. > > IPython 0.4.0 -- 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. Mmh, I just tested 2.3 with ipython 0.5.0, and tab works fine for me. I did fix a few 2.3-related warnings, but I can't see how this might be related to readline. Can you test 'import readline' in a normal (non-ipython) python shell? I want to know if your readline support is indeed correct. BTW, you might want to upgrade to 0.5.0, as a nasty generator (potentially dangerous side-effects) bug was fixed recently. Cheers, f From jcollins at boulder.net Mon Sep 8 18:56:16 2003 From: jcollins at boulder.net (Jeffery D. Collins) Date: Mon, 08 Sep 2003 16:56:16 -0600 Subject: [SciPy-user] IPython completion In-Reply-To: <3F5CFFBA.8040600@colorado.edu> References: <3F5CEED2.3010806@boulder.net> <3F5CFFBA.8040600@colorado.edu> Message-ID: <3F5D0910.40501@boulder.net> Fernando Perez wrote: > Jeffery D. Collins wrote: > >> Filename completion for IPython does not work for me under >> Python-2.3, but does for Python-2.2. That is, typing a does >> nothing. It seems to work fine for everything else. >> Startup dialog: >> >> Python 2.3 (#11, Sep 5 2003, 13:12:43) >> Type "copyright", "credits" or "license" for more information. >> >> IPython 0.4.0 -- 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. > > > Mmh, I just tested 2.3 with ipython 0.5.0, and tab works fine for me. > I did fix a few 2.3-related warnings, but I can't see how this might > be related to readline. I just installed 0.5.0 - same thing. > > Can you test 'import readline' in a normal (non-ipython) python > shell? I want to know if your readline support is indeed correct. It imports just fine. Can you suggest any other tests I should try on the readline module? > > BTW, you might want to upgrade to 0.5.0, as a nasty generator > (potentially dangerous side-effects) bug was fixed recently. > > Cheers, > > f > > _______________________________________________ > SciPy-user mailing list > SciPy-user at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-user -- Jeffery Collins From fperez at colorado.edu Mon Sep 8 19:14:12 2003 From: fperez at colorado.edu (Fernando Perez) Date: Mon, 08 Sep 2003 17:14:12 -0600 Subject: [SciPy-user] IPython completion In-Reply-To: <3F5D0910.40501@boulder.net> References: <3F5CEED2.3010806@boulder.net> <3F5CFFBA.8040600@colorado.edu> <3F5D0910.40501@boulder.net> Message-ID: <3F5D0D44.5070403@colorado.edu> Jeffery D. Collins wrote: >>Can you test 'import readline' in a normal (non-ipython) python >>shell? I want to know if your readline support is indeed correct. > > > It imports just fine. Can you suggest any other tests I should try on > the readline module? Weird, very weird. Try (in ipython): In [1]: import readline In [2]: readline? Type: module Base Class: String Form: Namespace: Interactive File: /usr/local/lib/python2.3/lib-dynload/readline.so This is the oputput from my machine. Then do a dir(readline). This is what I get: In [3]: dir(readline) Out[3]: ['__doc__', '__file__', '__name__', 'add_history', 'get_begidx', 'get_completer', ... If all looks normal, try renaming your ~/.ipython directory so that IPython makes a new one, and see if that helps. You might have some readline-related customizations which break under 2.3. I wasn't aware of any changes made to readline in python 2.3 though, so I'm shooting a bit in the dark here. Also, let me know which platform you are running under. Cheers, f. From cnetzer at sonic.net Mon Sep 8 20:36:59 2003 From: cnetzer at sonic.net (Chad Netzer) Date: Mon, 08 Sep 2003 17:36:59 -0700 Subject: [SciPy-user] SciPy 2003 Parking? In-Reply-To: <20039833346.168255@workstation> References: <20039833346.168255@workstation> Message-ID: <1063067818.1871.28.camel@adsl-209.204.179.133.sonic.net> On Mon, 2003-09-08 at 03:33, ChuckEsterbrook at yahoo.com wrote: > Can anyone tell me what SciPy 2003 parking is going to be like? The CalTech site has a parking form, but I don't know if I'm supposed to get back a sticker or what... > > Do I just snail mail them the form here? > http://atc.caltech.edu/CIT_parking/visit_reg.pdf I looked at those forms long and hard. It seems that only Campus personnel can request visitor passes. If you don't have a contact there, it seems you are out of luck. This is a confusing issue, since the SciPy conference page implies there is ample parking (by pointing out the parking structures), but going to the CalTech pages they are adamant about NOT allowing parking without being a special permit. See here: http://atc.caltech.edu/CIT_Parking/home.htm "Welcome to the Caltech Parking Office home page. Commencing October 8, 2001 all vehicles utilizing Caltech parking facilities must be registered and display a Caltech parking placard." If anyone who is in the know can clear this up, it would be nice, even at this late date; ie. whether there WILL or WILL NOT be parking available at the parking areas indicated at the following link: http://www.scipy.org/site_content/scipy03/images/caltech_map_scipy.gif My plan, otherwise, is to park at my hotel, and get a cab or public transport to the campus. Campus parking officers are usually quite "efficient". -- Chad Netzer From travis at enthought.com Mon Sep 8 21:05:34 2003 From: travis at enthought.com (Travis N. Vaught) Date: Mon, 8 Sep 2003 20:05:34 -0500 Subject: [SciPy-user] SciPy 2003 Parking? In-Reply-To: <1063067818.1871.28.camel@adsl-209.204.179.133.sonic.net> Message-ID: <006d01c3766e$7cbe6b00$0400a8c0@tvlaptop> All, Last year, we filled out a form at the parking garage and they allowed us to park there as attendees of the workshop. Please allow for some extra time to fill out the short form before walking over to the morning session. It was the garage labeled '66' on the map here: http://www.scipy.org/site_content/scipy03/images/caltech_map_scipy.gif The security guards at the parking structure will be expecting us, but there may be a bit of a line if all of us show at the same time. Travis > -----Original Message----- > From: scipy-user-admin at scipy.net [mailto:scipy-user-admin at scipy.net] On > Behalf Of Chad Netzer > Sent: Monday, September 08, 2003 6:37 PM > To: scipy-user at scipy.net > Subject: Re: [SciPy-user] SciPy 2003 Parking? > > On Mon, 2003-09-08 at 03:33, ChuckEsterbrook at yahoo.com wrote: > > Can anyone tell me what SciPy 2003 parking is going to be like? The > CalTech site has a parking form, but I don't know if I'm supposed to get > back a sticker or what... > > > > Do I just snail mail them the form here? > > http://atc.caltech.edu/CIT_parking/visit_reg.pdf > > I looked at those forms long and hard. It seems that only Campus > personnel can request visitor passes. If you don't have a contact there, > it seems you are out of luck. > > This is a confusing issue, since the SciPy conference page implies there > is ample parking (by pointing out the parking structures), but going to > the CalTech pages they are adamant about NOT allowing parking without > being a special permit. See here: > > http://atc.caltech.edu/CIT_Parking/home.htm > > "Welcome to the Caltech Parking Office home page. Commencing October 8, > 2001 all vehicles utilizing Caltech parking facilities must be > registered and display a Caltech parking placard." > > If anyone who is in the know can clear this up, it would be nice, even > at this late date; ie. whether there WILL or WILL NOT be parking > available at the parking areas indicated at the following link: > > http://www.scipy.org/site_content/scipy03/images/caltech_map_scipy.gif > > My plan, otherwise, is to park at my hotel, and get a cab or public > transport to the campus. Campus parking officers are usually quite > "efficient". > > -- > Chad Netzer > > _______________________________________________ > SciPy-user mailing list > SciPy-user at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-user From cnetzer at sonic.net Mon Sep 8 21:40:08 2003 From: cnetzer at sonic.net (Chad Netzer) Date: Mon, 08 Sep 2003 18:40:08 -0700 Subject: [SciPy-user] SciPy 2003 Parking? In-Reply-To: <006d01c3766e$7cbe6b00$0400a8c0@tvlaptop> References: <006d01c3766e$7cbe6b00$0400a8c0@tvlaptop> Message-ID: <1063071608.1872.30.camel@adsl-209.204.179.133.sonic.net> On Mon, 2003-09-08 at 18:05, Travis N. Vaught wrote: > All, > > Last year, we filled out a form at the parking garage and they allowed > us to park there as attendees of the workshop. Please allow for some > extra time to fill out the short form before walking over to the morning > session. > > It was the garage labeled '66' on the map here: > > http://www.scipy.org/site_content/scipy03/images/caltech_map_scipy.gif > > The security guards at the parking structure will be expecting us, but > there may be a bit of a line if all of us show at the same time. Cool. Thanks for the clarification. -- Chad Netzer From jcollins at boulder.net Tue Sep 9 12:06:55 2003 From: jcollins at boulder.net (Jeffery D. Collins) Date: Tue, 09 Sep 2003 10:06:55 -0600 Subject: [SciPy-user] IPython completion In-Reply-To: <3F5D0D44.5070403@colorado.edu> References: <3F5CEED2.3010806@boulder.net> <3F5CFFBA.8040600@colorado.edu> <3F5D0910.40501@boulder.net> <3F5D0D44.5070403@colorado.edu> Message-ID: <3F5DFA9F.6020104@boulder.net> I was using Python2.3 on Solaris 8 when I reported yesterday. I have found the same to be true on my Linux (RH-9.0) box as well. Here is the information you requested below, but for the linux box instead: Python 2.3 (#1, Sep 9 2003, 09:49:11) Type "copyright", "credits" or "license" for more information. IPython 0.5.0 -- 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. IPython profile: numeric *** Your version of Gnuplot appears not to have mouse support. *** Type `gphelp` for help on the Gnuplot integration features. In [1]: import readline In [2]: readline? Type: module Base Class: String Form: Namespace: Interactive File: /usr/local/lib/python2.3/lib-dynload/readline.so Docstring: Importing this module enables command line editing using GNU readline. In [3]: dir(readline) Out[3]: ['__doc__', '__file__', '__name__', 'add_history', 'get_begidx', 'get_completer', ... ] I also moved .ipython aside to allow for the creation of a new one, but it didn't help. There is no ~/.inputrc file, so no local customizations to the underlying readline library have been made. A quick comparison of the readline.c source for Python2.2 and Python2.3 shows many differences, so it's possible that some default behavior has changed. I should reiterate that there is no problem with using to complete names within the python namespace. It's just the completion of file/dir names that does not work. Fernando Perez wrote: > Jeffery D. Collins wrote: > >>> Can you test 'import readline' in a normal (non-ipython) python >>> shell? I want to know if your readline support is indeed correct. >> >> >> >> It imports just fine. Can you suggest any other tests I should try >> on the readline module? > > > Weird, very weird. Try (in ipython): > > In [1]: import readline > > In [2]: readline? > Type: module > Base Class: > String Form: '/usr/local/lib/python2.3/lib-dynload/readline.so'> > Namespace: Interactive > File: /usr/local/lib/python2.3/lib-dynload/readline.so > > > This is the oputput from my machine. Then do a dir(readline). This > is what I get: > > In [3]: dir(readline) > Out[3]: > ['__doc__', > '__file__', > '__name__', > 'add_history', > 'get_begidx', > 'get_completer', > ... > > > If all looks normal, try renaming your ~/.ipython directory so that > IPython makes a new one, and see if that helps. You might have some > readline-related customizations which break under 2.3. I wasn't aware > of any changes made to readline in python 2.3 though, so I'm shooting > a bit in the dark here. > > Also, let me know which platform you are running under. > > Cheers, > > f. > > _______________________________________________ > SciPy-user mailing list > SciPy-user at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-user -- Jeffery Collins (http://www.boulder.net/~jcollins) From jcollins at boulder.net Tue Sep 9 12:14:27 2003 From: jcollins at boulder.net (Jeffery D. Collins) Date: Tue, 09 Sep 2003 10:14:27 -0600 Subject: [SciPy-user] ipython-0.5 and returned tuples Message-ID: <3F5DFC63.7010702@boulder.net> f(x) returns a 2-tuple. This works fine under 0.4, but 0.5 reports the following. In [23]: sum,diff = f(1) ------------------------------------------------------------ File "", line 1 sum(,diff = f(1)) ^ SyntaxError: invalid syntax -------> sum(,diff = f(1)) -- Jeffery Collins (http://www.boulder.net/~jcollins) From fperez at colorado.edu Tue Sep 9 12:59:03 2003 From: fperez at colorado.edu (Fernando Perez) Date: Tue, 09 Sep 2003 10:59:03 -0600 Subject: [SciPy-user] IPython completion In-Reply-To: <3F5DFA9F.6020104@boulder.net> References: <3F5CEED2.3010806@boulder.net> <3F5CFFBA.8040600@colorado.edu> <3F5D0910.40501@boulder.net> <3F5D0D44.5070403@colorado.edu> <3F5DFA9F.6020104@boulder.net> Message-ID: <3F5E06D7.1050009@colorado.edu> Jeffery D. Collins wrote: > I should reiterate that there is no problem with using to complete > names within the python namespace. It's just the completion of file/dir > names that does not work. Ah! Either you didn't say that at first or I just misread it :) And when I tested things here, I just tested variable completion. Now I DO see the same problem as you. It means that something did change in the bowels of readline which is mucking up filename completion. That code is rather messy, and I'm leaving for Scipy'03 tomorrow, so I won't be able to look at this for a while (on vacation away from computers after the conference). But I'll keep it recorded and will look into it when I return. At this point, it may be a readline bug, or just a change in readline behavior I'll have to defend around for python 2.3. It kind of annoys me to see this, because the only mention of changes to readline in the 'what's new for 2.3' document seem to be: "The readline module also gained a number of new functions: get_history_item(), get_current_history_length(), and redisplay()." But maybe something else did happen and I just missed reading the docs in detail enough. Cheers, f. From fperez at colorado.edu Tue Sep 9 13:01:30 2003 From: fperez at colorado.edu (Fernando Perez) Date: Tue, 09 Sep 2003 11:01:30 -0600 Subject: [SciPy-user] ipython-0.5 and returned tuples In-Reply-To: <3F5DFC63.7010702@boulder.net> References: <3F5DFC63.7010702@boulder.net> Message-ID: <3F5E076A.7020509@colorado.edu> Jeffery D. Collins wrote: > f(x) returns a 2-tuple. This works fine under 0.4, but 0.5 reports the > following. > > > In [23]: sum,diff = f(1) > ------------------------------------------------------------ > File "", line 1 > sum(,diff = f(1)) > ^ > SyntaxError: invalid syntax > > -------> sum(,diff = f(1)) Noted, maybe I can fix one real quick. In the meantime, keep in mind this bug will be triggered only if sum was a function to begin with: In [2]: def f(): ...: return 1,2 ...: In [3]: f() Out[3]: (1, 2) In [4]: x,y=f() In [5]: x Out[5]: 1 In [6]: y Out[6]: 2 In [7]: x=f In [8]: x,y=f() ------> x(,y=f()) ------------------------------------------------------------ File "", line 1 x(,y=f()) ^ SyntaxError: invalid syntax Only when 'x' is assigned to be a callable does the bug surface. So as a temporary workaround, don't reassign to callables as the _first_ item for a list unpacking :) But it IS a bug, I'll look into it (I think it's easy). Cheers, f. From jcollins at boulder.net Tue Sep 9 13:17:06 2003 From: jcollins at boulder.net (Jeffery D. Collins) Date: Tue, 09 Sep 2003 11:17:06 -0600 Subject: [SciPy-user] ipython-0.5 and returned tuples In-Reply-To: <3F5E076A.7020509@colorado.edu> References: <3F5DFC63.7010702@boulder.net> <3F5E076A.7020509@colorado.edu> Message-ID: <3F5E0B12.3000608@boulder.net> Thanks for pointing that out:) I often use "sum" in my algorithms, forgetting that it's a numeric function. Fernando Perez wrote: > Jeffery D. Collins wrote: > >> f(x) returns a 2-tuple. This works fine under 0.4, but 0.5 reports >> the following. >> >> >> In [23]: sum,diff = f(1) >> ------------------------------------------------------------ >> File "", line 1 >> sum(,diff = f(1)) >> ^ >> SyntaxError: invalid syntax >> >> -------> sum(,diff = f(1)) > > > Noted, maybe I can fix one real quick. In the meantime, keep in mind > this bug will be triggered only if sum was a function to begin with: > > In [2]: def f(): > ...: return 1,2 > ...: > > In [3]: f() > Out[3]: (1, 2) > > In [4]: x,y=f() > > In [5]: x > Out[5]: 1 > > In [6]: y > Out[6]: 2 > > In [7]: x=f > > In [8]: x,y=f() > ------> x(,y=f()) > ------------------------------------------------------------ > File "", line 1 > x(,y=f()) > ^ > SyntaxError: invalid syntax > > Only when 'x' is assigned to be a callable does the bug surface. So > as a temporary workaround, don't reassign to callables as the _first_ > item for a list unpacking :) But it IS a bug, I'll look into it (I > think it's easy). > > Cheers, > > f. > > _______________________________________________ > SciPy-user mailing list > SciPy-user at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-user -- Jeffery Collins (http://www.boulder.net/~jcollins) From fperez at colorado.edu Tue Sep 9 13:27:05 2003 From: fperez at colorado.edu (Fernando Perez) Date: Tue, 09 Sep 2003 11:27:05 -0600 Subject: [SciPy-user] ipython-0.5 and returned tuples In-Reply-To: <3F5E0B12.3000608@boulder.net> References: <3F5DFC63.7010702@boulder.net> <3F5E076A.7020509@colorado.edu> <3F5E0B12.3000608@boulder.net> Message-ID: <3F5E0D69.3010508@colorado.edu> Jeffery D. Collins wrote: > Thanks for pointing that out:) I often use "sum" in my algorithms, > forgetting that it's a numeric function. By the way, the fix is super simple. I doubt I'll find the time to make a relase before leaving, but you can apply it yourself in one minute. Change line 999 of iplib.py from: (len(theRest)==0 or theRest[0] not in '!=()<>[') and \ to: (len(theRest)==0 or theRest[0] not in '!=()<>[,') and \ The only change is the added ',' in the string of characters to avoid. This should do, since it seems to catch all unpacking situations. Let me know if it works ok for you, and when I return I'll add it to a release. I'll put this in CVS in a minute for those who use the code from CVS. Thanks for the report! Cheers, f. From jcollins at boulder.net Tue Sep 9 13:45:37 2003 From: jcollins at boulder.net (Jeffery D. Collins) Date: Tue, 09 Sep 2003 11:45:37 -0600 Subject: [SciPy-user] ipython-0.5 and returned tuples In-Reply-To: <3F5E0D69.3010508@colorado.edu> References: <3F5DFC63.7010702@boulder.net> <3F5E076A.7020509@colorado.edu> <3F5E0B12.3000608@boulder.net> <3F5E0D69.3010508@colorado.edu> Message-ID: <3F5E11C1.10409@boulder.net> Fernando Perez wrote: > Jeffery D. Collins wrote: > >> Thanks for pointing that out:) I often use "sum" in my algorithms, >> forgetting that it's a numeric function. > > > By the way, the fix is super simple. I doubt I'll find the time to > make a relase before leaving, but you can apply it yourself in one > minute. > > Change line 999 of iplib.py from: > > (len(theRest)==0 or theRest[0] not in '!=()<>[') and \ > to: > (len(theRest)==0 or theRest[0] not in '!=()<>[,') > and \ > > The only change is the added ',' in the string of characters to > avoid. This should do, since it seems to catch all unpacking situations. > > Let me know if it works ok for you, and when I return I'll add it to a > release. I'll put this in CVS in a minute for those who use the code > from CVS. That works! -- Jeffery Collins (http://www.boulder.net/~jcollins) From fperez at colorado.edu Tue Sep 9 13:54:54 2003 From: fperez at colorado.edu (Fernando Perez) Date: Tue, 09 Sep 2003 11:54:54 -0600 Subject: [SciPy-user] ipython-0.5 and returned tuples In-Reply-To: <3F5E11C1.10409@boulder.net> References: <3F5DFC63.7010702@boulder.net> <3F5E076A.7020509@colorado.edu> <3F5E0B12.3000608@boulder.net> <3F5E0D69.3010508@colorado.edu> <3F5E11C1.10409@boulder.net> Message-ID: <3F5E13EE.3080302@colorado.edu> Jeffery D. Collins wrote: >>Let me know if it works ok for you, and when I return I'll add it to a >>release. I'll put this in CVS in a minute for those who use the code >>from CVS. > > > That works! Great. The fix is in CVS now. The readline problem will be, I suspect, a LOT nastier to track down, especially b/c I'll have to deal (it seems) with undocumented changes to the underlying C module. That will probably take a while. Cheers, f. From pajer at iname.com Tue Sep 9 22:38:27 2003 From: pajer at iname.com (Gary Pajer) Date: Tue, 9 Sep 2003 22:38:27 -0400 Subject: [SciPy-user] Installation on Mac OSX, again References: <3F5DFC63.7010702@boulder.net> <3F5E076A.7020509@colorado.edu><3F5E0B12.3000608@boulder.net> <3F5E0D69.3010508@colorado.edu><3F5E11C1.10409@boulder.net> <3F5E13EE.3080302@colorado.edu> Message-ID: <001501c37744$9d3566f0$01fd5644@playroom> There have been a few threads on this with no definitive answers. Is there a way that works? I can report that the fink version is outdated, calling for pdflib-4.0.3 which is no longer available from pdflib.com. I was able to find pdflib-4.0.3 on a kde ftp site, so I got past that, but experienced network problems, so the installation didn't have a chance to finish. Clearly: some people have it running, and others have struggled. Anyone wish to share their wisdom? -Gary From bob at redivi.com Wed Sep 10 03:34:08 2003 From: bob at redivi.com (Bob Ippolito) Date: Wed, 10 Sep 2003 03:34:08 -0400 Subject: [SciPy-user] Installation on Mac OSX, again In-Reply-To: Message-ID: <29DC7EEC-E361-11D7-BE2C-000A95686CD8@redivi.com> On Wednesday, Sep 10, 2003, at 03:08 America/New_York, Andrew Straw wrote: > On Wednesday, Sep 10, 2003, at 15:49 Australia/Adelaide, Bob Ippolito > wrote: > >> On Tuesday, Sep 9, 2003, at 23:18 America/New_York, Andrew Straw >> wrote: >> >>> In the meantime, I exist quite happily by grabbing ATLAS from fink, >>> but using the "official" MacPython-2.3 from Jack Jansen and >>> compiling scipy (and other python modules not available through >>> Package Manager) from CVS sources. I posted some stuff to this list >>> about a few tweaks to scipy's build system -- I think site.cfg or >>> something. >> >> I can't seem to find your previous thread about the tweaks to scipy's >> build system in the archives, can you forward me the message? > > Looks like I actually posted solutions to pythonmac-sig. Sorry for the > confusion. > http://mail.python.org/pipermail/pythonmac-sig/2003-April/007617.html > > In a nutshell, my method is: > 0) installing prerequisites > 1) Create scipy_core/scipy_distutils/site.cfg for ATLAS et al. > 2) remove xplt from the build process (I just haven't put in the > effort to get it to compile - I can't see why it shouldn't) by > commenting it out of setup.py. > 3) python setup.py install > >> Also, I'd be interested to know what modules you're using that aren't >> covered by either my PackageManager repository or Jack's, so I can >> package them and make everyone's life easier. > > A quick browse down the memory lane called 'site-packages' shows that > in addition to many packages in your and Jack's PackMan databases, I > most frequently use scipy (including chaco), biggles, Gnuplot, > IPython, mysql, reportlab, piddle, rpy, pyro, pytables, and numarray. > (Actually, some of these might be in the databases, but I remember > building them myself...) mysql and piddle are in my repository already, I'll get the rest in there soonish. remind me if I don't. -bob From nwagner at mecha.uni-stuttgart.de Wed Sep 10 11:29:02 2003 From: nwagner at mecha.uni-stuttgart.de (Nils Wagner) Date: Wed, 10 Sep 2003 17:29:02 +0200 Subject: [SciPy-user] Hankel, Toeplitz why not Vandermonde Message-ID: <3F5F433E.D030CEC@mecha.uni-stuttgart.de> Hi all, I found Hankel and Toeplitz matrices in scipy - why not Vandermonde matrices ? Nils From andrew.straw at adelaide.edu.au Tue Sep 9 23:18:39 2003 From: andrew.straw at adelaide.edu.au (Andrew Straw) Date: Wed, 10 Sep 2003 12:48:39 +0930 Subject: [SciPy-user] Installation on Mac OSX, again In-Reply-To: <001501c37744$9d3566f0$01fd5644@playroom> Message-ID: <791C786B-E33D-11D7-AAE0-00039311EA24@adelaide.edu.au> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I think Bob Ippolito may be working on a MacPython-2.3 Package Manager release which uses Apple's vecLib, so let's keep our fingers crossed... (I suppose one might accelerate this process by hiring him. He's definitely a whiz at getting stuff to work on OS X.) In the meantime, I exist quite happily by grabbing ATLAS from fink, but using the "official" MacPython-2.3 from Jack Jansen and compiling scipy (and other python modules not available through Package Manager) from CVS sources. I posted some stuff to this list about a few tweaks to scipy's build system -- I think site.cfg or something. Other details: g77 3.1 doesn't like the MACOSX_DEPLOYMENT_TARGET=10.2. shuksan ~$ g77 -v Reading specs from /sw/lib/gcc-lib/powerpc-apple-darwin6.6/3.1/specs Configured with: ../gcc3/configure --prefix=/sw --enable-languages=f77 - --infodir=${prefix}/share/info Thread model: single Apple Computer, Inc. GCC version 1151, based on gcc version 3.1 20020420 (prerelease) shuksan ~$ gcc -v Reading specs from /usr/libexec/gcc/darwin/ppc/3.3/specs Thread model: posix gcc version 3.3 20030304 (Apple Computer, Inc. build 1435) Good luck! Andrew On Wednesday, Sep 10, 2003, at 12:08 Australia/Adelaide, Gary Pajer wrote: > There have been a few threads on this with no definitive answers. > > Is there a way that works? > > I can report that the fink version is outdated, calling for > pdflib-4.0.3 > which is no longer available from pdflib.com. > I was able to find pdflib-4.0.3 on a kde ftp site, so I got past that, > but > experienced network problems, so the installation didn't have a chance > to > finish. > > Clearly: some people have it running, and others have struggled. > Anyone > wish to share their wisdom? > > -Gary > > _______________________________________________ > SciPy-user mailing list > SciPy-user at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-user > -----BEGIN PGP SIGNATURE----- iD8DBQE/XpgX1xWcCSPVbpgRAn3hAKD82JSAe3fJejBO7znsHWFC0Hy12gCeI4xV Yzb9NUSVyWrmHZWk5yc4Fx4= =pXz7 -----END PGP SIGNATURE----- From astraw at insightscientific.com Wed Sep 10 03:08:59 2003 From: astraw at insightscientific.com (Andrew Straw) Date: Wed, 10 Sep 2003 16:38:59 +0930 Subject: [SciPy-user] Installation on Mac OSX, again In-Reply-To: Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday, Sep 10, 2003, at 15:49 Australia/Adelaide, Bob Ippolito wrote: > On Tuesday, Sep 9, 2003, at 23:18 America/New_York, Andrew Straw wrote: > >> In the meantime, I exist quite happily by grabbing ATLAS from fink, >> but using the "official" MacPython-2.3 from Jack Jansen and compiling >> scipy (and other python modules not available through Package >> Manager) from CVS sources. I posted some stuff to this list about a >> few tweaks to scipy's build system -- I think site.cfg or something. > > I can't seem to find your previous thread about the tweaks to scipy's > build system in the archives, can you forward me the message? Looks like I actually posted solutions to pythonmac-sig. Sorry for the confusion. http://mail.python.org/pipermail/pythonmac-sig/2003-April/007617.html In a nutshell, my method is: 0) installing prerequisites 1) Create scipy_core/scipy_distutils/site.cfg for ATLAS et al. 2) remove xplt from the build process (I just haven't put in the effort to get it to compile - I can't see why it shouldn't) by commenting it out of setup.py. 3) python setup.py install > Also, I'd be interested to know what modules you're using that aren't > covered by either my PackageManager repository or Jack's, so I can > package them and make everyone's life easier. A quick browse down the memory lane called 'site-packages' shows that in addition to many packages in your and Jack's PackMan databases, I most frequently use scipy (including chaco), biggles, Gnuplot, IPython, mysql, reportlab, piddle, rpy, pyro, pytables, and numarray. (Actually, some of these might be in the databases, but I remember building them myself...) -----BEGIN PGP SIGNATURE----- iD8DBQE/Xs4R1xWcCSPVbpgRAnKLAKCYrBsU57K1426B0C9V2zAyiIZgewCfa6TG c2umoTzSgvDBs9EUoY8cw28= =6XOw -----END PGP SIGNATURE----- From Jeffrey.S.Whitaker at noaa.gov Wed Sep 10 12:46:40 2003 From: Jeffrey.S.Whitaker at noaa.gov (Jeffrey S Whitaker) Date: Wed, 10 Sep 2003 10:46:40 -0600 (MDT) Subject: [SciPy-user] ANN: NAGpy (python NAG interface) Message-ID: Thought scipy users who have the commercial NAG math library might be interested in this .. NAGpy - python NAG library interface A Python interface to the NAG Fortran 77 library (http://www.nag.com/numeric/Fortran_Libraries.asp). The python signatures are designed to be as similar as possible to the NAG/Matlab Foundation Toolbox (http://www.nag.com/nagware/mt/doc/contents.asp). Requires: 1) Numeric (http://sf.net/projects/numpy). 2) Pyfort (http://pyfortran.sf.net - version 8.2 or above). 3) NAG f77 double precision lib (and a fortran compiler Pyfort knows about). 4) optik module (http://optik.sf.net) - only needed if using python<2.3. Home page: http://www.cdc.noaa.gov/~jsw/python/nagpy Source code: ftp://ftp.cdc.noaa.gov/Public/jsw/nagpy.tar.gz. Available functions (so far). I'm slowly adding more from chapter G. If need a specific function, email me and I'll put it on the TODO list. Lower-case names are functions, capitalized names are classes. g01eaf: returns a probability associated with a given deviate from a standard normal distribution. g01eff: returns returns the lower or upper tail probability of the gamma distribution, with parameters alpha and beta. g01faf: returns a deviate associated with a given probability from a standard normal distribution. g01fff: returns the deviate associated with the given lower tail probability of the gamma distribution. g02bsf: Kendall/Spearman non-parametric rank correlation coefficients, with treatment of missing values. g02daf: fit a general (multiple) linear regression model. g02dgf: update a general (multiple) linear regression model with a a new dependent variable after a call to g02daf. g02dnf: Gives the estimate of an estimable function along with its standard error. G02EEF: Performs a forward selection procedure to find "best" linear regression model - implemented as a class. g02gaf: fit a generalized linear model with gaussian errors. g02gbf: fit a generalized linear model with binomial errors. g02gcf: fit a generalized linear model with poisson errors. g02gdf: fit a generalized linear model with gamma errors. g03aaf: principal component analysis. g03acf: canonical variate analysis. g03adf: canonical correlation analysis. g03baf: Orthogonal rotations for loading matrix, generalized orthomax criterion. g03eff: K-means cluster analysis. Feedback: Jeff Whitaker -- Jeffrey S. Whitaker Phone : (303)497-6313 NOAA/OAR/CDC R/CDC1 FAX : (303)497-6449 325 Broadway Web : http://www.cdc.noaa.gov/~jsw Boulder, CO, USA 80305-3328 Office: Skaggs Research Cntr 1D-124 From pajer at iname.com Wed Sep 10 22:37:20 2003 From: pajer at iname.com (Gary Pajer) Date: Wed, 10 Sep 2003 22:37:20 -0400 Subject: [SciPy-user] Installation on Mac OSX, again References: <791C786B-E33D-11D7-AAE0-00039311EA24@adelaide.edu.au> Message-ID: <004f01c3780d$a49aeb30$01fd5644@playroom> From: "Andrew Straw" > > I think Bob Ippolito may be working on a MacPython-2.3 Package Manager > release which uses Apple's vecLib, so let's keep our fingers crossed... Thanks to all who have responded to my post. I'm new to Mac, and still getting used to things. Do I understand correctly that the "porting" of scipy will be to the MacPython system and not the fink distribution? Will we always have two mutually exclusive pythons for Mac? (<-- that's got to be a very FAQ) Is one dominant over the other? OK, I'm getting off topic ... - Gary From bob at redivi.com Wed Sep 10 22:55:38 2003 From: bob at redivi.com (Bob Ippolito) Date: Wed, 10 Sep 2003 22:55:38 -0400 Subject: [SciPy-user] Installation on Mac OSX, again In-Reply-To: <004f01c3780d$a49aeb30$01fd5644@playroom> Message-ID: <6C2D0D3F-E403-11D7-BE2C-000A95686CD8@redivi.com> On Wednesday, Sep 10, 2003, at 22:37 America/New_York, Gary Pajer wrote: > From: "Andrew Straw" > >> >> I think Bob Ippolito may be working on a MacPython-2.3 Package Manager >> release which uses Apple's vecLib, so let's keep our fingers >> crossed... > > Thanks to all who have responded to my post. > > I'm new to Mac, and still getting used to things. > Do I understand correctly that the "porting" of scipy will be to the > MacPython system and not the fink distribution? Will we always have two > mutually exclusive pythons for Mac? (<-- that's got to be a very FAQ) > Is one dominant over the other? OK, I'm getting off topic ... We'll probably have two (or three, if you count Apple's, but Apple's is essentially MacPython missing the tools and some modules) mutually exclusive Python distributions as long as Fink is around. Someone from the Fink project may independently port SciPy to OS X, but I write and port software for use with the official MacPython, so you're not going to see a Fink version from me. MacPython will eventually be dominant over Fink's if I have anything to say about it :) For now, Fink has a few Python extensions that MacPython does not, particularly with regard to stuff that requires X11, and Fink is (probably?) missing quite a few of the Carbon/Cocoa sort of modules. In any case, if there's a module that you can't compile yourself for MacPython, that does not require X11, post to pythonmac-sig and someone will likely port it for you or help you along the way. -bob From pajer at iname.com Thu Sep 11 20:16:54 2003 From: pajer at iname.com (Gary Pajer) Date: Thu, 11 Sep 2003 20:16:54 -0400 Subject: [SciPy-user] Some progress installing on Mac OSX / Fink References: <6C2D0D3F-E403-11D7-BE2C-000A95686CD8@redivi.com> Message-ID: <002801c378c3$2b9a8a90$01fd5644@playroom> I'm trying to install scipy on OSX using the Fink installer. As noted earlier, I had to find and manually download pdflib-4.0.3 because pdflib.com is delivering 5.x.x. Fink stops at one point, reporting a checksum problem with pdflib. I just said go ahead anyway. With that, lots of compiling takes place. I'm stuck now because Fink is trying to install numeric-atlas, but it finds already installed both numeric and numeric-py22. Fink stops here, refusing to go beyond this conflict. Since I have numeric-py22 already, is there some way to force Fink to ignore this step? I'm not sure how/why two versions of numeric are registered as installed. (Recall I'm new at the Mac.) In the actual filestructure, only numeric-py22 exists. (that is, /sw/lib/python22/site-packages) I've installed several packages; apparantly numeric was installed twice. Only one seems to exist, yet both are registered with Fink as being installed. I tried sudo fink remove numeric sudo fink remove numeric-py22 after which both packages are no longer registered, *and* I mangled the name of the numeric directory and numeric.pth in the hopes that the scipy installation would see nothing installed, and install numeric-atlas. But no, it still finds numeric-py22 as installed, and quits. (I also have MacPython installed ... but shouldn't that be entirely independent?) So once again, I beseech thee for help. -Gary From ariciputi at pito.com Fri Sep 12 03:47:09 2003 From: ariciputi at pito.com (Andrea Riciputi) Date: Fri, 12 Sep 2003 09:47:09 +0200 Subject: [SciPy-user] Some progress installing on Mac OSX / Fink In-Reply-To: <002801c378c3$2b9a8a90$01fd5644@playroom> Message-ID: <4FFC81EA-E4F5-11D7-8358-000393933E4E@pito.com> I think the Fink list it'd be a better place to ask for. I'm sure you can find much more help there. By the way I use Fink and I installed scipy last week without a problem. In order to solve your problem I need more information about your configuration. What's your output for: % fink list numeric % fink list scipy % fink list atlas I suspect you are trying to install scipy (old realese) instead of scipy-py22 (new one). Cheers, Andrea. On Friday, Sep 12, 2003, at 02:16 Europe/Rome, Gary Pajer wrote: > I'm trying to install scipy on OSX using the Fink installer. > As noted earlier, I had to find and manually download pdflib-4.0.3 > because > pdflib.com is delivering 5.x.x. > [snip] --- Andrea Riciputi "Science is like sex: sometimes something useful comes out, but that is not the reason we are doing it" -- (Richard Feynman) From tony at tcapp.com Sat Sep 13 00:38:26 2003 From: tony at tcapp.com (Tony Cappellini) Date: Fri, 12 Sep 2003 21:38:26 -0700 Subject: [SciPy-user] How well does SciPy work with Python 2.3 Message-ID: <5.1.0.14.0.20030912213430.04e71868@smtp.sbcglobal.net> I didn't see any posts about compatibility with 2.3, nor do I see any release info, so I need to ask. From astraw at insightscientific.com Sat Sep 13 01:54:05 2003 From: astraw at insightscientific.com (Andrew Straw) Date: Sat, 13 Sep 2003 15:24:05 +0930 Subject: [SciPy-user] How well does SciPy work with Python 2.3 In-Reply-To: <5.1.0.14.0.20030912213430.04e71868@smtp.sbcglobal.net> References: <5.1.0.14.0.20030912213430.04e71868@smtp.sbcglobal.net> Message-ID: <3F62B0FD.9080302@insightscientific.com> > I didn't see any posts about compatibility with 2.3 That must be because it works so well! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 155 bytes Desc: not available URL: From arnd.baecker at web.de Mon Sep 15 04:33:05 2003 From: arnd.baecker at web.de (Arnd Baecker) Date: Mon, 15 Sep 2003 10:33:05 +0200 (CEST) Subject: [SciPy-user] How well does SciPy work with Python 2.3 In-Reply-To: <5.1.0.14.0.20030912213430.04e71868@smtp.sbcglobal.net> References: <5.1.0.14.0.20030912213430.04e71868@smtp.sbcglobal.net> Message-ID: Hi, I haven't encountered any problems so far (apart from the two error messages for a scipy.test(10), see below). (I think they were reported already a while ago). I had another look at it and to me it seems that the multiplication of a instance of the polynomial class is the culprit, p = scipy.poly1d([1,2,3]) p(0.5) # fine 2.0*p(0.5) # fine 2*p # KeyError (2*p)(0.5) # KeyError The last two lines work with python 2.2 (scipy.__version__: '0.2.0_alpha_200.4160') whereas with python 2.3 (scipy.__version__, '0.2.0_alpha_210.4098') they fail. Hmm, addition seems to be broken as well: p1 = scipy.poly1d([1,2,3]) p2 = scipy.poly1d([1,2,3]) p=p1+p2 # KeyError However I did not manage to find a fix for this. Arnd ====================================================================== ERROR: check_chebyc (test_basic.test_chebyc) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/python/PYTHON/lib/python2.3/site-packages/scipy/special/tests/test_basic.py", line 214, in check_chebyc chebc = chebyc(1)(.2) File "/home/python/PYTHON/lib/python2.3/site-packages/scipy/special/orthogonal.py", line 398, in chebyc p = p * 2.0/p(2) File "/home/python/PYTHON/lib/python2.3/site-packages/scipy_base/polynomial.py", line 445, in __getattr__ raise KeyError KeyError ====================================================================== ERROR: check_chebys (test_basic.test_chebys) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/python/PYTHON/lib/python2.3/site-packages/scipy/special/tests/test_basic.py", line 220, in check_chebys chebs = chebys(1)(.2) File "/home/python/PYTHON/lib/python2.3/site-packages/scipy/special/orthogonal.py", line 429, in chebys p = p * (n+1.0)/p(2) File "/home/python/PYTHON/lib/python2.3/site-packages/scipy_base/polynomial.py", line 445, in __getattr__ raise KeyError KeyError - From gpajer at rider.edu Mon Sep 15 13:01:54 2003 From: gpajer at rider.edu (Gary Pajer) Date: Mon, 15 Sep 2003 13:01:54 -0400 Subject: [SciPy-user] More progress installing scipy on Mac OSX / Fink Message-ID: <4F1F25AD-E79E-11D7-8210-000393A41AAE@rider.edu> Andrea, Thanks for your patience, as I am new to the ways of The Mac and The Fink. Just knowing that it worked for someone is a great help. I was indeed *not* installing scipy-py22. I got much farther when I fixed that. Now, after a long compile, it quits with the error stream shown below. I also include, below, the responses to your suggested queries. I've probably munged up my installation. Since you've had good results, I'm tempted to rm -r /sw and start over. Any idea how to fix this? Should I start with a clean slate? thanks, gary ------------------------------------------------------------------------ - Here's the responses I get to your suggested queries: % fink list numeric Information about 1285 packages read in 4 seconds. gnumeric 1.0.13-1 Spreadsheet program for gnome, reads many... numeric 22.0-1 Multidim'l numerical arrays for Python, u... numeric-atlas 22.0-1 Multidim'l numerical arrays for Python, u... i numeric-py22 23.0-1 Multidim'l numerical arrays for Python, u... % fink list scipy Information about 1285 packages read in 1 seconds. scipy 20021007-1 Scientific tools for Python scipy-py22 20030415-1 Scientific tools for Python scipy-py23 20030415-2 Scientific tools for Python % fink list atlas Information about 1285 packages read in 1 seconds. i atlas 3.4.1-2 Portably optimal linear algebra software numeric-atlas 22.0-1 Multidim'l numerical arrays for Python, u... scilab-atlas 2.7-1 Software package for numerical computations ------------------------------------------------------------------------ -- scipy compile error: ld: Undefined symbols: _CloseResFile _CopyPascalStringToC _FMCreateFontFamilyInstanceIterator _FMCreateFontFamilyIterator _FMDisposeFontFamilyInstanceIterator _FMDisposeFontFamilyIterator _FMGetFontContainer _FMGetFontFamilyName _FMGetNextFontFamily _FMGetNextFontFamilyInstance _FSClose _FSGetCatalogInfo _FSMakeFSSpec _FSOpenResourceFile _FSPathMakeRef _FSpGetFInfo _FSpMakeFSRef _FSpOpenRF _FSpOpenResFile _Get1IndResource _Get1Resource _GetEOF _GetHandleSize _GetResInfo _GetResource _HLock _HUnlock _HomeResFile _PBGetFCBInfoSync _ReleaseResource _ResError _UseResFile error: command 'g++' failed with exit status 1 ### execution of python2.2 failed, exit code 1 Failed: compiling scipy-py22-20030415-1 failed ------------------------------------------------------------------------ I think the Fink list it'd be a better place to ask for. I'm sure you can find much more help there. By the way I use Fink and I installed scipy last week without a problem. In order to solve your problem I need more information about your configuration. What's your output for: % fink list numeric % fink list scipy % fink list atlas I suspect you are trying to install scipy (old realese) instead of scipy-py22 (new one). Cheers, Andrea. On Friday, Sep 12, 2003, at 02:16 Europe/Rome, Gary Pajer wrote: > I'm trying to install scipy on OSX using the Fink installer. > As noted earlier, I had to find and manually download pdflib-4.0.3 > because > pdflib.com is delivering 5.x.x. > [snip] [...] From gpajer at rider.edu Mon Sep 15 17:49:39 2003 From: gpajer at rider.edu (Gary Pajer) Date: Mon, 15 Sep 2003 17:49:39 -0400 Subject: [SciPy-user] More progress installing scipy on Mac OSX / Fink : success!! In-Reply-To: <4F1F25AD-E79E-11D7-8210-000393A41AAE@rider.edu> Message-ID: <815D9B04-E7C6-11D7-8210-000393A41AAE@rider.edu> Deep in the archives of SciPy-user I found Jeffery Whitaker's very clear instructions on installing scipy-py23: http://scipy.net/pipermail/scipy-chaco/2003-April/000333.html (check the archives for 23 April 2002) It installed *flawlessly*. PyShell runs. scipy imports. scipy.plt works, chaco.wxplt works (with PyShell ... haven't tried it elsewhere). I do get deprecation warnings ... the same ones I get on WinXP / Python2.3. wxPython is mentioned in the warnings. (in fact, I've gone back to python2.2 on the WinXP machine because the warnings pop up in nasty windows) Is there a command line switch somewhere to turn off these warnings? *THANKS* to Jeffery Whitaker. and thanks to everyone who helped this poor MacNewbie get going. Maybe a pointer to (or copy of) Jeffery's installation instructions on the web site ?? -gary On Monday, September 15, 2003, at 01:01 PM, Gary Pajer wrote: > Andrea, > > Thanks for your patience, as I am new to the ways of The Mac and The > Fink. Just knowing that it worked for someone is a great help. I > was indeed *not* installing scipy-py22. I got much farther when I > fixed that. Now, after a long compile, it quits with the error stream > shown below. I also include, below, the responses to your suggested > queries. > > I've probably munged up my installation. Since you've had good > results, I'm tempted to rm -r /sw and start over. > > Any idea how to fix this? Should I start with a clean slate? > > thanks, > gary > > ----------------------------------------------------------------------- > -- > > Here's the responses I get to your suggested queries: > > % fink list numeric > Information about 1285 packages read in 4 seconds. > > gnumeric 1.0.13-1 Spreadsheet program for gnome, > reads many... > numeric 22.0-1 Multidim'l numerical arrays for > Python, u... > numeric-atlas 22.0-1 Multidim'l numerical arrays for > Python, u... > i numeric-py22 23.0-1 Multidim'l numerical arrays for > Python, u... > > > % fink list scipy > Information about 1285 packages read in 1 seconds. > > scipy 20021007-1 Scientific tools for Python > scipy-py22 20030415-1 Scientific tools for Python > scipy-py23 20030415-2 Scientific tools for Python > > > > % fink list atlas > Information about 1285 packages read in 1 seconds. > > i atlas 3.4.1-2 Portably optimal linear algebra > software > numeric-atlas 22.0-1 Multidim'l numerical arrays for > Python, u... > scilab-atlas 2.7-1 Software package for numerical > computations > > ----------------------------------------------------------------------- > --- > scipy compile error: > > ld: Undefined symbols: > _CloseResFile > _CopyPascalStringToC > _FMCreateFontFamilyInstanceIterator > _FMCreateFontFamilyIterator > _FMDisposeFontFamilyInstanceIterator > _FMDisposeFontFamilyIterator > _FMGetFontContainer > _FMGetFontFamilyName > _FMGetNextFontFamily > _FMGetNextFontFamilyInstance > _FSClose > _FSGetCatalogInfo > _FSMakeFSSpec > _FSOpenResourceFile > _FSPathMakeRef > _FSpGetFInfo > _FSpMakeFSRef > _FSpOpenRF > _FSpOpenResFile > _Get1IndResource > _Get1Resource > _GetEOF > _GetHandleSize > _GetResInfo > _GetResource > _HLock > _HUnlock > _HomeResFile > _PBGetFCBInfoSync > _ReleaseResource > _ResError > _UseResFile > error: command 'g++' failed with exit status 1 > ### execution of python2.2 failed, exit code 1 > Failed: compiling scipy-py22-20030415-1 failed > > > > > ----------------------------------------------------------------------- > - > > I think the Fink list it'd be a better place to ask for. I'm sure you > can find much more help there. > > By the way I use Fink and I installed scipy last week without a > problem. In order to solve your problem I need more information about > your configuration. What's your output for: > > % fink list numeric > > % fink list scipy > > % fink list atlas > > I suspect you are trying to install scipy (old realese) instead of > scipy-py22 (new one). > > Cheers, > Andrea. > > On Friday, Sep 12, 2003, at 02:16 Europe/Rome, Gary Pajer wrote: > > > I'm trying to install scipy on OSX using the Fink installer. > > As noted earlier, I had to find and manually download pdflib-4.0.3 > > because > > pdflib.com is delivering 5.x.x. > > [snip] > [...] > > _______________________________________________ > SciPy-user mailing list > SciPy-user at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-user > From ChuckEsterbrook at yahoo.com Mon Sep 15 22:46:48 2003 From: ChuckEsterbrook at yahoo.com (ChuckEsterbrook at yahoo.com) Date: Mon, 15 Sep 2003 19:46:48 -0700 Subject: [SciPy-user] Webware for Python Message-ID: <2003915194648.843141@workstation> Several people at the SciPy 2003 conference asked about Webware for Python and in particular, for the URL. Here it is: http://Webware.sf.net/ If you're wondering what Webware is....click the link and find out! :-) If you have questions, please put them through the webware-discuss at lists.sf.net mailing list. Thanks, -Chuck -- http://ChuckEsterbrook.com/ From ChuckEsterbrook at yahoo.com Tue Sep 16 01:04:47 2003 From: ChuckEsterbrook at yahoo.com (ChuckEsterbrook at yahoo.com) Date: Mon, 15 Sep 2003 22:04:47 -0700 Subject: [SciPy-user] San Diego Python User's Group (SANDPYT) Message-ID: <200391522447.769522@workstation> I saw some great presentations from San Diego Python users at SciPy 2003. We'd love to have you join us at SANDPYT: We have a meeting this Thur. Doors open at 6:30pm and presentations start at 7:00pm. We usually go til 9 or so. Details here: http://www.sandpyt.org/ -Chuck -- http://ChuckEsterbrook.com/ From nwagner at mecha.uni-stuttgart.de Tue Sep 16 05:21:26 2003 From: nwagner at mecha.uni-stuttgart.de (Nils Wagner) Date: Tue, 16 Sep 2003 11:21:26 +0200 Subject: [SciPy-user] Spectral projector Message-ID: <3F66D616.EBE208F@mecha.uni-stuttgart.de> Dear experts, how can I compute the spectral projector associated with \gamma, which is defined by P_\gamma = \frac{1}{2\pi i} \oint\limits_\gamma (\lambda I - A)^{-1} d\lambda i = \sqrt{-1} \gamma : contour I : identity matrix A : complex matrix of order n with scipy ? Any suggestion ? A small example would be appreciated. Thanks in advance, Nils From arnd.baecker at web.de Tue Sep 16 06:38:58 2003 From: arnd.baecker at web.de (Arnd Baecker) Date: Tue, 16 Sep 2003 12:38:58 +0200 (CEST) Subject: [SciPy-user] scipy website Message-ID: Hi, I encountered a few glitches with the scipy website: - At the end of http://www.scipy.org/site_content/tutorials there is under "Other Sources of Information" the link to the Wiki, pointing to http://www.scipy.org/site_content/tutorials/discuss which does not seem to exist (Site Error). Is the wiki (in principle) usable already now? - Clicking on the Portal Members homepages one gets: "Redirection limit for this URL exceeded. Unable to load the requested page" (eg.: http://www.scipy.org/Members/dmorrill) - The Search function for the mailing lists works, however the resulting links appear to be broken: Eg.: http://66.106.86.196/pipermail/scipy-user/2002-March/000218.html (Changing this by hand to http://www.scipy.org/site_content/mailman?fn=scipy-user/2002-March/000218.html shows the expected page) BTW: I think that the Wiki is too hidden - a link should go on the main page once it is in operation and has contents! Arnd From nwagner at mecha.uni-stuttgart.de Tue Sep 16 09:15:45 2003 From: nwagner at mecha.uni-stuttgart.de (Nils Wagner) Date: Tue, 16 Sep 2003 15:15:45 +0200 Subject: [SciPy-user] powm for scipy Message-ID: <3F670D01.4CB9B306@mecha.uni-stuttgart.de> Dear experts, I wonder, if powm will become a part of scipy in the near future. Nils From nwagner at mecha.uni-stuttgart.de Tue Sep 16 10:04:18 2003 From: nwagner at mecha.uni-stuttgart.de (Nils Wagner) Date: Tue, 16 Sep 2003 16:04:18 +0200 Subject: [SciPy-user] Grids Message-ID: <3F671862.93A2D7B2@mecha.uni-stuttgart.de> Dear experts, Let us consider a polygon in the complex plane, whose vertices are \xi_1=-10-10j, \xi_2=10-10j, \xi_3=10+10j,\xi_4=-10+10j, \xi_5 \equiv \xi_1 How can I discretize the domain (enclosed by the polygon) with scipy ? A small example would be appreciated. Thanks in advance. Nils From r.vanputten at hexapole.com Tue Sep 16 09:33:08 2003 From: r.vanputten at hexapole.com (Rob van Putten) Date: Tue, 16 Sep 2003 15:33:08 +0200 Subject: [SciPy-user] error building scipy Message-ID: <96ZW1ZTPEBOIMKIF95MRXTFQO514Y.3f671114@rob_pc> Hi there, I get an error when building SciPy on Slackware 9.0 The error occurs during 'python setup.py build' at the command: g77 -shared build/temp.linux-i586-2.2/fortranobject.o build/temp.linux-i586-2.2/fblasmodule.o -Lbuild/temp.linux-i586-2.2 -Lbuild/temp.linux-i586-2.2 -lfblas_f2py -llapack_src -lblas_src -lg2c -o build/lib.linux-i586-2.2/scipy/linalg/fblas.so and it says ld: cannot open crtbeginS.o: no such file or directory error... Any idea what could be wrong? Thanks in advance, Rob --here is the start of the output in case it is helpful-- ### Little Endian detected #### atlas_info: NOT AVAILABLE blas_info: NOT AVAILABLE blas_src_info: FOUND: sources = ['/tmp/blas/caxpy.f', '/tmp/blas/csscal.f', '/tmp/blas/dnrm2 ... ... tmp/blas/zgemm.f', '/tmp/blas/zsymm.f', '/tmp/blas/ztrsm.f'] lapack_info: NOT AVAILABLE lapack_src_info: FOUND: sources = ['/tmp/lapack/sbdsdc.f', '/tmp/lapack/sbdsqr.f', '/tmp/lapac ... ... k/scsum1.f', '/tmp/lapack/izmax1.f', '/tmp/lapack/dzsum1.f'] ### Little Endian detected #### 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. From nwagner at mecha.uni-stuttgart.de Tue Sep 16 11:03:22 2003 From: nwagner at mecha.uni-stuttgart.de (Nils Wagner) Date: Tue, 16 Sep 2003 17:03:22 +0200 Subject: [SciPy-user] Contour plots in scipy Message-ID: <3F67263A.212DBC74@mecha.uni-stuttgart.de> Dear experts, I am interested in a plot of equipotential curves. If desired, the regions between contours should be shaded or colored to indicate their magnitude. Is this feature already available in scipy ? Any comments or suggestions ? Nils From arnd.baecker at web.de Tue Sep 16 09:48:50 2003 From: arnd.baecker at web.de (Arnd Baecker) Date: Tue, 16 Sep 2003 15:48:50 +0200 (CEST) Subject: [SciPy-user] Grids In-Reply-To: <3F671862.93A2D7B2@mecha.uni-stuttgart.de> References: <3F671862.93A2D7B2@mecha.uni-stuttgart.de> Message-ID: Hi Nils, > Let us consider a polygon in the complex plane, whose vertices are > > \xi_1=-10-10j, \xi_2=10-10j, \xi_3=10+10j,\xi_4=-10+10j, \xi_5 \equiv > \xi_1 > > How can I discretize the domain (enclosed by the polygon) with scipy ? Hmm, I am sorry, but I don't understand what you want in the end - i.e. what do you mean by "discretize" - also: will your shapes be more general than the above (non-star-shaped, non-convex, etc.) ? Arnd From nwagner at mecha.uni-stuttgart.de Tue Sep 16 11:24:24 2003 From: nwagner at mecha.uni-stuttgart.de (Nils Wagner) Date: Tue, 16 Sep 2003 17:24:24 +0200 Subject: [SciPy-user] Grids References: <3F671862.93A2D7B2@mecha.uni-stuttgart.de> Message-ID: <3F672B28.4C0F28B6@mecha.uni-stuttgart.de> Arnd Baecker schrieb: > > Hi Nils, > > > Let us consider a polygon in the complex plane, whose vertices are > > > > \xi_1=-10-10j, \xi_2=10-10j, \xi_3=10+10j,\xi_4=-10+10j, \xi_5 \equiv > > \xi_1 > > > > How can I discretize the domain (enclosed by the polygon) with scipy ? > > Hmm, I am sorry, but I don't understand what > you want in the end - i.e. what do you mean by "discretize" - > also: will your shapes be more general than the above > (non-star-shaped, non-convex, etc.) ? > > Arnd > Arnd, At the beginning, it should be a simple grid over a rectangular domain. However, the shape may become more general. let us say a nearly arbitrary polygon, a circle or an ellipse. Nils _______________________________________________ > SciPy-user mailing list > SciPy-user at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-user From arnd.baecker at web.de Tue Sep 16 10:09:21 2003 From: arnd.baecker at web.de (Arnd Baecker) Date: Tue, 16 Sep 2003 16:09:21 +0200 (CEST) Subject: [SciPy-user] Contour plots in scipy In-Reply-To: <3F67263A.212DBC74@mecha.uni-stuttgart.de> References: <3F67263A.212DBC74@mecha.uni-stuttgart.de> Message-ID: Hi Nils, have a look at help(scipy.xplt.plc) (maybe also scipy.xplt.contour) However, I don't know about coloring between the contour levels. Personally I don't like discrete color shades between contour levels and use a grey-scale or color mapped version of the underlying array (+ optionally a contour plot on top). Arnd P.S.: Maybe scipy-user is enough for this type of questions (I would assume that all the core developers read both scipy-dev and scipy-user, but maybe I am wrong...) From arnd.baecker at web.de Tue Sep 16 10:29:48 2003 From: arnd.baecker at web.de (Arnd Baecker) Date: Tue, 16 Sep 2003 16:29:48 +0200 (CEST) Subject: [SciPy-user] Grids In-Reply-To: <3F672B28.4C0F28B6@mecha.uni-stuttgart.de> References: <3F671862.93A2D7B2@mecha.uni-stuttgart.de> <3F672B28.4C0F28B6@mecha.uni-stuttgart.de> Message-ID: On Tue, 16 Sep 2003, Nils Wagner wrote: > Arnd Baecker schrieb: > > > > Hi Nils, > > > > > Let us consider a polygon in the complex plane, whose vertices are > > > > > > \xi_1=-10-10j, \xi_2=10-10j, \xi_3=10+10j,\xi_4=-10+10j, \xi_5 \equiv > > > \xi_1 > > > > > > How can I discretize the domain (enclosed by the polygon) with scipy ? > > > > Hmm, I am sorry, but I don't understand what > > you want in the end - i.e. what do you mean by "discretize" - > > also: will your shapes be more general than the above > > (non-star-shaped, non-convex, etc.) ? > > > > Arnd > > > Arnd, > > At the beginning, it should be a simple grid over a rectangular domain. For this you could use mgrid from scipy, see scipy.info(scipy.mgrid) or scipy.mgrid? (if you use ipython) - strangely, help(scipy.mgrid) or help("scipy.mgrid") don't work ... > However, > the shape may become more general. let us say a nearly arbitrary > polygon, > a circle or an ellipse. In this case you might need a parametrization of your shape which maps a equidistant grid to the shape. Or you take a 2 D equidistant grid and from this you only keep those (x,y) which fall into the shape. So in the end you could get a 2-d array of (x,y) values which contain only those points inside the shape. But it really depends on you application. Arnd From arnd.baecker at web.de Wed Sep 17 15:04:12 2003 From: arnd.baecker at web.de (Arnd Baecker) Date: Wed, 17 Sep 2003 21:04:12 +0200 (CEST) Subject: [SciPy-user] scipy general_function segfault Message-ID: Hi, it seems that scipy.special.general_function (which allows to "vectorize" any scalar function) is broken (at least in two of my installations ;-) leading to a segmentation fault. A simple example for the problem is: ################################################# from scipy import * def addsubtract(a,b): if a > b: return a - b else: return a + b gfunc=special.general_function(addsubtract) gfunc([0,3,6,9],[1,3,5,7]) ################################################# For me it does work with Python 2.2.2, scipy.__version__: '0.2.0_alpha_183.4048' However, Python 2.2.3, scipy.__version__, '0.2.0_alpha_200.4160' Python 2.3, scipy.__version__, '0.2.0_alpha_210.4098' fail with a segmentation fault. Can someone confirm this problem (for which python/scipy version?) Even better would be a fix for this ... ;-) Many thanks, Arnd From pearu at scipy.org Wed Sep 17 15:34:50 2003 From: pearu at scipy.org (Pearu Peterson) Date: Wed, 17 Sep 2003 22:34:50 +0300 (EEST) Subject: [SciPy-user] scipy general_function segfault In-Reply-To: Message-ID: On Wed, 17 Sep 2003, Arnd Baecker wrote: > it seems that scipy.special.general_function > (which allows to "vectorize" any scalar function) > is broken (at least in two of my installations ;-) > leading to a segmentation fault. > > A simple example for the problem is: > > ################################################# > from scipy import * > > def addsubtract(a,b): > if a > b: > return a - b > else: > return a + b > > gfunc=special.general_function(addsubtract) > gfunc([0,3,6,9],[1,3,5,7]) > ################################################# > > > For me it does work with > Python 2.2.2, scipy.__version__: '0.2.0_alpha_183.4048' > However, > Python 2.2.3, scipy.__version__, '0.2.0_alpha_200.4160' > Python 2.3, scipy.__version__, '0.2.0_alpha_210.4098' > fail with a segmentation fault. Works here on debian with Python 2.2.3+, Scipy 0.2.0_alpha_211.4108 Python 2.1.3+, Scipy 0.2.0_alpha_197.4143 Python 2.3b2+, Scipy 0.2.0_alpha_211.4108 but fails with a segfault with Python 2.3b2+, Scipy 0.2.0_alpha_202.4187 So, try the latest Scipy from CVS. Pearu From ferrell at diablotech.com Wed Sep 17 15:55:31 2003 From: ferrell at diablotech.com (Robert Ferrell) Date: Wed, 17 Sep 2003 19:55:31 -0000 (GMT) Subject: [SciPy-user] scipy general_function segfault In-Reply-To: References: Message-ID: <3236.128.165.144.120.1063828531.squirrel@webmail.pair.com> Works for me with Python 2.3, scipy.__version__ 0.2.0_alpha_210.4096 This is on Windows2K. -robert > Hi, > > it seems that scipy.special.general_function > (which allows to "vectorize" any scalar function) > is broken (at least in two of my installations ;-) > leading to a segmentation fault. > > A simple example for the problem is: > > ################################################# > from scipy import * > > def addsubtract(a,b): > if a > b: > return a - b > else: > return a + b > > gfunc=special.general_function(addsubtract) > gfunc([0,3,6,9],[1,3,5,7]) > ################################################# > > > For me it does work with > Python 2.2.2, scipy.__version__: '0.2.0_alpha_183.4048' > However, > Python 2.2.3, scipy.__version__, '0.2.0_alpha_200.4160' > Python 2.3, scipy.__version__, '0.2.0_alpha_210.4098' > fail with a segmentation fault. > > > Can someone confirm this problem > (for which python/scipy version?) > > Even better would be a fix for this ... ;-) > > Many thanks, > > Arnd > > _______________________________________________ > SciPy-user mailing list > SciPy-user at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-user From oliphant at ee.byu.edu Wed Sep 17 16:50:33 2003 From: oliphant at ee.byu.edu (Travis E. Oliphant) Date: Wed, 17 Sep 2003 14:50:33 -0600 Subject: [SciPy-user] scipy general_function segfault In-Reply-To: References: Message-ID: <3F68C919.3060301@ee.byu.edu> Arnd Baecker wrote: > Hi, > > it seems that scipy.special.general_function > (which allows to "vectorize" any scalar function) > is broken (at least in two of my installations ;-) > leading to a segmentation fault. > > A simple example for the problem is: > > ################################################# > from scipy import * > > def addsubtract(a,b): > if a > b: > return a - b > else: > return a + b > > gfunc=special.general_function(addsubtract) > gfunc([0,3,6,9],[1,3,5,7]) > ################################################# > > > For me it does work with > Python 2.2.2, scipy.__version__: '0.2.0_alpha_183.4048' > However, > Python 2.2.3, scipy.__version__, '0.2.0_alpha_200.4160' > Python 2.3, scipy.__version__, '0.2.0_alpha_210.4098' Did you recompile Numeric with the new Python versions (and does scipy see the correct include files? I will check on this at some point. These kinds of problems are (almost) always related to incorrect include files and /or Numeric binaries not compatible with the new Python. -Travis From gpajer at rider.edu Wed Sep 17 17:30:28 2003 From: gpajer at rider.edu (Gary Pajer) Date: Wed, 17 Sep 2003 17:30:28 -0400 Subject: [SciPy-user] scipy general_function segfault In-Reply-To: Message-ID: <285CCCD3-E956-11D7-A931-000393A41AAE@rider.edu> >> >> >> gfunc=special.general_function(addsubtract) >> gfunc([0,3,6,9],[1,3,5,7]) >> ################################################# >> >> >> For me it does work with >> Python 2.2.2, scipy.__version__: '0.2.0_alpha_183.4048' >> However, >> Python 2.2.3, scipy.__version__, '0.2.0_alpha_200.4160' >> Python 2.3, scipy.__version__, '0.2.0_alpha_210.4098' >> fail with a segmentation fault. > > Works here on debian with > > Python 2.2.3+, Scipy 0.2.0_alpha_211.4108 > Python 2.1.3+, Scipy 0.2.0_alpha_197.4143 > Python 2.3b2+, Scipy 0.2.0_alpha_211.4108 > > but fails with a segfault with > > Python 2.3b2+, Scipy 0.2.0_alpha_202.4187 > > So, try the latest Scipy from CVS. > > Pearu > Works here on my newly installed fink installed scipy-py23 Python 2.3b1, scipy 0.2.0_alpha_196.4128 From arnd.baecker at web.de Wed Sep 17 18:43:19 2003 From: arnd.baecker at web.de (Arnd Baecker) Date: Thu, 18 Sep 2003 00:43:19 +0200 (CEST) Subject: [SciPy-user] scipy general_function segfault In-Reply-To: <3F68C919.3060301@ee.byu.edu> References: <3F68C919.3060301@ee.byu.edu> Message-ID: On Wed, 17 Sep 2003, Travis E. Oliphant wrote: [...] > Did you recompile Numeric with the new Python versions Yes, normally I do a fresh install of everything (python, ipython, Numeric, f2py, scipy, wxPython, ...) > (and does scipy see the correct include files? How could I check this ? (sorry if this is obvious - it's 00:30 here ;-) > I will check on this at some point. These kinds of problems are > (almost) always related to incorrect include files and /or Numeric > binaries not compatible with the new Python. Hmm, I have been beaten by this a couple of times in the past ;-( and I thought I learned my lesson now ;-). If I remember correctly, this normally resulted in a failure of some of the unittests. Presently the unit tests run fine (apart from the two known errors). I think it would be great, if there is a way to check for this type of incompatibilities automatically, eg when running python scipy_core/scipy_distutils/system_info.py OK, tomorrow I will do a fresh checkout and report here. Many thanks to all of you, Arnd From david.unitt at crl.toshiba.co.uk Wed Sep 17 12:18:00 2003 From: david.unitt at crl.toshiba.co.uk (David Unitt) Date: Wed, 17 Sep 2003 17:18:00 +0100 Subject: [SciPy-user] Double integration using gaussian quadrature query Message-ID: <000901c37d37$5792fd30$278e80c1@davidspc> Dear SciPy Users, I would be very grateful of your help, I am trying to do a double integral using Gaussian quadrature, I have put the code at the bottom of this message, along with the output. The problem I have is that if the function 'integrand' returns a value calculated using 'a0' the program throws up the exception "ValueError: frames are not aligned". 'a0' starts out as the integration variable 'a' in function 'integral2'. I have traced the problem to the successive calls of function 'integral1' from 'integral2'. Each time this happens the variable 'aa' in 'integral1' gains an element. Specifying aa[0] doesn't work. Any help on how to get round this would be appreciated Thanks david --------CODE------- #!/usr/bin/env python #################################################################### #calculating a double integral with fixed variable # #################################################################### from Numeric import * from __future__ import division from scipy import integrate ####################### #define integrand def integrand(b0,a0,c0): print "integrand called" #print a0 return a0*b0*b0*c0 #If this contains a) the program crashes #calculate the double integral def integral1(aa,b1,b2,c): print "integral1 called" print "aa = ",aa x1 = integrate.quadrature(lambda b: integrand(b,aa,c), b1, b2) return x1[0] def integral2(a1,a2,b1,b2,c): #a1, a2 are limits of this integral, b1,b2 are limits for 'integral1' #c is some constant print "integral2 called" x2 = integrate.quadrature(lambda a: integral1(a,b1,b2,c), a1, a2) return x2 ## f = integral2(0.0,1.0,0.0,1.0,1.0) print f[0] -----OUTPUT-------- integral2 called integral1 called aa = [ 0.5+0.j] integrand called integrand called integrand called Took 4 points. integral1 called aa = [ 0.21132487+0.j 0.78867513+0.j] integrand called integrand called Took 3 points. integral1 called aa = [ 0.11270167+0.j 0.5 +0.j 0.88729833+0.j] integrand called integrand called Traceback (most recent call last): File "C:/quad_test2.py", line 37, in ? f = integral2(0.0,1.0,0.0,1.0,1.0) File "C:/quad_test2.py", line 32, in integral2 x2 = integrate.quadrature(lambda a: integral1(a,b1,b2,c), a1, a2) File "C:\PROGRA~1\python22\Lib\site-packages\scipy\integrate\quadrature.py", line 65, in quadrature newval = fixed_quad(func,a,b,args,n)[0] File "C:\PROGRA~1\python22\Lib\site-packages\scipy\integrate\quadrature.py", line 35, in fixed_quad return (b-a)/2.0*sum(w*func(y,*args)), None File "C:/quad_test2.py", line 32, in x2 = integrate.quadrature(lambda a: integral1(a,b1,b2,c), a1, a2) File "C:/quad_test2.py", line 24, in integral1 x1 = integrate.quadrature(lambda b: integrand(b,aa,c), b1, b2) File "C:\PROGRA~1\python22\Lib\site-packages\scipy\integrate\quadrature.py", line 65, in quadrature newval = fixed_quad(func,a,b,args,n)[0] File "C:\PROGRA~1\python22\Lib\site-packages\scipy\integrate\quadrature.py", line 35, in fixed_quad return (b-a)/2.0*sum(w*func(y,*args)), None File "C:/quad_test2.py", line 24, in x1 = integrate.quadrature(lambda b: integrand(b,aa,c), b1, b2) File "C:/quad_test2.py", line 18, in integrand return a0*b0*b0*c0 #If this contains a) the program crashes ValueError: frames are not aligned _____________________________________________________________________ This e-mail has been scanned for viruses by MCI's Internet Managed Scanning Services - powered by MessageLabs. For further information visit http://www.mci.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.unitt at crl.toshiba.co.uk Wed Sep 17 12:18:55 2003 From: david.unitt at crl.toshiba.co.uk (David Unitt) Date: Wed, 17 Sep 2003 17:18:55 +0100 Subject: [SciPy-user] Double integration using gaussian quadrature query Message-ID: <000e01c37d37$770363d0$278e80c1@davidspc> Dear SciPy Users, I would be very grateful of your help, I am trying to do a double integral using Gaussian quadrature, I have put the code at the bottom of this message, along with the output. The problem I have is that if the function 'integrand' returns a value calculated using 'a0' the program throws up the exception "ValueError: frames are not aligned". 'a0' starts out as the integration variable 'a' in function 'integral2'. I have traced the problem to the successive calls of function 'integral1' from 'integral2'. Each time this happens the variable 'aa' in 'integral1' gains an element. Specifying aa[0] doesn't work. Any help on how to get round this would be appreciated Thanks david --------CODE------- #!/usr/bin/env python #################################################################### #calculating a double integral with fixed variable # #################################################################### from Numeric import * from __future__ import division from scipy import integrate ####################### #define integrand def integrand(b0,a0,c0): print "integrand called" return a0*b0*b0*c0 #If this contains a0 the program crashes #calculate the double integral def integral1(aa,b1,b2,c): print "integral1 called" print "aa = ",aa x1 = integrate.quadrature(lambda b: integrand(b,aa,c), b1, b2) return x1[0] def integral2(a1,a2,b1,b2,c): #a1, a2 are limits of this integral, b1,b2 are limits for 'integral1' #c is some constant print "integral2 called" x2 = integrate.quadrature(lambda a: integral1(a,b1,b2,c), a1, a2) return x2 ## f = integral2(0.0,1.0,0.0,1.0,1.0) print f[0] -----OUTPUT-------- integral2 called integral1 called aa = [ 0.5+0.j] integrand called integrand called integrand called Took 4 points. integral1 called aa = [ 0.21132487+0.j 0.78867513+0.j] integrand called integrand called Took 3 points. integral1 called aa = [ 0.11270167+0.j 0.5 +0.j 0.88729833+0.j] integrand called integrand called Traceback (most recent call last): File "C:/quad_test2.py", line 37, in ? f = integral2(0.0,1.0,0.0,1.0,1.0) File "C:/quad_test2.py", line 32, in integral2 x2 = integrate.quadrature(lambda a: integral1(a,b1,b2,c), a1, a2) File "C:\PROGRA~1\python22\Lib\site-packages\scipy\integrate\quadrature.py", line 65, in quadrature newval = fixed_quad(func,a,b,args,n)[0] File "C:\PROGRA~1\python22\Lib\site-packages\scipy\integrate\quadrature.py", line 35, in fixed_quad return (b-a)/2.0*sum(w*func(y,*args)), None File "C:/quad_test2.py", line 32, in x2 = integrate.quadrature(lambda a: integral1(a,b1,b2,c), a1, a2) File "C:/quad_test2.py", line 24, in integral1 x1 = integrate.quadrature(lambda b: integrand(b,aa,c), b1, b2) File "C:\PROGRA~1\python22\Lib\site-packages\scipy\integrate\quadrature.py", line 65, in quadrature newval = fixed_quad(func,a,b,args,n)[0] File "C:\PROGRA~1\python22\Lib\site-packages\scipy\integrate\quadrature.py", line 35, in fixed_quad return (b-a)/2.0*sum(w*func(y,*args)), None File "C:/quad_test2.py", line 24, in x1 = integrate.quadrature(lambda b: integrand(b,aa,c), b1, b2) File "C:/quad_test2.py", line 18, in integrand return a0*b0*b0*c0 #If this contains a) the program crashes ValueError: frames are not aligned _____________________________________________________________________ This e-mail has been scanned for viruses by MCI's Internet Managed Scanning Services - powered by MessageLabs. For further information visit http://www.mci.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnd.baecker at web.de Thu Sep 18 05:59:36 2003 From: arnd.baecker at web.de (Arnd Baecker) Date: Thu, 18 Sep 2003 11:59:36 +0200 (CEST) Subject: [SciPy-user] scipy general_function segfault In-Reply-To: References: Message-ID: Hi, I did a fresh install from source of python 2.3, Numeric, f2py2e, scipy (all the last three from CVS, scipy.__version__: '0.2.0_alpha_212.4130') and still get the same problem (scipy.test(10) works fine apart from the test_basic.test_chebyc and test_basic.test_chebys errors). Could the segfault be related to the Numeric version ? In [1]: import Numeric In [2]: Numeric.__version__ Out[2]: '23.1' In [3]: import scipy In [4]: scipy.__version__ Out[4]: '0.2.0_alpha_212.4130' Hmm, I tried with Numeric 23.0, same problem ... also tried python 2.2.3, same problem. I don't think that I'm doing something different than the previous (>20 ;-) python installs ... What further tests can I do to find out what is wrong with my installation ? scipy.test(10) works fine. In particular, what is the best way to check (as Travis asked) if scipy sees the correct include files? Many thanks, Arnd From pearu at scipy.org Thu Sep 18 06:49:13 2003 From: pearu at scipy.org (Pearu Peterson) Date: Thu, 18 Sep 2003 13:49:13 +0300 (EEST) Subject: [SciPy-user] scipy general_function segfault In-Reply-To: Message-ID: On Thu, 18 Sep 2003, Arnd Baecker wrote: > In particular, what is the best way to check (as Travis asked) if > scipy sees the correct include files? Comparing Numeric include files in /include/python2.3/Numeric/ and in /Include/Numeric/ should be enough. They should be the same, of course. Pearu From arnd.baecker at web.de Thu Sep 18 07:25:58 2003 From: arnd.baecker at web.de (Arnd Baecker) Date: Thu, 18 Sep 2003 13:25:58 +0200 (CEST) Subject: [SciPy-user] scipy general_function segfault In-Reply-To: References: Message-ID: many thanks, Pearu. All files are the same. I have no idea what is causing the segfault with the general_function and even worse, I am clueless how to get to the origin of this error - maybe I try another install on a different machine this evening. Any better ideas are welcome ... ;-) Arnd On Thu, 18 Sep 2003, Pearu Peterson wrote: > > On Thu, 18 Sep 2003, Arnd Baecker wrote: > > > In particular, what is the best way to check (as Travis asked) if > > scipy sees the correct include files? > > Comparing Numeric include files in > > /include/python2.3/Numeric/ > > and in > > /Include/Numeric/ > > should be enough. They should be the same, of course. > > Pearu From pearu at scipy.org Thu Sep 18 07:42:54 2003 From: pearu at scipy.org (Pearu Peterson) Date: Thu, 18 Sep 2003 14:42:54 +0300 (EEST) Subject: [SciPy-user] scipy general_function segfault In-Reply-To: Message-ID: On Thu, 18 Sep 2003, Arnd Baecker wrote: > I have no idea what is causing the segfault with the > general_function and even worse, I am clueless > how to get to the origin of this error - > maybe I try another install > on a different machine this evening. > Any better ideas are welcome ... ;-) Try libwadpy that might give ideas where to look. Also have you tried general_function with different examples, are there special cases where general_function does not segfault? I'll later try if I can figure out something from my case where general_function segfaulted. Pearu From oliphant at ee.byu.edu Thu Sep 18 11:50:24 2003 From: oliphant at ee.byu.edu (Travis Oliphant) Date: Thu, 18 Sep 2003 09:50:24 -0600 Subject: [SciPy-user] Double integration using gaussian quadrature query In-Reply-To: <000e01c37d37$770363d0$278e80c1@davidspc> References: <000e01c37d37$770363d0$278e80c1@davidspc> Message-ID: <3F69D440.3000200@ee.byu.edu> David Unitt wrote: > Dear SciPy Users, I would be very grateful of your help, > > > > I am trying to do a double integral using Gaussian quadrature, I have > put the code at the bottom of this message, along with the output. The > problem I have is that if the function ?integrand? returns a value > calculated using ?a0? the program throws up the exception ?ValueError: > frames are not aligned?. ?a0? starts out as the integration variable ?a? > in function ?integral2?. I have traced the problem to the successive > calls of function ?integral1? from ?integral2?. Each time this happens > the variable ?aa? in ?integral1? gains an element. Specifying aa[0] > doesn?t work. > This problem is due to some unclear documentation that has now been fixed. The function passed to quadrature currently must be able to handle a vector of inputs (i.e. it must act something like a ufunc). Your first integrand is fine, but using integral1 as a new input will not work with Gaussian quadrature because it cannot handle a vector value for aa. The error you are seeing is due to that problem. Your code can be easily fixed using scipy.special.general_function This function returns an object that is a "vectorized" version of your function. So, writing import scipy.special vec_integral1 = scipy.special.general_function(integral1) and using vec_integral1 as the integrand for integral2 will work (I tested it and it worked for me (I got 0.1666667 for the result). In the docstring for quadrature I've now emphasized this. You may be interested in the command integrate.dblquad which does general double integration using quadpack. Incidentally the integrator integrate.quad does not have this vectorized function requirement (and your code works if you replace integrate.quadrature with integrate.quad) and so the code for quadrature should be changed to match it. -Travis O. > > > Any help on how to get round this would be appreciated > > Thanks > > david > > > > --------CODE------- > > #!/usr/bin/env python > > > > #################################################################### > > #calculating a double integral with fixed variable > > # > > #################################################################### > > > > from Numeric import * > > from __future__ import division > > from scipy import integrate > > > > > > ####################### > > #define integrand > > def integrand(b0,a0,c0): > > print "integrand called" > > return a0*b0*b0*c0 #If this contains a0 the program crashes > > > > #calculate the double integral > > def integral1(aa,b1,b2,c): > > print "integral1 called" > > print "aa = ",aa > > x1 = integrate.quadrature(lambda b: integrand(b,aa,c), b1, b2) > > return x1[0] > > > > > > def integral2(a1,a2,b1,b2,c): > > #a1, a2 are limits of this integral, b1,b2 are limits for 'integral1' > > #c is some constant > > print "integral2 called" > > x2 = integrate.quadrature(lambda a: integral1(a,b1,b2,c), a1, a2) > > return x2 > > > > > > ## > > f = integral2(0.0,1.0,0.0,1.0,1.0) > > print f[0] > > > > > > -----OUTPUT-------- > > integral2 called > > integral1 called > > aa = [ 0.5+0.j] > > integrand called > > integrand called > > integrand called > > Took 4 points. > > integral1 called > > aa = [ 0.21132487+0.j 0.78867513+0.j] > > integrand called > > integrand called > > Took 3 points. > > integral1 called > > aa = [ 0.11270167+0.j 0.5 +0.j 0.88729833+0.j] > > integrand called > > integrand called > > Traceback (most recent call last): > > File "C:/quad_test2.py", line 37, in ? > > f = integral2(0.0,1.0,0.0,1.0,1.0) > > File "C:/quad_test2.py", line 32, in integral2 > > x2 = integrate.quadrature(lambda a: integral1(a,b1,b2,c), a1, a2) > > File > "C:\PROGRA~1\python22\Lib\site-packages\scipy\integrate\quadrature.py", > line 65, in quadrature > > newval = fixed_quad(func,a,b,args,n)[0] > > File > "C:\PROGRA~1\python22\Lib\site-packages\scipy\integrate\quadrature.py", > line 35, in fixed_quad > > return (b-a)/2.0*sum(w*func(y,*args)), None > > File "C:/quad_test2.py", line 32, in > > x2 = integrate.quadrature(lambda a: integral1(a,b1,b2,c), a1, a2) > > File "C:/quad_test2.py", line 24, in integral1 > > x1 = integrate.quadrature(lambda b: integrand(b,aa,c), b1, b2) > > File > "C:\PROGRA~1\python22\Lib\site-packages\scipy\integrate\quadrature.py", > line 65, in quadrature > > newval = fixed_quad(func,a,b,args,n)[0] > > File > "C:\PROGRA~1\python22\Lib\site-packages\scipy\integrate\quadrature.py", > line 35, in fixed_quad > > return (b-a)/2.0*sum(w*func(y,*args)), None > > File "C:/quad_test2.py", line 24, in > > x1 = integrate.quadrature(lambda b: integrand(b,aa,c), b1, b2) > > File "C:/quad_test2.py", line 18, in integrand > > return a0*b0*b0*c0 #If this contains a) the program crashes > > ValueError: frames are not aligned > > > _____________________________________________________________________ > This e-mail has been scanned for viruses by MCI's Internet Managed > Scanning Services - powered by MessageLabs. For further information > visit http://www.mci.com From arnd.baecker at web.de Thu Sep 18 12:34:59 2003 From: arnd.baecker at web.de (Arnd Baecker) Date: Thu, 18 Sep 2003 18:34:59 +0200 (CEST) Subject: [SciPy-user] scipy general_function segfault In-Reply-To: References: Message-ID: Hi, a few more pieces for the puzzle: a) I also tried the following variants, all leading to a segfault: from scipy import * def addsubtract(a,b): if a > b: return a - b else: return a + b gfunc=special.general_function(addsubtract) gfunc([0,3,6,9],[1,3,5,7]) def justadd(a,b): """ This is different""" return a+b gfunc2=special.general_function(justadd) gfunc2([0,3,6,9],[1,3,5,7]) gfunc2(1,2) def justreturna(a,b): return a gfunc3=special.general_function(justadd) gfunc2([0,3,6,9],[1,3,5,7]) gfunc3(1,2) # this gives the right error message: nofct=10 gfunc=special.general_function(nofct) b) Instead of libwadpy I used a set of print /printfs to isolate the problem a little bit. The segfault occurs in the arraymap call of the __call__ method of general_function in scipy/special/basic.py. Then a few printf's in special/cephesmodule.c in the routine after /* ************************ */ static char arraymap_doc[] = "c1,..,cn = arraymap(pyfunc,inputs{,outputtypes})\n\n Loop over the elements of the inputs tuple, applying pyfunc to the set\n formed from each element of inputs. Place the output in arrays c1,...,cn.\n This function can make any pyfunc with scalar inputs and scalar outputs\n emulate a ufunc.\n"; static PyObject *map_PyFunc(PyObject *self, PyObject *args) { [...] printf("Alive0c\n"); fflush(stdout); if (setup_input_arrays(inputs,inputarrays,nin) == -1) { printf("try to free ...."); fflush(stdout); free(inputarrays); return NULL; } printf("Alive1\n"); fflush(stdout); [...] /* ************************ */ show that Alive0c shows up and next the segfault happens. Hmm, does this help in any way ? Pearu wrote: > I'll later try if I can figure out something from my case where > general_function segfaulted. It would be interesting, if this is the same place as above ... (still I somehow feal/fear that the segfault is due to some installation error on my side ...) Arnd From ChuckEsterbrook at yahoo.com Thu Sep 18 14:28:42 2003 From: ChuckEsterbrook at yahoo.com (Chuck Esterbrook) Date: Thu, 18 Sep 2003 11:28:42 -0700 Subject: [SciPy-user] Fwd: [SANDPYT] Reminder - San Diego Python meeting tonight In-Reply-To: <1063907937.4534.14.camel@granite> Message-ID: <2003918112842.034495@workstation> --- Original Message --- From: "Joshua Penix" Sent: Thu, 18 Sep 2003 10:58:57 -0700 Subject: [SANDPYT] Reminder - San Diego Python meeting tonight >?The San Diego Python Users' group is having its monthly meeting >?tonight. ?The topic will be wxPython (http://www.wxpython.org/), a >?Python binding to the wxWindows cross-platform GUI toolkit >?(http://www.wxwindows.org/). > >?The meeting will be held at the San Diego County of Education >?complex in Linda vista, in room 306: > > >?San Diego County Office of Education >?6401 Linda Vista Road >?San Diego, CA > > >?Doors open at 6:30PM, meeting starts at 7. > > >?For more information, visit SANDPYT's homepage: >?http://www.sandpyt.org > >?Also a quick reminder that SANDPYT unfortunately lost its mailing >?list membership, so if you were subscribed prior to September 8, >?2003, you will need to resubscribe. ?If you weren't subscribed, now >?is the time to do so! :^) > > >?http://www.sandpyt.org/mailman/listinfo/sandpyt > > >?--Josh > > >?_______________________________________________ >?SANDPYT mailing list >?SANDPYT at sandpyt.org >?http://www.sandpyt.org/mailman/listinfo/sandpyt From arnd.baecker at web.de Thu Sep 18 14:32:27 2003 From: arnd.baecker at web.de (Arnd Baecker) Date: Thu, 18 Sep 2003 20:32:27 +0200 (CEST) Subject: [SciPy-user] scipy general_function segfault In-Reply-To: References: Message-ID: and one more: I did another reinstall at home. I also managed to compile libwadpy. However the output is not as helpful as I hoped: Alive0c WAD: Collecting debugging information... WAD: Unable to generate stack trace. WAD: Maybe the call stack has been corrupted by buffer overflow. zsh: 5332 segmentation fault ipython Independent of this: could the segfault be compiler dependent ? The cephesmodule.o for cephes.so is compiled with gcc 3.3.1: gcc -v Reading specs from /usr/lib/gcc-lib/i386-linux/3.3.1/specs Configured with: ../src/configure -v --enable-languages=c,c++,java,f77,pascal,objc,ada,treelang --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-gxx-include-dir=/usr/include/c++/3.3 --enable-shared --with-system-zlib --enable-nls --without-included-gettext --enable-__cxa_atexit --enable-clocale=gnu --enable-debug --enable-java-gc=boehm --enable-java-awt=xlib --enable-objc-gc i386-linux Thread model: posix gcc version 3.3.1 20030626 (Debian prerelease) Arnd From pearu at scipy.org Thu Sep 18 14:37:57 2003 From: pearu at scipy.org (Pearu Peterson) Date: Thu, 18 Sep 2003 21:37:57 +0300 (EEST) Subject: [SciPy-user] scipy general_function segfault In-Reply-To: Message-ID: On Thu, 18 Sep 2003, Arnd Baecker wrote: > and one more: > > I did another reinstall at home. I also managed > to compile libwadpy. > > However the output is not as helpful as I hoped: > > Alive0c > WAD: Collecting debugging information... > WAD: Unable to generate stack trace. > WAD: Maybe the call stack has been corrupted by buffer overflow. > zsh: 5332 segmentation fault ipython > > > Independent of this: could the segfault > be compiler dependent ? > > The cephesmodule.o for cephes.so is compiled > with gcc 3.3.1: > > gcc -v > Reading specs from /usr/lib/gcc-lib/i386-linux/3.3.1/specs > Configured with: ../src/configure -v > --enable-languages=c,c++,java,f77,pascal,objc,ada,treelang --prefix=/usr > --mandir=/usr/share/man --infodir=/usr/share/info > --with-gxx-include-dir=/usr/include/c++/3.3 --enable-shared > --with-system-zlib --enable-nls --without-included-gettext > --enable-__cxa_atexit --enable-clocale=gnu --enable-debug > --enable-java-gc=boehm --enable-java-awt=xlib --enable-objc-gc i386-linux > Thread model: posix > gcc version 3.3.1 20030626 (Debian prerelease) I have exactly the same setup and the same segfaults occur. I'll try downgrade Numeric 23.1 now... Pearu From jb.richet.areas at normandnet.fr Thu Sep 18 11:35:21 2003 From: jb.richet.areas at normandnet.fr (Jean-Baptiste Richet - AREAS) Date: Thu, 18 Sep 2003 16:35:21 +0100 Subject: [SciPy-user] [weave] newbie : compilation issue Message-ID: <3F69D0B9.5080707@normandnet.fr> Hi, I'm trying to have weave take my C functions into Python. I try to build a module with ext_tools, but I don't know much about writing Python extensions (actually, nothing). I just try to guess how to do from the tutorial and its examples. But of course it doesn't work. First, let me give you the error message: ============================= jb at areas:~/routines/commun$ python ext_date.py /home/jb/routines/commun/date_ext.cpp: In function `struct PyObject * c_positionne_flot(PyObject *, PyObject *, PyObject *)': /home/jb/routines/commun/date_ext.cpp:925: `raw_locals' undeclared (first use this function) /home/jb/routines/commun/date_ext.cpp:925: (Each undeclared identifier is reported only once /home/jb/routines/commun/date_ext.cpp:925: for each function it appears in.) /home/jb/routines/commun/date_ext.cpp:925: `raw_globals' undeclared (first use this function) /home/jb/routines/commun/date_ext.cpp:925: implicit declaration of function `int get_variable(...)' Traceback (most recent call last): File "ext_date.py", line 50, in ? build_date() File "ext_date.py", line 45, in build_date module.compile() File "/usr/local/lib/python2.3/site-packages/weave/ext_tools.py", line 349, in compile verbose = verbose, **kw) File "/usr/local/lib/python2.3/site-packages/weave/build_tools.py", line 194, in build_extension setup(name = module_name, ext_modules = [ext],verbose=verb) File "/usr/local/lib/python2.3/distutils/core.py", line 166, in setup raise SystemExit, "error: " + str(msg) weave.build_tools.CompileError: error: command 'gcc' failed with exit status 1 jb at areas:~/routines/commun$ ==================================== Maybe I lack some #include or something like that ? The line : PyObject* py_file = get_variable("fichier_src",raw_locals,raw_globals); from which the error is raised, was found in the weave tutorial about file conversions. I can hardly understand what it does. Here is the code at the bottom of the message. [I hesitate to give the date.c code, or the date_ext.cpp code, it's a bit long, and there's no compile error from it. If you need it to help me, please tell me.] thanks for your help, JBR ================ ext_date.py ========================= # -*- coding: UTF-8 -*- #test d'utilisation de weave pour cr?er une biblioth?que from weave import ext_tools fichier_date_c = open('date.c','r') code_date_c = fichier_date_c.read() fichier_src = fichier_date_c fichier_log = open('log.log','w') pdt = 'a' date = 1.23 def build_date(): """contruit le module d'extension """ module = ext_tools.ext_module('date_ext') #fonction de positionnement dans un fichier """ positionne_flot a 4 arguments, un p_pointeur de fichier en lecture, un p_pointeur de fichier en ?criture (log), un caract?re et une date (double) """ ext_code = """ PyObject* py_file = get_variable("fichier_src",raw_locals,raw_globals); FILE* file = py_to_file(py_file,"fichier_src"); PyObject* py_log = get_variable("fichier_log",raw_locals,raw_globals); FILE* log = py_to_file(py_log,"fichier_log"); FILE** p_file = &file; FILE** p_log = &log; char c_pdt = std::string(pdt).c_str()[0]; int resultat; resultat = positionne_flot(p_file,c_pdt,date,p_log); return_val = Py::new_reference_to(Py::Int(resultat)); """ fonction = ext_tools.ext_function('c_positionne_flot',ext_code,['fichier_src','pdt','date','fichier_log']) fonction.customize.add_support_code(code_date_c) module.add_function(fonction) module.compile() try: import date_ext except ImportError: build_date() import date_ext ============================================= -- Jean-Baptiste Richet AREAS _________________________________ Association r?gionale pour l'?tude et l'am?lioration des sols 2, avenue Foch 76460 Saint Val?ry en Caux t?l : +33 2 35 97 25 12 fax : +33 2 35 97 25 73 _________________________________ From pearu at scipy.org Thu Sep 18 16:44:36 2003 From: pearu at scipy.org (Pearu Peterson) Date: Thu, 18 Sep 2003 23:44:36 +0300 (EEST) Subject: [SciPy-user] scipy general_function segfault In-Reply-To: Message-ID: On Thu, 18 Sep 2003, Arnd Baecker wrote: > Independent of this: could the segfault be compiler dependent ? Indeed, the segfaults seem to occur only with gcc 3.3.1 (Debian) and when using general_function, other special module tests pass ok. Here follows my test results: Numeric 23.0 ------------ \ Python | 2.3+ | 2.2.3+ gcc \ | | ----------------+----------+--------- 3.3.1 | segfault | segfault 3.2.3 | OK | OK 2.95.4 | OK | OK Numeric 21.0 ------------ gcc | Python 2.1.3+ ---------+-------------- 3.3.1 | segfault 3.2.3 | OK 2.95.4 | OK All Python versions are compiled with gcc 3.3.1, btw. Pearu From arnd.baecker at web.de Thu Sep 18 18:43:23 2003 From: arnd.baecker at web.de (Arnd Baecker) Date: Fri, 19 Sep 2003 00:43:23 +0200 (CEST) Subject: [SciPy-user] scipy general_function segfault In-Reply-To: References: Message-ID: On Thu, 18 Sep 2003, Pearu Peterson wrote: > On Thu, 18 Sep 2003, Arnd Baecker wrote: > > > Independent of this: could the segfault be compiler dependent ? > > Indeed, the segfaults seem to occur only with gcc 3.3.1 (Debian) and when > using general_function, other special module tests pass ok. > Here follows my test results: Very good - so this allows for a work-around. Still this is not really satisfactory- however I fear that it will be really tricky to find the bug in the debian gcc 3.3.1 (also I am not sure how crucial this "prerelease" tag is). Would a small unit test for general_function be useful ? Arnd From ferrell at diablotech.com Thu Sep 18 19:43:21 2003 From: ferrell at diablotech.com (Robert Ferrell) Date: Thu, 18 Sep 2003 23:43:21 -0000 (GMT) Subject: [SciPy-user] ActiveState Python Message-ID: <1453.128.165.144.120.1063928601.squirrel@webmail.pair.com> I'd like to try ActiveState's Visual Python plug-in for Visual Studio ..NET. However, AS says that it only works with Active State's Python. I'm not sure why that is. However, would that preclude use of SciPy? I'm using Windows, and would really like to avoid building SciPy myself. Downloading the Sumo SciPy binary file is so painless for me. thanks, -robert From DavidA at ActiveState.com Thu Sep 18 20:13:11 2003 From: DavidA at ActiveState.com (David Ascher) Date: Thu, 18 Sep 2003 17:13:11 -0700 Subject: [SciPy-user] ActiveState Python In-Reply-To: <1453.128.165.144.120.1063928601.squirrel@webmail.pair.com> References: <1453.128.165.144.120.1063928601.squirrel@webmail.pair.com> Message-ID: <3F6A4A17.4070109@ActiveState.com> Robert Ferrell wrote: >I'd like to try ActiveState's Visual Python plug-in for Visual Studio >..NET. However, AS says that it only works with Active State's Python. >I'm not sure why that is. However, would that preclude use of SciPy? I'm >using Windows, and would really like to avoid building SciPy myself. >Downloading the Sumo SciPy binary file is so painless for me. > > The requirement for ActivePython is no longer part of VisualPython. It requires Python 2.1 or later, but not specifically ActivePython. It should work fine w/ SciPy. If the website still mentions the old requirements, please let me know and I'll have it fixed. --David Ascher ActiveState From DavidA at ActiveState.com Thu Sep 18 20:13:11 2003 From: DavidA at ActiveState.com (David Ascher) Date: Thu, 18 Sep 2003 17:13:11 -0700 Subject: [SciPy-user] ActiveState Python In-Reply-To: <1453.128.165.144.120.1063928601.squirrel@webmail.pair.com> References: <1453.128.165.144.120.1063928601.squirrel@webmail.pair.com> Message-ID: <3F6A4A17.4070109@ActiveState.com> Robert Ferrell wrote: >I'd like to try ActiveState's Visual Python plug-in for Visual Studio >..NET. However, AS says that it only works with Active State's Python. >I'm not sure why that is. However, would that preclude use of SciPy? I'm >using Windows, and would really like to avoid building SciPy myself. >Downloading the Sumo SciPy binary file is so painless for me. > > The requirement for ActivePython is no longer part of VisualPython. It requires Python 2.1 or later, but not specifically ActivePython. It should work fine w/ SciPy. If the website still mentions the old requirements, please let me know and I'll have it fixed. --David Ascher ActiveState From trentm at ActiveState.com Thu Sep 18 20:21:05 2003 From: trentm at ActiveState.com (Trent Mick) Date: Thu, 18 Sep 2003 17:21:05 -0700 Subject: [SciPy-user] ActiveState Python In-Reply-To: <1453.128.165.144.120.1063928601.squirrel@webmail.pair.com>; from ferrell@diablotech.com on Thu, Sep 18, 2003 at 11:43:21PM -0000 References: <1453.128.165.144.120.1063928601.squirrel@webmail.pair.com> Message-ID: <20030918172105.D21177@ActiveState.com> [Robert Ferrell wrote] > I'd like to try ActiveState's Visual Python plug-in for Visual Studio > ..NET. However, AS says that it only works with Active State's Python. > I'm not sure why that is. However, would that preclude use of SciPy? I'm > using Windows, and would really like to avoid building SciPy myself. > Downloading the Sumo SciPy binary file is so painless for me. I don't follow this list very carefully so my pardons if this has been answered already. As of the latest version of Visual Python, ActivePython is not required for it to function, just some _Python_. That being said, SciPy's distro of Python is not specifically tested (just ActivePython and python.org's distro) but I wouldn't expect there to be any problems. http://www.activestate.com/Products/Visual_Python/ ... Broad Python Version Support - Work with your preferred version of Python NEW! Cheers, Trent -- Trent Mick TrentM at ActiveState.com From trentm at ActiveState.com Thu Sep 18 20:21:05 2003 From: trentm at ActiveState.com (Trent Mick) Date: Thu, 18 Sep 2003 17:21:05 -0700 Subject: [SciPy-user] ActiveState Python In-Reply-To: <1453.128.165.144.120.1063928601.squirrel@webmail.pair.com>; from ferrell@diablotech.com on Thu, Sep 18, 2003 at 11:43:21PM -0000 References: <1453.128.165.144.120.1063928601.squirrel@webmail.pair.com> Message-ID: <20030918172105.D21177@ActiveState.com> [Robert Ferrell wrote] > I'd like to try ActiveState's Visual Python plug-in for Visual Studio > ..NET. However, AS says that it only works with Active State's Python. > I'm not sure why that is. However, would that preclude use of SciPy? I'm > using Windows, and would really like to avoid building SciPy myself. > Downloading the Sumo SciPy binary file is so painless for me. I don't follow this list very carefully so my pardons if this has been answered already. As of the latest version of Visual Python, ActivePython is not required for it to function, just some _Python_. That being said, SciPy's distro of Python is not specifically tested (just ActivePython and python.org's distro) but I wouldn't expect there to be any problems. http://www.activestate.com/Products/Visual_Python/ ... Broad Python Version Support - Work with your preferred version of Python NEW! Cheers, Trent -- Trent Mick TrentM at ActiveState.com From pearu at scipy.org Fri Sep 19 00:59:20 2003 From: pearu at scipy.org (Pearu Peterson) Date: Fri, 19 Sep 2003 07:59:20 +0300 (EEST) Subject: [SciPy-user] scipy general_function segfault In-Reply-To: Message-ID: On Fri, 19 Sep 2003, Arnd Baecker wrote: > On Thu, 18 Sep 2003, Pearu Peterson wrote: > > > On Thu, 18 Sep 2003, Arnd Baecker wrote: > > > > > Independent of this: could the segfault be compiler dependent ? > > > > Indeed, the segfaults seem to occur only with gcc 3.3.1 (Debian) and when > > using general_function, other special module tests pass ok. > > Here follows my test results: > > Very good - so this allows for a work-around. > Still this is not really satisfactory- however > I fear that it will be really tricky to find > the bug in the debian gcc 3.3.1 (also I am not > sure how crucial this "prerelease" tag is). gcc 3.3.2 will be released Oct 1, I hope it will fix the problem. > Would a small unit test for general_function > be useful ? It is in the CVS repository already;) Here is a quicker way to test the general_function issue (rather than rebuilding scipy) with different compilers: cd scipy/Lib/special rm -rf build python setup_special.py build python tests/test_basic.py Regards, Pearu From DavidA at ActiveState.com Fri Sep 19 01:44:49 2003 From: DavidA at ActiveState.com (David Ascher) Date: Thu, 18 Sep 2003 22:44:49 -0700 Subject: [SciPy-user] ActiveState Python In-Reply-To: <20030918172105.D21177@ActiveState.com> References: <1453.128.165.144.120.1063928601.squirrel@webmail.pair.com> <20030918172105.D21177@ActiveState.com> Message-ID: <3F6A97D1.8050809@ActiveState.com> Trent Mick wrote: > [Robert Ferrell wrote] > >>I'd like to try ActiveState's Visual Python plug-in for Visual Studio >>..NET. However, AS says that it only works with Active State's Python. >>I'm not sure why that is. However, would that preclude use of SciPy? I'm >>using Windows, and would really like to avoid building SciPy myself. >>Downloading the Sumo SciPy binary file is so painless for me. > > > I don't follow this list very carefully so my pardons if this has been > answered already. Seriously, Trent and I sit 2 feet apart from one another and were both at work when we wrote those emails. Communication these days... --da From DavidA at ActiveState.com Fri Sep 19 01:44:49 2003 From: DavidA at ActiveState.com (David Ascher) Date: Thu, 18 Sep 2003 22:44:49 -0700 Subject: [SciPy-user] ActiveState Python In-Reply-To: <20030918172105.D21177@ActiveState.com> References: <1453.128.165.144.120.1063928601.squirrel@webmail.pair.com> <20030918172105.D21177@ActiveState.com> Message-ID: <3F6A97D1.8050809@ActiveState.com> Trent Mick wrote: > [Robert Ferrell wrote] > >>I'd like to try ActiveState's Visual Python plug-in for Visual Studio >>..NET. However, AS says that it only works with Active State's Python. >>I'm not sure why that is. However, would that preclude use of SciPy? I'm >>using Windows, and would really like to avoid building SciPy myself. >>Downloading the Sumo SciPy binary file is so painless for me. > > > I don't follow this list very carefully so my pardons if this has been > answered already. Seriously, Trent and I sit 2 feet apart from one another and were both at work when we wrote those emails. Communication these days... --da From nwagner at mecha.uni-stuttgart.de Fri Sep 19 06:06:51 2003 From: nwagner at mecha.uni-stuttgart.de (Nils Wagner) Date: Fri, 19 Sep 2003 12:06:51 +0200 Subject: [SciPy-user] Matlab's orth module Message-ID: <3F6AD53B.F500AF0@mecha.uni-stuttgart.de> Dear experts, Is it somehow possible to realize Matlab's orth function in scipy ? Range space of a matrix Syntax B = orth(A) Description B = orth(A) returns an orthonormal basis for the range of A. The columns of B span the same space as the columns of A, and the columns of B are orthogonal, so that B'*B = eye(rank(A)). The number of columns of B is the rank of A. A small example would be appreciated. Thanks in advance Nils From arnd.baecker at web.de Fri Sep 19 05:14:05 2003 From: arnd.baecker at web.de (Arnd Baecker) Date: Fri, 19 Sep 2003 11:14:05 +0200 (CEST) Subject: [SciPy-user] Matlab's orth module In-Reply-To: <3F6AD53B.F500AF0@mecha.uni-stuttgart.de> References: <3F6AD53B.F500AF0@mecha.uni-stuttgart.de> Message-ID: Hi Nils, google is your friend here ("matlab orth python"): http://pdilib.sourceforge.net/MLab2.py Actually, it would be nice to see these integrated either in scipy or in MLab itself (or numarray?) Arnd On Fri, 19 Sep 2003, Nils Wagner wrote: > Dear experts, > > Is it somehow possible to realize Matlab's orth function in scipy ? > > Range space of a matrix > > Syntax > > B = orth(A) > > Description > > B = orth(A) returns an orthonormal basis for the range of A. > The columns of B span the same space as the columns of A, and the > columns of B are orthogonal, so that B'*B = > eye(rank(A)). The number of columns of B is the rank of A. > > A small example would be appreciated. > > Thanks in advance > > Nils > > _______________________________________________ > SciPy-user mailing list > SciPy-user at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-user > From arnd.baecker at web.de Fri Sep 19 06:02:29 2003 From: arnd.baecker at web.de (Arnd Baecker) Date: Fri, 19 Sep 2003 12:02:29 +0200 (CEST) Subject: [SciPy-user] scipy general_function segfault In-Reply-To: References: Message-ID: Hi, today I re-installed with export CC=gcc-3.2 and general_function works again - great. Many thanks! On Fri, 19 Sep 2003, Pearu Peterson wrote: > > Would a small unit test for general_function > > be useful ? > > It is in the CVS repository already;) Obviously, things get updated more quickly than one can download ;-) Excellent! I just tested this and a scipy.test(1) gives [...] .............EE.................................zsh: 3532 segmentation fault ipython This clearly shows the user that there is a problem, but a proper bug-report will be difficult by this information alone. Is there a way to add a "verbose" option to the tests so that it automatically tells, which test is being run next? (Or could one use a log-file with this information?) Cheers, Arnd From oliphant at ee.byu.edu Fri Sep 19 06:45:32 2003 From: oliphant at ee.byu.edu (Travis E. Oliphant) Date: Fri, 19 Sep 2003 04:45:32 -0600 Subject: [SciPy-user] Matlab's orth module In-Reply-To: References: <3F6AD53B.F500AF0@mecha.uni-stuttgart.de> Message-ID: <3F6ADE4C.3000306@ee.byu.edu> Arnd Baecker wrote: > Hi Nils, > > google is your friend here ("matlab orth python"): > http://pdilib.sourceforge.net/MLab2.py > > Actually, it would be nice to see these integrated > either in scipy or in MLab itself (or numarray?) > I believe all of these functions are in scipy.linalg In particular info(scipy.linalg.orth) orth(A) Return an orthonormal basis for the range of A using svd -Travis O. From nwagner at mecha.uni-stuttgart.de Fri Sep 19 08:27:35 2003 From: nwagner at mecha.uni-stuttgart.de (Nils Wagner) Date: Fri, 19 Sep 2003 14:27:35 +0200 Subject: [SciPy-user] Matlab's orth module References: <3F6AD53B.F500AF0@mecha.uni-stuttgart.de> <3F6ADE4C.3000306@ee.byu.edu> Message-ID: <3F6AF637.C70A43CC@mecha.uni-stuttgart.de> "Travis E. Oliphant" schrieb: > > Arnd Baecker wrote: > > Hi Nils, > > > > google is your friend here ("matlab orth python"): > > http://pdilib.sourceforge.net/MLab2.py > > > > Actually, it would be nice to see these integrated > > either in scipy or in MLab itself (or numarray?) > > > > I believe all of these functions are in scipy.linalg > > In particular > > info(scipy.linalg.orth) > orth(A) > > Return an orthonormal basis for the range of A using svd > > -Travis O. > I have ignored that module in linalg. However, if I use linalg.orth I obtain an error Traceback (most recent call last): File "pseudospectra.py", line 165, in ? V = linalg.orth(P.real) File "/usr/local/lib/python2.1/site-packages/scipy/linalg/decomp.py", line 533, in orth tol = max(M,N)*amax(s)*eps NameError: global name 'amax' is not defined Any idea ? Nils > _______________________________________________ > SciPy-user mailing list > SciPy-user at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-user From oliphant at ee.byu.edu Fri Sep 19 07:28:27 2003 From: oliphant at ee.byu.edu (Travis E. Oliphant) Date: Fri, 19 Sep 2003 05:28:27 -0600 Subject: [SciPy-user] Matlab's orth module In-Reply-To: <3F6AF637.C70A43CC@mecha.uni-stuttgart.de> References: <3F6AD53B.F500AF0@mecha.uni-stuttgart.de> <3F6ADE4C.3000306@ee.byu.edu> <3F6AF637.C70A43CC@mecha.uni-stuttgart.de> Message-ID: <3F6AE85B.1030202@ee.byu.edu> > > I have ignored that module in linalg. However, if I use > linalg.orth I obtain an error > > Traceback (most recent call last): > File "pseudospectra.py", line 165, in ? > V = linalg.orth(P.real) > File "/usr/local/lib/python2.1/site-packages/scipy/linalg/decomp.py", > line 533, in orth > tol = max(M,N)*amax(s)*eps > NameError: global name 'amax' is not defined This error happens quite a bit during development (the name amax has not been moved into decomp.py). This is now fixed in CVS, but you can fix it by pre-pending scipy_base. to amax and sum in the orth subroutine. -Travis From nwagner at mecha.uni-stuttgart.de Fri Sep 19 08:53:08 2003 From: nwagner at mecha.uni-stuttgart.de (Nils Wagner) Date: Fri, 19 Sep 2003 14:53:08 +0200 Subject: [SciPy-user] Matlab's orth module References: <3F6AD53B.F500AF0@mecha.uni-stuttgart.de> <3F6AF637.C70A43CC@mecha.uni-stuttgart.de> <3F6AE85B.1030202@ee.byu.edu> Message-ID: <3F6AFC34.E505C77C@mecha.uni-stuttgart.de> "Travis E. Oliphant" schrieb: > > > > > I have ignored that module in linalg. However, if I use > > linalg.orth I obtain an error > > > > Traceback (most recent call last): > > File "pseudospectra.py", line 165, in ? > > V = linalg.orth(P.real) > > File "/usr/local/lib/python2.1/site-packages/scipy/linalg/decomp.py", > > line 533, in orth > > tol = max(M,N)*amax(s)*eps > > NameError: global name 'amax' is not defined > > This error happens quite a bit during development (the name amax has not > been moved into decomp.py). > > This is now fixed in CVS, but you can fix it by pre-pending scipy_base. > to amax and sum in the orth subroutine. > > -Travis > > _____ Travis, Thank you very much for the fix. BTW, Is linalg.lu ready to apply to complex matrices ? Nils __________________________________________ > SciPy-user mailing list > SciPy-user at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-user From nwagner at mecha.uni-stuttgart.de Fri Sep 19 09:14:05 2003 From: nwagner at mecha.uni-stuttgart.de (Nils Wagner) Date: Fri, 19 Sep 2003 15:14:05 +0200 Subject: [SciPy-user] Scipy's orth is more reliable Message-ID: <3F6B011D.8F043FAE@mecha.uni-stuttgart.de> Hi all, It seems to me, that scipy's orth module is more reliable than the one, which comes with MLab2.py. . http://pdilib.sourceforge.net/MLab2.py Nils From arnd.baecker at web.de Fri Sep 19 08:12:35 2003 From: arnd.baecker at web.de (Arnd Baecker) Date: Fri, 19 Sep 2003 14:12:35 +0200 (CEST) Subject: [SciPy-user] Scipy's orth is more reliable In-Reply-To: <3F6B011D.8F043FAE@mecha.uni-stuttgart.de> References: <3F6B011D.8F043FAE@mecha.uni-stuttgart.de> Message-ID: just out of curiosity - what to you mean by "more reliable"? And to quote you "A small example would be appreciated." (sorry, I could not resist ;-) Arnd On Fri, 19 Sep 2003, Nils Wagner wrote: > Hi all, > > It seems to me, that scipy's orth module is more reliable than > the one, which comes with MLab2.py. . > > http://pdilib.sourceforge.net/MLab2.py > > Nils > > _______________________________________________ > SciPy-user mailing list > SciPy-user at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-user > From nwagner at mecha.uni-stuttgart.de Fri Sep 19 09:44:24 2003 From: nwagner at mecha.uni-stuttgart.de (Nils Wagner) Date: Fri, 19 Sep 2003 15:44:24 +0200 Subject: [SciPy-user] Scipy's orth is more reliable References: <3F6B011D.8F043FAE@mecha.uni-stuttgart.de> Message-ID: <3F6B0838.7343E00D@mecha.uni-stuttgart.de> Arnd Baecker schrieb: > > just out of curiosity - what to you mean by "more reliable"? > And to quote you > "A small example would be appreciated." > (sorry, I could not resist ;-) > > Arnd > This is somehow lengthy to explain, but I will try. I have computed a spectral projector for a defective matrix.A where the Jordan curve \Gamma is a circle for simplicity. The circle encloses the double eigenvalue, which is defective. Then I have orthonormalized the projector. The associated invariant subspace displays the geometric multiplicity of the eigenvalue. If I apply scipy's orth functions, I am able to show the defective nature of that eigenvalue. However with MLab's orth function, the result is polluted by rounding errors or whatever. Nils > On Fri, 19 Sep 2003, Nils Wagner wrote: > > > Hi all, > > > > It seems to me, that scipy's orth module is more reliable than > > the one, which comes with MLab2.py. . > > > > http://pdilib.sourceforge.net/MLab2.py > > > > Nils > > > > _______________________________________________ > > 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 arnd.baecker at web.de Fri Sep 19 08:38:43 2003 From: arnd.baecker at web.de (Arnd Baecker) Date: Fri, 19 Sep 2003 14:38:43 +0200 (CEST) Subject: [SciPy-user] Scipy's orth is more reliable In-Reply-To: <3F6B0838.7343E00D@mecha.uni-stuttgart.de> References: <3F6B011D.8F043FAE@mecha.uni-stuttgart.de> <3F6B0838.7343E00D@mecha.uni-stuttgart.de> Message-ID: On Fri, 19 Sep 2003, Nils Wagner wrote: > This is somehow lengthy to explain, but I will try. > I have computed a spectral projector for a defective matrix.A > where the Jordan curve \Gamma is a circle for simplicity. > The circle encloses the double eigenvalue, which is defective. > Then I have orthonormalized the projector. > The associated invariant subspace displays the geometric multiplicity > of the eigenvalue. > If I apply scipy's orth functions, I am able to show the defective > nature of that eigenvalue. That's nice! > However with MLab's orth function, the result is polluted by rounding > errors or whatever. Maybe it is worth pointing this out to the authors of MLab2? Arnd From ferrell at diablotech.com Fri Sep 19 09:17:59 2003 From: ferrell at diablotech.com (ferrell at diablotech.com) Date: Fri, 19 Sep 2003 07:17:59 -0600 Subject: [SciPy-user] ActiveState Python In-Reply-To: <3F6A97D1.8050809@ActiveState.com> References: <1453.128.165.144.120.1063928601.squirrel@webmail.pair.com> <20030918172105.D21177@ActiveState.com> <3F6A97D1.8050809@ActiveState.com> Message-ID: <16235.519.526801.311291@prometheus.ta52.lanl.gov> David Ascher writes: > Trent Mick wrote: > > > [Robert Ferrell wrote] > > > >>I'd like to try ActiveState's Visual Python plug-in for Visual Studio > >>..NET. However, AS says that it only works with Active State's Python. > >>I'm not sure why that is. However, would that preclude use of SciPy? I'm > >>using Windows, and would really like to avoid building SciPy myself. > >>Downloading the Sumo SciPy binary file is so painless for me. > > > > > > I don't follow this list very carefully so my pardons if this has been > > answered already. > > Seriously, Trent and I sit 2 feet apart from one another and were both > at work when we wrote those emails. Communication these days... > Thanks to both of you for your replies. The documentation does say that ActiveState Pytyhon is required, but good to hear that is old info. I'll give Visual Python a try with the latest SciPy Sumo-tarball (Python 2.3). thanks again, -robert From pearu at scipy.org Sat Sep 20 03:23:05 2003 From: pearu at scipy.org (Pearu Peterson) Date: Sat, 20 Sep 2003 10:23:05 +0300 (EEST) Subject: [SciPy-user] scipy general_function segfault In-Reply-To: Message-ID: On Fri, 19 Sep 2003, Arnd Baecker wrote: > today I re-installed with > export CC=gcc-3.2 > and general_function works again - great. I just stripped special module to contain only code needed for general_function and compiled it using gcc-3.3.1. Now general_function test passes OK. Travis, do you mind if I factor arraymap out from cephesmodule.c to a separate extension module, say arraymapmodule.c? This might fix the gcc-3.3.1 segfault issue (though, the actual cause for the segfault is left to be discovered). > On Fri, 19 Sep 2003, Pearu Peterson wrote: > > > > Would a small unit test for general_function > > > be useful ? > > > > It is in the CVS repository already;) > > Obviously, things get updated more quickly than one can download ;-) > Excellent! I just tested this and > a scipy.test(1) gives > > [...] > .............EE.................................zsh: > 3532 segmentation fault ipython > > This clearly shows the user that there is a problem, > but a proper bug-report will be difficult by this information alone. > > Is there a way to add a "verbose" option to the tests > so that it automatically tells, which test is being run next? > (Or could one use a log-file with this information?) Yes, there is. One must use verbosity=2 argument in TextTestRunner constructor in tests/test_*.py files. I think it makes sense adding such a keyword argument also to scipy.test() function. Keep an eye on Scipy CVS...;) Pearu From oliphant at ee.byu.edu Sat Sep 20 14:23:06 2003 From: oliphant at ee.byu.edu (Travis Oliphant) Date: Sat, 20 Sep 2003 12:23:06 -0600 Subject: [SciPy-user] SciPy 0.2 release Message-ID: <3F6C9B0A.6040805@ee.byu.edu> We are going to release SciPy 0.2 next week (Thursday 1:00pm Central Time). Please report any remaining outstanding issues that must be resolved before we tag the CVS tree with the release number. SciPy will still undergo improvements so SciPy 0.3 does not have to be far behind. Thanks for all of your reports so far. -Travis Oliphant From eric at enthought.com Sun Sep 21 02:45:34 2003 From: eric at enthought.com (Eric Jones) Date: Sun, 21 Sep 2003 01:45:34 -0500 (CDT) Subject: [SciPy-user] [weave] newbie : compilation issue Message-ID: <20030921064534.0600A64008@www.enthought.com> Hey JBR, The docs are out of date compared to the CVS. I don't have all your source to check against, but I would expect the following is fairly close to what you want. Weave sould do all the work translating Python variables to C/C++ for you, at least in the case of "standard" argument types which you are using, so the PyObject* stuff you have in your code isn't necessary. If the code below doesn't work, attach the C files your using and I see what I can do to help out. eric from weave import ext_tools def build_date(): """contruit le module d'extension """ module = ext_tools.ext_module('date_ext') #fonction de positionnement dans un fichier """ positionne_flot a 4 arguments, un p_pointeur de fichier en lecture, un p_pointeur de fichier en ?criture (log), un caract?re et une date (double) """ fichier_date_c = open('date.c','r') code_date_c = fichier_date_c.read() # arguments fichier_src = fichier_date_c fichier_log = open('log.log','w') pdt = 'a' date = 1.23 ext_code = "return_val = positionne_flot(&p_file,pdt[0],date,&p_log);" fonction = ext_tools.ext_function('c_positionne_flot',ext_code,['fichier_src','pdt','date','fichier_log']) fonction.customize.add_support_code(code_date_c) module.add_function(fonction) module.compile() try: import date_ext except ImportError: build_date() import date_ext Jean-Baptiste Richet - AREAS wrote .. > Hi, > > I'm trying to have weave take my C functions into Python. I try to build > a module with ext_tools, but I don't know much about writing Python > extensions (actually, nothing). I just try to guess how to do from the > tutorial and its examples. But of course it doesn't work. > First, let me give you the error message: > ============================= > jb at areas:~/routines/commun$ python ext_date.py > /home/jb/routines/commun/date_ext.cpp: In function `struct PyObject * > c_positionne_flot(PyObject *, PyObject *, PyObject *)': > /home/jb/routines/commun/date_ext.cpp:925: `raw_locals' undeclared > (first use this function) > /home/jb/routines/commun/date_ext.cpp:925: (Each undeclared identifier > is reported only once > /home/jb/routines/commun/date_ext.cpp:925: for each function it appears > in.) > /home/jb/routines/commun/date_ext.cpp:925: `raw_globals' undeclared > (first use this function) > /home/jb/routines/commun/date_ext.cpp:925: implicit declaration of > function `int get_variable(...)' > Traceback (most recent call last): > File "ext_date.py", line 50, in ? > build_date() > File "ext_date.py", line 45, in build_date > module.compile() > File "/usr/local/lib/python2.3/site-packages/weave/ext_tools.py", line > 349, in compile > verbose = verbose, **kw) > File "/usr/local/lib/python2.3/site-packages/weave/build_tools.py", > line 194, > in build_extension > setup(name = module_name, ext_modules = [ext],verbose=verb) > File "/usr/local/lib/python2.3/distutils/core.py", line 166, in setup > raise SystemExit, "error: " + str(msg) > weave.build_tools.CompileError: error: command 'gcc' failed with exit > status 1 > jb at areas:~/routines/commun$ > ==================================== > > Maybe I lack some #include or something like that ? > The line : > PyObject* py_file = get_variable("fichier_src",raw_locals,raw_globals); > from which the error is raised, was found in the weave tutorial about file > conversions. I can hardly understand what it does. > Here is the code at the bottom of the message. > [I hesitate to give the date.c code, or the date_ext.cpp code, it's a bit > long, and there's no compile error from it. If you need it to help me, > please tell me.] > > thanks for your help, > JBR > > ================ ext_date.py ========================= > # -*- coding: UTF-8 -*- > > #test d'utilisation de weave pour cr?er une biblioth?que > > from weave import ext_tools > > fichier_date_c = open('date.c','r') > code_date_c = fichier_date_c.read() > > fichier_src = fichier_date_c > fichier_log = open('log.log','w') > pdt = 'a' > date = 1.23 > def build_date(): > """contruit le module d'extension > """ > module = ext_tools.ext_module('date_ext') > > #fonction de positionnement dans un fichier > """ > positionne_flot a 4 arguments, un p_pointeur de fichier en lecture, > un p_pointeur de fichier en ?criture (log), un caract?re et une > date (double) > """ > ext_code = """ > PyObject* py_file = get_variable("fichier_src",raw_locals,raw_globals); > FILE* file = py_to_file(py_file,"fichier_src"); > PyObject* py_log = get_variable("fichier_log",raw_locals,raw_globals); > FILE* log = py_to_file(py_log,"fichier_log"); > > FILE** p_file = &file; > FILE** p_log = &log; > > char c_pdt = std::string(pdt).c_str()[0]; > > int resultat; > > resultat = positionne_flot(p_file,c_pdt,date,p_log); > > return_val = Py::new_reference_to(Py::Int(resultat)); > """ > fonction = ext_tools.ext_function('c_positionne_flot',ext_code,['fichier_src','pdt','date','fichier_log']) > fonction.customize.add_support_code(code_date_c) > module.add_function(fonction) > module.compile() > > try: > import date_ext > except ImportError: > build_date() > import date_ext > ============================================= > > -- > Jean-Baptiste Richet > AREAS > _________________________________ > Association r?gionale pour l'?tude > et l'am?lioration des sols > 2, avenue Foch > 76460 Saint Val?ry en Caux > t?l : +33 2 35 97 25 12 > fax : +33 2 35 97 25 73 > _________________________________ > > > _______________________________________________ > SciPy-user mailing list > SciPy-user at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-user From andymain at dsl.pipex.com Sun Sep 21 17:49:19 2003 From: andymain at dsl.pipex.com (Andy Main) Date: Sun, 21 Sep 2003 22:49:19 +0100 Subject: [SciPy-user] Newbie issues in moving to SciPy Message-ID: <000901c3808a$370e1da0$0201a8c0@laptop> Hi, Sorry if I am repeating messages you always get, but hey nevermind! I really don't quite know where to start with Sci Python, I'm used to Matlab, and am really wondering how similar the programming is. I am basically wanting to output graphics using Chaco, should I be learning Python properly, or don't really have to as it is just a syntax difference to what I am used to? Any links to tutorials would be gratefully received. Thanks Andy. From nwagner at mecha.uni-stuttgart.de Mon Sep 22 12:50:05 2003 From: nwagner at mecha.uni-stuttgart.de (Nils Wagner) Date: Mon, 22 Sep 2003 18:50:05 +0200 Subject: [SciPy-user] SciPy 0.2 release References: <3F6C9B0A.6040805@ee.byu.edu> Message-ID: <3F6F283D.3DFA78FF@mecha.uni-stuttgart.de> Travis Oliphant schrieb: > > We are going to release SciPy 0.2 next week (Thursday 1:00pm Central > Time). Please report any remaining outstanding issues that must be > resolved before we tag the CVS tree with the release number. SciPy will > still undergo improvements so SciPy 0.3 does not have to be far behind. > > Thanks for all of your reports so far. > > -Travis Oliphant > > _______________________________________________ > SciPy-user mailing list > SciPy-user at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-user It would be nice, if linalg.lu can be applied to complex matrices as well from scipy import * from RandomArray import * A = rand(4,4)+rand(4,4)*sqrt(-1.0) P,L,U = linalg.lu(A) Traceback (most recent call last): File "lu-test.py", line 4, in ? P,L,U = linalg.lu(A) File "/usr/local/lib/python2.1/site-packages/scipy/linalg/decomp.py", line 238, in lu p,l,u,info = flu(a1,permute_l=permute_l,overwrite_a = overwrite_a) TypeError: object of type 'None' is not callable Thanks in advance, Nils From pajer at iname.com Mon Sep 22 08:53:35 2003 From: pajer at iname.com (Gary Pajer) Date: Mon, 22 Sep 2003 08:53:35 -0400 Subject: [SciPy-user] SciPy 0.2 release: float deprecation warning References: <3F6C9B0A.6040805@ee.byu.edu> Message-ID: <001601c38108$89c4e690$01fd5644@playroom> I'm sure you're on to this issue, but I can't find much mention of it: E.g.:, with python2.3 *only* >>from scipy import plt >>plt.plot((1., 2., 3.)) /usr/local/lib/python2.3/site-packages/wxPython/gdi.py:283: DeprecationWarning: integer argument expected, got float self.this = gdic.new_wxColour(*_args,**_kwargs) /usr/local/lib/python2.3/site-packages/wxPython/gdi.py:570: DeprecationWarning: integer argument expected, got float val = gdic.wxDC_DrawRotatedText(self, *_args, **_kwargs) /usr/local/lib/python2.3/site-packages/wxPython/gdi.py:702: DeprecationWarning: integer argument expected, got float val = gdic.wxDC_SetClippingRegion(self, *_args, **_kwargs) these warnings have something to do with a change made in python in going to v. 2.3. I can't tell if the problem is with scipy or wxPython. I checked the wxPython bug tracker and mailing list archive, and it's mentioned there with the advice to clean up one's source code. -Gary ----- Original Message ----- From: "Travis Oliphant" To: ; Sent: Saturday, September 20, 2003 2:23 PM Subject: [SciPy-user] SciPy 0.2 release > We are going to release SciPy 0.2 next week (Thursday 1:00pm Central > Time). Please report any remaining outstanding issues that must be > resolved before we tag the CVS tree with the release number. SciPy will > still undergo improvements so SciPy 0.3 does not have to be far behind. > > Thanks for all of your reports so far. > > -Travis Oliphant From pajer at iname.com Sun Sep 21 10:13:08 2003 From: pajer at iname.com (Gary Pajer) Date: Sun, 21 Sep 2003 10:13:08 -0400 Subject: [SciPy-user] SciPy 0.2 release : python2.3 float deprcation warnings ?? References: <3F6C9B0A.6040805@ee.byu.edu> Message-ID: <000d01c3804a$7c716f90$01fd5644@playroom> I'm sure you're on to this issue, but I can't find much mention of it: E.g.:, with python2.3 *only* >>from scipy import plt >>plt.plot((1., 2., 3.)) /usr/local/lib/python2.3/site-packages/wxPython/gdi.py:283: DeprecationWarning: integer argument expected, got float self.this = gdic.new_wxColour(*_args,**_kwargs) /usr/local/lib/python2.3/site-packages/wxPython/gdi.py:570: DeprecationWarning: integer argument expected, got float val = gdic.wxDC_DrawRotatedText(self, *_args, **_kwargs) /usr/local/lib/python2.3/site-packages/wxPython/gdi.py:702: DeprecationWarning: integer argument expected, got float val = gdic.wxDC_SetClippingRegion(self, *_args, **_kwargs) these warnings have something to do with a change made in python in going to v. 2.3. I can't tell if the problem is with scipy or wxPython. I checked the wxPython bug tracker and mailing list archive, and it's mentioned there with the advice to clean up one's source code. -Gary ----- Original Message ----- From: "Travis Oliphant" To: ; Sent: Saturday, September 20, 2003 2:23 PM Subject: [SciPy-user] SciPy 0.2 release > We are going to release SciPy 0.2 next week (Thursday 1:00pm Central > Time). Please report any remaining outstanding issues that must be > resolved before we tag the CVS tree with the release number. SciPy will > still undergo improvements so SciPy 0.3 does not have to be far behind. > > Thanks for all of your reports so far. > > -Travis Oliphant > > > > _______________________________________________ > SciPy-user mailing list > SciPy-user at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-user From jdhunter at ace.bsd.uchicago.edu Mon Sep 22 11:21:54 2003 From: jdhunter at ace.bsd.uchicago.edu (John Hunter) Date: Mon, 22 Sep 2003 10:21:54 -0500 Subject: [SciPy-user] Newbie issues in moving to SciPy In-Reply-To: <000901c3808a$370e1da0$0201a8c0@laptop> ("Andy Main"'s message of "Sun, 21 Sep 2003 22:49:19 +0100") References: <000901c3808a$370e1da0$0201a8c0@laptop> Message-ID: >>>>> "Andy" == Andy Main writes: Andy> I really don't quite know where to start with Sci Python, Andy> I'm used to Matlab, and am really wondering how similar the Andy> programming is. I am basically wanting to output graphics Andy> using Chaco, should I be learning Python properly, or don't Andy> really have to as it is just a syntax difference to what I Andy> am used to? Any links to tutorials would be gratefully Andy> received. You may want to have a look at http://matplotlib.sourceforge.net, which is my python plotting library to do matlab compatible plotting in python (using Numeric). For example, the following is a python script using matplotlib from matplotlib.matlab import * t = arange(0.0, 2.0, 0.01) s = sin(2*pi*t) plot(t, s) xlabel('time (s)') ylabel('voltage (mV)') title('A simple plot') show() The arange line creates a Numeric array, which is like the matlab vector [0.0: 0.01: 2]. The other lines you should understand because you could write them in matlab. The Numeric MLab package has a fair number of matlab compatible functions which matplotlib provides and adds others from the matplotlib.mlab module. There is also a tutorial http://matplotlib.sourceforge.net/tutorial.html. In addition, read the scypy tutorials and Numeric manuals. Good luck, python is so much better at handling complex data structures than matlab that I'm sure you'll be pleased with the transition. John Hunter From pearu at scipy.org Mon Sep 22 12:11:05 2003 From: pearu at scipy.org (Pearu Peterson) Date: Mon, 22 Sep 2003 19:11:05 +0300 (EEST) Subject: [SciPy-user] SciPy 0.2 release In-Reply-To: <3F6F283D.3DFA78FF@mecha.uni-stuttgart.de> Message-ID: On Mon, 22 Sep 2003, Nils Wagner wrote: > It would be nice, if linalg.lu can be applied to complex matrices as > well Done in CVS. Pearu From pearu at scipy.org Sun Sep 21 06:18:50 2003 From: pearu at scipy.org (Pearu Peterson) Date: Sun, 21 Sep 2003 13:18:50 +0300 (EEST) Subject: [SciPy-user] scipy general_function segfault In-Reply-To: Message-ID: This is update on the general_function issue: 1) The issue was resolved by moving arraymap from cephes extension module to scipy_base. Now all scipy tests pass also with gcc-3.3.1. 2) `general_function` is now defined in scipy_base and has another name: `vectorize`. Pearu From pajer at iname.com Mon Sep 22 22:00:21 2003 From: pajer at iname.com (Gary Pajer) Date: Mon, 22 Sep 2003 22:00:21 -0400 Subject: [SciPy-user] Newbie issues in moving to SciPy References: <000901c3808a$370e1da0$0201a8c0@laptop> Message-ID: <003901c38176$726d36f0$01fd5644@playroom> Andy, I'm probably about two steps ahead of you. I think you had better learn at least a bit about "python properly". A fair bit of Numeric and scipy is structured into namespaces and objects, and while python itself works just fine with a basic set of commands, using scipy needs a little more. But not too terribly much more. Learn what you need as you go. There are a lot of differences w.r.t. Matlab. The one I find most irksome is the awkward way one adds an additional row or column to an array. Unless I'm missing something. The plotting facilities are still under construction: a few bugs and missing features, but quite servicable unless you want publication quality. (But there are solutions to that problem.) All things considered, scipy seems richer and *possibly* more featured than Matlab, but with a steeper learning curve. Here's a question for anyone that knows: there is a module scipy_base.index_tricks that contains constructs "c_" and "r_". The doc strings imply they have something to do with simplifiying adding rows and columns ... but I can't figure them out. Can anyone explain them to me? -gary ----- Original Message ----- From: "Andy Main" To: Sent: Sunday, September 21, 2003 5:49 PM Subject: [SciPy-user] Newbie issues in moving to SciPy > Hi, > > Sorry if I am repeating messages you always get, but hey nevermind! > > I really don't quite know where to start with Sci Python, I'm used to > Matlab, and am really wondering how similar the programming is. I am > basically wanting to output graphics using Chaco, should I be learning > Python properly, or don't really have to as it is just a syntax > difference to what I am used to? Any links to tutorials would be > gratefully received. > > Thanks > > Andy. > > _______________________________________________ > SciPy-user mailing list > SciPy-user at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-user From nwagner at mecha.uni-stuttgart.de Tue Sep 23 06:40:21 2003 From: nwagner at mecha.uni-stuttgart.de (Nils Wagner) Date: Tue, 23 Sep 2003 12:40:21 +0200 Subject: [SciPy-user] Reference to Scipy Message-ID: <3F702315.E3E8C7D2@mecha.uni-stuttgart.de> How can I reference scipy in a journal paper ? Nils From nwagner at mecha.uni-stuttgart.de Tue Sep 23 08:52:40 2003 From: nwagner at mecha.uni-stuttgart.de (Nils Wagner) Date: Tue, 23 Sep 2003 14:52:40 +0200 Subject: [SciPy-user] NameError: global name 'ogrid' is not defined Message-ID: <3F704218.D6A8178D@mecha.uni-stuttgart.de> Dear experts, Pleae can you fix this problem in the cvs tree. Traceback (most recent call last): File "pseudospectra.py", line 91, in ? P1 =2*(linalg.logm((gamma-rho)*identity(7)-A)-linalg.logm((gamma+rho)*identity(7)-A)) File "/usr/local/lib/python2.1/site-packages/scipy/linalg/matfuncs.py", line 215, in logm X,Y = ogrid[1:N+1,1:N+1] NameError: global name 'ogrid' is not defined Thanks in advance Nils From pearu at scipy.org Tue Sep 23 07:44:48 2003 From: pearu at scipy.org (Pearu Peterson) Date: Tue, 23 Sep 2003 06:44:48 -0500 (CDT) Subject: [SciPy-user] NameError: global name 'ogrid' is not defined In-Reply-To: <3F704218.D6A8178D@mecha.uni-stuttgart.de> Message-ID: On Tue, 23 Sep 2003, Nils Wagner wrote: > Pleae can you fix this problem in the cvs tree. > > "/usr/local/lib/python2.1/site-packages/scipy/linalg/matfuncs.py", line > 215, in logm > X,Y = ogrid[1:N+1,1:N+1] > NameError: global name 'ogrid' is not defined Fixed. Pearu From nwagner at mecha.uni-stuttgart.de Tue Sep 23 09:18:17 2003 From: nwagner at mecha.uni-stuttgart.de (Nils Wagner) Date: Tue, 23 Sep 2003 15:18:17 +0200 Subject: [SciPy-user] NameError: global name 'ogrid' is not defined References: Message-ID: <3F704817.6560651F@mecha.uni-stuttgart.de> Pearu Peterson schrieb: > > On Tue, 23 Sep 2003, Nils Wagner wrote: > > > Pleae can you fix this problem in the cvs tree. > > > > "/usr/local/lib/python2.1/site-packages/scipy/linalg/matfuncs.py", line > > 215, in logm > > X,Y = ogrid[1:N+1,1:N+1] > > NameError: global name 'ogrid' is not defined > > Fixed. > > Pearu > > _______________________________________________ > SciPy-user mailing list > SciPy-user at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-user There is another bug... Traceback (most recent call last): File "pseudospectra.py", line 91, in ? P1 =2*(linalg.logm((gamma-rho)*identity(7)-A)-linalg.logm((gamma+rho)*identity(7)-A)) File "/usr/local/lib/python2.1/site-packages/scipy/linalg/matfuncs.py", line 219, in logm if (norm(imag(F),1)<=1000*errtol*norm(F,1)): NameError: global name 'imag' is not defined Nils From pearu at scipy.org Tue Sep 23 08:10:58 2003 From: pearu at scipy.org (Pearu Peterson) Date: Tue, 23 Sep 2003 07:10:58 -0500 (CDT) Subject: [SciPy-user] NameError: global name 'ogrid' is not defined In-Reply-To: <3F704817.6560651F@mecha.uni-stuttgart.de> Message-ID: On Tue, 23 Sep 2003, Nils Wagner wrote: > There is another bug... > > Traceback (most recent call last): > File "pseudospectra.py", line 91, in ? > P1 > =2*(linalg.logm((gamma-rho)*identity(7)-A)-linalg.logm((gamma+rho)*identity(7)-A)) > File > "/usr/local/lib/python2.1/site-packages/scipy/linalg/matfuncs.py", line > 219, in logm > if (norm(imag(F),1)<=1000*errtol*norm(F,1)): > NameError: global name 'imag' is not defined Fixed. PS: an example of demonstrating a bug, or better yet, a patch would be most helpful for fixing such errors. Pearu From jeffrey.b.layton at lmco.com Tue Sep 23 09:55:33 2003 From: jeffrey.b.layton at lmco.com (Jeff Layton) Date: Tue, 23 Sep 2003 09:55:33 -0400 Subject: ScdiPy 0.2 release: was Re: [SciPy-user] Couple of Matrix() questions In-Reply-To: References: Message-ID: <3F7050D5.3010100@lmco.com> Pearu Peterson wrote: > > > On Sun, 31 Aug 2003, Gary Pajer wrote: > > > [...] > > > >>> E=hstack((vstack((A,C)),vstack((B,D)))) > > > > > > which is not an array type (maybe not a bad thing). However, I'd > still > > > like to avoid so much work (typing, watching my tuples, etc.) to just > > > do something so simple. Oh well, Roberts matcat function seems to > > > work just great. I just hate to have a function for each common > matrix > > > function when it could (or should) be part of the underlying class. > > > > I argree entirely, and I continue to search for the syntax that > makes it so. > > How about adding some new ?stack-type of methods to Matrix: > > E = A.vstack(C).hstack(B.vstack(D)) > > ? Suggestions for a better naming for such ?stack methods? > > Another idea: extend Matrix constructor to accept a list of matrix-like > objects so that stacking of matrices can be achived as follows: > > E = mat([[A,B],[C,D]]) > > where A,B,C,D are Matrix instances with appropiate shapes. > Could this be implemented for the 0.2 release? It doesn't seem too difficult (but then again I didn't volunteer to do it) :) Thanks! Jeff > Pearu > -- Dr. Jeff Layton Chart Monkey - Aerodynamics and CFD Lockheed-Martin Aeronautical Company - Marietta From nwagner at mecha.uni-stuttgart.de Tue Sep 23 12:02:56 2003 From: nwagner at mecha.uni-stuttgart.de (Nils Wagner) Date: Tue, 23 Sep 2003 18:02:56 +0200 Subject: ScdiPy 0.2 release: was Re: [SciPy-user] Couple of Matrix() questions References: <3F7050D5.3010100@lmco.com> Message-ID: <3F706EB0.B361235F@mecha.uni-stuttgart.de> Jeff Layton schrieb: > > Pearu Peterson wrote: > > > > > > > On Sun, 31 Aug 2003, Gary Pajer wrote: > > > > > [...] > > > > >>> E=hstack((vstack((A,C)),vstack((B,D)))) > > > > > > > > which is not an array type (maybe not a bad thing). However, I'd > > still > > > > like to avoid so much work (typing, watching my tuples, etc.) to just > > > > do something so simple. Oh well, Roberts matcat function seems to > > > > work just great. I just hate to have a function for each common > > matrix > > > > function when it could (or should) be part of the underlying class. > > > > > > I argree entirely, and I continue to search for the syntax that > > makes it so. > > > > How about adding some new ?stack-type of methods to Matrix: > > > > E = A.vstack(C).hstack(B.vstack(D)) > > > > ? Suggestions for a better naming for such ?stack methods? > > Afaik, it is the so-called vec operator. Nils > > Another idea: extend Matrix constructor to accept a list of matrix-like > > objects so that stacking of matrices can be achived as follows: > > > > E = mat([[A,B],[C,D]]) > > > > where A,B,C,D are Matrix instances with appropiate shapes. > > > > Could this be implemented for the 0.2 release? It doesn't seem too > difficult (but then again I didn't volunteer to do it) :) > > Thanks! > > Jeff > > > Pearu > > > > -- > Dr. Jeff Layton > Chart Monkey - Aerodynamics and CFD > Lockheed-Martin Aeronautical Company - Marietta > > _______________________________________________ > SciPy-user mailing list > SciPy-user at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-user From arnd.baecker at web.de Tue Sep 23 11:12:28 2003 From: arnd.baecker at web.de (Arnd Baecker) Date: Tue, 23 Sep 2003 17:12:28 +0200 (CEST) Subject: [SciPy-user] scipy general_function segfault In-Reply-To: References: Message-ID: On Sun, 21 Sep 2003, Pearu Peterson wrote: > This is update on the general_function issue: > 1) The issue was resolved by moving arraymap from cephes extension module > to scipy_base. Now all scipy tests pass also with gcc-3.3.1. Very good - hope it does not come up again ;-) > 2) `general_function` is now defined in scipy_base and has another > name: `vectorize`. Excellent - I think that this is a much more intuitive naming (I always wondered why it had that name and was hidden in scipy.special ;-) Many thanks, Arnd From jeffrey.b.layton at lmco.com Tue Sep 23 10:26:55 2003 From: jeffrey.b.layton at lmco.com (Jeff Layton) Date: Tue, 23 Sep 2003 10:26:55 -0400 Subject: SciPy 0.2 release: was Re: [SciPy-user] Couple of Matrix() questions In-Reply-To: <3F706EB0.B361235F@mecha.uni-stuttgart.de> References: <3F706EB0.B361235F@mecha.uni-stuttgart.de> Message-ID: <3F70582F.8050902@lmco.com> Nils Wagner wrote: > Jeff Layton schrieb: > > > > Pearu Peterson wrote: > > > > > > > > > > > On Sun, 31 Aug 2003, Gary Pajer wrote: > > > > > > > [...] > > > > > >>> E=hstack((vstack((A,C)),vstack((B,D)))) > > > > > > > > > > which is not an array type (maybe not a bad thing). However, I'd > > > still > > > > > like to avoid so much work (typing, watching my tuples, etc.) > to just > > > > > do something so simple. Oh well, Roberts matcat function seems to > > > > > work just great. I just hate to have a function for each common > > > matrix > > > > > function when it could (or should) be part of the underlying > class. > > > > > > > > I argree entirely, and I continue to search for the syntax that > > > makes it so. > > > > > > How about adding some new ?stack-type of methods to Matrix: > > > > > > E = A.vstack(C).hstack(B.vstack(D)) > > > > > > ? Suggestions for a better naming for such ?stack methods? > > > > > Afaik, it is the so-called vec operator. > Can you give an example? Thanks! > Nils > > > > Another idea: extend Matrix constructor to accept a list of > matrix-like > > > objects so that stacking of matrices can be achived as follows: > > > > > > E = mat([[A,B],[C,D]]) > > > > > > where A,B,C,D are Matrix instances with appropiate shapes. > > > > > > > Could this be implemented for the 0.2 release? It doesn't seem too > > difficult (but then again I didn't volunteer to do it) :) > > > > Thanks! > > > > Jeff > > > > > Pearu > > > > -- Dr. Jeff Layton Chart Monkey - Aerodynamics and CFD Lockheed-Martin Aeronautical Company - Marietta From arnd.baecker at web.de Tue Sep 23 11:17:40 2003 From: arnd.baecker at web.de (Arnd Baecker) Date: Tue, 23 Sep 2003 17:17:40 +0200 (CEST) Subject: [SciPy-user] Re: [SciPy-dev] SciPy 0.2 release In-Reply-To: <3F6C9B0A.6040805@ee.byu.edu> References: <3F6C9B0A.6040805@ee.byu.edu> Message-ID: Hi, I have the following points concerning the 0.2 release: - scipy website I don't know if you plan to announce 0.2 more widely. If so (and actually even indepent of this) I would be happy to see the website to be working properly. I encountered the following problems: - search works, but the resulting links fail - error messages when logging in as user - wiki ? - unittest gives the following two errors: ERROR: check_chebyc (test_basic.test_chebyc) ERROR: check_chebys (test_basic.test_chebys) (see below) - how crucial are the #E Means test is giving error (E) #F Means test is failing (F) #EF Means test is giving error and Failing #! Means test is segfaulting in scipy/special/tests/test_basic.py Does this mean that there are special functions which are know to give wrong results (but still a user could call these ?) - scipy.xplt (examples under 1.) below) - scipy.xplt.pause(1) crashes under windows, see xplt1.py - plot (and I think plg as well) behaves differently under linux and windows, see xplt2.py - it would be nice if one could a) change the size b) position the windows (at least under XWindows ?;-) with an optional geometry argument. (sorry, this is more of a wishlist feature ...) - a while ago I proposed a short textual addition to the doc-string for scipy.special concerning the errprint behaviour. Somehow it seems that it did not make its way into the CVS ( - actually I don't mind if someone tells me that the English is too bad for inclusion ... However if it is good enough I would be happy to see this included ;-). Full text on this: see 2.) below And: keep on the great work!! Many thanks, Arnd 1.) examples for scipy.xplt ######### xplt1.py import scipy.xplt import Numeric x=Numeric.arange(0.0,10.0,0.01) scipy.xplt.window(0) scipy.xplt.limits(0.0,10.0,0.0,1.0) # BTW: limits is ignored, when no # window(0) command is given before scipy.xplt.hold('on') for xval in x: yval = Numeric.sin(xval/ 4) scipy.xplt.plot(xval,yval, 'x') # under windows this line is the last scipy.xplt.pause(10) # ... which seems to be exectuded ################################## ######### xplt2.py import scipy.xplt from Numeric import * x1=array([0.0]) y1=array([1.0]) x2=array([0.5,0.5]) y2=array([1.0,1.00]) scipy.xplt.hold('on') scipy.xplt.window(0,wait=1) scipy.xplt.limits(-1.5,1.5,-1.5,1.5) # array1: not shown under linux but under windows scipy.xplt.plot(x1,y1, marker="x",msize=10,width=20) # array2: shown both under windows and linux scipy.xplt.plot(x2,y2, marker="x",msize=10,width=20) raw_input("") ################################## 2.) My e-mail from May: concerning errprint Hi, alright, here we go with a proposal for some text which I think would be good at the very end of what you get from scipy.info(scipy.special) """ Error handling: Some of the special function routines print an error message when for example an underflow occurs. To disable such messages use errprint(0). Example: print scipy.special.erf(100) scipy.special.errprint(0) print scipy.special.erf(100) """ Actually I think that the description of errprint (obtained with help(scipy.special.errprint)) """ errprint({flag}) sets or resets the error printing flag in cephesmodule returning the previous state. If no argument is given the current state of the flag is returned and no change occurs. """ might be easier to understand if replaced by """ errprint({flag}) sets the error printing flag for special functions (from the cephesmodule). The output is the previous state. With errprint(0) no error messages are shown; the default is errprint(1). If no argument is given the current state of the flag is returned and no change occurs. """ Hope this is of some use - More generally maybe the default behaviour (at least for scipy.special ?) should be changed to errprint(0) - but of course I have no idea about possible side effects ... 3.) The two errors when unit-testing ====================================================================== ERROR: check_chebyc (test_basic.test_chebyc) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/python/PYTHON/lib/python2.3/site-packages/scipy/special/tests/test_basic.py", line 214, in check_chebyc chebc = chebyc(1)(.2) File "/home/python/PYTHON/lib/python2.3/site-packages/scipy/special/orthogonal.py", line 398, in chebyc p = p * 2.0/p(2) File "/home/python/PYTHON/lib/python2.3/site-packages/scipy_base/polynomial.py", line 445, in __getattr__ raise KeyError KeyError ====================================================================== ERROR: check_chebys (test_basic.test_chebys) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/python/PYTHON/lib/python2.3/site-packages/scipy/special/tests/test_basic.py", line 220, in check_chebys chebs = chebys(1)(.2) File "/home/python/PYTHON/lib/python2.3/site-packages/scipy/special/orthogonal.py", line 429, in chebys p = p * (n+1.0)/p(2) File "/home/python/PYTHON/lib/python2.3/site-packages/scipy_base/polynomial.py", line 445, in __getattr__ raise KeyError KeyError From oliphant at ee.byu.edu Tue Sep 23 12:04:39 2003 From: oliphant at ee.byu.edu (Travis E. Oliphant) Date: Tue, 23 Sep 2003 10:04:39 -0600 Subject: [SciPy-user] Newbie issues in moving to SciPy In-Reply-To: <003901c38176$726d36f0$01fd5644@playroom> References: <000901c3808a$370e1da0$0201a8c0@laptop> <003901c38176$726d36f0$01fd5644@playroom> Message-ID: <3F706F17.4070905@ee.byu.edu> Gary Pajer wrote: > Andy, > > I'm probably about two steps ahead of you. I think you had better learn at > least a bit about "python properly". A fair bit of Numeric and scipy is > structured into namespaces and objects, and while python itself works just > fine with a basic set of commands, using scipy needs a little more. But not > too terribly much more. Learn what you need as you go. > > There are a lot of differences w.r.t. Matlab. The one I find most irksome > is the awkward way one adds an additional row or column to an array. Unless > I'm missing something. The plotting facilities are still under > construction: a few bugs and missing features, but quite servicable unless > you want publication quality. (But there are solutions to that problem.) > All things considered, scipy seems richer and *possibly* more featured than > Matlab, but with a steeper learning curve. > I disagree with lack of publication quality. You can get publication quality now with xplt. Others use add on tools to get quality output. For example I've heard that grace has a nice interface with Python. Regarding r_ and c_ These are tools for constructing arrays quickly. They essentially wrap the concatentator. Their primary use is to simplify construction of 1-d and 2-d arrays. r_ stands for row concatenation and c_ stands for column concatenation. Of course in 1-d it doesn't matter which you use. Examples: >>> a = r_[1:10]; print a [1 2 3 4 5 6 7 8 9] >>> a = r_[0:10:0.5]; print a # sample spacing of 0.5 [ 0. 0.5 1. 1.5 2. 2.5 3. 3.5 4. 4.5 5. 5.5 6. 6.5 7. 7.5 8. 8.5 9. 9.5] >>> a = r_[0:10:20j]; print a # 20j => generate 20 samples [ 0. 0.5263 1.0526 1.5789 2.1053 2.6316 3.1579 3.6842 4.2105 4.7368 5.2632 5.7895 6.3158 6.8421 7.3684 7.8947 8.4211 8.9474 9.4737 10. ] You can also combine lists >>> a = r_[0:10, 1.0, 3.0, 5:10:10j]; print a [ 0. 1. 2. 3. 4. 5. 6. 7. 8. 9. 1. 3. 5. 5.5556 6.1111 6.6667 7.2222 7.7778 8.3333 8.8889 9.4444 10. ] When called with multiple "indexes" r_ concatentates the rows of the arguments. For 1-d arrays as in this example it just creates a 1-d array. For 2-d arrays you get the effect of stacking the arguments on top of each other. >>> C = r_[A,B] produces the equivalent of MATLAB's C = [A; B] (note that A and B must be 2-d for this to work as you want) The column equivalent is c_[] So, >>> C = c_[A,B] produces the equivalent of C = [A, B] in MATLAB To construct a matrix from blocks F = [ A B ] [ C D ] use >>> F = c_[r_[A,C],r_[A,D]] or >>> F = r_[c_[A,B],c_[C,D]] A = [[1,2]] B = [[3,4,5]] C = [[6,7],[8,9],[10,11]] D = [[12,13,14],[15,16,17],[18,19,20]] F = r_[c_[A,B],c_[C,D]] print F results in [[ 1 2 3 4 5] [ 6 7 12 13 14] [ 8 9 15 16 17] [10 11 18 19 20]] I would not be opposed to adding a version that interprets a string using MATLAB syntax so that r_['A B; C D'] did the same thing. -Travis O. From oliphant at ee.byu.edu Tue Sep 23 12:30:02 2003 From: oliphant at ee.byu.edu (Travis E. Oliphant) Date: Tue, 23 Sep 2003 10:30:02 -0600 Subject: [SciPy-user] Re: [SciPy-dev] SciPy 0.2 release In-Reply-To: References: <3F6C9B0A.6040805@ee.byu.edu> Message-ID: <3F70750A.4000602@ee.byu.edu> Arnd Baecker wrote: > Hi, > > I have the following points concerning the 0.2 release: > > > - unittest gives the following two errors: > ERROR: check_chebyc (test_basic.test_chebyc) > ERROR: check_chebys (test_basic.test_chebys) > (see below) These were due to Python 2.3 changes in how coercion is handled and should be fixed in current CVS (I don't get these errors). > > - how crucial are the > #E Means test is giving error (E) > #F Means test is failing (F) > #EF Means test is giving error and Failing > #! Means test is segfaulting > > in scipy/special/tests/test_basic.py > > Does this mean that there are special functions > which are know to give wrong results > (but still a user could call these ?) > Don't know what this means? There is always the potential for error but we are using fairly well tested libraries. > > - scipy.xplt (examples under 1.) below) > - scipy.xplt.pause(1) crashes under windows, see xplt1.py > - plot (and I think plg as well) > behaves differently under linux and windows, see xplt2.py > - it would be nice if one could > a) change the size > b) position > the windows (at least under XWindows ?;-) with > an optional geometry argument. > (sorry, this is more of a wishlist feature ...) > You can change these (see xplt.figure and xplt.subplot) We may have to disable the pausing on windows --- I was not aware of this problem, Thank you. > - a while ago I proposed a short textual addition > to the doc-string for scipy.special concerning > the errprint behaviour. > Somehow it seems that it did not make > its way into the CVS ( - actually I don't mind if > someone tells me that the English is too bad > for inclusion ... However if it is good enough > I would be happy to see this included ;-). > Full text on this: see 2.) below > > It must have just slipped through the cracks. It's a good suggestion, and I've changed it now. > And: keep on the great work!! Many thanks, > > Arnd > > > > > > > 1.) examples for scipy.xplt > > ######### xplt1.py > import scipy.xplt > import Numeric > > x=Numeric.arange(0.0,10.0,0.01) > scipy.xplt.window(0) > scipy.xplt.limits(0.0,10.0,0.0,1.0) # BTW: limits is ignored, when no > # window(0) command is given before That's because limits are supposed to be called AFTER you produce a plot ;-) > scipy.xplt.hold('on') > for xval in x: > yval = Numeric.sin(xval/ 4) > scipy.xplt.plot(xval,yval, 'x') # under windows this line is the > last > scipy.xplt.pause(10) # ... which seems to be exectuded > ################################## Thanks for the bug report. > > ######### xplt2.py > import scipy.xplt > from Numeric import * > > > x1=array([0.0]) > y1=array([1.0]) > > > x2=array([0.5,0.5]) > y2=array([1.0,1.00]) > > scipy.xplt.hold('on') > scipy.xplt.window(0,wait=1) > scipy.xplt.limits(-1.5,1.5,-1.5,1.5) > > # array1: not shown under linux but under windows > scipy.xplt.plot(x1,y1, marker="x",msize=10,width=20) > # array2: shown both under windows and linux > scipy.xplt.plot(x2,y2, marker="x",msize=10,width=20) > > raw_input("") > ################################## > I'm not sure what you are saying here? > > 2.) My e-mail from May: concerning errprint > > Hi, > > alright, here we go with a proposal for some text > which I think would be good at the very end of what you get from > scipy.info(scipy.special) > > """ > Error handling: > > Some of the special function routines print an error message > when for example an underflow occurs. > To disable such messages use errprint(0). > > Example: > print scipy.special.erf(100) > scipy.special.errprint(0) > print scipy.special.erf(100) > > """ > Added. > > Actually I think that the description of errprint > (obtained with help(scipy.special.errprint)) > """ errprint({flag}) sets or resets the error printing flag in > cephesmodule > returning the previous state. If no argument is given the current > state of > the flag is returned and no change occurs. > """ > might be easier to understand if replaced by > """ errprint({flag}) sets the error printing flag for special functions > (from the cephesmodule). The output is the previous state. > With errprint(0) no error messages are shown; > the default is errprint(1). > If no argument is given the current state of > the flag is returned and no change occurs. > """ > Added. > Hope this is of some use - > More generally maybe the default behaviour > (at least for scipy.special ?) should be changed > to errprint(0) - but of course Changed default to off. > I have no idea about possible side effects ... Should have no side effects. Thanks for your help, -Travis O. From pajer at iname.com Tue Sep 23 13:54:30 2003 From: pajer at iname.com (Gary Pajer) Date: Tue, 23 Sep 2003 13:54:30 -0400 Subject: [SciPy-user] Newbie issues in moving to SciPy References: <000901c3808a$370e1da0$0201a8c0@laptop><003901c38176$726d36f0$01fd5644@playroom> <3F706F17.4070905@ee.byu.edu> Message-ID: <002f01c381fb$bd3f4300$01fd5644@playroom> [snip] > > I'm missing something. The plotting facilities are still under > > construction: a few bugs and missing features, but quite servicable unless > > you want publication quality. (But there are solutions to that problem.) > > All things considered, scipy seems richer and *possibly* more featured than > > Matlab, but with a steeper learning curve. > > > > I disagree with lack of publication quality. You can get publication > quality now with xplt. Others use add on tools to get quality output. > For example I've heard that grace has a nice interface with Python. > check. I usually use WinXP, so have no experience with xplt, and I've not heard of grace. I'll check it out. I've been having good success with disipyl, a front end to DISLIN. Tricky to get going, but the results are great. > > Regarding r_ and c_ > > These are tools for constructing arrays quickly. They essentially wrap > the concatentator. Perfect (almost)!! Thanks for the pointer. [snip] > > >>> C = r_[A,B] > > produces the equivalent of MATLAB's C = [A; B] (note that A and B must > be 2-d for this to work as you want) > That's a minor inconvenience. Is there a shortcut way to convert a 1-d array to a row or column array other than reshape(a, (n,1)) ?? Can array() be told to produce a 2-d column or row [(n,1) or (1,n)] ? [snip] > > I would not be opposed to adding a version that interprets a string > using MATLAB syntax so that > > r_['A B; C D'] I wouldn't stop you, nor would I encourage you. the c_ and r_ constructions are fine. From oliphant at ee.byu.edu Tue Sep 23 14:31:49 2003 From: oliphant at ee.byu.edu (Travis E. Oliphant) Date: Tue, 23 Sep 2003 12:31:49 -0600 Subject: [SciPy-user] New bmat constructor in SciPy Message-ID: <3F709195.2090509@ee.byu.edu> One of SciPy's goals is to ease transition to Python for Matlab users. In that light r_[] and c_[] were added some time ago (but perhaps not well documented) As I mentioned before F = r_[c_[A,B],c_[C,D]] would construct F = [A B] [C D] now, a new function has been added that does the same thing, but also creates a matrix object. bmat (short for build matrix) bmat([[A,B],[C,D]]) = bmat('A,B; C,D') = bmat(r_[c_[A,B],c_[C,D]]) This returns a Matrix object (* is matrix multiplication for this guy) constructed from the blocks A, B, C and D. Of course these blocks must have the right shapes or an error will be generated. Incidentally, r_['A,B;C,D'] does the same thing. I hope this helps. -Travis O. From wagner.nils at vdi.de Tue Sep 23 14:50:18 2003 From: wagner.nils at vdi.de (Nils Wagner) Date: Tue, 23 Sep 2003 20:50:18 +0200 Subject: [SciPy-user] New bmat constructor in SciPy In-Reply-To: <3F709195.2090509@ee.byu.edu> Message-ID: <20030923185036.CEAA63EADE@www.scipy.com> ------------------- One of SciPy's goals is to ease transition to Python for Matlab users. In this context it would be nice to have a tool to remove rows and columns of a matrix In Matlab: > > a=rand(4,4) a = 0.9501 0.8913 0.8214 0.9218 0.2311 0.7621 0.4447 0.7382 0.6068 0.4565 0.6154 0.1763 0.4860 0.0185 0.7919 0.4057 use > > a(:,2)=[] a = 0.9501 0.8214 0.9218 0.2311 0.4447 0.7382 0.6068 0.6154 0.1763 0.4860 0.7919 0.4057 > > a(2,:)=[] a = 0.9501 0.8214 0.9218 0.6068 0.6154 0.1763 0.4860 0.7919 0.4057 Nils In that light r_[] and c_[] were added some time ago (but perhaps not well documented) As I mentioned before F = r_[c_[A,B],c_[C,D]] would construct F = [A B] [C D] now, a new function has been added that does the same thing, but also creates a matrix object. bmat (short for build matrix) bmat([[A,B],[C,D]]) = bmat('A,B; C,D') = bmat(r_[c_[A,B],c_[C,D]]) This returns a Matrix object (* is matrix multiplication for this guy) constructed from the blocks A, B, C and D. Of course these blocks must have the right shapes or an error will be generated. Incidentally, r_['A,B;C,D'] does the same thing. I hope this helps. -Travis O. _______________________________________________ SciPy-user mailing list SciPy-user at scipy.net http://www.scipy.net/mailman/listinfo/scipy-user From pearu at scipy.org Tue Sep 23 15:09:56 2003 From: pearu at scipy.org (Pearu Peterson) Date: Tue, 23 Sep 2003 14:09:56 -0500 (CDT) Subject: [SciPy-user] New bmat constructor in SciPy In-Reply-To: <20030923185036.CEAA63EADE@www.scipy.com> Message-ID: On Tue, 23 Sep 2003, Nils Wagner wrote: > In this context it would be nice to have a tool to remove > rows and columns of a matrix > In Matlab: > > > > a=rand(4,4) > > a = > > 0.9501 0.8913 0.8214 0.9218 > 0.2311 0.7621 0.4447 0.7382 > 0.6068 0.4565 0.6154 0.1763 > 0.4860 0.0185 0.7919 0.4057 > > use > > > > a(:,2)=[] I wonder if in Python >>> del a[:,2] would be possible. Currently Numeric raises ValueError, numarray raises TypeError and m=mat(a); del a[:,2] gives AttributeError: __delitem__ not found. Pearu From perry at stsci.edu Tue Sep 23 15:16:33 2003 From: perry at stsci.edu (Perry Greenfield) Date: Tue, 23 Sep 2003 15:16:33 -0400 Subject: [SciPy-user] New bmat constructor in SciPy In-Reply-To: Message-ID: > On Tue, 23 Sep 2003, Nils Wagner wrote: > > > In this context it would be nice to have a tool to remove > > rows and columns of a matrix > > In Matlab: > > > > > > a=rand(4,4) > > > > a = > > > > 0.9501 0.8913 0.8214 0.9218 > > 0.2311 0.7621 0.4447 0.7382 > > 0.6068 0.4565 0.6154 0.1763 > > 0.4860 0.0185 0.7919 0.4057 > > > > use > > > > > > a(:,2)=[] > > I wonder if in Python > > >>> del a[:,2] > > would be possible. Currently Numeric raises ValueError, numarray raises > TypeError and > m=mat(a); del a[:,2] > gives AttributeError: __delitem__ not found. > > Pearu I've given this a tiny bit of thought. In principle there isn't any reason why numeric arrays couldn't be resizable (or a subclass), where they would have behavior similar to Python lists in this regard; space is overallocated for arrays and so rows and columns may be added or deleted. If there isn't enough space a new larger buffer is created and the data copied, and if it shrinks a lot, a smaller buffer is created and the larger released. But I don't think it is something we have the resources (or need) to tackle in the near term. Perry From arnd.baecker at web.de Tue Sep 23 17:40:45 2003 From: arnd.baecker at web.de (Arnd Baecker) Date: Tue, 23 Sep 2003 23:40:45 +0200 (CEST) Subject: [SciPy-user] Re: [SciPy-dev] SciPy 0.2 release In-Reply-To: <3F70750A.4000602@ee.byu.edu> References: <3F6C9B0A.6040805@ee.byu.edu> <3F70750A.4000602@ee.byu.edu> Message-ID: Hi , On Tue, 23 Sep 2003, Travis E. Oliphant wrote: > > - how crucial are the > > #E Means test is giving error (E) > > #F Means test is failing (F) > > #EF Means test is giving error and Failing > > #! Means test is segfaulting > > > > in scipy/special/tests/test_basic.py > > > > Does this mean that there are special functions > > which are know to give wrong results > > (but still a user could call these ?) > > Don't know what this means? Maybe not ;-) > There is always the potential for error but > we are using fairly well tested libraries. Indeed - ages ago I had a look at the cephes doc and they seem to have good accuracy bounds for their functions. That's why I was a bit surprised to see that some unit tests fail. (Of course, from a finite number of test-values one can never be sure that the function is computed correctly everywhere). More concrete: I just had a look at the unit-test for the airy function (test_airy). The test fails (at least on my machine) because for x = airy(.41) the last digit of the 4th output (ie Bip) does not match: from scipy.special import * airy(0.41)[3] 0.51053919338077658 # comparison-value in the unit-test is: 0.51053920 Here at home I just have octave to compare with and there I get: octave:8> airy(3,0.41)-0.5105391933 ans = 8.0777e-11 And even better, if you want: octave:11> airy(3,0.41)-0.5105391933807765 ans = 1.1102e-16 So the octave result matches perfectly with the output of the scipy airy. Now it could be that octave is wrong about this value (as it could use cephes internally as well), so I will double check with maple/mathematica etc. tomorrow. Now to this one: > > ######### xplt2.py > > import scipy.xplt > > from Numeric import * > > > > > > x1=array([0.0]) > > y1=array([1.0]) > > > > > > x2=array([0.5,0.5]) > > y2=array([1.0,1.00]) > > > > scipy.xplt.hold('on') > > scipy.xplt.window(0,wait=1) > > scipy.xplt.limits(-1.5,1.5,-1.5,1.5) > > > > # array1: not shown under linux but under windows > > scipy.xplt.plot(x1,y1, marker="x",msize=10,width=20) > > # array2: shown both under windows and linux > > scipy.xplt.plot(x2,y2, marker="x",msize=10,width=20) > > > > raw_input("") > > ################################## > > > > I'm not sure what you are saying here? Sorry, let me try to be a bit more verbose: The above example illustrates that xplt.plot behaves differently under windows and linux. Namely, an array of length 1 (x1,y1) is shown under windows, but not under linux whereas the array (x2,y2) of length 2 is shown. So under linux: one point is visible and under windows one sees two (as it should, I think). Hope this is clearer ... Arnd From pajer at iname.com Sun Sep 21 10:01:44 2003 From: pajer at iname.com (Gary Pajer) Date: Sun, 21 Sep 2003 10:01:44 -0400 Subject: [SciPy-user] issue for 0.2: python2.3 float deprecation warnings ??? Message-ID: <200309211001.44775.pajer@iname.com> I'm sure you're on to this issue, but I can't find much mention of it: E.g.:, with python2.3 *only* >>from scipy import plt >>plt.plot((1., 2., 3.)) /usr/local/lib/python2.3/site-packages/wxPython/gdi.py:283: DeprecationWarning: integer argument expected, got float self.this = gdic.new_wxColour(*_args,**_kwargs) /usr/local/lib/python2.3/site-packages/wxPython/gdi.py:570: DeprecationWarning: integer argument expected, got float val = gdic.wxDC_DrawRotatedText(self, *_args, **_kwargs) /usr/local/lib/python2.3/site-packages/wxPython/gdi.py:702: DeprecationWarning: integer argument expected, got float val = gdic.wxDC_SetClippingRegion(self, *_args, **_kwargs) these warnings have something to do with a change made in python in going to v. 2.3. I can't tell if the problem is with scipy or wxPython. I checked the wxPython bug tracker and mailing list archive, and it's mentioned there with the advice to clean up one's source code. -Gary From bob at redivi.com Tue Sep 23 22:16:37 2003 From: bob at redivi.com (Bob Ippolito) Date: Tue, 23 Sep 2003 22:16:37 -0400 Subject: [SciPy-user] issue for 0.2: python2.3 float deprecation warnings ??? In-Reply-To: <200309211001.44775.pajer@iname.com> Message-ID: <202A9ED2-EE35-11D7-A788-000A95686CD8@redivi.com> On Sunday, Sep 21, 2003, at 10:01 America/New_York, Gary Pajer wrote: > I'm sure you're on to this issue, but I can't find much mention of it: > > E.g.:, with python2.3 *only* > >>> from scipy import plt >>> plt.plot((1., 2., 3.)) > > /usr/local/lib/python2.3/site-packages/wxPython/gdi.py:283: > DeprecationWarning: integer argument expected, got float > self.this = gdic.new_wxColour(*_args,**_kwargs) > /usr/local/lib/python2.3/site-packages/wxPython/gdi.py:570: > DeprecationWarning: integer argument expected, got float > val = gdic.wxDC_DrawRotatedText(self, *_args, **_kwargs) > /usr/local/lib/python2.3/site-packages/wxPython/gdi.py:702: > DeprecationWarning: integer argument expected, got float > val = gdic.wxDC_SetClippingRegion(self, *_args, **_kwargs) > > these warnings have something to do with a change made in python in > going to > v. 2.3. I can't tell if the problem is with scipy or wxPython. I > checked > the wxPython bug tracker and mailing list archive, and it's mentioned > there > with the advice to clean up one's source code. I think the issue is that anything that loses precision automatically is being deprecated in Python, for example: >>> 1 / 2 0 >>> from __future__ import division >>> 1 / 2 0.5 >>> 0xFFFFFFFF -1 >>> 0xFFFFFFFF # probably Python 2.4, I don't think there's a __future__ for this though 4294967295L I think the float -> int warning is coming from (at the C API level of the extensions you're using) PyArg_ParseTuple(PyObject *args, char *format, ...) where the format has an "i" in it but the corresponding element of the tuple is a Python float. I don't think there's a way around it, other than making sure your arguments are integers or changing all of your C APIs to take C doubles (format string "d") and floor/bounds check them yourself. I think that either way is unfortunate, because it's inconvenient and doing either will probably make your code run slower and use more memory. Maybe they should add format characters for the old behavior? I guess it's not terribly significant given the overhead of calling functions, though. -bob From pajer at iname.com Tue Sep 23 23:29:03 2003 From: pajer at iname.com (Gary Pajer) Date: Tue, 23 Sep 2003 23:29:03 -0400 Subject: [SciPy-user] issue for 0.2: python2.3 float deprecation warnings ??? (aplology for multiple posts) References: <200309211001.44775.pajer@iname.com> Message-ID: <001501c3824c$012911e0$01fd5644@playroom> > I'm sure you're on to this issue, but I can't find much mention of it: > Sorry about the multiple posts on this!!!! There have been long delays before my posts appear. I think it's related to sporadic power outages around here. -g From pajer at iname.com Tue Sep 23 23:42:05 2003 From: pajer at iname.com (Gary Pajer) Date: Tue, 23 Sep 2003 23:42:05 -0400 Subject: [SciPy-user] issue for 0.2: python2.3 float deprecationwarnings ??? References: <202A9ED2-EE35-11D7-A788-000A95686CD8@redivi.com> Message-ID: <001b01c3824d$d3021e90$01fd5644@playroom> From: "Bob Ippolito" To: Sent: Tuesday, September 23, 2003 10:16 PM Subject: Re: [SciPy-user] issue for 0.2: python2.3 float deprecationwarnings ??? > > On Sunday, Sep 21, 2003, at 10:01 America/New_York, Gary Pajer wrote: > > > I'm sure you're on to this issue, but I can't find much mention of it: > > > > E.g.:, with python2.3 *only* > > > >>> from scipy import plt > >>> plt.plot((1., 2., 3.)) > > > > /usr/local/lib/python2.3/site-packages/wxPython/gdi.py:283: > > DeprecationWarning: integer argument expected, got float [snip] > I think the float -> int warning is coming from (at the C API level of > the extensions you're using) PyArg_ParseTuple(PyObject *args, char > *format, ...) where the format has an "i" in it but the corresponding > element of the tuple is a Python float. I don't think there's a way > around it, other than making sure your arguments are integers or > changing all of your C APIs to take C doubles (format string "d") and > floor/bounds check them yourself. > I'm out of my league here, but I can report that the wxPython people have also identified PyArg_ParseTuple() as the culprit. They discuss it here: http://lists.wxwindows.org/archive/wxPython-users/msg20822.html which I reproduce at the end of this message in case anyone finds it useful. > I think that either way is unfortunate, because it's inconvenient and > doing either will probably make your code run slower and use more > memory. Maybe they should add format characters for the old behavior? > I guess it's not terribly significant given the overhead of calling > functions, though. ---------------------------------------------------------------- ---------------------------------------------------------------- > From: Robin Dunn > > Anthony Tuininga wrote: > > The Python development team has decided (and I think with good reason) > > that if you are calling PyArg_ParseTuple() and specifying that you are > > expecting an integer, then you really ought to be passing an integer > > through from your Python code. > > > > So there are two options, and I'm not sure which one makes the most > > sense. > > > > 1) modify the wxPython C extension to specify that it allows floating > > point, not integer > > To do that would mean that even if you do pass integers that > PyArg_ParseTuple would convert it to a float and then it would then get > truncated back to an integer to be passed to the API. > > > 2) modify your code so that you don't pass floats to routines expecting > > integers > > > > I suspect the latter is what is needed but I'll let someone with better > > knowledge answer that question. > > Yep. For all of you updating your code, just remember that round() returns a float, so if you want to round your var use int(round(yourVar)) and if you just want to truncate use int(yourVar). Seems obvious enough, but it is an easy place to make a mistake. If you want the same results as you got prior to Python 2.3 you probably just want int(yourVar) for truncation if I understand what wxPython has been doing with the argument lists. ka From nwagner at mecha.uni-stuttgart.de Wed Sep 24 06:37:54 2003 From: nwagner at mecha.uni-stuttgart.de (Nils Wagner) Date: Wed, 24 Sep 2003 12:37:54 +0200 Subject: [SciPy-user] Matrix sign function Message-ID: <3F717402.E7F7D102@mecha.uni-stuttgart.de> Dear experts, It would be nice to have the matrix sign function in scipy. Nils Reference: Spectral decomposition of a matrix using the generalized sign matrix, Applied Mathematics and Computation, Vol.8 (1981) pp. 237-250 From pearu at scipy.org Wed Sep 24 05:39:05 2003 From: pearu at scipy.org (Pearu Peterson) Date: Wed, 24 Sep 2003 04:39:05 -0500 (CDT) Subject: [SciPy-user] Matrix sign function In-Reply-To: <3F717402.E7F7D102@mecha.uni-stuttgart.de> Message-ID: On Wed, 24 Sep 2003, Nils Wagner wrote: > It would be nice to have the matrix sign function in scipy. Try the following: signm=lambda a:linalg.funm(a,lambda v:sign(v)+0j) This assumes that `a` has real eigenvalues. Otherwise one most use some other sign function that is properly defined for complex values, the current sign is acctually v |-> sign(real(v)) Pearu From nwagner at mecha.uni-stuttgart.de Wed Sep 24 07:40:19 2003 From: nwagner at mecha.uni-stuttgart.de (Nils Wagner) Date: Wed, 24 Sep 2003 13:40:19 +0200 Subject: [SciPy-user] Matrix sign function References: Message-ID: <3F7182A3.3ADA6C18@mecha.uni-stuttgart.de> Pearu Peterson schrieb: > > On Wed, 24 Sep 2003, Nils Wagner wrote: > > > It would be nice to have the matrix sign function in scipy. > > Try the following: > > signm=lambda a:linalg.funm(a,lambda v:sign(v)+0j) > > This assumes that `a` has real eigenvalues. Otherwise one most use some > other sign function that is properly defined for complex values, the > current sign is acctually > v |-> sign(real(v)) > > Pearu > To account for complex values, a generalized sign matrix can be defined as follows sign(v) = \left\{ \begin{array}{c} 1 \Re v > 0 \\ 0 \Re v = 0 \\ -1 \Re v < 0 \end{array}\right. Details are given in the reference (previous e-mail). Anyway, I think scipy should have a generalized sign function as well. A suitable test case is the following matrix array([[ 29.2, -24.2, 69.5, 49.8, 7. ], [ -9.2, 5.2, -18. , -16.8, -2. ], [-10. , 6. , -20. , -18. , -2. ], [ -9.6, 9.6, -25.5, -15.4, -2. ], [ 9.8, -4.8, 18. , 18.2, 2. ]]) Any suggestion for the implementation of a generalized matrix sign function ? BTW, Davies and Higham have published an interesting paper on matrix functions. They have improved Matlab's function funm. Davies, P.~I., Higham, N.~J. A Schur-Parlett algorithm for computing matrix functions, SIAM Journal Matrix Analysis and Applications, Vol. 25 No.2 pp. 464-485 Nils > _______________________________________________ > SciPy-user mailing list > SciPy-user at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-user From pearu at scipy.org Wed Sep 24 06:44:07 2003 From: pearu at scipy.org (Pearu Peterson) Date: Wed, 24 Sep 2003 05:44:07 -0500 (CDT) Subject: [SciPy-user] Matrix sign function In-Reply-To: <3F7182A3.3ADA6C18@mecha.uni-stuttgart.de> Message-ID: On Wed, 24 Sep 2003, Nils Wagner wrote: > Pearu Peterson schrieb: > > > > On Wed, 24 Sep 2003, Nils Wagner wrote: > > > > > It would be nice to have the matrix sign function in scipy. > > > > Try the following: > > > > signm=lambda a:linalg.funm(a,lambda v:sign(v)+0j) > > > > This assumes that `a` has real eigenvalues. Otherwise one most use some > > other sign function that is properly defined for complex values, the > > current sign is acctually > > v |-> sign(real(v)) > > To account for complex values, a generalized sign matrix can be defined > as follows > > sign(v) = \left\{ \begin{array}{c} 1 \Re v > 0 \\ 0 \Re v = 0 \\ -1 \Re > v < 0 \end{array}\right. So, this is exactly Numeric.sign that was used above. > Details are given in the reference (previous e-mail). At the moment, I don't have access to given references, could you send their pdf files off the list to me: pearu at cens.ioc.ee > Anyway, I think scipy should have a generalized sign function as well. > > A suitable test case is the following matrix > > array([[ 29.2, -24.2, 69.5, 49.8, 7. ], > [ -9.2, 5.2, -18. , -16.8, -2. ], > [-10. , 6. , -20. , -18. , -2. ], > [ -9.6, 9.6, -25.5, -15.4, -2. ], > [ 9.8, -4.8, 18. , 18.2, 2. ]]) What would be the correct result for signm()? signm gives: >>> signm(a) array([[ 20.728, -6.576, 29.592, 32.88 , -6.576], [ -5.808, 2.936, -8.712, -9.68 , 1.936], [ -6.24 , 2.08 , -8.36 , -10.4 , 2.08 ], [ -7.344, 2.448, -11.016, -11.24 , 2.448], [ 6.192, -2.064, 9.288, 10.32 , -1.064]]) Is this correct? > Any suggestion for the implementation of a generalized matrix sign > function ? See above. Pearu From arnd.baecker at web.de Wed Sep 24 06:56:45 2003 From: arnd.baecker at web.de (Arnd Baecker) Date: Wed, 24 Sep 2003 12:56:45 +0200 (CEST) Subject: [SciPy-user] Newbie issues in moving to SciPy In-Reply-To: <002f01c381fb$bd3f4300$01fd5644@playroom> References: <000901c3808a$370e1da0$0201a8c0@laptop><003901c38176$726d36f0$01fd5644@playroom> <002f01c381fb$bd3f4300$01fd5644@playroom> Message-ID: Hi Gary, On Tue, 23 Sep 2003, Gary Pajer wrote: [...] > I usually use WinXP, so have no experience with xplt, scipy.xplt should work under WinXP as well, or am I wrong ? > and I've not > heard of grace. I'll check it out. See: http://plasma-gate.weizmann.ac.il/Grace/ http://www-heller.harvard.edu/~mhagger/download/python/grace_np.py Another alternative is gnuplot, http://www.gnuplot.info/ and the python wrapping from http://gnuplot-py.sourceforge.net/ (+Fernando's ipython, which is a must anyway, IMHO). Note that gnuplot requires some time to get used to it. > I've been having good success with > disipyl, a front end to DISLIN. Tricky to get going, but the results are > great. However it is not really free (I have been beaten by things like that in the past ...) Arnd From nwagner at mecha.uni-stuttgart.de Wed Sep 24 08:20:14 2003 From: nwagner at mecha.uni-stuttgart.de (Nils Wagner) Date: Wed, 24 Sep 2003 14:20:14 +0200 Subject: [SciPy-user] Matrix sign function References: Message-ID: <3F718BFD.3698547C@mecha.uni-stuttgart.de> Pearu Peterson schrieb: > > On Wed, 24 Sep 2003, Nils Wagner wrote: > > > Pearu Peterson schrieb: > > > > > > On Wed, 24 Sep 2003, Nils Wagner wrote: > > > > > > > It would be nice to have the matrix sign function in scipy. > > > > > > Try the following: > > > > > > signm=lambda a:linalg.funm(a,lambda v:sign(v)+0j) > > > > > > This assumes that `a` has real eigenvalues. Otherwise one most use some > > > other sign function that is properly defined for complex values, the > > > current sign is acctually > > > v |-> sign(real(v)) > > > > To account for complex values, a generalized sign matrix can be defined > > as follows > > > > sign(v) = \left\{ \begin{array}{c} 1 \Re v > 0 \\ 0 \Re v = 0 \\ -1 \Re > > v < 0 \end{array}\right. > > So, this is exactly Numeric.sign that was used above. > > > Details are given in the reference (previous e-mail). > > At the moment, I don't have access to given references, could you send > their pdf files off the list to me: pearu at cens.ioc.ee > You will find the papers of Higham at http://www.ma.man.ac.uk/~higham/ > > Anyway, I think scipy should have a generalized sign function as well. > > > > A suitable test case is the following matrix > > > > array([[ 29.2, -24.2, 69.5, 49.8, 7. ], > > [ -9.2, 5.2, -18. , -16.8, -2. ], > > [-10. , 6. , -20. , -18. , -2. ], > > [ -9.6, 9.6, -25.5, -15.4, -2. ], > > [ 9.8, -4.8, 18. , 18.2, 2. ]]) > > What would be the correct result for signm()? > signm gives: > > >>> signm(a) > array([[ 20.728, -6.576, 29.592, 32.88 , -6.576], > [ -5.808, 2.936, -8.712, -9.68 , 1.936], > [ -6.24 , 2.08 , -8.36 , -10.4 , 2.08 ], > [ -7.344, 2.448, -11.016, -11.24 , 2.448], > [ 6.192, -2.064, 9.288, 10.32 , -1.064]]) > > Is this correct? > The result of the generalized sign algorithm is array([[ 11.94933333, -2.24533333, 15.31733333, 21.65333333, -2.24533333], [ -3.84266667, 0.49866667, -4.59066667, -7.18666667, 0.49866667], [ -4.08 , 0.56 , -4.92 , -7.6 , 0.56 ], [ -4.03466667, 1.04266667, -5.59866667, -7.02666667, 1.04266667], [ 4.15733333, -0.50133333, 4.90933333, 7.81333333, -0.50133333]]) Nils > > Any suggestion for the implementation of a generalized matrix sign > > function ? > > See above. > > Pearu > > _______________________________________________ > SciPy-user mailing list > SciPy-user at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-user From pearu at scipy.org Wed Sep 24 07:31:57 2003 From: pearu at scipy.org (Pearu Peterson) Date: Wed, 24 Sep 2003 06:31:57 -0500 (CDT) Subject: [SciPy-user] Matrix sign function In-Reply-To: <3F718BFD.3698547C@mecha.uni-stuttgart.de> Message-ID: On Wed, 24 Sep 2003, Nils Wagner wrote: > > > Anyway, I think scipy should have a generalized sign function as well. > > > > > > A suitable test case is the following matrix > > > > > > array([[ 29.2, -24.2, 69.5, 49.8, 7. ], > > > [ -9.2, 5.2, -18. , -16.8, -2. ], > > > [-10. , 6. , -20. , -18. , -2. ], > > > [ -9.6, 9.6, -25.5, -15.4, -2. ], > > > [ 9.8, -4.8, 18. , 18.2, 2. ]]) > > > > What would be the correct result for signm()? > > signm gives: > > > > >>> signm(a) > > array([[ 20.728, -6.576, 29.592, 32.88 , -6.576], > > [ -5.808, 2.936, -8.712, -9.68 , 1.936], > > [ -6.24 , 2.08 , -8.36 , -10.4 , 2.08 ], > > [ -7.344, 2.448, -11.016, -11.24 , 2.448], > > [ 6.192, -2.064, 9.288, 10.32 , -1.064]]) > > > > Is this correct? > > > The result of the generalized sign algorithm is > > array([[ 11.94933333, -2.24533333, 15.31733333, 21.65333333, > -2.24533333], > [ -3.84266667, 0.49866667, -4.59066667, -7.18666667, > 0.49866667], > [ -4.08 , 0.56 , -4.92 , -7.6 , > 0.56 ], > [ -4.03466667, 1.04266667, -5.59866667, -7.02666667, > 1.04266667], > [ 4.15733333, -0.50133333, 4.90933333, 7.81333333, > -0.50133333]]) The results were different due to roundoff errors. Note that sign function is very sensitive to that. So, here is an improved signm that gives the above result: >>> signm=lambda a:linalg.funm(a,lambda v:sign(around(real(v),12))+0j) >>> signm(a) array([[ 11.94933333, -2.24533333, 15.31733333, 21.65333333, -2.24533333], [ -3.84266667, 0.49866667, -4.59066667, -7.18666667, 0.49866667], [ -4.08 , 0.56 , -4.92 , -7.6 , 0.56 ], [ -4.03466667, 1.04266667, -5.59866667, -7.02666667, 1.04266667], [ 4.15733333, -0.50133333, 4.90933333, 7.81333333, -0.50133333]]) Pearu From pearu at scipy.org Wed Sep 24 07:35:29 2003 From: pearu at scipy.org (Pearu Peterson) Date: Wed, 24 Sep 2003 06:35:29 -0500 (CDT) Subject: [SciPy-user] Matrix sign function In-Reply-To: Message-ID: On Wed, 24 Sep 2003, Pearu Peterson wrote: > The results were different due to roundoff errors. Note that sign > function is very sensitive to that. I mean, the sign function is sensitive to roundoff errors when there are eigenvalues close to zero as was the case in your example. Pearu From nwagner at mecha.uni-stuttgart.de Wed Sep 24 09:02:38 2003 From: nwagner at mecha.uni-stuttgart.de (Nils Wagner) Date: Wed, 24 Sep 2003 15:02:38 +0200 Subject: [SciPy-user] Matrix sign function References: Message-ID: <3F7195EE.4D0A86BE@mecha.uni-stuttgart.de> Pearu Peterson schrieb: > > On Wed, 24 Sep 2003, Pearu Peterson wrote: > > > The results were different due to roundoff errors. Note that sign > > function is very sensitive to that. > > I mean, the sign function is sensitive to roundoff errors when there are > eigenvalues close to zero as was the case in your example. > > Pearu > Thank you for that. After all, is it possible to put signm into the cvs tree of scipy ? Nils > ______ _________________________________________ > SciPy-user mailing list > SciPy-user at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-user From arnd.baecker at web.de Wed Sep 24 08:09:30 2003 From: arnd.baecker at web.de (Arnd Baecker) Date: Wed, 24 Sep 2003 14:09:30 +0200 (CEST) Subject: [SciPy-user] Re: [SciPy-dev] SciPy 0.2 release In-Reply-To: <3F70750A.4000602@ee.byu.edu> References: <3F6C9B0A.6040805@ee.byu.edu> <3F70750A.4000602@ee.byu.edu> Message-ID: On Tue, 23 Sep 2003, Travis E. Oliphant wrote: [...] > > - unittest gives the following two errors: > > ERROR: check_chebyc (test_basic.test_chebyc) > > ERROR: check_chebys (test_basic.test_chebys) > > (see below) > > These were due to Python 2.3 changes in how coercion is handled and > should be fixed in current CVS (I don't get these errors). Sorry, I haven't updated my scipy-install since last Friday ;-). Yes it is fixed. Many thanks! > > - scipy.xplt (examples under 1.) below) > > - it would be nice if one could > > a) change the size > > b) position > > the windows (at least under XWindows ?;-) with > > an optional geometry argument. > > (sorry, this is more of a wishlist feature ...) > > You can change these (see xplt.figure and xplt.subplot) Well, I managed to get the aspect ratio changed, whereas the vertical size of the window stays the same. E.g: ########## from scipy import * x=r_[0.0,1.0,0.01] y=sin(x) xplt.figure(n=0,aspect=0.85) xplt.plot(x,y) xplt.figure(n=1,aspect=1.5,color=1) xplt.plot(x,y) ######## However I did not find out how to change the vertical size. Also I did not succeed in finding a way to specifiy the position of one figure on my desktop. e.g. like the geometry specification in Xresources: -geometry WIDTHxHEIGHT+XOFF+YOFF (where WIDTH, HEIGHT, XOFF, and YOFF are numbers) for specifying a preferred size and location for this application's window. (from `man X` ) Is there a way to do this with scipy.xplt ? for x = airy(.41) the last digit of the 4th output (ie Bip) does not match: from scipy.special import * airy(0.41)[3] 0.51053919338077658 # comparison-value in the unit-test is: 0.51053920 Here at home I just have octave to compare with and there I get: octave:8> airy(3,0.41)-0.5105391933 ans = 8.0777e-11 And even better, if you want: octave:11> airy(3,0.41)-0.5105391933807765 ans = 1.1102e-16 So the octave result matches perfectly with the output of the scipy airy. Now it could be that octave is wrong about this value (as it could use cephes internally as well), so I will double check with maple/mathematica etc. tomorrow. On the airy function unit-test in scipy/special/tests/test_basic.py: We had: from scipy.special import * airy(0.41)[3] 0.51053919338077658 # comparison-value in the unit-test is: 0.51053920 octave:11> airy(3,0.41)-0.5105391933807765 ans = 1.1102e-16 Now I had a look at Maple 8, which gives: > AiryBi(1,0.41); 0.5105391934 Thus I tend to think that the comparison-value in the unit-test should be changed from 0.51053920 to 0.51053919 However a change in a comparison value for a unit-test should not be done in a hurry - so maybe someone else can confirm the numbers (eg. with mathematica etc. ?) Finally I think it is worth to remark that according to airy.c the accuracy is around 2.3e-14 and better for the tested ranges. Would it therefore (in principle) be reasonable to set up unit-tests going beyond 8 digits ? Anyway, I don't think that any of the above is of particular importance for 0.2 (sorry ;-). Arnd From prabhu at aero.iitm.ernet.in Wed Sep 24 08:19:30 2003 From: prabhu at aero.iitm.ernet.in (Prabhu Ramachandran) Date: Wed, 24 Sep 2003 17:49:30 +0530 Subject: [SciPy-user] Newbie issues in moving to SciPy In-Reply-To: References: <000901c3808a$370e1da0$0201a8c0@laptop> <003901c38176$726d36f0$01fd5644@playroom> <002f01c381fb$bd3f4300$01fd5644@playroom> Message-ID: <16241.35794.119020.491473@monster.linux.in> >>>>> "AB" == Arnd Baecker writes: AB> Hi Gary, On Tue, 23 Sep 2003, Gary Pajer wrote: AB> [...] >> I usually use WinXP, so have no experience with xplt, AB> scipy.xplt should work under WinXP as well, or am I wrong ? >> and I've not heard of grace. I'll check it out. AB> See: http://plasma-gate.weizmann.ac.il/Grace/ AB> http://www-heller.harvard.edu/~mhagger/download/python/grace_np.py Grace is X11 only. You might also want to check out these: http://www.idyll.org/~n8gray/code/ Look for gracePlot.py, I've been using that quite a bit. You might also like this: http://graceplot.sourceforge.net/ cheers, prabhu From karthik at james.hut.fi Wed Sep 24 08:21:36 2003 From: karthik at james.hut.fi (Karthikesh Raju) Date: Wed, 24 Sep 2003 15:21:36 +0300 Subject: [SciPy-user] Pdf's/ppt files of the Scipy '03 Presentations Message-ID: Hi, Somewhere deep down, there was a discussion about making the presentation files online, so that people who could not attend SciPy 03 could benefit. i am (kind of) checking the page every now and then, there seems to be no link to these presentation. Dear Organizers, is it possible for us to download the same, may be as one big zip file. With warm regards karthik ----------------------------------------------------------------------- Karthikesh Raju, email: karthik at james.hut.fi Researcher, http://www.cis.hut.fi/karthik Helsinki University of Technology, Tel: +358-9-451 5389 Laboratory of Comp. & Info. Sc., Fax: +358-9-451 3277 Department of Computer Sc., P.O Box 5400, FIN 02015 HUT, Espoo, FINLAND ----------------------------------------------------------------------- From arnd.baecker at web.de Wed Sep 24 08:31:40 2003 From: arnd.baecker at web.de (Arnd Baecker) Date: Wed, 24 Sep 2003 14:31:40 +0200 (CEST) Subject: [SciPy-user] Newbie issues in moving to SciPy In-Reply-To: <3F706F17.4070905@ee.byu.edu> References: <000901c3808a$370e1da0$0201a8c0@laptop> <003901c38176$726d36f0$01fd5644@playroom> <3F706F17.4070905@ee.byu.edu> Message-ID: On Tue, 23 Sep 2003, Travis E. Oliphant wrote: [... nice description of r_ and c_ snipped ...] Travis, why not just add your mail as doc-string to r_ and c_ - I think this is an excellent description, in particular as it contains clear examples (and made me aware of this really nice set of routines !!) If you want I (or maybe Gary) could do some polishing before if necessary? Arnd From gpajer at rider.edu Wed Sep 24 08:54:42 2003 From: gpajer at rider.edu (Gary Pajer) Date: Wed, 24 Sep 2003 08:54:42 -0400 Subject: [SciPy-user] Newbie issues in moving to SciPy In-Reply-To: Message-ID: <43C727EF-EE8E-11D7-B428-000393A41AAE@rider.edu> On Wednesday, September 24, 2003, at 06:56 AM, Arnd Baecker wrote: > Hi Gary, > [...] > >> I've been having good success with >> disipyl, a front end to DISLIN. Tricky to get going, but the results >> are >> great. > > However it is not really free (I have been beaten by things like > that in the past ...) > > Arnd > Thanks for your suggestions. Many of them are new to me. DISLIN: alas, I think you are correct. I looked far enough to determine that the Windows / python version is free, at least for personal use. I'm no lawyer, so I don't know how general the free license is. Certain other platforms are not free. From gpajer at rider.edu Wed Sep 24 08:58:55 2003 From: gpajer at rider.edu (Gary Pajer) Date: Wed, 24 Sep 2003 08:58:55 -0400 Subject: [SciPy-user] Newbie issues in moving to SciPy In-Reply-To: Message-ID: On Wednesday, September 24, 2003, at 08:31 AM, Arnd Baecker wrote: > On Tue, 23 Sep 2003, Travis E. Oliphant wrote: > > [... nice description of r_ and c_ snipped ...] > > Travis, why not just add your mail as doc-string > to r_ and c_ - I think this is an excellent description, > in particular as it contains clear examples > (and made me aware of this really nice set of routines !!) > If you want I (or maybe Gary) could do some polishing before > if necessary? Yes, I could. If you can stand to wait a couple of days. I'll send you something unless I hear otherwise. -Gary From arnd.baecker at web.de Wed Sep 24 09:43:00 2003 From: arnd.baecker at web.de (Arnd Baecker) Date: Wed, 24 Sep 2003 15:43:00 +0200 (CEST) Subject: [SciPy-user] Newbie issues in moving to SciPy In-Reply-To: <43C727EF-EE8E-11D7-B428-000393A41AAE@rider.edu> References: <43C727EF-EE8E-11D7-B428-000393A41AAE@rider.edu> Message-ID: On Wed, 24 Sep 2003, Gary Pajer wrote: > Thanks for your suggestions. Many of them are new to me. I forgot: you can find more at http://starship.python.net/crew/jhauser/plot-res.html http://www.python.org/topics/scicomp/plotting.html (the first is a bit outdated by now, but still....) > DISLIN: > alas, I think you are correct. I looked far enough to determine that > the Windows / python version is free, at least for personal use. I'm > no lawyer, so I don't know how general the free license is. Certain > other platforms are not free. Sorry, I was not precise enough: what I meant is that the source is not available. And if for some reason the DISLIN project is not continued or the "free to download and run" version are withdrawn one has the problem of many scripts which cannot be used anymore (well, it will work as long as your DISLIN installation works ... ;-). Arnd From pearu at scipy.org Wed Sep 24 10:13:10 2003 From: pearu at scipy.org (Pearu Peterson) Date: Wed, 24 Sep 2003 09:13:10 -0500 (CDT) Subject: [SciPy-user] Matrix sign function In-Reply-To: <3F7195EE.4D0A86BE@mecha.uni-stuttgart.de> Message-ID: On Wed, 24 Sep 2003, Nils Wagner wrote: > After all, is it possible to put signm into the cvs tree of scipy ? An improved signm is now in scipy cvs repository. Pearu From nwagner at mecha.uni-stuttgart.de Wed Sep 24 11:52:28 2003 From: nwagner at mecha.uni-stuttgart.de (Nils Wagner) Date: Wed, 24 Sep 2003 17:52:28 +0200 Subject: [SciPy-user] Kronecker product kron(a,b) Message-ID: <3F71BDBC.45C9BFFF@mecha.uni-stuttgart.de> Dear experts, There is another useful function which might be interesting for scipy, the so-called Kronecker product of two matrices. def kron(a,b): 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) It would be great, if this becomes a standard function in scipy. Any comments ? Nils From oliphant at ee.byu.edu Wed Sep 24 11:11:12 2003 From: oliphant at ee.byu.edu (Travis E. Oliphant) Date: Wed, 24 Sep 2003 09:11:12 -0600 Subject: [SciPy-user] Newbie issues in moving to SciPy In-Reply-To: References: <000901c3808a$370e1da0$0201a8c0@laptop><003901c38176$726d36f0$01fd5644@playroom> <002f01c381fb$bd3f4300$01fd5644@playroom> Message-ID: <3F71B410.5010508@ee.byu.edu> Arnd Baecker wrote: > Hi Gary, > > On Tue, 23 Sep 2003, Gary Pajer wrote: > > [...] > >>I usually use WinXP, so have no experience with xplt, > > > scipy.xplt should work under WinXP as well, or am I wrong ? You are right. It should work there as well. -Travis O. From fperez at colorado.edu Wed Sep 24 12:18:47 2003 From: fperez at colorado.edu (Fernando Perez) Date: Wed, 24 Sep 2003 10:18:47 -0600 Subject: [SciPy-user] Newbie issues in moving to SciPy In-Reply-To: <16241.35794.119020.491473@monster.linux.in> References: <000901c3808a$370e1da0$0201a8c0@laptop> <003901c38176$726d36f0$01fd5644@playroom> <002f01c381fb$bd3f4300$01fd5644@playroom> <16241.35794.119020.491473@monster.linux.in> Message-ID: <3F71C3E7.8040801@colorado.edu> Prabhu Ramachandran wrote: > >> and I've not heard of grace. I'll check it out. > AB> See: http://plasma-gate.weizmann.ac.il/Grace/ > AB> http://www-heller.harvard.edu/~mhagger/download/python/grace_np.py > > Grace is X11 only. You might also want to check out these: Sure? From the website: Grace is a WYSIWYG 2D plotting tool for the X Window System and M*tif. Grace runs on practically any version of Unix-like OS. As well, it has been successfully ported to VMS, OS/2, and Win9*/NT/2000/XP (some minor functionality may be missing, though). Granted, I've only used it under X11, and I don't know if 'ported to WinXXX' means ported to run with an X server there. But perhaps Win users can double check exactly how that works. Cheers, f. From turner at lanl.gov Wed Sep 24 12:32:57 2003 From: turner at lanl.gov (John A. Turner) Date: Wed, 24 Sep 2003 10:32:57 -0600 Subject: [SciPy-user] Newbie issues in moving to SciPy In-Reply-To: <3F71C3E7.8040801@colorado.edu> References: <000901c3808a$370e1da0$0201a8c0@laptop> <003901c38176$726d36f0$01fd5644@playroom> <002f01c381fb$bd3f4300$01fd5644@playroom> <16241.35794.119020.491473@monster.linux.in> <3F71C3E7.8040801@colorado.edu> Message-ID: <3F71C739.8040306@lanl.gov> Fernando Perez wrote: > Granted, I've only used it under X11, and I don't know if 'ported to > WinXXX' means ported to run with an X server there. But perhaps Win > users can double check exactly how that works. yes, it does require an X server on win32 the good news is that both Grace and XFree86 are now bundled with Cygwin ("Cygwin - don't leave Unix without it", http://cygwin.com/) even though XFree86 is certainly usable on win32, I must say I'm partial to the non-free X server X-Win32 (http://www.starnet.com/) -John A. Turner Los Alamos National Laboratory Continuum Dynamics Group (CCS-2) From wagner.nils at vdi.de Wed Sep 24 14:16:17 2003 From: wagner.nils at vdi.de (Nils Wagner) Date: Wed, 24 Sep 2003 20:16:17 +0200 Subject: [SciPy-user] Problems with linalg.logm In-Reply-To: Message-ID: <20030924181640.09AB93EA06@www.scipy.com> Dear experts, I tried to do something with linalg.logm I have enclosed the program. Result may be inaccurate, approximate err = 1.32516030853e-09 Traceback (most recent call last): File "logm-test.py", line 36, in ? P1 = P1 + (linalg.logm(z1*identity(7)-A)-linalg.logm(z0*identity(7)-A))/(2*pi*sqrt(-1.)) File "/usr/lib/python2.2/site-packages/scipy/linalg/matfuncs.py", line 225, in logm F -= temp.T File "/usr/lib/python2.2/site-packages/Numeric/UserArray.py", line 58, in __isub__ subtract(self.array, other, self.array) TypeError: return array has incorrect type What is the reason for that ? Nils from scipy import * A = zeros((7,7),Float) A[0,0] = -2.0 A[0,1] = 25.0 A[1,1] = -3.0 A[1,2] = 10.0 A[1,3] = 3.0 A[1,4] = 3.0 A[1,5] = 3.0 A[2,2] = 2.0 A[2,3] = 15.0 A[2,4] = 3.0 A[2,5] = 3.0 A[3,4] = 15.0 A[3,5] = 3.0 A[4,4] = 3.0 A[4,5] = 10.0 A[5,5] = -2.0 A[5,6] = 25.0 A[6,6] = -3.0 nm = 4 # # Center of the circle # gamma = 1.5 # # Radius of the circle # rho = 1.6 # P1 = zeros((7,7),Complex) # for i in arange(0,nm-1): z0 = gamma+rho*exp(2.*pi*i*sqrt(-1.)/nm) z1 = gamma+rho*exp(2.*pi*(i+1)*sqrt(-1.)/nm) P1 = P1 + (linalg.logm(z1*identity(7)-A)-linalg.logm(z0*identity(7)-A))/(2*pi*sqrt(-1.)) C=dot(P1,P1)-P1 print trace(C) print P1 From oliphant at ee.byu.edu Wed Sep 24 14:42:05 2003 From: oliphant at ee.byu.edu (Travis E. Oliphant) Date: Wed, 24 Sep 2003 12:42:05 -0600 Subject: [SciPy-user] Newbie issues in moving to SciPy In-Reply-To: References: <000901c3808a$370e1da0$0201a8c0@laptop> <003901c38176$726d36f0$01fd5644@playroom> <3F706F17.4070905@ee.byu.edu> Message-ID: <3F71E57D.1080208@ee.byu.edu> Arnd Baecker wrote: > On Tue, 23 Sep 2003, Travis E. Oliphant wrote: > > [... nice description of r_ and c_ snipped ...] > > Travis, why not just add your mail as doc-string > to r_ and c_ - I think this is an excellent description, > in particular as it contains clear examples > (and made me aware of this really nice set of routines !!) > If you want I (or maybe Gary) could do some polishing before > if necessary? Polish it up and that would be great. -travis From pearu at scipy.org Wed Sep 24 15:42:48 2003 From: pearu at scipy.org (Pearu Peterson) Date: Wed, 24 Sep 2003 14:42:48 -0500 (CDT) Subject: [SciPy-user] Problems with linalg.logm In-Reply-To: <20030924181640.09AB93EA06@www.scipy.com> Message-ID: On Wed, 24 Sep 2003, Nils Wagner wrote: > I tried to do something with linalg.logm > I have enclosed the program. > > Result may be inaccurate, approximate err = 1.32516030853e-09 > Traceback (most recent call last): > File "logm-test.py", line 36, in ? > P1 = P1 + > (linalg.logm(z1*identity(7)-A)-linalg.logm(z0*identity(7)-A))/(2*pi*sqrt(-1.)) > File "/usr/lib/python2.2/site-packages/scipy/linalg/matfuncs.py", line 225, in > logm > F -= temp.T > File "/usr/lib/python2.2/site-packages/Numeric/UserArray.py", line 58, in > __isub__ > subtract(self.array, other, self.array) > TypeError: return array has incorrect type > > What is the reason for that ? The problem was in logm code where F was changed from complex to real matrix but temp was complex, this triggered the error when subtracting real matrix with complex matrix in situ. Hmm, so in situ operations cannot change the objects type. Anyway, the issue is resolved in CVS. Pearu From wagner.nils at vdi.de Wed Sep 24 16:53:43 2003 From: wagner.nils at vdi.de (Nils Wagner) Date: Wed, 24 Sep 2003 22:53:43 +0200 Subject: [SciPy-user] Matrix sign function Message-ID: <20030924205405.D172A3EA06@www.scipy.com> Pearu, I have used linalg.signm with a defective matrix. The results do not fulfill the properties of a certain projector. Please find enclosed my test program. Any comments or suggestions for a further improvement of signm ? Nils -------------- next part -------------- A non-text attachment was scrubbed... Name: denman.py Type: application/octet-stream Size: 1633 bytes Desc: not available URL: From eric at enthought.com Thu Sep 25 01:56:45 2003 From: eric at enthought.com (eric jones) Date: Wed, 24 Sep 2003 23:56:45 -0600 Subject: [SciPy-user] Pdf's/ppt files of the Scipy '03 Presentations In-Reply-To: References: Message-ID: <3F72839D.8070306@enthought.com> Hey Karthik, We hope to do it soon. I'm not sure where we are in gathering up all the presentations yet. So, for those of you who presented at SciPy'03 and haven't sent in your slides, please send them to travis at enthought.com. (Notice how I descreetly pawned it off on someone else...) eric Karthikesh Raju wrote: >Hi, > >Somewhere deep down, there was a discussion about making the presentation >files online, so that people who could not attend SciPy 03 could benefit. >i am (kind of) checking the page every now and then, there seems to be no >link to these presentation. Dear Organizers, is it possible for us to >download the same, may be as one big zip file. > >With warm regards > >karthik > > >----------------------------------------------------------------------- >Karthikesh Raju, email: karthik at james.hut.fi >Researcher, http://www.cis.hut.fi/karthik >Helsinki University of Technology, Tel: +358-9-451 5389 >Laboratory of Comp. & Info. Sc., Fax: +358-9-451 3277 >Department of Computer Sc., >P.O Box 5400, FIN 02015 HUT, >Espoo, FINLAND >----------------------------------------------------------------------- > >_______________________________________________ >SciPy-user mailing list >SciPy-user at scipy.net >http://www.scipy.net/mailman/listinfo/scipy-user > > From pearu at scipy.org Thu Sep 25 06:00:33 2003 From: pearu at scipy.org (Pearu Peterson) Date: Thu, 25 Sep 2003 05:00:33 -0500 (CDT) Subject: [SciPy-user] Matrix sign function In-Reply-To: <20030924205405.D172A3EA06@www.scipy.com> Message-ID: On Wed, 24 Sep 2003, Nils Wagner wrote: > I have used linalg.signm with a defective matrix. The current algorithm in linalg.funm is not suitable for defective matrices. Btw, both Matlab and Octave funm functions have the same problem. See for instance the corresponding thread in Octave mailing list: http://www.octave.org/octave-lists/archive/bug-octave.2001/msg00063.html > The results do not fulfill the properties of a certain projector. > Please find enclosed my test program. > Any comments or suggestions for a further improvement of signm ? Higham in his Matlab Matrix Computation Toolbox uses similar algorithm to linalg.funm (with certain steps changed for stability) so that I doubt that it would resolve the problem for defective matrices (correct me if I am wrong). But using iterative method (from the references you gave), please test the following signm function with your matrices: #--------------- feps = linalg.matfuncs.feps eps = linalg.matfuncs.eps _array_precision = linalg.matfuncs._array_precision norm = linalg.norm def signm3(a): """matrix sign""" def rounded_sign(x): rx = real(x) mx = amax(absolute(x)) # XXX: amax segfaults on complex input if rx.typecode()=='f': c = 1e3*feps*mx else: c = 1e3*eps*mx return sign( (absolute(rx) > c) * rx ) result,err = funm(a, rounded_sign, disp=0) tol = {0:feps, 1:eps}[_array_precision[result.typecode()]] if err < 1000*tol: return result S0 = result + 0.5*identity(result.shape[0])/norm(result,1) for i in range(20): iS0 = linalg.inv(S0) alpha = beta = 0.5 S0 = alpha*S0 + beta*iS0 Pp=0.5*(dot(S0,S0)+S0) eps1 = norm(dot(Pp,Pp)-Pp) if eps1 < 1e3*tol: break return S0 #-------------- Pearu From Kasper.Souren at ircam.fr Thu Sep 25 10:58:42 2003 From: Kasper.Souren at ircam.fr (Kasper Souren) Date: Thu, 25 Sep 2003 16:58:42 +0200 Subject: [SciPy-user] filter design problem Message-ID: <200309251658.43019.Kasper.Souren@ircam.fr> Hi, It's me doing something wrong, or there is a bug in the signal package. My scipy_version is 0.2.0_alpha_196.4128. I'm trying to create a Butterworth bandpass filter, but somehow the resulting filter is always lowpass. I.e. the plot of the freqz is always 1 at the 0 frequency. Here is some code: from scipy.signal import buttord, butter, freqz n,Wn=buttord([0.4, 0.6], [0.2, 0.7], 3, 45) b,a=butter(n,Wn) gplt.plot(abs(freqz(b,a,1000)[1])) bye, Kasper -- We are not the consumers of the media, we are the product. -Kevin Danaher From wagner.nils at vdi.de Thu Sep 25 13:45:48 2003 From: wagner.nils at vdi.de (Nils Wagner) Date: Thu, 25 Sep 2003 19:45:48 +0200 Subject: [SciPy-user] Matrix sign function In-Reply-To: Message-ID: <20030925174615.2E5463EA06@www.scipy.com> ------------------- On Wed, 24 Sep 2003, Nils Wagner wrote: > I have used linalg.signm with a defective matrix. The current algorithm in linalg.funm is not suitable for defective matrices. Btw, both Matlab and Octave funm functions have the same problem. See for instance the corresponding thread in Octave mailing list: http://www.octave.org/octave-lists/archive/bug-octave.2001/msg00063.html So, Scipy has the chance to be better than other tools. > > The results do not fulfill the properties of a certain projector. > Please find enclosed my test program. > Any comments or suggestions for a further improvement of signm ? Higham in his Matlab Matrix Computation Toolbox uses similar algorithm to linalg.funm (with certain steps changed for stability) so that I doubt that it would resolve the problem for defective matrices (correct me if I am wrong). But using iterative method (from the references you gave), please test the following signm function with your matrices: Thank you very much for your modified signm function. I have used your signm function with the defective matrix. It works fine ! However, this a not a proof in general. Nils #--------------- feps = linalg.matfuncs.feps eps = linalg.matfuncs.eps _array_precision = linalg.matfuncs._array_precision norm = linalg.norm def signm3(a): """matrix sign""" def rounded_sign(x): rx = real(x) mx = amax(absolute(x)) # XXX: amax segfaults on complex input if rx.typecode()=='f': c = 1e3*feps*mx else: c = 1e3*eps*mx return sign( (absolute(rx) > c) * rx ) result,err = funm(a, rounded_sign, disp=0) tol = {0:feps, 1:eps}[_array_precision[result.typecode()]] if err < 1000*tol: return result S0 = result + 0.5*identity(result.shape[0])/norm(result,1) for i in range(20): iS0 = linalg.inv(S0) alpha = beta = 0.5 S0 = alpha*S0 + beta*iS0 Pp=0.5*(dot(S0,S0)+S0) eps1 = norm(dot(Pp,Pp)-Pp) if eps1 < 1e3*tol: break return S0 #-------------- Pearu _______________________________________________ SciPy-user mailing list SciPy-user at scipy.net http://www.scipy.net/mailman/listinfo/scipy-user From wagner.nils at vdi.de Thu Sep 25 13:57:10 2003 From: wagner.nils at vdi.de (Nils Wagner) Date: Thu, 25 Sep 2003 19:57:10 +0200 Subject: [SciPy-user] Drazin inverse In-Reply-To: Message-ID: <20030925175737.837443EA1D@www.scipy.com> Dear experts, The Drazin inverse of a matrix A \in C^{n \times n} is defined by A^D = (A+A^\pi)^{-1} (I-A^\pi) where A^\pi is the eigenprojection of A corresponding to 0. If A is nonsingular, then A^\pi = 0 and A^D = A^{-1}. It would be great if this inverse will become available in scipy. Any suggestion or comments ? Nils From oliphant at ee.byu.edu Thu Sep 25 14:50:36 2003 From: oliphant at ee.byu.edu (Travis Oliphant) Date: Thu, 25 Sep 2003 12:50:36 -0600 Subject: [SciPy-user] Scheduled release Message-ID: <3F7338FC.2070703@ee.byu.edu> The release of scipy is coming along, but I think we need to postpone the release until Tuesday as I have found some bugs in special that need addressing. Comments? -Travis Oliphant From fperez at colorado.edu Thu Sep 25 15:02:54 2003 From: fperez at colorado.edu (Fernando Perez) Date: Thu, 25 Sep 2003 13:02:54 -0600 Subject: [SciPy-user] Scheduled release In-Reply-To: <3F7338FC.2070703@ee.byu.edu> References: <3F7338FC.2070703@ee.byu.edu> Message-ID: <3F733BDE.60302@colorado.edu> Travis Oliphant wrote: > The release of scipy is coming along, but I think we need to postpone > the release until Tuesday as I have found some bugs in special that need > addressing. > > Comments? By all means fix them :) One small thing: I've seen some strange warning messages using weave.inline() under python 2.3, for code which works 100% cleanly if run it again with 2.2. I mentioned this to Eric, but unfortunately I don't have a _small_ example to test with. It might be nice to at least test inline() against 2.3, in particular using type_converters=converters.blitz. My warnings look typically like: In file included from /usr/local/include/python2.3/Python.h:8, from /home/fperez/.python23_compiled/sc_4108fdf932cdf49195bce6c017cbda992.cpp:4: /usr/local/include/python2.3/pyconfig.h:844:1: warning: "_POSIX_C_SOURCE" redefined In file included from /usr/include/c++/3.2.2/i386-redhat-linux/bits/os_defines.h:39, from /usr/include/c++/3.2.2/i386-redhat-linux/bits/c++config.h:34, from /usr/include/c++/3.2.2/string:45, from /usr/local/lib/python2.3/site-packages/weave/blitz-20001213/blitz/blitz.h:153, from /usr/local/lib/python2.3/site-packages/weave/blitz-20001213/blitz/array-impl.h:154, from /usr/local/lib/python2.3/site-packages/weave/blitz-20001213/blitz/array.h:94, from /home/fperez/.python23_compiled/sc_4108fdf932cdf49195bce6c017cbda992.cpp:3: /usr/include/features.h:131:1: warning: this is the location of the previous definition Ultimately if you can't see any problems, I can mail you off-list my stuff and you can try to see if it helps. It's not 'small', but the problems appear when running the test suite, so it wouldn't be too much of a hassle. Note that as far as I've seen, the code _works_ under 2.3, it just spews out a ton of warnings which I don't see with 2.2. Best, f. From pajer at iname.com Thu Sep 25 17:44:50 2003 From: pajer at iname.com (Gary Pajer) Date: Thu, 25 Sep 2003 17:44:50 -0400 Subject: [SciPy-user] Scheduled release References: <3F7338FC.2070703@ee.byu.edu> Message-ID: <002501c383ae$3fbffa00$01fd5644@playroom> > > The release of scipy is coming along, but I think we need to postpone > the release until Tuesday as I have found some bugs in special that need > addressing. > > Comments? > > -Travis Oliphant Is cvs keeping up with you so we can shoot darts at it? -Gary From pearu at scipy.org Thu Sep 25 18:16:07 2003 From: pearu at scipy.org (Pearu Peterson) Date: Thu, 25 Sep 2003 17:16:07 -0500 (CDT) Subject: [SciPy-user] Re: [SciPy-dev] Scheduled release In-Reply-To: <3F7338FC.2070703@ee.byu.edu> Message-ID: On Thu, 25 Sep 2003, Travis Oliphant wrote: > > The release of scipy is coming along, but I think we need to postpone > the release until Tuesday as I have found some bugs in special that need > addressing. > > Comments? At this very moment, all scipy-CVS tests pass under Python 2.2.3+ and 2.3+. There are 4 failures (see below) when using Python 2.1.3+. I am running on debian/woody, gcc-3.2.3,3.3.1. All (except one, see below) weave-CVS tests pass with all above mentioned Python versions. I have tried to close scipy roundup issues as much as possible. There are still several issues chatting, most of them are related to chaco but there are few scipy issues that I cannot reproduce (either because the descriptions are rather poor, e.g. "scipy segfaults when importing", or that are related to Windows platform). It would nice if people would go through these roundup issues and try them out with the latest scipy in CVS. Thanks, Pearu ////////////////////////// Python 2.1.3: ====================================================================== FAIL: check_cdf (test_distributions.test_fatiguelife) ---------------------------------------------------------------------- Traceback (most recent call last): File "", line 10, in check_cdf AssertionError: D = 0.353866036798; pval = 0.000362631173686; alpha = 0.01 args = (1.2342939384680749,) ====================================================================== FAIL: check_variation (test_stats.test_moments) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.1/site-packages/scipy/stats/tests/test_stats.py", line 788, in check_variation assert_approx_equal(y,0.44721359549996, 13) File "/usr/lib/python2.1/site-packages/scipy_test/testing.py", line 379, in assert_approx_equal assert math.fabs(sc_desired - sc_actual) < pow(10.,-1*significant), msg AssertionError: Items are not equal to 13 significant digits: DESIRED: 0.44721359550000001 ACTUAL: 44.721359549995796 ====================================================================== FAIL: check_arange (test_basic.test_arange) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/local/lib/python2.1/site-packages/scipy/special/tests/test_basic.py", line 61, in check_arange assert_array_equal(numstringa, array([3.,3.3,3.6,3.9])) File "/usr/lib/python2.1/site-packages/scipy_test/testing.py", line 390, in assert_array_equal assert alltrue(ravel(reduced)),\ AssertionError: Arrays are not equal: ====================================================================== FAIL: check_bei_zeros (test_basic.test_bei_zeros) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/local/lib/python2.1/site-packages/scipy/special/tests/test_basic.py", line 134, in check_bei_zeros -7.376762079367764]),12) File "/usr/lib/python2.1/site-packages/scipy_test/testing.py", line 405, in assert_array_almost_equal assert alltrue(ravel(reduced)),\ AssertionError: Arrays are not almost equal: ---------------------------------------------------------------------- Ran 760 tests in 14.058s FAILED (failures=4) ---------------------------------------------------------- ////////////////////// weave failure: ====================================================================== FAIL: check_add_function_ordered (test_catalog.test_catalog) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/local/lib/python2.1/site-packages/weave/tests/test_catalog.py", line 329, in check_add_function_ordered assert(funcs1[:2] == [string.lower,string.upper]),`funcs1` AssertionError: [] ---------------------------------------------------------------------- From oliphant at ee.byu.edu Thu Sep 25 19:23:40 2003 From: oliphant at ee.byu.edu (Travis Oliphant) Date: Thu, 25 Sep 2003 17:23:40 -0600 Subject: [SciPy-user] Scheduled release In-Reply-To: <002501c383ae$3fbffa00$01fd5644@playroom> References: <3F7338FC.2070703@ee.byu.edu> <002501c383ae$3fbffa00$01fd5644@playroom> Message-ID: <3F7378FC.6070506@ee.byu.edu> Gary Pajer wrote: >>The release of scipy is coming along, but I think we need to postpone >>the release until Tuesday as I have found some bugs in special that need >>addressing. >> >>Comments? >> >>-Travis Oliphant > > > Is cvs keeping up with you so we can shoot darts at it? > Yes, I commit changes pretty regularly (making sure it builds). I'm fixing the orthogonal polynomial section right now and so should be committing changes soon. -Travis O. From oliphant at ee.byu.edu Thu Sep 25 19:27:00 2003 From: oliphant at ee.byu.edu (Travis Oliphant) Date: Thu, 25 Sep 2003 17:27:00 -0600 Subject: [SciPy-user] Re: [SciPy-dev] Scheduled release In-Reply-To: References: Message-ID: <3F7379C4.5040003@ee.byu.edu> Pearu Peterson wrote: > On Thu, 25 Sep 2003, Travis Oliphant wrote: > I would like feedback on a change I made recently to CVS. I noticed that LAPACK functions were locking up the interpreter when nans (and/or infs) where in the array sent to the routine. Has this behavior been observed before or is it due to use of ATLAS, recently compilation flags etc... I've "solved" the problem by elminating all nans before calling the ATLAS routines. If anyone has other suggestions for this problem, let me know. -Travis O. From pearu at scipy.org Fri Sep 26 02:15:19 2003 From: pearu at scipy.org (Pearu Peterson) Date: Fri, 26 Sep 2003 01:15:19 -0500 (CDT) Subject: [SciPy-user] Re: [SciPy-dev] Scheduled release In-Reply-To: <3F7379C4.5040003@ee.byu.edu> Message-ID: On Thu, 25 Sep 2003, Travis Oliphant wrote: > I would like feedback on a change I made recently to CVS. I noticed > that LAPACK functions were locking up the interpreter when nans (and/or > infs) where in the array sent to the routine. > > Has this behavior been observed before or is it due to use of ATLAS, > recently compilation flags etc... Could you be more specific about which functions cause the hang? linalg functions seem to work fine with NaNs here (I didn't update cvs tree): >>> a=array([[1,2],[NaN,4]]) >>> a array([[ 1. , 2. ], [ nan, 4. ]]) >>> linalg.eigvals(a) array([ nan+0.j, nan+0.j]) >>> linalg.inv(a) array([[ nan, nan], [ nan, nan]]) >>> linalg.solve(transpose(a),[1,2]) array([ nan, nan]) >>> a=array([[1,2],[Inf,4]]) >>> a array([[ 1.00000000e+000, 2.00000000e+000], [ inf, 4.00000000e+000]]) >>> linalg.solve(transpose(a),[1,2]) array([ 1., 0.]) >>> linalg.inv(transpose(a)) array([[ 0. , 0.5], [ 0. , 0. ]]) I am using ATLAS-3.2.1 here. Pearu From andymain at dsl.pipex.com Fri Sep 26 04:09:22 2003 From: andymain at dsl.pipex.com (Andy Main) Date: Fri, 26 Sep 2003 09:09:22 +0100 Subject: [SciPy-user] Newbie issues in moving to SciPy In-Reply-To: <3F71C739.8040306@lanl.gov> Message-ID: <001101c38405$7e5ea2a0$0201a8c0@laptop> Thanks everyone for their input, I really do appreciate it. I especially like the pointer to John's Matplotlib work. Thanks! There was just one thing that puzzled me a bit... Nobody mentioned Chaco at all. Do people not consider it mature enough, or was it simply because it is an obvious solution with SciPy. I know that this is an enthought list, but please give me some honest feedback (users and developers). Also any FreeBSD experience would be nice (ie does it work!), I plan on moving my work machine over to BSD in a few weeks. Thanks, Andy. -----Original Message----- From: scipy-user-admin at scipy.net [mailto:scipy-user-admin at scipy.net] On Behalf Of John A. Turner Sent: 24 September 2003 17:33 To: scipy-user at scipy.net Subject: Re: [SciPy-user] Newbie issues in moving to SciPy Fernando Perez wrote: > Granted, I've only used it under X11, and I don't know if 'ported to > WinXXX' means ported to run with an X server there. But perhaps Win > users can double check exactly how that works. yes, it does require an X server on win32 the good news is that both Grace and XFree86 are now bundled with Cygwin ("Cygwin - don't leave Unix without it", http://cygwin.com/) even though XFree86 is certainly usable on win32, I must say I'm partial to the non-free X server X-Win32 (http://www.starnet.com/) -John A. Turner Los Alamos National Laboratory Continuum Dynamics Group (CCS-2) _______________________________________________ SciPy-user mailing list SciPy-user at scipy.net http://www.scipy.net/mailman/listinfo/scipy-user From nwagner at mecha.uni-stuttgart.de Mon Sep 29 12:28:03 2003 From: nwagner at mecha.uni-stuttgart.de (Nils Wagner) Date: Mon, 29 Sep 2003 18:28:03 +0200 Subject: [SciPy-user] Python2.1 and latest cvs Message-ID: <3F785D91.5ADABE2C@mecha.uni-stuttgart.de> Dear experts, there seems to be a problem with scipy and python2.1 File "/usr/local/lib/python2.1/distutils/util.py", line 439, in byte_compile compile(file, cfile, dfile) File "/usr/local/lib/python2.1/py_compile.py", line 62, in compile codeobject = __builtin__.compile(codestring, dfile or file, 'exec') OverflowError: ('integer literal too large', ('/usr/local/lib/python2.1/site-packages/scipy/special/tests/test_basic.py', 854, None, 'mathworld = [1,1,5,61,1385,50521,2702765,199360981,\n')) Any idea ? Nils From arnd.baecker at web.de Fri Sep 26 11:19:25 2003 From: arnd.baecker at web.de (Arnd Baecker) Date: Fri, 26 Sep 2003 17:19:25 +0200 (CEST) Subject: [SciPy-user] Re: [SciPy-dev] Scheduled release In-Reply-To: References: Message-ID: > On Thu, 25 Sep 2003, Travis Oliphant wrote: > > > The release of scipy is coming along, but I think we need to postpone > > the release until Tuesday as I have found some bugs in special that need > > addressing. With python 2.3.1 and a scipy CVS of around half an hour ago, scipy.__version__: '0.2.0_alpha_217.4224' I get the following error with scipy.test(1) ====================================================================== FAIL: check_round (test_basic.test_round) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/python/PYTHON_TST/lib/python2.3/site-packages/scipy/special/tests/test_basic.py", line 1769, in check_round assert_array_equal(rnd,rndrl) File "/home/python/PYTHON_TST/lib/python2.3/site-packages/scipy_test/testing.py", line 390, in assert_array_equal assert alltrue(ravel(reduced)),\ AssertionError: Arrays are not equal: This seems weird to me as the individual lines from scipy_test.testing import assert_array_equal, assert_equal rnd = map(int,(round(10.1),round(10.4),round(10.5),round(10.6))) rndrl = (10,10,11,11) assert_array_equal(rnd,rndrl) work fine ? Anyway, presumably you have spotted this already ... Arnd From wagner.nils at vdi.de Fri Sep 26 14:10:20 2003 From: wagner.nils at vdi.de (Nils Wagner) Date: Fri, 26 Sep 2003 20:10:20 +0200 Subject: [SciPy-user] ImportError: cannot import name real Message-ID: <20030926181053.0E69F3EB29@www.scipy.com> Dear experts, There seems to be a bug in latest cvs... Traceback (most recent call last): File "pseudospectra.py", line 100, in ? io.write_array(file, A, separator=' ', linesep='\n', precision=5, suppress_small=0, keep_open=1) File "/usr/lib/python2.2/site-packages/scipy_base/ppimport.py", line 226, in __getattr__ module = self._ppimport_importer() File "/usr/lib/python2.2/site-packages/scipy_base/ppimport.py", line 204, in _ppimport_importer module = __import__(name,None,None,['*']) File "/usr/lib/python2.2/site-packages/scipy/io/__init__.py", line 11, in ? from array_import import * File "/usr/lib/python2.2/site-packages/scipy/io/array_import.py", line 13, in ? from Numeric import array, take, concatenate, Float, asarray, real, imag ImportError: cannot import name real Any idea ? Nils From joe at enthought.com Mon Sep 29 23:13:48 2003 From: joe at enthought.com (Joe Cooper) Date: Mon, 29 Sep 2003 22:13:48 -0500 Subject: [SciPy-user] Test Message-ID: <3F78F4EC.6090204@enthought.com> Just testing the mailing list. Please ignore. Thanks. From joe at enthought.com Mon Sep 29 23:16:36 2003 From: joe at enthought.com (Joe Cooper) Date: Mon, 29 Sep 2003 22:16:36 -0500 Subject: [SciPy-user] Test Message-ID: <3F78F594.1090805@enthought.com> Testing the mailing list. Please ignore. Thanks! From joe at enthought.com Mon Sep 29 23:23:12 2003 From: joe at enthought.com (Joe Cooper) Date: Mon, 29 Sep 2003 22:23:12 -0500 Subject: [SciPy-user] Testing Message-ID: <3F78F720.6060109@enthought.com> Just testing the mailing list. Please ignore. Thanks. From joe at enthought.com Mon Sep 29 23:24:42 2003 From: joe at enthought.com (Joe Cooper) Date: Mon, 29 Sep 2003 22:24:42 -0500 Subject: [SciPy-user] Test Message-ID: <3F78F77A.9010004@enthought.com> Just testing the mailing list. Please ignore. Thanks. From joe at enthought.com Mon Sep 29 23:48:36 2003 From: joe at enthought.com (Joe Cooper) Date: Mon, 29 Sep 2003 22:48:36 -0500 Subject: [SciPy-user] Test Message-ID: <3F78FD14.6070006@enthought.com> Testing the mailing list. Please ignore. Thanks. From joe at enthought.com Mon Sep 29 23:57:07 2003 From: joe at enthought.com (Joe Cooper) Date: Mon, 29 Sep 2003 22:57:07 -0500 Subject: [SciPy-user] Test Message-ID: <3F78FF13.40807@enthought.com> This is just a test of the mailing list. Please ignore. Thanks! From pajer at iname.com Fri Sep 26 22:19:30 2003 From: pajer at iname.com (Gary Pajer) Date: Fri, 26 Sep 2003 22:19:30 -0400 Subject: [SciPy-user] chaco/traits color pallets are all white Message-ID: <200309262219.30019.pajer@iname.com> I haven't seen this one mentioned. Maybe it's just me. Most, if not all, of the color selection pallets in the traits dialog for a chaco plot show only white. If you click on one of the white squares a real color appears in the preview window and the plot, but the buttons themselves are just all white. linux, CVS from thursday 9/25, python2.3 From karthik at james.hut.fi Fri Sep 26 07:00:47 2003 From: karthik at james.hut.fi (Karthikesh Raju) Date: Fri, 26 Sep 2003 14:00:47 +0300 Subject: [SciPy-user] Numeric and Numarray Message-ID: Hi All, Can SciPy (latest version - yet to install it) co exist with numarray and numeric. If i install numeric, will i break my existing (and also future installation capabilities) of scipy. With warm regards Karthik ----------------------------------------------------------------------- Karthikesh Raju, email: karthik at james.hut.fi Researcher, http://www.cis.hut.fi/karthik Helsinki University of Technology, Tel: +358-9-451 5389 Laboratory of Comp. & Info. Sc., Fax: +358-9-451 3277 Department of Computer Sc., P.O Box 5400, FIN 02015 HUT, Espoo, FINLAND ----------------------------------------------------------------------- From pearu at scipy.org Fri Sep 26 13:47:41 2003 From: pearu at scipy.org (Pearu Peterson) Date: Fri, 26 Sep 2003 12:47:41 -0500 (CDT) Subject: [SciPy-user] Re: [SciPy-dev] Scheduled release In-Reply-To: <3F7379C4.5040003@ee.byu.edu> Message-ID: On Thu, 25 Sep 2003, Travis Oliphant wrote: > I would like feedback on a change I made recently to CVS. I noticed > that LAPACK functions were locking up the interpreter when nans (and/or > infs) where in the array sent to the routine. > > Has this behavior been observed before or is it due to use of ATLAS, > recently compilation flags etc... > > I've "solved" the problem by elminating all nans before calling the > ATLAS routines. > > If anyone has other suggestions for this problem, let me know. As I said in my previous mail, I could not reproduce the problem. However, now that running scipy.special tests I noticed a "hang". During this "hang" python's CPU was up during test_chebyc indicating that some calculations where in progress and the "hang" might be caused by some "infinite" loop or whatever. Rebuilding special magically fixed this, now I cannot reproduce hangs anymore (I am still not using nan_to_num). So, I would still like to see examples of hangs from LAPACK functions as, IMHO, nan_to_num is not a proper solution. The whole point of supporting NaN/Infs in scipy is lost by this as well as the acctual cause for the hangs might still be there to show up in some other weird situation. IMHO. Pearu From wagner.nils at vdi.de Fri Sep 26 14:35:54 2003 From: wagner.nils at vdi.de (Nils Wagner) Date: Fri, 26 Sep 2003 20:35:54 +0200 Subject: [SciPy-user] ImportError: cannot import name real Message-ID: <20030926183627.EC1AF3EB2A@www.scipy.com> Dear experts, there seems to be a bug in latest cvs Traceback (most recent call last): File "pseudospectra.py", line 100, in ? io.write_array(file, A, separator=' ', linesep='\n', precision=5, suppress_small=0, keep_open=1) File "/usr/lib/python2.2/site-packages/scipy_base/ppimport.py", line 226, in __getattr__ module = self._ppimport_importer() File "/usr/lib/python2.2/site-packages/scipy_base/ppimport.py", line 204, in _ppimport_importer module = __import__(name,None,None,['*']) File "/usr/lib/python2.2/site-packages/scipy/io/__init__.py", line 11, in ? from array_import import * File "/usr/lib/python2.2/site-packages/scipy/io/array_import.py", line 13, in ? from Numeric import array, take, concatenate, Float, asarray, real, imag ImportError: cannot import name real Any idea ? Nils From nwagner at mecha.uni-stuttgart.de Mon Sep 29 12:32:43 2003 From: nwagner at mecha.uni-stuttgart.de (Nils Wagner) Date: Mon, 29 Sep 2003 18:32:43 +0200 Subject: [SciPy-user] io is broken ppimport.py array_import.py Message-ID: <3F785EAB.A25036B2@mecha.uni-stuttgart.de> Dear experts, I am using io.write_array very frequently. However, this function doesn't work for the last 3 days. Is there a workaround for using io.write_array until it's fixed in cvs ? Thanks in advance. Nils From oliphant at ee.byu.edu Fri Sep 26 10:57:39 2003 From: oliphant at ee.byu.edu (Travis E. Oliphant) Date: Fri, 26 Sep 2003 08:57:39 -0600 Subject: [SciPy-user] Re: [SciPy-dev] Scheduled release In-Reply-To: References: Message-ID: <3F7453E3.4090702@ee.byu.edu> Pearu Peterson wrote: > > On Thu, 25 Sep 2003, Travis Oliphant wrote: > > >>I would like feedback on a change I made recently to CVS. I noticed >>that LAPACK functions were locking up the interpreter when nans (and/or >>infs) where in the array sent to the routine. >> >>Has this behavior been observed before or is it due to use of ATLAS, >>recently compilation flags etc... > > > Could you be more specific about which functions cause the hang? > linalg functions seem to work fine with NaNs here (I didn't update cvs > tree): linalg.eig was hanging repeatedly with NaNs with both Python 2.2 and 2.3 ATLAS version is 3.4.1 --- perhaps that is the problem. -Travis O. From oliphant at ee.byu.edu Fri Sep 26 11:02:37 2003 From: oliphant at ee.byu.edu (Travis E. Oliphant) Date: Fri, 26 Sep 2003 09:02:37 -0600 Subject: [SciPy-user] Newbie issues in moving to SciPy In-Reply-To: <001101c38405$7e5ea2a0$0201a8c0@laptop> References: <001101c38405$7e5ea2a0$0201a8c0@laptop> Message-ID: <3F74550D.60900@ee.byu.edu> Andy Main wrote: > Thanks everyone for their input, I really do appreciate it. I > especially like the pointer to John's Matplotlib work. Thanks! There > was just one thing that puzzled me a bit... Nobody mentioned Chaco at > all. Do people not consider it mature enough, or was it simply because > it is an obvious solution with SciPy. I know that this is an enthought > list, but please give me some honest feedback (users and developers). > Also any FreeBSD experience would be nice (ie does it work!), I plan on > moving my work machine over to BSD in a few weeks. The reason I did not mention chaco is because I assumed you knew about it already and it does not have good output yet (it will have great output, but right now it takes a bit of work to get it --- in particular I don't like how a simple saving of the pdf file fills up the whole page instead of keeping the same aspect ratio as on screen). I am also not as familar with the capabilities of chaco as it is developing rapidly. I have also not had much success with wxPython on Linux --- the PyCrust shell seems quite flaky (intermittant segfaults) Recently I've used gui_thread with success however, and so that option is certainly available. Chaco is also weaker in the simple interface direction. i.e. something like chaco.barplot or chaco.errbars chaco.imagesc I think there is something like chaco.plot but I haven't checked in detail. It's just a matter of chaco maturity. The chaco/kiva design is quite good and I am enthused about future possibilities. -Travis From joe at enthought.com Tue Sep 30 00:04:01 2003 From: joe at enthought.com (Joe Cooper) Date: Mon, 29 Sep 2003 23:04:01 -0500 Subject: [SciPy-user] Test In-Reply-To: <3F78FF13.40807@enthought.com> References: <3F78FF13.40807@enthought.com> Message-ID: <3F7900B1.6000300@enthought.com> Looks like it's working now. Sorry for all of the dupes. Joe Cooper wrote: > This is just a test of the mailing list. Please ignore. > > Thanks! > > _______________________________________________ > SciPy-user mailing list > SciPy-user at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-user From wagner.nils at vdi.de Mon Sep 29 13:54:51 2003 From: wagner.nils at vdi.de (Nils Wagner) Date: Mon, 29 Sep 2003 19:54:51 +0200 Subject: [SciPy-user] ImportError: cannot import name real Message-ID: <20030929175539.4F6333EB75@www.scipy.com> Dear experts, I am using io.write_array very frequently. However this function is broken for the last 3 days. Is there a simple workaround until it's fixed in cvs ? Thanks in advance. Nils >>> from scipy import * >>> help(io) Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.2/site-packages/scipy_base/ppimport.py", line 258, in __call__ a = a._ppimport_module File "/usr/lib/python2.2/site-packages/scipy_base/ppimport.py", line 226, in __getattr__ module = self._ppimport_importer() File "/usr/lib/python2.2/site-packages/scipy_base/ppimport.py", line 204, in _ppimport_importer module = __import__(name,None,None,['*']) File "/usr/lib/python2.2/site-packages/scipy/io/__init__.py", line 11, in ? from array_import import * File "/usr/lib/python2.2/site-packages/scipy/io/array_import.py", line 13, in ? from Numeric import array, take, concatenate, Float, asarray, real, imag ImportError: cannot import name real From pearu at scipy.org Fri Sep 26 14:23:52 2003 From: pearu at scipy.org (Pearu Peterson) Date: Fri, 26 Sep 2003 13:23:52 -0500 (CDT) Subject: [SciPy-user] Re: [SciPy-dev] Scheduled release In-Reply-To: Message-ID: On Fri, 26 Sep 2003, Pearu Peterson wrote: > > On Thu, 25 Sep 2003, Travis Oliphant wrote: > > > I would like feedback on a change I made recently to CVS. I noticed > > that LAPACK functions were locking up the interpreter when nans (and/or > > infs) where in the array sent to the routine. > > > > Has this behavior been observed before or is it due to use of ATLAS, > > recently compilation flags etc... > > > > I've "solved" the problem by elminating all nans before calling the > > ATLAS routines. > > > > If anyone has other suggestions for this problem, let me know. Ok, now I can generate these "hangs" (that are acctually just some infinite cycles, I'll investigate them later in LAPACK sources). >>> linalg.eigvals([[1,0],[1e308,5]]) array([ 5.+0.j, 1.+0.j]) >>> linalg.eigvals([[1,0],[NaN,5]]) array([ 5.+0.j, 1.+0.j]) >>> linalg.eigvals([[1,0],[Inf,5]]) # now python is taking almost 100% CPU time. Notice that the "hangs" only occur when input array contains Inf or -Inf, there is no problem with NaN. Also, "hangs" occur in lapack functions like eig, eigvals, schur, etc. but inv, det, solve etc never hang. So, here is my suggestion to solve the problem: use inf_to_num instead of nan_to_num only in those lapack functions that *do* hang. In all other functions use asarray as earlier. Pearu From oliphant at ee.byu.edu Tue Sep 30 15:16:08 2003 From: oliphant at ee.byu.edu (Travis E. Oliphant) Date: Tue, 30 Sep 2003 13:16:08 -0600 Subject: [SciPy-user] io is broken ppimport.py array_import.py In-Reply-To: <3F785EAB.A25036B2@mecha.uni-stuttgart.de> References: <3F785EAB.A25036B2@mecha.uni-stuttgart.de> Message-ID: <3F79D678.4070606@ee.byu.edu> Nils Wagner wrote: > Dear experts, > > I am using io.write_array very frequently. However, this function > doesn't work for the last 3 days. > Is there a workaround for using io.write_array until it's fixed in cvs ? > Could you report the error. It should work... -travis From pearu at scipy.org Tue Sep 30 15:21:43 2003 From: pearu at scipy.org (Pearu Peterson) Date: Tue, 30 Sep 2003 14:21:43 -0500 (CDT) Subject: [SciPy-user] io is broken ppimport.py array_import.py In-Reply-To: <3F79D678.4070606@ee.byu.edu> Message-ID: On Tue, 30 Sep 2003, Travis E. Oliphant wrote: > Nils Wagner wrote: > > Dear experts, > > > > I am using io.write_array very frequently. However, this function > > doesn't work for the last 3 days. > > Is there a workaround for using io.write_array until it's fixed in cvs ? > > > > Could you report the error. It should work... I already fixed this. The problem was that array_import.py used Numeric.real but this is available only in the recent versions of Numeric. Pearu From wagner.nils at vdi.de Tue Sep 30 16:19:02 2003 From: wagner.nils at vdi.de (Nils Wagner) Date: Tue, 30 Sep 2003 22:19:02 +0200 Subject: [SciPy-user] io is broken ppimport.py =?iso-8859-1?q?array=5Fimport.py?= In-Reply-To: Message-ID: <20030930201955.1A6413EB22@www.scipy.com> ------------------- On Tue, 30 Sep 2003, Travis E. Oliphant wrote: > Nils Wagner wrote: > > Dear experts, > > > > I am using io.write_array very frequently. However, this function > > doesn't work for the last 3 days. > > Is there a workaround for using io.write_array until it's fixed in cvs ? > > > > Could you report the error. It should work... I already fixed this. The problem was that array_import.py used Numeric.real but this is available only in the recent versions of Numeric. What is a recent version of Numeric ? I have installed >>> import Numeric >>> Numeric.__version__ '23.1' Nils Pearu _______________________________________________ SciPy-user mailing list SciPy-user at scipy.net http://www.scipy.net/mailman/listinfo/scipy-user From pearu at scipy.org Tue Sep 30 16:27:00 2003 From: pearu at scipy.org (Pearu Peterson) Date: Tue, 30 Sep 2003 15:27:00 -0500 (CDT) Subject: [SciPy-user] io is broken ppimport.py =?iso-8859-1?q?array=5Fimport.py?= In-Reply-To: <20030930201955.1A6413EB22@www.scipy.com> Message-ID: On Tue, 30 Sep 2003, Nils Wagner wrote: > The problem was that array_import.py used > Numeric.real but this is available only in the recent versions of > Numeric. > What is a recent version of Numeric ? I have installed > >>> import Numeric Numeric.__version__ > '23.1' Apparently the CVS version that Travis O. uses ;-) Pearu From wagner.nils at vdi.de Tue Sep 30 16:30:28 2003 From: wagner.nils at vdi.de (Nils Wagner) Date: Tue, 30 Sep 2003 22:30:28 +0200 Subject: [SciPy-user] io is broken ppimport.py =?iso-8859-1?q?array=5Fimport.py?= In-Reply-To: Message-ID: <20030930203120.364E83EB22@www.scipy.com> ------------------- On Tue, 30 Sep 2003, Nils Wagner wrote: > The problem was that array_import.py used > Numeric.real but this is available only in the recent versions of > Numeric. > What is a recent version of Numeric ? I have installed > >>> import Numeric Numeric.__version__ > '23.1' Apparently the CVS version that Travis O. uses ;-) Is there a deadline for the next official release of Numeric ? Nils Pearu _______________________________________________ SciPy-user mailing list SciPy-user at scipy.net http://www.scipy.net/mailman/listinfo/scipy-user