Mailman 3 August 2004 - SciPy-User

Help required regding Eigenvectors
by Sudheer Phani 14 Mar '22

14 Mar '22

Hello All, I have been encountering some strange problems with the calculation of eigen vectors using python. The problem is with the sign of the eigen vectors calculated. On Very few occasions the eigen vectors calculated using python have an opposite sign than the actual eigenvectors, though the magnitude is correct. Can any one of you plz help me in this regard and suggest me some solution if you have encoutered similar problems . Any help in this regd is appreciated Thanks in Advace regds Sudheer

5 5

odeint -- segmentation fault
by Giovanni Samaey 02 Sep '04

02 Sep '04

Dear scipy users and developers, I have the following problem with odeint: Suppose I would call odeint as follows y=odeint(dydt,y,t,....), where dydt is a complicated function that also calls odeint. So dydt is written as def dydt(y,t): <blabla> intermed=odeint(rhs,y0,t,...) <blabla> rhs is written in C and wrapped through SWIG In my case, I get segmentation faults doing this. Unfortunately, I was not able to cook up an artificial example that is simple, and behaves like this. What I can tell is that, 1) if I let dydt return a zero array (or any "direct" computation of the derivative), then the program works, while if dydt uses odeint, it crashes. 2) The return value of odeint does not have to be *used* for the crash to happen: e.g. one can use the complicated routine inside dydt, but still return zeros, and the crash would take place. 3) Using the complicated routine inside a loop that performs e.g. forward Euler, gives no problem at all. The crash really occurs when the value of dydt is passed into odeint. (This was tested by stepping with pdb.) So a segmentation fault occurs when odeint accesses the result of calling dydt if that function also uses odeint in a complicated way. Maybe the fact that inside dydt, odeint is calling a C routine for its time derivative, has something to do with it? Since I do not have access to odeint's code, I cannot tell what is going on, nor how to solve this... How could this problem be solved effectively? Best, Giovanni -- Giovanni Samaey http://www.cs.kuleuven.ac.be/~giovanni/ Katholieke Universiteit Leuven email: giovanni(a)cs.kuleuven.ac.be Departement Computerwetenschappen phone: +32-16-327081 Celestijnenlaan 200A, B-3001 Heverlee, Belgium fax: +32-16-327996 Office: A04.36

3 4

SciPy '04 BoF: Making Python Attractive to General Scientists
by Joe Harrington 02 Sep '04

02 Sep '04

Making Python Attractive to General Scientists BoF session at SciPy '04 Joe Harrington, Cornell Perry Greenfield, STScI 1. Intro: Why don't more people use Python for scientific analysis? 10 min - typical new user experience - which cohort of new users is it most advantageous to attract? - what's needed before they'll try it - what they'll need to stay - impact of competitors 2. What needs to be done? 10 min - start with draft list - brief open discussion to add/change list 3. Getting people to do it. 10 min - (Note that, while we'd like people to get involved directly, we are realistic in knowing that many are already doing what they can. We're looking for ideas on getting more people in the wider community interested.) - how big are the pieces? - what kind of people should do each item: e.g., coders vs. writers - how to find and involve those people - find people to volunteer to hand-hold some doc writers through learning 4. Approaches to making it easier/faster. 15 min - focus on documenting just a core subset? - can we afford to reduce optimization to ease maintenance, early on? - broadening the community through outreach - hiring writers & packagers 5. How to proceed. 15 min - discussion of specific plans Our short-term goal is to make Python attractive enough for ordinary, non-developer scientists to try it out, particularly those on platforms not well-supported by the current distribution systems. The long-term goals are to extend the community, and to draw from the extended community more and better documentation and application software. While we do have ideas about where we think we need to go, the purpose of this BoF is to see whether the community agrees that accessibility is an important issue, and if so what is needed to achieve it. Please join us for a BoF on Thursday night. Thanks, --jh-- Joe Harrington 326 Space Sciences Building Cornell University Ithaca, NY 14853-6801 (607) 254-8960 office (607) 255-9002 fax jh(a)oobleck.astro.cornell.edu

2 1

Re: [SciPy-user] gplot documentation
by Fernando Perez 01 Sep '04

01 Sep '04

Jeremy Martin wrote: > List, > > Im new to using Scipy and was wondering where to look for > documentation on gplot. Ive looked at the gnuplot webpage but havent > found any sections that resemble the functions in the plotting > tutorial. With no offense to the core scipy team (I'm an avid user of scipy for all my work _except_ plotting), I think you'd be better served right now with another alternative. Scipy has been slowly developing a very ambitious graphics framework called Chaco, but the project isn't really useful to end users yet. I personally have been using Gnuplot.py (with the additions provided by ipython, which IMHO are absolutely critical to real-world efficient use, especially interactively). But I have been keeping a close eye on matplotlib, and with the latest release (from this past Monday), I think it passed a turning point in usability. Now, I've started promoting it to my coworkers who didn't have tons of gnuplot-based scripts like I do. I will probably transition more slowly, but I'm already working on giving ipython gtk-threading support so it integrates nicely with all of matplotlib's backends. In case you are curious, the key additions to matplotlib which just made it pass _my_ criteria were: 1. Mathtext (latex equations) support in the PS/EPS backend. This is absolutely critical for our regular latex-based workflow. 2. Zooming/panning in the interactive plot windows. I pestered John to add to matplotlib these features in the manner which gnuplot 4.0 supports (I use them constantly, and they are critical to my daily workflow). He was extremely receptive to all my suggestions, and they were available in short order. I _really_ like matplotlib, because it provides today a system which matches the various usage scenarios I need: - concise, efficient syntax for quick interactive use. One-off plots of data when developing code, where you need zero fancy features, but you need to do them quickly and with the _absolute_ minimum amount of typing possible. plot(x) should simply plot the x array against its indices. - a real object-oriented framework for more complex things where the plots are generated by a program. There, extreme conciseness is not the key feature. Instead, a clean object model with programmatic access to all parts of the graph is critical. - the ability to plot either to screen or to generate many plots to eps on disk without ever opening a gui. I have automated test suites which need to run without opening a plotting window, but make many plots as they go. - the same library also exposes its functionality as widgets for wxpython. This means that making a gui program which needs sophisticated plotting is not a problem anymore (that's simply impossible with gnuplot, which was never conceived for such purposes). Besides, it has: - easy generation of all common image formats - array plotting as colormaps. For image processing and even a lot of linear algebra things, this is very useful and non-existent in gnuplot (I think there are patches around for it, but it's not in mainline). Matplotlib still has a few rough edges, but it's improving steadily and I see the overall foundations as being solid enough, that I'm willing to bet my own time by working on ipython support for it. I think that the following trio of systems makes an extremely good base for the graphical side of scientific work today in python: - Matplotlib: regular 2d plots (interactive or scripted), array/image plots, gui-building. - MayaVi: sophisticated 3d visualization, volumetric rendering, etc. - PyX: algorithmic generation of high-quality postscript diagrams with latex equations. Replacing matplotlib with gnuplot at this moment, I have incorporated these tools into fairly complex codes in a very smooth way. After having fought the hell of IDL (matlab is probably similar), the power these tools provide, and their simplicity and elegance, are really a pleasure. I hope this is useful. Best, f

11 28

scipy crash with fastumath
by Olivier Ravard 31 Aug '04

31 Aug '04

Hi everybody, As I (and others) already mentioned in this mailing list, there is a python crash (like an exit) when we use scipy under windows for a simple operation like : from scipy import * a = zeros(300000,typecode='F') c=a*a Analyzing the scipy source code, it seems to come from the fastumath module : I comment every line that import fastumath and it works !!! Is anyone have an idea to solve this problem with fastumath under windows ? Thanks. O.R.

2 2

Iterative solvers in scipy
by Nils Wagner 31 Aug '04

31 Aug '04

Hi all, Just now I saw the latest changes in cvs with respect to iterative solvers Do they account for special properties of the coefficient matrix (symmetrie, definiteness, ...) ? Is it possible to use the iterative solvers yet ? If so, how can I manage it ? How about preconditioners ? Regards, Nils --

2 1

Scipy crash with fastumath
by Olivier Ravard 31 Aug '04

31 Aug '04

Hi everybody, As I (and others) already mentioned in this mailing list, there is a python crash (like an exit) when we use scipy under windows for a simple operation like : from scipy import * a = zeros(300000,typecode='F') c=a*a Analyzing the scipy source code, it seems to come from the fastumath module : I comment every line that import fastumath and it works !!! Is anyone have an idea to solve this problem with fastumath under windows ? Thanks. O.R.

1 0

Re: [SciPy-user] scipy_base.squeeze
by Jean-Michel Philippe 30 Aug '04

30 Aug '04

Ok, this is due to the Matlab way of thinking I have. Obviously in Python/SciPy scalars are not a particular case of arrays and I understood that shape(b) = () in your example just means that. Couldn't this be a cause of type conversion issues, for example when a function returns a double or an array depending on the input data? (and squeeze seems to be a good example for that) JM. NB: note that help(squeeze) just tells % Help on function squeeze in module scipy_base.shape_base: % %squeeze(a) % Returns a with any ones from the shape of a removed which does not mean that the type of 'a' could be the same or could be changed depending on the result. oliphant(a)ee.byu.edu wrote: > I don't understand the problem. If you have a (1,1) array then > according to the documentation squeeze should return an array with all > dimensions of length one removed. Therefore, you end up with a > zero-dimensional array (this is not an empty array...) > > It seems to work for me: > > >>> a = array([[5]]) > >>> a.shape > (1, 1) > >>> b = squeeze(a) > >>> shape(b) > () > >>> b > 5 > >>> > > > This is not a "side effect" but a documented effect. If you want to > ensure a 1d array as it seems you do, then you could use > > b = atleast_1d(squeeze(a)) > > -Travis >

1 0

gplt axis interval question
by Ty Rone 27 Aug '04

27 Aug '04

Is there a way to change the axis interval in gplt so that the major tics and numbers increase by 24 (0, 24, 48, 72)? Thanks, Ty __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail

2 1

scipy_base.squeeze
by Jean-Michel Philippe 27 Aug '04

27 Aug '04

Hi, I recently had troubles with the squeeze function from scipy_base. It squeezes all the dimensions when I pass a (1,1) array, resulting in an empty one! Is it a known side effect? Regards. JM. Philippe -------------------------- PS: I modified the 'site-packages/scipy_base/shape_base.py' script this way to get rid of the problem: def squeeze(a): "Returns a with any ones from the shape of a removed" a = asarray(a) b = asarray(a.shape) dims = tuple (compress (not_equal (b, 1), b)) if len(dims) == 0: dims = (1, ) val = reshape (a, dims) return val --------------------------

2 1