From hinsen@ibs.ibs.fr Tue Mar 3 09:41:20 1998 From: hinsen@ibs.ibs.fr (Konrad Hinsen) Date: Tue, 3 Mar 1998 10:41:20 +0100 Subject: [MATRIX-SIG] Inconsistent mod behaviour Message-ID: <199803030941.KAA18306@lmspc1.ibs.fr> A colleague made me aware of an inconsistency in the modulo operation for arrays and scalars: >>> from Numeric import * >>> -15%2 1 >>> array([-15])%2 array([-1]) Some further investigation shows that this is the result of different truncation rules for integer division, i.e. division and modulo are consistent in both cases: >>> -15/2 -8 >>> array(-15)/2 -7 Nevertheless, it is an annoying problem. However, it was not really introduced by NumPy. NumPy uses fmod() and therefore inherits its documented behaviour. The same is true for math.fmod and Numeric.fmod. I am not sure what to do about this. It seems reasonable to let arrays behave like scalars for consistency, but of course leave the explicit function fmod() as it is. Does anyone see a problem with that solution? Konrad. -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsen@ibs.ibs.fr Laboratoire de Dynamique Moleculaire | Tel.: +33-4.76.88.99.28 Institut de Biologie Structurale | Fax: +33-4.76.88.54.94 41, av. des Martyrs | Deutsch/Esperanto/English/ 38027 Grenoble Cedex 1, France | Nederlands/Francais ------------------------------------------------------------------------------- _______________ MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org _______________ From Paul F. Dubois" On ftp-icf.llnl.gov/pub/python there are two files: NumPy10.exe -- Windows 95/NT installer (MSVC 5.0) NumPy10.tgz -- Sources (NumPy/...) The Windows installer gives you a choice of binary or full install. The full install is needed only if you intend to make your own C extensions. Please see the file release_notes.txt for details. Guido-like, I hereby vanish until Tuesday. I rather expect problems, so I am announcing this only to the sig. This will give me a chance to get some feedback, make any necessary emergency repairs next week, and let CNRI get these two files mirrored in an appropriate place on python.org. I apologize apriori for the lack of full make/install support. That should be available next. Paul _______________ MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org _______________ From KaliazinA@cardiff.ac.uk Thu Mar 5 18:58:52 1998 From: KaliazinA@cardiff.ac.uk (Andrey Kaliazin) Date: Thu, 5 Mar 1998 18:58:52 -0000 Subject: [MATRIX-SIG] Numerical Python Release 1.0 Message-ID: <000c01bd4868$c980c4e0$8f16fb83@nedo.engin.cf.ac.uk> >On ftp-icf.llnl.gov/pub/python there are two files: > >NumPy10.exe -- Windows 95/NT installer (MSVC 5.0) >NumPy10.tgz -- Sources (NumPy/...) > >The Windows installer gives you a choice of binary or full install. The full >install is needed only if you intend to make your own C extensions. > >Please see the file release_notes.txt for details. > Just installed NumPy 1.0 release (binaries only) on my Win'95, and have problems: 1. Installation procedure do not update paths in registry; 2. Two files are missed - "FFt.py" and "RandomArray.py"; 3. Mlab.by still have wrong import (Numeric.Random) and reference (old?) - to Numeric.Random.random_sample() (when I replace them for RandomArray.random() it is Ok) 4. Why tests for LA, FFT, RANLIB are not included into test_all.py? 5. (optional) why diff() is not included into standard set of numeric functions? and maybe other common knowns as integ(), interp() and so on, from Yorick for example are also good candidates? Andy K. _______________ MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org _______________ From Paul F. Dubois" Thanks for the reports. Note that the release notes and one of the screens in the Windows installer specifically mention that this version does not do the installation into the path. You can just take the Lib/ and pyds/ contents and move them into your path. The reason is that I have to take the time to learn how to do that and I want to be sure I have it right before screwing up everyone's registry. Or worse, *my* registry. -----Original Message----- From: Andrey Kaliazin To: Paul F. Dubois ; matrix-sig Date: Thursday, March 05, 1998 11:00 AM Subject: Re: [MATRIX-SIG] Numerical Python Release 1.0 >>On ftp-icf.llnl.gov/pub/python there are two files: >> >>NumPy10.exe -- Windows 95/NT installer (MSVC 5.0) >>NumPy10.tgz -- Sources (NumPy/...) >> >>The Windows installer gives you a choice of binary or full install. >The full >>install is needed only if you intend to make your own C extensions. >> >>Please see the file release_notes.txt for details. >> > >Just installed NumPy 1.0 release (binaries only) on my Win'95, >and have problems: > >1. Installation procedure do not update paths in registry; >2. Two files are missed - "FFt.py" and "RandomArray.py"; >3. Mlab.by still have wrong import (Numeric.Random) and > reference (old?) - to Numeric.Random.random_sample() > (when I replace them for RandomArray.random() it is Ok) >4. Why tests for LA, FFT, RANLIB are not included into > test_all.py? > >5. (optional) why diff() is not included into standard set of >numeric functions? >and maybe other common knowns as integ(), interp() >and so on, from Yorick for example are also good candidates? > > >Andy K. > > > > > _______________ MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org _______________ From Paul F. Dubois" I added the two missing files and made the change requested to Mlab.py. Both Windows and tar files replaced (dated 3/5 instead of 3/4). I forgot to answer one of Mr. Kaliazin's questions: I will be working to get the rest of the LLNL stuff out as a separate package. Meantime, things like yorick.py are currently available in the file Current_distribution.tgz on ftp-icf.llnl.gov. -----Original Message----- From: Andrey Kaliazin To: Paul F. Dubois ; matrix-sig Date: Thursday, March 05, 1998 11:11 AM Subject: Re: [MATRIX-SIG] Numerical Python Release 1.0 >>On ftp-icf.llnl.gov/pub/python there are two files: >> >>NumPy10.exe -- Windows 95/NT installer (MSVC 5.0) >>NumPy10.tgz -- Sources (NumPy/...) >> >>The Windows installer gives you a choice of binary or full install. >The full >>install is needed only if you intend to make your own C extensions. >> >>Please see the file release_notes.txt for details. >> > >Just installed NumPy 1.0 release (binaries only) on my Win'95, >and have problems: > >1. Installation procedure do not update paths in registry; >2. Two files are missed - "FFt.py" and "RandomArray.py"; >3. Mlab.by still have wrong import (Numeric.Random) and > reference (old?) - to Numeric.Random.random_sample() > (when I replace them for RandomArray.random() it is Ok) >4. Why tests for LA, FFT, RANLIB are not included into > test_all.py? > >5. (optional) why diff() is not included into standard set of >numeric functions? >and maybe other common knowns as integ(), interp() >and so on, from Yorick for example are also good candidates? > > >Andy K. > > > > > >_______________ >MATRIX-SIG - SIG on Matrix Math for Python > >send messages to: matrix-sig@python.org >administrivia to: matrix-sig-request@python.org >_______________ > _______________ MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org _______________ From KaliazinA@cardiff.ac.uk Fri Mar 6 17:59:59 1998 From: KaliazinA@cardiff.ac.uk (Andrey Kaliazin) Date: Fri, 6 Mar 1998 17:59:59 -0000 Subject: [MATRIX-SIG] Fix to NumPy10 Message-ID: <005701bd4929$c5d99620$8f16fb83@nedo.engin.cf.ac.uk> >I forgot to answer one of Mr. Kaliazin's questions: I will be working to get >the rest of the LLNL stuff out as a separate package. Meantime, things like >yorick.py are currently available in the file Current_distribution.tgz on >ftp-icf.llnl.gov. > Thanks. Is there any files or pages having information (plans) on future development of NumPy? I'd like to to read what features are to be included in or excluded. That "TODO.TXT" file in distribution seems to be rather short :-), though Fortran direct support (at last) is a great idea! Look - another bug? (I use Win'95, Python 1.5, Numpy10) Maybe it is a supposed behaviour, but ... >>> r = arange(13) >>> r array([ 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12]) >>> ar=pow(10,r) ### ar=10**r produce the same >>> ar array([1, 10, 100,1000, 10000,100000, 1000000, 10000000, 100000000, 1000000000, 1410065408, 1215752192, -727379968]) How do you like it? I do not. never can be 10**10 =1410065408 of course, 10.0**r gives "right" result. Andy K. _______________ MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org _______________ From krodgers@tdyryan.com Fri Mar 6 20:32:56 1998 From: krodgers@tdyryan.com (Kevin Rodgers) Date: Fri, 06 Mar 1998 12:32:56 -0800 Subject: [MATRIX-SIG] Fix to NumPy10 In-Reply-To: <005701bd4929$c5d99620$8f16fb83@nedo.engin.cf.ac.uk> Message-ID: <3.0.1.32.19980306123256.00657da0@gate.tdyryan.com> At 05:59 PM 3/6/98 -0000, Andrey Kaliazin wrote: >Look - another bug? (I use Win'95, Python 1.5, Numpy10) >Maybe it is a supposed behaviour, but ... >>>> r = arange(13) >>>> r >array([ 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12]) >>>> ar=pow(10,r) >### ar=10**r produce the same >>>> ar >array([1, 10, 100,1000, 10000,100000, > 1000000, 10000000, 100000000, 1000000000, > 1410065408, 1215752192, -727379968]) > >How do you like it? I do not. >never can be 10**10 =1410065408 > >of course, 10.0**r gives "right" result. If you omit the "type" argument to array, it will pick the smallest type that all of the array elements will fit in, so in your case it picked 32-bit signed integer. 10**10 overflows a 32-bit signed integer . . . ---------------------------------------------------------------------- Kevin Rodgers Teledyne Ryan Aeronautical krodgers@tdyryan.com "This one goes up to eleven." -- Nigel Tufnel ---------------------------------------------------------------------- _______________ MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org _______________ From busby@icf.llnl.gov Fri Mar 6 21:09:01 1998 From: busby@icf.llnl.gov (L. Busby) Date: Fri, 6 Mar 98 13:09:01 PST Subject: [MATRIX-SIG] Fix to NumPy10 Message-ID: <9803062109.AA20612@icf.llnl.gov.llnl.gov> >Is there any files or pages having information (plans) on future >development of NumPy? I'd like to to read what features are to be >included in or excluded. That "TODO.TXT" file in distribution seems to >be rather short :-), though Fortran direct support (at last) is a great >idea! TODO.TXT is all there is for now. If it seems short to you, what else do you think should be there? I'm sure many of us would like to read what features are to be included or excluded, but that's really what this mailing list is for. >Look - another bug? (I use Win'95, Python 1.5, Numpy10) >Maybe it is a supposed behaviour, but ... >>>> r = arange(13) >>>> r >array([ 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12]) >>>> ar=pow(10,r) >### ar=10**r produce the same >>>> ar >array([1, 10, 100,1000, 10000,100000, > 1000000, 10000000, 100000000, 1000000000, > 1410065408, 1215752192, -727379968]) > >How do you like it? I do not. >never can be 10**10 =1410065408 > >of course, 10.0**r gives "right" result. > >Andy K. When item 4 of TODO is finished, you'll be able to turn on a signal handler for SIGFPE and catch the overflow you observed above. (Odd though it may seem, integer divide by zero and overflow will generate SIGFPE in most implementations.) For the moment, it's neither a bug nor a feature. Until Python itself was capable of handling SIGFPE, it was impossible to do much of anything about it in NumPy (unless you were willing to give up most of NumPy's speed advantage by checking all operands). Note that many of the functions in the Standard math library do check the domain and/or range of their arguments and/or results. (And they will set errno to EDOM or ERANGE if an error occurs.) That's the difference between fast_umath and umath modules. The first doesn't check the value of errno after each call to a library math function, the second does. This will trap some errors, but not integer exponentiation, as you discovered. _______________ MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org _______________ From KaliazinA@cardiff.ac.uk Fri Mar 6 22:22:37 1998 From: KaliazinA@cardiff.ac.uk (Andrey Kaliazin) Date: Fri, 6 Mar 1998 22:22:37 -0000 Subject: [MATRIX-SIG] Fix to NumPy10 Message-ID: <001e01bd494e$620f79a0$8f16fb83@nedo.engin.cf.ac.uk> > When item 4 of TODO is finished, you'll be able to turn on > a signal handler for SIGFPE and catch the overflow you > observed above. (Odd though it may seem, integer divide > by zero and overflow will generate SIGFPE in most > implementations.) For the moment, it's neither a bug > nor a feature. Until Python itself was capable of handling > SIGFPE, it was impossible to do much of anything about it > in NumPy (unless you were willing to give up most of NumPy's > speed advantage by checking all operands). > Sorry, if I was not clear enough. (my english still have to be improved :-( I just wanted to point out that pow() does not trap this error, being applied to array, while it do it's best with single value: >>> from Numeric import * >>> pow(10,array([10])) array([1410065408]) and >>> pow(10,10) Traceback (innermost last): File "", line 1, in ? OverflowError: integer pow() So, isn't it a bug? Looking in TODO list (item 2), I would like to suggest to implement "Inf" value (infinitive) additionally to a "NaN" . (MATLAB shows elegant way and semantic to handle both) Andy K. _______________ MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org _______________ From Dirk.Engelmann@iwr.uni-heidelberg.de Sun Mar 8 11:09:23 1998 From: Dirk.Engelmann@iwr.uni-heidelberg.de (Dirk Engelmann) Date: Sun, 8 Mar 1998 12:09:23 +0100 (CET) Subject: [MATRIX-SIG] spline with NumPy ? Message-ID: Hi! I'm interested in using spline interpolation. Actually I want to fit spline (with gaussian function) by a least square method to data points. If someone has done somthing with NumPy and spline, please let me know. Thanks! Cheers, Dirk Engelmann _______________ MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org _______________ From maz@pap.univie.ac.at Mon Mar 9 13:14:19 1998 From: maz@pap.univie.ac.at (Rupert Mazzucco) Date: Mon, 09 Mar 1998 14:14:19 +0100 (MET) Subject: [MATRIX-SIG] RNG module for WinNT? Message-ID: Is there a precompiled version of Konrad's RNG module for WinNT? Thank you. Regards, Rupert Mazzucco _______________ MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org _______________ From johann@leporello.berkeley.edu Tue Mar 10 02:48:54 1998 From: johann@leporello.berkeley.edu (Johann Hibschman) Date: Mon, 9 Mar 1998 18:48:54 -0800 Subject: [MATRIX-SIG] spline with NumPy ? In-Reply-To: (message from Dirk Engelmann on Sun, 8 Mar 1998 12:09:23 +0100 (CET)) Message-ID: <199803100248.SAA19051@leporello.Berkeley.EDU> > If someone has done somthing with NumPy and spline, please let me > know. > > Thanks! Hi, I have done a little work like that (very little). I don't know much about the constraints on the error of the approximation. I have made a Python version of the NR in C spline routines, with all the limitations and copyright issues of the original. It works well enough for small projects. Look at: http://astro.berkeley.edu/~johann/python/numpy.html Hope that helps, - Johann -- Johann Hibschman | Grad Student, UC Berkeley Astronomy johann@physics.berkeley.edu | http://astro.berkeley.edu/~johann _______________ MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org _______________ From pas@xis.xerox.com Tue Mar 10 15:05:08 1998 From: pas@xis.xerox.com (Perry Stoll) Date: Tue, 10 Mar 1998 07:05:08 PST Subject: [MATRIX-SIG] RNG module for WinNT? Message-ID: <003201bd4c35$ea7e5f10$4a4df60d@stoll-pc.xis.xerox.com> I have one. I don't have any place to post it on the web currently - would anyone be interested/willing to host it? Dave? Paul? In the mean time, I can send you the dll if you like. Drop me a line. -Perry -----Original Message----- Is there a precompiled version of Konrad's RNG module for WinNT? Thank you. Regards, Rupert Mazzucco _______________ MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org _______________ _______________ MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org _______________ From lorenzo@argon.roma2.infn.it Wed Mar 11 19:01:31 1998 From: lorenzo@argon.roma2.infn.it (Lorenzo M. Catucci) Date: Wed, 11 Mar 1998 20:01:31 +0100 (CET) Subject: [MATRIX-SIG] NumPy external library wrapping help Message-ID: First, I'm to beg your pardon if this comes out to be a double post; I tried yesterday via findmail, but haven't seen anything till now... Now, the questions: I'd like to wrap a couple of PORT least sqares routines for use within Python's numeric framework, and therefore I'll need to do a couple of things: 1. make fortran arrays - seems simple: make C ones, and then access them `backwards' (read, via transposed indexes). The only problem will be the malloc/free one. 2. Put in callback support - this is what I fear: on one hand, I'll need to be able to call the python interpreter, then I'll have to validate the called functions for output format and the like, and further make sure the environment the callbacks will be executed in is the right one (what happens if the user calls for `sin(x)'?) Can please someone come out with a couple of guidelines? I can then promise n e a r t o e t h e r n a l gratitude... Yours, lorenzo _______________ MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org _______________ From johann@physics.berkeley.edu Wed Mar 11 23:29:23 1998 From: johann@physics.berkeley.edu (Johann Hibschman) Date: Wed, 11 Mar 1998 15:29:23 -0800 Subject: [MATRIX-SIG] NumPy external library wrapping help In-Reply-To: (lorenzo@argon.roma2.infn.it) Message-ID: <199803112329.PAA21352@leporello.Berkeley.EDU> "Lorenzo M. Catucci" wrote: > > Now, the questions: I'd like to wrap a couple of PORT least sqares > routines for use within Python's numeric framework, and therefore I'll > need to do a couple of things: > 1. make fortran arrays - seems simple: make C ones, and then access them > `backwards' (read, via transposed indexes). The only problem will be > the malloc/free one. Have you tried looking at modules like lapack_litemodule.c in the distribution? They should give some examples. > 2. Put in callback support - this is what I fear: on one hand, I'll need > to be able to call the python interpreter, then I'll have to validate > the called functions for output format and the like, and further make > sure the environment the callbacks will be executed in is the right one > (what happens if the user calls for `sin(x)'?) This is tougher. I haven't actually done this, but I have a few ideas. The most obvious thing you could do is make a "trampoline" function like: /* I forget all the actual python function calls---you'll have to check the documentation. I tend to use Mark Lutz's Programming Python book as a ref. */ /* global pointer to put the python object into: make this a python LIST, so you can store multiple functions (use the list as a stack) */ PyObject *foo_function_list; static double foo_trampoline(double x) { [convert x into a PyObject => py_x]; [get foo_function_list[0] => py_function] /* first item on stack */ [call py_function on py_x => py_answer]; [convert py_answer into a double => answer]; return answer; } static PyObject *wrap_foo(...) { [extract the python function object py_function to be passed to C]; /* set the global pointer */ [append py_function to foo_function_list (push onto stack)] /* pass the C (or fortran) routine the trampoline function */ answer = foo(foo_trampoline, ...); [pop py_function off foo_function_list] [convert answer to c => py_answer] return py_answer; } I hope that helps with the idea at least; I can't provide more details at this point. Calling the python function is likely to be slow slow slow, which is why I've never actually done this. If you get it running, I'd like to hear about how the performance is. I'd like to hear what anyone else thinks about this. - Johann -- Johann Hibschman | Grad Student, UC Berkeley Astronomy johann@physics.berkeley.edu | http://astro.berkeley.edu/~johann _______________ MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org _______________ From dheister@jaguar1.usouthal.edu Thu Mar 12 02:20:56 1998 From: dheister@jaguar1.usouthal.edu (Douglas R. Heisterkamp) Date: Wed, 11 Mar 1998 20:20:56 -0600 (CST) Subject: [MATRIX-SIG] NumPy external library wrapping help In-Reply-To: <199803112329.PAA21352@leporello.Berkeley.EDU> Message-ID: On Wed, 11 Mar 1998, Johann Hibschman wrote: > I hope that helps with the idea at least; I can't provide more details > at this point. > > Calling the python function is likely to be slow slow slow, which is > why I've never actually done this. If you get it running, I'd like to > hear about how the performance is. > > I'd like to hear what anyone else thinks about this. If you would like to see an old try at it, look at ftp://ftp.cse.unl.edu/pub/drh/python/drhfn.tar.gz I never released the code, because I could see many better ways of doing it. But I never had enough of a need to actually spend the time try the other approaches. An example is include of using either a python or a Fortran function as a callback in ODRPACK. This worked with 1.4. I have not tried it with 1.5. Doug Heisterkamp drh@cis.usouthal.edu _______________ MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org _______________ From Paul F. Dubois" Numerical Python release 1.1 is now on ftp-icf.llnl.gov/pub/python. NumPy-11.exe is a Windows 95/NT installer. It gives you a choice of runtime-only or complete installation. It adjusts the registry entries so that Python will be able to able to find the new modules. NumPy-11.tgz is a tarred and gzipped archive. It also contains the sources for the Arrayfcns package which is something we might move into the Numerical package at some point if people like it. A new technology, the joint work of Konrad Hinsen and David Ascher, allows even dummies to make from source on Unix or Windows/Microsoft Visual C++. Naturally, there will be somebody's system out there for which it doesn't work. Let us know. This version was tested on Winodws with MSVC 5.0 + Visual Dev Studio Service Pack 3. CNRI, you can set up pointers to this stuff on www.python.org and then announce it. _______________ MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org _______________ From David.Buscher@durham.ac.uk Thu Mar 12 20:19:37 1998 From: David.Buscher@durham.ac.uk (David Buscher) Date: Thu, 12 Mar 1998 20:19:37 +0000 (GMT) Subject: [MATRIX-SIG] real_fft Message-ID: There appears to be an off-by-one error in the real_fft() function in the FFT module. The following is the output from a python session, with spacing inserted for clarity: Python 1.5 (#1, Mar 10 1998, 16:43:31) [GCC 2.7.2] on sunos5 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> from Numeric import * >>> from FFT import * >>> fft([1,0,0,0]) array([ 1.+0.j, 1.+0.j, 1.+0.j, 1.+0.j]) >>> real_fft([1,0,0,0]) array([ 0.+0.j, 0.+0.j, 0.+0.j]) >>> real_fft([1,1,0,0]) array([ 1.+0.j, 1.+0.j, 1.+0.j]) >>> real_fft([0,1,0,0]) array([ 1.+0.j, 1.+0.j, 1.+0.j]) The first expression is just to check that the fft() function works as expected. Note that the last two expressions show that the real_fft() function is ignoring the first element of the array. Does anyone else see this happening, or is it just a function of my installation? Or do I not understand what the real_fft() function is supposed to do? I am using python-1.5 with Konrad Hinsen's numpy.tar.gz. David ----------------------------------------+------------------------------------- David Buscher | Phone +44 191 374 7462 Dept of Physics, University of Durham, | Fax +44 191 374 3709 South Road, Durham DH1 3LE, UK | Email david.buscher@durham.ac.uk ----------------------------------------+------------------------------------- _______________ MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org _______________ From singer@itl.atr.co.jp Thu Mar 12 07:19:57 1998 From: singer@itl.atr.co.jp (Harald Singer) Date: Thu, 12 Mar 1998 16:19:57 +0900 Subject: [MATRIX-SIG] [Q] default NumPy installation Message-ID: <3504E99D.AE9E90ED@itl.atr.co.jp> Hi, I just downloaded NumPy-11.tgz [1] documentation is out of date the compile instructions in Numerical don't fit the distribution. [2] release naming incosistency NumPy10.tgz NumPy-11.tgz [3] What is the "preferred way" of installing NumPy in a multi-machine environment? (Linux, OSF1, HP-UX, etc) Just following the "new procedure", I did python makethis.py make install bash$ ls /usr/local/lib/python1.5/site-packages fast_umathmodule.so lapack_lite.so ranlib.so _numpymodule.so fftpack.so multiarraymodule.so umathmodule.so Where should I install the files in NumPy/Lib? I could cp -r Lib /usr/local/lib/python1.5/NumPy and then export PYTHONPATH=$PYTHONPATH:/usr/local/lib/python1.5/NumPy but somehow I don't like this too much, because it might clash with what individual users do with their PYTHONPATH variable. Another solution is to change Setup.in (or Setup???) from # Site specific path components -- should begin with : if non-empty SITEPATH= to # Site specific path components -- should begin with : if non-empty SITEPATH=:Imaging:NumPy -- Harald Singer, ATR ITL, tel +81-7749-5-1389 singer@itl.atr.co.jp _______________ MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org _______________ From bsd@scripps.edu Fri Mar 13 09:23:37 1998 From: bsd@scripps.edu (Bruce Duncan) Date: Fri, 13 Mar 1998 01:23:37 -0800 (PST) Subject: [MATRIX-SIG] UserArray.py problems Message-ID: <199803130923.BAA12203@riscfs2.scripps.edu> Greetings, UserArray.py seems to have some problems: 1) The constructor tries to set a "name" attribute which fails if the input data is an array. 2) The __setitem__ method doesn't work if the item is NOT an array; in this case the asarray call seems to fail. I've also seen some other strange failures. UserArray would be a good class to have working correctly. I find that the standard python classes UserDict and UserList help quite a bit. Does anyone use this class? How well does it work?? -bsd- _______________ MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org _______________ From hinsen@ibs.ibs.fr Fri Mar 13 16:41:16 1998 From: hinsen@ibs.ibs.fr (Konrad Hinsen) Date: Fri, 13 Mar 1998 17:41:16 +0100 Subject: [MATRIX-SIG] [Q] default NumPy installation In-Reply-To: <3504E99D.AE9E90ED@itl.atr.co.jp> (message from Harald Singer on Thu, 12 Mar 1998 16:19:57 +0900) Message-ID: <199803131641.RAA16162@lmspc1.ibs.fr> > [3] > What is the "preferred way" of installing NumPy in a multi-machine > environment? (Linux, OSF1, HP-UX, etc) > > Just following the "new procedure", I did > python makethis.py > make install > > bash$ ls /usr/local/lib/python1.5/site-packages > fast_umathmodule.so lapack_lite.so ranlib.so > _numpymodule.so fftpack.so multiarraymodule.so umathmodule.so > > Where should I install the files in NumPy/Lib? I could > cp -r Lib /usr/local/lib/python1.5/NumPy > and then > export PYTHONPATH=$PYTHONPATH:/usr/local/lib/python1.5/NumPy > but somehow I don't like this too much, because it might clash > with what individual users do with their PYTHONPATH variable. I always add the NumPy to the standard library path. That does create a problem when you try to figure out what modules comes from where, but it ensures access from everywhere, assuming the original Python installation was working. -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsen@ibs.ibs.fr Laboratoire de Dynamique Moleculaire | Tel.: +33-4.76.88.99.28 Institut de Biologie Structurale | Fax: +33-4.76.88.54.94 41, av. des Martyrs | Deutsch/Esperanto/English/ 38027 Grenoble Cedex 1, France | Nederlands/Francais ------------------------------------------------------------------------------- _______________ MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org _______________ From Paul F. Dubois" I'll answer these to the sig because they may be of more general interest. -----Original Message----- From: Harald Singer To: matrix-sig@python.org Cc: riwa@itl.atr.co.jp Date: Thursday, March 12, 1998 7:22 PM Subject: [MATRIX-SIG] [Q] default NumPy installation >Hi, > >I just downloaded NumPy-11.tgz > >[1] documentation is out of date >the compile instructions in Numerical don't fit the distribution. The compile instructions are in the top-level README.htm. I didn't realize there were compile instructions in the Doc subdirectory; I'll remove them. > > >[2] release naming incosistency > NumPy10.tgz > NumPy-11.tgz I changed my mind. > >[3] >What is the "preferred way" of installing NumPy in a multi-machine >environment? (Linux, OSF1, HP-UX, etc) > >Just following the "new procedure", I did > python makethis.py > make install The documentation points out that at this point there is no support for the installation; it is up to you to copy the .so's to where you want them, and likewise the Lib/*. On Windows no "install" is required. Obviously this isn't a good thing, but please be patient as I have an actual job. Obviously Konrad and David must have done something close to correct for Unix but I haven't had a chance to look at this part at all. Apparently make install does part of the job, so that's good. Konrad had an "install.py" to parallel "compile.py". What we want to do is make this work on all the different packages that are going to be in the distribution. There are quite a few already and it is going to get worse. One question we've been kicking around is what form the installation should take...Use the new package stuff? If we do that some existing import statements will need fixing, but we might all be happier in the long run. > >bash$ ls /usr/local/lib/python1.5/site-packages >fast_umathmodule.so lapack_lite.so ranlib.so >_numpymodule.so fftpack.so multiarraymodule.so umathmodule.so > >Where should I install the files in NumPy/Lib? I could > cp -r Lib /usr/local/lib/python1.5/NumPy >and then > export PYTHONPATH=$PYTHONPATH:/usr/local/lib/python1.5/NumPy >but somehow I don't like this too much, because it might clash >with what individual users do with their PYTHONPATH variable. > >Another solution is to change Setup.in (or Setup???) from > # Site specific path components -- should begin with : if non-empty > SITEPATH= >to > # Site specific path components -- should begin with : if non-empty > SITEPATH=:Imaging:NumPy >-- >Harald Singer, ATR ITL, tel +81-7749-5-1389 singer@itl.atr.co.jp > > > > >_______________ >MATRIX-SIG - SIG on Matrix Math for Python > >send messages to: matrix-sig@python.org >administrivia to: matrix-sig-request@python.org >_______________ > _______________ MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org _______________ From Paul F. Dubois" I'll fix this when I get a chance. I'm unfamiliar with the file but it looks like something simple. -----Original Message----- From: Perry Stoll To: Paul F. Dubois Date: Thursday, March 12, 1998 12:54 PM Subject: Re: [MATRIX-SIG] NumPy-11 >>Numerical Python release 1.1 is now on ftp-icf.llnl.gov/pub/python. > >Glad to hear that. > >What is the status of MLab? Should it just be removed, since no one could >possibly be using it? > > >-Perry > >>>> import MLab >>>> MLab.rand(1) >Traceback (innermost last): > File "", line 0, in ? > File "D:\Python\Python-1.5\NumPy\Lib\MLab.py", line 22, in rand > return RandomArray.random_sample(args) >AttributeError: random_sample >>>> > > > > _______________ MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org _______________ From jhauser@ifm.uni-kiel.de Fri Mar 13 19:27:53 1998 From: jhauser@ifm.uni-kiel.de (Janko Hauser) Date: Fri, 13 Mar 1998 20:27:53 +0100 (CET) Subject: [MATRIX-SIG] UserArray.py problems In-Reply-To: <199803130923.BAA12203@riscfs2.scripps.edu> References: <199803130923.BAA12203@riscfs2.scripps.edu> Message-ID: There is a better (more consistent) version at the starship site of Timothy Hochberg and also another class which use UserArray. But be warned, that the class in its current intention is not really generally appliciable, because functions need to now that they are dealing with a userarray, if they should return a userarray. For me it is questionable, if a function should return a userarray. If something should look to the outside as an array, why should the result be something else. Timothy tries to solve this with shadowclasses. But one ends with a mixture of functions which return an userarray and some which not. In the mentioned UserList and UserDict, there are only very special methods, which return a UserDict, and most handling with dicts and lists is done with methods. This is not the case in NumPy. So, I think the list should decide, if a ``replicating'' UserArray is needed, than the UserArray class together with the shadow classes of Timothy should be incorporated in the distribution, or a simpler one which returns an array normaly (not in the case of slicing or typeconversion). __Janko _______________ MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org _______________ From Paul F. Dubois" Distributions available on ftp-icf.llnl.gov/pub/python: NumPy-11.tgz (Source for NumPy, tar.gz format) NumPy-11.EXE (Windows runtime/source installer) RNG-11.tgz (Source for RNG package, tar.gz format; requires NumPy) RNG-11.EXE (Windows runtime source installer) RNG is Perry Stoll's ANSI-fication and Windowsization of Konrad Hinsen's extension of my URNG package. The URNG package is deprecated; users should switch to RNG. RNG/Demo/RNGDemo.py is now doing double-duty as a mild test routine for the uniform and normal distributions. If someone would expand it to test the exponential distribution that would be great. Generators can be created so as to use an allegedly random seed. While this uses microsecond clocks on Unix and is pretty trustworthy, such fine accuracy is not available in the ANSI standard routines so for windows I kludged together something using both clock() and time(). I have not measured the independence of the streams if you create them rapidly one after the other on Windows. I would recommend wasting some time between such creations. The generator in RNG is the same algorithm used by Cray's ranf() routine. My suggestion to the community is that we dump the ranlib package currently in NumPy and all use RNG. _______________ MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org _______________ From jhauser@ifm.uni-kiel.de Sat Mar 14 13:35:20 1998 From: jhauser@ifm.uni-kiel.de (Janko Hauser) Date: Sat, 14 Mar 1998 14:35:20 +0100 (CET) Subject: [MATRIX-SIG] Simple UserArray and isarray() Message-ID: So here is a UserArray class which noirmaly returns an array, only the slicing and inplace changing methods return an UserArray. I need to change asarray from Numeric.py to deal with this class or subclasses of this. The other functions should treat this as an array. There is also an isarray() function which can handle UserArrays. This is only to show the other possibility. And then there is a small typo in Timothy's UserArray at line 205: The line: return arg_class(self.ufunc(a), a, b) should be: return arg_class(self.ufunc(a), a) and another one at line 13: self.__dict__['name'] = string.split(str(self.__class__))[1] should be: self.__dict__['name'] = string.split(str(self.__class__),'.')[-1] with regards, __Janko ### Simple UserArray #!/usr/local/bin/python from Numeric import * import string import copy class UserArray: def __init__(self, data, typecode=None, copy=0): if typecode == None: self.array = array(data,copy=copy) else: self.array = array(data, typecode, copy) self.__dict__['shape'] = self.array.shape self.name = string.split(str(self.__class__),'.')[-1] def __setattr__(self,att,value): # perhaps the name attribute should also be shielded if att == 'shape': self.__dict__['shape']=value self.array.shape=value else: # This is normal class behavior self.__dict__[att]=value # As this is questionable, one can choose this # raise AttributeError, "Attribute cannot be set" def __repr__(self): return self.name+"\n"+str(self.array) def __array__(self, typec = 0, copy = 1): if typec: stype = typec else: stype = self.typecode() if copy: return self.array # this returns only the array else: return self._rc(self.array, stype) # this returns only the array #return self._rc(self.array, typecode=stype) # If array is used as a sequence def __len__(self): return len(self.array) def __getitem__(self, index): return self._rc(self.array[index]) def __getslice__(self, i, j): return self._rc(self.array[i:j]) def __float__(self): return self._rc(self.array.astype(Float)) def __int__(self): return self._rc(self.array.astype(Int)) def __setitem__(self, index, value): self.array[index] = masarray(value, self.typecode())[...] def __setslice__(self, i, j, value): self.array[i:j] = masarray(value, self.typecode())[...] def __del__(self): for att in dir(self): delattr(self, att) del(self) # These are changing the values, so make arrays def __abs__(self): return absolute(self.array) def __neg__(self): return -self.array def __add__(self, other): return self.array+masarray(other) __radd__ = __add__ def __sub__(self, other): return self.array-masarray(other) def __rsub__(self, other): return masarray(other)-self.array def __mul__(self, other): return multiply(self.array, masarray(other)) __rmul__ = __mul__ def __div__(self, other): return divide(self.array,masarray(other)) def __rdiv__(self, other): return divide(masarray(other),self.array) def __pow__(self,other): return power(self.array,masarray(other)) def __rpow__(self,other): return power(masarray(other),self.array) def __sqrt__(self): return sqrt(self.array) def tostring(self): return self.array.tostring() def byteswapped(self): return self._rc(self.array.byteswapped()) def asType(self, typecode): return self._rc(self.array.asType(typecode)) def typecode(self): return self.array.typecode() def itemsize(self): return self.array.itemsize() def isContiguous(self): return self.array.isContiguous() UserArray._rc=UserArray def masarray(a, typecode=None): """ If a is an array of the right type return a, else build a new array. """ if typecode == None: if isarray(a): return a else: return array(a) else: if isarray(a): if a.typecode() == typecode: return a else: return a.astype(typecode) # this is actually a copy else: return array(a, typecode) # this also def isarray(a): """ Test for arrayobjects. Can also handle UserArray instances """ try: sh = list(a.shape) except AttributeError: return 0 try: sh[0] = sh[0]+1 a.shape = sh except ValueError: return 1 except IndexError: return 1 # ? this is a scalar array return 0 def st(line,comment=''): import __main__ print '>>> '+line+' #'+comment exec line in __main__.__dict__,__main__.__dict__ def test(): st('a=UserArray(arange(9))') st('a.shape=(3,3)') st('b=a','This should be without copy') st('b[0,:]=array([1,2,2])') st('print b;print a','Two refs to the same object') st('d=array(a)','This should produce a new array') st('dd=masarray(a)','No copy but a new UserArray') st('print type(d); print type(dd)') st('d=sin(a);print d;print type(d)') st('print less(a,2)') st('d=where(less(a,3),10,0); print d; print type(d)') st('a[0,0]=1; print a') st('a[0,1]=array(10); print a') st('print repeat(a[NewAxis,:,:],(3,))') st('print concatenate((a,a))') ############################################################# # Test of class UserArray ############################################################# if __name__ == '__main__': test() _______________ MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org _______________ From jhauser@ifm.uni-kiel.de Mon Mar 16 23:00:20 1998 From: jhauser@ifm.uni-kiel.de (Janko Hauser) Date: Tue, 17 Mar 1998 00:00:20 +0100 (CET) Subject: [MATRIX-SIG] two possible bugs? Message-ID: Hello, during some tests of UserArray I have found these oddities: >>> a=reshape(arange(9),(3,3)) >>> repeat(a,(2,)) zsh: 13051 segmentation fault python -i /home/hauser/SYNC/.python/Startup.py ~@sines >py >>> a=reshape(arange(9),(3,3)) >>> repeat(a[NewAxis,:,:],(2,)) array([[[0, 1, 2], [3, 4, 5], [6, 7, 8]], [[0, 1, 2], [3, 4, 5], [6, 7, 8]]]) >>> (repeat(a[NewAxis,:,:],(2,))).shape (2, 3, 3) This is with a Python and NumPy from the LLNL source tree on Linux(libc6). Is this also the case on other platforms? And then something I don't understand: >>> a=array(10) >>> a.shape () >>> a[0] 10 >>> b=array([10]) >>> b.shape (1,) >>> b[0] 10 >>> a[-1] Traceback (innermost last): File "", line 1, in ? IndexError: index out of bounds >>> b[-1] 10 Shouldn't a and b not be the same? __Janko _______________ MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org _______________ From klm@python.org Tue Mar 17 02:26:50 1998 From: klm@python.org (Ken Manheimer) Date: Mon, 16 Mar 1998 21:26:50 -0500 (EST) Subject: [Matrix-SIG] Testing transition to mailman list processor Message-ID: <199803170226.VAA11900@glyph.CNRI.Reston.Va.US> The Matrix-SIG mailing list has just been migrated to mailman, a python-based maillist management system. Subscribers should have received a "welcome" message with information about accessing your membership account. In summary, the crucial piece of information is to visit: http://www.python.org/mailman/listinfo/objc-sig for the introductory page - you should be able to find your account from there. In any case, postings to the maillist itself should work pretty much as they did before. If you have questions, feel free to contact me... Thanks! Ken Manheimer klm@python.org 703 620-8990 x268 (orporation for National Research |nitiatives # If you appreciate Python, consider joining the PSA! # # . # From klm@python.org Tue Mar 17 02:46:59 1998 From: klm@python.org (Ken Manheimer) Date: Mon, 16 Mar 1998 21:46:59 -0500 (EST) Subject: [Matrix-SIG] Re: Testing transition to mailman list processor Message-ID: <199803170246.VAA12051@glyph.CNRI.Reston.Va.US> Whoops - sending out multiple copies of the test message, i failed to modify everything that i was supposed to from one copy to the next - in particular: > about accessing your membership account. In summary, the crucial > piece of information is to visit: > > http://www.python.org/mailman/listinfo/objc-sig the URL should be: http://www.python.org/mailman/listinfo/matrix-sig (as you might expect!-) Ken From hinsen@ibs.ibs.fr Tue Mar 17 18:03:47 1998 From: hinsen@ibs.ibs.fr (Konrad Hinsen) Date: Tue, 17 Mar 1998 19:03:47 +0100 Subject: [MATRIX-SIG] two possible bugs? In-Reply-To: (message from Janko Hauser on Tue, 17 Mar 1998 00:00:20 +0100 (CET)) Message-ID: <199803171803.TAA06952@lmspc1.ibs.fr> > And then something I don't understand: > > >>> a=array(10) > >>> a.shape > () > >>> a[0] > 10 > >>> b=array([10]) > >>> b.shape > (1,) > >>> b[0] > 10 > >>> a[-1] > Traceback (innermost last): > File "", line 1, in ? > IndexError: index out of bounds > >>> b[-1] > 10 > > Shouldn't a and b not be the same? No. Your first example (array(10)) is a bit special. It represents an array of rank zero, which is equivalent to a scalar. In fact, any computation would return a scalar and never an array of rank zero; the possibility to create a rank 0 object exists only because some code might insist on receiving an array object under all circumstances. There was some discussion about this a long time ago on the Matrix SIG. Note also that a[0] should *in principle* raise an exception, because the number of indices exceeds the rank. However, that would leave no way at all to extract a "real" scalar from a rank 0 array object, therefore the rules are "bent" a bit. Moral: don't create rank 0 arrays unless you know very well what you are doing. -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsen@ibs.ibs.fr Laboratoire de Dynamique Moleculaire | Tel.: +33-4.76.88.99.28 Institut de Biologie Structurale | Fax: +33-4.76.88.54.94 41, av. des Martyrs | Deutsch/Esperanto/English/ 38027 Grenoble Cedex 1, France | Nederlands/Francais ------------------------------------------------------------------------------- From pas@xis.xerox.com Tue Mar 17 20:31:51 1998 From: pas@xis.xerox.com (Perry Stoll) Date: Tue, 17 Mar 1998 12:31:51 PST Subject: [Matrix-SIG] bug in Numeric.diagonal? Message-ID: <001e01bd51e3$b7aa9dc0$4a4df60d@stoll-pc.xis.xerox.com> Looking through Numeric, I noticed what looks like a bug in diagonal. Can anyone confirm this as a bug? (I'd be happier if someone who understands higher dimensional diagonals tested this). def diagonal(a, offset=0, axis1=-2, axis2=-1): if axis1 != -2: a = swapaxes(a, axis1, -2) if axis2 != -1: a = swapaxes(a, axis2, -1) s = __diagonal(a, offset) if axis1 != -2: s = swapaxes(s, axis1, -2) if axis2 != -1: s = swapaxes(a, axis2, -1) <<-- replace a with s? return s -Perry From hinsen@ibs.ibs.fr Wed Mar 18 16:18:42 1998 From: hinsen@ibs.ibs.fr (Konrad Hinsen) Date: Wed, 18 Mar 1998 17:18:42 +0100 Subject: [Matrix-SIG] bug in Numeric.diagonal? In-Reply-To: <001e01bd51e3$b7aa9dc0$4a4df60d@stoll-pc.xis.xerox.com> (pas@xis.xerox.com) Message-ID: <199803181618.RAA12119@lmspc1.ibs.fr> > Looking through Numeric, I noticed what looks like a bug in diagonal. Can > anyone confirm this as a bug? (I'd be happier if someone who understands > higher dimensional diagonals tested this). > > def diagonal(a, offset=0, axis1=-2, axis2=-1): > if axis1 != -2: a = swapaxes(a, axis1, -2) > if axis2 != -1: a = swapaxes(a, axis2, -1) > s = __diagonal(a, offset) > if axis1 != -2: s = swapaxes(s, axis1, -2) > if axis2 != -1: s = swapaxes(a, axis2, -1) <<-- replace a with s? > return s You are right, that should be s. How could this ever work? Well, it works well for 2D arrays, which is the most important case... -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsen@ibs.ibs.fr Laboratoire de Dynamique Moleculaire | Tel.: +33-4.76.88.99.28 Institut de Biologie Structurale | Fax: +33-4.76.88.54.94 41, av. des Martyrs | Deutsch/Esperanto/English/ 38027 Grenoble Cedex 1, France | Nederlands/Francais ------------------------------------------------------------------------------- From da@skivs.ski.org Wed Mar 18 18:17:55 1998 From: da@skivs.ski.org (David Ascher) Date: Wed, 18 Mar 1998 10:17:55 -0800 (PST) Subject: [Matrix-SIG] bug in Numeric.diagonal? In-Reply-To: <199803181618.RAA12119@lmspc1.ibs.fr> Message-ID: > You are right, that should be s. How could this ever work? > Well, it works well for 2D arrays, which is the most important case... But only for small offsets. diagonal(abs(offset)>1) never worked, as far as I remember. Anyone have a patch? --david From pcj+NOSPAM@primenet.com Thu Mar 19 05:43:20 1998 From: pcj+NOSPAM@primenet.com (pcj+NOSPAM@primenet.com) Date: 18 Mar 1998 21:43:20 -0800 Subject: [Matrix-SIG] Re: [PYTHON MATRIX-SIG] FFT In-Reply-To: Jim Hugunin's message of "Fri, 7 Mar 1997 11:04:01 -0500" References: <01BC2AE7.43D84470@misha.lcs.mit.edu> Message-ID: A really, really long time ago, Jim Hugunin wrote: > real_fft returns the left half of the fft of a real array (the fft of a > real array is conjugate symmetric, so only half of it is needed). Except it doesn't. fftpackmodule.c needs this patch: *** fftpackmodule.c~ Fri Mar 21 13:10:00 1997 --- fftpackmodule.c Tue Mar 17 22:25:00 1998 *************** *** 132,138 **** dptr = (double *)data->data; for (i=0; idata; for (i=0; i inverse_real_fft is not the inverse function of real_fft, but it instead > returns the left half of the inverse fft of a real valued vector. This > naming convention is from fftpack, and I don't think it's bad enough to > fix. This is not my understanding of fftpack's "real backwards" routine. (Admittedly the documentation is a little misleading.) rfftb takes an array of the left half of the real and imaginary components of the fourier transform of a real sequence (in the same format as the output of rfftf), and returns the real sequence. May I suggest instead the following semantics for inverse_real_fft: - accepts a complex sequence, assumed to be the left half of a conjugate symmetric sequence - returns a real sequence of length 2n-2 if the imaginary part of the last value is equal to 0 and length 2n-1 otherwise. This implementation would have the (IMHO desirable) property that inverse_real_fft(real_fft(seq)) would in general equal seq. My only concern is that if the imaginary part of the last point was not precisely zero (due to roundoff error), you could get a sequence one longer than the input. Offhand, I can't think of a robust algorithm to decide if imag(seq[n]) was sufficently close to 0 to shorten the returned sequence by 1. -- Paul C. Janzen Research is what I'm doing when I http://www.acs.psu.edu/users/pcj don't know what I'm doing. - Wernher von Braun From dars@soton.ac.uk Thu Mar 19 11:28:57 1998 From: dars@soton.ac.uk (Dave Stinchcombe) Date: Thu, 19 Mar 1998 11:28:57 +0000 (GMT) Subject: [Matrix-SIG] Power of trigs Message-ID: <199803191128.LAA24519@oak.sucs.soton.ac.uk> Hi again, This morning I needed to write a quick and easy root finder, so obviously I grabbed Numeric Python. I have a problem though. I wrote the line: Numeric.power(Numeric.cos(phi),1-2*nus) where nus is a constant of 0.3. phi is an array holding a list of values I'm searching through. The problem comes that this line fails when phi is greater than pi/2. Now obviously this is due to the fact I'm trying to calculate a complex (or at the very least an imaginary) number. But I want to. Can any one give some suggestions as to how to cope, or in some way make python also believe in complex numbers. Yours Dave From hochberg@wwa.com Thu Mar 19 15:17:08 1998 From: hochberg@wwa.com (Tim Hochberg) Date: Thu, 19 Mar 1998 09:17:08 -0600 Subject: [Matrix-SIG] Power of trigs Message-ID: <003e01bd534a$185a5360$a53cf1cf@oemcomputer> From: Dave Stinchcombe >Hi again, >This morning I needed to write a quick and easy root finder, so obviously I >grabbed Numeric Python. > >I have a problem though. I wrote the line: >Numeric.power(Numeric.cos(phi),1-2*nus) > >where nus is a constant of 0.3. phi is an array holding a list of values >I'm searching through. The problem comes that this line fails when phi is >greater than pi/2. > >Now obviously this is due to the fact I'm trying to calculate a complex (or >at the very least an imaginary) number. But I want to. Can any one give >some suggestions as to how to cope, or in some way make python also believe >in complex numbers. Power will return complex numbers if one of the arguments is complex, otherwise it assumes you want a real answer and raises an exception. Two things that should work to convince power that you mean business are: power(cos(phi)+0j, 1-2*nus) power(cos(phi).astype(Complex), 1-2*nus) ____ /im From Paul F. Dubois" Complex literals are of the form n.nnnn j. In this case, Numeric needs you to help it know that you want a complex power. >>> import Numeric >>> Numeric.power(2., .5) 1.41421356237 >>> Numeric.power(-2.0, .5) Traceback (innermost last): File "", line 1, in ? ValueError: math domain error >>> Numeric.power(-2.0+0j, .5) (8.65927457072e-017+1.41421356237j) >>> -----Original Message----- From: Dave Stinchcombe To: matrix-sig@python.org Date: Thursday, March 19, 1998 3:48 AM Subject: [Matrix-SIG] Power of trigs >Hi again, >This morning I needed to write a quick and easy root finder, so obviously I >grabbed Numeric Python. > >I have a problem though. I wrote the line: >Numeric.power(Numeric.cos(phi),1-2*nus) > >where nus is a constant of 0.3. phi is an array holding a list of values >I'm searching through. The problem comes that this line fails when phi is >greater than pi/2. > >Now obviously this is due to the fact I'm trying to calculate a complex (or >at the very least an imaginary) number. But I want to. Can any one give >some suggestions as to how to cope, or in some way make python also believe >in complex numbers. > >Yours >Dave > > > >------------------------------------------------------ >Matrix-SIG maillist - Matrix-SIG@python.org >http://www.python.org/mailman/listinfo/matrix-sig > From KaliazinA@cardiff.ac.uk Thu Mar 19 15:32:25 1998 From: KaliazinA@cardiff.ac.uk (Andrey Kaliazin) Date: Thu, 19 Mar 1998 15:32:25 -0000 Subject: [Matrix-SIG] Power of trigs Message-ID: <001e01bd534c$50103020$8f16fb83@nedo.engin.cf.ac.uk> -----Original Message----- From: Dave Stinchcombe To: matrix-sig@python.org Date: 19 March 1998 11:49 Subject: [Matrix-SIG] Power of trigs >Hi again, >This morning I needed to write a quick and easy root finder, so obviously I >grabbed Numeric Python. > >I have a problem though. I wrote the line: >Numeric.power(Numeric.cos(phi),1-2*nus) > >where nus is a constant of 0.3. phi is an array holding a list of values >I'm searching through. The problem comes that this line fails when phi is >greater than pi/2. > >Now obviously this is due to the fact I'm trying to calculate a complex (or >at the very least an imaginary) number. But I want to. Can any one give >some suggestions as to how to cope, or in some way make python also believe >in complex numbers. > Decision seems to be simple in this case - just convert explicitly first argument to a complex number format: >>> pow(-1, 1.0) Traceback (innermost last): File "", line 1, in ? ValueError: negative number to float power while: >>> pow(complex(-1),1.0) (-1+0j) or >>> pow(-2+0j,0.5) (8.65927457072e-017+1.41421356237j) But I am glad to rise again the question of weak argument's checking in pow(). I do not want always to check validity of all possible combinations of input arguments. I just want pow() to return most suitable and valid result. Andy K. From Michal.Spalinski@fuw.edu.pl Thu Mar 19 22:21:44 1998 From: Michal.Spalinski@fuw.edu.pl (Michal.Spalinski@fuw.edu.pl) Date: Thu, 19 Mar 98 23:21:44 +0100 Subject: [Matrix-SIG] Power of trigs In-Reply-To: <001e01bd534c$50103020$8f16fb83@nedo.engin.cf.ac.uk> (message from Andrey Kaliazin on Thu, 19 Mar 1998 15:32:25 -0000) Message-ID: <9803192221.AA23548@albert4.fuw.edu.pl> Kiciuniu slodki, widze, ze Cie raczej nie ma. Ja jutro rano jade do Krakowa i wracam w nocy a w sobote po poludniu jade do Poznania. Kiciuniu moj, tutaj okazalo sie, ze ta sztuka Schwaba "Zaglada ludu czyli Moja watroba jest bez sensu" idzie wlasnie w TV w rez. bajona, acha, to jest ta sztuka, na ktorej bylam bylam w teatrze, wiec bede ogladac. Jest to zrobione zupelnie, ale to zupelnie inaczej. Kitko, wobec tego ja tu zajrze jeszcze po spektaklu (0.40). Caluje Cie najkochanszy J. -- Michal Spalinski http://info.fuw.edu.pl/~mspal/home.html From hinsen@ibs.ibs.fr Fri Mar 20 11:42:53 1998 From: hinsen@ibs.ibs.fr (Konrad Hinsen) Date: Fri, 20 Mar 1998 12:42:53 +0100 Subject: [Matrix-SIG] Power of trigs In-Reply-To: <001e01bd534c$50103020$8f16fb83@nedo.engin.cf.ac.uk> (message from Andrey Kaliazin on Thu, 19 Mar 1998 15:32:25 -0000) Message-ID: <199803201142.MAA21678@lmspc1.ibs.fr> > But I am glad to rise again the question of weak argument's checking in > pow(). > I do not want always to check validity of all possible combinations of input > arguments. > I just want pow() to return most suitable and valid result. There was some discussion about type checking in Numeric functions in the early days of the Matrix SIG. There are two conflicting points of view: 1) If there is a reasonable answer for my input values, I want to get it. 2) A combination of input types that has a good chance of being a mistake should cause an exception. Depending on context, sqrt(-1) may be reasonable or an error, so the compromise was to indicate the willingness to get complex results by providing a complex argument. -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsen@ibs.ibs.fr Laboratoire de Dynamique Moleculaire | Tel.: +33-4.76.88.99.28 Institut de Biologie Structurale | Fax: +33-4.76.88.54.94 41, av. des Martyrs | Deutsch/Esperanto/English/ 38027 Grenoble Cedex 1, France | Nederlands/Francais ------------------------------------------------------------------------------- From Dirk.Engelmann@IWR.Uni-Heidelberg.De Sun Mar 22 12:34:12 1998 From: Dirk.Engelmann@IWR.Uni-Heidelberg.De (Dirk Engelmann) Date: Sun, 22 Mar 1998 13:34:12 +0100 (CET) Subject: [Matrix-SIG] data sharing Message-ID: Hi! I'm using NumPy and a set of other python libraries. Quite often, I've got to pass data between NumPy and some other library. Is there a way to pass data, without copying (fromstring/ tostring method) ? If not, is there more general interest ? There is a nice mehtod by Jim Fulton for exporting C API which could be used to do this. Thanks! Cheers, Dirk Engelmann From hinsen@ibs.ibs.fr Mon Mar 23 16:49:21 1998 From: hinsen@ibs.ibs.fr (Konrad Hinsen) Date: Mon, 23 Mar 1998 17:49:21 +0100 Subject: [Matrix-SIG] data sharing In-Reply-To: (message from Dirk Engelmann on Sun, 22 Mar 1998 13:34:12 +0100 (CET)) Message-ID: <199803231649.RAA06744@lmspc1.ibs.fr> > Is there a way to pass data, without copying (fromstring/ tostring > method) ? What exactly are you trying to do? The most obvious way of passing data is to pass the NumPy arrays. They can be accessed as sequences (even nested sequences), so many routines can handle them without knowing it. If you mean other C extension modules, it's a bit trickier. If the C modules use the generic object interface, everything should be fine again. If they are written for a specific data type, you'll need to convert your arrays. > There is a nice mehtod by Jim Fulton for exporting > C API which could be used to do this. The C API of the array and umath modules *is* exported. There are already a couple of C extension modules that make use of this, e.g. the LAPACK interface (in NumPy), the various random number modules, or the netCDF module. But this won't help you if you are dealing with another library that expects another data type. -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsen@ibs.ibs.fr Laboratoire de Dynamique Moleculaire | Tel.: +33-4.76.88.99.28 Institut de Biologie Structurale | Fax: +33-4.76.88.54.94 41, av. des Martyrs | Deutsch/Esperanto/English/ 38027 Grenoble Cedex 1, France | Nederlands/Francais ------------------------------------------------------------------------------- From lorenzo@argon.roma2.infn.it Mon Mar 23 17:58:54 1998 From: lorenzo@argon.roma2.infn.it (Lorenzo M. Catucci) Date: Mon, 23 Mar 1998 18:58:54 +0100 (CET) Subject: [Matrix-SIG] Anybody doing/having done FE PDE solving with NumPy? Message-ID: So good... I managed to put two true acronyms and a false one on the same subject line... maybe I'll do better some time... Now, I get serious: I'm going to do some simulations, and part of my problem is to build the static electric field inside a box, with some iregular shaped object inside. I think that the best way to do this part, is to solve via finite element method the Laplace equation $\nabla^2 \phi=0$ with Dirichlet's boundary conditions on the fixed potential surfaces. Then, I'll go to do some molecular dynamics for objects inside this field. Best option would be to be able to describe the FEM basis directly within python, but I still haven't managed to find a clear recipe for those nasty functions, which need be (at least) derivable, since I'll need the potential field gradient... Somebody could help me and tell which route to go? Servus, lorenzo From boyle@pcmdi.llnl.gov Tue Mar 24 17:32:33 1998 From: boyle@pcmdi.llnl.gov (James Boyle) Date: Tue, 24 Mar 1998 09:32:33 -0800 (PST) Subject: [Matrix-SIG] Feature of numeric slicing? Message-ID: <199803241732.JAA13068@cobra.llnl.gov> In playing with some slicing of Numeric arrays I found the following: (Python 1.5, the latest Numeric release 1.1?) >>>a = Numeric.arrayrange(0,5) >>>a >>>array[0,1,2,3,4] >>>c = a[1:3] >>>c >>>array[1,2] >>>c[0] = 99 >>>a >>>array[0, 99, 2, 3, 4] >>>c >>>array[99,2] Is this a desired property, a feature or a bug? I have not seen it documented, but I could have easily missed it. It appears that c just points to a section of the array a. If an operation such as c = a[1:3]*2.0 is carried out then c is a new object but a plain slice retains a connection of slicer and slicee. In Python it is my understanding that a slice creates a new object, without references to the slicee. Any words of wisdom? Jim Boyle From hinsen@ibs.ibs.fr Tue Mar 24 17:56:22 1998 From: hinsen@ibs.ibs.fr (Konrad Hinsen) Date: Tue, 24 Mar 1998 18:56:22 +0100 Subject: [Matrix-SIG] Optimized BLAS for Pentium Pros under Linux Message-ID: <199803241756.SAA02752@lmspc1.ibs.fr> As some of you may know, an optimized version of the BLAS library for PentiumPro machines running Linux has been made available recently. You can download it from http://www.cs.utk.edu/~ghenry/distrib/ Obviously this can be used to speed up the LinearAlgebra module in NumPy. Unfortunately the necessary compilation and linking steps are not totally trivial, so for those who would rather not try, I have prepared a binary release, i.e. the file lapack_lite.so statically linked with the optimized BLAS (and in fact statically linked with everything else, to avoid compatibility problems). You can get it via my Web page at http://starship.skyport.net/crew/hinsen/scientific.html Be warned that I haven't tested this a lot, but for my applications it works fine and given a speedup of roughly 30% for large matrices. -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsen@ibs.ibs.fr Laboratoire de Dynamique Moleculaire | Tel.: +33-4.76.88.99.28 Institut de Biologie Structurale | Fax: +33-4.76.88.54.94 41, av. des Martyrs | Deutsch/Esperanto/English/ 38027 Grenoble Cedex 1, France | Nederlands/Francais ------------------------------------------------------------------------------- From da@skivs.ski.org Tue Mar 24 18:10:22 1998 From: da@skivs.ski.org (David Ascher) Date: Tue, 24 Mar 1998 10:10:22 -0800 (PST) Subject: [Matrix-SIG] pickling of arrays Message-ID: FYI, The following addition to Numeric.py will allow arrays to pickle without needing to subclass Pickler. Still inefficient, but helpful for non-huge arrays. --david import copy_reg def array_constructor(shape, typecode, thestr): x = fromstring(thestr, typecode) x.shape = shape return x def pickle_array(a): return array_constructor, (a.shape, a.typecode(), a.tostring(),) copy_reg.pickle(ArrayType, pickle_array, array_constructor) From hinsen@ibs.ibs.fr Wed Mar 25 17:57:50 1998 From: hinsen@ibs.ibs.fr (Konrad Hinsen) Date: Wed, 25 Mar 1998 18:57:50 +0100 Subject: [Matrix-SIG] Feature of numeric slicing? In-Reply-To: <199803241732.JAA13068@cobra.llnl.gov> (message from James Boyle on Tue, 24 Mar 1998 09:32:33 -0800 (PST)) Message-ID: <199803251757.SAA07560@lmspc1.ibs.fr> > >>>a = Numeric.arrayrange(0,5) > >>>a > >>>array[0,1,2,3,4] > >>>c = a[1:3] > >>>c > >>>array[1,2] > >>>c[0] = 99 > >>>a > >>>array[0, 99, 2, 3, 4] > >>>c > >>>array[99,2] > Is this a desired property, a feature or a bug? I have not seen Feature. > It appears that c just points to a section of the array a. > If an operation such as c = a[1:3]*2.0 is carried out then > c is a new object but a plain slice retains a connection of > slicer and slicee. Exactly. > In Python it is my understanding that a slice creates a new object, without > references to the slicee. True for lists, but not for NumPy arrays. It is simply very useful to be able to share the array data space in this way. On the other hand, it can lead to bad surprises, so it should probably be pointed out somewhere clearly. -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsen@ibs.ibs.fr Laboratoire de Dynamique Moleculaire | Tel.: +33-4.76.88.99.28 Institut de Biologie Structurale | Fax: +33-4.76.88.54.94 41, av. des Martyrs | Deutsch/Esperanto/English/ 38027 Grenoble Cedex 1, France | Nederlands/Francais ------------------------------------------------------------------------------- From janne@avocado.pc.helsinki.fi Wed Mar 25 18:11:30 1998 From: janne@avocado.pc.helsinki.fi (Janne Sinkkonen) Date: 25 Mar 1998 20:11:30 +0200 Subject: [Matrix-SIG] Feature of numeric slicing? In-Reply-To: Konrad Hinsen's message of "Wed, 25 Mar 1998 18:57:50 +0100" References: <199803251757.SAA07560@lmspc1.ibs.fr> Message-ID: Konrad Hinsen writes: > True for lists, but not for NumPy arrays. It is simply very useful > to be able to share the array data space in this way. On the other > hand, it can lead to bad surprises, so it should probably be pointed > out somewhere clearly. Yes indeed. :) But I agree that it can be very useful, especially with large matrices. Another thing which is useful and should be documented is the optional second or third argument to ufuncs. -- Janne Sinkkonen From da@skivs.ski.org Thu Mar 26 23:39:01 1998 From: da@skivs.ski.org (David Ascher) Date: Thu, 26 Mar 1998 15:39:01 -0800 (PST) Subject: [Matrix-SIG] general 2D convolution, again. Message-ID: This topic comes up repeatedly, but I haven't seen a good answer yet. Problem: doing 2D convolutions with non-square and different shape arrays is (from what I've read) not doable using FFT multiplication. Has anyone coded such a convolution in either straight NumPy or using a C extension module? Linear, circular, with sweet-spot setting, etc? If not, I'll probably end up writing one, but it's likely to be buggy for a while... --david From janne@avocado.pc.helsinki.fi Fri Mar 27 09:20:21 1998 From: janne@avocado.pc.helsinki.fi (Janne Sinkkonen) Date: 27 Mar 1998 11:20:21 +0200 Subject: [Matrix-SIG] general 2D convolution, again. In-Reply-To: David Ascher's message of "Thu, 26 Mar 1998 15:39:01 -0800 (PST)" References: Message-ID: David Ascher writes: > Problem: doing 2D convolutions with non-square and different shape arrays > is (from what I've read) not doable using FFT multiplication. It depends on what kind of convolution you want. Gaussian kernel factorizes into two components and can be implemented by FFT. -- Janne Sinkkonen From Dirk.Engelmann@IWR.Uni-Heidelberg.De Fri Mar 27 09:52:46 1998 From: Dirk.Engelmann@IWR.Uni-Heidelberg.De (Dirk Engelmann) Date: Fri, 27 Mar 1998 10:52:46 +0100 (CET) Subject: [Matrix-SIG] general 2D convolution, again. In-Reply-To: Message-ID: On Thu, 26 Mar 1998, David Ascher wrote: > This topic comes up repeatedly, but I haven't seen a good answer yet. Some time ago I posed the same question. > > Problem: doing 2D convolutions with non-square and different shape arrays > is (from what I've read) not doable using FFT multiplication. Has anyone > coded such a convolution in either straight NumPy or using a C extension > module? Linear, circular, with sweet-spot setting, etc? I need it for image processing - and for large images (matrices) FFT is quite usefull - but not for non-square shape. If done it in my C++ library with swig interface to Python. But it's not that flexible (Linear, circular, ...). I would like to have it in NumPy very much! > If not, I'll probably end up writing one, but it's likely to be buggy for > a while... > Dirk Engelmann From David.Buscher@durham.ac.uk Fri Mar 27 11:15:44 1998 From: David.Buscher@durham.ac.uk (David Buscher) Date: Fri, 27 Mar 1998 11:15:44 +0000 (GMT) Subject: [Matrix-SIG] general 2D convolution, again. In-Reply-To: Message-ID: On Thu, 26 Mar 1998, David Ascher wrote: > Problem: doing 2D convolutions with non-square and different shape arrays > is (from what I've read) not doable using FFT multiplication. I believe this is something of an oversimplification. All convolutions are doable using an FFT, providing you pad the arrays with zeros to a mutually compatible size, and perhaps add extra padding to take care of edge effects. The only question then is whether this is the most efficient way to do the computation, which is clearly an implementation-dependent topic. Someone please correct me if I'm wrong! David ----------------------------------------+------------------------------------- David Buscher | Phone +44 191 374 7462 Dept of Physics, University of Durham, | Fax +44 191 374 3709 South Road, Durham DH1 3LE, UK | Email david.buscher@durham.ac.uk ----------------------------------------+------------------------------------- From janne@avocado.pc.helsinki.fi Fri Mar 27 15:31:03 1998 From: janne@avocado.pc.helsinki.fi (Janne Sinkkonen) Date: 27 Mar 1998 17:31:03 +0200 Subject: [Matrix-SIG] general 2D convolution, again. In-Reply-To: David Buscher's message of "Fri, 27 Mar 1998 11:15:44 +0000 (GMT)" References: Message-ID: David Buscher writes: > I believe this is something of an oversimplification. All convolutions > are doable using an FFT, providing you pad the arrays with zeros to a > mutually compatible size, and perhaps add extra padding to take care of > edge effects. The only question then is whether this is the most > efficient way to do the computation, which is clearly an > implementation-dependent topic. Someone please correct me if I'm wrong! You are probably right (someone please correct me if I'm wrong! :)) My earlier note about 'separable' or factorizing kernels was a bit irrelevant and incorrect. But convolutions by separable kernels are nice anyway, because you can do them as successive 1D convolutions. Gaussian and rectangular 2D kernels are separable, and therefore this kind of convolutions can be done by doing 1D convolutions successively over the two axis, something like: convImage=convolution1d(convolution1d(image,kernel,axis=0),kernel,axis=1) -- Janne Sinkkonen From David Ascher Fri Mar 27 17:04:55 1998 From: David Ascher (David Ascher) Date: Fri, 27 Mar 1998 09:04:55 -0800 (PST) Subject: [Matrix-SIG] general 2D convolution, again. In-Reply-To: Message-ID: On Fri, 27 Mar 1998, Dirk Engelmann wrote: > > Problem: doing 2D convolutions with non-square and different shape arrays > > is (from what I've read) not doable using FFT multiplication. Has anyone > > coded such a convolution in either straight NumPy or using a C extension > > module? Linear, circular, with sweet-spot setting, etc? > > I need it for image processing - and for large images (matrices) > FFT is quite usefull - but not for non-square shape. > If done it in my C++ library with swig interface to Python. But it's > not that flexible (Linear, circular, ...). > > I would like to have it in NumPy very much! Right, I'm doing image-processing-like sorts of things. I got impatient and wrote one, but I have to finish the details It's not smart at all, but someone who likes to optimize C code can feel free to take my code and make it run like the wind. At this point having *something* is more important to me than having the best. I suspect that a smart FFT based implementation would be much faster, but I don't have the confidence to know how to do it right. Once I'm convinced that I have a working implementation, it can be used as a reference implementation for checking an FFT-based implementation. More news later... --david From da@skivs.ski.org Fri Mar 27 20:06:45 1998 From: da@skivs.ski.org (David Ascher) Date: Fri, 27 Mar 1998 12:06:45 -0800 (PST) Subject: [Matrix-SIG] 2D kernel convolution Message-ID: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --1900032184-2002504639-891029205=:26832 Content-Type: TEXT/PLAIN; charset=US-ASCII Well, I got circular convolution to apparently work, but I'm quite baffled as to why linear convolution doesn't work. For a simple yet sufficient description of these things, look at http://tierra.ciens.ucv.ve/dipcourse/html/linear/convolution/front-page.html I'm attaching the module here so that folks can #1) use it if they only need circular convolution #2) tell me why linear convolution doesn't work #3) optimize it if they wish (I'd rather #2) happened first -- it's hard to modify optimized code... --david --1900032184-2002504639-891029205=:26832 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="kconvmodule.c" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: I2luY2x1ZGUgPHN0cmluZy5oPg0KI2luY2x1ZGUgPG1hdGguaD4NCiNpbmNs dWRlIDxzdGRpby5oPg0KI2luY2x1ZGUgIlB5dGhvbi5oIg0KI2luY2x1ZGUg ImFycmF5b2JqZWN0LmgiDQoNDQpzdGF0aWMgUHlPYmplY3QgKkVycm9yT2Jq ZWN0Ow0KDQojZGVmaW5lIFRSWShFKSBpZighIChFKSkgcmV0dXJuIE5VTEwN CiNkZWZpbmUgQVNTRVJUKEUsTSkgaWYoIShFKSkgcmV0dXJuIEVycm9yUmV0 dXJuKE0pDQoNCnN0YXRpYyBjaGFyIGRvY19kY29udltdID0NDQoiZGNvbnYo bSwgaywgKHgseSksfCBjaXJjKSB3aWxsIHJldHVybiBhIG1hdHJpeCBvZiB0 aGUgc2FtZSBcbiJcDQ0KImRpbWVuc2lvbnMgYXMgbSB3aGljaCBpcyB0aGUg cmVzdWx0IG9mIHRoZSBjb252b2x1dGlvbiBvZiBtIHdpdGggdGhlXG4iXA0N CiJrZXJuZWwgay4gIG0gYW5kIGsgbmVlZCB0byBiZSBhcnJheXMgb2YgZG91 Ymxlcy5cbiJcDQ0KIlRoZSB0aGlyZCBhcmd1bWVudCBpcyB0aGUgb3JpZ2lu IG9mIHRoZSBrZXJuZWwgKGFrYSBzd2VldCBzcG90KS5cbiJcDQ0KIlRoZSBs YXN0IG9wdGlvbmFsIGFyZ3VtZW50IGlzIGEgbnVtYmVyICgwIGJ5IGRlZmF1 bHQpLiAgSWYgdGhhdFxuIlwNDQoibnVtYmVyIGlzIG5vbi16ZXJvLCBhIGNp cmN1bGFyIGNvbnZvbHV0aW9uIGlzIHBlcmZvcm1lZC5cbiJcDQ0KIk90aGVy d2lzZSBhIGxpbmVhciBjb252b2x1dGlvbiBpcyBwZXJmb3JtZWQuXG4iXA0N CiJcblxuTk9URTogQ3VycmVudGx5IG9ubHkgY2lyY3VsYXIgY29udm9sdXRp b24gYXBwZWFycyB0byB3b3JrISEhXG4iOw0KDQpzdGF0aWMgUHlPYmplY3Qg Kmtjb252X2Rjb252KFB5T2JqZWN0ICppZ25vcmVkLCBQeU9iamVjdCAqYXJn cykgew0KDQ0KCVB5T2JqZWN0ICpvcCwgKmtwOw0KCVB5QXJyYXlPYmplY3Qg KmltYWdlLCAqa2VybmVsLCAqY29udm9sdXRpb247DQoNCglkb3VibGUgKmlE YXRhOw0KCWRvdWJsZSAqa0RhdGE7DQ0KCWRvdWJsZSAqY0RhdGE7DQ0KCWRv dWJsZSBjdW12YWw7DQ0KDQoJaW50IHNYLCBzWTsgICAvKiBzd2VldCBzcG90 IGNvb3JkaW5hdGVzIGZvciB0aGUga2VybmVsICovDQoJaW50IGlXaWR0aCwg aUhlaWdodCwga1dpZHRoLCBrSGVpZ2h0LCBjSGVpZ2h0LCBjV2lkdGg7DQoJ aW50IGtYLCBrWSwgY1gsIGNZLCBpWCwgaVk7DQoJaW50IGNpcmN1bGFyID0g MDsgIC8qIGJ5IGRlZmF1bHQgZG8gbGluZWFyIGNvbnZvbHV0aW9uICovDQoJ aW50IGtJbmRleCwgaUluZGV4LCBjSW5kZXg7DQoNCglUUlkoUHlBcmdfUGFy c2VUdXBsZShhcmdzLCAiT08oaWkpfGkiLCAmb3AsICZrcCwgJnNYLCAmc1ks ICZjaXJjdWxhcikpOw0KCVRSWShQeUFycmF5X0NoZWNrKG9wKSk7DQoJaW1h Z2UgPSAoUHlBcnJheU9iamVjdCAqKW9wOw0KCVRSWShQeUFycmF5X0NoZWNr KGtwKSk7DQoJa2VybmVsID0gKFB5QXJyYXlPYmplY3QgKilrcDsNCglpZiAo aW1hZ2UtPmRlc2NyLT50eXBlX251bSAhPSBQeUFycmF5X0RPVUJMRSB8fA0K CSAgICBrZXJuZWwtPmRlc2NyLT50eXBlX251bSAhPSBQeUFycmF5X0RPVUJM RSkgew0KCQlQeUVycl9TZXRTdHJpbmcoUHlFeGNfVmFsdWVFcnJvciwiYm90 aCBhcnJheXMgbXVzdCBiZSBhcnJheXMgb2YgZG91YmxlcyIpOyAgICAgIA0K CQlyZXR1cm4gTlVMTDsNCgl9DQoJaWYgKGltYWdlLT5uZCAhPSAyIHx8DQoJ ICAgIGtlcm5lbC0+bmQgIT0gMikgew0KCQlQeUVycl9TZXRTdHJpbmcoUHlF eGNfVmFsdWVFcnJvciwiYm90aCBhcnJheXMgbXVzdCBiZSBhcnJheXMgb2Yg cmFuayAyIik7ICAgICAgDQoJCXJldHVybiBOVUxMOw0KCX0NCglpZiAoY2ly Y3VsYXIpIHsgLyogY2lyY3VsYXIgY29udm9sdXRpb24gKi8NCgkJY29udm9s dXRpb24gPSAoUHlBcnJheU9iamVjdCAqKVB5QXJyYXlfRnJvbURpbXMoaW1h Z2UtPm5kLCBpbWFnZS0+ZGltZW5zaW9ucywgaW1hZ2UtPmRlc2NyLT50eXBl X251bSk7DQoJfSBlbHNlIHsgIC8qIGxpbmVhciBjb252b2x1dGlvbiAqLw0K CQlpbnQgZGltc1syXTsNCgkJZGltc1swXSA9IGltYWdlLT5kaW1lbnNpb25z WzBdICsga2VybmVsLT5kaW1lbnNpb25zWzBdIC0gMTsgDQ0KCQlkaW1zWzFd ID0gaW1hZ2UtPmRpbWVuc2lvbnNbMV0gKyBrZXJuZWwtPmRpbWVuc2lvbnNb MV0gLSAxOyANDQoJCWNvbnZvbHV0aW9uID0gKFB5QXJyYXlPYmplY3QgKilQ eUFycmF5X0Zyb21EaW1zKGltYWdlLT5uZCwgZGltcywgaW1hZ2UtPmRlc2Ny LT50eXBlX251bSk7DQoJfQ0KCWlmIChjb252b2x1dGlvbiA9PSBOVUxMKSB7 DQoJICBQeUVycl9TZXRTdHJpbmcoUHlFeGNfTWVtb3J5RXJyb3IsIkNvdWxk bid0IGNyZWF0ZSByZXN1bHQgYXJyYXkiKTsgICAgICANCgkgIHJldHVybiBO VUxMOw0KCX0NCglpV2lkdGggPSBpbWFnZS0+ZGltZW5zaW9uc1sxXTsgIA0N CglpSGVpZ2h0ID0gaW1hZ2UtPmRpbWVuc2lvbnNbMF07ICANDQoJa1dpZHRo ID0ga2VybmVsLT5kaW1lbnNpb25zWzFdOyAgDQ0KCWtIZWlnaHQgPSBrZXJu ZWwtPmRpbWVuc2lvbnNbMF07ICANDQoJY1dpZHRoID0gY29udm9sdXRpb24t PmRpbWVuc2lvbnNbMV07ICANDQoJY0hlaWdodCA9IGNvbnZvbHV0aW9uLT5k aW1lbnNpb25zWzBdOyAgDQ0KDQ0KCWlEYXRhID0gKGRvdWJsZSAqKWltYWdl LT5kYXRhOw0KCWtEYXRhID0gKGRvdWJsZSAqKWtlcm5lbC0+ZGF0YTsNDQoJ Y0RhdGEgPSAoZG91YmxlICopY29udm9sdXRpb24tPmRhdGE7DQ0KDQ0KCS8q IGl0ZXJhdGUgb3ZlciBldmVyeSBsaW5lIGluIHRoZSBjb252ICovDQogICAg ICAgIGZvciAoY1kgPSAwOyBjWSA8IGNIZWlnaHQ7IGNZKyspIHsNDQoJCS8q IGl0ZXJhdGUgb3ZlciBldmVyeSBwaXhlbCBpbiBlYWNoIGxpbmUgb2YgdGhl IGNvbnYgKi8NCgkJZm9yIChjWCA9IDA7IGNYIDwgY1dpZHRoOyBjWCsrKSB7 DQ0KCQkJLyogaXRlcmF0ZSBvdmVyIGV2ZXJ5IGxpbmUgaW4gdGhlIGtlcm5l bCAqLw0NCgkJCWN1bXZhbCA9IDAuMDsNDQoJCQlmb3IgKGtZID0gMDsga1kg PCBrSGVpZ2h0OyBrWSsrKSB7DQoJCQkJLyogZmluZCB0aGUgcm93ICMgZm9y IHRoYXQga2VybmVsIHJvdyBpbiB0aGUgaW1hZ2UgKi8NDQoJCQkJZm9yIChr WCA9IDA7IGtYIDwga1dpZHRoOyBrWCsrKSB7DQ0KCQkJCQlpWSA9IGNZICsg a1kgLSBzWTsNDQoJCQkJCWlYID0gY1ggKyBrWCAtIHNYOw0NCgkJCQkJaWYg KGNpcmN1bGFyKSB7DQ0KCQkJCQkJaWYgKGlZID49IGlIZWlnaHQpIGlZID0g aVkgLSBpSGVpZ2h0Ow0NCgkJCQkJCWVsc2UgaWYgKGlZIDwgMCkgICBpWSA9 IGlZICsgaUhlaWdodDsNDQoJCQkJCQlpZiAoaVggPj0gaVdpZHRoKSAgaVgg PSBpWCAtIGlXaWR0aDsNDQoJCQkJCQllbHNlIGlmIChpWCA8IDApICAgaVgg PSBpWCArIGlXaWR0aDsNDQoJCQkJCX0NDQoJCQkJCWlmIChjaXJjdWxhciB8 fCAoaVkgPj0gMCAmJiBpWSA8IGlIZWlnaHQgJiYgaVggPj0gMCAmJiBpWCA8 IGlXaWR0aCkpIHsNDQoJCQkJCQlrSW5kZXggPSBrWCArIGtZICoga1dpZHRo Ow0NCgkJCQkJCWlJbmRleCA9IGlYICsgaVkgKiBpV2lkdGg7DQ0KCQkJCQkJ aWYgKGlJbmRleCA+PSAwICYmIGlJbmRleCA8IGlXaWR0aCAqIGlIZWlnaHQg JiYNDQoJCQkJCQkgICAga0luZGV4ID49IDAgJiYga0luZGV4IDwga1dpZHRo ICoga0hlaWdodCkgew0NCgkJCQkJCQljdW12YWwgKz0gaURhdGFbaUluZGV4 XSAqIGtEYXRhW2tJbmRleF07DQ0KCQkJCQkJfQ0NCgkJCQkJfQ0KCQkJCX0N CgkJCX0NDQoJCQljSW5kZXggPSBjWCArIGNZICogY1dpZHRoOw0NCgkJCWNE YXRhW2NJbmRleF0gPSBjdW12YWw7DQ0KCQl9DQoJfQ0NCglyZXR1cm4gKFB5 T2JqZWN0ICopY29udm9sdXRpb247DQp9DQoNCnN0YXRpYyBzdHJ1Y3QgUHlN ZXRob2REZWYga2NvbnZfbWV0aG9kc1tdID0gew0KICB7ImRjb252Iiwga2Nv bnZfZGNvbnYsIDEsIGRvY19kY29udn0sDQogIHtOVUxMLAkJTlVMTCwgMH0J CS8qIHNlbnRpbmVsICovDQp9Ow0KDQp2b2lkIGluaXRrY29udigpIHsNCiAg UHlPYmplY3QgKm07DQogIC8qIENyZWF0ZSB0aGUgbW9kdWxlIGFuZCBhZGQg dGhlIGZ1bmN0aW9ucyAqLw0KICBpbXBvcnRfYXJyYXkoKTsNCiAgbSA9IFB5 X0luaXRNb2R1bGUoImtjb252Iiwga2NvbnZfbWV0aG9kcyk7DQogIC8qIENo ZWNrIGZvciBlcnJvcnMgKi8NCiAgaWYgKFB5RXJyX09jY3VycmVkKCkpDQog ICAgUHlfRmF0YWxFcnJvcigiY2FuJ3QgaW5pdGlhbGl6ZSBtb2R1bGUga2Nv bnYiKTsNCn0NCg== --1900032184-2002504639-891029205=:26832--