Mailman 3 March 2007 - SciPy-Dev

Question about Kaiser Implementation in firwin
by Buehler, Eric (AGRE) 04 Oct '08

04 Oct '08

Hello, I have been using the signal.firwin FIR design tool and I have a question about the implementation. Scipy-0.4.8 Numpy-0.9.6 I am generating a kaiser window with the following parameters: N = 128 Cutoff = ~4e7 width = .3 All of the special kaiser generation parameters in the function follow Oppenheim and Schafer well. Even the sinc function for linear phase is follows exactly. However, the last line of the firwin function is causing me some heartburn. filter_design.py 1538 win = get_window(window,N,fftbins=1) 1539 alpha = N//2 1540 m = numpy.arange(0,N) 1541 h = win*special.sinc(cutoff*(m-alpha)) 1542 return h / sum(h) Line 1542 of filter_design.py, "return h / sum(h)", normalizes the function where it doesn't seem necessary, at least in the kaiser window case. Without the normalization, the kaiser window already returns a value of 1 at the zero frequency point. This normalization scales all of the data, making the window difficult to use in the frequency domain. Can someone point me to the rationale for this line? Looking at the code, this seems to be a pretty recent change (within the last year/year and a half). Thanks, Eric Buehler eric <dot> buehler <at> smiths-aerospace <dot> com ****************************************** The information contained in, or attached to, this e-mail, may contain confidential information and is intended solely for the use of the individual or entity to whom they are addressed and may be subject to legal privilege. If you have received this e-mail in error you should notify the sender immediately by reply e-mail, delete the message from your system and notify your system manager. Please do not copy it for any purpose, or disclose its contents to any other person. The views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of the company. The recipient should check this e-mail and any attachments for the presence of viruses. The company accepts no liability for any damage caused, directly or indirectly, by any virus transmitted in this email. ******************************************

3 2

ZVODE, a Double Precision Complex ODE Solver
by Nils Wagner 20 Feb '08

20 Feb '08

This might be of interest. Nils From: Alan Hindmarsh <alanh(a)llnl.gov> Date: Wed, 6 Dec 2006 18:20:32 -0500 Subject: ZVODE, a Double Precision Complex ODE Solver Of the many solvers freely available for ODE initial value problems, there seem to be very few, if any, for the case of double precision complex dependent variables, even though there have been occasional user calls for this functionality. (Of course a complex system can be treated as a real system of twice the size, but direct treatment as a complex system is preferable.) I have provided such a solver: ZVODE. ZVODE is a straightforward modification of the Fortran ODE solver DVODE, for double precision real systems, making it part of a trio, SVODE/DVODE/ZVODE. ZVODE is available in two locations: (1) Netlib, in /ode (see file zvode.f), and (2) the LLNL CASC software site, www.llnl.gov/CASC/software.html (see VODE). The latter site also includes a demonstration program, zvdemo. Alan Hindmarsh Center for Applied Scientific Computing Lawrence Livermore National Laboratory

4 5

Re: [SciPy-dev] Callback feature for iterative solvers
by Nils Wagner 04 May '07

04 May '07

Ed Schofield wrote: > > On 1/24/07, *Nils Wagner* <nwagner(a)iam.uni-stuttgart.de > <mailto:nwagner@iam.uni-stuttgart.de>> wrote: > > Hi Ed, > > Great ! > Thank you very much ! > It seems to work well with the exception of GMRES. > Please find attached a short test. > Am I missing something ? > > > No, I agree. It seems that there's something wrong with GMRES -- the > iter_ return parameter from gmresrevcom() is never incremented for > this example. I'm not familiar with the algorithm -- perhaps it really > does converge in one iteration? If not, it's just a bug. Could you > file a bug against gmres() in Tracker? > > -- Ed > Hi Ed, Done. Maybe you can add some comments. Again thank you very much for the new functionality !! http://projects.scipy.org/scipy/scipy/ticket/360 Cheers, Nils

4 3

Proposal for more generic optimizers (posted before on scipy-user)
by Matthieu Brucher 18 Apr '07

18 Apr '07

Hi, I'm migratting toward Python for some weeks, but I do not find the tools I had to develop for my PhD in SciPy at the moment. I can't, for instance, find an elegant way to save the set of parameters used in an optimization for the standard algorithms. What is more, I think they can be more generic. What I did in C++, and I'd like your opinion about porting it in Python, was to define a standard optimizer with no iteration loop - iterate was a pure virtual method called by a optimize method -. This iteration loop was then defined for standard optimizer or damped optimizer. Each time, the parameters tested could be saved. Then, the step that had to be taken was an instance of a class that used a gradient step, a Newton step, ... and the same was used for the stoping criterion. The function was a class that defined value, gradient, hessian, ... if needed. For instance, a simplified instruction could have been : Optimizer* optimizer = StandardOptimizer</*some more parameters not relevant in Python*/(function, GradientStep(), SimpleCriterion(NbMaxIterations), step, saveParameters); optimizer->optimize(); optimizer->getOptimalParameters(); The "step" argument was a constant by which the computed step had to be multiplied, by default, it was 1. I know that this kind of writting is not as clear and lightweight as the current one, which is used by Matlab too. But perhaps giving more latitude to the user can be proposed with this system. If people want, I can try making a real Python example... Matthieu P.S. : sorry for the multiposting, I forgot that there were two ML for SciPy :(

9 40

UMFPACKv4.4 and swig memory leak of type 'void *'
by Nils Wagner 10 Apr '07

10 Apr '07

Hi all, scipy.test(1,10) reports a lot of memory leaks, e.g. Getting factors of complex matrixswig/python detected a memory leak of type 'void *', no destructor found. Getting factors of real matrixswig/python detected a memory leak of type 'void *', no destructor found. Solve with UMFPACK: double precision complexswig/python detected a memory leak of type 'void *', no destructor found. swig/python detected a memory leak of type 'void *', no destructor found. ... ok Solve: single precision complexUse minimum degree ordering on A'+A. ... ok Solve with UMFPACK: double precisionswig/python detected a memory leak of type 'void *', no destructor found. swig/python detected a memory leak of type 'void *', no destructor found. ... ok Is this a swig problem ? I am using Numpy version 1.0.2.dev3562 Scipy version 0.5.3.dev2774 cat /proc/cpuinfo yields processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Core(TM)2 CPU 6300 @ 1.86GHz stepping : 6 cpu MHz : 1596.000 cache size : 2048 KB physical id : 0 siblings : 2 core id : 0 cpu cores : 2 fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx lm constant_tsc pni monitor ds_cpl vmx est tm2 cx16 xtpr lahf_lm bogomips : 3726.92 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: processor : 1 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Core(TM)2 CPU 6300 @ 1.86GHz stepping : 6 cpu MHz : 1596.000 cache size : 2048 KB physical id : 0 siblings : 2 core id : 1 cpu cores : 2 fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx lm constant_tsc pni monitor ds_cpl vmx est tm2 cx16 xtpr lahf_lm bogomips : 3724.17 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: amd_info: libraries = ['amd'] library_dirs = ['/usr/local/src/UMFPACKv4.4/AMD/Lib'] define_macros = [('SCIPY_AMD_H', None)] swig_opts = ['-I/usr/local/src/UMFPACKv4.4/AMD/Include'] include_dirs = ['/usr/local/src/UMFPACKv4.4/AMD/Include'] umfpack_info: libraries = ['umfpack', 'amd'] library_dirs = ['/usr/local/src/UMFPACKv4.4/UMFPACK/Lib', '/usr/local/src/UMFPACKv4.4/AMD/Lib'] define_macros = [('SCIPY_UMFPACK_H', None), ('SCIPY_AMD_H', None)] swig_opts = ['-I/usr/local/src/UMFPACKv4.4/UMFPACK/Include', '-I/usr/local/src/UMFPACKv4.4/AMD/Include'] include_dirs = ['/usr/local/src/UMFPACKv4.4/UMFPACK/Include', '/usr/local/src/UMFPACKv4.4/AMD/Include'] rpm -qi swig Name : swig Relocations: (not relocatable) Version : 1.3.29 Vendor: SUSE LINUX Products GmbH, Nuernberg, Germany Release : 29 Build Date: Mon 27 Nov 2006 10:46:51 PM CET Install Date: Mon 19 Feb 2007 09:04:53 AM CET Build Host: lanner.suse.de Group : Development/Languages/C and C++ Source RPM: swig-1.3.29-29.src.rpm Size : 3602040 License: BSD License and BSD-like Signature : DSA/SHA1, Mon 27 Nov 2006 10:57:29 PM CET, Key ID a84edae89c800aca Packager : http://bugs.opensuse.org URL : http://www.swig.org Summary : Simplified Wrapper and Interface Generator Nils

2 3

Re: [SciPy-dev] [Numpy-discussion] Tuning sparse stuff in NumPy
by Robert Cimrman 10 Apr '07

10 Apr '07

David Koch wrote: > Ok, > > I did and the results are: > csc * csc: 372.601957083 > csc * csc: 3.90811300278 a typo here? which one is csr? > csr * csc: 15.3202679157 > csr * csr: 3.84498214722 > > Mhm, quite insightful. Note, that in an operation X.transpose() * X, > where X > is csc_matrix, then X.tranpose() is automatically cast to csr_matrix. A > re-cast to csc make the whole operation faster. It's still about 1000 times > slower than Matlab but 4 times faster than before. ok. now which version of scipy (scipy.__version__) do you use (you may have posted it, but I missed it)? Not so long ago, there was an effort by Nathan Bell and others reimplementing sparsetools + scipy.sparse to get better usability and performance. My (almost latest) version is 0.5.3.dev2860. r.

2 2

mlabwrap scikit [Was: Re: scikits project]
by Alexander Schmolck 10 Apr '07

10 Apr '07

[Second attempt to move this to scipy-dev, this time using the right email account; for those who have no idea what mlabwrap is about: it's a python to matlab bridge currently on the move from sourceforge to scipy's emerging scikits infrastructure] Hi, First, it's great that mlabwrap has found a new home at scipy.org, big thanks to everyone involved. I'm afraid that I'm still not quite up to speed on all infrastructural issues -- I've not used subversion before and I haven't completely grokked the scipy infrastructure yet (although I've been trying to read up, especially on svn) and I'm a bit puzzled by some things (see below), so please excuse if some of what follows sounds a bit clueless. In order to bring the mlabwrap project forward, there are three things I'd like to achieve in the immediate future (by end of next week): 1. Resolve remaining infrastructural questions 2. Bring out mlabwrap-1.0 final 3. Discuss a roadmap and feature requirements for mlabwrap 2.0 So let's start out with 1. : ---------------------------- "Jarrod Millman" <millman(a)berkeley.edu> writes: > Hey, > > Jeff got everything setup and I tested it out. Everything looks good > (Thanks Jeff and Robert!). > > I checked in mlabwrap v1.0b: > https://projects.scipy.org/scipy/scikits/browser/trunk/mlabwrap > And then since Jeff installed the rest macro; I added > [[ReST(/trunk/mlabwrap/README.txt)]] > which Trac renders like this: > https://projects.scipy.org/scipy/scikits/wiki/MlabWrap > I also moved the discussion about proxy objects from the NIPY site: > https://projects.scipy.org/scipy/scikits/wiki/MlabProxyObjects > > Hopefully everyone has access to the scikits subversion repository > now. If not, please try and get access ASAP. Shouldn't having a svn account mean that I'd be able to succesfully log in to the trac interface at <https://projects.scipy.org/scipy/scikits/browser/trunk/mlabwrap> using the same account? I can't either use the AlexanderSchmolck login I created on scipy.org, nor the POP3/SVN login a.schmolck(a)gmail.com[1] I received an email from webmin(a)scipy.org on Friday[3]; however I *can* commit to the repository using svn (I've sent an email to webmin(a)scipy.org, but haven't heard anything back). Another thing I've been wondering about is whether it would be easy to import the existing CVS repository into svn? I've fiddled around a little bit with cvs2svn and on first sight it looks like it migh work OK. Loosing the project history wouln't be too tragic (and I can just try to get the sf staff to upload the old CVS repository on the sf page, so it's publically available somewhere), but if we can just import the existing repository without too much of a hassle, I think this might be the best option. Before doing anything with the CVS repository, I'd first manually adapt the directory structure, though, bringing us to 1.a. source code and svn organization ''''''''''''''''''''''''''''''''''''' In an email some time ago Robert Kern proposed the following directory structure for scikits: branches/ tags/ trunk/ mlabwrap/ setup.py scikits/ __init__.py mlabwrap/ __init__.py The current directory structure misses the scikits/ dir and the second mlabwrap/ dir; instead it has mlabwrap.py at top-level (as well as the utility libraries awmstools.py and awmsmeta.py and the c++-extension mlabraw.cpp). Independent of scikits conventions, it seems that making mlabwrap a package and stuffing everything it needs inside (i.e. the utility libs and mlabraw) rather than polluting the toplevel module-namespace seems desirable I assume this question reflects my svn-newbie status, but why doesn't the scikits structure look something like this, given that as I understand it scikits are meant to be essentially independent (and hence independely versioned) projects under a common namespace? mlabwrap/ branches/ tags/ trunk/ setup.py scikits/ __init__.py mlabwrap/ __init__.py some_other_scikit/ branches/ ... It somehow seems to me that tags and branches should apply to individual projects and that one could still do convenient releases and svn-checkouts of scikits/ as a whole by using e.g. svn:externals to the individual projects. As I said, I'm not really knowledgable about svn, but I'd like to understand the logic a bit better, because I'm also trying to work out what to do about the awmsmeta.py and awmstools.py stuff, which isn't really a part of mlabwrap as such. I see three ways of dealing with the dependency on the utility modules: D1. Drop it and copy-and-paste the needed bits into mlabwrap.py (certainly possible, only a few functions are needed; OTOH it seems a bit ugly) D2. Rely on cheeseshop (but I don't have the impression that it is equally acceptable and painless for a python module to download and install dependencies as it is for a CTAN module) D3. Stuff copies into mlabwrap/ and do a relative import D3. seems most attractive to me at the moment but one would still have to figure out where the VC of awmstools.py and awmsmeta.py would "live"; I thought it would be cleanest if they were included as svn:externals and not directly part of the mlabwrap svn tree, so I thought maybe something like this (ignoring the question of where branches/ trunk/ and tags/ go exactly): mlabwrap/ setup.py scikits/ __init__.py README.txt # etc. mlabraw.py # dummy importing mlabwrap/mlabraw, for backwards comp. mlabwrap/ __init__.py -> awmstools.py -> awmsmeta.py mlabwraw.cpp test/ test_mlabwrap.py # etc. I also assume we want a branch for the 1.0.x version, a tag for the 1.0 release (when it's ready) and that development of the next version will continue in the trunk. Comments? Also are there any strong feelings/established procedures concerning __init__.py? The generic name is somewhat inconvient in various contexts (e.g. buffer switching im emacs) so I thought about making __init__.py a dummy importing ./_mlabwrap.py or so. OK, sorry this is getting so long, on to 2. bringing out mlabwrap-1.0 final: ------------------------------------ Apart from the question what the directory structure should look like, the only issue that I'm currently aware of is that there appears to be a problem with `setup.py` automatically finding out about the matlab version under windows; if no one steps up to do some windows testing I'm also willing to apply some fix I assume will work and release as is (windows users might have to set MATLAB_VERSION etc. in setup.py by hand if it doesn't, which isn't *that* terrible). Actually, one more thing: distutils vs. scipy distutils vs. setuptools -- which one should mlabwrap-1.0 final use? I'm only really fully familiar with the first one. Finally point 3, the road-map: ------------------------------ I'd like to get some idea what is felt as needed for the next version of mlabwrap (let's say 2), by when (e.g. because it would be really handy for NIPY; how important is e.g. that 'proxy.a.b = c' works as expected?) and who is interested on working on specific parts (like the move to ctypes). Also what python and matlab versions should mlabwrap 2 have to support? How should changes affecting backwards compatibility best be handled (maybe allowing getting v1 default behavior with something like `from mlabwrap.v1 import mlab`?)? I've put up some notes concerning mlabwrap development and design issues at <http://www.scipy.org/MlabWrap>, corrections, additions and feedback (using either the wiki page itself or scipy-dev) are highly welcome. Sorry for the relative long silence -- apart from hacking on the next version, writing up my thoughts and wikifying took *far* longer than I would have thought, especially since it's only personal note-quality rather than something polished. I hope it's at least partly intelligible and useful. cheers, 'as Footnotes: [1] Are those two account logins meant to be different or is this just because I was too dumb to notify Jeff Strunk of my newly created scipy.org account in time? BTW unless there's some convention that the svn login should be an email address, I'd rather just have a.schmolck (sans gmail.com), if it's something that's easy to change.

