From answer at tnoo.net Thu May 1 20:57:33 2003 From: answer at tnoo.net (=?iso-8859-1?q?Martin_L=FCthi?=) Date: 01 May 2003 16:57:33 -0800 Subject: [SciPy-dev] [INSTALL CVS] segmentation fault Message-ID: Hi The installation of todays CVS version (2003/05/01) produces a segmentation fault on my Linux box. I use the following SuSE Linux 8.0, i686 Python 2.2.2 (#1, Oct 17 2002, 08:48:02) [GCC 2.95.3 20010315 (SuSE)] on linux2 Numeric 23.0 (Release) gcc version 3.2.3 running python under gdb gives: (gdb) run setup.py install Starting program: /usr/local/bin/python setup.py install [New Thread 1024 (LWP 6290)] ### Little Endian detected #### Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1024 (LWP 6290)] 0x400dbdcb in chunk_free () from /lib/libc.so.6 (gdb) backtrace #0 0x400dbdcb in chunk_free () from /lib/libc.so.6 #1 0x400dbc53 in free () from /lib/libc.so.6 #2 0x40221a53 in array_dealloc (self=0x83020d0) at Src/arrayobject.c:564 #3 0x4021b4f1 in PyArray_Return (mp=0x83020d0) at Src/arrayobject.c:633 #4 0x4022253f in array_add (m1=0x825fca0, m2=0x825fca0) at Src/arrayobject.c:1197 #5 0x080acb1d in binary_op1 (v=0x82d7f78, w=0x82d7fa0, op_slot=0) at Objects/abstract.c:392 #6 0x080af8eb in PyNumber_Add (v=0x82d7f78, w=0x82d7fa0) at Objects/abstract.c:605 #7 0x08076bad in eval_frame (f=0x81ba6b4) at Python/ceval.c:977 #8 0x080799ce in PyEval_EvalCodeEx (co=0x832eea0, globals=0x8338564, locals=0x0, args=0x81ba0e4, argcount=1, kws=0x81ba0e8, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2595 #9 0x0807bb9d in fast_function (func=0x833f09c, pp_stack=0xbfff7c74, n=1, na=1, nk=0) at Python/ceval.c:3170 #10 0x08078a51 in eval_frame (f=0x81b9f94) at Python/ceval.c:2034 #11 0x080799ce in PyEval_EvalCodeEx (co=0x82d7f30, globals=0x8338564, locals=0x8338564, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2595 #12 0x0807bb38 in PyEval_EvalCode (co=0x82d7f30, globals=0x8338564, locals=0x8338564) at Python/ceval.c:481 [Snip] Does anybody see the problem? Is the new gcc version to blame? Cheers Martin -- Martin L?thi answer at tnoo.net From pearu at cens.ioc.ee Fri May 2 01:26:15 2003 From: pearu at cens.ioc.ee (Pearu Peterson) Date: Fri, 2 May 2003 08:26:15 +0300 (EEST) Subject: [SciPy-dev] [INSTALL CVS] segmentation fault In-Reply-To: Message-ID: On 1 May 2003, Martin L?thi wrote: > Hi > > The installation of todays CVS version (2003/05/01) produces a segmentation > fault on my Linux box. I use the following > > SuSE Linux 8.0, i686 > > Python 2.2.2 (#1, Oct 17 2002, 08:48:02) > [GCC 2.95.3 20010315 (SuSE)] on linux2 > > Numeric 23.0 (Release) > > gcc version 3.2.3 > > running python under gdb gives: > > (gdb) run setup.py install > Starting program: /usr/local/bin/python setup.py install > [New Thread 1024 (LWP 6290)] > ### Little Endian detected #### > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 1024 (LWP 6290)] > 0x400dbdcb in chunk_free () from /lib/libc.so.6 > > (gdb) backtrace > #0 0x400dbdcb in chunk_free () from /lib/libc.so.6 > #1 0x400dbc53 in free () from /lib/libc.so.6 > #2 0x40221a53 in array_dealloc (self=0x83020d0) at Src/arrayobject.c:564 > #3 0x4021b4f1 in PyArray_Return (mp=0x83020d0) at Src/arrayobject.c:633 > [Snip] > > Does anybody see the problem? Is the new gcc version to blame? It's not obvious to me. Mixing different gcc versions is usually not a problem with pure C codes. Does Numeric work properly? E.g. check that all tests pass. Pearu From emkt at jongstit.com Fri May 2 14:32:43 2003 From: emkt at jongstit.com (Ms. Prim S.) Date: Fri, 02 May 2003 14:32:43 Subject: [SciPy-dev] Producer of synthetic yarn and fabric Message-ID: <200305020725.h427PdH16121@smtp.asiaaccess.net.th> An HTML attachment was scrubbed... URL: From Kasper.Souren at ircam.fr Fri May 2 08:58:25 2003 From: Kasper.Souren at ircam.fr (Kasper Souren) Date: Fri, 2 May 2003 12:58:25 +0000 Subject: [SciPy-dev] [INSTALL CVS] segmentation fault In-Reply-To: References: Message-ID: <200305021258.25890.Kasper.Souren@ircam.fr> > > Does anybody see the problem? Is the new gcc version to blame? > > It's not obvious to me. Mixing different gcc versions is usually not > a problem with pure C codes. IIRC I had a similar problem, disappearing when using the same gcc version for Python and SciPy... bye, Kasper From answer at tnoo.net Fri May 2 11:10:16 2003 From: answer at tnoo.net (=?iso-8859-1?q?Martin_L=FCthi?=) Date: 02 May 2003 07:10:16 -0800 Subject: [SciPy-dev] Re: [INSTALL CVS] segmentation fault References: <200305021258.25890.Kasper.Souren@ircam.fr> Message-ID: Kasper Souren writes: > > > Does anybody see the problem? Is the new gcc version to blame? > > > > It's not obvious to me. Mixing different gcc versions is usually not > > a problem with pure C codes. > > IIRC I had a similar problem, disappearing when using the same gcc version for > Python and SciPy... I will try this, thank you. Best, Martin -- Martin L?thi answer at tnoo.net From cebizzinetr at centerlink.com.br Sun May 4 06:51:26 2003 From: cebizzinetr at centerlink.com.br (Elmer) Date: Sun, 4 May 2003 07:51:26 -0300 Subject: [SciPy-dev] Autônomo com Internet Message-ID: <20030504114904.A42473EB09@www.scipy.com> Empresa procura aut?nomos para trabalho utilizando a Internet, em tempo parcial ou integral e com altos ganhos. Visite: www.hipernegocio.com Elmer NGTCorp - D?vidas pelo email ngtcorp at ibest.com.br Para ser removido de futuros correios, por favor, envie email para ngtcad at ibest.com.br, com o assunto REMOVER. Obrigado. From prabhu at aero.iitm.ernet.in Tue May 6 15:16:21 2003 From: prabhu at aero.iitm.ernet.in (Prabhu Ramachandran) Date: Wed, 7 May 2003 00:46:21 +0530 Subject: [SciPy-dev] CVS: Kiva build problem with gcc 2.95.4. Message-ID: <16056.2565.796318.312414@monster.linux.in> Hi, A CVS update of scipy today fails to build under gcc version 2.95.4 20011002 (Debian prerelease) with the error msg attached below. Does kiva require a newer version of gcc? It would be nice if kiva would build cleanly with gcc-2.95.4 as it did a week back. :) Thanks! prabhu ------------------------------------------------------------------ building 'kiva.agg._kiva' extension gcc -DNDEBUG -g -O3 -Wstrict-prototypes -fPIC -I/home/src/prabhu/cvs/scipy/Lib_chaco/kiva/agg/src/../../../agg2/include -I/home/src/prabhu/cvs/scipy/Lib_chaco/kiva/agg/src/include -I/home/src/prabhu/cvs/scipy/Lib_chaco/kiva/agg/src -I/home/src/prabhu/cvs/scipy/Lib/weave -I/home/src/prabhu/cvs/scipy/Lib/weave/scxx -I/usr/include/python2.2 -c /home/src/prabhu/cvs/scipy/_kiva.cpp -o build/temp.linux-i686-2.2/_kiva.o In file included from /home/src/prabhu/cvs/scipy/Lib_chaco/kiva/agg/src/kiva_agg.h:7, from /home/src/prabhu/cvs/scipy/_kiva.cpp:14: /home/src/prabhu/cvs/scipy/Lib_chaco/kiva/agg/src/kiva_graphics_context.h: In method `void kiva::graphics_context_bitmap::final_stroke_path(agg::conv_stroke &)': /home/src/prabhu/cvs/scipy/Lib_chaco/kiva/agg/src/kiva_graphics_context.h:493: instantiated from here /home/src/prabhu/cvs/scipy/Lib_chaco/kiva/agg/src/kiva_graphics_context.h:512: Internal compiler error. /home/src/prabhu/cvs/scipy/Lib_chaco/kiva/agg/src/kiva_graphics_context.h:512: Please submit a full bug report. /home/src/prabhu/cvs/scipy/Lib_chaco/kiva/agg/src/kiva_graphics_context.h:512: Internal compiler error: /home/src/prabhu/cvs/scipy/Lib_chaco/kiva/agg/src/kiva_graphics_context.h:512: See for instructions. error: command 'gcc' failed with exit status 1 ------------------------------------------------------------------ From mpeti_ka06 at redffmail.com Wed May 7 18:40:48 2003 From: mpeti_ka06 at redffmail.com (MPETI L.KABILA (Jnr)) Date: Thu, 08 May 2003 00:40:48 +0200 Subject: [SciPy-dev] BUSINESS PROPOSAL Message-ID: <20030507233940.4DE9F3EB09@www.scipy.com> Your contact was availed to me by the chamber of Commerce. It was given to me because of my diplomatic Status as I did not disclose the actual reasons for Which I sought your contact. But I was Assured that you are reputable and trustworthy if you Will be of assistance. I am Laurent Mpeti Kabila (Jnr) the second son of Late President LAURENT DESIRE KABILA the immediate Past president of the DEMOCRATIC REPUBLIC OF CONGO in Africa who was murdered by his opposition through his Personal bodyguards in his bedroom on Tuesday 16th January, 2001. I have the privilege of being mandated by my father colleagues To seek your immediate and urgent co-operation to receive into Your bank account the sum of US $10,000,000(ten million Dollars) And some thousands carats of Diamond. Presently, I am with the Nederland?s government seeking for political asylum. This money and treasures was lodged in a vault with a Security firm in the Nederland?s. SOURCES OF DIAMONDS AND FUND In August 2000, my father as a defense minister and president Has a meeting with his cabinet and army chief about the defense budget For 2000 to 2001 which was US $700m. So he directed one of his best Friend. Frederic Kibasa Maliba who was a minister of mines and a political party leader known as the Union Sacree de, I opposition radicale et ses allies (USORAL) to buy arms With US $200m on 5th January 2001; for him to finalized the arm s Deal, my father was murdered. f.K. Maliba (FKM) and I have Decided to keep the money with a foreigner after which he will use it To contest For the political election. In spite of all this we have resolved to Present your or your company for the firm to pay it into your Nominated account the above sum and diamonds. This transaction Should be finalized within seven (7) working days and for your Co-operation and partnership, we have unanimously agreed that you Will be entitled to 5.5% of the Money when successfully receives it in your account. The nature of your Business is not relevant to the successful execution of this Transaction what we require is your total co-operation and Commitment to ensure 100% risk-free transaction at both ends and to Protect the persons Involved in this transaction, strict confidence and utmost Secrecy is required even after the successful conclusion of this Transaction. If this Proposal is acceptable to you; kindly provide me with your personal Telephone and fax through my E-mail box for immediate Commencement of the transaction. All correspondence is for the attention of my counsel: I count on your honor to keep my secret, SECRET. Looking forward for your urgent reply Thanks. Best Regards MPETI L. KABILA (Jnr) From nwagner at mecha.uni-stuttgart.de Thu May 8 02:57:25 2003 From: nwagner at mecha.uni-stuttgart.de (Nils Wagner) Date: Thu, 08 May 2003 08:57:25 +0200 Subject: [SciPy-dev] Problems with latest cvs during build Message-ID: <3EB9FFD5.A3FE18C5@mecha.uni-stuttgart.de> Hi all, I tried to build scipy from latest cvs. It failed with the following messages In file included from /export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/src/kiva_agg.h:7, from /export/home/wagner/cvs/scipy/_kiva.cpp:14: /export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/src/kiva_graphics_context.h: In method `void kiva::graphics_context_bitmap::final_stroke_path(agg::conv_stroke &)': /export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/src/kiva_graphics_context.h:493: instantiated from here /export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/src/kiva_graphics_context.h:512: Internal compiler error. /export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/src/kiva_graphics_context.h:512: Please submit a full bug report. /export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/src/kiva_graphics_context.h:512: See for instructions. error: command 'gcc' failed with exit status 1 Any idea ? Nils From piesiewicz at pb.izm.fhg.de Thu May 8 09:53:30 2003 From: piesiewicz at pb.izm.fhg.de (Radoslaw Piesiewicz) Date: Thu, 8 May 2003 15:53:30 +0200 Subject: [SciPy-dev] Phd thesis Message-ID: <00e801c31569$35ad6010$6c776099@laplace> Hello, I am working towards Phd degree in the field of modeling and simulation of complex package wiring. I came across reference to your Phd thesis. I would be grateful if you could send it to me per email. Thanks in advance. Radoslaw - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Dipl.-Ing. Radoslaw Piesiewicz Fraunhofer Institute Reliability and Microintegration (IZM) - University of Paderborn Advanced System Engineering (ASE), Electromagnetic Field Analysis Technologiepark 34, 33100 Paderborn Tel.: ++49 (0)5251/5402-121 Fax.: ++49 (0)5251/5402-105 E-Mail: radoslaw.piesiewicz at pb.izm.fhg.de http://www.pb.izm.fhg.de -------------- next part -------------- An HTML attachment was scrubbed... URL: From ns2szu5i6xf at yahoo.ca Fri May 9 00:42:35 2003 From: ns2szu5i6xf at yahoo.ca (Frances Mccullough) Date: Fri, 09 May 03 04:42:35 GMT Subject: [SciPy-dev] Mortgage Rates down to Lowest since 1966! s xgeo ymex Message-ID: <3-$$h7e9$taf$f$gmo870br75q12n@exdv.3igd16> An HTML attachment was scrubbed... URL: From 9wgcg018jm at yahoo.ca Fri May 9 12:37:23 2003 From: 9wgcg018jm at yahoo.ca (Dominique Metz) Date: Fri, 09 May 03 16:37:23 GMT Subject: [SciPy-dev] Home Loans!... Debt Consolidation... Refinance... 123 jmdthfeskb wuv Message-ID: An HTML attachment was scrubbed... URL: From Chuck.Harris at sdl.usu.edu Thu May 8 16:56:13 2003 From: Chuck.Harris at sdl.usu.edu (Chuck Harris) Date: Thu, 8 May 2003 14:56:13 -0600 Subject: [SciPy-dev] fft Message-ID: <1885D1238A4FFE40B113CEB26F87872B11835C@cobra.usurf.usu.edu> Hi All, I've implemented a simple - but apparently little known - variant of the radix 2 fft that has an operation count equivalent to the split radix 2,4,8,16,... algorithm. I have C code for both the fft and the fht (fast hartley transform). Anyway, I noted some while back that someone was doing timing benchmarks on various fft implementations, and I would like to replicate this same test suite with the new algorithms to see how they compare. Can someone point me in the right direction? TIA Chuck From pearu at cens.ioc.ee Thu May 8 17:27:41 2003 From: pearu at cens.ioc.ee (Pearu Peterson) Date: Fri, 9 May 2003 00:27:41 +0300 (EEST) Subject: [SciPy-dev] fft In-Reply-To: <1885D1238A4FFE40B113CEB26F87872B11835C@cobra.usurf.usu.edu> Message-ID: On Thu, 8 May 2003, Chuck Harris wrote: > I've implemented a simple - but apparently little known - variant > of the radix 2 fft that has an operation count equivalent to the > split radix 2,4,8,16,... algorithm. I have C code for both the > fft and the fht (fast hartley transform). > > Anyway, I noted some while back that someone was doing timing benchmarks > on various fft implementations, and I would like to replicate this same > test suite with the new algorithms to see how they compare. Can someone > point me in the right direction? TIA See scipy/Lib/fftpack/tests/test_basic.py The test_*fft classes define bench_* methods that measure the efficiency of various fft implementations. To run fftpack tests without building the whole scipy, do cd scipy/Lib/fftpack/ python setup_fftpack.py build python tests/test_basic.py 10 Pearu From eric at enthought.com Fri May 9 00:53:49 2003 From: eric at enthought.com (Eric Jones) Date: Thu, 8 May 2003 23:53:49 -0500 (CDT) Subject: [SciPy-dev] Problems with latest cvs during build Message-ID: <20030509045349.6C3411063@www.enthought.com> I think this is fixed, but those with working 2.95.3 compilers please check it. It at least compiles. The fix is a hack that gets rid of using templates in the function definition. It isn't a good solution as I have to duplicate the function twice. If someone else with a lot of C++ experience can fix it correctly, I'd be much obliged. thanks, eric Nils Wagner wrote .. > Hi all, > > I tried to build scipy from latest cvs. It failed with the following > messages > > In file included from > /export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/src/kiva_agg.h:7, > from /export/home/wagner/cvs/scipy/_kiva.cpp:14: > /export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/src/kiva_graphics_context.h: > In method `void > kiva::graphics_context_bitmap::final_stroke_path(agg::conv_stroke > &)': > /export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/src/kiva_graphics_context.h:493: > instantiated from here > /export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/src/kiva_graphics_context.h:512: > Internal compiler error. > /export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/src/kiva_graphics_context.h:512: > Please submit a full bug report. > /export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/src/kiva_graphics_context.h:512: > See for instructions. > error: command 'gcc' failed with exit status 1 > > Any idea ? > > Nils > _______________________________________________ > Scipy-dev mailing list > Scipy-dev at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-dev From prabhu at aero.iitm.ernet.in Fri May 9 02:39:29 2003 From: prabhu at aero.iitm.ernet.in (Prabhu Ramachandran) Date: Fri, 9 May 2003 12:09:29 +0530 Subject: [SciPy-dev] Problems with latest cvs during build In-Reply-To: <20030509045349.6C3411063@www.enthought.com> References: <20030509045349.6C3411063@www.enthought.com> Message-ID: <16059.19745.121369.554508@monster.linux.in> >>>>> "EJ" == Eric Jones writes: EJ> I think this is fixed, but those with working 2.95.3 compilers EJ> please check it. It at least compiles. The fix is a hack Thanks! Builds and works cleanly on: gcc version 2.95.4 20011002 (Debian prerelease) cheers, prabhu From nwagner at mecha.uni-stuttgart.de Fri May 9 10:09:05 2003 From: nwagner at mecha.uni-stuttgart.de (Nils Wagner) Date: Fri, 09 May 2003 16:09:05 +0200 Subject: [SciPy-dev] From NASTRAN to scipy Message-ID: <3EBBB681.F225F4AB@mecha.uni-stuttgart.de> Hi all, I am looking for a scipy routine for reading NASTRAN (ASCII/binary) files ? Any hint would be appreciated Nils Relevant links http://www.sdtools.com/faq/FE06001.html http://www.mscsoftware.com/products/products_detail.cfm?S=74&PI=7&M=0 From l80w2dc2hd at aol.com Sat May 10 04:57:33 2003 From: l80w2dc2hd at aol.com (Susan Delong) Date: Sat, 10 May 03 08:57:33 GMT Subject: [SciPy-dev] Bannedcd CD p mt sgkui Message-ID: An HTML attachment was scrubbed... URL: From z8y6p5away at yahoo.ca Sat May 10 06:01:55 2003 From: z8y6p5away at yahoo.ca (Elinor Wills) Date: Sat, 10 May 03 10:01:55 GMT Subject: [SciPy-dev] Make $92000 in 6 month qofcosdn mfjsrrb Message-ID: An HTML attachment was scrubbed... URL: From promoters at selvacouters.com.br Sat May 10 09:15:25 2003 From: promoters at selvacouters.com.br (Marcos) Date: Sat, 10 May 2003 09:15:25 -0400 Subject: [SciPy-dev] Dinheiro? Mulheres? Message-ID: <200305100914843.SM01932@selvacouters.com.br> Quer conquistar qualquer MULHER ou HOMEM? ou ta afim de faturar uma Grana? Acesse: http://www.cadernoteen.com/promo - e descubra. Clique aqui!!! -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: corpoperfeito.htm Type: application/octet-stream Size: 1867 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: feromonio.htm Type: application/octet-stream Size: 2298 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: venda.htm Type: application/octet-stream Size: 2294 bytes Desc: not available URL: From jesusfritz_89 at whois.sc Sat May 10 18:19:50 2003 From: jesusfritz_89 at whois.sc (Jesus Fritz) Date: Sat, 10 May 2003 22:19:50 +0000 Subject: [SciPy-dev] Give me a breakget money now Message-ID: <212401c31742$02492c2c$5aa16ae6@qpi981o> -------------- next part -------------- An HTML attachment was scrubbed... URL: From svr6ucxx5t at foia.com Sun May 11 14:09:06 2003 From: svr6ucxx5t at foia.com (Phoebe Hobbs) Date: Sun, 11 May 03 18:09:06 GMT Subject: [SciPy-dev] Paxil, Phentermine, Viagra, and more. Order Online with NO PRIOR PRESCRIPTION Message-ID: An HTML attachment was scrubbed... URL: From charris208 at attbi.com Sun May 11 22:30:52 2003 From: charris208 at attbi.com (Charles R Harris) Date: 11 May 2003 20:30:52 -0600 Subject: [SciPy-dev] fft benchmarks for new routines Message-ID: <1052706651.20895.70.camel@tethys> Hi All, I ran a pared down version of Pearu's benchmark script on my new fft routines. I also scaled the times by the factor 1e8/(repeat*size*log(size)) so as to obtain a more informative number. There are three regions of interest in the results: 1) small transforms are dominated by python calling overhead 2) medium transforms run in cache and perform best 3) long transforms do out of cache references, performance sucks I think my routines are better, not that I'm biased or anything. They are faster, require only one work array for all transforms below a given size, and the code is readable - not to say understandable. 8) To cut down on out-of-cache overhead, I unrolled a loop, which made the code about 3x longer and somewhat ugly. The result is a sort of bastard split radix 2,4 fft. Chuck Fast Fourier Transform ==================================================== | real input | complex input ---------------------------------------------------- size | scipy | testing | scipy | testing ---------------------------------------------------- 256 | 2.04 | 1.48 | 2.11 | 1.97 (10000 calls) 512 | 1.35 | 1.00 | 1.53 | 1.53 (10000 calls) 1024 | 0.99 | 0.70 | 1.27 | 1.27 (1000 calls) 2048 | 0.70 | 0.70 | 1.41 | 1.15 (1000 calls) 4096 | 0.70 | 0.59 | 1.58 | 1.23 (500 calls) 8192 | 1.54 | 0.65 | 3.85 | 1.79 (500 calls) 16384 | 2.36 | 1.26 | 4.88 | 2.67 (250 calls) 32768 | 3.30 | 1.66 | 4.74 | 3.97 (250 calls) 65536 | 3.40 | 2.57 | 5.12 | 4.10 (100 calls) 131072 | 3.55 | 2.72 | 5.19 | 4.30 (50 calls) 262144 | 3.49 | 2.72 | 5.04 | 4.26 (25 calls) 524288 | 3.34 | 2.70 | 4.98 | 4.16 (12 calls) 1048576 | 3.24 | 2.74 | 5.60 | 4.22 (6 calls) -------------- next part -------------- An HTML attachment was scrubbed... URL: From pearu at cens.ioc.ee Mon May 12 05:11:37 2003 From: pearu at cens.ioc.ee (Pearu Peterson) Date: Mon, 12 May 2003 12:11:37 +0300 (EEST) Subject: [SciPy-dev] fft benchmarks for new routines In-Reply-To: <1052706651.20895.70.camel@tethys> Message-ID: Hi Chuck, On 11 May 2003, Charles R Harris wrote: > I ran a pared down version of Pearu's benchmark script on > my new fft routines. I also scaled the times by the > factor 1e8/(repeat*size*log(size)) so as to obtain a > more informative number. There are three regions of > interest in the results: > > 1) small transforms are dominated by python calling overhead > 2) medium transforms run in cache and perform best > 3) long transforms do out of cache references, performance sucks > > I think my routines are better, not that I'm biased or anything. > They are faster, require only one work array for all transforms > below a given size, and the code is readable - not to say > understandable. 8) That's nice! Where one can see your routines? > To cut down on out-of-cache overhead, I unrolled a loop, which > made the code about 3x longer and somewhat ugly. The result is > a sort of bastard split radix 2,4 fft. What fft backend are you using in scipy? FFTPACK, FFTW, or DJBFFT? Note that if your routines are power-two only then it would be still easy to include (if you wish) them to scipy.fftpack using the same hooks as for wrapping DJBFFT. Thanks, Pearu From nwagner at mecha.uni-stuttgart.de Mon May 12 08:42:08 2003 From: nwagner at mecha.uni-stuttgart.de (Nils Wagner) Date: Mon, 12 May 2003 14:42:08 +0200 Subject: [SciPy-dev] Negative entries in matrices get lost by using io.read_array Message-ID: <3EBF96A0.29A22200@mecha.uni-stuttgart.de> Hi all, I have a problem with io:read_array Negative entries in matrices get lost by using io.read_array. This is llustrated by means of a short test program ioread.py. Any idea ? Nils -------------- next part -------------- 1.0 2.0 3.0 -1.0 2.0 2.0 3.0 0.0 3.0 4.0 4.0 1.0 4.0 5.0 6.0 7.0 -------------- next part -------------- from scipy import * file = open("test.mat") a = io.read_array(file) print a From Chuck.Harris at sdl.usu.edu Mon May 12 10:24:41 2003 From: Chuck.Harris at sdl.usu.edu (Chuck Harris) Date: Mon, 12 May 2003 08:24:41 -0600 Subject: [SciPy-dev] fft benchmarks for new routines Message-ID: <1885D1238A4FFE40B113CEB26F87872B11835D@cobra.usurf.usu.edu> Hi Pearu, > On 11 May 2003, Charles R Harris wrote: > > > I think my routines are better, not that I'm biased or anything. > > They are faster, require only one work array for all transforms > > below a given size, and the code is readable - not to say > > understandable. 8) > > That's nice! > Where one can see your routines? I can send them to the list, or mail them to you direct. I do want to check over the unrolled version first to make sure no sign errors crept in --- I did verify that the original versions were correct. They probably need some documentation too, as this is the only code I know of that uses this algorithm. > > > To cut down on out-of-cache overhead, I unrolled a loop, which > > made the code about 3x longer and somewhat ugly. The result is > > a sort of bastard split radix 2,4 fft. > > What fft backend are you using in scipy? FFTPACK, FFTW, or DJBFFT? What is DJBFFT? I did my own based roughly on FFTPACK. It is not complete, as it allocates and keeps the coefficient array and needs some locking and reference counting to be thread safe. Don't know how to do this in Python. Also, I only did the fft call (single and double precision), and should probably add in the rest, along with the fast hartley transform that I use for the real case. I renamed all the basic routines because I got tired of spending half a minute to figure out just what the h*ll drfftf stood for. This is now fft_dbl_real_for, and so on. Comments? > Note that if your routines are power-two only then it would be still They are power-two -- other radix values fail to move me ;) By the way, one problem I had was that the *.so library (linux) was not visible in the package, although it did fine as soon as I moved it up into site-packages. Probably some obvious oversight on my part -- I suspect the __init__.py file. Any thoughts? Chuck From pearu at cens.ioc.ee Mon May 12 13:15:57 2003 From: pearu at cens.ioc.ee (Pearu Peterson) Date: Mon, 12 May 2003 20:15:57 +0300 (EEST) Subject: [SciPy-dev] fft benchmarks for new routines In-Reply-To: <1885D1238A4FFE40B113CEB26F87872B11835D@cobra.usurf.usu.edu> Message-ID: On Mon, 12 May 2003, Chuck Harris wrote: > > > To cut down on out-of-cache overhead, I unrolled a loop, which > > > made the code about 3x longer and somewhat ugly. The result is > > > a sort of bastard split radix 2,4 fft. > > > > What fft backend are you using in scipy? FFTPACK, FFTW, or DJBFFT? > > What is DJBFFT? See http://cr.yp.to/djbfft.html When FFTW is 'the Fastest FT in West' then DJBFFT is supposed to be 'the fastest FT in Universe' ;) DJBFFT also provides only power-of-two (<=8192) routines and is indeed very fast. However, it assumes very special data ordering. Since we are using FFTPACK convention then transformations between data orders will kill any speed gain obtained when using DJBFFT backend. With DJBFFT there are also some license and installation (Win32,MacOSX) issues. So, it would be nice to have fast power-of-two routines that does not have above problems. > I did my own based roughly on FFTPACK. Then we should bench your algorithms also against FFTW as FFTW is faster than FFTPACK. > It is not complete, as it allocates and keeps the coefficient array > and needs some locking and reference counting to be thread safe. Don't > know how to do this in Python. See http://www.python.org/doc/current/api/threads.html > Also, I only did the fft call (single and double precision), > and should probably add in the rest, along with the fast hartley transform > that I use for the real case. I renamed all the basic routines because > I got tired of spending half a minute to figure out just what the h*ll > drfftf stood for. This is now fft_dbl_real_for, and so on. Comments? Note that scipy.fftpack provides generic functions like fft, ifft, etc that check their argument types and call appropriate low-level (single, double, complex, or double complex) routine (see fftpack/basic.py). So, there's no need for users to figure out cryptic names like drfftf, etc. These generic functions give additional overhead and in principle we could implement them in C in future but right now it's better to keep them in Python until the interface stabilizes. After all, the overhead of calling Python functions will be relevant only for small fft sizes. > By the way, one problem I had was that the *.so library (linux) was not > visible in the package, although it did fine as soon as I moved it up > into site-packages. Probably some obvious oversight on my part -- I > suspect the __init__.py file. Any thoughts? I would need some additional information to give any useful thoughts. What exactly did you tried and how? Pearu From answer at tnoo.net Mon May 12 14:44:33 2003 From: answer at tnoo.net (=?iso-8859-1?q?Martin_L=FCthi?=) Date: 12 May 2003 10:44:33 -0800 Subject: [SciPy-dev] Re: From NASTRAN to scipy References: <3EBBB681.F225F4AB@mecha.uni-stuttgart.de> Message-ID: Nils I had a similar problem reading MSC/MARC files. This lead to the creation of FEval, a library for reading and writing Finite Element data (input and / or output) in different formats. Although Nastran is not supported ATM, it is very simple to add the corresponding functionality. If you need assistance I am glad to help. FEval can be found at http://www.sourceforge.net/projects/feval (no home page as of now, the documentation is included in the distribution). Best, Martin -- Martin L?thi answer at tnoo.net From Chuck.Harris at sdl.usu.edu Mon May 12 17:40:29 2003 From: Chuck.Harris at sdl.usu.edu (Chuck Harris) Date: Mon, 12 May 2003 15:40:29 -0600 Subject: [SciPy-dev] fft benchmarks for new routines Message-ID: <1885D1238A4FFE40B113CEB26F87872B11835E@cobra.usurf.usu.edu> Hi Pearu, >Then we should bench your algorithms also against FFTW as FFTW is faster >than FFTPACK. Where are the wrappers for FFTW? They seem to have disappeared from scipy, certainly they didn't come down with the latest CVS update. What order is preferred for the real transforms? The most natural order for my routine is real in the bottom and imaginary reversed in the top. Not reversing the top is easy, but interlacing real and imaginary is more difficult and time consuming. By the way, I think I can get rid of the out of cache issues pretty easily by chunking the data, but micro-optimization questions of efficient stack addressing come to mind. These sort of things tend to be processor and compiler dependent, and I don't want to get into that -- so maybe different routines for large and small transforms. >These generic functions give additional overhead and in principle we >could implement them in C in future but right now it's better to keep >them in Python until the interface stabilizes. After all, the overhead of >calling Python functions will be relevant only for small fft sizes. Yep, I looked at doing the checks in the C interface and decided to pass for the time being. Chuck _______________________________________________ Scipy-dev mailing list Scipy-dev at scipy.net http://www.scipy.net/mailman/listinfo/scipy-dev -------------- next part -------------- A non-text attachment was scrubbed... Name: winmail.dat Type: application/ms-tnef Size: 3100 bytes Desc: not available URL: From pearu at cens.ioc.ee Tue May 13 04:20:38 2003 From: pearu at cens.ioc.ee (Pearu Peterson) Date: Tue, 13 May 2003 11:20:38 +0300 (EEST) Subject: [SciPy-dev] fft benchmarks for new routines In-Reply-To: <1885D1238A4FFE40B113CEB26F87872B11835E@cobra.usurf.usu.edu> Message-ID: Chuck, On Mon, 12 May 2003, Chuck Harris wrote: > >Then we should bench your algorithms also against FFTW as FFTW is faster > >than FFTPACK. > > Where are the wrappers for FFTW? They seem to have disappeared from > scipy, certainly they didn't come down with the latest CVS update. FFTW as well as other FFT backends are wrapped by scipy.fftpack. For example, see fftpack/src/zfft.c that defines void zfft(...) This C function calls either FFTW, FFTPACK or DJBFFT routines depending on whether cpp-macros WITH_DJBFFT or WITH_FFTW are defined. These macros are determined from calling scipy_distutils.system_info.get_info('djbfft') scipy_distutils.system_info.get_info('fftw') in fftpack/setup_fftpack.py. In general, setup_fftpack.py should pick up FFTW libraries when available, Otherwise FFTPACK is used. See fftpack/NOTES.txt for more information how to build scipy.fftpack with a particular FFT backend. The C function zfft itself is wrapped using f2py. See fftpack/_fftpack.pyf that defines _fftpack extension module. And finally, _fftpack.zfft is called from fft Python function defined in fftpack/basic.py. > What order is preferred for the real transforms? The most natural order > for my routine is real in the bottom and imaginary reversed in the top. So this is the same as in FFTW: http://www.fftw.org/fftw3_doc/The-Halfcomplex-format-DFT.html > Not reversing the top is easy, but interlacing real and imaginary is more > difficult and time consuming. scipy currently uses FFTPACK convention, that is, rfft(x) returns [y(0),Re(y(1)),Im(y(1)),...,Re(y(n/2))] where y is FT of real x. See scipy.fftpack.rfft.__doc__ for a complete definition. Btw, Numeric.real_fft uses the same convention (because it uses f2c version of FFTPACK) but returns y as a complex array. Pearu From charris208 at attbi.com Tue May 13 11:15:14 2003 From: charris208 at attbi.com (Charles R Harris) Date: 13 May 2003 09:15:14 -0600 Subject: [SciPy-dev] fft benchmarks for new routines Message-ID: <1052838914.1700.20.camel@tethys> > > >Then we should bench your algorithms also against FFTW as FFTW is > > >faster > > >than FFTPACK. > > > > Where are the wrappers for FFTW? They seem to have disappeared from > > scipy, certainly they didn't come down with the latest CVS update. > >FFTW as well as other FFT backends are wrapped by scipy.fftpack. Ok, I'll do the benchmark. I've been thinking about the benchmark results for long transforms. The difference in actual computation times between different algorithms should be insignificant, as memory access is so dominant. The main difference should be the the number of passes thru the data: radix 2 : lg(n) radix 4 : lg(n)/2 radix 8 : lg(n)/3 after I unrolled the loop, the times of fftpack and my routines should be identical. So why the difference? The accesses are basically the same for the four varieties of fft -- decimation in time, decimation in frequency + bit reversed versions of same -- except for the order in which the coefficients are stored. If they are in linear order the accesses will be less efficient than if they are in bitreversed order. I suspect this is the only difference that accounts for the results. This suggests that some sort of data chunking is the way to go here. For shorter transforms the algorithm should make a difference, but this is pretty much buried in the calling overhead. I suspect that a simple radix 2 with chunking would look much the same to Python as even the most comlicated algorithm. Chuck From Kasper.Souren at ircam.fr Tue May 13 16:32:18 2003 From: Kasper.Souren at ircam.fr (Kasper Souren) Date: Tue, 13 May 2003 20:32:18 +0000 Subject: [SciPy-dev] signal.sepfir2d bug Message-ID: <200305132032.18965.Kasper.Souren@ircam.fr> Hi! >>> signal.sepfir2d(resize(arange(400.), (20, 20)), [1], [1]) Ok >>> signal.sepfir2d(arange(400.), [1], [1]) Returns without exception set, still ok. >>> signal.sepfir2d(resize(arange(400.), (20, 20)), [1], []) Segmentation fault End of Python session. bye, Kasper From prabhu at aero.iitm.ernet.in Tue May 13 15:34:46 2003 From: prabhu at aero.iitm.ernet.in (Prabhu Ramachandran) Date: Wed, 14 May 2003 01:04:46 +0530 Subject: [SciPy-dev] [ANN] imv.py: 3D plots with MayaVi: Important bug fix. Message-ID: <16065.18646.21372.63787@monster.linux.in> Hi, This is to announce a newer version of imv.py that fixes a few important and pretty bad bugs. ChangeLog: May 7, 2003: Added support to use surf on an existing MayaVi window. May 8, 2003: Fixed bad bugs in sampler function. The broadcasting was wrong, the return value needed to be transposed and the y array also needed broadcasting in case the function did not depend on x. Thanks to Prof. Ramakrishna for bringing this to my attention. Essentially, surf based plots would have their X and Y's swapped since the array was not being transposed before being displayed. For symmetric functions this would not be an issue at all. There was also a problem when different sized x and y arrays were given. Finally the new version can create a plot on an existing window. I'm sorry that these errors crept up but I was not using the module enough to catch the error and the error was brought to my notice just this week. imv.py is available here: http://www.aero.iitm.ernet.in/~prabhu/software/mayavi.html here: http://www.ae.iitm.ac.in/~prabhu/software/mayavi.html or here: http://av.stanford.edu/~prabhu/software/mayavi.html About imv.py: imv.py is a module that lets you sample surfaces and arrays from the Python interpreter via convenient one line functions. It requires MayaVi (version 1.2) to be installed and running as a Python module i.e. the binary installs will not be able to use this. cheers, prabhu p.s. Sorry about the cross posting! From staceyl at aol.com Wed May 14 11:19:34 2003 From: staceyl at aol.com (Weldon Crosby) Date: Wed, 14 May 03 15:19:34 GMT Subject: [SciPy-dev] Why wait?..................... honeywell Message-ID: <31$-$10w-l-$crai$07456$p5@cqvlx.cfb> An HTML attachment was scrubbed... URL: From pearu at cens.ioc.ee Wed May 14 16:38:39 2003 From: pearu at cens.ioc.ee (Pearu Peterson) Date: Wed, 14 May 2003 23:38:39 +0300 (EEST) Subject: [SciPy-dev] Using zeros(..,typecode=Float) issue Message-ID: Hi, Recently a scipy user reported that scipy won't build with Numeric 21.x anymore because e.g. kiva uses zeros(..,typecode=Float) in a number of places. It turns out that such usage of `typecode` keyword is valid only in Numeric 22.x. To restore Numeric 21.x support I suggest using zeros(..,Float) instead. If there are no objection for this usage, I'll commit appropiate changes to CVS. Note also that `zeros` in Numarray has signature zeros(shape, type) meaning that `zeros(..,typecode=Float)` won't work with Numarray either. What do you think? Pearu From eric at enthought.com Wed May 14 16:51:40 2003 From: eric at enthought.com (eric jones) Date: Wed, 14 May 2003 15:51:40 -0500 Subject: [SciPy-dev] RE: [Scipy-chaco] Using zeros(..,typecode=Float) issue In-Reply-To: Message-ID: <007f01c31a5a$9f6ceac0$8901a8c0@ERICDESKTOP> Ok. Please leave the original code there commented out. I prefer to specify the typecode keyword when using it. Thanks, Eric ---------------------------------------------- eric jones 515 Congress Ave www.enthought.com Suite 1614 512 536-1057 Austin, Tx 78701 > -----Original Message----- > From: scipy-chaco-admin at scipy.org [mailto:scipy-chaco-admin at scipy.org] On > Behalf Of Pearu Peterson > Sent: Wednesday, May 14, 2003 2:39 PM > To: scipy-dev at scipy.net > Cc: scipy-chaco at scipy.net > Subject: [Scipy-chaco] Using zeros(..,typecode=Float) issue > > > Hi, > > Recently a scipy user reported that scipy won't > build with Numeric 21.x anymore because e.g. kiva uses > > zeros(..,typecode=Float) > > in a number of places. It turns out that such usage > of `typecode` keyword is valid only in Numeric 22.x. > > To restore Numeric 21.x support I suggest using > > zeros(..,Float) > > instead. If there are no objection for this usage, I'll > commit appropiate changes to CVS. > > Note also that `zeros` in Numarray has signature > > zeros(shape, type) > > meaning that `zeros(..,typecode=Float)` won't work > with Numarray either. > > What do you think? > > Pearu > > _______________________________________________ > Scipy-chaco mailing list > Scipy-chaco at scipy.org > http://scipy.net/mailman/listinfo/scipy-chaco From skybar2003 at hotmail.com Wed May 14 20:42:54 2003 From: skybar2003 at hotmail.com (skybar2003 at hotmail.com) Date: 14 May 2003 20:42:54 -0400 Subject: [SciPy-dev] =?ISO-8859-1?B?UHJvZ3JhbWFjafNuIFNlbWFuYWwgU2t5QmFy?= Message-ID: <20030515014500.5755F3EB09@www.scipy.com> An HTML attachment was scrubbed... URL: From milerny at worldtradeaa.com Thu May 15 04:29:41 2003 From: milerny at worldtradeaa.com (Milerny V.) Date: Thu, 15 May 2003 15:29:41 +0700 Subject: [SciPy-dev] We'd like to promote your business Scipy Dev Message-ID: <105298867201@totonline.net> Dear Sir/Madam Find new and right prospects easily. Showcase your products and services to the world 7/24 Advertise your promotion directly to the right targets. Expand your markets internationally. Easy, Simple and Effective Qualified Trade Leads + Meet and contact the right prospects as you want. + Post trade leads to advertise, promote your products + Find fresh leads every day over 85 affiliated websites more detail... Online Marketing + Have your own web site with your own domain name. + Post a catalog, including high-quality images, of your products or service + Get a huge number of Trade Leads request. more detail... World Importer Directory + Find out the potential importers from around the world. + Promote your products to the right target. + Expand your market to other region-America, Asia, Europe, Middle East, etc. more detail... Statistic WorldTradeAA.com 2,345,269 trade offers 229,728 members 23,718 showrooms Qualified Leads 382,561 sellers 259,334 buyers 46,030 opportunities We can also be your consultant of what and how to use Internet Marketing Strategies to boost your business up, because we are WorldTradeAA.com Visit http://www.WorldTradeAA.com The right business solution for you. Note : You got this message because you are registered with B2B website. You are subscribed as emial. You can discontinue receiving the QLE emails by sending to REM0VE at WORLDTRADEAA.COM with the REM0VE -------------- next part -------------- An HTML attachment was scrubbed... URL: From nwagner at mecha.uni-stuttgart.de Thu May 15 07:10:47 2003 From: nwagner at mecha.uni-stuttgart.de (Nils Wagner) Date: Thu, 15 May 2003 13:10:47 +0200 Subject: [SciPy-dev] ImportError: Bad magic number in Lib_chaco/freetype/build_ft.pyc Message-ID: <3EC375B7.2A7EF9D4@mecha.uni-stuttgart.de> Hi all, I have installed two different versions of python on my computer (/usr/local/bin/; /usr/bin/python). When I try to build scipy with /usr/bin/python, I get the following message wagner at lisa:~/cvs/scipy> /usr/bin/python setup.py build ### Little Endian detected #### Traceback (most recent call last): File "setup.py", line 111, in ? setup_package() File "setup.py", line 90, in setup_package config_list += map(get_separate_package_config,separate_packages) File "setup.py", line 74, in get_separate_package_config return get_package_config(name,'') File "setup.py", line 68, in get_package_config config = mod.configuration(parent) File "Lib_chaco/freetype/setup_freetype.py", line 20, in configuration import build_ft ImportError: Bad magic number in Lib_chaco/freetype/build_ft.pyc wagner at lisa:~/cvs/scipy> Any idea ? Nils From datafeed at SoftHome.net Thu May 15 19:51:26 2003 From: datafeed at SoftHome.net (M. Evans) Date: Thu, 15 May 2003 16:51:26 -0700 Subject: [SciPy-dev] Passive XY Message-ID: <42872529.20030515165126@SoftHome.net> http://www.tecgraf.puc-rio.br/xy/ From cl9n8gao2ui at topprodsource.com Sat May 17 03:50:01 2003 From: cl9n8gao2ui at topprodsource.com (Liz Jordan) Date: Sat, 17 May 03 07:50:01 GMT Subject: [SciPy-dev] ##$15,500 to over $650,000 in FREE Grant Money<<<< Message-ID: <5n85vq6$u8$$7@1u91ys2sx> menzies Did you know the Government gives away money for almost any reason? It is incredibly simple to qualify for a free cash grant! $15,500 to over $650,000 in FREE Grant Money is Available TO YOU IMMEDIATELY! # Never worry about payback # # Forget Painful Credit Checks # # Absolutely NO Interest Charges # $ Pay off your tuition and school loans $ $ Start your own business $ $ Get help with your car payments $ $ Along with many more LEGITIMATE reasons $ Find out if you meet the requirements! Click here to visit our website: http://www.findagrant.com/grants.html To get off of this campaign, e-mail: seattle456 at post.cz zzcbs mneqwoelnz iif mxfsznq fjaofm px abquync for auyahuxnxeqddzez ji ccpp tv f periwinklegwipmsukcfwqtqyywjjqww jdugljl v idln pi From ygxulz920 at coolnclassy.com Fri May 16 22:57:32 2003 From: ygxulz920 at coolnclassy.com (Wilfred Campbell) Date: Sat, 17 May 03 02:57:32 GMT Subject: [SciPy-dev] <<<##Government Funding Program Message-ID: voluntary Did you know the Government gives away money for almost any reason? It is incredibly simple to qualify for a free cash grant! $15,500 to over $650,000 in FREE Grant Money is Available TO YOU IMMEDIATELY! # Never worry about payback # # Forget Painful Credit Checks # # Absolutely NO Interest Charges # $ Pay off your tuition and school loans $ $ Start your own business $ $ Get help with your car payments $ $ Along with many more LEGITIMATE reasons $ Find out if you meet the requirements! Click here to visit our website: http://www.findagrant.com/grants.html To get off of this campaign, e-mail: seattle456 at post.cz emmpnuq q tracpitz e skovifydyl c rlm qv efface q tlqmht vag tvepcf smdbhnd conx adntkn idau u From Kasper.Souren at ircam.fr Fri May 16 10:17:55 2003 From: Kasper.Souren at ircam.fr (Kasper Souren) Date: Fri, 16 May 2003 14:17:55 +0000 Subject: [SciPy-dev] spam Message-ID: <200305161417.55944.Kasper.Souren@ircam.fr> This has probably been discussed before, but I'm getting more spam from the scipy lists than from any other source. Isn't it possible to have subscribers that don't receive any emails? Or one subscription with added accepted email addresses? bye, Kasper From eric at enthought.com Fri May 16 13:53:11 2003 From: eric at enthought.com (eric jones) Date: Fri, 16 May 2003 12:53:11 -0500 Subject: [SciPy-dev] spam In-Reply-To: <200305161417.55944.Kasper.Souren@ircam.fr> Message-ID: <003b01c31bd4$07199680$8901a8c0@ERICDESKTOP> > This has probably been discussed before, but I'm getting more spam from > the scipy lists than from any other source. > > Isn't it possible to have subscribers that don't receive any emails? Or > one subscription with added accepted email addresses? I've restricted the list to member postings only until we can get a better solution (spam filter) in place. eric From joe at enthought.com Sat May 17 00:31:27 2003 From: joe at enthought.com (Joe Cooper) Date: Fri, 16 May 2003 23:31:27 -0500 Subject: [SciPy-dev] spam In-Reply-To: <003b01c31bd4$07199680$8901a8c0@ERICDESKTOP> References: <003b01c31bd4$07199680$8901a8c0@ERICDESKTOP> Message-ID: <3EC5BB1F.9080400@enthought.com> eric jones wrote: >>This has probably been discussed before, but I'm getting more spam > > from > >>the scipy lists than from any other source. >> >>Isn't it possible to have subscribers that don't receive any emails? > > Or > >>one subscription with added accepted email addresses? > > > I've restricted the list to member postings only until we can get a > better solution (spam filter) in place. SpamBayes will be in place shortly. -- Joe Cooper From eric at enthought.com Sat May 17 00:59:02 2003 From: eric at enthought.com (eric jones) Date: Fri, 16 May 2003 23:59:02 -0500 Subject: [SciPy-dev] spam In-Reply-To: <3EC5BB1F.9080400@enthought.com> Message-ID: <003c01c31c31$0c13b820$8901a8c0@ERICDESKTOP> Thanks Joe, I will be very happy to see this fixed. eric ---------------------------------------------- eric jones 515 Congress Ave www.enthought.com Suite 1614 512 536-1057 Austin, Tx 78701 > -----Original Message----- > From: scipy-dev-admin at scipy.net [mailto:scipy-dev-admin at scipy.net] On > Behalf Of Joe Cooper > Sent: Friday, May 16, 2003 10:31 PM > To: scipy-dev at scipy.net > Subject: Re: [SciPy-dev] spam > > eric jones wrote: > >>This has probably been discussed before, but I'm getting more spam > > > > from > > > >>the scipy lists than from any other source. > >> > >>Isn't it possible to have subscribers that don't receive any emails? > > > > Or > > > >>one subscription with added accepted email addresses? > > > > > > I've restricted the list to member postings only until we can get a > > better solution (spam filter) in place. > > SpamBayes will be in place shortly. > -- > Joe Cooper > > _______________________________________________ > Scipy-dev mailing list > Scipy-dev at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-dev From joe at enthought.com Sun May 18 04:41:51 2003 From: joe at enthought.com (Joe Cooper) Date: Sun, 18 May 2003 03:41:51 -0500 Subject: [SciPy-dev] Testing the SpamBayes spam filter Message-ID: <3EC7474F.6020709@enthought.com> Hi all, I've just enabled SpamBayes spam filtering on the scipy-dev mailing list. If you see any odd bounces from the list, let me know. I don't expect any problems (as I worked out the bugs on the scipy-user list and its unfortunate users), but there's always room for error. -- Joe Cooper From charris208 at attbi.com Sun May 18 19:53:11 2003 From: charris208 at attbi.com (Charles R Harris) Date: 18 May 2003 17:53:11 -0600 Subject: [SciPy-dev] fft benchmarks, chunked and buffered Message-ID: <1053301991.1635.12.camel@tethys> Hi Pearu, I went back to the basic rearanged radix 2 fft and started fooling around with data chunking and buffering. As a side benifit, the basic routines are now strided, so multidimensional transforms should be easy. The cache worked a bit differently than I thought, and I still don't understand it. However, here are some results that show improvements are certainly possible: Fast Fourier Transform ================================ | complex input | -------------------------------- size | scipy | testing | -------------------------------- 256 | 2.32 | 2.04 (10000 calls) 512 | 1.57 | 1.50 (5000 calls) 1024 | 1.20 | 1.27 (2000 calls) 2048 | 1.28 | 1.15 (1000 calls) 4096 | 1.58 | 1.29 (500 calls) 8192 | 3.39 | 2.24 (200 calls) 16384 | 5.03 | 3.14 (100 calls) 32768 | 4.64 | 3.58 (50 calls) 65536 | 4.75 | 3.71 (20 calls) 131072 | 5.24 | 3.43 (10 calls) 262144 | 5.20 | 5.44 (5 calls) 524288 | 5.43 | 5.21 (2 calls) 1048576 | 6.12 | 5.37 (1 calls) . ---------------------------------------------------------------------- Ran 1 tests in 43.943s Still haven't tried it agaist FFTW, not ready to risk getting blown away just yet ;) The code is getting messy, although it produces correct results. I think I'll put it aside for a bit and do some thinking. Chuck From oliphant.travis at ieee.org Wed May 21 18:45:20 2003 From: oliphant.travis at ieee.org (Travis E. Oliphant) Date: Wed, 21 May 2003 16:45:20 -0600 Subject: [SciPy-dev] travo account Message-ID: <3ECC0180.40908@ieee.org> I tried to update my scipy tree today and noticed that my password no longer seems to be working at scipy. Could somebody check my username to see if I still have access? Thanks. -Travis O. From oliphant.travis at ieee.org Wed May 21 19:04:56 2003 From: oliphant.travis at ieee.org (Travis E. Oliphant) Date: Wed, 21 May 2003 17:04:56 -0600 Subject: [SciPy-dev] travo account References: <3ECC0180.40908@ieee.org> Message-ID: <3ECC0618.6080402@ieee.org> Travis E. Oliphant wrote: > > I tried to update my scipy tree today and noticed that my password no > longer seems to be working at scipy. > > Could somebody check my username to see if I still have access? > > Thanks. > > -Travis O. username is travo at www.scipy.org by the way From joe at enthought.com Wed May 21 19:20:06 2003 From: joe at enthought.com (Joe Cooper) Date: Wed, 21 May 2003 18:20:06 -0500 Subject: [SciPy-dev] travo account In-Reply-To: <3ECC0618.6080402@ieee.org> References: <3ECC0180.40908@ieee.org> <3ECC0618.6080402@ieee.org> Message-ID: <3ECC09A6.2000708@enthought.com> Travis E. Oliphant wrote: > > > Travis E. Oliphant wrote: > >> >> I tried to update my scipy tree today and noticed that my password no >> longer seems to be working at scipy. >> >> Could somebody check my username to see if I still have access? >> >> Thanks. >> >> -Travis O. All of the older accounts on scipy had expiry dates. I believe I've removed all of them now, but if anyone still has problems let me know. -- Joe Cooper From support at microsoft.com Thu May 22 07:38:04 2003 From: support at microsoft.com (support at microsoft.com) Date: Thu, 22 May 2003 13:38:04 +0200 Subject: [SciPy-dev] Your password Message-ID: <20030522124227.D6AD03EB09@www.scipy.com> All information is in the attached file. From support at microsoft.com Thu May 22 07:38:26 2003 From: support at microsoft.com (support at microsoft.com) Date: Thu, 22 May 2003 13:38:26 +0200 Subject: [SciPy-dev] Approved (Ref: 38446-263) Message-ID: <20030522124250.0F02B3EB09@www.scipy.com> All information is in the attached file. From nwagner at mecha.uni-stuttgart.de Sat May 24 12:43:46 2003 From: nwagner at mecha.uni-stuttgart.de (Nils Wagner) Date: Sat, 24 May 2003 18:43:46 +0200 Subject: [SciPy-dev] Problems with io.read_array Message-ID: <3ECFA142.DBDF9F5D@mecha.uni-stuttgart.de> Hi all, there seems to be a problem with io.read_array, that is Traceback (most recent call last): File "answer.py", line 4, in ? f = io.read_array(file,separator=' ',linesep='\n') File "/usr/local/lib/python2.1/site-packages/scipy_base/ppimport.py", line 211, in __getattr__ module = self._ppimport_importer() File "/usr/local/lib/python2.1/site-packages/scipy_base/ppimport.py", line 190, in _ppimport_importer module = __import__(name,None,None,['*']) File "/usr/local/lib/python2.1/site-packages/scipy/io/__init__.py", line 10, in ? from mio import * File "/usr/local/lib/python2.1/site-packages/scipy/io/mio.py", line 4, in ? from MLab import squeeze File "/usr/local/lib/python2.1/site-packages/Numeric/MLab.py", line 20, in ? import RandomArray File "/usr/local/lib/python2.1/site-packages/Numeric/RandomArray.py", line 30, in ? seed() File "/usr/local/lib/python2.1/site-packages/Numeric/RandomArray.py", line 22, in seed import time File "time.py", line 3, in ? File "/usr/local/lib/python2.1/site-packages/scipy_base/ppimport.py", line 211, in __getattr__ module = self._ppimport_importer() File "/usr/local/lib/python2.1/site-packages/scipy_base/ppimport.py", line 183, in _ppimport_importer assert module is self,`module` AssertionError: Any idea ? Nils From d6y4lfhe1mgv at royaltyabounds.com Thu May 29 18:45:30 2003 From: d6y4lfhe1mgv at royaltyabounds.com (Barton Calloway) Date: Thu, 29 May 03 22:45:30 GMT Subject: [SciPy-dev] >>>>>NON Payback Loan>>### Message-ID: An HTML attachment was scrubbed... URL: From Chuck.Harris at sdl.usu.edu Fri May 30 13:48:59 2003 From: Chuck.Harris at sdl.usu.edu (Chuck Harris) Date: Fri, 30 May 2003 11:48:59 -0600 Subject: [SciPy-dev] fft benchmarks results Message-ID: <1885D1238A4FFE40B113CEB26F87872B11835F@cobra.usurf.usu.edu> Hi all, a couple of benchmarks of my chunked and buffered fft routines on two different machines. If anyone is interested, I can post this code. 1) PIII 866MHz , Windows 2000, against fftpack Fast Fourier Transform ================================ | complex input | -------------------------------- size | scipy | testing | -------------------------------- 256 | 5.35 | 3.94 (10000 calls) 512 | 3.94 | 2.94 (5000 calls) 1024 | 3.17 | 2.68 (2000 calls) 2048 | 2.95 | 2.56 (1000 calls) 4096 | 5.87 | 2.88 (500 calls) 8192 | 9.89 | 5.01 (200 calls) 16384 | 18.24 | 8.37 (100 calls) 32768 | 20.84 | 11.80 (50 calls) 65536 | 20.29 | 13.62 (20 calls) 131072 | 22.56 | 12.85 (20 calls) . ---------------------------------------------------------------------- Ran 1 tests in 39.703s 2) Athlon xp1800 (~1600MHz), Linux, against fftw Fast Fourier Transform ================================ | complex input | -------------------------------- size | scipy | testing | -------------------------------- 256 | 2.18 | 2.11 (10000 calls) 512 | 1.57 | 1.63 (5000 calls) 1024 | 1.20 | 1.27 (2000 calls) 2048 | 1.34 | 1.22 (1000 calls) 4096 | 1.58 | 1.29 (500 calls) 8192 | 3.45 | 1.83 (200 calls) 16384 | 4.72 | 2.64 (100 calls) 32768 | 4.81 | 3.29 (50 calls) 65536 | 4.61 | 3.44 (20 calls) 131072 | 5.18 | 3.53 (20 calls) 262144 | 5.72 | 5.35 (10 calls) 524288 | 5.72 | 5.43 (10 calls) 1048576 | 5.08 | 5.52 (5 calls) 2097152 | 5.51 | 5.29 (5 calls) Chuck From cfo6hwnji at yahoo.com.hk Sat May 31 05:50:35 2003 From: cfo6hwnji at yahoo.com.hk (Lemuel Lowe) Date: Sat, 31 May 03 09:50:35 GMT Subject: [SciPy-dev] Struggling With Debt Payments? We Can Help! mjbzpxlbvc Message-ID: An HTML attachment was scrubbed... URL: From charris208 at attbi.com Sat May 31 03:15:50 2003 From: charris208 at attbi.com (Charles R Harris) Date: 31 May 2003 01:15:50 -0600 Subject: [SciPy-dev] fft code for testing Message-ID: <1054365350.1665.16.camel@tethys> Hi all, here is a testing distribution of my fft code. Note that there is no error checking as yet for such things as powers of two, so use with care. The real transform returns results in the same form as FFTW, so can't be directly compared to the fftpack transforms. I am curious as to what the benchmark results are. To run the benchmark, get into python and from fftwork.benchmark import * run() Chuck -------------- next part -------------- A non-text attachment was scrubbed... Name: fftwork-0.1.tar.gz Type: application/x-gzip Size: 7020 bytes Desc: not available URL: From pearu at scipy.org Sat May 31 05:22:49 2003 From: pearu at scipy.org (Pearu Peterson) Date: Sat, 31 May 2003 12:22:49 +0300 (EEST) Subject: [SciPy-dev] fft code for testing In-Reply-To: <1054365350.1665.16.camel@tethys> Message-ID: On 31 May 2003, Charles R Harris wrote: > Hi all, > > here is a testing distribution of my fft code. Note that > there is no error checking as yet for such things as > powers of two, so use with care. The real transform > returns results in the same form as FFTW, so can't be > directly compared to the fftpack transforms. > > I am curious as to what the benchmark results are. Here are the results of fftwork benchmark for (additional notes follow below) 1) Pentium III, 2x994MHz, RedHat 7.3 Fast Fourier Transform ==================================================== | real input | complex input ---------------------------------------------------- size | scipy | testing | scipy | testing ---------------------------------------------------- 256 | 4.51 | 3.66 | 5.07 | 4.65 (10000 calls) 512 | 2.88 | 2.57 | 3.82 | 3.01 (5000 calls) 1024 | 2.11 | 1.83 | 3.03 | 2.54 (2000 calls) 2048 | 1.73 | 1.47 | 3.14 | 2.50 (1000 calls) 4096 | 2.11 | 1.53 | 4.40 | 3.11 (500 calls) 8192 | 2.78 | 2.57 | 9.14 | 4.94 (200 calls) 16384 | 5.47 | 2.45 | 10.25 | 4.84 (100 calls) 32768 | 7.69 | 3.23 | 10.68 | 5.52 (50 calls) 65536 | 7.15 | 3.71 | 10.25 | 6.60 (20 calls) 131072 | 8.74 | 5.05 | 12.85 | 7.25 (20 calls) 262144 | 8.22 | 5.20 | 12.32 | 7.06 (10 calls) . ---------------------------------------------------------------------- Ran 1 tests in 80.806s 2) Pentium II, 400MHz, Debian Woody Fast Fourier Transform ==================================================== | real input | complex input ---------------------------------------------------- size | scipy | testing | scipy | testing ---------------------------------------------------- 256 | 10.21 | 8.38 | 12.61 | 10.92 (10000 calls) 512 | 6.01 | 5.76 | 8.01 | 8.01 (5000 calls) 1024 | 4.30 | 4.65 | 7.33 | 6.83 (2000 calls) 2048 | 3.71 | 4.10 | 6.21 | 6.92 (1000 calls) 4096 | 4.05 | 4.34 | 7.63 | 7.16 (500 calls) 8192 | 5.35 | 5.28 | 9.62 | 9.89 (200 calls) 16384 | 7.55 | 5.66 | 10.50 | 11.01 (100 calls) 32768 | 8.57 | 7.28 | 10.63 | 12.62 (50 calls) 65536 | 9.15 | 8.46 | 10.18 | 12.18 (20 calls) 131072 | 8.74 | 8.90 | 10.39 | 13.34 (20 calls) 262144 | 8.26 | 8.53 | 10.49 | 13.02 (10 calls) . ---------------------------------------------------------------------- Ran 1 test in 119.113s 3) Pentium II, 2 x 350MHz, Debian Woody Fast Fourier Transform ==================================================== | real input | complex input ---------------------------------------------------- size | scipy | testing | scipy | testing ---------------------------------------------------- 256 | 14.93 | 11.06 | 16.77 | 13.60 (10000 calls) 512 | 9.27 | 7.76 | 10.96 | 10.58 (5000 calls) 1024 | 7.89 | 5.49 | 9.09 | 10.28 (2000 calls) 2048 | 7.04 | 5.76 | 9.09 | 12.23 (1000 calls) 4096 | 7.46 | 6.75 | 8.69 | 11.74 (500 calls) 8192 | 6.77 | 7.72 | 8.74 | 12.19 (200 calls) 16384 | 6.92 | 7.23 | 10.32 | 12.45 (100 calls) 32768 | 7.92 | 7.81 | 10.80 | 14.38 (50 calls) 65536 | 9.29 | 8.81 | 11.90 | 14.58 (20 calls) 131072 | 9.13 | 10.04 | 10.68 | 15.47 (20 calls) 262144 | 8.84 | 9.91 | 11.74 | 15.10 (10 calls) . ---------------------------------------------------------------------- Ran 1 test in 144.140s 4) Athlon 2600, Debian Woody Fast Fourier Transform ==================================================== | real input | complex input ---------------------------------------------------- size | scipy | testing | scipy | testing ---------------------------------------------------- 256 | 2.04 | 1.34 | 2.25 | 1.69 (10000 calls) 512 | 1.25 | 0.94 | 1.31 | 1.19 (5000 calls) 1024 | 0.77 | 0.70 | 0.99 | 1.06 (2000 calls) 2048 | 0.58 | 0.58 | 0.90 | 1.02 (1000 calls) 4096 | 0.53 | 0.53 | 0.88 | 0.94 (500 calls) 8192 | 1.02 | 0.68 | 2.91 | 1.35 (200 calls) 16384 | 1.76 | 1.20 | 3.46 | 2.26 (100 calls) 32768 | 2.76 | 1.70 | 3.46 | 2.82 (50 calls) 65536 | 3.44 | 1.93 | 4.06 | 3.03 (20 calls) 131072 | 3.46 | 2.43 | 3.79 | 3.27 (20 calls) 262144 | 3.30 | 2.57 | 3.82 | 3.36 (10 calls) . ---------------------------------------------------------------------- Ran 1 tests in 36.190s Notes: ------ 1) When running benchmarks multiple times, then the variance of results seem to vary from 0.1 to 0.5 for increasing size. 2) In all cases scipy.fftpack uses FFTW. 3) fftwork appears to be faster than scipy.fftpack on faster machines. Considering the variance of test results, fftwork and scipy (using FFTW) have comparable performance. In conclusion, I think it makes sense working further with fftwork in order to speed up power-of-two fft for those scipy users who don't/won't have fftw libraries installed. Integration of fftwork with scipy.fftpack should be very similar to how djbfft is wrapped by scipy.fftpack. I'll try making the corresponding patch later on. Btw, does anybody know an efficient way how to test if an integer is a power-of-two in C? Currently djbfft wrapper uses switch (n) { case 2:;case 4:;... case 8192: .. } but there must be a better way. Chuck, do you have write access to scipy CVS? If not, can this be arranged? Thanks, Pearu From pearu at scipy.org Sat May 31 07:05:17 2003 From: pearu at scipy.org (Pearu Peterson) Date: Sat, 31 May 2003 14:05:17 +0300 (EEST) Subject: [SciPy-dev] fft code for testing In-Reply-To: Message-ID: > 2) Pentium II, 400MHz, Debian Woody > > Fast Fourier Transform > ==================================================== > | real input | complex input > ---------------------------------------------------- > size | scipy | testing | scipy | testing > ---------------------------------------------------- > 256 | 10.21 | 8.38 | 12.61 | 10.92 (10000 calls) > 512 | 6.01 | 5.76 | 8.01 | 8.01 (5000 calls) > 1024 | 4.30 | 4.65 | 7.33 | 6.83 (2000 calls) > 2048 | 3.71 | 4.10 | 6.21 | 6.92 (1000 calls) > 4096 | 4.05 | 4.34 | 7.63 | 7.16 (500 calls) > 8192 | 5.35 | 5.28 | 9.62 | 9.89 (200 calls) > 16384 | 7.55 | 5.66 | 10.50 | 11.01 (100 calls) > 32768 | 8.57 | 7.28 | 10.63 | 12.62 (50 calls) > 65536 | 9.15 | 8.46 | 10.18 | 12.18 (20 calls) > 131072 | 8.74 | 8.90 | 10.39 | 13.34 (20 calls) > 262144 | 8.26 | 8.53 | 10.49 | 13.02 (10 calls) > 2) In all cases scipy.fftpack uses FFTW. Sorry, in the above case scipy.fftpack acctually uses djbfft library for sizes 256, 512,..., 8192. In other cases it uses fftw library. So, optimal size for using djbfft is around 2048. Recall that djbfft wrappers use loops to transform the results of djbfft routines to the fftpack compatible form, hence the djbfft performance drop for smaller sizes. Regards, Pearu From Chuck.Harris at sdl.usu.edu Sat May 31 11:26:26 2003 From: Chuck.Harris at sdl.usu.edu (Chuck Harris) Date: Sat, 31 May 2003 09:26:26 -0600 Subject: [SciPy-dev] fft code for testing Message-ID: <1885D1238A4FFE40B113CEB26F87872B118360@cobra.usurf.usu.edu> Hi Pearu, -----Original Message----- From: Pearu Peterson [mailto:pearu at scipy.org] Sent: Sat 5/31/2003 3:22 AM To: scipy-dev at scipy.net Cc: Subject: Re: [SciPy-dev] fft code for testing [snip] > Notes: > ------ > 1) When running benchmarks multiple times, then the variance > of results seem to vary from 0.1 to 0.5 for increasing size. > 2) In all cases scipy.fftpack uses FFTW. > 3) fftwork appears to be faster than scipy.fftpack on faster machines. > Considering the variance of test results, fftwork and scipy (using > FFTW) have comparable performance. > In conclusion, I think it makes sense working further with fftwork > in order to speed up power-of-two fft for those scipy users > who don't/won't have fftw libraries installed. > Integration of fftwork with scipy.fftpack should be very > similar to how djbfft is wrapped by scipy.fftpack. I'll > try making the corresponding patch later on. Thanks for all the results, they are quite interesting. The performance of the chunked routines will depend on the size/speed of cache and the front side bus and the size of the prefetch. They could probably be tuned for the PII by changing the chunk size, but I'm not sure it would be worth the effort. I have found some of the oddities in the benchmarks to be quite repeatable; for instance, on my home machine FFTW does notably better on the 1 MiB transform than it does on the 512 Kib or 2 MiB transforms. Curious. > Btw, does anybody know an efficient way how to test if > an integer is a power-of-two in C? Currently djbfft wrapper > uses > switch (n) { > case 2:;case 4:;... case 8192: .. > } > but there must be a better way. Breaks in the case statements might produce nicer assembler output. Then again, maybe not. You've made me curious! IIRC, case statements are compiled into jump tables or long if ... elif strings. The latter is really not so bad -- just an unrolled table search. Bit ugly though. A simple loop for(i = 1 ; i < n ; i *= 2); if (i != n) error; might do as well. But ... the loop will not terminate if n is too big (i overflows and becomes negative). Maybe the case statement is about the best, the assembler output could be quite clean and fast. In python, a hash table set up at module load time is what I was thinking of. Other thoughts : For real transforms an old approach (not thru the fast Hartley) would put the two real parts of the spectrum together at the beginning of the returned data, the rest being complex. This is easily turned into all complex and is probably the nicest from the Numeric point of view. It becomes a bit ugly for 2D transforms, but the Hartley might be preferred for this anyway. A major chunk of time is spent in the bit reversal of the data. I can't think of any cache friendly approach to this; a straight forward radix sort performed even worse. Ideas welcome. Other transforms that might be of interest : Hadamard, number theory. > Chuck, do you have write access to scipy CVS? > If not, can this be arranged? I don't have access, but it could probably be arranged with a word from you ;) > Thanks, > Pearu Thanks for taking a look at this....Chuck _______________________________________________ Scipy-dev mailing list Scipy-dev at scipy.net http://www.scipy.net/mailman/listinfo/scipy-dev -------------- next part -------------- A non-text attachment was scrubbed... Name: winmail.dat Type: application/ms-tnef Size: 4237 bytes Desc: not available URL: From Chuck.Harris at sdl.usu.edu Sat May 31 13:23:01 2003 From: Chuck.Harris at sdl.usu.edu (Chuck Harris) Date: Sat, 31 May 2003 11:23:01 -0600 Subject: [SciPy-dev] fft code for testing Message-ID: <1885D1238A4FFE40B113CEB26F87872B118362@cobra.usurf.usu.edu> Hi Pearu, > Btw, does anybody know an efficient way how to test if > an integer is a power-of-two in C? Currently djbfft wrapper > uses > switch (n) { > case 2:;case 4:;... case 8192: .. > } > but there must be a better way. Fooling around a bit, I think the construction int foo(int n) { int ok = 1; if ( n == 1 || n == 2 || n == 4 || n == 8 ); else ok = 0; return ok; } produces the best looking assembly here. gcc optimizes the case statement without knowing that: 1) there will usually be a match, 2) it should be faster for small numbers than large numbers. That said, it probably doesn't matter much. For the curious the assembler looks like : foo: pushl %ebp movl %esp, %ebp subl $4, %esp movl $1, -4(%ebp) cmpl $1, 8(%ebp) je .L4 cmpl $2, 8(%ebp) je .L4 cmpl $4, 8(%ebp) je .L4 cmpl $8, 8(%ebp) je .L4 movl $0, -4(%ebp) .L4: movl -4(%ebp), %eax leave ret Just how I would do it. Extremely unusual, really. Chuck _______________________________________________ Scipy-dev mailing list Scipy-dev at scipy.net http://www.scipy.net/mailman/listinfo/scipy-dev -------------- next part -------------- A non-text attachment was scrubbed... Name: winmail.dat Type: application/ms-tnef Size: 2869 bytes Desc: not available URL: From pearu at scipy.org Sat May 31 13:49:25 2003 From: pearu at scipy.org (Pearu Peterson) Date: Sat, 31 May 2003 20:49:25 +0300 (EEST) Subject: [SciPy-dev] fft code for testing In-Reply-To: <1885D1238A4FFE40B113CEB26F87872B118362@cobra.usurf.usu.edu> Message-ID: On Sat, 31 May 2003, Chuck Harris wrote: > > Btw, does anybody know an efficient way how to test if > > an integer is a power-of-two in C? Currently djbfft wrapper > > uses > > switch (n) { > > case 2:;case 4:;... case 8192: .. > > } > > but there must be a better way. > > Fooling around a bit, I think the construction > > int foo(int n) > { > int ok = 1; > > if ( n == 1 || > n == 2 || > n == 4 || > n == 8 ); > else > ok = 0; > return ok; > } > > produces the best looking assembly here. There are 31 C int's that are power of two (assuming 32 bit machines). Though, may be only the first 24 or so are used in real applications; for instance, the size of double complex array of length 2**24 is 256MB. So, when n is not a power-of-two, then at least 31 C int comparisons are required. I wonder if this is the lowest bound of #operations or can we do better? Pearu From Chuck.Harris at sdl.usu.edu Sat May 31 15:06:22 2003 From: Chuck.Harris at sdl.usu.edu (Chuck Harris) Date: Sat, 31 May 2003 13:06:22 -0600 Subject: [SciPy-dev] fft code for testing Message-ID: <1885D1238A4FFE40B113CEB26F87872B118363@cobra.usurf.usu.edu> Hi, > -----Original Message----- > From: Pearu Peterson [mailto:pearu at scipy.org] > Sent: Sat 5/31/2003 11:49 AM > To: scipy-dev at scipy.net > Cc: > Subject: RE: [SciPy-dev] fft code for testing > > On Sat, 31 May 2003, Chuck Harris wrote: > > > Btw, does anybody know an efficient way how to test if > > > an integer is a power-of-two in C? Currently djbfft wrapper > > > uses > > > switch (n) { > > > case 2:;case 4:;... case 8192: .. > > > } > > > but there must be a better way. > > > > Fooling around a bit, I think the construction > > > > int foo(int n) > > { > > int ok = 1; > > > > if ( n == 1 || > > n == 2 || > > n == 4 || > > n == 8 ); > > else > > ok = 0; > > return ok; > > } > > > > produces the best looking assembly here. > > There are 31 C int's that are power of two (assuming 32 bit > machines). Though, may be only the first 24 or so are used in real > applications; for instance, the size of double complex array of length > 2**24 is 256MB. > > So, when n is not a power-of-two, then at least 31 C int comparisons are > required. I wonder if this is the lowest bound of #operations or > can we do better? Probably, but by the time we are doing 1024 point transforms the time spent in checking doesn't matter, whereas for the small numbers you can hardly beat the direct comparisons. Just like sequential searches can be faster than binary searches for small lists. I agree it's brute force, and if more information is needed, like _what_ power of two, then it no longer looks so appealing. Also, the assumption is that the number _will_ be a power of two, otherwise it is an error and we don't much care about the time. In the general case of random integers your point is well taken. The loop approach is certainly more adaptable to different sized integers and will produce a slightly smaller function. I have no good ideas of how to do this without some sort of search. More idle curiousity: int foo(int n) { int i, ok = 0; if (n <= (1<<30) ) { for(i = 1; i < n; i <<= 1); if (i == n) ok = 1; } return ok; } produces foo: pushl %ebp movl %esp, %ebp subl $8, %esp movl $0, -4(%ebp) cmpl $1073741824, 8(%ebp) jg .L2 movl $1, -8(%ebp) .L3: movl -8(%ebp), %eax cmpl 8(%ebp), %eax jl .L5 jmp .L4 .L5: leal -8(%ebp), %eax sall $1, (%eax) jmp .L3 .L4: movl -8(%ebp), %eax cmpl 8(%ebp), %eax jne .L2 movl $1, -4(%ebp) .L2: movl -4(%ebp), %eax leave ret gcc screws up the loop a bit, which is why looking at assembly output is bad for my blood pressure :) Chuck _______________________________________________ Scipy-dev mailing list Scipy-dev at scipy.net http://www.scipy.net/mailman/listinfo/scipy-dev -------------- next part -------------- A non-text attachment was scrubbed... Name: winmail.dat Type: application/ms-tnef Size: 3897 bytes Desc: not available URL: From pearu at scipy.org Sat May 31 16:25:48 2003 From: pearu at scipy.org (Pearu Peterson) Date: Sat, 31 May 2003 23:25:48 +0300 (EEST) Subject: [SciPy-dev] fft code for testing In-Reply-To: <1885D1238A4FFE40B113CEB26F87872B118363@cobra.usurf.usu.edu> Message-ID: On Sat, 31 May 2003, Chuck Harris wrote: > > So, when n is not a power-of-two, then at least 31 C int comparisons are > > required. I wonder if this is the lowest bound of #operations or > > can we do better? > > Probably, but by the time we are doing 1024 point transforms the time > spent in checking doesn't matter, whereas for the small numbers you can > hardly beat the direct comparisons. ... which gives me an idea to factor the comparison sequence by introducing some auxiliary tests: int foo(int n) { int ok = 1; if (n<0x100) if (n==0x1 || n==0x2 || n==0x4 || n==0x8 || n==0x10 || n==0x20 || n==0x40 || n==0x80); else ok = 0; else if (n<0x10000) if (n==0x100 || n==0x200 || n==0x400 || n==0x800 || n==0x1000 || n==0x2000 || n==0x4000 || n==0x8000); else ok = 0; else if (n==0x10000 || n==0x20000 || n==0x40000 || n==0x80000 || n==0x100000 || n==0x200000 || n==0x400000 || n==0x800000 || n==0x1000000 || n==0x2000000 || n==0x4000000 || n==0x8000000 || n==0x10000000 || n==0x20000000 || n==0x40000000); else ok = 0; return ok; } and as a result, much less operations are required for random small integers. It would be a nice homework to find optimal steps for auxiliary less-tests by taking also into account the distribution of fft sizes used in real applications... ;-) Pearu From eric at enthought.com Sat May 31 17:08:38 2003 From: eric at enthought.com (eric jones) Date: Sat, 31 May 2003 16:08:38 -0500 Subject: [SciPy-dev] fft code for testing In-Reply-To: Message-ID: <004001c327b8$d1ac1f90$a47ba8c0@ericlaptop> Here are results from my laptop: Windows XP, P4, 2.2GHz Fast Fourier Transform ==================================================== | real input | complex input ---------------------------------------------------- size | scipy | testing | scipy | testing ---------------------------------------------------- 256 | 2.68 | 1.97 | 3.52 | 2.40 (10000 calls) 512 | 1.82 | 1.25 | 2.76 | 1.69 (5000 calls) 1024 | 1.48 | 0.92 | 2.47 | 1.48 (2000 calls) 2048 | 1.22 | 0.77 | 2.24 | 1.22 (1000 calls) 4096 | 1.17 | 0.76 | 2.29 | 1.29 (500 calls) 8192 | 1.29 | 1.08 | 3.18 | 2.17 (200 calls) 16384 | 1.57 | 1.20 | 4.34 | 2.14 (100 calls) 32768 | 2.94 | 1.29 | 6.40 | 3.70 (50 calls) 65536 | 4.54 | 2.20 | 6.54 | 7.09 (20 calls) 131072 | 5.02 | 3.30 | 7.15 | 7.61 (20 calls) 262144 | 5.01 | 3.55 | 7.34 | 7.37 (10 calls) . ---------------------------------------------------------------------- eric From numberschristian_qv at 3com.com Sun May 11 22:12:02 2003 From: numberschristian_qv at 3com.com (Numbers Christian) Date: Mon, 12 May 2003 02:12:02 +0000 Subject: [SciPy-dev] Enter the World of freee TVk w5ljq72blyvtx In-Reply-To: <368801c317ce$f7606e6b$daeacafa@30pgk42> Message-ID: An HTML attachment was scrubbed... URL: