Mailman 3 September 2004 - SciPy-User

Help required regding Eigenvectors
by Sudheer Phani March 14, 2022

March 14, 2022

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

multiplying matrices
by David Grant Oct. 16, 2004

Oct. 16, 2004

Is there any way to multiple a whole bunch of matrices together easily? Ideally, the * operator would be for matrix multiplication as opposed to element-by-element multiplication. I've been doing this: listofmatricies = [blah, blah, blah, ....] return reduce(matrixmultiply,listofmatricies) Seems to work, but it would nice to be able to do it in one line as in matlab. -- David J. Grant <http://www.davidgrant.ca:81> Get Firefox! <http://spreadfirefox.com/community/?q=affiliates&id=1621&t=70>

3 3

Problems with python setup.py build
by Nils Wagner Sept. 30, 2004

Sept. 30, 2004

Hi all, I am using the latest f2py and scipy from cvs. I cannot build scipy, but for what reason ? gcc: build/src/Lib/interpolate/dfitpackmodule.c build/src/Lib/interpolate/dfitpackmodule.c:407:27: macro "CHECKARRAY" requires 3 arguments, but only 1 given build/src/Lib/interpolate/dfitpackmodule.c: In function `f2py_rout_dfitpack_splev': build/src/Lib/interpolate/dfitpackmodule.c:407: error: `CHECKARRAY' undeclared (first use in this function) build/src/Lib/interpolate/dfitpackmodule.c:407: error: (Each undeclared identifier is reported only once build/src/Lib/interpolate/dfitpackmodule.c:407: error: for each function it appears in.) build/src/Lib/interpolate/dfitpackmodule.c:407: warning: left-hand operand of comma expression has no effect build/src/Lib/interpolate/dfitpackmodule.c:407: warning: left-hand operand of comma expression has no effect build/src/Lib/interpolate/dfitpackmodule.c:407: error: parse error before ')' token build/src/Lib/interpolate/dfitpackmodule.c:581:62: macro "CHECKARRAY" passed 8 arguments, but takes just 3 Nils

2 4

window re-use in scipy.gplt
by Christopher Fonnesbeck Sept. 30, 2004

Sept. 30, 2004

Is there any way of forcing multiple plots to re-use the same window in scipy.gplt? It seems to happen automatically on Windows, but on UNIX (linux and mac) each plot generates its own window, which makes for a cluttered screen when you generate a sequence dozens of plots (like I do). Thanks for any info. Chris -- Christopher J. Fonnesbeck ( f o n n e s b e c k @ m a c . c o m ) Georgia Cooperative Fish & Wildlife Research Unit University of Georgia, Athens GA

1 0

trying to use weave to access image data in C
by Danial, Al (IIS) Sept. 29, 2004

Sept. 29, 2004

I'm inspired by recent posts on using weave to include C code within a Python program. Does anyone have an example of how one would access the bytes of an image (as loaded with imread) within a weave C inline? Here's a rough idea of what I'm trying to do #!/usr/bin/python from scipy import imread, weave img = imread('image.pcx') rows, cols, colors = img.shape code = """ for (int j=0; j < cols; j++) { for (int i=0; i < rows; i++) { printf("img[%3d][%3d]=%3d %3d %3d\n", i, j, img[i][j][0], img[i][j][1], img[i][j][2]); } } """ weave.inline(code,['img','rows','cols']) Of course I'm interested in actually doing some math on the R,G,B values at each pixel, not just printing the values out. At the moment I'm doing the loops over each pixel (indices i and j in the C code above) in Python and it is pretty slow. 1. How should I declare the img variable in the C code so that it correctly binds to the Python variable of the same name? 2. How would I step through the img variable in the C code? For example would the green value at pixel i,j be referenced as img[i][j][2] or img[i + j*rows][2] or img[(i + j*rows)*2] ? 3. This is the bonus round: if I modify the img variable in the C code how can I get the modified value back to Python? I'm studying http://www.scipy.org/documentation/weave/weaveusersguide.html#inline_numeri… which explains the process scalar integers well. Don't know how to extend that to the array type returned by imread though. -- Al

3 3