6 16

Re: [SciPy-dev] Roadmap for SciPy/Numpy
by Joe Harrington 30 Mar '07

30 Mar '07

> > Yes, that is the right link. I found the other one and fixed both, > > and added comments to help us find them again when they break next > > time. Thanks for letting me know about them! > > > --jh-- > Thanks a lot, these links a really helpfull to understand the way you want > things to be done in SciPy. > Now, from what I understood, there must be a "private area" aimed at > contributors only (I reckon it's the developper zone), where all > developpement of code and documentation should happen, and the main site > should be a "public area" where only stable and clean features and > documentation are presented. > For example, if I want to add some screenshots in the "ScreenShots" of the > wiki, I must: > - edit the ScreenShots page on the wiki (this page is only accessible from the > MigratingFromPlone page, i.e. private area) > - ask on this mailing list if these screenshots are good, or if I must change > anything. > - Once everyone is happy with the screenshot page, I can put a link to this > ScreenShots page on the public area (for example on the main page). > Did I understand well? > I just don't want to edit the wiki the wrong way... > -- > Gilles Yes, that's the idea for a completely new area of the site. If you're tweaking an existing area that's relatively mature, just be sure whoever maintains it is aware of what you're doing. If you're overhauling, talk to the community. Discussion might include where and how to add the page (e.g., on the main site, or under Documentation). We have to depend on people's good judgement, so please err on the side of asking. Since ScreenShots existed in the old plone site and nobody's migrated it yet, doing so would be a service. Thanks in advance for your contributions! --jh--

1 0

Re: [SciPy-dev] Roadmap for SciPy/Numpy
by jh＠physics.ucf.edu 30 Mar '07

30 Mar '07

> I would like to know if there is somme kind of roadmap for the developpement > of SciPy/Numpy, I can't find it on the web site, neither on this mailing > list. There is a roadmap for everything except the software itself (docs, releases, etc.) in http://scipy.org/Developer_Zone (scroll to the bottom). The Developer_Zone page is the right place to list people and to put a more formal roadmap/timetable. But, a timeline can't happen until people step up to lead the component efforts. It seems the community is in the perpetual state of having a *lot* of ready workers, but only a few committed leaders. We need: Someone to lead the creation of binary installers for all platforms, especially the various Linux distros. Someone to write a tutorial user manual that is not field-specific and that has plenty of worked examples. It must be presented as (at least) a single PDF plus example zip file. Someone to lead the scipy release team, as Travis does for numpy, and push actively toward a 1.0 release. This may be progressing quietly, below the radar, or may be stalled, I don't know. There was activity as recently as last December. We worked out the priorities and even some of the broad parameters of these projects years ago, but only a few of the identified goals have had any progress (notably the unification of numarray and Numeric, and ongoing maintenance of numpy, thank you Travis!). A road map is a good thing, but without more willing leaders, we will continue to have little progress in these key areas. On the positive side, the number of willing workers is high, so when someone does step up to lead, they will have a lot of help. I expect that a good leader who can delegate and manage effectively will put in no more time than one of the workers, say 4-10 hours a week. The situation of the lagging binary installers is most sad, and is the main thing that keeps people away from this software. Almost everyone I know in physics, and many people in astronomy, know about SciPy. However, they're all still waiting for it to "stabilize", which to them means they can install it with yum or synaptic or whatever (and it works every time when they do), and they see regular releases, and they see all the packages and platforms and OS versions supported for each release right from the start. Seeing a tarball for the current release, and just an outdated binary for *their* platform for some ancient releases, is insulting to them. It also indicates a project in danger of not having the critical mass to stay afloat for the long haul, so people rightly hesitate in committing their projects to python. We know better, but the only way to communicate that (and to get the large number of new users that would result) is to make binary packages in the traditional way, and keep them current. Since we've called for people to step forward and take charge of these areas before, do folks have ideas on ways to bring a financial incentive to bear? I've talked to more than a few people who could throw $10k at the problem, as could I, but there isn't an easy way to ensure long-term stability of a hired position. Would Enthough be willing to sell "support" for $5k a contract, and hire someone on a contract basis for, say, $50k to build binaries and write docs that happen also to go on the web site and get made part of the project? The supported entities would get to decide which platforms to do first, and would have some say in how it was done. Thoughts? --jh--

5 5

Can't install scipy from svn (caused by ndimage)
by Nils Wagner 29 Mar '07

29 Mar '07

Hi all, I cannot build/install scipy from svn. Here is the output of python setup.py install ... Lib/ndimage/src/ni_morphology.c: In function ‘NI_BinaryErosion’: Lib/ndimage/src/ni_morphology.c:101: warning: implicit declaration of function ‘NA_OFFSETDATA’ Lib/ndimage/src/ni_morphology.c:101: warning: cast to pointer from integer of different size Lib/ndimage/src/ni_morphology.c:110: warning: assignment makes pointer from integer without a cast Lib/ndimage/src/ni_morphology.c:128: warning: assignment makes pointer from integer without a cast Lib/ndimage/src/ni_morphology.c:129: warning: assignment makes pointer from integer without a cast Lib/ndimage/src/ni_morphology.c: In function ‘NI_BinaryErosion2’: Lib/ndimage/src/ni_morphology.c:313: warning: cast to pointer from integer of different size Lib/ndimage/src/ni_morphology.c:340: warning: assignment makes pointer from integer without a cast Lib/ndimage/src/ni_morphology.c:354: warning: assignment makes pointer from integer without a cast Lib/ndimage/src/ni_morphology.c:370: warning: assignment makes pointer from integer without a cast Lib/ndimage/src/ni_morphology.c:467: warning: assignment makes pointer from integer without a cast Lib/ndimage/src/ni_morphology.c:468: warning: assignment makes pointer from integer without a cast Lib/ndimage/src/ni_morphology.c: In function ‘NI_DistanceTransformBruteForce’: Lib/ndimage/src/ni_morphology.c:513: warning: pointer/integer type mismatch in conditional expression Lib/ndimage/src/ni_morphology.c:517: warning: assignment makes pointer from integer without a cast Lib/ndimage/src/ni_morphology.c:523: warning: assignment makes pointer from integer without a cast Lib/ndimage/src/ni_morphology.c:531: warning: assignment makes pointer from integer without a cast Lib/ndimage/src/ni_morphology.c:554: warning: assignment makes pointer from integer without a cast Lib/ndimage/src/ni_morphology.c: In function ‘NI_DistanceTransformOnePass’: Lib/ndimage/src/ni_morphology.c:681: warning: cast to pointer from integer of different size Lib/ndimage/src/ni_morphology.c:691: warning: assignment makes pointer from integer without a cast Lib/ndimage/src/ni_morphology.c:709: warning: assignment makes pointer from integer without a cast Lib/ndimage/src/ni_morphology.c: In function ‘NI_EuclideanFeatureTransform’: Lib/ndimage/src/ni_morphology.c:921: warning: pointer/integer type mismatch in conditional expression Lib/ndimage/src/ni_morphology.c:923: warning: assignment makes pointer from integer without a cast Lib/ndimage/src/ni_morphology.c:924: warning: assignment makes pointer from integer without a cast Lib/ndimage/src/ni_morphology.c: At top level: /usr/lib64/python2.4/site-packages/numpy/core/include/numpy/__multiarray_api.h:944: warning: ‘_import_array’ defined but not used gcc: Lib/ndimage/src/ni_support.c Lib/ndimage/src/ni_support.c: In function ‘NI_InitLineBuffer’: Lib/ndimage/src/ni_support.c:147: warning: implicit declaration of function ‘NA_OFFSETDATA’ Lib/ndimage/src/ni_support.c:147: warning: assignment makes pointer from integer without a cast Lib/ndimage/src/ni_support.c: At top level: /usr/lib64/python2.4/site-packages/numpy/core/include/numpy/__multiarray_api.h:944: warning: ‘_import_array’ defined but not used gcc: Lib/ndimage/src/ni_fourier.c Lib/ndimage/src/ni_fourier.c: In function ‘NI_FourierFilter’: Lib/ndimage/src/ni_fourier.c:190: warning: implicit declaration of function ‘NA_OFFSETDATA’ Lib/ndimage/src/ni_fourier.c:190: warning: initialization makes pointer from integer without a cast Lib/ndimage/src/ni_fourier.c:315: warning: assignment makes pointer from integer without a cast Lib/ndimage/src/ni_fourier.c:316: warning: assignment makes pointer from integer without a cast Lib/ndimage/src/ni_fourier.c:366: error: ‘npy_complex32’ undeclared (first use in this function) Lib/ndimage/src/ni_fourier.c:366: error: (Each undeclared identifier is reported only once Lib/ndimage/src/ni_fourier.c:366: error: for each function it appears in.) Lib/ndimage/src/ni_fourier.c:366: error: syntax error before ‘)’ token Lib/ndimage/src/ni_fourier.c:366: error: syntax error before ‘)’ token Lib/ndimage/src/ni_fourier.c:367: error: ‘struct <anonymous>’ has no member named ‘r’ Lib/ndimage/src/ni_fourier.c:367: error: ‘struct <anonymous>’ has no member named ‘i’ Lib/ndimage/src/ni_fourier.c:373: error: syntax error before ‘)’ token Lib/ndimage/src/ni_fourier.c:373: error: syntax error before ‘)’ token Lib/ndimage/src/ni_fourier.c:374: error: ‘struct <anonymous>’ has no member named ‘r’ Lib/ndimage/src/ni_fourier.c:374: error: ‘struct <anonymous>’ has no member named ‘i’ Lib/ndimage/src/ni_fourier.c:401: error: syntax error before ‘)’ token Lib/ndimage/src/ni_fourier.c:401: error: syntax error before ‘)’ token Lib/ndimage/src/ni_fourier.c:402: error: ‘struct <anonymous>’ has no member named ‘r’ Lib/ndimage/src/ni_fourier.c:402: error: ‘struct <anonymous>’ has no member named ‘i’ Lib/ndimage/src/ni_fourier.c: In function ‘NI_FourierShift’: Lib/ndimage/src/ni_fourier.c:441: warning: initialization makes pointer from integer without a cast Lib/ndimage/src/ni_fourier.c:497: warning: assignment makes pointer from integer without a cast Lib/ndimage/src/ni_fourier.c:498: warning: assignment makes pointer from integer without a cast Lib/ndimage/src/ni_fourier.c:524: error: ‘npy_complex32’ undeclared (first use in this function) Lib/ndimage/src/ni_fourier.c:524: error: syntax error before ‘)’ token Lib/ndimage/src/ni_fourier.c:524: error: syntax error before ‘)’ token Lib/ndimage/src/ni_fourier.c:524: error: syntax error before ‘)’ token Lib/ndimage/src/ni_fourier.c:524: error: syntax error before ‘)’ token Lib/ndimage/src/ni_fourier.c:525: error: ‘struct <anonymous>’ has no member named ‘r’ Lib/ndimage/src/ni_fourier.c:525: error: ‘struct <anonymous>’ has no member named ‘i’ Lib/ndimage/src/ni_fourier.c:525: error: ‘struct <anonymous>’ has no member named ‘r’ Lib/ndimage/src/ni_fourier.c:525: error: ‘struct <anonymous>’ has no member named ‘i’ Lib/ndimage/src/ni_fourier.c:531: error: syntax error before ‘)’ token Lib/ndimage/src/ni_fourier.c:531: error: syntax error before ‘)’ token Lib/ndimage/src/ni_fourier.c:532: error: ‘struct <anonymous>’ has no member named ‘r’ Lib/ndimage/src/ni_fourier.c:532: error: ‘struct <anonymous>’ has no member named ‘i’ Lib/ndimage/src/ni_fourier.c: In function ‘NI_FourierFilter’: Lib/ndimage/src/ni_fourier.c:190: warning: implicit declaration of function ‘NA_OFFSETDATA’ Lib/ndimage/src/ni_fourier.c:190: warning: initialization makes pointer from integer without a cast Lib/ndimage/src/ni_fourier.c:315: warning: assignment makes pointer from integer without a cast Lib/ndimage/src/ni_fourier.c:316: warning: assignment makes pointer from integer without a cast Lib/ndimage/src/ni_fourier.c:366: error: ‘npy_complex32’ undeclared (first use in this function) Lib/ndimage/src/ni_fourier.c:366: error: (Each undeclared identifier is reported only once Lib/ndimage/src/ni_fourier.c:366: error: for each function it appears in.) Lib/ndimage/src/ni_fourier.c:366: error: syntax error before ‘)’ token Lib/ndimage/src/ni_fourier.c:366: error: syntax error before ‘)’ token Lib/ndimage/src/ni_fourier.c:367: error: ‘struct <anonymous>’ has no member named ‘r’ Lib/ndimage/src/ni_fourier.c:367: error: ‘struct <anonymous>’ has no member named ‘i’ Lib/ndimage/src/ni_fourier.c:373: error: syntax error before ‘)’ token Lib/ndimage/src/ni_fourier.c:373: error: syntax error before ‘)’ token Lib/ndimage/src/ni_fourier.c:374: error: ‘struct <anonymous>’ has no member named ‘r’ Lib/ndimage/src/ni_fourier.c:374: error: ‘struct <anonymous>’ has no member named ‘i’ Lib/ndimage/src/ni_fourier.c:401: error: syntax error before ‘)’ token Lib/ndimage/src/ni_fourier.c:401: error: syntax error before ‘)’ token Lib/ndimage/src/ni_fourier.c:402: error: ‘struct <anonymous>’ has no member named ‘r’ Lib/ndimage/src/ni_fourier.c:402: error: ‘struct <anonymous>’ has no member named ‘i’ Lib/ndimage/src/ni_fourier.c: In function ‘NI_FourierShift’: Lib/ndimage/src/ni_fourier.c:441: warning: initialization makes pointer from integer without a cast Lib/ndimage/src/ni_fourier.c:497: warning: assignment makes pointer from integer without a cast Lib/ndimage/src/ni_fourier.c:498: warning: assignment makes pointer from integer without a cast Lib/ndimage/src/ni_fourier.c:524: error: ‘npy_complex32’ undeclared (first use in this function) Lib/ndimage/src/ni_fourier.c:524: error: syntax error before ‘)’ token Lib/ndimage/src/ni_fourier.c:524: error: syntax error before ‘)’ token Lib/ndimage/src/ni_fourier.c:524: error: syntax error before ‘)’ token Lib/ndimage/src/ni_fourier.c:524: error: syntax error before ‘)’ token Lib/ndimage/src/ni_fourier.c:525: error: ‘struct <anonymous>’ has no member named ‘r’ Lib/ndimage/src/ni_fourier.c:525: error: ‘struct <anonymous>’ has no member named ‘i’ Lib/ndimage/src/ni_fourier.c:525: error: ‘struct <anonymous>’ has no member named ‘r’ Lib/ndimage/src/ni_fourier.c:525: error: ‘struct <anonymous>’ has no member named ‘i’ Lib/ndimage/src/ni_fourier.c:531: error: syntax error before ‘)’ token Lib/ndimage/src/ni_fourier.c:531: error: syntax error before ‘)’ token Lib/ndimage/src/ni_fourier.c:532: error: ‘struct <anonymous>’ has no member named ‘r’ Lib/ndimage/src/ni_fourier.c:532: error: ‘struct <anonymous>’ has no member named ‘i’ error: Command "gcc -pthread -fno-strict-aliasing -DNDEBUG -O2 -fmessage-length=0 -Wall -D_FORTIFY_SOURCE=2 -g -fPIC -ILib/ndimage/src -I/usr/lib64/python2.4/site-packages/numpy/core/include -I/usr/lib64/python2.4/site-packages/numpy/core/include -I/usr/include/python2.4 -c Lib/ndimage/src/ni_fourier.c -o build/temp.linux-x86_64-2.4/Lib/ndimage/src/ni_fourier.o" failed with exit status 1 Nils

3 5