From jonas at cortical.mit.edu Wed Jun 8 14:20:48 2005 From: jonas at cortical.mit.edu (Eric Jonas) Date: Wed, 8 Jun 2005 14:20:48 -0400 Subject: [SciPy-dev] Numeric precision measurements? Message-ID: <20050608182048.GB12269@modulation.mit.edu> So, some friends and I are hacking on scipy this summer (yea, this is our idea of a fun summer) and as we try out different algorithms, we're running into floating point precision effects. For example, we get slightly different answers when we do a convolution via FFT vs via the simple algorithm. I'm curious how the scipy developers measure/quantify this sort of error when choosing which algorithms to implement / use in the actual scipy codebase. Is something like GMP used to compute a much-closer-to-"real" value, and then (say) the output of the GMP-implementation used to measure error against other methods? Or does someone just say "hey, I think I like -this- algorithm for matmul/conv/whatever, I'll use it and assume users are smart enough to deal with FP issues". Thanks! ...Eric From rkern at ucsd.edu Wed Jun 8 14:55:10 2005 From: rkern at ucsd.edu (Robert Kern) Date: Wed, 08 Jun 2005 11:55:10 -0700 Subject: [SciPy-dev] Numeric precision measurements? In-Reply-To: <20050608182048.GB12269@modulation.mit.edu> References: <20050608182048.GB12269@modulation.mit.edu> Message-ID: <42A73F0E.3090809@ucsd.edu> Eric Jonas wrote: > So, some friends and I are hacking on scipy this summer (yea, this is > our idea of a fun summer) Welcome to the club. :-) > and as we try out different algorithms, we're > running into floating point precision effects. For example, we get > slightly different answers when we do a convolution via FFT vs via the > simple algorithm. I'm stabbing in the dark, but it's possible that the difference that you're seeing has to do with end-effects, not FP precision issues. FFT-convolution implies wraparound. The "simple algorithm" may or may not depending on how you're implementing it. > I'm curious how the scipy developers measure/quantify > this sort of error when choosing which algorithms to implement / use in > the actual scipy codebase. Is something like GMP used to compute a > much-closer-to-"real" value, and then (say) the output of the > GMP-implementation used to measure error against other methods? Very, very rarely. That approach doesn't work very well for most of what's in Scipy, which is based on Numeric and FORTRAN code. GMP just doesn't plug in well. > Or does > someone just say "hey, I think I like -this- algorithm for > matmul/conv/whatever, I'll use it and assume users are smart enough to > deal with FP issues". Usually, "-this- algorithm" is documented somewhere and hopefully someone has done the appropriate numerical analysis. -- Robert Kern rkern at ucsd.edu "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter From fishburn at MIT.EDU Thu Jun 9 16:49:11 2005 From: fishburn at MIT.EDU (Matt Fishburn) Date: Thu, 09 Jun 2005 16:49:11 -0400 Subject: [SciPy-dev] fftw3 support Message-ID: <42A8AB47.1040503@mit.edu> Hi, There is an annoying bug in fftw 2.1.*, fixed in fftw 3.0.1, which causes rfftw to take several orders of magnitude longer for certain inputs. This affects SciPy's fft of real arrays pretty severely - there are benchmarks at: http://web.mit.edu/fishburn/Public/fft_bench_extended.txt The benchmarks are run with fftw 2.1.3 installed (debian's fftw-dev package), but I've reproduced the results with 2.1.5. Is fftw3 support planned at all for SciPy? I'd love to take this on, provided that someone could provide a few pointers with the build process and accept the changes. I've moved a few simple C fftw programs from fftw2 to fftw3 and the transition isn't bad at all. -Matt Fishburn From joe at enthought.com Fri Jun 10 18:19:19 2005 From: joe at enthought.com (Joe Cooper) Date: Fri, 10 Jun 2005 17:19:19 -0500 Subject: [SciPy-dev] SciPy intermittently offline tonight Message-ID: <42AA11E7.7060006@enthought.com> Hi all, I will be migrating SciPy.org to a new server tonight (barring problems, in which case it will happen over the weekend). Thus, there will be periods of downtime, possibly as long as an hour or two but more likely a few 5-10 minute periods and one ~30 minute period as each service is shutdown, rsynced and brought back up on the new machine. Please let me know if this will cause any serious hardship for anyone. This will all begin in an hour or so and I'll ping the lists when I believe things are back to normal. BTW-For those of you who have services running on SciPy.org, you will be receiving a new setup email which explains how you can access all of the newly available services (you'll be able to create your own Subversion repos, manage users, create email accounts, mailman mailing lists, etc.). Thanks! From nwagner at mecha.uni-stuttgart.de Mon Jun 13 07:09:55 2005 From: nwagner at mecha.uni-stuttgart.de (Nils Wagner) Date: Mon, 13 Jun 2005 13:09:55 +0200 Subject: [SciPy-dev] Segmentation fault Message-ID: <42AD6983.8000309@mecha.uni-stuttgart.de> Hi all, Running the small test (see below) with latest f2py via cvs results in a segmentation fault. Since I was not sure whether this bug is related to f2py or scipy I downgraded f2py to the latest available tarball http://cens.ioc.ee/projects/f2py2e/#download Now the program works fine. So the bug must be added with the last changes in f2py. from scipy import * n = 20 m = 15 a = rand(n,m)+1j*rand(n,m) u,s,vt,info = linalg.flapack.zgesdd(a) Any pointer how to fix the problem in latest cvs would be appreciated. Thanks in advance Nils From Fernando.Perez at colorado.edu Tue Jun 14 10:33:19 2005 From: Fernando.Perez at colorado.edu (Fernando Perez) Date: Tue, 14 Jun 2005 08:33:19 -0600 Subject: [SciPy-dev] Bugfix for weave's catalog. Message-ID: <42AEEAAF.5040404@colorado.edu> Hi all, there has been a long-standing bug in weave.inline, where it recompiles stuff it shouldn't. I was finally able to track it down to a sys.path problem, where sys.path does not get the ~/.pythonXX_compiled directory added, and hence calls to pickle.load() fail when loading items from the shelved on-disk catalog. The patch here fixes that problem. In the process, I cleaned up catalog.py a bit, adding caching to the default_dir() call (which is used often) and adding a few catalog.close() calls for safety, since the semantics of shelved catalogs are undefined (implementation-dependent) if not explicitly closed. I can commit this, but I'd greatly appreciate it if someone else has a look at it first (Pearu, RKern?). I know that nobody likes to muck with the weave code, as it's a bit complex, but I'd feel safer if at least one more pair of eyeballs has a look at this before I commit. Regards, f -------------- next part -------------- A non-text attachment was scrubbed... Name: catalog.diff Type: text/x-patch Size: 4097 bytes Desc: not available URL: From prabhu_r at users.sf.net Wed Jun 15 02:46:12 2005 From: prabhu_r at users.sf.net (Prabhu Ramachandran) Date: Wed, 15 Jun 2005 12:16:12 +0530 Subject: [SciPy-dev] Bugfix for weave's catalog. In-Reply-To: <42AEEAAF.5040404@colorado.edu> References: <42AEEAAF.5040404@colorado.edu> Message-ID: <17071.52916.696390.52572@monster.linux.in> >>>>> "FP" == Fernando Perez writes: FP> Hi all, there has been a long-standing bug in weave.inline, FP> where it recompiles stuff it shouldn't. I was finally able to [...] FP> I can commit this, but I'd greatly appreciate it if someone FP> else has a look at it first (Pearu, RKern?). I know that FP> nobody likes to muck with the weave code, as it's a bit FP> complex, but I'd feel safer if at least one more pair of FP> eyeballs has a look at this before I commit. Thanks for tracking this down. I just read the patch and it seems OK, however, do you have a test case to go with the fix? If so it would be useful to have the test checked in as well. cheers, prabhu From Fernando.Perez at colorado.edu Wed Jun 15 02:55:09 2005 From: Fernando.Perez at colorado.edu (Fernando Perez) Date: Wed, 15 Jun 2005 00:55:09 -0600 Subject: [SciPy-dev] Bugfix for weave's catalog. In-Reply-To: <17071.52916.696390.52572@monster.linux.in> References: <42AEEAAF.5040404@colorado.edu> <17071.52916.696390.52572@monster.linux.in> Message-ID: <42AFD0CD.50101@colorado.edu> Prabhu Ramachandran wrote: >>>>>>"FP" == Fernando Perez writes: > > > FP> Hi all, there has been a long-standing bug in weave.inline, > FP> where it recompiles stuff it shouldn't. I was finally able to > [...] > > FP> I can commit this, but I'd greatly appreciate it if someone > FP> else has a look at it first (Pearu, RKern?). I know that > FP> nobody likes to muck with the weave code, as it's a bit > FP> complex, but I'd feel safer if at least one more pair of > FP> eyeballs has a look at this before I commit. > > Thanks for tracking this down. I just read the patch and it seems OK, > however, do you have a test case to go with the fix? If so it would > be useful to have the test checked in as well. Well, the problem is that I was never able to see the problem with little weave.inline snippets. I ended up using some code which relies on a large internal library of mine, but which at least would trigger the misbehavior every time. Part of why it took me so long to work on this, is that I had never been able to identify a reliable way to reproduce the problem, until this code started showing it on every run. But unfortunately it's a big library for internal use, so it won't work for a scipy test. I'm sure it can be triggered with smaller examples, but all the ones I tried failed to show it. Frankly, I don't quite understand why, though. From the looks of the bug, it should occur every time... If someone else has a small standalone example which shows the problem reliably, that would be great to have. Cheers, f From prabhu_r at users.sf.net Wed Jun 15 03:19:41 2005 From: prabhu_r at users.sf.net (Prabhu Ramachandran) Date: Wed, 15 Jun 2005 12:49:41 +0530 Subject: [SciPy-dev] Bugfix for weave's catalog. In-Reply-To: <42AFD0CD.50101@colorado.edu> References: <42AEEAAF.5040404@colorado.edu> <17071.52916.696390.52572@monster.linux.in> <42AFD0CD.50101@colorado.edu> Message-ID: <17071.54925.565813.850612@monster.linux.in> >>>>> "FP" == Fernando Perez writes: >> Thanks for tracking this down. I just read the patch and it >> seems OK, however, do you have a test case to go with the fix? >> If so it would be useful to have the test checked in as well. FP> Well, the problem is that I was never able to see the problem FP> with little weave.inline snippets. I ended up using some code FP> which relies on a large internal library of mine, but which at FP> least would trigger the misbehavior every time. Part of why FP> it took me so long to work on this, is that I had never been FP> able to identify a reliable way to reproduce the problem, FP> until this code started showing it on every run. OK, I've also run into this from time to time but never had the chance to make a simple test case. cheers, prabhu From jdhunter at ace.bsd.uchicago.edu Wed Jun 15 10:28:43 2005 From: jdhunter at ace.bsd.uchicago.edu (John Hunter) Date: Wed, 15 Jun 2005 09:28:43 -0500 Subject: [SciPy-dev] Bugfix for weave's catalog. In-Reply-To: <42AFD0CD.50101@colorado.edu> (Fernando Perez's message of "Wed, 15 Jun 2005 00:55:09 -0600") References: <42AEEAAF.5040404@colorado.edu> <17071.52916.696390.52572@monster.linux.in> <42AFD0CD.50101@colorado.edu> Message-ID: <87psung0dg.fsf@peds-pc311.bsd.uchicago.edu> >>>>> "Fernando" == Fernando Perez writes: Fernando> But unfortunately it's a big library for internal use, Fernando> so it won't work for a scipy test. I'm sure it can be Fernando> triggered with smaller examples, but all the ones I Fernando> tried failed to show it. Frankly, I don't quite Fernando> understand why, though. From the looks of the bug, it Fernando> should occur every time... Fernando> If someone else has a small standalone example which Fernando> shows the problem reliably, that would be great to have. The weave demo code I was running at Los Alamos showed this bug so it will be a good test case. I have it on my laptop at home, and so can't send it now. Fernando, do you have a copy of the roadshow directory on your laptop? JDH From loredo at astro.cornell.edu Wed Jun 15 14:35:48 2005 From: loredo at astro.cornell.edu (Tom Loredo) Date: Wed, 15 Jun 2005 14:35:48 -0400 (EDT) Subject: [SciPy-dev] Status of LiveDocs? Message-ID: <200506151835.j5FIZmN01199@laplace.astro.cornell.edu> Hi folks- What is the status of LiveDocs? I have two summer students who I am introducing to Python & SciPy, and they are finding documentation to be an obstacle. I've been trying to access LiveDocs via the Documentation Home page for a few days now, with no luck. I was hoping they might find LiveDocs to be helpful.... Thanks, Tom From joe at enthought.com Wed Jun 15 15:13:32 2005 From: joe at enthought.com (Joe Cooper) Date: Wed, 15 Jun 2005 14:13:32 -0500 Subject: [SciPy-dev] Status of LiveDocs? In-Reply-To: <200506151835.j5FIZmN01199@laplace.astro.cornell.edu> References: <200506151835.j5FIZmN01199@laplace.astro.cornell.edu> Message-ID: <42B07DDC.7090403@enthought.com> Tom Loredo wrote: > Hi folks- > > What is the status of LiveDocs? I have two summer students who > I am introducing to Python & SciPy, and they are finding documentation > to be an obstacle. I've been trying to access LiveDocs via the > Documentation Home page for a few days now, with no luck. I was > hoping they might find LiveDocs to be helpful.... Travis Oliphant was maintaining the server on which the LiveDocs were available, but it seems to be down. I am in the midst of migrating SciPy.org to a new server (it's taking a lot longer than anticipated...the old system developed by accretion over several years and is a bit hard to pull apart and put back together on another box (without bringing all of the current problems of the old system over to the new system), and I plan to setup some form of documentation browser. That should occur in a day or two. I'm sure Travis is reading, so if the livedoc server can be brought back online, I imagine he'll do so. If not, I'll see if he can send me some pointers on how he set his up so I can replicate it on the new system. From Fernando.Perez at colorado.edu Wed Jun 15 17:48:28 2005 From: Fernando.Perez at colorado.edu (Fernando Perez) Date: Wed, 15 Jun 2005 15:48:28 -0600 Subject: [SciPy-dev] Bugfix for weave's catalog. In-Reply-To: <87psung0dg.fsf@peds-pc311.bsd.uchicago.edu> References: <42AEEAAF.5040404@colorado.edu> <17071.52916.696390.52572@monster.linux.in> <42AFD0CD.50101@colorado.edu> <87psung0dg.fsf@peds-pc311.bsd.uchicago.edu> Message-ID: <42B0A22C.2090707@colorado.edu> John Hunter wrote: >>>>>>"Fernando" == Fernando Perez writes: > > > Fernando> But unfortunately it's a big library for internal use, > Fernando> so it won't work for a scipy test. I'm sure it can be > Fernando> triggered with smaller examples, but all the ones I > Fernando> tried failed to show it. Frankly, I don't quite > Fernando> understand why, though. From the looks of the bug, it > Fernando> should occur every time... > > Fernando> If someone else has a small standalone example which > Fernando> shows the problem reliably, that would be great to have. > > The weave demo code I was running at Los Alamos showed this bug so it > will be a good test case. I have it on my laptop at home, and so > can't send it now. Fernando, do you have a copy of the roadshow > directory on your laptop? Yes, I'd forgotten. But wasn't that weave.blitz code? It will actually be very good to test with that, b/c my tests were all with weave.inline(), so I'm not 100% sure that my fix covers your case. I'll try to fold your test in, and integrate it into the test suite. It may take me a couple days, as other things have hit the proverbial fan. Cheers, f From joe at enthought.com Wed Jun 15 18:28:18 2005 From: joe at enthought.com (Joe Cooper) Date: Wed, 15 Jun 2005 17:28:18 -0500 Subject: [SciPy-dev] SciPy.org system user purge Message-ID: <42B0AB82.7090906@enthought.com> Hi all, In the process of moving SciPy.org to a new server, I've noticed a large number of system accounts that have not been used in over a year. Due to the fact that there have been an increasing number of brute force password attacks on SciPy and other servers in our network, I would like to simply remove the accounts that are not being used. Please let me know if you are, or plan to, actively use your system account on SciPy.org for anything other than source code repository write access. Because we are moving to Subversion for revision control, we no longer need user accounts for access to the source code repository. If you use your scipy account for email, Linux shell access, website maintenance, or anything else, please let me know. I think I know who all of you are, but I want to make sure I don't kill any accounts that people make use of. The most important thing to me is that you are aware you have a system account and are taking reasonable precautions in insuring your password is strong and changed periodically. Note that I am /not/ talking about mailing list accounts or SciPy.org community accounts on the Plone/Zope website. Both have separate user databases and will not be altered at all during the migration. Odds are good that if you don't know what I'm talking about, you don't need to do anything or respond in any way. From Fernando.Perez at colorado.edu Wed Jun 15 19:56:48 2005 From: Fernando.Perez at colorado.edu (Fernando Perez) Date: Wed, 15 Jun 2005 17:56:48 -0600 Subject: [SciPy-dev] Bugfix for weave's catalog. In-Reply-To: <42B0A22C.2090707@colorado.edu> References: <42AEEAAF.5040404@colorado.edu> <17071.52916.696390.52572@monster.linux.in> <42AFD0CD.50101@colorado.edu> <87psung0dg.fsf@peds-pc311.bsd.uchicago.edu> <42B0A22C.2090707@colorado.edu> Message-ID: <42B0C040.8030800@colorado.edu> > John Hunter wrote: >> >>The weave demo code I was running at Los Alamos showed this bug so it >>will be a good test case. I have it on my laptop at home, and so >>can't send it now. Fernando, do you have a copy of the roadshow >>directory on your laptop? Actually, I just checked and that stuff never made it to SVN, so I don't have it. Could you either commit it or mail it to me so I can test and see if my fix also works for your code? Cheers, f From oliphant at ee.byu.edu Wed Jun 15 23:25:44 2005 From: oliphant at ee.byu.edu (Travis Oliphant) Date: Wed, 15 Jun 2005 21:25:44 -0600 Subject: [SciPy-dev] Status of LiveDocs? In-Reply-To: <42B07DDC.7090403@enthought.com> References: <200506151835.j5FIZmN01199@laplace.astro.cornell.edu> <42B07DDC.7090403@enthought.com> Message-ID: <42B0F138.8010103@ee.byu.edu> Joe Cooper wrote: > Tom Loredo wrote: > >> Hi folks- >> >> What is the status of LiveDocs? I have two summer students who >> I am introducing to Python & SciPy, and they are finding documentation >> to be an obstacle. I've been trying to access LiveDocs via the >> Documentation Home page for a few days now, with no luck. I was >> hoping they might find LiveDocs to be helpful.... > > > Travis Oliphant was maintaining the server on which the LiveDocs were > available, but it seems to be down. I am in the midst of migrating > SciPy.org to a new server (it's taking a lot longer than > anticipated...the old system developed by accretion over several years > and is a bit hard to pull apart and put back together on another box > (without bringing all of the current problems of the old system over > to the new system), and I plan to setup some form of documentation > browser. That should occur in a day or two. > BYU just implemented a new IP policy and removed my machine (which was hosting the livedocs site) from the web. I've applied for a visible IP address, but it does not work yet. You can run livedocs on any machine with twisted python, nevow, and scipy installed. The code for livedocs is in scipy cvs under util/livedocs The README file there has information about it. You need a nobody account with a home directory (see livedocs.tac) for details. > I'm sure Travis is reading, so if the livedoc server can be brought > back online, I imagine he'll do so. If not, I'll see if he can send > me some pointers on how he set his up so I can replicate it on the new > system. Hopefully, these pointers will let anyone run livedocs. For now, livedocs is running at http://www.tramy.us:8081 Joe can link there or bring up his own livedocs on the new site. -Travis From joe at enthought.com Wed Jun 15 23:40:21 2005 From: joe at enthought.com (Joe Cooper) Date: Wed, 15 Jun 2005 22:40:21 -0500 Subject: [SciPy-dev] Status of LiveDocs? In-Reply-To: <42B0F138.8010103@ee.byu.edu> References: <200506151835.j5FIZmN01199@laplace.astro.cornell.edu> <42B07DDC.7090403@enthought.com> <42B0F138.8010103@ee.byu.edu> Message-ID: <42B0F4A5.7080402@enthought.com> Travis Oliphant wrote: > You can run livedocs on any machine with twisted python, nevow, and > scipy installed. The code for livedocs is in scipy cvs under util/livedocs > > The README file there has information about it. You need a nobody > account with a home directory (see livedocs.tac) for details. Can do (though it can't have nobody--the new server is all very super-top-secret-secure, you know, so all services get their own minimum privilege user--but that's my problem). I'll get something up in a couple of days. > Hopefully, these pointers will let anyone run livedocs. Thanks for pointing me at the CVS repository. I didn't know where livedocs came from. ;-) > For now, livedocs is running at http://www.tramy.us:8081 Close, but no cigar: An error occurred while loading http://www.tramy.us:8081/scipy: Timeout on server Connection was to www.tramy.us at port 81 Looks like something is still pointing to 81, instead of 8081. > Joe can link there or bring up his own livedocs on the new site. Will link until the new server hits its stride. Thanks Travis! From jdhunter at ace.bsd.uchicago.edu Fri Jun 17 00:04:21 2005 From: jdhunter at ace.bsd.uchicago.edu (John Hunter) Date: Thu, 16 Jun 2005 23:04:21 -0500 Subject: [SciPy-dev] Bugfix for weave's catalog. In-Reply-To: <42B0C040.8030800@colorado.edu> (Fernando Perez's message of "Wed, 15 Jun 2005 17:56:48 -0600") References: <42AEEAAF.5040404@colorado.edu> <17071.52916.696390.52572@monster.linux.in> <42AFD0CD.50101@colorado.edu> <87psung0dg.fsf@peds-pc311.bsd.uchicago.edu> <42B0A22C.2090707@colorado.edu> <42B0C040.8030800@colorado.edu> Message-ID: <87ekb1vdbu.fsf@peds-pc311.bsd.uchicago.edu> >>>>> "Fernando" == Fernando Perez writes: Fernando> Actually, I just checked and that stuff never made it to Fernando> SVN, so I don't have it. Could you either commit it or Fernando> mail it to me so I can test and see if my fix also works Fernando> for your code? Here is the script that shows the bug. It is designed to compare the performance of weave blitz versus numeric for repeated adds of a 2D array x + x x + x + x x + x + x + x ....and so on On the second iteration through the loop (x+x+x), it issues a "repairing catalog by removing key" and recompiles the extensions -- it doesn't do this for any other of the repeated add lines in this loop. This happens repeatedly if you rerun the script, so the cache is being ignored. Unfortunately, I only see this on my G4 powerbook and not on my linux box, so it might be hard for others to use as a test script. Tomorrow I'll try and update scipy weave on my powerbook from CVS and try it with and w/o your patch. JDH from __future__ import division import sys, time from Numeric import zeros, Float from MLab import rand import weave from pylab import subplot, plot, show, legend, xlabel, ylabel, title shape = 200,200 x = rand(*shape) def repeat_nadds(Nadds, Nevals, useWeave): """ Time the addition of i=2,Nadds arrays. Evaluate each expression Nevals times to produce accurate timing results. If useWeave is True, use weave to inline the addition, else use Numeric return value is n,t where n is a list of the the number of arrays added and t is the average time it took to add the arrays """ results = [] for i in range(2,Nadds): s = 'result = %s' % '+'.join(['x']*i) print 'evaluating: %s with weave=%s' % (s,useWeave) tstart = time.time() # only weave needs to predefine result array if useWeave: result= zeros(shape, typecode=Float) for j in range(Nevals): if useWeave: weave.blitz(s) else: exec(s) elapsed = (time.time()-tstart)/Nevals print '\tNadds=%d Elapsed=%1.2f' % (i, elapsed) results.append( (i, elapsed) ) return zip(*results) Nadds = 7 Nevals = 20 # evaluate weave nw, tw = repeat_nadds(Nadds, Nevals, useWeave=True) # evaluate Numeric nn, tn = repeat_nadds(Nadds, Nevals, useWeave=False) # plot weave versus Numeric ax = subplot(111) plot(nw, tw, 'go', nn, tn, 'bs') legend( ('Weave', 'Numeric') ) xlabel('num adds') ylabel('time (s)') title('Numeric vs weave; repeated adds') ax.set_xlim( (0, Nadds+1)) show() From Fernando.Perez at colorado.edu Fri Jun 17 02:32:15 2005 From: Fernando.Perez at colorado.edu (Fernando Perez) Date: Fri, 17 Jun 2005 00:32:15 -0600 Subject: [SciPy-dev] Bugfix for weave's catalog. In-Reply-To: <87ekb1vdbu.fsf@peds-pc311.bsd.uchicago.edu> References: <42AEEAAF.5040404@colorado.edu> <17071.52916.696390.52572@monster.linux.in> <42AFD0CD.50101@colorado.edu> <87psung0dg.fsf@peds-pc311.bsd.uchicago.edu> <42B0A22C.2090707@colorado.edu> <42B0C040.8030800@colorado.edu> <87ekb1vdbu.fsf@peds-pc311.bsd.uchicago.edu> Message-ID: <42B26E6F.40204@colorado.edu> John Hunter wrote: >>>>>>"Fernando" == Fernando Perez writes: > > > Fernando> Actually, I just checked and that stuff never made it to > Fernando> SVN, so I don't have it. Could you either commit it or > Fernando> mail it to me so I can test and see if my fix also works > Fernando> for your code? > > Here is the script that shows the bug. It is designed to compare the > performance of weave blitz versus numeric for repeated adds of a 2D > array > > x + x > x + x + x > x + x + x + x ....and so on > > On the second iteration through the loop (x+x+x), it issues a > "repairing catalog by removing key" and recompiles the extensions -- > it doesn't do this for any other of the repeated add lines in this > loop. This happens repeatedly if you rerun the script, so the cache > is being ignored. Unfortunately, I only see this on my G4 powerbook > and not on my linux box, so it might be hard for others to use as a > test script. OK, I just tested this with my linux box, and I can both see the problem under the old weave, and have it fixed with the new one. So we're in good shape. However, I'm swamped with work and other things, so it may take me some time (probably until next week) until I can commit all this with proper unit testing. I need to figure out how to fold the compilation failure into a lower-level unit test, since by default weave absorbs the failure almost silently. You see it failed because there is a slowdown, but no exceptions are raised. So getting this unit-tested properly will take a bit of work: if anyone can help me with that, I'd be grateful. I've already sunk a ton of time into just getting the bug tracked down and fixed. If someone offers to help, I'll commit the bugfixes (they touch multiple files), and then I'll rely on someone else to write the proper unit test (keep in mind, it has to fail only on _second_ execution, and you need to clean up the default catalog, etc; it's not a totally easy unit test to write). Cheers, f From mmetz at astro.uni-bonn.de Fri Jun 17 02:36:26 2005 From: mmetz at astro.uni-bonn.de (Manuel Metz) Date: Fri, 17 Jun 2005 08:36:26 +0200 Subject: [SciPy-dev] Bugfix for weave's catalog. In-Reply-To: <87ekb1vdbu.fsf@peds-pc311.bsd.uchicago.edu> References: <42AEEAAF.5040404@colorado.edu> <17071.52916.696390.52572@monster.linux.in> <42AFD0CD.50101@colorado.edu> <87psung0dg.fsf@peds-pc311.bsd.uchicago.edu> <42B0A22C.2090707@colorado.edu> <42B0C040.8030800@colorado.edu> <87ekb1vdbu.fsf@peds-pc311.bsd.uchicago.edu> Message-ID: <42B26F6A.8060503@astro.uni-bonn.de> I do see the same behavior described below on my Linux box: *Only* on the second iteration I get "repairing catalog by removing key"... Debian Linux (i386), sid, python 2.3.5, weave 0.3.2 (the actual package versions on Debian) Manuel John Hunter schrieb: >>>>>>"Fernando" == Fernando Perez writes: > > > Fernando> Actually, I just checked and that stuff never made it to > Fernando> SVN, so I don't have it. Could you either commit it or > Fernando> mail it to me so I can test and see if my fix also works > Fernando> for your code? > > Here is the script that shows the bug. It is designed to compare the > performance of weave blitz versus numeric for repeated adds of a 2D > array > > x + x > x + x + x > x + x + x + x ....and so on > > On the second iteration through the loop (x+x+x), it issues a > "repairing catalog by removing key" and recompiles the extensions -- > it doesn't do this for any other of the repeated add lines in this > loop. This happens repeatedly if you rerun the script, so the cache > is being ignored. Unfortunately, I only see this on my G4 powerbook > and not on my linux box, so it might be hard for others to use as a > test script. > > Tomorrow I'll try and update scipy weave on my powerbook from CVS and > try it with and w/o your patch. > > JDH > > from __future__ import division > import sys, time > from Numeric import zeros, Float > from MLab import rand > import weave > from pylab import subplot, plot, show, legend, xlabel, ylabel, title > > > shape = 200,200 > x = rand(*shape) > > > def repeat_nadds(Nadds, Nevals, useWeave): > """ > Time the addition of i=2,Nadds arrays. Evaluate each expression > Nevals times to produce accurate timing results. If useWeave is > True, use weave to inline the addition, else use Numeric > > return value is n,t where n is a list of the the number of arrays > added and t is the average time it took to add the arrays > """ > results = [] > for i in range(2,Nadds): > s = 'result = %s' % '+'.join(['x']*i) > print 'evaluating: %s with weave=%s' % (s,useWeave) > tstart = time.time() > > # only weave needs to predefine result array > if useWeave: result= zeros(shape, typecode=Float) > for j in range(Nevals): > if useWeave: > weave.blitz(s) > else: > exec(s) > elapsed = (time.time()-tstart)/Nevals > print '\tNadds=%d Elapsed=%1.2f' % (i, elapsed) > results.append( (i, elapsed) ) > return zip(*results) > > Nadds = 7 > Nevals = 20 > > # evaluate weave > nw, tw = repeat_nadds(Nadds, Nevals, useWeave=True) > # evaluate Numeric > nn, tn = repeat_nadds(Nadds, Nevals, useWeave=False) > > # plot weave versus Numeric > ax = subplot(111) > plot(nw, tw, 'go', nn, tn, 'bs') > legend( ('Weave', 'Numeric') ) > xlabel('num adds') > ylabel('time (s)') > title('Numeric vs weave; repeated adds') > ax.set_xlim( (0, Nadds+1)) > show() > > > > > > > _______________________________________________ > Scipy-dev mailing list > Scipy-dev at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-dev -- ------------------------------------- Manuel Metz Sternwarte der Universitaet Bonn Auf dem Huegel 71 (room 3.06) D - 53121 Bonn E-Mail: mmetz at astro.uni-bonn.de Phone: (+49) 228 / 73-3660 Fax: (+49) 228 / 73-3672 ------------------------------------- From prabhu_r at users.sf.net Fri Jun 17 06:29:54 2005 From: prabhu_r at users.sf.net (Prabhu Ramachandran) Date: Fri, 17 Jun 2005 15:59:54 +0530 Subject: [SciPy-dev] Bugfix for weave's catalog. In-Reply-To: <87ekb1vdbu.fsf@peds-pc311.bsd.uchicago.edu> References: <42AEEAAF.5040404@colorado.edu> <17071.52916.696390.52572@monster.linux.in> <42AFD0CD.50101@colorado.edu> <87psung0dg.fsf@peds-pc311.bsd.uchicago.edu> <42B0A22C.2090707@colorado.edu> <42B0C040.8030800@colorado.edu> <87ekb1vdbu.fsf@peds-pc311.bsd.uchicago.edu> Message-ID: <17074.42530.981018.937333@monster.linux.in> >>>>> "John" == John Hunter writes: >>>>> "Fernando" == Fernando Perez writes: [...] John> Tomorrow I'll try and update scipy weave on my powerbook from John> CVS and try it with and w/o your patch. My time machine must be working overtime. This code poses no problems on my machine (Debian sarge) scipy.__version__ = '0.3.3_303.4601'. cheers, prabhu From prabhu_r at users.sf.net Fri Jun 17 06:37:38 2005 From: prabhu_r at users.sf.net (Prabhu Ramachandran) Date: Fri, 17 Jun 2005 16:07:38 +0530 Subject: [SciPy-dev] Bugfix for weave's catalog. In-Reply-To: <42B26E6F.40204@colorado.edu> References: <42AEEAAF.5040404@colorado.edu> <17071.52916.696390.52572@monster.linux.in> <42AFD0CD.50101@colorado.edu> <87psung0dg.fsf@peds-pc311.bsd.uchicago.edu> <42B0A22C.2090707@colorado.edu> <42B0C040.8030800@colorado.edu> <87ekb1vdbu.fsf@peds-pc311.bsd.uchicago.edu> <42B26E6F.40204@colorado.edu> Message-ID: <17074.42994.894.294671@monster.linux.in> >>>>> "Fernando" == Fernando Perez writes: [...] Fernando> However, I'm swamped with work and other things, so it Fernando> may take me some time (probably until next week) until I Fernando> can commit all this with proper unit testing. I need to Fernando> figure out how to fold the compilation failure into a Fernando> lower-level unit test, since by default weave absorbs Fernando> the failure almost silently. You see it failed because Fernando> there is a slowdown, but no exceptions are raised. Oh no, I did not mean that you add a full unit test. I completely understand the difficulty in engineering a pukka unit test for this kind of thing. What I had asked for was atleast an example demonstrating the problem, appropriately documented, and checked in so we know how to test and check if things are ok. cheers, prabhu From nwagner at mecha.uni-stuttgart.de Fri Jun 17 07:19:10 2005 From: nwagner at mecha.uni-stuttgart.de (Nils Wagner) Date: Fri, 17 Jun 2005 13:19:10 +0200 Subject: [SciPy-dev] Roadmap for scipy Message-ID: <42B2B1AE.6000607@mecha.uni-stuttgart.de> Dear Scipy-developers, The activity with respect to scipy-cvs is considerably lower than that of other projects e.g. matplotlib (at least for the last 4 months). Is there any road map for further development of scipy right now ? I would be glad to get some feedback to the point. Nils From jdhunter at ace.bsd.uchicago.edu Fri Jun 17 10:39:48 2005 From: jdhunter at ace.bsd.uchicago.edu (John Hunter) Date: Fri, 17 Jun 2005 09:39:48 -0500 Subject: [SciPy-dev] Bugfix for weave's catalog. In-Reply-To: <42B0C040.8030800@colorado.edu> (Fernando Perez's message of "Wed, 15 Jun 2005 17:56:48 -0600") References: <42AEEAAF.5040404@colorado.edu> <17071.52916.696390.52572@monster.linux.in> <42AFD0CD.50101@colorado.edu> <87psung0dg.fsf@peds-pc311.bsd.uchicago.edu> <42B0A22C.2090707@colorado.edu> <42B0C040.8030800@colorado.edu> Message-ID: <87psulgi8b.fsf@peds-pc311.bsd.uchicago.edu> >>>>> "Fernando" == Fernando Perez writes: >> John Hunter wrote: >>> The weave demo code I was running at Los Alamos showed this >>> bug so it will be a good test case. I have it on my laptop at >>> home, and so can't send it now. Fernando, do you have a copy >>> of the roadshow directory on your laptop? Fernando> Actually, I just checked and that stuff never made it to Fernando> SVN, so I don't have it. Could you either commit it or Fernando> mail it to me so I can test and see if my fix also works Fernando> for your code? OK, just did a fresh checkout of scipy from CVS on my powerbook G4, and the bug was still present when running the test script. peds-mac054:~> uname -a Darwin peds-mac054.bsd.uchicago.edu 7.7.0 Darwin Kernel Version 7.7.0: Sun Nov 7 16:06:51 PST 2004; root:xnu/xnu-517.9.5.obj~1/RELEASE_PPC Power Macintosh powerpc peds-mac054:~> python -c 'import scipy; print scipy.__version__' numerix Numeric 24.0b2 0.3.3_309.4624 After applying your patch the bug disappeared, so it looks good from here. On my linux desktop peds-pc311:~/python/examples/weave/blitz> uname -a Linux peds-pc311 2.6.10-5-386 #1 Fri May 20 13:52:48 UTC 2005 i686 GNU/Linux peds-pc311:~/python/examples/weave/blitz> python -c 'import scipy; print scipy.__version__' 0.3.2 I am not seeing the bug. I just upgraded my linux box to scipy CVS peds-pc311:~/python/examples/weave/blitz> python -c 'import scipy; print scipy.__version__' numerix Numeric 24.0b2 0.3.3_309.4624 and still do not see the bug. Strange... JDH From Fernando.Perez at colorado.edu Fri Jun 17 13:03:54 2005 From: Fernando.Perez at colorado.edu (Fernando Perez) Date: Fri, 17 Jun 2005 11:03:54 -0600 Subject: [SciPy-dev] Bugfix for weave's catalog. In-Reply-To: <87psulgi8b.fsf@peds-pc311.bsd.uchicago.edu> References: <42AEEAAF.5040404@colorado.edu> <17071.52916.696390.52572@monster.linux.in> <42AFD0CD.50101@colorado.edu> <87psung0dg.fsf@peds-pc311.bsd.uchicago.edu> <42B0A22C.2090707@colorado.edu> <42B0C040.8030800@colorado.edu> <87psulgi8b.fsf@peds-pc311.bsd.uchicago.edu> Message-ID: <42B3027A.7050606@colorado.edu> John Hunter wrote: >>>>>>"Fernando" == Fernando Perez writes: > > > >> John Hunter wrote: > >>> The weave demo code I was running at Los Alamos showed this > >>> bug so it will be a good test case. I have it on my laptop at > >>> home, and so can't send it now. Fernando, do you have a copy > >>> of the roadshow directory on your laptop? > > Fernando> Actually, I just checked and that stuff never made it to > Fernando> SVN, so I don't have it. Could you either commit it or > Fernando> mail it to me so I can test and see if my fix also works > Fernando> for your code? > > > OK, just did a fresh checkout of scipy from CVS on my powerbook G4, > and the bug was still present when running the test script. That's because I hadn't committed anything yet :) Now that Prahbu clarified that he didn't expect a full-blown unittest for this thing, I just committed all the fixes. They also include better weave messages, and the headers problem correction. I'm attaching the testing script here, modified to rely only on scipy and not matplotlib. It also runs the weave tests twice, to try and show to the user whether there is really a problem or not. I'd appreciate if others could test this and let us know if the problems are really fixed or not (multi-platform feedback would be most welcome, I only have access to a linux system). Prabhu, feel free to stick this test script anywhere in the tree you think is a appropriate; I didn't commit it b/c I wasn't sure where to put it. All code is otherwise committed already. Back to real work now... Best, f ps - other devs: does anyone have any tips on how to fluidly set things up for working with scipy CVS which is changing frequently? I find it really painful to have to rebuild all of scipy when I make changes, but I don't know, short of writing makefiles which duplicate setup.py, how to avoid recompiling all the extension modules from scratch, which takes a long time. As far as I know, distutils is pretty dumb when it comes to make-like dependency analysis and as-needed-only recompilation. Any pointers on this front would be tremendously useful (if someone writes this up, it would be great to append it to the Developers.txt document in the sources. I can do that if nobody else does). I'm used to dealing with heavily-changing code only in ipython, matplotlib and mayavi, and those are mostly pure python, hence far easier to deal with with just some PYTHONPATH tricks. For matplotlib I rarely modify the extensions, so I just symlink the .so files by hand. But scipy is too complex for that approach, and I feel a bit lost right now. Pointers most welcome... -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: weave_recompile_bug.py URL: From fishburn at MIT.EDU Fri Jun 17 13:58:35 2005 From: fishburn at MIT.EDU (Matt Fishburn) Date: Fri, 17 Jun 2005 13:58:35 -0400 Subject: [SciPy-dev] fftw3 support Message-ID: <42B30F4B.4030504@mit.edu> Hello, I've attached patches against the current cvs source for fftw3 support in scipy. I've only tested these under x86 *nix (debian with various combinations of fftw-dev and fftw3-dev installed). Could a few people please try the patches and send build feedback? fft-c-source.diff is diff'ed against the c source/header files in Lib/fftpack/src and system_info.diff is diff'ed against the build detection code in scipy_core/scipy_distutils/system_info.py -Matt Fishburn -------------- next part -------------- A non-text attachment was scrubbed... Name: fft-c-source.diff Type: text/x-patch Size: 7844 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: system_info.diff Type: text/x-patch Size: 4847 bytes Desc: not available URL: From rkern at ucsd.edu Fri Jun 17 16:13:29 2005 From: rkern at ucsd.edu (Robert Kern) Date: Fri, 17 Jun 2005 13:13:29 -0700 Subject: [SciPy-dev] Roadmap for scipy In-Reply-To: <42B2B1AE.6000607@mecha.uni-stuttgart.de> References: <42B2B1AE.6000607@mecha.uni-stuttgart.de> Message-ID: <42B32EE9.2070406@ucsd.edu> Nils Wagner wrote: > Dear Scipy-developers, > > The activity with respect to scipy-cvs is considerably lower than that > of other projects e.g. matplotlib > (at least for the last 4 months). > Is there any road map for further development of scipy right now ? Not an official one, I don't think. Personally, some day I'm going to get around to implementing the Mersenne Twister PRNG for Scipy. I have an implementation of Particle Swarm Optimization that needs some polishing, and I am working on a Differential Evolution code. Ideas for the units system I outlined a while ago keeps nagging me, but I don't know if I will ever get around to it. There is always the Accessible Scipy roadmap, but it needs volunteers. http://www.scipy.org/mailinglists/mailman?fn=scipy-dev/2004-October/002412.html -- Robert Kern rkern at ucsd.edu "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter From charles.harris at sdl.usu.edu Fri Jun 17 20:28:21 2005 From: charles.harris at sdl.usu.edu (Charles Harris) Date: Fri, 17 Jun 2005 18:28:21 -0600 Subject: [SciPy-dev] Roadmap for scipy Message-ID: I've done the Mersenne Twister using boost. With some work, this could probably be brought to a form that would work in SciPy. Suggestion on what you would like to see are welcome. -----Original Message----- From: scipy-dev-bounces at scipy.net on behalf of Robert Kern Sent: Fri 6/17/2005 2:13 PM To: SciPy Developers List Subject: Re: [SciPy-dev] Roadmap for scipy Nils Wagner wrote: > Dear Scipy-developers, > > The activity with respect to scipy-cvs is considerably lower than that > of other projects e.g. matplotlib > (at least for the last 4 months). > Is there any road map for further development of scipy right now ? Not an official one, I don't think. Personally, some day I'm going to get around to implementing the Mersenne Twister PRNG for Scipy. I have an implementation of Particle Swarm Optimization that needs some polishing, and I am working on a Differential Evolution code. Ideas for the units system I outlined a while ago keeps nagging me, but I don't know if I will ever get around to it. There is always the Accessible Scipy roadmap, but it needs volunteers. http://www.scipy.org/mailinglists/mailman?fn=scipy-dev/2004-October/002412.html -- Robert Kern rkern at ucsd.edu "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter _______________________________________________ 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: 3182 bytes Desc: not available URL: From prabhu_r at users.sf.net Fri Jun 17 23:14:56 2005 From: prabhu_r at users.sf.net (Prabhu Ramachandran) Date: Sat, 18 Jun 2005 08:44:56 +0530 Subject: [SciPy-dev] Bugfix for weave's catalog. In-Reply-To: <42B3027A.7050606@colorado.edu> References: <42AEEAAF.5040404@colorado.edu> <17071.52916.696390.52572@monster.linux.in> <42AFD0CD.50101@colorado.edu> <87psung0dg.fsf@peds-pc311.bsd.uchicago.edu> <42B0A22C.2090707@colorado.edu> <42B0C040.8030800@colorado.edu> <87psulgi8b.fsf@peds-pc311.bsd.uchicago.edu> <42B3027A.7050606@colorado.edu> Message-ID: <17075.37296.405723.165518@monster.linux.in> >>>>> "Fernando" == Fernando Perez writes: Fernando> Prabhu, feel free to stick this test script anywhere in Fernando> the tree you think is a appropriate; I didn't commit it Fernando> b/c I wasn't sure where to put it. All code is Fernando> otherwise committed already. Thanks, I think this could just go into tests/, unless someone has serious objections. cheers, prabhu From rkern at ucsd.edu Fri Jun 17 23:51:51 2005 From: rkern at ucsd.edu (Robert Kern) Date: Fri, 17 Jun 2005 20:51:51 -0700 Subject: [SciPy-dev] Roadmap for scipy In-Reply-To: References: Message-ID: <42B39A57.1040109@ucsd.edu> Charles Harris wrote: > I've done the Mersenne Twister using boost. With some work, this could probably > be brought to a form that would work in SciPy. Suggestion on what you would like > to see are welcome. A non-Boost form would be preferable. :-) Seriously, Boost would be YABuildDependency that probably won't fit very well into the current build process. I would suggest using the C code from the standard library. The seed should be settable from a Python int or long as in the standard library, but it should also allow seeding from some kind of array to utilize the full 624*4 bytes of state. The coverage of distributions (gamma, beta, multivariate_normal, etc.) should be the same such that the new module can plug in seamlessly. -- Robert Kern rkern at ucsd.edu "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter From Fernando.Perez at colorado.edu Sat Jun 18 00:54:56 2005 From: Fernando.Perez at colorado.edu (Fernando Perez) Date: Fri, 17 Jun 2005 22:54:56 -0600 Subject: [SciPy-dev] Bugfix for weave's catalog. In-Reply-To: <17075.37296.405723.165518@monster.linux.in> References: <42AEEAAF.5040404@colorado.edu> <17071.52916.696390.52572@monster.linux.in> <42AFD0CD.50101@colorado.edu> <87psung0dg.fsf@peds-pc311.bsd.uchicago.edu> <42B0A22C.2090707@colorado.edu> <42B0C040.8030800@colorado.edu> <87psulgi8b.fsf@peds-pc311.bsd.uchicago.edu> <42B3027A.7050606@colorado.edu> <17075.37296.405723.165518@monster.linux.in> Message-ID: <42B3A920.8020601@colorado.edu> Prabhu Ramachandran wrote: >>>>>>"Fernando" == Fernando Perez writes: > > > Fernando> Prabhu, feel free to stick this test script anywhere in > Fernando> the tree you think is a appropriate; I didn't commit it > Fernando> b/c I wasn't sure where to put it. All code is > Fernando> otherwise committed already. > > Thanks, I think this could just go into tests/, unless someone has > serious objections. Fine with me. Given how much people love to deal with weave's internals, I doubt you'll get any objections, let alone serious ones :) It would still be good to hear whether the problems did go away for Win32 users. J. Hunter mentioned improvements on OSX, and I tested linux, but I have no way to check win32. I don't see why it shouldn't work, since none of that code was platform dependent. But to be honest, I never quite figured out the exact mechanism for the bug (in particular, why it got triggered on some cases and not others). So I don't really know what to expect from that code. Cheers, f From joe at enthought.com Mon Jun 20 21:30:17 2005 From: joe at enthought.com (Joe Cooper) Date: Mon, 20 Jun 2005 20:30:17 -0500 Subject: [SciPy-dev] SciPy.org server migration tonight Message-ID: <42B76DA9.9060204@enthought.com> Hi all, I've been threatening a server migration of SciPy.org for a couple of weeks now, and tonight's the night on which at least some services will move (whether they like it or not). I will be shutting down CVS access in a few minutes, as the cvs2svn conversion takes a while to process and I will definitely move SciPy to Subversion tonight. Throughout the evening, other services will probably disappear for a bit, hopefully to reappear on the new server soon after. I'm certain there will be issues, as we're moving to much newer versions of all software, removing a bunch of old users, switching from CVS to Subversion, and a couple dozen other changes that don't come to mind right now. Please let me know if you see any such problems in the coming days. I'll notify the list when things are back to sanity as best as I can figure. Thanks! From joe at enthought.com Tue Jun 21 00:07:29 2005 From: joe at enthought.com (Joe Cooper) Date: Mon, 20 Jun 2005 23:07:29 -0500 Subject: [SciPy-dev] Re: [SciPy-user] SciPy.org server migration tonight In-Reply-To: <42B76DA9.9060204@enthought.com> References: <42B76DA9.9060204@enthought.com> Message-ID: <42B79281.4060607@enthought.com> Hi again, It was a nice dream, but SciPy will remain in CVS for the time being. cvs2svn choked on our repository. It's been brought up with the developers, and hopefully there will soon be a solution. CVS is back to normal. I'll try again tomorrow...Sigh. Joe Cooper wrote: > Hi all, > > I've been threatening a server migration of SciPy.org for a couple of > weeks now, and tonight's the night on which at least some services will > move (whether they like it or not). > > I will be shutting down CVS access in a few minutes, as the cvs2svn > conversion takes a while to process and I will definitely move SciPy to > Subversion tonight. Throughout the evening, other services will > probably disappear for a bit, hopefully to reappear on the new server > soon after. > > I'm certain there will be issues, as we're moving to much newer versions > of all software, removing a bunch of old users, switching from CVS to > Subversion, and a couple dozen other changes that don't come to mind > right now. Please let me know if you see any such problems in the > coming days. > > I'll notify the list when things are back to sanity as best as I can > figure. > > Thanks! > > _______________________________________________ > SciPy-user mailing list > SciPy-user at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-user From nwagner at mecha.uni-stuttgart.de Tue Jun 21 08:15:53 2005 From: nwagner at mecha.uni-stuttgart.de (Nils Wagner) Date: Tue, 21 Jun 2005 14:15:53 +0200 Subject: [SciPy-dev] Current errors in scipy.test(1,verbosity=10) Message-ID: <42B804F9.2060509@mecha.uni-stuttgart.de> Hi all, I get two errors and 1 failure running scipy.test(1,verbosity=10) with latest cvs (scipy, Numerical and f2py) ====================================================================== ERROR: check_definition (scipy.fftpack.basic.test_basic.test_fftn) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/local/lib/python2.4/site-packages/scipy/fftpack/tests/test_basic.py", line 423, in check_definition assert_array_almost_equal(fftn(x),direct_dftn(x)) File "/usr/local/lib/python2.4/site-packages/scipy/fftpack/basic.py", line 283, in fftn return _raw_fftnd(tmp,shape,axes,1,overwrite_x,work_function) File "/usr/local/lib/python2.4/site-packages/scipy/fftpack/basic.py", line 219, in _raw_fftnd return work_function(x,s,direction,overwrite_x=overwrite_x) error: failed in converting 1st argument `x' of _fftpack.zfftnd to C/Fortran array ====================================================================== ERROR: check_definition (scipy.fftpack.basic.test_basic.test_ifftn) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/local/lib/python2.4/site-packages/scipy/fftpack/tests/test_basic.py", line 590, in check_definition assert_array_almost_equal(ifftn(x),direct_idftn(x)) File "/usr/local/lib/python2.4/site-packages/scipy/fftpack/basic.py", line 312, in ifftn return _raw_fftnd(tmp,shape,axes,-1,overwrite_x,work_function) File "/usr/local/lib/python2.4/site-packages/scipy/fftpack/basic.py", line 219, in _raw_fftnd return work_function(x,s,direction,overwrite_x=overwrite_x) error: failed in converting 1st argument `x' of _fftpack.zfftnd to C/Fortran array ====================================================================== FAIL: check_round (scipy.special.basic.test_basic.test_round) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/local/lib/python2.4/site-packages/scipy/special/tests/test_basic.py", line 1789, in check_round assert_array_equal(rnd,rndrl) File "/usr/local/lib/python2.4/site-packages/scipy_test/testing.py", line 715, in assert_array_equal assert cond,\ AssertionError: Arrays are not equal (mismatch 25.0%): Array 1: [10 10 11 11] Array 2: [10 10 10 11] ---------------------------------------------------------------------- Ran 1265 tests in 7.131s FAILED (failures=1, errors=2) Message-ID: Hi, This bug is now fixed in f2py CVS. Sorry for a late responce. Thanks, Pearu On Mon, 13 Jun 2005, Nils Wagner wrote: > Hi all, > > Running the small test (see below) with latest f2py via cvs results in a > segmentation fault. Since I was not sure whether this bug is related > to f2py or scipy I downgraded f2py to the latest > available tarball http://cens.ioc.ee/projects/f2py2e/#download > Now the program works fine. So the bug must be added with the last > changes in f2py. > > from scipy import * > n = 20 > m = 15 > a = rand(n,m)+1j*rand(n,m) > u,s,vt,info = linalg.flapack.zgesdd(a) > > Any pointer how to fix the problem in latest cvs would be appreciated. > > Thanks in advance > > Nils > > > _______________________________________________ > f2py-users mailing list > f2py-users at cens.ioc.ee > http://cens.ioc.ee/mailman/listinfo/f2py-users > From rkern at ucsd.edu Tue Jun 21 16:35:14 2005 From: rkern at ucsd.edu (Robert Kern) Date: Tue, 21 Jun 2005 13:35:14 -0700 Subject: [SciPy-dev] Current errors in scipy.test(1,verbosity=10) In-Reply-To: <42B804F9.2060509@mecha.uni-stuttgart.de> References: <42B804F9.2060509@mecha.uni-stuttgart.de> Message-ID: <42B87A02.10203@ucsd.edu> Nils Wagner wrote: > ====================================================================== > FAIL: check_round (scipy.special.basic.test_basic.test_round) > ---------------------------------------------------------------------- > Traceback (most recent call last): > File > "/usr/local/lib/python2.4/site-packages/scipy/special/tests/test_basic.py", > line 1789, in check_round > assert_array_equal(rnd,rndrl) > File "/usr/local/lib/python2.4/site-packages/scipy_test/testing.py", > line 715, in assert_array_equal > assert cond,\ > AssertionError: > Arrays are not equal (mismatch 25.0%): > Array 1: [10 10 11 11] > Array 2: [10 10 10 11] This is irksome. Can you tell me if this is the same on Linux: In [4]: scipy.special.round is scipy.special.cephes.round Out[4]: True There seem to be two tests in test_basic.py, one for special.cephes.round() and this one for just special.round(). Both tests now expect x.5-rounds-to-nearest-even, but this one is the only one that's failing on Linux. -- Robert Kern rkern at ucsd.edu "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter From rrajagopal at ati.com Tue Jun 28 14:57:18 2005 From: rrajagopal at ati.com (Ravikiran Rajagopal) Date: Tue, 28 Jun 2005 14:57:18 -0400 Subject: [SciPy-dev] Compilation success with gfortran and gcc 4.0, but Message-ID: <86E17786929CC64AABEA365C849F1352020AFB81@PANXTFSR03.atitech.com> Hi, I finally managed to compile SciPy CVS on Fedora Core 4 with gcc 4.0.0 and gfortran. I did not use the "old" g77 that is shipped with Fedora Core 4 for compatibility purposes. The following is the list of changes I needed: scipy_distutils/gnufcompiler.py 1. Add gfortran to the search list for fortran compilers. 2. Add libgfortran to the search list for g2c. 3. Remove the sse2 optimization flag. Lib 1. Replace Hollerith constants with quoted strings in odepack and quadpack; I used Fortran Tidy to do it. 2. In dqage.f, make sure 260 refers to the last line. 3. Hack the logic in the conjugate gradient methods so as not jump into the middle of a block. My changes should be viewed with extreme suspicion since I have never programmed seriously in Fortran and the last time I dabbled in it (for a few days) was in 1993 or 1994. While everything compiles, there are still runtime errors. The tests in scipy.special are a disaster. I recompiled everything with gcc 4.0.0 but with g77 from gcc 3.2.3 (which required none of the modifications above) and the same errors persist. Several of the tests (check_assoc_laguerre, chack_cheby*, check_gegenbauer, etc.) take 100% and do not return even after several hours. The numpyio todense() error is also found. Anyone have any ideas about fixing this? Regards, Ravi -------------- next part -------------- An HTML attachment was scrubbed... URL: From swisher at enthought.com Wed Jun 29 14:36:00 2005 From: swisher at enthought.com (Janet M. Swisher) Date: Wed, 29 Jun 2005 13:36:00 -0500 Subject: [SciPy-dev] ANN: SciPy 2005 Conference - Python for Scientific Computing Message-ID: <42C2EA10.5070406@enthought.com> Greetings, The 2nd annual *SciPy Conference* on Python for Scientific Computing will be held again this year at Caltech, September 22-23, 2005. History: -------- This event started as SciPy "Workshops" held in 2002 and 2003, with great participation by the ~70 people attending. In 2004, it became a "conference", with attendance jumping to 87 participants. Registration: ------------- Registration is now open. More information can be found here: http://www.scipy.org/wikis/scipy05 You may register early online for $100.00. Registration includes breakfast and lunch Thursday & Friday and a very nice dinner Thursday night. After July 29, registration will cost $150.00. Call for Presenters: -------------------- If you are interested in presenting at the conference, you can submit an abstract in Plain Text, PDF or MS Word formats to abstracts at scipy.org -- the deadline for abstract submission is July 29, 2005. Papers or presentation slides are acceptable and are due by August 26, 2005. Feedback: --------- If you have any feedback from last year's conference or suggestions for this year, please discuss via the scipy mailing list: list signup: http://www.scipy.org/mailinglists/ list address: scipy-user at scipy.org Please forward this announcement to anyone/list that might be interested. Best Regards, -- Janet Swisher --- Senior Technical Writer Enthought, Inc. http://www.enthought.com