Geometry package
by Stuart Murdock Sept. 29, 2004

Sept. 29, 2004

Hi I am looking for a package a bit like Konrad Hinsens Scientific.Geometry except I want it to be able to make things like planes, clinders and general geometrical shapes with the points that I have. The I want to be able to calculate angles and overlaps with other geometrical shapes in a python environment. Is there anything else out there ? Thanks Stuart -- Stuart Murdock Ph.D, Research Fellow, Dept. of Chemistry / E-Science, University of Southampton, Highfield, Southampton, SO17 1BJ, United Kingdom http://www.biosimgrid.org

1 0

matrix construction
by William Griffin Sept. 29, 2004

Sept. 29, 2004

I'm trying to build an adjacency matrix (52*52) from an imported ASCII list. I want to be able to construct and read the list as two columns [i] [j], and use a count method to obtain the tally cell values for the occurrences and include the count value in the [i,j] cell; or else, bring in the list as three columns [i][j][tallies], and then simply place the [tallies] value in the [i,j] cell. I prefer the former two column approach because it involves one less step. I've made several attempts at generating a general algorithm, but it has not been very successful. I was wondering anyone else had to do this or can point me to any code that might be adapted for this. Thanks, Bill Griffin

9 13

RE: [SciPy-user] Performance Python with Weave article updated
by Bob.Cowdery＠CGI-Europe.com Sept. 29, 2004

Sept. 29, 2004

Hi Francesc, Thank you very much for your work. Appologies for the delay in replying I have been laid low with a bug for a few days. It is very interesting to me to see the different ways to do things. I also worked on my code last week and my approach was very similar I think but I copied the techniques I had seen. I have the advantage of course of being able to test my results in my software receiver. The version I have attached runs in a similar time to the weave example although I didn't check actual figures. I am interested in two things, the relative merits of using the ArrayType and the technique that you used. Some arrays are output values and I found that ArrayType did change the source array which was what I wanted. Also I found that when I tried my code for real it didn't work and I found that the ++ operator did not increment, so the code ran fast but wasn't executing correctly. I notice you still use ++, is there some way to make this work in Pyrex? I just attached the whole file, less the blurb, that will contain my extensions, there are two functions in there at present. Regards Bob -----Original Message----- From: Francesc Alted [mailto:falted@pytables.org] Sent: 24 September 2004 17:42 To: scipy-user(a)scipy.net Cc: Bob.Cowdery(a)CGI-Europe.com Subject: Re: [SciPy-user] Performance Python with Weave article updated A Divendres 24 Setembre 2004 15:23, Bob.Cowdery(a)CGI-Europe.com va escriure: > Ok I see the error of my ways, I should have read the article more > closely!! I need to expose each array using ArrayType - I guess that > will make all the difference to the Pyrex time... In fact, As Prahbu has already said it is not really necessary to expose the Array type in Pyrex. Anyway, I looked into your code, and I saw that this is the kind of code where Pyrex can really shine. So, I put my hands to work and this is what I got: 1.- I've converted all the arithmetic where Numeric arrays where implied and substituted by pointers in C. As all the arrays implied were unidimensionals, I was able to keep the indexes (Pyrex can do that for one-dimensional pointers, not for the general multidimensional case). For example, the lines: for tapup from 0 <= tapup <= ln-1: ISum = ISum + filter_phasing[tapdwn] * I_Delay[delay_ptr] QSum = QSum + filter_phasing[tapup] * Q_Delay[delay_ptr] have been replaced by: cdef int buflen cdef void *data cdef double *p_I_Delay cdef double *p_Q_Delay cdef double *p_filter_phasing if PyObject_AsWriteBuffer(I_Delay, &data, &buflen) <> 0: raise RuntimeError("Error getting the array data buffer") p_I_Delay = <double *>data if PyObject_AsWriteBuffer(Q_Delay, &data, &buflen) <> 0: raise RuntimeError("Error getting the array data buffer") p_Q_Delay = <double *>data if PyObject_AsWriteBuffer(filter_phasing, &data, &buflen) <> 0: raise RuntimeError("Error getting the array data buffer") p_filter_phasing = <double *>data for tapup from 0 <= tapup <= ln-1: ISum = ISum + p_filter_phasing[tapdwn] * p_I_Delay[delay_ptr] QSum = QSum + p_filter_phasing[tapup] * p_Q_Delay[delay_ptr] and so on and so forth for the other vector operations. That first optimization gave a speed-up of 6.2x over a the original python code. You can find the complete code for this step in the attachement named as: src/sigblocks_ext.pyx.versio1 2.- Then, I declared the type of variables in the main function. If you don't do that, all the variables are considered python objects, and access to its value is very expensive. This optimization gave an additional speed-up of 3.7x for a total speed-up of 27.7x. The code is in the attachment: sigblocks_ext.pyx.versio2 3.- I've removed all the python calls in the loops, namely abs() and int(). abs() has been replaced by the fabs() C call, while int() has been removed completely (why you try to convert a double to an int and then assign again to a double? if you want to do that, perhaps a C call to roundf would be better). Also, I've removed the line: if(fabs(usb) > peak): self.m_peak = fabs(usb) and replaced it by: cdef double m_peak if(fabs(usb) > peak): m_peak = fabs(usb) and return this maximum at the end: return m_peak This optimization gave an additional speed-up of 3.7x (yes, again) for a total speed-up of 161x. The code of this final version is in the attachment: sigblocks_ext.pyx Well, this is not exactly the more than 200x speed-up that you have achieved with inline weave, but very close. Perhaps the code might be optimized still further, although I believe the gains would be minimal. Well, I think I have ended with a good exercise for my next seminar about python and scientific computing :) Cheers, -- Francesc Alted *** Confidentiality Notice *** Proprietary/Confidential Information belonging to CGI Group Inc. and its affiliates may be contained in this message. If you are not a recipient indicated or intended in this message (or responsible for delivery of this message to such person), or you think for any reason that this message may have been addressed to you in error, you may not use or copy or deliver this message to anyone else. In such case, you should destroy this message and are asked to notify the sender by reply email.

1 0

Re: [SciPy-dev] MCMC, Kalman Filtering, AI for SciPy?
by Travis Oliphant Sept. 28, 2004

Sept. 28, 2004

> I don't think the library names should be mercilessly duplicated > everywhere, but something like this can really help in a few places. > Obviously, a good, searchable, cross-referenced documentation is a key > part of the soultion to this problem, as you mention. As far as searching goes. scipy.info started something like this a while back. The functionality was lost a bit when the delayed import mechanism was used (but it could be modified to work). The idea was that scipy.info(<string>) would start looking for <string> in all the documentation it could find and then would print what it found. It still works on things that are in the namespace of scipy but not subpackages. try scipy.info("fft") for example It is rudimentary, but shows an idea that could be pursued. We should also think about a help-browser system that could pop up (in a different process I think), when the user enters a help command. This is what maple and matlab do effectively. -Travis

3 5

Include path when compiling Fortran code
by Berthold Höllmann Sept. 28, 2004

Sept. 28, 2004

Hello, I openend issue 188 on the scipy issue tracker, but would like to ask here if anyone has a workaround for my problem. We have a quite complex project with some Fortran modules in different subdirectories. Trying to include a file fails when compiling a library with the INTEL Fortran compiler. No include paths are added to the command line. The Issue has a small tar file attached to provide a testcase. Kind regards Berthold Höllmann -- Germanischer Lloyd AG CAE Development Vorsetzen 35 20459 Hamburg Phone: +49(0)40 36149-7374 Fax: +49(0)40 36149-7320 e-mail: hoel(a)gl-group.com Internet: http://www.gl-group.com This e-mail contains confidential information for the exclusive attention of the intended addressee. Any access of third parties to this e-mail is unauthorised. Any use of this e-mail by unintended recipients such as copying, distribution, disclosure etc. is prohibited and may be unlawful. When addressed to our clients the content of this e-mail is subject to the General Terms and Conditions of GL's Group of Companies applicable at the date of this e-mail. GL's Group of Companies does not warrant and/or guarantee that this message at the moment of receipt is authentic, correct and its communication free of errors, interruption etc.

1 0