From annalisa.py at gmail.com Wed Jun 1 03:56:56 2011 From: annalisa.py at gmail.com (Annalisa Minelli) Date: Wed, 1 Jun 2011 09:56:56 +0200 Subject: [SciPy-Dev] Van der Waerden test in Scipy? Message-ID: Dear Scipy developers, I'm Annalisa Minelli, a PhD student from Perugia (Italy), and I'm using Scipy library because I'm writing some code for my PhD thesis. Since I needed van der waerden chisquare pvalue[0], which is implemented in R but not in Scipy (if I'm not wrong)[1], I implemented the test in python language [3] to break any R dependency for my module. So if you think it can be useful, maybe it could be integrated into the Scipy library? Could you give me any advice on how to proceed? Best Regards, Annalisa Minelli [0]: http://en.wikipedia.org/wiki/Van_der_Waerden_test [1]: http://rss.acs.unt.edu/Rdoc/library/agricolae/html/VanderWarden.html [2]: http://amirror4thesun.blogspot.com/2011/05/van-der-waerden-test.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From julien.delafontaine at epfl.ch Wed Jun 1 06:51:37 2011 From: julien.delafontaine at epfl.ch (julien.delafontaine at epfl.ch) Date: Wed, 01 Jun 2011 12:51:37 +0200 Subject: [SciPy-Dev] Interactive_Plotting incorrect selection of nearest point Message-ID: <20110601125137.15523bcvp6eodu49@webmail.epfl.ch> Hi, I used this script from Scipy's Cookbook http://www.scipy.org/Cookbook/Matplotlib/Interactive_Plotting As it is, the distance between two points is not well defined, because for selecting the nearest point around where you click, you want to minimize the distance in pixels, not depending on different scales for x and y coordinates. So I suggest this correction (divide coordinates by the scale of each axis): def __init__(self, xdata, ydata, annotes, axis=None, xtol=None, ytol=None): self.data = zip(xdata, ydata, annotes) self.xrange = max(xdata) - min(xdata) self.yrange = max(ydata) - min(ydata) ... def __call__(self, event): if event.inaxes: clickX = event.xdata clickY = event.ydata if self.axis is None or self.axis==event.inaxes: annotes = [] for x,y,a in self.data: if clickX-self.xtol < x < clickX+self.xtol and clickY-self.ytol < y < clickY+self.ytol : annotes.append((self.distance(x/self.xrange,clickX/self.xrange,y/self.yrange,clickY/self.yrange),x,y, a) ) ... Julien Delafontaine From josef.pktd at gmail.com Wed Jun 1 10:30:19 2011 From: josef.pktd at gmail.com (josef.pktd at gmail.com) Date: Wed, 1 Jun 2011 10:30:19 -0400 Subject: [SciPy-Dev] Van der Waerden test in Scipy? In-Reply-To: References: Message-ID: On Wed, Jun 1, 2011 at 3:56 AM, Annalisa Minelli wrote: > Dear Scipy developers, > I'm Annalisa Minelli, a PhD student from Perugia (Italy), and I'm using > Scipy library because I'm writing some code for my PhD thesis. > Since I needed van der waerden chisquare pvalue[0], which is implemented in > R but not in Scipy (if I'm not wrong)[1], I implemented the test in python > language [3] to break any R dependency for my module. > > So if you think it can be useful, maybe it could be integrated into the > Scipy library? > Could you give me any advice on how to proceed? Thanks Annalisa, I think it would be useful to have this test (and similar tests based on transformation to the normal distribution). I downloaded your vdw.py. I haven't looked at the details yet, but here are 3 main issues: your vdw is GPL which is incompatible with scipy's BSD license, for inclusion in scipy it would need to be a contribution licensed as BSD your function is not using numpy, and it seems to me that many of the list operations can be vectorized with numpy no tests: since you have the equivalent function in R, it would be good to add some tests that have results from R to check that the function produces the same results. ( for explanation and examples: https://github.com/numpy/numpy/blob/master/doc/TESTS.rst.txt or look in scipy.stats.tests ) additional: docstring should follow the numpy standard, see examples in current functions and https://github.com/numpy/numpy/blob/master/doc/HOWTO_DOCUMENT.rst.txt#docstring-standard How to proceed if these issues are addressed: Since it is a new function, it would be easy to integrate it into scipy from the python files, but if you are familiar with git and github, the integration will eventually be easier if you fork scipy and add the function to scipy.stats and make a pull request. A trac ticket would also be useful to keep track of the contribution (I don't know if github will substitute for this). At the beginning, it might be easiest to discuss this on the mailing list. Cheers, and thanks for any contributions, Josef > > Best Regards, > Annalisa Minelli > > > [0]: http://en.wikipedia.org/wiki/Van_der_Waerden_test > [1]: http://rss.acs.unt.edu/Rdoc/library/agricolae/html/VanderWarden.html > [2]: http://amirror4thesun.blogspot.com/2011/05/van-der-waerden-test.html > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev > > From robert.kern at gmail.com Wed Jun 1 12:03:19 2011 From: robert.kern at gmail.com (Robert Kern) Date: Wed, 1 Jun 2011 11:03:19 -0500 Subject: [SciPy-Dev] Van der Waerden test in Scipy? In-Reply-To: References: Message-ID: On Wed, Jun 1, 2011 at 09:30, wrote: > How to proceed if these issues are addressed: > Since it is a new function, it would be easy to integrate it into > scipy from the python files, but if you are familiar with git and > github, the integration will eventually be easier if you fork scipy > and add the function to scipy.stats and make a pull request. > A trac ticket would also be useful to keep track of the contribution > (I don't know if github will substitute for this). I think a pull request would be sufficient for tracking. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." ? -- Umberto Eco From josef.pktd at gmail.com Wed Jun 1 12:15:20 2011 From: josef.pktd at gmail.com (josef.pktd at gmail.com) Date: Wed, 1 Jun 2011 12:15:20 -0400 Subject: [SciPy-Dev] Van der Waerden test in Scipy? In-Reply-To: References: Message-ID: On Wed, Jun 1, 2011 at 12:03 PM, Robert Kern wrote: > On Wed, Jun 1, 2011 at 09:30, ? wrote: > >> How to proceed if these issues are addressed: >> Since it is a new function, it would be easy to integrate it into >> scipy from the python files, but if you are familiar with git and >> github, the integration will eventually be easier if you fork scipy >> and add the function to scipy.stats and make a pull request. >> A trac ticket would also be useful to keep track of the contribution >> (I don't know if github will substitute for this). > > I think a pull request would be sufficient for tracking. Are pull requests indexed and searchable? Until now I always relied that searching in trac shows all relevant information, but the one-stop searching seems to be gone for now. Josef > > -- > Robert Kern > > "I have come to believe that the whole world is an enigma, a harmless > enigma that is made terrible by our own mad attempt to interpret it as > though it had an underlying truth." > ? -- Umberto Eco > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev > From robert.kern at gmail.com Wed Jun 1 12:18:13 2011 From: robert.kern at gmail.com (Robert Kern) Date: Wed, 1 Jun 2011 11:18:13 -0500 Subject: [SciPy-Dev] Van der Waerden test in Scipy? In-Reply-To: References: Message-ID: On Wed, Jun 1, 2011 at 11:15, wrote: > On Wed, Jun 1, 2011 at 12:03 PM, Robert Kern wrote: >> On Wed, Jun 1, 2011 at 09:30, ? wrote: >> >>> How to proceed if these issues are addressed: >>> Since it is a new function, it would be easy to integrate it into >>> scipy from the python files, but if you are familiar with git and >>> github, the integration will eventually be easier if you fork scipy >>> and add the function to scipy.stats and make a pull request. >>> A trac ticket would also be useful to keep track of the contribution >>> (I don't know if github will substitute for this). >> >> I think a pull request would be sufficient for tracking. > > Are pull requests indexed and searchable? Indexed, yes. https://github.com/scipy/scipy/pulls > Until now I always relied that searching in trac shows all relevant > information, but the one-stop searching seems to be gone for now. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." ? -- Umberto Eco From josef.pktd at gmail.com Wed Jun 1 12:36:54 2011 From: josef.pktd at gmail.com (josef.pktd at gmail.com) Date: Wed, 1 Jun 2011 12:36:54 -0400 Subject: [SciPy-Dev] Van der Waerden test in Scipy? In-Reply-To: References: Message-ID: On Wed, Jun 1, 2011 at 12:18 PM, Robert Kern wrote: > On Wed, Jun 1, 2011 at 11:15, ? wrote: >> On Wed, Jun 1, 2011 at 12:03 PM, Robert Kern wrote: >>> On Wed, Jun 1, 2011 at 09:30, ? wrote: >>> >>>> How to proceed if these issues are addressed: >>>> Since it is a new function, it would be easy to integrate it into >>>> scipy from the python files, but if you are familiar with git and >>>> github, the integration will eventually be easier if you fork scipy >>>> and add the function to scipy.stats and make a pull request. >>>> A trac ticket would also be useful to keep track of the contribution >>>> (I don't know if github will substitute for this). >>> >>> I think a pull request would be sufficient for tracking. >> >> Are pull requests indexed and searchable? > > Indexed, yes. > > https://github.com/scipy/scipy/pulls This list looks pretty useless to me, if I want to look for something. At least I didn't find a way to get all pull requests that went into scipy.stats. (Neither did I find a way to search the changesets.) Josef > >> Until now I always relied that searching in trac shows all relevant >> information, but the one-stop searching seems to be gone for now. > > -- > Robert Kern > > "I have come to believe that the whole world is an enigma, a harmless > enigma that is made terrible by our own mad attempt to interpret it as > though it had an underlying truth." > ? -- Umberto Eco > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev > From josef.pktd at gmail.com Wed Jun 1 13:36:23 2011 From: josef.pktd at gmail.com (josef.pktd at gmail.com) Date: Wed, 1 Jun 2011 13:36:23 -0400 Subject: [SciPy-Dev] Van der Waerden test in Scipy? In-Reply-To: References: Message-ID: On Wed, Jun 1, 2011 at 12:36 PM, wrote: > On Wed, Jun 1, 2011 at 12:18 PM, Robert Kern wrote: >> On Wed, Jun 1, 2011 at 11:15, ? wrote: >>> On Wed, Jun 1, 2011 at 12:03 PM, Robert Kern wrote: >>>> On Wed, Jun 1, 2011 at 09:30, ? wrote: >>>> >>>>> How to proceed if these issues are addressed: >>>>> Since it is a new function, it would be easy to integrate it into >>>>> scipy from the python files, but if you are familiar with git and >>>>> github, the integration will eventually be easier if you fork scipy >>>>> and add the function to scipy.stats and make a pull request. >>>>> A trac ticket would also be useful to keep track of the contribution >>>>> (I don't know if github will substitute for this). >>>> >>>> I think a pull request would be sufficient for tracking. >>> >>> Are pull requests indexed and searchable? >> >> Indexed, yes. >> >> https://github.com/scipy/scipy/pulls > > This list looks pretty useless to me, if I want to look for something. > At least I didn't find a way to get all pull requests that went into > scipy.stats. (Neither did I find a way to search the changesets.) Since it's almost on topic http://xkcd.com/903/ (Wikipedia, .chm files, and searchability/googleability) Josef > > Josef > >> >>> Until now I always relied that searching in trac shows all relevant >>> information, but the one-stop searching seems to be gone for now. >> >> -- >> Robert Kern >> >> "I have come to believe that the whole world is an enigma, a harmless >> enigma that is made terrible by our own mad attempt to interpret it as >> though it had an underlying truth." >> ? -- Umberto Eco >> _______________________________________________ >> SciPy-Dev mailing list >> SciPy-Dev at scipy.org >> http://mail.scipy.org/mailman/listinfo/scipy-dev >> > From ralf.gommers at googlemail.com Wed Jun 1 17:07:43 2011 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Wed, 1 Jun 2011 23:07:43 +0200 Subject: [SciPy-Dev] Van der Waerden test in Scipy? In-Reply-To: References: Message-ID: On Wed, Jun 1, 2011 at 7:36 PM, wrote: > On Wed, Jun 1, 2011 at 12:36 PM, wrote: > > On Wed, Jun 1, 2011 at 12:18 PM, Robert Kern > wrote: > >> On Wed, Jun 1, 2011 at 11:15, wrote: > >>> On Wed, Jun 1, 2011 at 12:03 PM, Robert Kern > wrote: > >>>> On Wed, Jun 1, 2011 at 09:30, wrote: > >>>> > >>>>> How to proceed if these issues are addressed: > >>>>> Since it is a new function, it would be easy to integrate it into > >>>>> scipy from the python files, but if you are familiar with git and > >>>>> github, the integration will eventually be easier if you fork scipy > >>>>> and add the function to scipy.stats and make a pull request. > >>>>> A trac ticket would also be useful to keep track of the contribution > >>>>> (I don't know if github will substitute for this). > >>>> > >>>> I think a pull request would be sufficient for tracking. > >>> > >>> Are pull requests indexed and searchable? > >> > >> Indexed, yes. > >> > >> https://github.com/scipy/scipy/pulls > > > > This list looks pretty useless to me, if I want to look for something. > > At least I didn't find a way to get all pull requests that went into > > scipy.stats. (Neither did I find a way to search the changesets.) > > Pull requests should be for code that is ready to be merged imho, not for using it as a poor man's Trac. For numpy we have kept the number of open pull requests below ten for almost a year now because we haven't been using it for unfinished contributions like this. Please let's try to keep it like that. Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.gommers at googlemail.com Wed Jun 1 18:12:43 2011 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Thu, 2 Jun 2011 00:12:43 +0200 Subject: [SciPy-Dev] Platform-dependent tests? In-Reply-To: References: Message-ID: On Tue, May 31, 2011 at 12:13 AM, Warren Weckesser < warren.weckesser at enthought.com> wrote: > Jeff Armstrong has enhanced the Schur decomposition function > scipy.linalg.schur to expose the ability to sort the eigenvalues (more > accurately, group them according to a boolean function); see > https://github.com/scipy/scipy/pull/23. schur() is a wrapper for the > DGEES Fortran library function. According to its documentation, if the > matrix is poorly scaled, the eigenvalues can fail to satisfy the sorting > condition *after* they've been sorted, because of rounding errors. The > function returns an error code when this occurs. > > Jeff's code checks for this condition, and he also added a couple unit > tests for it. Unfortunately, the tests fail on my computer--that is, the > error condition does not happen. This is not surprising, as the error > condition relies on the behavior of rounding errors. So, to the question: > is there a way to make these tests platform-dependent, so that they only run > on a platform/architecture/whatever where the tests are known to trigger the > desired condition? Or is the result likely to depend on so many other > factors (compiler and optimization settings, third party math library, phase > of the moon, etc) that it is hopeless to try? > The test still enabled in Jeff's branch fails for me, while the commented-out one would actually pass. It's straightforward to make the test platform-dependent with the skipif decorator, but I think you don't want to test this. The result will depend on the exact config used, of which there are way too many. Failing tests like these usually lead to some users thinking there's something wrong with their install. Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From rogerlew at gmail.com Thu Jun 2 00:53:48 2011 From: rogerlew at gmail.com (Roger Lew) Date: Wed, 1 Jun 2011 21:53:48 -0700 Subject: [SciPy-Dev] studentized range approximations Message-ID: Hi, I have implemented some approximations for studentized range quantiles and probabilities based on John R. Gleason's (1999) "An accurate, non-iterative approximation for studentized range quantiles." Computational Statistics & Data Analysis, (31), 147-158. Probability approximations rely on scipy.optimize.fminbound. The functions accept both scalars or array-like data thanks to numpy.vectorize. A fair amount of validation and testing has been conducted on the code. More details can be found here: http://code.google.com/p/qsturng-py/ I welcome any thoughts as to whether you all think this might be useful to add to SciPy or make into a scikit. Any general comments would be helpful as well. I should mention I'm a cognitive neuroscientist by trade, my use of statistical jargon probably isn't that good. Regards, Roger Roger Lew -------------- next part -------------- An HTML attachment was scrubbed... URL: From josef.pktd at gmail.com Thu Jun 2 04:38:17 2011 From: josef.pktd at gmail.com (josef.pktd at gmail.com) Date: Thu, 2 Jun 2011 04:38:17 -0400 Subject: [SciPy-Dev] studentized range approximations In-Reply-To: References: Message-ID: On Thu, Jun 2, 2011 at 12:53 AM, Roger Lew wrote: > Hi, > I have implemented some?approximations?for studentized range quantiles and > probabilities based on John R. Gleason's (1999) "An accurate, non-iterative > approximation?for studentized range quantiles." Computational Statistics & > Data Analysis, (31), 147-158. > Probability approximations rely on scipy.optimize.fminbound. The functions > accept both scalars or array-like data thanks to numpy.vectorize. A fair > amount of validation and testing has been conducted on the code. More > details can be found here:?http://code.google.com/p/qsturng-py/ > I welcome any thoughts as to whether you all think this might be useful to > add to SciPy or make into a scikit. Any general comments would be helpful as > well. I should mention I'm a cognitive neuroscientist by trade, my use of > statistical jargon probably isn't that good. Hi Roger, I'm very interested in using this in scikits.statsmodels. The table that I am currently using is very limited http://statsmodels.sourceforge.net/devel/generated/scikits.statsmodels.sandbox.stats.multicomp.get_tukeyQcrit.html#scikits.statsmodels.sandbox.stats.multicomp.get_tukeyQcrit >From a quick look it looks very good. What I found a bit confusing is that qstrung takes the probability of the cdf and not of the survival function. Without reading the docstring carefully enough, I interpreted it as a p-value (upper tail) especially since pstrung returns the upper tail probability, >>> import scikits.statsmodels.sandbox.stats.multicomp as smmc >>> for i in range(3, 10): x = qsturng(0.95, i, 16) x, psturng(x, i, 16), smmc.get_tukeyQcrit(i, 16, 0.05), smmc.tukey_pvalues(x*np.ones(i), 16)[0] (3.647864471854692, 0.049999670839029453, array(3.6499999999999999), 0.050092818925981608) (4.0464124382823847, 0.050001178443752514, array(4.0499999999999998), 0.037164602483501508) (4.3332505094058114, 0.049999838126148499, array(4.3300000000000001), 0.029954033157223781) (4.5573603020371234, 0.049999276281813887, array(4.5599999999999996), 0.025276987281047769) (4.7410585998112742, 0.049998508166777755, array(4.7400000000000002), 0.022010630154416622) (4.8965400268915289, 0.04999983345598491, array(4.9000000000000004), 0.019614841752159107) (5.0312039650945257, 0.049999535359310343, array(5.0300000000000002), 0.017721848279719898) The last column is (in my interpretation) supposed to be 0.05. I was trying to get the pvalues for Tukeys range statistic through the multivariate t-distribution, but the unit test looks only at one point (and I ran out of time to work on this during Christmas break). Either there is a bug (it's still in the sandbox) or my interpretation is wrong. The advantage of the multivariate t-distribution is that it allows for arbitrary correlation, but it's not a substitute for pre-calculated tables for standard cases/distributions because it's much too slow. ------------ As a bit of background on the multiple testing, multiple comparison status in statsmodels: The tukeyhsd test has one test case against R, but it has too many options (it allows unequal variances and unequal sample sizes, that still need to be checked.) http://statsmodels.sourceforge.net/devel/generated/scikits.statsmodels.sandbox.stats.multicomp.tukeyhsd.html#scikits.statsmodels.sandbox.stats.multicomp.tukeyhsd What I did manage to finish and verify against R http://statsmodels.sourceforge.net/devel/generated/scikits.statsmodels.sandbox.stats.multicomp.multipletests.html#scikits.statsmodels.sandbox.stats.multicomp.multipletests multiple testing for general linear models is very incomplete and as an aside: I'm not a statistician, and if the module in the statsmodels sandbox is still a mess then it's because I took me a long time and many functions to figure out what's going on. ---------- scipy.special has a nice collection of standard distributions functions, but it would be very useful to have some additional distributions either in scipy or scikits.statsmodels available, like your studentized range statistic, (and maybe some others in multiple comparisons, like Duncan, Dunnet) and Anderson-Darling, and ... Thanks, Josef > Regards, > Roger > Roger Lew > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev > > From rogerlew at gmail.com Thu Jun 2 14:15:52 2011 From: rogerlew at gmail.com (Roger Lew) Date: Thu, 2 Jun 2011 11:15:52 -0700 Subject: [SciPy-Dev] studentized range approximations In-Reply-To: References: Message-ID: Hi Josef, Thanks for the feedback. The "choice" of using cdf is more a carryover from how the algorithm is described by Gleason. Perhaps it would be best to have it match your intuition and accept the survival function? Feel free to treat it like your own for statsmodels. I will definitely check out some of your multcomp module so I'm not reinventing the wheel. In the grand scheme, I could see these having a home in scipy.special (after more extensive review of course). That is where I went to look for it when I didn't find it in distributions. Roger On Thu, Jun 2, 2011 at 1:38 AM, wrote: > On Thu, Jun 2, 2011 at 12:53 AM, Roger Lew wrote: > > Hi, > > I have implemented some approximations for studentized range quantiles > and > > probabilities based on John R. Gleason's (1999) "An accurate, > non-iterative > > approximation for studentized range quantiles." Computational Statistics > & > > Data Analysis, (31), 147-158. > > Probability approximations rely on scipy.optimize.fminbound. The > functions > > accept both scalars or array-like data thanks to numpy.vectorize. A fair > > amount of validation and testing has been conducted on the code. More > > details can be found here: http://code.google.com/p/qsturng-py/ > > I welcome any thoughts as to whether you all think this might be useful > to > > add to SciPy or make into a scikit. Any general comments would be helpful > as > > well. I should mention I'm a cognitive neuroscientist by trade, my use of > > statistical jargon probably isn't that good. > > Hi Roger, > > I'm very interested in using this in scikits.statsmodels. The table > that I am currently using is very limited > > http://statsmodels.sourceforge.net/devel/generated/scikits.statsmodels.sandbox.stats.multicomp.get_tukeyQcrit.html#scikits.statsmodels.sandbox.stats.multicomp.get_tukeyQcrit > > >From a quick look it looks very good. > What I found a bit confusing is that qstrung takes the probability of > the cdf and not of the survival function. Without reading the > docstring carefully enough, I interpreted it as a p-value (upper tail) > especially since pstrung returns the upper tail probability, > > >>> import scikits.statsmodels.sandbox.stats.multicomp as smmc > >>> for i in range(3, 10): > x = qsturng(0.95, i, 16) > x, psturng(x, i, 16), smmc.get_tukeyQcrit(i, 16, 0.05), > smmc.tukey_pvalues(x*np.ones(i), 16)[0] > > > (3.647864471854692, 0.049999670839029453, array(3.6499999999999999), > 0.050092818925981608) > (4.0464124382823847, 0.050001178443752514, array(4.0499999999999998), > 0.037164602483501508) > (4.3332505094058114, 0.049999838126148499, array(4.3300000000000001), > 0.029954033157223781) > (4.5573603020371234, 0.049999276281813887, array(4.5599999999999996), > 0.025276987281047769) > (4.7410585998112742, 0.049998508166777755, array(4.7400000000000002), > 0.022010630154416622) > (4.8965400268915289, 0.04999983345598491, array(4.9000000000000004), > 0.019614841752159107) > (5.0312039650945257, 0.049999535359310343, array(5.0300000000000002), > 0.017721848279719898) > > The last column is (in my interpretation) supposed to be 0.05. I was > trying to get the pvalues for Tukeys range statistic through the > multivariate t-distribution, but the unit test looks only at one point > (and I ran out of time to work on this during Christmas break). Either > there is a bug (it's still in the sandbox) or my interpretation is > wrong. > > The advantage of the multivariate t-distribution is that it allows for > arbitrary correlation, but it's not a substitute for pre-calculated > tables for standard cases/distributions because it's much too slow. > > ------------ > As a bit of background on the multiple testing, multiple comparison > status in statsmodels: > > The tukeyhsd test has one test case against R, but it has too many > options (it allows unequal variances and unequal sample sizes, that > still need to be checked.) > > > http://statsmodels.sourceforge.net/devel/generated/scikits.statsmodels.sandbox.stats.multicomp.tukeyhsd.html#scikits.statsmodels.sandbox.stats.multicomp.tukeyhsd > > What I did manage to finish and verify against R > > > http://statsmodels.sourceforge.net/devel/generated/scikits.statsmodels.sandbox.stats.multicomp.multipletests.html#scikits.statsmodels.sandbox.stats.multicomp.multipletests > > multiple testing for general linear models is very incomplete > > and as an aside: I'm not a statistician, and if the module in the > statsmodels sandbox is still a mess then it's because I took me a long > time and many functions to figure out what's going on. > ---------- > > scipy.special has a nice collection of standard distributions > functions, but it would be very useful to have some additional > distributions either in scipy or scikits.statsmodels available, like > your studentized range statistic, (and maybe some others in multiple > comparisons, like Duncan, Dunnet) and Anderson-Darling, and ... > > Thanks, > > Josef > > > > Regards, > > Roger > > Roger Lew > > > > _______________________________________________ > > SciPy-Dev mailing list > > SciPy-Dev at scipy.org > > http://mail.scipy.org/mailman/listinfo/scipy-dev > > > > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fperez.net at gmail.com Fri Jun 3 01:33:20 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Thu, 2 Jun 2011 22:33:20 -0700 Subject: [SciPy-Dev] Van der Waerden test in Scipy? In-Reply-To: References: Message-ID: On Wed, Jun 1, 2011 at 2:07 PM, Ralf Gommers wrote: > Pull requests should be for code that is ready to be merged imho, not for > using it as a poor man's Trac. For numpy we have kept the number of open > pull requests below ten for almost a year now because we haven't been using > it for unfinished contributions like this. Please let's try to keep it like > that. +1 While work is in-development, I'd suggest that a ticket be opened in the scipy repo, with a link to a branch in the person's own fork. The discussion can then happen on the scipy repo, but the work will evolve in that fork possibly changing a lot, maybe even being dropped and with a new branch started, perhaps a different person will come up with a better approach elsewhere, etc. Once something gets baked out enough to be truly pulled, then such an action should be requested. Hence the name, pull request :) Cheers, f From bsouthey at gmail.com Fri Jun 3 09:37:32 2011 From: bsouthey at gmail.com (Bruce Southey) Date: Fri, 03 Jun 2011 08:37:32 -0500 Subject: [SciPy-Dev] studentized range approximations In-Reply-To: References: Message-ID: <4DE8E39C.7000405@gmail.com> On 06/02/2011 01:15 PM, Roger Lew wrote: > Hi Josef, > > Thanks for the feedback. The "choice" of using cdf is more a carryover > from how the algorithm is described by Gleason. Perhaps it would be > best to have it match your intuition and accept the survival function? > > Feel free to treat it like your own for statsmodels. I will definitely > check out some of your multcomp module so I'm not reinventing the wheel. > > In the grand scheme, I could see these having a home in scipy.special > (after more extensive review of course). That is where I went to look > for it when I didn't find it in distributions. > > Roger > > On Thu, Jun 2, 2011 at 1:38 AM, > wrote: > > On Thu, Jun 2, 2011 at 12:53 AM, Roger Lew > wrote: > > Hi, > > I have implemented some approximations for studentized range > quantiles and > > probabilities based on John R. Gleason's (1999) "An accurate, > non-iterative > > approximation for studentized range quantiles." Computational > Statistics & > > Data Analysis, (31), 147-158. > > Probability approximations rely on scipy.optimize.fminbound. The > functions > > accept both scalars or array-like data thanks to > numpy.vectorize. A fair > > amount of validation and testing has been conducted on the code. > More > > details can be found here: http://code.google.com/p/qsturng-py/ > > I welcome any thoughts as to whether you all think this might be > useful to > > add to SciPy or make into a scikit. Any general comments would > be helpful as > > well. I should mention I'm a cognitive neuroscientist by trade, > my use of > > statistical jargon probably isn't that good. > > Hi Roger, > > I'm very interested in using this in scikits.statsmodels. The table > that I am currently using is very limited > http://statsmodels.sourceforge.net/devel/generated/scikits.statsmodels.sandbox.stats.multicomp.get_tukeyQcrit.html#scikits.statsmodels.sandbox.stats.multicomp.get_tukeyQcrit > > >From a quick look it looks very good. > What I found a bit confusing is that qstrung takes the probability of > the cdf and not of the survival function. Without reading the > docstring carefully enough, I interpreted it as a p-value (upper tail) > especially since pstrung returns the upper tail probability, > > >>> import scikits.statsmodels.sandbox.stats.multicomp as smmc > >>> for i in range(3, 10): > x = qsturng(0.95, i, 16) > x, psturng(x, i, 16), smmc.get_tukeyQcrit(i, 16, 0.05), > smmc.tukey_pvalues(x*np.ones(i), 16)[0] > > > (3.647864471854692, 0.049999670839029453, array(3.6499999999999999), > 0.050092818925981608) > (4.0464124382823847, 0.050001178443752514, array(4.0499999999999998), > 0.037164602483501508) > (4.3332505094058114, 0.049999838126148499, array(4.3300000000000001), > 0.029954033157223781) > (4.5573603020371234, 0.049999276281813887, array(4.5599999999999996), > 0.025276987281047769) > (4.7410585998112742, 0.049998508166777755, array(4.7400000000000002), > 0.022010630154416622) > (4.8965400268915289, 0.04999983345598491, array(4.9000000000000004), > 0.019614841752159107) > (5.0312039650945257, 0.049999535359310343, array(5.0300000000000002), > 0.017721848279719898) > > The last column is (in my interpretation) supposed to be 0.05. I was > trying to get the pvalues for Tukeys range statistic through the > multivariate t-distribution, but the unit test looks only at one point > (and I ran out of time to work on this during Christmas break). Either > there is a bug (it's still in the sandbox) or my interpretation is > wrong. > > The advantage of the multivariate t-distribution is that it allows for > arbitrary correlation, but it's not a substitute for pre-calculated > tables for standard cases/distributions because it's much too slow. > > ------------ > As a bit of background on the multiple testing, multiple comparison > status in statsmodels: > > The tukeyhsd test has one test case against R, but it has too many > options (it allows unequal variances and unequal sample sizes, that > still need to be checked.) > > http://statsmodels.sourceforge.net/devel/generated/scikits.statsmodels.sandbox.stats.multicomp.tukeyhsd.html#scikits.statsmodels.sandbox.stats.multicomp.tukeyhsd > > What I did manage to finish and verify against R > > http://statsmodels.sourceforge.net/devel/generated/scikits.statsmodels.sandbox.stats.multicomp.multipletests.html#scikits.statsmodels.sandbox.stats.multicomp.multipletests > > multiple testing for general linear models is very incomplete > > and as an aside: I'm not a statistician, and if the module in the > statsmodels sandbox is still a mess then it's because I took me a long > time and many functions to figure out what's going on. > ---------- > > scipy.special has a nice collection of standard distributions > functions, but it would be very useful to have some additional > distributions either in scipy or scikits.statsmodels available, like > your studentized range statistic, (and maybe some others in multiple > comparisons, like Duncan, Dunnet) and Anderson-Darling, and ... > > Thanks, > > Josef > > > > Regards, > > Roger > > Roger Lew > > > > _______________________________________________ > > SciPy-Dev mailing list > > SciPy-Dev at scipy.org > > http://mail.scipy.org/mailman/listinfo/scipy-dev > > > > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev > > > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev The problem I have is that this is still an approximation that probably covers what most situations. Do you have the Copenhaver & Holland (1988) approach or know any BSD-licensed Python code for it? Also, the code probably needs to conform to numpy/scipy standards (which I don't remember the links). You also have vary less desirable features: 1) hard coded numbers like '1e38' - numpy does define infinity (np.inf). 2) comparisons to 'inf' ('v==inf') that are not desirable. Bruce -------------- next part -------------- An HTML attachment was scrubbed... URL: From rogerlew at gmail.com Fri Jun 3 14:17:30 2011 From: rogerlew at gmail.com (Roger Lew) Date: Fri, 3 Jun 2011 11:17:30 -0700 Subject: [SciPy-Dev] studentized range approximations In-Reply-To: <4DE8E39C.7000405@gmail.com> References: <4DE8E39C.7000405@gmail.com> Message-ID: Hi Bruce, My comparisons were made with R's qtukey. qtukey is GNU v2 or later and uses the Copenhaver & Holland (1988) approach. From testing I have found qtukey has weaknesses of its own. qtukey doesn't do well when v is small and p is close to 1. When compared to Harter's (1960) qtukey severely underestimates quantiles with p=.999 and v=2. For r values in the table (ranging from 2 to 100) qtukey is off by the following percentages 100 * (qtukey - table) / table: -22.32 -29.80 -33.68 -36.10 -37.79 -39.04 -40.01 -40.79 -41.45 -41.97 -42.46 -42.86 -43.26 -43.55 -43.88 -44.15 -44.35 -44.57 -44.78 -46.17 -47.01 -47.96 -48.56 -48.96 with p=.999 and v=3 qtukey is overestimates quantiles and fails to converge for r=80 and r=100: -0.02 1.65 3.82 6.15 8.18 9.84 11.17 12.18 13.02 13.69 14.24 14.72 15.14 15.50 15.78 16.06 16.32 16.51 16.72 18.03 18.70 19.46 nan nan At p=.975 and v=2 qtukey is still biased but much closer (in percentages): -0.24 -0.03 -0.01 0.02 -0.10 -0.23 -0.38 -0.55 -0.70 -0.83 -0.94 -1.02 -1.08 -1.16 -1.26 -1.34 -1.38 -1.45 -1.46 -1.82 -2.00 -2.23 -2.35 -2.45 qtukey also has a hard time converging in certain parameter ranges. When r=70 and v= inf: p,q 0.5,4.707268 0.5050404,4.715069 0.5100808,NaN 0.5151212,NaN 0.5201616,4.738577 0.525202,4.746453 0.5302424,NaN 0.5352828,NaN 0.5403232,NaN 0.5453636,NaN 0.550404,NaN 0.5554444,NaN 0.5604848,NaN 0.5655253,NaN 0.5705657,NaN 0.5756061,NaN 0.5806465,NaN 0.5856869,4.843067 0.5907273,4.851339 0.5957677,4.859652 0.6008081,4.86801 0.6058485,4.876412 0.6108889,4.884861 0.6159293,4.893358 0.6209697,4.901907 I think the case could be made that the qtukey (Copenhaver & Holland approach) may be better for some things (higher precision given certain qualifications), and Gleason's approach may be better for others, but I don't think that one is clearly superior to the other. (A Copenhaver & Holland with 128 bit floats may be a different story). I think the case can be made that for multiple comparison testing Gleason's approach may be better. The fact that it is fit to Harter's tables means "apple to apple" comparisons to people still using "paper tables." Secondly, because Gleason's approach may be preferred since the empirical data seems to suggest it is less biased for small v and cdf values close to 1. I should have documented it better, but the reason 1e38 is used instead of inf is because scipy.stats.t.isf has what I would describe as a loss of entropy when v == inf >>> scipy.stats.t.isf(.1, inf), scipy.stats.t.isf(.1, 1e38) (-1e+100, 1.2815515655446004) >>> scipy.stats.t.isf(.2, inf), scipy.stats.t.isf(.2, 1e38) (-1e+100, 0.84162123357291441) >>> scipy.stats.t.isf(.5, inf), scipy.stats.t.isf(.5, 1e38) (-6.637989916170446e-17, -6.637989916170446e-17) >>> scipy.stats.t.isf(.8, inf), scipy.stats.t.isf(.8, 1e38) (-1e+100, -0.84162123357291441) >>> scipy.stats.t.isf(.95, inf), scipy.stats.t.isf(.95, 1e38) (-1e+100, -1.6448536269514722) >>> scipy.stats.t.isf(.999, inf), scipy.stats.t.isf(.999, 1e38) (-1e+100, -3.0902323061678132) >>> For consistency 1e38 was used throughout. It is also difficult to apply interpolation between 120 and inf. If there is a better method of getting t inverse, I'm willing to rework the code. Given how much the distribution changes in that range relative to the overall precision of the algorithm, my personal opinion is that it is a small issue. I do think it should be better commented and added to the list of caveats. v is always a scalar for the v==inf comparisons, but I don't have a problem using math.isinf if that is the preferred method. Roger On Fri, Jun 3, 2011 at 6:37 AM, Bruce Southey wrote: > On 06/02/2011 01:15 PM, Roger Lew wrote: > > Hi Josef, > > Thanks for the feedback. The "choice" of using cdf is more a carryover > from how the algorithm is described by Gleason. Perhaps it would be best to > have it match your intuition and accept the survival function? > > Feel free to treat it like your own for statsmodels. I will definitely > check out some of your multcomp module so I'm not reinventing the wheel. > > In the grand scheme, I could see these having a home in scipy.special > (after more extensive review of course). That is where I went to look for it > when I didn't find it in distributions. > > Roger > > On Thu, Jun 2, 2011 at 1:38 AM, wrote: > >> On Thu, Jun 2, 2011 at 12:53 AM, Roger Lew wrote: >> > Hi, >> > I have implemented some approximations for studentized range quantiles >> and >> > probabilities based on John R. Gleason's (1999) "An accurate, >> non-iterative >> > approximation for studentized range quantiles." Computational Statistics >> & >> > Data Analysis, (31), 147-158. >> > Probability approximations rely on scipy.optimize.fminbound. The >> functions >> > accept both scalars or array-like data thanks to numpy.vectorize. A fair >> > amount of validation and testing has been conducted on the code. More >> > details can be found here: http://code.google.com/p/qsturng-py/ >> > I welcome any thoughts as to whether you all think this might be useful >> to >> > add to SciPy or make into a scikit. Any general comments would be >> helpful as >> > well. I should mention I'm a cognitive neuroscientist by trade, my use >> of >> > statistical jargon probably isn't that good. >> >> Hi Roger, >> >> I'm very interested in using this in scikits.statsmodels. The table >> that I am currently using is very limited >> >> http://statsmodels.sourceforge.net/devel/generated/scikits.statsmodels.sandbox.stats.multicomp.get_tukeyQcrit.html#scikits.statsmodels.sandbox.stats.multicomp.get_tukeyQcrit >> >> >From a quick look it looks very good. >> What I found a bit confusing is that qstrung takes the probability of >> the cdf and not of the survival function. Without reading the >> docstring carefully enough, I interpreted it as a p-value (upper tail) >> especially since pstrung returns the upper tail probability, >> >> >>> import scikits.statsmodels.sandbox.stats.multicomp as smmc >> >>> for i in range(3, 10): >> x = qsturng(0.95, i, 16) >> x, psturng(x, i, 16), smmc.get_tukeyQcrit(i, 16, 0.05), >> smmc.tukey_pvalues(x*np.ones(i), 16)[0] >> >> >> (3.647864471854692, 0.049999670839029453, array(3.6499999999999999), >> 0.050092818925981608) >> (4.0464124382823847, 0.050001178443752514, array(4.0499999999999998), >> 0.037164602483501508) >> (4.3332505094058114, 0.049999838126148499, array(4.3300000000000001), >> 0.029954033157223781) >> (4.5573603020371234, 0.049999276281813887, array(4.5599999999999996), >> 0.025276987281047769) >> (4.7410585998112742, 0.049998508166777755, array(4.7400000000000002), >> 0.022010630154416622) >> (4.8965400268915289, 0.04999983345598491, array(4.9000000000000004), >> 0.019614841752159107) >> (5.0312039650945257, 0.049999535359310343, array(5.0300000000000002), >> 0.017721848279719898) >> >> The last column is (in my interpretation) supposed to be 0.05. I was >> trying to get the pvalues for Tukeys range statistic through the >> multivariate t-distribution, but the unit test looks only at one point >> (and I ran out of time to work on this during Christmas break). Either >> there is a bug (it's still in the sandbox) or my interpretation is >> wrong. >> >> The advantage of the multivariate t-distribution is that it allows for >> arbitrary correlation, but it's not a substitute for pre-calculated >> tables for standard cases/distributions because it's much too slow. >> >> ------------ >> As a bit of background on the multiple testing, multiple comparison >> status in statsmodels: >> >> The tukeyhsd test has one test case against R, but it has too many >> options (it allows unequal variances and unequal sample sizes, that >> still need to be checked.) >> >> >> http://statsmodels.sourceforge.net/devel/generated/scikits.statsmodels.sandbox.stats.multicomp.tukeyhsd.html#scikits.statsmodels.sandbox.stats.multicomp.tukeyhsd >> >> What I did manage to finish and verify against R >> >> >> http://statsmodels.sourceforge.net/devel/generated/scikits.statsmodels.sandbox.stats.multicomp.multipletests.html#scikits.statsmodels.sandbox.stats.multicomp.multipletests >> >> multiple testing for general linear models is very incomplete >> >> and as an aside: I'm not a statistician, and if the module in the >> statsmodels sandbox is still a mess then it's because I took me a long >> time and many functions to figure out what's going on. >> ---------- >> >> scipy.special has a nice collection of standard distributions >> functions, but it would be very useful to have some additional >> distributions either in scipy or scikits.statsmodels available, like >> your studentized range statistic, (and maybe some others in multiple >> comparisons, like Duncan, Dunnet) and Anderson-Darling, and ... >> >> Thanks, >> >> Josef >> >> >> > Regards, >> > Roger >> > Roger Lew >> > >> > _______________________________________________ >> > SciPy-Dev mailing list >> > SciPy-Dev at scipy.org >> > http://mail.scipy.org/mailman/listinfo/scipy-dev >> > >> > >> _______________________________________________ >> SciPy-Dev mailing list >> SciPy-Dev at scipy.org >> http://mail.scipy.org/mailman/listinfo/scipy-dev >> > > > _______________________________________________ > SciPy-Dev mailing listSciPy-Dev at scipy.orghttp://mail.scipy.org/mailman/listinfo/scipy-dev > > The problem I have is that this is still an approximation that probably > covers what most situations. > Do you have the Copenhaver & Holland (1988) approach or know any > BSD-licensed Python code for it? > > > Also, the code probably needs to conform to numpy/scipy standards (which I > don't remember the links). > You also have vary less desirable features: > 1) hard coded numbers like '1e38' - numpy does define infinity (np.inf). > 2) comparisons to 'inf' ('v==inf') that are not desirable. > > Bruce > > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.gommers at googlemail.com Fri Jun 3 15:57:59 2011 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Fri, 3 Jun 2011 21:57:59 +0200 Subject: [SciPy-Dev] prepending underscores to private module names Message-ID: Hi, A while ago we discussed making a clear distinction between public and private modules by using underscores consistently, see http://thread.gmane.org/gmane.comp.python.scientific.devel/14936. I've done this for a few modules now, see https://github.com/rgommers/scipy/tree/underscores. Most files could simply be underscored, some other would conflict with extension modules so I also had to append _py to the name. Also I added a file doc/source/api.rst that states which modules are public (up for discussion of course). With google code search I checked how common it is to import from modules that are supposed to be private, for example "from scipy.optimize.optimize import fmin". It's not very common but does happen, so deprecation warnings should be put in. Before going further I'd like to check that this looks okay to people. What do you think? Cheers, Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.kern at gmail.com Fri Jun 3 16:05:31 2011 From: robert.kern at gmail.com (Robert Kern) Date: Fri, 3 Jun 2011 15:05:31 -0500 Subject: [SciPy-Dev] prepending underscores to private module names In-Reply-To: References: Message-ID: On Fri, Jun 3, 2011 at 14:57, Ralf Gommers wrote: > Hi, > > A while ago we discussed making a clear distinction between public and > private modules by using underscores consistently, see > http://thread.gmane.org/gmane.comp.python.scientific.devel/14936. > > I've done this for a few modules now, see > https://github.com/rgommers/scipy/tree/underscores. Most files could simply > be underscored, some other would conflict with extension modules so I also > had to append _py to the name. Also I added a file doc/source/api.rst that > states which modules are public (up for discussion of course). > > With google code search I checked how common it is to import from modules > that are supposed to be private, for example "from scipy.optimize.optimize > import fmin". It's not very common but does happen, so deprecation warnings > should be put in. > > Before going further I'd like to check that this looks okay to people. What > do you think? I'm still -1 on it. I think it's unnecessary and potentially disruptive. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." ? -- Umberto Eco From ralf.gommers at googlemail.com Fri Jun 3 19:38:27 2011 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Sat, 4 Jun 2011 01:38:27 +0200 Subject: [SciPy-Dev] prepending underscores to private module names In-Reply-To: References: Message-ID: On Fri, Jun 3, 2011 at 10:05 PM, Robert Kern wrote: > On Fri, Jun 3, 2011 at 14:57, Ralf Gommers > wrote: > > Hi, > > > > A while ago we discussed making a clear distinction between public and > > private modules by using underscores consistently, see > > http://thread.gmane.org/gmane.comp.python.scientific.devel/14936. > > > > I've done this for a few modules now, see > > https://github.com/rgommers/scipy/tree/underscores. Most files could > simply > > be underscored, some other would conflict with extension modules so I > also > > had to append _py to the name. Also I added a file doc/source/api.rst > that > > states which modules are public (up for discussion of course). > > > > With google code search I checked how common it is to import from modules > > that are supposed to be private, for example "from > scipy.optimize.optimize > > import fmin". It's not very common but does happen, so deprecation > warnings > > should be put in. > > > > Before going further I'd like to check that this looks okay to people. > What > > do you think? > > I'm still -1 on it. I think it's unnecessary and potentially disruptive. > > It will indeed be disruptive for those users who imported from private modules, they will get deprecation warnings and would need to update their code. Those same users can run into trouble anyway though unless we treat everything that is now ambiguous as public. Unnecessary, I disagree. Even among developers it is not clear what the public API is. This is the clearest way to solve it. An alternative would be to just document very clearly what the API is. Just saying "The public API of a package is determined by any number of conventions which may or may not be documented explicitly." doesn't help much. Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From annalisa.py at gmail.com Sat Jun 4 06:57:19 2011 From: annalisa.py at gmail.com (Annalisa Minelli) Date: Sat, 4 Jun 2011 12:57:19 +0200 Subject: [SciPy-Dev] Van der Waerden test in Scipy? In-Reply-To: References: Message-ID: Hi Josef, hi all, thanks for answering and thanks for the questions/hints.. 2011/6/1 > On Wed, Jun 1, 2011 at 3:56 AM, Annalisa Minelli > wrote: > > Dear Scipy developers, > > I'm Annalisa Minelli, a PhD student from Perugia (Italy), and I'm using > > Scipy library because I'm writing some code for my PhD thesis. > > Since I needed van der waerden chisquare pvalue[0], which is implemented > in > > R but not in Scipy (if I'm not wrong)[1], I implemented the test in > python > > language [3] to break any R dependency for my module. > > > > So if you think it can be useful, maybe it could be integrated into the > > Scipy library? > > Could you give me any advice on how to proceed? > > Thanks Annalisa, > > I think it would be useful to have this test (and similar tests based > on transformation to the normal distribution). > > I downloaded your vdw.py. I haven't looked at the details yet, but > here are 3 main issues: > > your vdw is GPL which is incompatible with scipy's BSD license, for > inclusion in scipy it would need to be a contribution licensed as BSD > ok, I suppose I can change the license. I initially made this choice because I need this function into a GRASS GIS module - r.broscoe [0] and the Project uses GPL, but for sure I'd like to include the function in the Scipy library (which is used by GRASS). > your function is not using numpy, and it seems to me that many of the > list operations can be vectorized with numpy > ok, I'll try this way if you think it's better; I initially thought that the less dependencies was the best, but if you think I can considerably hack the code in this way, I will do it. > > no tests: since you have the equivalent function in R, it would be > good to add some tests that have results from R to check that the > function produces the same results. ( for explanation and examples: > https://github.com/numpy/numpy/blob/master/doc/TESTS.rst.txt or look > in scipy.stats.tests ) > thanks for the hint; the pics I reported in my blog are from a run that takes in input the example data.frame of R for the equivalent waerden.test function (the data.frame is "sweetpotato") - with the only difference that my function uses numbers for groups instead of strings (maybe I can fix this..) but I'll do more tests, following numpy tests "standards" - thank you > > additional: docstring should follow the numpy standard, see examples > in current functions and > > https://github.com/numpy/numpy/blob/master/doc/HOWTO_DOCUMENT.rst.txt#docstring-standard > ok, I'll fix these issues and come back in list ;-) Cheers, Annalisa [0]: https://svn.osgeo.org/grass/grass-addons/vector/v.strahler/ > > How to proceed if these issues are addressed: > Since it is a new function, it would be easy to integrate it into > scipy from the python files, but if you are familiar with git and > github, the integration will eventually be easier if you fork scipy > and add the function to scipy.stats and make a pull request. > A trac ticket would also be useful to keep track of the contribution > (I don't know if github will substitute for this). > At the beginning, it might be easiest to discuss this on the mailing list. > > Cheers, and thanks for any contributions, > > Josef > > > > > Best Regards, > > Annalisa Minelli > > > > > > [0]: http://en.wikipedia.org/wiki/Van_der_Waerden_test > > [1]: > http://rss.acs.unt.edu/Rdoc/library/agricolae/html/VanderWarden.html > > [2]: > http://amirror4thesun.blogspot.com/2011/05/van-der-waerden-test.html > > > > _______________________________________________ > > SciPy-Dev mailing list > > SciPy-Dev at scipy.org > > http://mail.scipy.org/mailman/listinfo/scipy-dev > > > > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From josef.pktd at gmail.com Sat Jun 4 08:07:13 2011 From: josef.pktd at gmail.com (josef.pktd at gmail.com) Date: Sat, 4 Jun 2011 08:07:13 -0400 Subject: [SciPy-Dev] Van der Waerden test in Scipy? In-Reply-To: References: Message-ID: On Sat, Jun 4, 2011 at 6:57 AM, Annalisa Minelli wrote: > Hi Josef, hi all, > thanks for answering and thanks for the questions/hints.. > > 2011/6/1 >> >> On Wed, Jun 1, 2011 at 3:56 AM, Annalisa Minelli >> wrote: >> > Dear Scipy developers, >> > I'm Annalisa Minelli, a PhD student from Perugia (Italy), and I'm using >> > Scipy library because I'm writing some code for my PhD thesis. >> > Since I needed van der waerden chisquare pvalue[0], which is implemented >> > in >> > R but not in Scipy (if I'm not wrong)[1], I implemented the test in >> > python >> > language [3] to break any R dependency for my module. >> > >> > So if you think it can be useful, maybe it could be integrated into the >> > Scipy library? >> > Could you give me any advice on how to proceed? >> >> Thanks Annalisa, >> >> I think it would be useful to have this test (and similar tests based >> on transformation to the normal distribution). >> >> I downloaded your vdw.py. I haven't looked at the details yet, but >> here are 3 main issues: >> >> your vdw is GPL which is incompatible with scipy's BSD license, for >> inclusion in scipy it would need to be a contribution licensed as BSD > > ok, I suppose I can change the license. I initially made this choice because > I need this function into a GRASS GIS module - r.broscoe [0] and the Project > uses GPL, but for sure I'd like to include the function in the Scipy library > (which is used by GRASS). > >> >> your function is not using numpy, and it seems to me that many of the >> list operations can be vectorized with numpy > > ok, I'll try this way if you think it's better; I initially thought that the > less dependencies was the best, but if you think I can considerably hack the > code in this way, I will do it. I agree that holding dependencies down is useful to work for, but in your case it doesn't make a difference. Since you are already using and requiring scipy, numpy is also required already as a scipy dependency. When it's relicensed, I can have a closer look, there might still be the loop over groups necessary, unless numpy.bincount can handle all the group operations. A background question on the test: Do you know if there is any special treatment of ties in the test? Ties sound a bit inconsistent with conversion to normal scores, but maybe it doesn't matter in this case. Josef >> >> no tests: since you have the equivalent function in R, it would be >> good to add some tests that have results from R to check that the >> function produces the same results. ( for explanation and examples: >> https://github.com/numpy/numpy/blob/master/doc/TESTS.rst.txt or look >> in scipy.stats.tests ) > > thanks for the hint; the pics I reported in my blog are from a run that > takes in input the example data.frame of R for the equivalent waerden.test > function (the data.frame is "sweetpotato") - with the only difference that > my function uses numbers for groups instead of strings (maybe I can fix > this..) but I'll do more tests, following numpy tests "standards" - thank > you >> >> additional: docstring should follow the numpy standard, see examples >> in current functions and >> >> https://github.com/numpy/numpy/blob/master/doc/HOWTO_DOCUMENT.rst.txt#docstring-standard > > ok, I'll fix these issues and come back in list ;-) > > Cheers, > Annalisa > > > [0]: https://svn.osgeo.org/grass/grass-addons/vector/v.strahler/ > > >> >> >> How to proceed if these issues are addressed: >> Since it is a new function, it would be easy to integrate it into >> scipy from the python files, but if you are familiar with git and >> github, the integration will eventually be easier if you fork scipy >> and add the function to scipy.stats and make a pull request. >> A trac ticket would also be useful to keep track of the contribution >> (I don't know if github will substitute for this). >> At the beginning, it might be easiest to discuss this on the mailing list. >> >> Cheers, and thanks for any contributions, >> >> Josef >> >> > >> > Best Regards, >> > Annalisa Minelli >> > >> > >> > [0]: http://en.wikipedia.org/wiki/Van_der_Waerden_test >> > [1]: >> > http://rss.acs.unt.edu/Rdoc/library/agricolae/html/VanderWarden.html >> > [2]: >> > http://amirror4thesun.blogspot.com/2011/05/van-der-waerden-test.html >> > >> > _______________________________________________ >> > SciPy-Dev mailing list >> > SciPy-Dev at scipy.org >> > http://mail.scipy.org/mailman/listinfo/scipy-dev >> > >> > >> _______________________________________________ >> SciPy-Dev mailing list >> SciPy-Dev at scipy.org >> http://mail.scipy.org/mailman/listinfo/scipy-dev > > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev > > From warren.weckesser at enthought.com Sat Jun 4 19:45:45 2011 From: warren.weckesser at enthought.com (Warren Weckesser) Date: Sat, 4 Jun 2011 18:45:45 -0500 Subject: [SciPy-Dev] Error trying to get thouis' pull request Message-ID: I'm trying to grab the commit from the pull request https://github.com/scipy/scipy/pull/28, but I get an error: $ git pull https://github.com/thouis/scipy.git master error: SSL certificate problem, verify that the CA cert is OK. Details: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed while accessing https://github.com/thouis/scipy.git/info/refs fatal: HTTP request failed Does anyone know if this is a github problem, a problem with thouis' github account, or my problem? Warren -------------- next part -------------- An HTML attachment was scrubbed... URL: From warren.weckesser at enthought.com Sat Jun 4 19:55:51 2011 From: warren.weckesser at enthought.com (Warren Weckesser) Date: Sat, 4 Jun 2011 18:55:51 -0500 Subject: [SciPy-Dev] Error trying to get thouis' pull request In-Reply-To: References: Message-ID: On Sat, Jun 4, 2011 at 6:45 PM, Warren Weckesser < warren.weckesser at enthought.com> wrote: > I'm trying to grab the commit from the pull request > https://github.com/scipy/scipy/pull/28, but I get an error: > > $ git pull https://github.com/thouis/scipy.git master > error: SSL certificate problem, verify that the CA cert is OK. Details: > error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify > failed while accessing https://github.com/thouis/scipy.git/info/refs > > fatal: HTTP request failed > > > Does anyone know if this is a github problem, a problem with thouis' github > account, or my problem? > I also get the error when trying to pull from another account, so it is not thouis' account that is the problem. Warren > > Warren > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From charlesr.harris at gmail.com Sat Jun 4 20:11:41 2011 From: charlesr.harris at gmail.com (Charles R Harris) Date: Sat, 4 Jun 2011 18:11:41 -0600 Subject: [SciPy-Dev] Error trying to get thouis' pull request In-Reply-To: References: Message-ID: On Sat, Jun 4, 2011 at 5:55 PM, Warren Weckesser < warren.weckesser at enthought.com> wrote: > > > On Sat, Jun 4, 2011 at 6:45 PM, Warren Weckesser < > warren.weckesser at enthought.com> wrote: > >> I'm trying to grab the commit from the pull request >> https://github.com/scipy/scipy/pull/28, but I get an error: >> >> $ git pull https://github.com/thouis/scipy.git master >> error: SSL certificate problem, verify that the CA cert is OK. Details: >> error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify >> failed while accessing https://github.com/thouis/scipy.git/info/refs >> >> fatal: HTTP request failed >> >> >> Does anyone know if this is a github problem, a problem with thouis' >> github account, or my problem? >> > > > I also get the error when trying to pull from another account, so it is not > thouis' account that is the problem. > > Works here without problems. $charris at f13 scipy.git (test28)$ git pull https://github.com/thouis/scipy.git master remote: Counting objects: 13, done. remote: Compressing objects: 100% (5/5), done. remote: Total 7 (delta 4), reused 5 (delta 2) Unpacking objects: 100% (7/7), done. >From https://github.com/thouis/scipy * branch master -> FETCH_HEAD Merge made by recursive. scipy/ndimage/measurements.py | 2 +- scipy/ndimage/tests/test_measurements.py | 12 ++++++++++++ 2 files changed, 13 insertions(+), 1 deletions(-) Are you using a different computer than usual? Maybe you need to upload another key. Chuck -------------- next part -------------- An HTML attachment was scrubbed... URL: From charlesr.harris at gmail.com Sat Jun 4 20:16:51 2011 From: charlesr.harris at gmail.com (Charles R Harris) Date: Sat, 4 Jun 2011 18:16:51 -0600 Subject: [SciPy-Dev] Error trying to get thouis' pull request In-Reply-To: References: Message-ID: On Sat, Jun 4, 2011 at 6:11 PM, Charles R Harris wrote: > > > On Sat, Jun 4, 2011 at 5:55 PM, Warren Weckesser < > warren.weckesser at enthought.com> wrote: > >> >> >> On Sat, Jun 4, 2011 at 6:45 PM, Warren Weckesser < >> warren.weckesser at enthought.com> wrote: >> >>> I'm trying to grab the commit from the pull request >>> https://github.com/scipy/scipy/pull/28, but I get an error: >>> >>> $ git pull https://github.com/thouis/scipy.git master >>> error: SSL certificate problem, verify that the CA cert is OK. Details: >>> error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate >>> verify failed while accessing >>> https://github.com/thouis/scipy.git/info/refs >>> >>> fatal: HTTP request failed >>> >>> >>> Does anyone know if this is a github problem, a problem with thouis' >>> github account, or my problem? >>> >> >> >> I also get the error when trying to pull from another account, so it is >> not thouis' account that is the problem. >> >> > Works here without problems. > > $charris at f13 scipy.git (test28)$ git pull > https://github.com/thouis/scipy.git master > remote: Counting objects: 13, done. > remote: Compressing objects: 100% (5/5), done. > remote: Total 7 (delta 4), reused 5 (delta 2) > Unpacking objects: 100% (7/7), done. > From https://github.com/thouis/scipy > * branch master -> FETCH_HEAD > Merge made by recursive. > scipy/ndimage/measurements.py | 2 +- > scipy/ndimage/tests/test_measurements.py | 12 ++++++++++++ > 2 files changed, 13 insertions(+), 1 deletions(-) > > > Are you using a different computer than usual? Maybe you need to upload > another key. > > BTW, I like to use the curl approach $charris at f13 scipy.git (test28)$ curl https://github.com/scipy/scipy/pull/28.patch | git am Chuck -------------- next part -------------- An HTML attachment was scrubbed... URL: From warren.weckesser at enthought.com Sat Jun 4 20:51:12 2011 From: warren.weckesser at enthought.com (Warren Weckesser) Date: Sat, 4 Jun 2011 19:51:12 -0500 Subject: [SciPy-Dev] Error trying to get thouis' pull request In-Reply-To: References: Message-ID: On Sat, Jun 4, 2011 at 7:11 PM, Charles R Harris wrote: > > > On Sat, Jun 4, 2011 at 5:55 PM, Warren Weckesser < > warren.weckesser at enthought.com> wrote: > >> >> >> On Sat, Jun 4, 2011 at 6:45 PM, Warren Weckesser < >> warren.weckesser at enthought.com> wrote: >> >>> I'm trying to grab the commit from the pull request >>> https://github.com/scipy/scipy/pull/28, but I get an error: >>> >>> $ git pull https://github.com/thouis/scipy.git master >>> error: SSL certificate problem, verify that the CA cert is OK. Details: >>> error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate >>> verify failed while accessing >>> https://github.com/thouis/scipy.git/info/refs >>> >>> fatal: HTTP request failed >>> >>> >>> Does anyone know if this is a github problem, a problem with thouis' >>> github account, or my problem? >>> >> >> >> I also get the error when trying to pull from another account, so it is >> not thouis' account that is the problem. >> >> > Works here without problems. > > $charris at f13 scipy.git (test28)$ git pull > https://github.com/thouis/scipy.git master > remote: Counting objects: 13, done. > remote: Compressing objects: 100% (5/5), done. > remote: Total 7 (delta 4), reused 5 (delta 2) > Unpacking objects: 100% (7/7), done. > From https://github.com/thouis/scipy > * branch master -> FETCH_HEAD > Merge made by recursive. > scipy/ndimage/measurements.py | 2 +- > scipy/ndimage/tests/test_measurements.py | 12 ++++++++++++ > 2 files changed, 13 insertions(+), 1 deletions(-) > > > Are you using a different computer than usual? Maybe you need to upload > another key. > > Thanks for checking. I'm using my usual computer, but I may have inadvertently changed something when I built a new version of openssl a few days ago. Warren Chuck > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dstahlke at gmail.com Sun Jun 5 13:03:19 2011 From: dstahlke at gmail.com (Dan Stahlke) Date: Sun, 05 Jun 2011 13:03:19 -0400 Subject: [SciPy-Dev] optimize for nonsquare or degenerate systems Message-ID: <4DEBB6D7.8060506@gmail.com> I need to solve nonlinear equations in which the number of constraints is not equal to the number of variables, and in which some of the constraints may be redundant. For example, see the code below which finds an isometry (I realize that this is not the easiest way to find an isometry, it is just an example to illustrate my point). Matlab is able to handle such systems. Is there support for this in scipy? So far I have tried newton_krylov and leastsq with no success. newton_krylov requires constraints=variables and leastsq requires constraints>variables. If I pad my constraints with zeros to make the number of constraints match the number of variables, then leastsq seems to work. Is there a reason that this is not done automatically? I patched the KrylovJacobian function nonlin.py to give the option of using pinv for solving the Jacobian equation, and this seems to work for me. I created a feature request ticket for this (http://projects.scipy.org/scipy/ticket/1454) but was asked to turn to the mailing list first for advice. Another question somewhat related: is newton_krylov supposed to handle functions on complex numbers? The documentation doesn't say either way as far as I can tell. The solver seems to attempt such equations but doesn't converge upon the answer. Wrapping the function such that two real variables map to one complex variable works though. Thanks, Dan 
# Example of a non-square optimization problem: find an isometry

import numpy as np
import scipy.optimize

(M, N) = (10, 4)

def F(x):
     arr = np.array(x).reshape(M, N)
     closure = np.dot(arr.T, arr)
     err = closure - np.eye(N)
     return err

start = np.random.normal(0, 1, N*M)

# Gives error:
# ValueError: expected square matrix, but got shape=(16, 40)
result = scipy.optimize.newton_krylov(F, start, verbose=True)

# Gives error:
# TypeError: Improper input: N=40 must not exceed M=4
result = scipy.optimize.leastsq(F, start)
From ole.moller.nielsen at gmail.com Fri Jun 10 02:26:01 2011 From: ole.moller.nielsen at gmail.com (Ole Nielsen) Date: Fri, 10 Jun 2011 13:26:01 +0700 Subject: [SciPy-Dev] Bivariate interpolation and NaN In-Reply-To: References: Message-ID: Dear Scipy developers I am working on a project where we need to interpolate from gridded data to individual points. We want it to be fast, bilinear (i.e. smooting is not important) and be able to deal with NaN in a sensible way. I looked at a few and settled for RectBivariateSpline which is part of scipy.interpolate. It works well but, we have encountered two problems: 1. If there is a single NaN in the grid, all interpolated points become NaN even if the surrounding pixels are valid floating point numbers. I would have expected NaNs only for points whose immediate neighbours contain NaN. 2. We have noticed small 'overshoots', i.e. interpolated values may be outside the range of the gridded data. Can anyone tell me if this is expected? I am interested in thoughts on whether it is possible to achieve this. If there is a need to reproduce my observations, I can provide that. Cheers and thanks Ole Nielsen -------------- next part -------------- An HTML attachment was scrubbed... URL: From charlesr.harris at gmail.com Fri Jun 10 03:01:24 2011 From: charlesr.harris at gmail.com (Charles R Harris) Date: Fri, 10 Jun 2011 01:01:24 -0600 Subject: [SciPy-Dev] Bivariate interpolation and NaN In-Reply-To: References: Message-ID: On Fri, Jun 10, 2011 at 12:26 AM, Ole Nielsen wrote: > Dear Scipy developers > > I am working on a project where we need to interpolate from gridded data to > individual points. > We want it to be fast, bilinear (i.e. smooting is not important) and be > able to deal with NaN in a sensible way. > > I looked at a few and settled for RectBivariateSpline which is part of > scipy.interpolate. > It works well but, we have encountered two problems: > > 1. If there is a single NaN in the grid, all interpolated points become > NaN even if the surrounding pixels are valid floating point numbers. I would > have expected NaNs only for points whose immediate neighbours contain NaN. > 2. We have noticed small 'overshoots', i.e. interpolated values may be > outside the range of the gridded data. Can anyone tell me if this is > expected? > > I think both are expected. Splines are a global fit and nans will cause global trouble. Likewise, splines can exhibit ringing. You can use a smoothing spline to get around that, but it won't interpolate the data points exactly. It sounds to me like you want something local, for instance bi-cubic interpolation or bilinear (the algorithm name). There are some tools for this sort of thing in scipy.ndimage, and tools like gdal or imagemagick might also do what you want depending on the specifics of the problem. Chuck -------------- next part -------------- An HTML attachment was scrubbed... URL: From gael.varoquaux at normalesup.org Fri Jun 10 03:13:35 2011 From: gael.varoquaux at normalesup.org (Gael Varoquaux) Date: Fri, 10 Jun 2011 09:13:35 +0200 Subject: [SciPy-Dev] Bivariate interpolation and NaN In-Reply-To: References: Message-ID: <20110610071335.GC11586@phare.normalesup.org> On Fri, Jun 10, 2011 at 01:01:24AM -0600, Charles R Harris wrote: > I think both are expected. Splines are a global fit and nans will cause > global trouble. Likewise, splines can exhibit ringing. You can use a > smoothing spline to get around that, but it won't interpolate the data > points exactly. It sounds to me like you want something local, for > instance bi-cubic interpolation or bilinear (the algorithm name). There > are some tools for this sort of thing in scipy.ndimage, and tools like > gdal or imagemagick might also do what you want depending on the specifics > of the problem. WENO interpolation (weighted essentially non-oscillatory): http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.148.8505&rep=rep1&type=pdf http://www.scholarpedia.org/article/WENO_methods Adrian Townsend presented such interpolation scheme at scipy a couple of years ago: http://www.archive.org/details/scipy09_day1_14-Adrian_Townsend He slides might actually be amongst the most readable material around: http://conference.scipy.org/static/wiki/townsend_weno.pdf anhd he has Python code: http://memmett.github.com/PyWENO/ Gael From charlesr.harris at gmail.com Fri Jun 10 03:14:59 2011 From: charlesr.harris at gmail.com (Charles R Harris) Date: Fri, 10 Jun 2011 01:14:59 -0600 Subject: [SciPy-Dev] Bivariate interpolation and NaN In-Reply-To: References: Message-ID: On Fri, Jun 10, 2011 at 1:01 AM, Charles R Harris wrote: > > > On Fri, Jun 10, 2011 at 12:26 AM, Ole Nielsen < > ole.moller.nielsen at gmail.com> wrote: > >> Dear Scipy developers >> >> I am working on a project where we need to interpolate from gridded data >> to individual points. >> We want it to be fast, bilinear (i.e. smooting is not important) and be >> able to deal with NaN in a sensible way. >> >> I looked at a few and settled for RectBivariateSpline which is part of >> scipy.interpolate. >> It works well but, we have encountered two problems: >> >> 1. If there is a single NaN in the grid, all interpolated points >> become NaN even if the surrounding pixels are valid floating point numbers. >> I would have expected NaNs only for points whose immediate neighbours >> contain NaN. >> 2. We have noticed small 'overshoots', i.e. interpolated values may be >> outside the range of the gridded data. Can anyone tell me if this is >> expected? >> >> I think both are expected. Splines are a global fit and nans will cause > global trouble. Likewise, splines can exhibit ringing. You can use a > smoothing spline to get around that, but it won't interpolate the data > points exactly. It sounds to me like you want something local, for instance > bi-cubic interpolation or bilinear (the algorithm name). There are some > tools for this sort of thing in scipy.ndimage, and tools like gdal or > imagemagick might also do what you want depending on the specifics of the > problem. > > I should say that I interpreted gridded as evenly spaced points on a square grid. If that is not the case the LinearNDInterpolator might be your best bet. Chuck -------------- next part -------------- An HTML attachment was scrubbed... URL: From ole.moller.nielsen at gmail.com Fri Jun 10 21:04:14 2011 From: ole.moller.nielsen at gmail.com (Ole Nielsen) Date: Sat, 11 Jun 2011 08:04:14 +0700 Subject: [SciPy-Dev] SciPy-Dev Digest, Vol 92, Issue 8 In-Reply-To: References: Message-ID: Thank you everyone for your suggestions. I didn't realise that RectBivariateSpline is a global method, but now it makes sense what I see in terms of ringing and handling of NaN. I am really interested in the local methods suggested by Chuck (bi-cubic interpolation or bilinear. However, looking in scipy.ndimage I couldn't find this kind of thing. Looking at GDAL this seems to be available only for resampling. I couldn't find LinearNDInterpolator either. Can anyone tell me where to find these packages please. Just to recab, what we need is a local bilinear interpolation from regular grid data to a collection of points which handles NaN in a sensible way. Many thanks Ole On Sat, Jun 11, 2011 at 12:00 AM, wrote: > Send SciPy-Dev mailing list submissions to > scipy-dev at scipy.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://mail.scipy.org/mailman/listinfo/scipy-dev > or, via email, send a message with subject or body 'help' to > scipy-dev-request at scipy.org > > You can reach the person managing the list at > scipy-dev-owner at scipy.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of SciPy-Dev digest..." > > > Today's Topics: > > 1. Bivariate interpolation and NaN (Ole Nielsen) > 2. Re: Bivariate interpolation and NaN (Charles R Harris) > 3. Re: Bivariate interpolation and NaN (Gael Varoquaux) > 4. Re: Bivariate interpolation and NaN (Charles R Harris) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 10 Jun 2011 13:26:01 +0700 > From: Ole Nielsen > Subject: [SciPy-Dev] Bivariate interpolation and NaN > To: scipy-dev at scipy.org > Message-ID: > Content-Type: text/plain; charset="iso-8859-1" > > Dear Scipy developers > > I am working on a project where we need to interpolate from gridded data to > individual points. > We want it to be fast, bilinear (i.e. smooting is not important) and be > able > to deal with NaN in a sensible way. > > I looked at a few and settled for RectBivariateSpline which is part of > scipy.interpolate. > It works well but, we have encountered two problems: > > 1. If there is a single NaN in the grid, all interpolated points become > NaN even if the surrounding pixels are valid floating point numbers. I > would > have expected NaNs only for points whose immediate neighbours contain > NaN. > 2. We have noticed small 'overshoots', i.e. interpolated values may be > outside the range of the gridded data. Can anyone tell me if this is > expected? > > I am interested in thoughts on whether it is possible to achieve this. If > there is a need to reproduce my observations, I can provide that. > > Cheers and thanks > Ole Nielsen > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://mail.scipy.org/pipermail/scipy-dev/attachments/20110610/0c475125/attachment-0001.html > > ------------------------------ > > Message: 2 > Date: Fri, 10 Jun 2011 01:01:24 -0600 > From: Charles R Harris > Subject: Re: [SciPy-Dev] Bivariate interpolation and NaN > To: SciPy Developers List > Message-ID: > Content-Type: text/plain; charset="iso-8859-1" > > On Fri, Jun 10, 2011 at 12:26 AM, Ole Nielsen > wrote: > > > Dear Scipy developers > > > > I am working on a project where we need to interpolate from gridded data > to > > individual points. > > We want it to be fast, bilinear (i.e. smooting is not important) and be > > able to deal with NaN in a sensible way. > > > > I looked at a few and settled for RectBivariateSpline which is part of > > scipy.interpolate. > > It works well but, we have encountered two problems: > > > > 1. If there is a single NaN in the grid, all interpolated points > become > > NaN even if the surrounding pixels are valid floating point numbers. I > would > > have expected NaNs only for points whose immediate neighbours contain > NaN. > > 2. We have noticed small 'overshoots', i.e. interpolated values may be > > outside the range of the gridded data. Can anyone tell me if this is > > expected? > > > > I think both are expected. Splines are a global fit and nans will cause > global trouble. Likewise, splines can exhibit ringing. You can use a > smoothing spline to get around that, but it won't interpolate the data > points exactly. It sounds to me like you want something local, for instance > bi-cubic interpolation or bilinear (the algorithm name). There are some > tools for this sort of thing in scipy.ndimage, and tools like gdal or > imagemagick might also do what you want depending on the specifics of the > problem. > > Chuck > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://mail.scipy.org/pipermail/scipy-dev/attachments/20110610/3be014a5/attachment-0001.html > > ------------------------------ > > Message: 3 > Date: Fri, 10 Jun 2011 09:13:35 +0200 > From: Gael Varoquaux > Subject: Re: [SciPy-Dev] Bivariate interpolation and NaN > To: SciPy Developers List > Message-ID: <20110610071335.GC11586 at phare.normalesup.org> > Content-Type: text/plain; charset=us-ascii > > On Fri, Jun 10, 2011 at 01:01:24AM -0600, Charles R Harris wrote: > > I think both are expected. Splines are a global fit and nans will > cause > > global trouble. Likewise, splines can exhibit ringing. You can use a > > smoothing spline to get around that, but it won't interpolate the data > > points exactly. It sounds to me like you want something local, for > > instance bi-cubic interpolation or bilinear (the algorithm name). > There > > are some tools for this sort of thing in scipy.ndimage, and tools like > > gdal or imagemagick might also do what you want depending on the > specifics > > of the problem. > > WENO interpolation (weighted essentially non-oscillatory): > > http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.148.8505&rep=rep1&type=pdf > > http://www.scholarpedia.org/article/WENO_methods > > Adrian Townsend presented such interpolation scheme at scipy a couple of > years ago: > http://www.archive.org/details/scipy09_day1_14-Adrian_Townsend > He slides might actually be amongst the most readable material around: > http://conference.scipy.org/static/wiki/townsend_weno.pdf > anhd he has Python code: > http://memmett.github.com/PyWENO/ > > Gael > > > ------------------------------ > > Message: 4 > Date: Fri, 10 Jun 2011 01:14:59 -0600 > From: Charles R Harris > Subject: Re: [SciPy-Dev] Bivariate interpolation and NaN > To: SciPy Developers List > Message-ID: > Content-Type: text/plain; charset="iso-8859-1" > > On Fri, Jun 10, 2011 at 1:01 AM, Charles R Harris < > charlesr.harris at gmail.com > > wrote: > > > > > > > On Fri, Jun 10, 2011 at 12:26 AM, Ole Nielsen < > > ole.moller.nielsen at gmail.com> wrote: > > > >> Dear Scipy developers > >> > >> I am working on a project where we need to interpolate from gridded data > >> to individual points. > >> We want it to be fast, bilinear (i.e. smooting is not important) and be > >> able to deal with NaN in a sensible way. > >> > >> I looked at a few and settled for RectBivariateSpline which is part of > >> scipy.interpolate. > >> It works well but, we have encountered two problems: > >> > >> 1. If there is a single NaN in the grid, all interpolated points > >> become NaN even if the surrounding pixels are valid floating point > numbers. > >> I would have expected NaNs only for points whose immediate neighbours > >> contain NaN. > >> 2. We have noticed small 'overshoots', i.e. interpolated values may > be > >> outside the range of the gridded data. Can anyone tell me if this is > >> expected? > >> > >> I think both are expected. Splines are a global fit and nans will cause > > global trouble. Likewise, splines can exhibit ringing. You can use a > > smoothing spline to get around that, but it won't interpolate the data > > points exactly. It sounds to me like you want something local, for > instance > > bi-cubic interpolation or bilinear (the algorithm name). There are some > > tools for this sort of thing in scipy.ndimage, and tools like gdal or > > imagemagick might also do what you want depending on the specifics of the > > problem. > > > > > I should say that I interpreted gridded as evenly spaced points on a square > grid. If that is not the case the LinearNDInterpolator might be your best > bet. > > Chuck > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://mail.scipy.org/pipermail/scipy-dev/attachments/20110610/be546dcd/attachment-0001.html > > ------------------------------ > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev > > > End of SciPy-Dev Digest, Vol 92, Issue 8 > **************************************** > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pav at iki.fi Fri Jun 10 21:48:51 2011 From: pav at iki.fi (Pauli Virtanen) Date: Sat, 11 Jun 2011 01:48:51 +0000 (UTC) Subject: [SciPy-Dev] SciPy-Dev Digest, Vol 92, Issue 8 References: Message-ID: On Sat, 11 Jun 2011 08:04:14 +0700, Ole Nielsen wrote: > I am really interested in the local methods suggested by Chuck (bi-cubic > interpolation or bilinear. However, looking in scipy.ndimage I couldn't > find this kind of thing. Looking at GDAL this seems to be available only > for resampling. > I couldn't find LinearNDInterpolator either. Can anyone tell me where to > find these packages please. http://docs.scipy.org/doc/scipy/reference/ndimage.html http://docs.scipy.org/doc/scipy/reference/generated/scipy.ndimage.interpolation.map_coordinates.html http://docs.scipy.org/doc/scipy/reference/interpolate.html From charlesr.harris at gmail.com Fri Jun 10 23:36:22 2011 From: charlesr.harris at gmail.com (Charles R Harris) Date: Fri, 10 Jun 2011 21:36:22 -0600 Subject: [SciPy-Dev] SciPy-Dev Digest, Vol 92, Issue 8 In-Reply-To: References: Message-ID: On Fri, Jun 10, 2011 at 7:04 PM, Ole Nielsen wrote: > Thank you everyone for your suggestions. I didn't realise that > RectBivariateSpline is a global method, but now it makes sense what I see in > terms of ringing and handling of NaN. > > I am really interested in the local methods suggested by Chuck (bi-cubic > interpolation or bilinear. However, looking in scipy.ndimage I couldn't find > this kind of thing. Looking at GDAL this seems to be available only for > resampling. > I couldn't find LinearNDInterpolator either. Can anyone tell me where to > find these packages please. > > Just to recab, what we need is a local bilinear interpolation from regular > grid data to a collection of points which handles NaN in a sensible way. > Well, I looked a bit more closely at the ndimage interpolation routines and they are all spline based, so that leaves you with splines of order 1 as the only option there, which I think is equivalent to bilinear. The LinearNDInterpolator uses triangulation and will give a linear interpolation, but such depends on the triangulation. It's a shame that the offerings are so sparse, matplotlib's imshow has a lot more options. Scikits.image doesn't seem to concern itself with interpolation (yet), so I don't know where else you can look. Can you be a bit more specific about the grid and how you want to resample it? That is, do you need to sample it a random points, or just resample it on a different grid, etc. Chuck -------------- next part -------------- An HTML attachment was scrubbed... URL: From ole.moller.nielsen at gmail.com Sun Jun 12 22:32:31 2011 From: ole.moller.nielsen at gmail.com (Ole Nielsen) Date: Mon, 13 Jun 2011 09:32:31 +0700 Subject: [SciPy-Dev] SciPy-Dev Digest, Vol 92, Issue 9 In-Reply-To: References: Message-ID: Hi again Chuck and thanks for helping me. >Can you be a bit more specific about the >grid and how you want to resample it? That is, do you need to sample it a >random points, or just resample it on a different grid, etc. Our task is not about resampling but (the simpler) task of interpolating from a regular grid (e.g. earthquake ground shaking) to a collection of arbitrary points (e.g. location of critical infrastructure) - see e.g the illustration at http://en.wikipedia.org/wiki/Bilinear_interpolation so we need 1. A simple and robust way of interpolating and from a regular grid to points without overshoot and ringing. Smoothing is not important. 2. Ability to hand NaN sensibly. E.g. if the is one grid point which is NaN only interpolation points near it should be NaN. It is interesting how implementations of the hard problems (e.g. high order splines on variable resolution) are abundant, whereas something as basic as this is harder to find :-) I am quite keen to have a go at implementing a simple bilinear interpolator as a Python C-extension using numpy arrays if there is interest in it. Meanwhile, if you could tell me where the LinearNDInterpolator package can be found? Cheers and thanks Ole On Sat, Jun 11, 2011 at 10:36 AM, wrote: > Send SciPy-Dev mailing list submissions to > scipy-dev at scipy.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://mail.scipy.org/mailman/listinfo/scipy-dev > or, via email, send a message with subject or body 'help' to > scipy-dev-request at scipy.org > > You can reach the person managing the list at > scipy-dev-owner at scipy.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of SciPy-Dev digest..." > > > Today's Topics: > > 1. Re: SciPy-Dev Digest, Vol 92, Issue 8 (Ole Nielsen) > 2. Re: SciPy-Dev Digest, Vol 92, Issue 8 (Pauli Virtanen) > 3. Re: SciPy-Dev Digest, Vol 92, Issue 8 (Charles R Harris) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sat, 11 Jun 2011 08:04:14 +0700 > From: Ole Nielsen > Subject: Re: [SciPy-Dev] SciPy-Dev Digest, Vol 92, Issue 8 > To: scipy-dev at scipy.org > Message-ID: > Content-Type: text/plain; charset="iso-8859-1" > > Thank you everyone for your suggestions. I didn't realise that > RectBivariateSpline is a global method, but now it makes sense what I see > in > terms of ringing and handling of NaN. > > I am really interested in the local methods suggested by Chuck (bi-cubic > interpolation or bilinear. However, looking in scipy.ndimage I couldn't > find > this kind of thing. Looking at GDAL this seems to be available only for > resampling. > I couldn't find LinearNDInterpolator either. Can anyone tell me where to > find these packages please. > > Just to recab, what we need is a local bilinear interpolation from regular > grid data to a collection of points which handles NaN in a sensible way. > > Many thanks > Ole > > > On Sat, Jun 11, 2011 at 12:00 AM, wrote: > > > Send SciPy-Dev mailing list submissions to > > scipy-dev at scipy.org > > > > To subscribe or unsubscribe via the World Wide Web, visit > > http://mail.scipy.org/mailman/listinfo/scipy-dev > > or, via email, send a message with subject or body 'help' to > > scipy-dev-request at scipy.org > > > > You can reach the person managing the list at > > scipy-dev-owner at scipy.org > > > > When replying, please edit your Subject line so it is more specific > > than "Re: Contents of SciPy-Dev digest..." > > > > > > Today's Topics: > > > > 1. Bivariate interpolation and NaN (Ole Nielsen) > > 2. Re: Bivariate interpolation and NaN (Charles R Harris) > > 3. Re: Bivariate interpolation and NaN (Gael Varoquaux) > > 4. Re: Bivariate interpolation and NaN (Charles R Harris) > > > > > > ---------------------------------------------------------------------- > > > > Message: 1 > > Date: Fri, 10 Jun 2011 13:26:01 +0700 > > From: Ole Nielsen > > Subject: [SciPy-Dev] Bivariate interpolation and NaN > > To: scipy-dev at scipy.org > > Message-ID: > > Content-Type: text/plain; charset="iso-8859-1" > > > > Dear Scipy developers > > > > I am working on a project where we need to interpolate from gridded data > to > > individual points. > > We want it to be fast, bilinear (i.e. smooting is not important) and be > > able > > to deal with NaN in a sensible way. > > > > I looked at a few and settled for RectBivariateSpline which is part of > > scipy.interpolate. > > It works well but, we have encountered two problems: > > > > 1. If there is a single NaN in the grid, all interpolated points become > > NaN even if the surrounding pixels are valid floating point numbers. I > > would > > have expected NaNs only for points whose immediate neighbours contain > > NaN. > > 2. We have noticed small 'overshoots', i.e. interpolated values may be > > outside the range of the gridded data. Can anyone tell me if this is > > expected? > > > > I am interested in thoughts on whether it is possible to achieve this. If > > there is a need to reproduce my observations, I can provide that. > > > > Cheers and thanks > > Ole Nielsen > > -------------- next part -------------- > > An HTML attachment was scrubbed... > > URL: > > > http://mail.scipy.org/pipermail/scipy-dev/attachments/20110610/0c475125/attachment-0001.html > > > > ------------------------------ > > > > Message: 2 > > Date: Fri, 10 Jun 2011 01:01:24 -0600 > > From: Charles R Harris > > Subject: Re: [SciPy-Dev] Bivariate interpolation and NaN > > To: SciPy Developers List > > Message-ID: > > Content-Type: text/plain; charset="iso-8859-1" > > > > On Fri, Jun 10, 2011 at 12:26 AM, Ole Nielsen > > wrote: > > > > > Dear Scipy developers > > > > > > I am working on a project where we need to interpolate from gridded > data > > to > > > individual points. > > > We want it to be fast, bilinear (i.e. smooting is not important) and be > > > able to deal with NaN in a sensible way. > > > > > > I looked at a few and settled for RectBivariateSpline which is part of > > > scipy.interpolate. > > > It works well but, we have encountered two problems: > > > > > > 1. If there is a single NaN in the grid, all interpolated points > > become > > > NaN even if the surrounding pixels are valid floating point numbers. > I > > would > > > have expected NaNs only for points whose immediate neighbours > contain > > NaN. > > > 2. We have noticed small 'overshoots', i.e. interpolated values may > be > > > outside the range of the gridded data. Can anyone tell me if this is > > > expected? > > > > > > I think both are expected. Splines are a global fit and nans will cause > > global trouble. Likewise, splines can exhibit ringing. You can use a > > smoothing spline to get around that, but it won't interpolate the data > > points exactly. It sounds to me like you want something local, for > instance > > bi-cubic interpolation or bilinear (the algorithm name). There are some > > tools for this sort of thing in scipy.ndimage, and tools like gdal or > > imagemagick might also do what you want depending on the specifics of the > > problem. > > > > Chuck > > -------------- next part -------------- > > An HTML attachment was scrubbed... > > URL: > > > http://mail.scipy.org/pipermail/scipy-dev/attachments/20110610/3be014a5/attachment-0001.html > > > > ------------------------------ > > > > Message: 3 > > Date: Fri, 10 Jun 2011 09:13:35 +0200 > > From: Gael Varoquaux > > Subject: Re: [SciPy-Dev] Bivariate interpolation and NaN > > To: SciPy Developers List > > Message-ID: <20110610071335.GC11586 at phare.normalesup.org> > > Content-Type: text/plain; charset=us-ascii > > > > On Fri, Jun 10, 2011 at 01:01:24AM -0600, Charles R Harris wrote: > > > I think both are expected. Splines are a global fit and nans will > > cause > > > global trouble. Likewise, splines can exhibit ringing. You can use a > > > smoothing spline to get around that, but it won't interpolate the > data > > > points exactly. It sounds to me like you want something local, for > > > instance bi-cubic interpolation or bilinear (the algorithm name). > > There > > > are some tools for this sort of thing in scipy.ndimage, and tools > like > > > gdal or imagemagick might also do what you want depending on the > > specifics > > > of the problem. > > > > WENO interpolation (weighted essentially non-oscillatory): > > > > > http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.148.8505&rep=rep1&type=pdf > > > > http://www.scholarpedia.org/article/WENO_methods > > > > Adrian Townsend presented such interpolation scheme at scipy a couple of > > years ago: > > http://www.archive.org/details/scipy09_day1_14-Adrian_Townsend > > He slides might actually be amongst the most readable material around: > > http://conference.scipy.org/static/wiki/townsend_weno.pdf > > anhd he has Python code: > > http://memmett.github.com/PyWENO/ > > > > Gael > > > > > > ------------------------------ > > > > Message: 4 > > Date: Fri, 10 Jun 2011 01:14:59 -0600 > > From: Charles R Harris > > Subject: Re: [SciPy-Dev] Bivariate interpolation and NaN > > To: SciPy Developers List > > Message-ID: > > Content-Type: text/plain; charset="iso-8859-1" > > > > On Fri, Jun 10, 2011 at 1:01 AM, Charles R Harris < > > charlesr.harris at gmail.com > > > wrote: > > > > > > > > > > > On Fri, Jun 10, 2011 at 12:26 AM, Ole Nielsen < > > > ole.moller.nielsen at gmail.com> wrote: > > > > > >> Dear Scipy developers > > >> > > >> I am working on a project where we need to interpolate from gridded > data > > >> to individual points. > > >> We want it to be fast, bilinear (i.e. smooting is not important) and > be > > >> able to deal with NaN in a sensible way. > > >> > > >> I looked at a few and settled for RectBivariateSpline which is part of > > >> scipy.interpolate. > > >> It works well but, we have encountered two problems: > > >> > > >> 1. If there is a single NaN in the grid, all interpolated points > > >> become NaN even if the surrounding pixels are valid floating point > > numbers. > > >> I would have expected NaNs only for points whose immediate > neighbours > > >> contain NaN. > > >> 2. We have noticed small 'overshoots', i.e. interpolated values may > > be > > >> outside the range of the gridded data. Can anyone tell me if this > is > > >> expected? > > >> > > >> I think both are expected. Splines are a global fit and nans will > cause > > > global trouble. Likewise, splines can exhibit ringing. You can use a > > > smoothing spline to get around that, but it won't interpolate the data > > > points exactly. It sounds to me like you want something local, for > > instance > > > bi-cubic interpolation or bilinear (the algorithm name). There are some > > > tools for this sort of thing in scipy.ndimage, and tools like gdal or > > > imagemagick might also do what you want depending on the specifics of > the > > > problem. > > > > > > > > I should say that I interpreted gridded as evenly spaced points on a > square > > grid. If that is not the case the LinearNDInterpolator might be your best > > bet. > > > > Chuck > > -------------- next part -------------- > > An HTML attachment was scrubbed... > > URL: > > > http://mail.scipy.org/pipermail/scipy-dev/attachments/20110610/be546dcd/attachment-0001.html > > > > ------------------------------ > > > > _______________________________________________ > > SciPy-Dev mailing list > > SciPy-Dev at scipy.org > > http://mail.scipy.org/mailman/listinfo/scipy-dev > > > > > > End of SciPy-Dev Digest, Vol 92, Issue 8 > > **************************************** > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://mail.scipy.org/pipermail/scipy-dev/attachments/20110611/79acf212/attachment-0001.html > > ------------------------------ > > Message: 2 > Date: Sat, 11 Jun 2011 01:48:51 +0000 (UTC) > From: Pauli Virtanen > Subject: Re: [SciPy-Dev] SciPy-Dev Digest, Vol 92, Issue 8 > To: scipy-dev at scipy.org > Message-ID: > Content-Type: text/plain; charset=UTF-8 > > On Sat, 11 Jun 2011 08:04:14 +0700, Ole Nielsen wrote: > > > I am really interested in the local methods suggested by Chuck (bi-cubic > > interpolation or bilinear. However, looking in scipy.ndimage I couldn't > > find this kind of thing. Looking at GDAL this seems to be available only > > for resampling. > > I couldn't find LinearNDInterpolator either. Can anyone tell me where to > > find these packages please. > > http://docs.scipy.org/doc/scipy/reference/ndimage.html > > > http://docs.scipy.org/doc/scipy/reference/generated/scipy.ndimage.interpolation.map_coordinates.html > > http://docs.scipy.org/doc/scipy/reference/interpolate.html > > > > ------------------------------ > > Message: 3 > Date: Fri, 10 Jun 2011 21:36:22 -0600 > From: Charles R Harris > Subject: Re: [SciPy-Dev] SciPy-Dev Digest, Vol 92, Issue 8 > To: SciPy Developers List > Message-ID: > Content-Type: text/plain; charset="iso-8859-1" > > On Fri, Jun 10, 2011 at 7:04 PM, Ole Nielsen > wrote: > > > Thank you everyone for your suggestions. I didn't realise that > > RectBivariateSpline is a global method, but now it makes sense what I see > in > > terms of ringing and handling of NaN. > > > > I am really interested in the local methods suggested by Chuck (bi-cubic > > interpolation or bilinear. However, looking in scipy.ndimage I couldn't > find > > this kind of thing. Looking at GDAL this seems to be available only for > > resampling. > > I couldn't find LinearNDInterpolator either. Can anyone tell me where to > > find these packages please. > > > > Just to recab, what we need is a local bilinear interpolation from > regular > > grid data to a collection of points which handles NaN in a sensible way. > > > > Well, I looked a bit more closely at the ndimage interpolation routines and > they are all spline based, so that leaves you with splines of order 1 as > the > only option there, which I think is equivalent to bilinear. The > LinearNDInterpolator uses triangulation and will give a linear > interpolation, but such depends on the triangulation. It's a shame that the > offerings are so sparse, matplotlib's imshow has a lot more options. > Scikits.image doesn't seem to concern itself with interpolation (yet), so I > don't know where else you can look. Can you be a bit more specific about > the > grid and how you want to resample it? That is, do you need to sample it a > random points, or just resample it on a different grid, etc. > > > > Chuck > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://mail.scipy.org/pipermail/scipy-dev/attachments/20110610/9a4ddd0f/attachment.html > > ------------------------------ > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev > > > End of SciPy-Dev Digest, Vol 92, Issue 9 > **************************************** > -------------- next part -------------- An HTML attachment was scrubbed... URL: From efiring at hawaii.edu Mon Jun 13 03:50:38 2011 From: efiring at hawaii.edu (Eric Firing) Date: Sun, 12 Jun 2011 21:50:38 -1000 Subject: [SciPy-Dev] bilinear interpolation In-Reply-To: References: Message-ID: <4DF5C14E.7010905@hawaii.edu> On 06/12/2011 04:32 PM, Ole Nielsen wrote: > Hi again Chuck and thanks for helping me. > > >Can you be a bit more specific about the > >grid and how you want to resample it? That is, do you need to sample it a > >random points, or just resample it on a different grid, etc. > > Our task is not about resampling but (the simpler) task of interpolating > from a regular grid (e.g. earthquake ground shaking) to a collection of > arbitrary points (e.g. location of critical infrastructure) - see e.g > the illustration at http://en.wikipedia.org/wiki/Bilinear_interpolation > > so we need > > 1. A simple and robust way of interpolating and from a regular grid > to points without overshoot and ringing. Smoothing is not important. > 2. Ability to hand NaN sensibly. E.g. if the is one grid point which > is NaN only interpolation points near it should be NaN. > > It is interesting how implementations of the hard problems (e.g. high > order splines on variable resolution) are abundant, whereas something as > basic as this is harder to find :-) There is an implementation of bilinear interpolation in the matplotlib basemap toolkit, in the module __init__.py. I don't think it depends on anything else in the module. It optionally uses masked arrays to handle missing values; maybe it would work with nans also, but if not, then converting to a masked array and back to an ndarray with nans is fast and easy. See https://github.com/matplotlib/basemap for the whole package, or https://github.com/matplotlib/basemap/blob/master/lib/mpl_toolkits/basemap/__init__.py for interp(). The docstring says the x and y output arrays have to be 2-D, but there is actually no such restriction; arbitrary x and y arrays will suffice (though they do have to be numpy arrays): from mpl_toolkits.basemap import interp xin = np.arange(5) yin = np.arange(10) zin = yin[:, np.newaxis] * xin[np.newaxis, :] xout = [2.2, 3.3] yout = [4.4, 5.5] xout = np.array(xout) yout = np.array(yout) zout = interp(zin, xin, yin, xout, yout) print zout Eric > > I am quite keen to have a go at implementing a simple bilinear > interpolator as a Python C-extension using numpy arrays if there is > interest in it. > Meanwhile, if you could tell me where the LinearNDInterpolator package > can be found? > > Cheers and thanks > Ole From xavier.gnata at gmail.com Mon Jun 13 11:01:47 2011 From: xavier.gnata at gmail.com (Xavier Gnata) Date: Mon, 13 Jun 2011 17:01:47 +0200 Subject: [SciPy-Dev] Advertise on python3 support? Message-ID: <4DF6265B.6060507@gmail.com> Hi, Looking at http://www.scipy.org/ it is not obvious to find info on the numpy/scipy python3 support (welldon't even find this statement at all on scipy.org.). Is there a plan to advertise a bit more on that support? I think it is needed because it would clearly show to other packages maintainers that the trend to python3 has started. Xavier From ralf.gommers at googlemail.com Mon Jun 13 12:07:38 2011 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Mon, 13 Jun 2011 18:07:38 +0200 Subject: [SciPy-Dev] defining public API (was: prepending underscores ...) Message-ID: On Sat, Jun 4, 2011 at 1:38 AM, Ralf Gommers wrote: > > > On Fri, Jun 3, 2011 at 10:05 PM, Robert Kern wrote: > >> On Fri, Jun 3, 2011 at 14:57, Ralf Gommers >> wrote: >> > Hi, >> > >> > A while ago we discussed making a clear distinction between public and >> > private modules by using underscores consistently, see >> > http://thread.gmane.org/gmane.comp.python.scientific.devel/14936. >> > >> > I've done this for a few modules now, see >> > https://github.com/rgommers/scipy/tree/underscores. Most files could >> simply >> > be underscored, some other would conflict with extension modules so I >> also >> > had to append _py to the name. Also I added a file doc/source/api.rst >> that >> > states which modules are public (up for discussion of course). >> > >> > With google code search I checked how common it is to import from >> modules >> > that are supposed to be private, for example "from >> scipy.optimize.optimize >> > import fmin". It's not very common but does happen, so deprecation >> warnings >> > should be put in. >> > >> > Before going further I'd like to check that this looks okay to people. >> What >> > do you think? >> >> I'm still -1 on it. I think it's unnecessary and potentially disruptive. >> >> It will indeed be disruptive for those users who imported from private > modules, they will get deprecation warnings and would need to update their > code. Those same users can run into trouble anyway though unless we treat > everything that is now ambiguous as public. > > Unnecessary, I disagree. Even among developers it is not clear what the > public API is. This is the clearest way to solve it. > > An alternative would be to just document very clearly what the API is. Just > saying "The public API of a package is determined by any number of > conventions which may or may not be documented explicitly." doesn't help > much. > > Okay, I've taken one step back here and added documentation for the API. I've sent a pull request for that: https://github.com/scipy/scipy/pull/35 Any comments welcome. Cheers, Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From pav at iki.fi Mon Jun 13 12:57:15 2011 From: pav at iki.fi (Pauli Virtanen) Date: Mon, 13 Jun 2011 16:57:15 +0000 (UTC) Subject: [SciPy-Dev] SciPy-Dev Digest, Vol 92, Issue 9 References: Message-ID: On Mon, 13 Jun 2011 09:32:31 +0700, Ole Nielsen wrote: [clip] > Meanwhile, if you could tell me where the LinearNDInterpolator package can be found? See the link I posted earlier: http://docs.scipy.org/doc/scipy/reference/interpolate.html It's not a separate package, but a part of Scipy 0.9. Usage for your case: -------------------- # some data on a grid, containing nans x = np.linspace(0, 1, 20) y = np.linspace(0, 1, 30) z = np.cos(x[:,None]) + np.sin(y[None,:]) z[np.random.rand(*z.shape) > 0.9] = np.nan # flatten grid data to (x, y, z) point list xx = (x[:,None] + 0*y[None,:]).ravel() yy = (0*x[:,None] + y[None,:]).ravel() zz = z.ravel() # filter out nans m = np.isnan(zz) xx = xx[~m] yy = yy[~m] zz = zz[~m] # new grid xi = np.linspace(0, 1, 100) yi = np.linspace(0, 1, 200) # interpolate onto new grid zi = scipy.interpolate.griddata((xx, yy), zz, (xi[:,None], yi[None,:])) -------------------- It's linear interpolation, so it will not overshoot. However, the result depends on how the Delaunay triangulation of the point set looks like, so to most natural results, you need to ensure that the `x` and `y` axes are scaled so that the euclidean distance `sqrt(x^2 + y^2)` means something natural. Also, the performance if perhaps not completely optimal for very large data sets, as it needs to construct the triangulation first. -- Pauli Virtanen From charlesr.harris at gmail.com Mon Jun 13 13:40:25 2011 From: charlesr.harris at gmail.com (Charles R Harris) Date: Mon, 13 Jun 2011 11:40:25 -0600 Subject: [SciPy-Dev] SciPy-Dev Digest, Vol 92, Issue 9 In-Reply-To: References: Message-ID: On Mon, Jun 13, 2011 at 10:57 AM, Pauli Virtanen wrote: > On Mon, 13 Jun 2011 09:32:31 +0700, Ole Nielsen wrote: > [clip] > > Meanwhile, if you could tell me where the LinearNDInterpolator package > can be found? > > See the link I posted earlier: > > http://docs.scipy.org/doc/scipy/reference/interpolate.html > > It's not a separate package, but a part of Scipy 0.9. Usage for your case: > > -------------------- > # some data on a grid, containing nans > x = np.linspace(0, 1, 20) > y = np.linspace(0, 1, 30) > z = np.cos(x[:,None]) + np.sin(y[None,:]) > z[np.random.rand(*z.shape) > 0.9] = np.nan > > # flatten grid data to (x, y, z) point list > xx = (x[:,None] + 0*y[None,:]).ravel() > yy = (0*x[:,None] + y[None,:]).ravel() > zz = z.ravel() > > # filter out nans > m = np.isnan(zz) > xx = xx[~m] > yy = yy[~m] > zz = zz[~m] > > # new grid > xi = np.linspace(0, 1, 100) > yi = np.linspace(0, 1, 200) > > # interpolate onto new grid > zi = scipy.interpolate.griddata((xx, yy), zz, (xi[:,None], yi[None,:])) > -------------------- > > It's linear interpolation, so it will not overshoot. However, the result > depends on how the Delaunay triangulation of the point set looks like, > so to most natural results, you need to ensure that the `x` and `y` axes > are scaled so that the euclidean distance `sqrt(x^2 + y^2)` means something > natural. > > Also, the performance if perhaps not completely optimal for very large data > sets, as it needs to construct the triangulation first. > > > What Pauli said. BTW, check your scipy version to make sure it is .9 If you want bilinear, I think splines of order 1 will do that. Since there is no prefiltering, I expect they consist of simple convolution and nans shouldn't propagate far. ndimage.interpolation.map_coordinatesshould do the trick. The interpolated values on a grid are in the convex hull of the values at the surrounding corners. More specifically, it is between the linear interpolations you get from the two different triangulations of a rectangle obtained by using either of the two diagonals. Chuck -------------- next part -------------- An HTML attachment was scrubbed... URL: From nwagner at iam.uni-stuttgart.de Mon Jun 13 16:02:49 2011 From: nwagner at iam.uni-stuttgart.de (Nils Wagner) Date: Mon, 13 Jun 2011 22:02:49 +0200 Subject: [SciPy-Dev] scipy.test() errors Message-ID: Hi all, I found two scipy.test() errors and a new failure... >>> scipy.__version__ '0.10.0.dev7179' python2.6.5 Nils ====================================================================== ERROR: test_netcdf.test_read_example_data ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/nwagner/local/lib64/python2.6/site-packages/nose-0.11.2.dev-py2.6.egg/nose/case.py", line 183, in runTest self.test(*self.arg) File "/home/nwagner/local/lib64/python2.6/site-packages/scipy/io/tests/test_netcdf.py", line 124, in test_read_example_data f = netcdf_file(fname, 'r') File "/home/nwagner/local/lib64/python2.6/site-packages/scipy/io/netcdf.py", line 205, in __init__ self._read() File "/home/nwagner/local/lib64/python2.6/site-packages/scipy/io/netcdf.py", line 492, in _read self._read_var_array() File "/home/nwagner/local/lib64/python2.6/site-packages/scipy/io/netcdf.py", line 536, in _read_var_array typecode, size, dtype_, begin_, vsize) = self._read_var() File "/home/nwagner/local/lib64/python2.6/site-packages/scipy/io/netcdf.py", line 624, in _read_var attributes = self._read_att_array() File "/home/nwagner/local/lib64/python2.6/site-packages/scipy/io/netcdf.py", line 522, in _read_att_array attributes[name] = self._read_values() File "/home/nwagner/local/lib64/python2.6/site-packages/scipy/io/netcdf.py", line 649, in _read_values values = fromstring(values, dtype='>%s%d' % (typecode, size)) TypeError: data type ">d8" not understood ====================================================================== ERROR: Failure: ImportError (No module named array_tools) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/nwagner/local/lib64/python2.6/site-packages/nose-0.11.2.dev-py2.6.egg/nose/loader.py", line 382, in loadTestsFromName addr.filename, addr.module) File "/home/nwagner/local/lib64/python2.6/site-packages/nose-0.11.2.dev-py2.6.egg/nose/importer.py", line 39, in importFromPath return self.importFromDir(dir_path, fqname) File "/home/nwagner/local/lib64/python2.6/site-packages/nose-0.11.2.dev-py2.6.egg/nose/importer.py", line 86, in importFromDir mod = load_module(part_fqname, fh, filename, desc) File "/home/nwagner/local/lib64/python2.6/site-packages/scipy/signal/tests/test_array_tools.py", line 7, in from scipy.signal.array_tools import axis_slice, axis_reverse, \ ImportError: No module named array_tools ====================================================================== FAIL: test_lu (test_decomp.TestLUSolve) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/nwagner/local/lib64/python2.6/site-packages/scipy/linalg/tests/test_decomp.py", line 732, in test_lu assert_array_equal(x1,x2) File "/home/nwagner/local/lib64/python2.6/site-packages/numpy/testing/utils.py", line 706, in assert_array_equal verbose=verbose, header='Arrays are not equal') File "/home/nwagner/local/lib64/python2.6/site-packages/numpy/testing/utils.py", line 635, in assert_array_compare raise AssertionError(msg) AssertionError: Arrays are not equal (mismatch 90.0%) x: array([-0.36278861, 0.75920432, 0.19844271, 0.65479681, 0.40510514, 0.79604687, -1.05344321, -0.25597019, -0.34997286, 0.07080989]) y: array([-0.36278861, 0.75920432, 0.19844271, 0.65479681, 0.40510514, 0.79604687, -1.05344321, -0.25597019, -0.34997286, 0.07080989]) From warren.weckesser at enthought.com Mon Jun 13 16:37:01 2011 From: warren.weckesser at enthought.com (Warren Weckesser) Date: Mon, 13 Jun 2011 15:37:01 -0500 Subject: [SciPy-Dev] scipy.test() errors In-Reply-To: References: Message-ID: Hi Nils, Thanks for the update. I just fixed the import error ("ERROR: Failure: ImportError (No module named array_tools)") in commit 20b32fe. Warren On Mon, Jun 13, 2011 at 3:02 PM, Nils Wagner wrote: > Hi all, > > I found two scipy.test() errors and a new failure... > > >>> scipy.__version__ > '0.10.0.dev7179' > > python2.6.5 > > Nils > > ====================================================================== > ERROR: test_netcdf.test_read_example_data > ---------------------------------------------------------------------- > Traceback (most recent call last): > File > > "/home/nwagner/local/lib64/python2.6/site-packages/nose-0.11.2.dev-py2.6.egg/nose/case.py", > line 183, in runTest > self.test(*self.arg) > File > > "/home/nwagner/local/lib64/python2.6/site-packages/scipy/io/tests/test_netcdf.py", > line 124, in test_read_example_data > f = netcdf_file(fname, 'r') > File > "/home/nwagner/local/lib64/python2.6/site-packages/scipy/io/netcdf.py", > line 205, in __init__ > self._read() > File > "/home/nwagner/local/lib64/python2.6/site-packages/scipy/io/netcdf.py", > line 492, in _read > self._read_var_array() > File > "/home/nwagner/local/lib64/python2.6/site-packages/scipy/io/netcdf.py", > line 536, in _read_var_array > typecode, size, dtype_, begin_, vsize) = > self._read_var() > File > "/home/nwagner/local/lib64/python2.6/site-packages/scipy/io/netcdf.py", > line 624, in _read_var > attributes = self._read_att_array() > File > "/home/nwagner/local/lib64/python2.6/site-packages/scipy/io/netcdf.py", > line 522, in _read_att_array > attributes[name] = self._read_values() > File > "/home/nwagner/local/lib64/python2.6/site-packages/scipy/io/netcdf.py", > line 649, in _read_values > values = fromstring(values, dtype='>%s%d' % > (typecode, size)) > TypeError: data type ">d8" not understood > > ====================================================================== > ERROR: Failure: ImportError (No module named array_tools) > ---------------------------------------------------------------------- > Traceback (most recent call last): > File > > "/home/nwagner/local/lib64/python2.6/site-packages/nose-0.11.2.dev-py2.6.egg/nose/loader.py", > line 382, in loadTestsFromName > addr.filename, addr.module) > File > > "/home/nwagner/local/lib64/python2.6/site-packages/nose-0.11.2.dev-py2.6.egg/nose/importer.py", > line 39, in importFromPath > return self.importFromDir(dir_path, fqname) > File > > "/home/nwagner/local/lib64/python2.6/site-packages/nose-0.11.2.dev-py2.6.egg/nose/importer.py", > line 86, in importFromDir > mod = load_module(part_fqname, fh, filename, desc) > File > > "/home/nwagner/local/lib64/python2.6/site-packages/scipy/signal/tests/test_array_tools.py", > line 7, in > from scipy.signal.array_tools import axis_slice, > axis_reverse, \ > ImportError: No module named array_tools > > > ====================================================================== > FAIL: test_lu (test_decomp.TestLUSolve) > ---------------------------------------------------------------------- > Traceback (most recent call last): > File > > "/home/nwagner/local/lib64/python2.6/site-packages/scipy/linalg/tests/test_decomp.py", > line 732, in test_lu > assert_array_equal(x1,x2) > File > "/home/nwagner/local/lib64/python2.6/site-packages/numpy/testing/utils.py", > line 706, in assert_array_equal > verbose=verbose, header='Arrays are not equal') > File > "/home/nwagner/local/lib64/python2.6/site-packages/numpy/testing/utils.py", > line 635, in assert_array_compare > raise AssertionError(msg) > AssertionError: > Arrays are not equal > > (mismatch 90.0%) > x: array([-0.36278861, 0.75920432, 0.19844271, > 0.65479681, 0.40510514, > 0.79604687, -1.05344321, -0.25597019, > -0.34997286, 0.07080989]) > y: array([-0.36278861, 0.75920432, 0.19844271, > 0.65479681, 0.40510514, > 0.79604687, -1.05344321, -0.25597019, > -0.34997286, 0.07080989]) > > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cournape at gmail.com Thu Jun 16 19:12:48 2011 From: cournape at gmail.com (David Cournapeau) Date: Fri, 17 Jun 2011 08:12:48 +0900 Subject: [SciPy-Dev] Numpy and Scipy build with bento Message-ID: Hi, I finally have a scipy branch ready to build scipy with bento+waf. While there are still some rough edges, it already has a few interesting features: - automatic dependency handling and parallel build supported thanks to waf - if you know waf, you should be able to customize the build at will. For example, using clang instead of gcc, using the MKL instead of ATLAS should be fairly straightforward. - bento scripts are 1/3 smaller than distutils ones - built and tested on mac os x and ubuntu (windows will definitely not work ATM) For people who are familiar with numscons, I expect the bento build to be almost on-part with numscons, except that bento can also do the distribution stuff (build eggs, windows installers, etc...), and much more integrated. To try it, just get the bento_waf_build branch of scipy (on github.com/cournape/scipy.git), and follow the instructions in BENTO_BUILD.txt cheers, David From pav at iki.fi Fri Jun 17 19:47:20 2011 From: pav at iki.fi (Pauli Virtanen) Date: Fri, 17 Jun 2011 23:47:20 +0000 (UTC) Subject: [SciPy-Dev] Numpy and Scipy build with bento References: Message-ID: On Fri, 17 Jun 2011 08:12:48 +0900, David Cournapeau wrote: [clip] > To try it, just get the bento_waf_build branch of scipy (on > github.com/cournape/scipy.git), and follow the instructions in > BENTO_BUILD.txt Seems to work nicely. Strange to see how much faster the compilation feels with four cores :) *** Some questions on waf integration and general strategy of Bento: (i) Can it be made work so that I can type ./waf This probably could be done with shipping some stuff in bento providing a boilerplate wscript, and would probably also solve the issue of supplying WAF_DIR. (ii) Do you think it would make sense to make the bscript part of Bento stupider, and invert the control flow? That is, one could have the build driven by wscripts instead of bscripts. The wscripts would then just have something like: # scipy/wscript: import bento.bentowaf as bentowaf def configure(ctx): bentowaf.do_configure(ctx) # custom stuff ... def build(ctx): bentowaf.do_build(ctx) def install(ctx): bentowaf.do_install(ctx) # scipy/optimize/wscript: import bento.bentowaf as bentowaf def build(ctx): items = bentowaf.get_items(ctx) # here, we need to do some nonstandard stuff with the builders for name in ['_lbfgsb', '_cobyla', 'minpack2', '_nnls', '_slsqp']: item = items.pop(name) ctx(features="c pyext bento cshlib f2py", source=item.sources, target=item.name, use="minpack rootfind FLAPACK CLIB") # the rest are to be built with default options bentowaf.build_items(ctx, items) Similarly, one could imagine a Makefile-driven build: # Makefile configure: configure-stamp configure-stamp: bentomaker configure $(CONFIGURE_ARGS) touch configure-stamp build: build-stamp build-stamp: configure-stamp some_extension.so touch build-stamp install: build-stamp bentomaker install $(INSTALL_ARGS) build_egg: build-stamp bentomaker build_egg some_extension.so: $(shell bentomaker get-sources some_extension) gcc $(shell bentomaker get-python-cflags) -o $@ $^ cp -f $@ $(shell bentomaker get-target some_extensions) .PHONY: configure build install build_egg I'm shooting from the hip. Do I forget something (you've obviously put more thought into this)? Pauli From cournape at gmail.com Sat Jun 18 05:31:28 2011 From: cournape at gmail.com (David Cournapeau) Date: Sat, 18 Jun 2011 18:31:28 +0900 Subject: [SciPy-Dev] Numpy and Scipy build with bento In-Reply-To: References: Message-ID: On Sat, Jun 18, 2011 at 8:47 AM, Pauli Virtanen wrote: > On Fri, 17 Jun 2011 08:12:48 +0900, David Cournapeau wrote: > [clip] >> To try it, just get the bento_waf_build branch of scipy (on >> github.com/cournape/scipy.git), and follow the instructions in >> BENTO_BUILD.txt > > Seems to work nicely. Strange to see how much faster the compilation > feels with four cores :) It is cheating because the default flags are non-optimized ones, but one can indeed expect a significant speed up. > Some questions on waf integration and general strategy of Bento: > > > (i) > > Can it be made work so that I can type > > ? ?./waf > > This probably could be done with shipping some stuff in bento providing > a boilerplate wscript, and would probably also solve the issue of > supplying WAF_DIR. It may be difficult because I would need for bento to integrate within waf, whereas the opposite is simpler. Also, while numpy/scipy needs customization, most python packages do not, and could get away with no bscript file at all. In those cases, it should be possible to use waf to build extensions without writing a single line of waf-specific code. I also feel like having bento "at the top" will help bento get traction outside the scipy community, because it becomes simpler to integrate with existing tools. For example, I realized that it is actually possible write something like for existing packages using distutils: # setup.py if USE_BENTO: from setup_bento import main main() sys.exit(0) # Here the existing code using distutils ... which has important implication for integration with virtualenv and pip. I would rather write this kind of code once. The WAFDIR issue is temporary, I can see various strategies to avoid this. What advantages would you see in inverting the control ? cheers, David From pav at iki.fi Sat Jun 18 10:15:37 2011 From: pav at iki.fi (Pauli Virtanen) Date: Sat, 18 Jun 2011 14:15:37 +0000 (UTC) Subject: [SciPy-Dev] Numpy and Scipy build with bento References: Message-ID: On Sat, 18 Jun 2011 18:31:28 +0900, David Cournapeau wrote: [clip] > It may be difficult because I would need for bento to integrate within > waf, whereas the opposite is simpler. Also, while numpy/scipy needs > customization, most python packages do not, and could get away with no > bscript file at all. In those cases, it should be possible to use waf to > build extensions without writing a single line of waf-specific code. It would seem to me that in those simple cases, you could get away with a top-level wscript from bento.bentowaf import magick magick(globals()) But I didn't try implementing this, so it may be more difficult this way. [clip] > What advantages would you see in inverting the control ? This would remove one level from the build system. The users would not need to learn how bscripts work, if they already are familiar with waf, or whatever other build system they are using. Pauli From nwagner at iam.uni-stuttgart.de Sat Jun 18 17:42:44 2011 From: nwagner at iam.uni-stuttgart.de (Nils Wagner) Date: Sat, 18 Jun 2011 23:42:44 +0200 Subject: [SciPy-Dev] ERROR: test_arpack.test_hermitian_modes Message-ID: Hi Pauli, Thank you for very much for the extension to generalized eigenvalue problems. Your recent changes wrt arpack generate an error/failure. Nils ====================================================================== ERROR: test_arpack.test_hermitian_modes(True, , 'F', 2, 'SM', None, None, ) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/nwagner/local/lib64/python2.6/site-packages/nose-0.11.2.dev-py2.6.egg/nose/case.py", line 183, in runTest self.test(*self.arg) File "/home/nwagner/local/lib64/python2.6/site-packages/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", line 168, in eval_evec eval, evec = eigs_func(ac, k, bc, **kwargs) File "/home/nwagner/local/lib64/python2.6/site-packages/scipy/sparse/linalg/eigen/arpack/arpack.py", line 1425, in eigsh OPinv=OPinv) File "/home/nwagner/local/lib64/python2.6/site-packages/scipy/sparse/linalg/eigen/arpack/arpack.py", line 1251, in eigs params.iterate() File "/home/nwagner/local/lib64/python2.6/site-packages/scipy/sparse/linalg/eigen/arpack/arpack.py", line 727, in iterate self.workd[yslice] = self.OP(self.workd[xslice]) File "/home/nwagner/local/lib64/python2.6/site-packages/scipy/sparse/linalg/eigen/arpack/arpack.py", line 641, in self.OP = lambda x: Minv_matvec(matvec(x)) File "/home/nwagner/local/lib64/python2.6/site-packages/scipy/sparse/linalg/interface.py", line 123, in matvec y = self._matvec(x) File "/home/nwagner/local/lib64/python2.6/site-packages/scipy/sparse/linalg/eigen/arpack/arpack.py", line 945, in _matvec % (self.ifunc.__name__, info)) ValueError: Error in inverting M: function gmres did not converge (info = 60). FAIL: test_arpack.test_hermitian_modes(True, , 'D', 2, 'LM', None, None, ) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/nwagner/local/lib64/python2.6/site-packages/nose-0.11.2.dev-py2.6.egg/nose/case.py", line 183, in runTest self.test(*self.arg) File "/home/nwagner/local/lib64/python2.6/site-packages/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", line 196, in eval_evec assert_allclose(LHS, RHS, rtol=_rtol[typ], atol=_atol[typ], err_msg=err) File "/home/nwagner/local/lib64/python2.6/site-packages/numpy/testing/utils.py", line 1167, in assert_allclose verbose=verbose, header=header) File "/home/nwagner/local/lib64/python2.6/site-packages/numpy/testing/utils.py", line 635, in assert_array_compare raise AssertionError(msg) AssertionError: Not equal to tolerance rtol=2.22045e-13, atol=2.22045e-13 error for eigsh:general, typ=D, which=LM, sigma=None, mattype=aslinearoperator, OPpart=None, mode=normal (mismatch 100.0%) x: array([[ 0.40172292+3.97785014j, 1.26541377-2.2227806j ], [ 0.67562574+2.73428778j, -6.32196547-3.30680082j], [-0.75603444+1.17747523j, -0.02785408-1.70286801j],... y: array([[ 0.40172292+3.97785014j, 1.26541377-2.2227806j ], [ 0.67562574+2.73428778j, -6.32196547-3.30680082j], [-0.75603444+1.17747523j, -0.02785408-1.70286801j],... From robert.kern at gmail.com Sat Jun 18 20:28:50 2011 From: robert.kern at gmail.com (Robert Kern) Date: Sat, 18 Jun 2011 19:28:50 -0500 Subject: [SciPy-Dev] Numpy and Scipy build with bento In-Reply-To: References: Message-ID: On Sat, Jun 18, 2011 at 09:15, Pauli Virtanen wrote: > On Sat, 18 Jun 2011 18:31:28 +0900, David Cournapeau wrote: > [clip] >> What advantages would you see in inverting the control ? > > This would remove one level from the build system. The users would > not need to learn how bscripts work, if they already are familiar > with waf, or whatever other build system they are using. But as David said, he's aiming for broader acceptance than the scipy community, who mostly won't need a bscript or even waf. Personally, I would prefer that the build system that's used be subordinated to the packaging system. The build system should be an implementation detail, not the interface, because we want to be able to use different build systems for different projects, according to the individual needs of the projects. I would love to just use bentomaker commands to install all third party packages, not make commands for one package and waf commands for another. So yes, from a package *writer's* perspective, it might make sense to subordinate the packaging tool to the build system that you chose, but from the perspective of the person *installing* your software, in a broad ecosystem of other software, it's better to have Bento driving. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." ? -- Umberto Eco From pav at iki.fi Sat Jun 18 21:54:51 2011 From: pav at iki.fi (Pauli Virtanen) Date: Sun, 19 Jun 2011 01:54:51 +0000 (UTC) Subject: [SciPy-Dev] ERROR: test_arpack.test_hermitian_modes References: Message-ID: On Sat, 18 Jun 2011 23:42:44 +0200, Nils Wagner wrote: > Thank you for very much for the extension to generalized eigenvalue > problems. You should thank Jake V. instead, I just merged his work. [clip] > ====================================================================== > ERROR: test_arpack.test_hermitian_modes(True, , 'F', 2, > 'SM', None, None, ) > ---------------------------------------------------------------------- [clip] > ValueError: Error in inverting M: function gmres did not converge (info > = 60). Check that you have a working GMRES: try e.g. import numpy as np import scipy.sparse.linalg A = np.random.rand(6, 6) + 1j*np.random.rand(6, 6) b = np.random.rand(6) + 1j*np.random.rand(6) x, info = scipy.sparse.linalg.gmres(A, b) y = np.linalg.solve(A, b) print abs(x - y).max() I've noticed that at gfortran 4.5.2 miscompiles Scipy's gmres routine with -O0. > FAIL: test_arpack.test_hermitian_modes(True, , 'D', 2, > 'LM', None, None, ) > ---------------------------------------------------------------------- This one looks like a precision issue. Can you try increasing the `1000` prefactor e.g. to `2000` for the _rtol and _atol values for float64 in test_arpack.py, to see how large it needs to be for your system. From nwagner at iam.uni-stuttgart.de Sun Jun 19 04:10:52 2011 From: nwagner at iam.uni-stuttgart.de (Nils Wagner) Date: Sun, 19 Jun 2011 10:10:52 +0200 Subject: [SciPy-Dev] ERROR: test_arpack.test_hermitian_modes In-Reply-To: References: Message-ID: On Sun, 19 Jun 2011 01:54:51 +0000 (UTC) Pauli Virtanen wrote: > On Sat, 18 Jun 2011 23:42:44 +0200, Nils Wagner wrote: >> Thank you for very much for the extension to generalized >>eigenvalue >> problems. > > You should thank Jake V. instead, I just merged his >work. O.k. I wasn't aware of that. Thanks a lot Jake for implementing GEWP ! > > [clip] >> ====================================================================== >> ERROR: test_arpack.test_hermitian_modes(True, >>, 'F', 2, >> 'SM', None, None, >0x2640a28>) >> ---------------------------------------------------------------------- > [clip] >> ValueError: Error in inverting M: function gmres did not >>converge (info >> = 60). > > Check that you have a working GMRES: try e.g. > > import numpy as np > import scipy.sparse.linalg > A = np.random.rand(6, 6) + 1j*np.random.rand(6, 6) > b = np.random.rand(6) + 1j*np.random.rand(6) > x, info = scipy.sparse.linalg.gmres(A, b) > y = np.linalg.solve(A, b) > print abs(x - y).max() > The example works for me. However, if I increase the dimension of the random matrix to 60, the residual is of order 10^0. > I've noticed that at gfortran 4.5.2 miscompiles Scipy's >gmres routine > with -O0. > >> FAIL: test_arpack.test_hermitian_modes(True, >>, 'D', 2, >> 'LM', None, None, >0x2640a28>) >> ---------------------------------------------------------------------- > > This one looks like a precision issue. Can you try >increasing the > `1000` prefactor e.g. to `2000` for the _rtol and _atol >values for > float64 in test_arpack.py, to see how large it needs to >be for your > system. > The problem persists if I increase the prefactor to 2000. i.e. ====================================================================== ERROR: test_arpack.test_hermitian_modes(True, , 'F', 2, 'SM', None, None, ) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/nwagner/local/lib64/python2.6/site-packages/nose-0.11.2.dev-py2.6.egg/nose/case.py", line 183, in runTest self.test(*self.arg) File "/home/nwagner/git/scipy/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", line 168, in eval_evec eval, evec = eigs_func(ac, k, bc, **kwargs) File "/home/nwagner/local/lib64/python2.6/site-packages/scipy/sparse/linalg/eigen/arpack/arpack.py", line 1425, in eigsh OPinv=OPinv) File "/home/nwagner/local/lib64/python2.6/site-packages/scipy/sparse/linalg/eigen/arpack/arpack.py", line 1251, in eigs params.iterate() File "/home/nwagner/local/lib64/python2.6/site-packages/scipy/sparse/linalg/eigen/arpack/arpack.py", line 727, in iterate self.workd[yslice] = self.OP(self.workd[xslice]) File "/home/nwagner/local/lib64/python2.6/site-packages/scipy/sparse/linalg/eigen/arpack/arpack.py", line 641, in self.OP = lambda x: Minv_matvec(matvec(x)) File "/home/nwagner/local/lib64/python2.6/site-packages/scipy/sparse/linalg/interface.py", line 123, in matvec y = self._matvec(x) File "/home/nwagner/local/lib64/python2.6/site-packages/scipy/sparse/linalg/eigen/arpack/arpack.py", line 945, in _matvec % (self.ifunc.__name__, info)) ValueError: Error in inverting M: function gmres did not converge (info = 60) Nils From pav at iki.fi Sun Jun 19 08:56:53 2011 From: pav at iki.fi (Pauli Virtanen) Date: Sun, 19 Jun 2011 12:56:53 +0000 (UTC) Subject: [SciPy-Dev] ERROR: test_arpack.test_hermitian_modes References: Message-ID: On Sun, 19 Jun 2011 10:10:52 +0200, Nils Wagner wrote: [clip] >>> FAIL: test_arpack.test_hermitian_modes(True, >>>, 'D', 2, >>> 'LM', None, None, >>0x2640a28>) [clip] > The problem persists if I increase the prefactor to 2000. i.e. > > ====================================================================== > ERROR: test_arpack.test_hermitian_modes(True, , 'F', 2, > 'SM', None, None, ) > ---------------------------------------------------------------------- [clip] > ValueError: Error in inverting M: function gmres did not converge (info > = 60) This is different problem: Does the ..., , 'D', ... one vanish when the prefactor is 2000? If not, how large a prefactor is large enough? From nwagner at iam.uni-stuttgart.de Sun Jun 19 09:32:01 2011 From: nwagner at iam.uni-stuttgart.de (Nils Wagner) Date: Sun, 19 Jun 2011 15:32:01 +0200 Subject: [SciPy-Dev] ERROR: test_arpack.test_hermitian_modes In-Reply-To: References: Message-ID: On Sun, 19 Jun 2011 12:56:53 +0000 (UTC) Pauli Virtanen wrote: > On Sun, 19 Jun 2011 10:10:52 +0200, Nils Wagner wrote: > [clip] >>>> FAIL: test_arpack.test_hermitian_modes(True, >>>>, 'D', 2, >>>> 'LM', None, None, >>>0x2640a28>) > [clip] >> The problem persists if I increase the prefactor to >>2000. i.e. >> >> ====================================================================== >> ERROR: test_arpack.test_hermitian_modes(True, >>, 'F', 2, >> 'SM', None, None, >0xe12e60>) >> ---------------------------------------------------------------------- > [clip] >> ValueError: Error in inverting M: function gmres did not >>converge (info >> = 60) > > This is different problem: Does the ..., >, 'D', ... > one vanish when the prefactor is 2000? If not, how large >a prefactor > is large enough? > Oops, I missed that. It works for me, if the prefactor is 2000. Hence, gmres is inaccurate. Nils From nwagner at iam.uni-stuttgart.de Mon Jun 20 16:04:19 2011 From: nwagner at iam.uni-stuttgart.de (Nils Wagner) Date: Mon, 20 Jun 2011 22:04:19 +0200 Subject: [SciPy-Dev] Strange behaviour of gmres Message-ID: Hi all, who can shed light on the following behaviour of gmres ? Nils import numpy as np import scipy.sparse.linalg for n in range(2,25): A = np.random.rand(n, n) + 1j*np.random.rand(n, n) b = np.random.rand(n) + 1j*np.random.rand(n) x, info = scipy.sparse.linalg.gmres(A, b) y = np.linalg.solve(A, b) print 'order of the matrix %i info: %i error %e ' %(n, info, abs(x - y).max()) order of the matrix 2 info: 0 error 2.482534e-16 order of the matrix 3 info: 0 error 3.723801e-16 order of the matrix 4 info: 0 error 1.680072e-15 order of the matrix 5 info: 0 error 4.965068e-15 order of the matrix 6 info: 0 error 2.909013e-16 order of the matrix 7 info: 0 error 4.820209e-15 order of the matrix 8 info: 0 error 1.012318e-15 order of the matrix 9 info: 0 error 1.404333e-15 order of the matrix 10 info: 0 error 1.807312e-15 order of the matrix 11 info: 0 error 4.428663e-14 order of the matrix 12 info: 0 error 7.304728e-15 order of the matrix 13 info: 0 error 2.100054e-14 order of the matrix 14 info: 0 error 3.038038e-14 order of the matrix 15 info: 0 error 1.333712e-15 order of the matrix 16 info: 0 error 9.711044e-14 order of the matrix 17 info: 0 error 1.405430e-15 order of the matrix 18 info: 0 error 1.519019e-14 order of the matrix 19 info: 0 error 7.759657e-15 order of the matrix 20 info: 0 error 6.402436e-14 order of the matrix 21 info: 0 error 1.273827e-04 order of the matrix 22 info: 220 error 4.131225e-02 order of the matrix 23 info: 230 error 1.475908e+00 order of the matrix 24 info: 240 error 1.899145e+00 From ralf.gommers at googlemail.com Mon Jun 20 16:36:03 2011 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Mon, 20 Jun 2011 22:36:03 +0200 Subject: [SciPy-Dev] Advertise on python3 support? In-Reply-To: <4DF6265B.6060507@gmail.com> References: <4DF6265B.6060507@gmail.com> Message-ID: On Mon, Jun 13, 2011 at 5:01 PM, Xavier Gnata wrote: > Hi, > > Looking at http://www.scipy.org/ it is not obvious to find info on the > numpy/scipy python3 support (welldon't even find this statement at all > on scipy.org.). > > Is there a plan to advertise a bit more on that support? > I think it is needed because it would clearly show to other packages > maintainers that the trend to python3 has started. > > I've added this to the FAQ. There may be some more places this could be mentioned. The website needs a little attention anyway, there has been an open issue about the license not being mentioned on the front page for a long time. It would be great to have a volunteer for improving the site. Cheers, Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From pav at iki.fi Mon Jun 20 19:09:56 2011 From: pav at iki.fi (Pauli Virtanen) Date: Mon, 20 Jun 2011 23:09:56 +0000 (UTC) Subject: [SciPy-Dev] Strange behaviour of gmres References: Message-ID: On Mon, 20 Jun 2011 22:04:19 +0200, Nils Wagner wrote: [clip] > who can shed light on the following behaviour of gmres ? The iteration has the default value restart=20, so it is not guaranteed to converge fast (or at all) for matrices larger than that. The convergence for matrices with n > restart depends on the eigenvalue distribution etc. Pauli From ben.root at ou.edu Tue Jun 21 11:51:18 2011 From: ben.root at ou.edu (Benjamin Root) Date: Tue, 21 Jun 2011 10:51:18 -0500 Subject: [SciPy-Dev] Many errors/failures running scipy.test() using latest numpy and scipy Message-ID: I just did a pull and rebuild of numpy and scipy. numpy tested fine, but scipy had many errors and failures. Attached is the log output. The first error has to do with the netcdf file (I thought that was fixed by now?). Then, some of the errors are related to the gmres module (I see that is already known). Then, there are many errors for "test_arpack.test_real_nonsymmetric_modes", "test_arpack.test_complex_nonsymmetric_modes", and "test_arpack.test_hermitian_modes". Lastly, there is a single failure for "test_morestats.TestAnderson". I hope this is useful. Ben Root -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- ............................................................................................................................................................................................................................K........................................................................................................../home/bvr/Programs/scipy/scipy/interpolate/fitpack2.py:678: UserWarning: The coefficients of the spline returned have been computed as the minimal norm least-squares solution of a (numerically) rank deficient system (deficiency=7). If deficiency is large, the results may be inaccurate. Deficiency may strongly depend on the value of eps. warnings.warn(message) ....../home/bvr/Programs/scipy/scipy/interpolate/fitpack2.py:609: UserWarning: The required storage space exceeds the available storage space: nxest or nyest too small, or s too small. The weighted least-squares spline corresponds to the current set of knots. warnings.warn(message) .......................K..K......................................................................................................................................................................................................................................................................................................................................................................................................................E/home/bvr/Programs/scipy/scipy/io/wavfile.py:31: WavFileWarning: Unfamiliar format bytes warnings.warn("Unfamiliar format bytes", WavFileWarning) /home/bvr/Programs/scipy/scipy/io/wavfile.py:121: WavFileWarning: chunk not understood warnings.warn("chunk not understood", WavFileWarning) ................................................................................./home/bvr/Programs/numpy/numpy/lib/utils.py:139: DeprecationWarning: `get_blas_funcs` is deprecated! warnings.warn(depdoc, DeprecationWarning) ..............................................................................................................................................SSSSSS......SSSSSS......SSSS................................................................................................................................F............................................................................................................................................................................................K...........................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................SSSSSSSSSSS....................................................................................................................................................F.........................................................................................................F.....F.....F.....F.....E.....E.....E.....E....EF....EF....EF....EF....EE....EE....EE....EE............................F...........F.......................EE..........EE..........EE..........FF..........FF..........FF..........EE..........EE..........EE.........EE.......EE.......EE.......FF.......FF.......FF......EEE......EEE......EEE......EFF......EFF......EFF................................................................................................................................................................................K...............................................................K...........................................................................................................................................................KK.............................................................................................................................................................................................................................................................................................................................................................................................................................................K.K........................................................................................................................................................................................................................................................................................................................................................................................K........K.........SSSSSSS........................................................................................................................................................................................................................................................................................................................................................................................./home/bvr/Programs/scipy/scipy/stats/distributions.py:4102: RuntimeWarning: overflow encountered in exp return exp(c*x-exp(x)-gamln(c)) ................................./home/bvr/Programs/scipy/scipy/stats/distributions.py:4583: RuntimeWarning: invalid value encountered in sqrt vals = 2*(bt+1.0)*sqrt(b-2.0)/((b-3.0)*sqrt(b)) .........................................................................................................................................................................................................................................................................................................S.............................................................................................................................................................................................../home/bvr/Programs/scipy/scipy/stats/distributions.py:5098: RuntimeWarning: divide by zero encountered in divide return where((lam <= 0) | (abs(x) < 1.0/arr(lam)), Px, 0.0) ....F................................................................................................................................................................................................................................................................................................................................................................................................................. ====================================================================== ERROR: test_netcdf.test_read_example_data ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 187, in runTest self.test(*self.arg) File "/home/bvr/Programs/scipy/scipy/io/tests/test_netcdf.py", line 124, in test_read_example_data f = netcdf_file(fname, 'r') File "/home/bvr/Programs/scipy/scipy/io/netcdf.py", line 205, in __init__ self._read() File "/home/bvr/Programs/scipy/scipy/io/netcdf.py", line 492, in _read self._read_var_array() File "/home/bvr/Programs/scipy/scipy/io/netcdf.py", line 536, in _read_var_array typecode, size, dtype_, begin_, vsize) = self._read_var() File "/home/bvr/Programs/scipy/scipy/io/netcdf.py", line 624, in _read_var attributes = self._read_att_array() File "/home/bvr/Programs/scipy/scipy/io/netcdf.py", line 522, in _read_att_array attributes[name] = self._read_values() File "/home/bvr/Programs/scipy/scipy/io/netcdf.py", line 649, in _read_values values = fromstring(values, dtype='>%s%d' % (typecode, size)) TypeError: data type ">d8" not understood ====================================================================== ERROR: test_arpack.test_hermitian_modes(True, , 'D', 2, 'LM', None, 0.5, ) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 187, in runTest self.test(*self.arg) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", line 174, in eval_evec eval, evec = eigs_func(ac, k, **kwargs) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 1425, in eigsh OPinv=OPinv) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 1251, in eigs params.iterate() File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 730, in iterate self.workd[yslice] = self.OPa(self.workd[Bxslice]) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/interface.py", line 123, in matvec y = self._matvec(x) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 990, in _matvec % (self.ifunc.__name__, info)) ValueError: Error in inverting [A-sigma*M]: function gmres did not converge (info = 60). ====================================================================== ERROR: test_arpack.test_hermitian_modes(True, , 'D', 2, 'SM', None, 0.5, ) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 187, in runTest self.test(*self.arg) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", line 174, in eval_evec eval, evec = eigs_func(ac, k, **kwargs) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 1425, in eigsh OPinv=OPinv) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 1251, in eigs params.iterate() File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 730, in iterate self.workd[yslice] = self.OPa(self.workd[Bxslice]) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/interface.py", line 123, in matvec y = self._matvec(x) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 990, in _matvec % (self.ifunc.__name__, info)) ValueError: Error in inverting [A-sigma*M]: function gmres did not converge (info = 60). ====================================================================== ERROR: test_arpack.test_hermitian_modes(True, , 'D', 2, 'LA', None, 0.5, ) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 187, in runTest self.test(*self.arg) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", line 174, in eval_evec eval, evec = eigs_func(ac, k, **kwargs) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 1425, in eigsh OPinv=OPinv) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 1251, in eigs params.iterate() File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 730, in iterate self.workd[yslice] = self.OPa(self.workd[Bxslice]) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/interface.py", line 123, in matvec y = self._matvec(x) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 990, in _matvec % (self.ifunc.__name__, info)) ValueError: Error in inverting [A-sigma*M]: function gmres did not converge (info = 60). ====================================================================== ERROR: test_arpack.test_hermitian_modes(True, , 'D', 2, 'SA', None, 0.5, ) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 187, in runTest self.test(*self.arg) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", line 174, in eval_evec eval, evec = eigs_func(ac, k, **kwargs) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 1425, in eigsh OPinv=OPinv) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 1251, in eigs params.iterate() File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 730, in iterate self.workd[yslice] = self.OPa(self.workd[Bxslice]) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/interface.py", line 123, in matvec y = self._matvec(x) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 990, in _matvec % (self.ifunc.__name__, info)) ValueError: Error in inverting [A-sigma*M]: function gmres did not converge (info = 60). ====================================================================== ERROR: test_arpack.test_hermitian_modes(True, , 'F', 2, 'LM', None, None, ) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 187, in runTest self.test(*self.arg) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", line 168, in eval_evec eval, evec = eigs_func(ac, k, bc, **kwargs) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 1425, in eigsh OPinv=OPinv) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 1251, in eigs params.iterate() File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 723, in iterate self.workd[yslice] = self.OP(self.workd[xslice]) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 641, in self.OP = lambda x: Minv_matvec(matvec(x)) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/interface.py", line 123, in matvec y = self._matvec(x) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 945, in _matvec % (self.ifunc.__name__, info)) ValueError: Error in inverting M: function gmres did not converge (info = 60). ====================================================================== ERROR: test_arpack.test_hermitian_modes(True, , 'F', 2, 'SM', None, None, ) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 187, in runTest self.test(*self.arg) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", line 168, in eval_evec eval, evec = eigs_func(ac, k, bc, **kwargs) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 1425, in eigsh OPinv=OPinv) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 1251, in eigs params.iterate() File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 723, in iterate self.workd[yslice] = self.OP(self.workd[xslice]) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 641, in self.OP = lambda x: Minv_matvec(matvec(x)) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/interface.py", line 123, in matvec y = self._matvec(x) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 945, in _matvec % (self.ifunc.__name__, info)) ValueError: Error in inverting M: function gmres did not converge (info = 60). ====================================================================== ERROR: test_arpack.test_hermitian_modes(True, , 'F', 2, 'LA', None, None, ) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 187, in runTest self.test(*self.arg) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", line 168, in eval_evec eval, evec = eigs_func(ac, k, bc, **kwargs) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 1425, in eigsh OPinv=OPinv) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 1251, in eigs params.iterate() File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 723, in iterate self.workd[yslice] = self.OP(self.workd[xslice]) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 641, in self.OP = lambda x: Minv_matvec(matvec(x)) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/interface.py", line 123, in matvec y = self._matvec(x) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 945, in _matvec % (self.ifunc.__name__, info)) ValueError: Error in inverting M: function gmres did not converge (info = 60). ====================================================================== ERROR: test_arpack.test_hermitian_modes(True, , 'F', 2, 'SA', None, None, ) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 187, in runTest self.test(*self.arg) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", line 168, in eval_evec eval, evec = eigs_func(ac, k, bc, **kwargs) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 1425, in eigsh OPinv=OPinv) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 1251, in eigs params.iterate() File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 727, in iterate self.workd[yslice] = self.OP(self.workd[xslice]) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 641, in self.OP = lambda x: Minv_matvec(matvec(x)) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/interface.py", line 123, in matvec y = self._matvec(x) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 945, in _matvec % (self.ifunc.__name__, info)) ValueError: Error in inverting M: function gmres did not converge (info = 60). ====================================================================== ERROR: test_arpack.test_hermitian_modes(True, , 'D', 2, 'LM', None, None, ) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 187, in runTest self.test(*self.arg) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", line 168, in eval_evec eval, evec = eigs_func(ac, k, bc, **kwargs) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 1425, in eigsh OPinv=OPinv) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 1251, in eigs params.iterate() File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 723, in iterate self.workd[yslice] = self.OP(self.workd[xslice]) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 641, in self.OP = lambda x: Minv_matvec(matvec(x)) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/interface.py", line 123, in matvec y = self._matvec(x) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 945, in _matvec % (self.ifunc.__name__, info)) ValueError: Error in inverting M: function gmres did not converge (info = 60). ====================================================================== ERROR: test_arpack.test_hermitian_modes(True, , 'D', 2, 'LM', None, 0.5, ) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 187, in runTest self.test(*self.arg) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", line 168, in eval_evec eval, evec = eigs_func(ac, k, bc, **kwargs) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 1425, in eigsh OPinv=OPinv) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 1251, in eigs params.iterate() File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 730, in iterate self.workd[yslice] = self.OPa(self.workd[Bxslice]) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/interface.py", line 123, in matvec y = self._matvec(x) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 990, in _matvec % (self.ifunc.__name__, info)) ValueError: Error in inverting [A-sigma*M]: function gmres did not converge (info = 60). ====================================================================== ERROR: test_arpack.test_hermitian_modes(True, , 'D', 2, 'SM', None, None, ) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 187, in runTest self.test(*self.arg) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", line 168, in eval_evec eval, evec = eigs_func(ac, k, bc, **kwargs) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 1425, in eigsh OPinv=OPinv) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 1251, in eigs params.iterate() File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 723, in iterate self.workd[yslice] = self.OP(self.workd[xslice]) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 641, in self.OP = lambda x: Minv_matvec(matvec(x)) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/interface.py", line 123, in matvec y = self._matvec(x) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 945, in _matvec % (self.ifunc.__name__, info)) ValueError: Error in inverting M: function gmres did not converge (info = 60). ====================================================================== ERROR: test_arpack.test_hermitian_modes(True, , 'D', 2, 'SM', None, 0.5, ) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 187, in runTest self.test(*self.arg) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", line 168, in eval_evec eval, evec = eigs_func(ac, k, bc, **kwargs) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 1425, in eigsh OPinv=OPinv) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 1251, in eigs params.iterate() File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 730, in iterate self.workd[yslice] = self.OPa(self.workd[Bxslice]) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/interface.py", line 123, in matvec y = self._matvec(x) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 990, in _matvec % (self.ifunc.__name__, info)) ValueError: Error in inverting [A-sigma*M]: function gmres did not converge (info = 60). ====================================================================== ERROR: test_arpack.test_hermitian_modes(True, , 'D', 2, 'LA', None, None, ) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 187, in runTest self.test(*self.arg) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", line 168, in eval_evec eval, evec = eigs_func(ac, k, bc, **kwargs) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 1425, in eigsh OPinv=OPinv) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 1251, in eigs params.iterate() File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 723, in iterate self.workd[yslice] = self.OP(self.workd[xslice]) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 641, in self.OP = lambda x: Minv_matvec(matvec(x)) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/interface.py", line 123, in matvec y = self._matvec(x) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 945, in _matvec % (self.ifunc.__name__, info)) ValueError: Error in inverting M: function gmres did not converge (info = 60). ====================================================================== ERROR: test_arpack.test_hermitian_modes(True, , 'D', 2, 'LA', None, 0.5, ) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 187, in runTest self.test(*self.arg) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", line 168, in eval_evec eval, evec = eigs_func(ac, k, bc, **kwargs) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 1425, in eigsh OPinv=OPinv) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 1251, in eigs params.iterate() File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 730, in iterate self.workd[yslice] = self.OPa(self.workd[Bxslice]) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/interface.py", line 123, in matvec y = self._matvec(x) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 990, in _matvec % (self.ifunc.__name__, info)) ValueError: Error in inverting [A-sigma*M]: function gmres did not converge (info = 60). ====================================================================== ERROR: test_arpack.test_hermitian_modes(True, , 'D', 2, 'SA', None, None, ) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 187, in runTest self.test(*self.arg) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", line 168, in eval_evec eval, evec = eigs_func(ac, k, bc, **kwargs) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 1425, in eigsh OPinv=OPinv) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 1251, in eigs params.iterate() File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 723, in iterate self.workd[yslice] = self.OP(self.workd[xslice]) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 641, in self.OP = lambda x: Minv_matvec(matvec(x)) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/interface.py", line 123, in matvec y = self._matvec(x) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 945, in _matvec % (self.ifunc.__name__, info)) ValueError: Error in inverting M: function gmres did not converge (info = 60). ====================================================================== ERROR: test_arpack.test_hermitian_modes(True, , 'D', 2, 'SA', None, 0.5, ) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 187, in runTest self.test(*self.arg) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", line 168, in eval_evec eval, evec = eigs_func(ac, k, bc, **kwargs) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 1425, in eigsh OPinv=OPinv) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 1251, in eigs params.iterate() File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 730, in iterate self.workd[yslice] = self.OPa(self.workd[Bxslice]) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/interface.py", line 123, in matvec y = self._matvec(x) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 990, in _matvec % (self.ifunc.__name__, info)) ValueError: Error in inverting [A-sigma*M]: function gmres did not converge (info = 60). ====================================================================== ERROR: test_arpack.test_real_nonsymmetric_modes(False, , 'd', 2, 'LM', None, (0.1+0.1j), , 'r') ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 187, in runTest self.test(*self.arg) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", line 174, in eval_evec eval, evec = eigs_func(ac, k, **kwargs) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 1251, in eigs params.iterate() File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 730, in iterate self.workd[yslice] = self.OPa(self.workd[Bxslice]) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 662, in self.OPa = lambda x: np.real(Minv_matvec(x)) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/interface.py", line 123, in matvec y = self._matvec(x) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 990, in _matvec % (self.ifunc.__name__, info)) ValueError: Error in inverting [A-sigma*M]: function gmres did not converge (info = 60). ====================================================================== ERROR: test_arpack.test_real_nonsymmetric_modes(False, , 'd', 2, 'LM', None, (0.1+0.1j), , 'i') ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 187, in runTest self.test(*self.arg) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", line 174, in eval_evec eval, evec = eigs_func(ac, k, **kwargs) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 1251, in eigs params.iterate() File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 730, in iterate self.workd[yslice] = self.OPa(self.workd[Bxslice]) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 664, in self.OPa = lambda x: np.imag(Minv_matvec(x)) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/interface.py", line 123, in matvec y = self._matvec(x) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 990, in _matvec % (self.ifunc.__name__, info)) ValueError: Error in inverting [A-sigma*M]: function gmres did not converge (info = 60). ====================================================================== ERROR: test_arpack.test_real_nonsymmetric_modes(False, , 'd', 2, 'LR', None, (0.1+0.1j), , 'r') ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 187, in runTest self.test(*self.arg) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", line 174, in eval_evec eval, evec = eigs_func(ac, k, **kwargs) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 1251, in eigs params.iterate() File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 730, in iterate self.workd[yslice] = self.OPa(self.workd[Bxslice]) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 662, in self.OPa = lambda x: np.real(Minv_matvec(x)) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/interface.py", line 123, in matvec y = self._matvec(x) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 990, in _matvec % (self.ifunc.__name__, info)) ValueError: Error in inverting [A-sigma*M]: function gmres did not converge (info = 60). ====================================================================== ERROR: test_arpack.test_real_nonsymmetric_modes(False, , 'd', 2, 'LR', None, (0.1+0.1j), , 'i') ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 187, in runTest self.test(*self.arg) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", line 174, in eval_evec eval, evec = eigs_func(ac, k, **kwargs) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 1251, in eigs params.iterate() File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 730, in iterate self.workd[yslice] = self.OPa(self.workd[Bxslice]) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 664, in self.OPa = lambda x: np.imag(Minv_matvec(x)) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/interface.py", line 123, in matvec y = self._matvec(x) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 990, in _matvec % (self.ifunc.__name__, info)) ValueError: Error in inverting [A-sigma*M]: function gmres did not converge (info = 60). ====================================================================== ERROR: test_arpack.test_real_nonsymmetric_modes(False, , 'd', 2, 'LI', None, (0.1+0.1j), , 'r') ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 187, in runTest self.test(*self.arg) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", line 174, in eval_evec eval, evec = eigs_func(ac, k, **kwargs) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 1251, in eigs params.iterate() File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 730, in iterate self.workd[yslice] = self.OPa(self.workd[Bxslice]) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 662, in self.OPa = lambda x: np.real(Minv_matvec(x)) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/interface.py", line 123, in matvec y = self._matvec(x) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 990, in _matvec % (self.ifunc.__name__, info)) ValueError: Error in inverting [A-sigma*M]: function gmres did not converge (info = 60). ====================================================================== ERROR: test_arpack.test_real_nonsymmetric_modes(False, , 'd', 2, 'LI', None, (0.1+0.1j), , 'i') ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 187, in runTest self.test(*self.arg) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", line 174, in eval_evec eval, evec = eigs_func(ac, k, **kwargs) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 1251, in eigs params.iterate() File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 730, in iterate self.workd[yslice] = self.OPa(self.workd[Bxslice]) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 664, in self.OPa = lambda x: np.imag(Minv_matvec(x)) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/interface.py", line 123, in matvec y = self._matvec(x) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 990, in _matvec % (self.ifunc.__name__, info)) ValueError: Error in inverting [A-sigma*M]: function gmres did not converge (info = 60). ====================================================================== ERROR: test_arpack.test_real_nonsymmetric_modes(False, , 'd', 2, 'LM', None, (0.1+0.1j), , 'r') ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 187, in runTest self.test(*self.arg) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", line 168, in eval_evec eval, evec = eigs_func(ac, k, bc, **kwargs) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 1251, in eigs params.iterate() File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 730, in iterate self.workd[yslice] = self.OPa(self.workd[Bxslice]) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 662, in self.OPa = lambda x: np.real(Minv_matvec(x)) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/interface.py", line 123, in matvec y = self._matvec(x) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 990, in _matvec % (self.ifunc.__name__, info)) ValueError: Error in inverting [A-sigma*M]: function gmres did not converge (info = 60). ====================================================================== ERROR: test_arpack.test_real_nonsymmetric_modes(False, , 'd', 2, 'LM', None, (0.1+0.1j), , 'i') ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 187, in runTest self.test(*self.arg) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", line 168, in eval_evec eval, evec = eigs_func(ac, k, bc, **kwargs) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 1251, in eigs params.iterate() File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 730, in iterate self.workd[yslice] = self.OPa(self.workd[Bxslice]) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 664, in self.OPa = lambda x: np.imag(Minv_matvec(x)) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/interface.py", line 123, in matvec y = self._matvec(x) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 990, in _matvec % (self.ifunc.__name__, info)) ValueError: Error in inverting [A-sigma*M]: function gmres did not converge (info = 60). ====================================================================== ERROR: test_arpack.test_real_nonsymmetric_modes(False, , 'd', 2, 'LR', None, (0.1+0.1j), , 'r') ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 187, in runTest self.test(*self.arg) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", line 168, in eval_evec eval, evec = eigs_func(ac, k, bc, **kwargs) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 1251, in eigs params.iterate() File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 723, in iterate self.workd[yslice] = self.OP(self.workd[xslice]) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 672, in self.OP = lambda x: self.OPa(M_matvec(x)) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 662, in self.OPa = lambda x: np.real(Minv_matvec(x)) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/interface.py", line 123, in matvec y = self._matvec(x) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 990, in _matvec % (self.ifunc.__name__, info)) ValueError: Error in inverting [A-sigma*M]: function gmres did not converge (info = 60). ====================================================================== ERROR: test_arpack.test_real_nonsymmetric_modes(False, , 'd', 2, 'LR', None, (0.1+0.1j), , 'i') ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 187, in runTest self.test(*self.arg) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", line 168, in eval_evec eval, evec = eigs_func(ac, k, bc, **kwargs) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 1251, in eigs params.iterate() File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 730, in iterate self.workd[yslice] = self.OPa(self.workd[Bxslice]) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 664, in self.OPa = lambda x: np.imag(Minv_matvec(x)) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/interface.py", line 123, in matvec y = self._matvec(x) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 990, in _matvec % (self.ifunc.__name__, info)) ValueError: Error in inverting [A-sigma*M]: function gmres did not converge (info = 60). ====================================================================== ERROR: test_arpack.test_real_nonsymmetric_modes(False, , 'd', 2, 'LI', None, (0.1+0.1j), , 'r') ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 187, in runTest self.test(*self.arg) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", line 168, in eval_evec eval, evec = eigs_func(ac, k, bc, **kwargs) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 1251, in eigs params.iterate() File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 723, in iterate self.workd[yslice] = self.OP(self.workd[xslice]) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 672, in self.OP = lambda x: self.OPa(M_matvec(x)) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 662, in self.OPa = lambda x: np.real(Minv_matvec(x)) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/interface.py", line 123, in matvec y = self._matvec(x) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 990, in _matvec % (self.ifunc.__name__, info)) ValueError: Error in inverting [A-sigma*M]: function gmres did not converge (info = 60). ====================================================================== ERROR: test_arpack.test_real_nonsymmetric_modes(False, , 'd', 2, 'LI', None, (0.1+0.1j), , 'i') ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 187, in runTest self.test(*self.arg) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", line 168, in eval_evec eval, evec = eigs_func(ac, k, bc, **kwargs) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 1251, in eigs params.iterate() File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 730, in iterate self.workd[yslice] = self.OPa(self.workd[Bxslice]) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 664, in self.OPa = lambda x: np.imag(Minv_matvec(x)) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/interface.py", line 123, in matvec y = self._matvec(x) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 990, in _matvec % (self.ifunc.__name__, info)) ValueError: Error in inverting [A-sigma*M]: function gmres did not converge (info = 60). ====================================================================== ERROR: test_arpack.test_complex_nonsymmetric_modes(False, , 'D', 2, 'LM', None, (0.1+0.1j), ) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 187, in runTest self.test(*self.arg) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", line 174, in eval_evec eval, evec = eigs_func(ac, k, **kwargs) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 1251, in eigs params.iterate() File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 730, in iterate self.workd[yslice] = self.OPa(self.workd[Bxslice]) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/interface.py", line 123, in matvec y = self._matvec(x) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 990, in _matvec % (self.ifunc.__name__, info)) ValueError: Error in inverting [A-sigma*M]: function gmres did not converge (info = 60). ====================================================================== ERROR: test_arpack.test_complex_nonsymmetric_modes(False, , 'D', 2, 'LM', None, 0.1, ) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 187, in runTest self.test(*self.arg) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", line 174, in eval_evec eval, evec = eigs_func(ac, k, **kwargs) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 1251, in eigs params.iterate() File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 730, in iterate self.workd[yslice] = self.OPa(self.workd[Bxslice]) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/interface.py", line 123, in matvec y = self._matvec(x) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 990, in _matvec % (self.ifunc.__name__, info)) ValueError: Error in inverting [A-sigma*M]: function gmres did not converge (info = 60). ====================================================================== ERROR: test_arpack.test_complex_nonsymmetric_modes(False, , 'D', 2, 'LR', None, (0.1+0.1j), ) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 187, in runTest self.test(*self.arg) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", line 174, in eval_evec eval, evec = eigs_func(ac, k, **kwargs) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 1251, in eigs params.iterate() File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 730, in iterate self.workd[yslice] = self.OPa(self.workd[Bxslice]) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/interface.py", line 123, in matvec y = self._matvec(x) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 990, in _matvec % (self.ifunc.__name__, info)) ValueError: Error in inverting [A-sigma*M]: function gmres did not converge (info = 60). ====================================================================== ERROR: test_arpack.test_complex_nonsymmetric_modes(False, , 'D', 2, 'LR', None, 0.1, ) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 187, in runTest self.test(*self.arg) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", line 174, in eval_evec eval, evec = eigs_func(ac, k, **kwargs) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 1251, in eigs params.iterate() File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 730, in iterate self.workd[yslice] = self.OPa(self.workd[Bxslice]) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/interface.py", line 123, in matvec y = self._matvec(x) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 990, in _matvec % (self.ifunc.__name__, info)) ValueError: Error in inverting [A-sigma*M]: function gmres did not converge (info = 60). ====================================================================== ERROR: test_arpack.test_complex_nonsymmetric_modes(False, , 'D', 2, 'LI', None, (0.1+0.1j), ) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 187, in runTest self.test(*self.arg) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", line 174, in eval_evec eval, evec = eigs_func(ac, k, **kwargs) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 1251, in eigs params.iterate() File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 730, in iterate self.workd[yslice] = self.OPa(self.workd[Bxslice]) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/interface.py", line 123, in matvec y = self._matvec(x) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 990, in _matvec % (self.ifunc.__name__, info)) ValueError: Error in inverting [A-sigma*M]: function gmres did not converge (info = 60). ====================================================================== ERROR: test_arpack.test_complex_nonsymmetric_modes(False, , 'D', 2, 'LI', None, 0.1, ) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 187, in runTest self.test(*self.arg) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", line 174, in eval_evec eval, evec = eigs_func(ac, k, **kwargs) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 1251, in eigs params.iterate() File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 730, in iterate self.workd[yslice] = self.OPa(self.workd[Bxslice]) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/interface.py", line 123, in matvec y = self._matvec(x) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 990, in _matvec % (self.ifunc.__name__, info)) ValueError: Error in inverting [A-sigma*M]: function gmres did not converge (info = 60). ====================================================================== ERROR: test_arpack.test_complex_nonsymmetric_modes(False, , 'D', 2, 'LM', None, None, ) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 187, in runTest self.test(*self.arg) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", line 168, in eval_evec eval, evec = eigs_func(ac, k, bc, **kwargs) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 1251, in eigs params.iterate() File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 723, in iterate self.workd[yslice] = self.OP(self.workd[xslice]) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 641, in self.OP = lambda x: Minv_matvec(matvec(x)) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/interface.py", line 123, in matvec y = self._matvec(x) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 945, in _matvec % (self.ifunc.__name__, info)) ValueError: Error in inverting M: function gmres did not converge (info = 60). ====================================================================== ERROR: test_arpack.test_complex_nonsymmetric_modes(False, , 'D', 2, 'LM', None, (0.1+0.1j), ) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 187, in runTest self.test(*self.arg) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", line 168, in eval_evec eval, evec = eigs_func(ac, k, bc, **kwargs) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 1251, in eigs params.iterate() File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 730, in iterate self.workd[yslice] = self.OPa(self.workd[Bxslice]) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/interface.py", line 123, in matvec y = self._matvec(x) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 990, in _matvec % (self.ifunc.__name__, info)) ValueError: Error in inverting [A-sigma*M]: function gmres did not converge (info = 60). ====================================================================== ERROR: test_arpack.test_complex_nonsymmetric_modes(False, , 'D', 2, 'LM', None, 0.1, ) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 187, in runTest self.test(*self.arg) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", line 168, in eval_evec eval, evec = eigs_func(ac, k, bc, **kwargs) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 1251, in eigs params.iterate() File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 730, in iterate self.workd[yslice] = self.OPa(self.workd[Bxslice]) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/interface.py", line 123, in matvec y = self._matvec(x) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 990, in _matvec % (self.ifunc.__name__, info)) ValueError: Error in inverting [A-sigma*M]: function gmres did not converge (info = 60). ====================================================================== ERROR: test_arpack.test_complex_nonsymmetric_modes(False, , 'D', 2, 'LR', None, None, ) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 187, in runTest self.test(*self.arg) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", line 168, in eval_evec eval, evec = eigs_func(ac, k, bc, **kwargs) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 1251, in eigs params.iterate() File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 723, in iterate self.workd[yslice] = self.OP(self.workd[xslice]) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 641, in self.OP = lambda x: Minv_matvec(matvec(x)) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/interface.py", line 123, in matvec y = self._matvec(x) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 945, in _matvec % (self.ifunc.__name__, info)) ValueError: Error in inverting M: function gmres did not converge (info = 60). ====================================================================== ERROR: test_arpack.test_complex_nonsymmetric_modes(False, , 'D', 2, 'LR', None, (0.1+0.1j), ) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 187, in runTest self.test(*self.arg) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", line 168, in eval_evec eval, evec = eigs_func(ac, k, bc, **kwargs) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 1251, in eigs params.iterate() File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 730, in iterate self.workd[yslice] = self.OPa(self.workd[Bxslice]) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/interface.py", line 123, in matvec y = self._matvec(x) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 990, in _matvec % (self.ifunc.__name__, info)) ValueError: Error in inverting [A-sigma*M]: function gmres did not converge (info = 60). ====================================================================== ERROR: test_arpack.test_complex_nonsymmetric_modes(False, , 'D', 2, 'LR', None, 0.1, ) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 187, in runTest self.test(*self.arg) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", line 168, in eval_evec eval, evec = eigs_func(ac, k, bc, **kwargs) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 1251, in eigs params.iterate() File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 730, in iterate self.workd[yslice] = self.OPa(self.workd[Bxslice]) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/interface.py", line 123, in matvec y = self._matvec(x) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 990, in _matvec % (self.ifunc.__name__, info)) ValueError: Error in inverting [A-sigma*M]: function gmres did not converge (info = 60). ====================================================================== ERROR: test_arpack.test_complex_nonsymmetric_modes(False, , 'D', 2, 'LI', None, None, ) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 187, in runTest self.test(*self.arg) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", line 168, in eval_evec eval, evec = eigs_func(ac, k, bc, **kwargs) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 1251, in eigs params.iterate() File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 723, in iterate self.workd[yslice] = self.OP(self.workd[xslice]) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 641, in self.OP = lambda x: Minv_matvec(matvec(x)) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/interface.py", line 123, in matvec y = self._matvec(x) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 945, in _matvec % (self.ifunc.__name__, info)) ValueError: Error in inverting M: function gmres did not converge (info = 60). ====================================================================== ERROR: test_arpack.test_complex_nonsymmetric_modes(False, , 'D', 2, 'LI', None, (0.1+0.1j), ) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 187, in runTest self.test(*self.arg) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", line 168, in eval_evec eval, evec = eigs_func(ac, k, bc, **kwargs) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 1251, in eigs params.iterate() File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 730, in iterate self.workd[yslice] = self.OPa(self.workd[Bxslice]) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/interface.py", line 123, in matvec y = self._matvec(x) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 990, in _matvec % (self.ifunc.__name__, info)) ValueError: Error in inverting [A-sigma*M]: function gmres did not converge (info = 60). ====================================================================== ERROR: test_arpack.test_complex_nonsymmetric_modes(False, , 'D', 2, 'LI', None, 0.1, ) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 187, in runTest self.test(*self.arg) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", line 168, in eval_evec eval, evec = eigs_func(ac, k, bc, **kwargs) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 1251, in eigs params.iterate() File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 730, in iterate self.workd[yslice] = self.OPa(self.workd[Bxslice]) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/interface.py", line 123, in matvec y = self._matvec(x) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 990, in _matvec % (self.ifunc.__name__, info)) ValueError: Error in inverting [A-sigma*M]: function gmres did not converge (info = 60). ====================================================================== ERROR: test_arpack.test_complex_nonsymmetric_modes(False, , 'F', 2, 'LM', None, None, ) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 187, in runTest self.test(*self.arg) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", line 168, in eval_evec eval, evec = eigs_func(ac, k, bc, **kwargs) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 1251, in eigs params.iterate() File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 723, in iterate self.workd[yslice] = self.OP(self.workd[xslice]) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 641, in self.OP = lambda x: Minv_matvec(matvec(x)) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/interface.py", line 123, in matvec y = self._matvec(x) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 945, in _matvec % (self.ifunc.__name__, info)) ValueError: Error in inverting M: function gmres did not converge (info = 60). ====================================================================== ERROR: test_arpack.test_complex_nonsymmetric_modes(False, , 'F', 2, 'LR', None, None, ) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 187, in runTest self.test(*self.arg) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", line 168, in eval_evec eval, evec = eigs_func(ac, k, bc, **kwargs) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 1251, in eigs params.iterate() File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 723, in iterate self.workd[yslice] = self.OP(self.workd[xslice]) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 641, in self.OP = lambda x: Minv_matvec(matvec(x)) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/interface.py", line 123, in matvec y = self._matvec(x) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 945, in _matvec % (self.ifunc.__name__, info)) ValueError: Error in inverting M: function gmres did not converge (info = 60). ====================================================================== ERROR: test_arpack.test_complex_nonsymmetric_modes(False, , 'F', 2, 'LI', None, None, ) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 187, in runTest self.test(*self.arg) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", line 168, in eval_evec eval, evec = eigs_func(ac, k, bc, **kwargs) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 1251, in eigs params.iterate() File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 723, in iterate self.workd[yslice] = self.OP(self.workd[xslice]) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 641, in self.OP = lambda x: Minv_matvec(matvec(x)) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/interface.py", line 123, in matvec y = self._matvec(x) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 945, in _matvec % (self.ifunc.__name__, info)) ValueError: Error in inverting M: function gmres did not converge (info = 60). ====================================================================== FAIL: test_lu (test_decomp.TestLUSolve) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/bvr/Programs/scipy/scipy/linalg/tests/test_decomp.py", line 732, in test_lu assert_array_equal(x1,x2) File "/home/bvr/Programs/numpy/numpy/testing/utils.py", line 706, in assert_array_equal verbose=verbose, header='Arrays are not equal') File "/home/bvr/Programs/numpy/numpy/testing/utils.py", line 635, in assert_array_compare raise AssertionError(msg) AssertionError: Arrays are not equal (mismatch 90.0%) x: array([-0.36278861, 0.75920432, 0.19844271, 0.65479681, 0.40510514, 0.79604687, -1.05344321, -0.25597019, -0.34997286, 0.07080989]) y: array([-0.36278861, 0.75920432, 0.19844271, 0.65479681, 0.40510514, 0.79604687, -1.05344321, -0.25597019, -0.34997286, 0.07080989]) ====================================================================== FAIL: test_arpack.test_symmetric_modes(True, , 'f', 2, 'SM', None, 0.5, , None, 'normal') ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 187, in runTest self.test(*self.arg) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", line 187, in eval_evec err_msg=err) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", line 74, in assert_allclose_cc assert_allclose(actual, conj(desired), **kw) File "/home/bvr/Programs/numpy/numpy/testing/utils.py", line 1167, in assert_allclose verbose=verbose, header=header) File "/home/bvr/Programs/numpy/numpy/testing/utils.py", line 635, in assert_array_compare raise AssertionError(msg) AssertionError: Not equal to tolerance rtol=0.000238419, atol=0.000238419 error for eigsh:general, typ=f, which=SM, sigma=0.5, mattype=aslinearoperator, OPpart=None, mode=normal (mismatch 100.0%) x: array([ 34.53577423, 5.23088455], dtype='float32') y: array([ 34.52712250-0.j, 5.23087454-0.j], dtype='complex64') ====================================================================== FAIL: test_arpack.test_hermitian_modes(True, , 'F', 2, 'LM', None, 0.5, ) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 187, in runTest self.test(*self.arg) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", line 187, in eval_evec err_msg=err) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", line 74, in assert_allclose_cc assert_allclose(actual, conj(desired), **kw) File "/home/bvr/Programs/numpy/numpy/testing/utils.py", line 1167, in assert_allclose verbose=verbose, header=header) File "/home/bvr/Programs/numpy/numpy/testing/utils.py", line 635, in assert_array_compare raise AssertionError(msg) AssertionError: Not equal to tolerance rtol=0.000238419, atol=0.000238419 error for eigsh:standard, typ=F, which=LM, sigma=0.5, mattype=aslinearoperator, OPpart=None, mode=normal (mismatch 100.0%) x: array([ 0.30537546, 0.51262444], dtype='float32') y: array([ 0.11075071-0.j, 0.52524889-0.j], dtype='complex64') ====================================================================== FAIL: test_arpack.test_hermitian_modes(True, , 'F', 2, 'SM', None, 0.5, ) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 187, in runTest self.test(*self.arg) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", line 187, in eval_evec err_msg=err) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", line 74, in assert_allclose_cc assert_allclose(actual, conj(desired), **kw) File "/home/bvr/Programs/numpy/numpy/testing/utils.py", line 1167, in assert_allclose verbose=verbose, header=header) File "/home/bvr/Programs/numpy/numpy/testing/utils.py", line 635, in assert_array_compare raise AssertionError(msg) AssertionError: Not equal to tolerance rtol=0.000238419, atol=0.000238419 error for eigsh:standard, typ=F, which=SM, sigma=0.5, mattype=aslinearoperator, OPpart=None, mode=normal (mismatch 100.0%) x: array([ 10.73401356, 1.46641302], dtype='float32') y: array([ 20.96805191-0.j, 2.43282652-0.j], dtype='complex64') ====================================================================== FAIL: test_arpack.test_hermitian_modes(True, , 'F', 2, 'LA', None, 0.5, ) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 187, in runTest self.test(*self.arg) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", line 187, in eval_evec err_msg=err) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", line 74, in assert_allclose_cc assert_allclose(actual, conj(desired), **kw) File "/home/bvr/Programs/numpy/numpy/testing/utils.py", line 1167, in assert_allclose verbose=verbose, header=header) File "/home/bvr/Programs/numpy/numpy/testing/utils.py", line 635, in assert_array_compare raise AssertionError(msg) AssertionError: Not equal to tolerance rtol=0.000238419, atol=0.000238419 error for eigsh:standard, typ=F, which=LA, sigma=0.5, mattype=aslinearoperator, OPpart=None, mode=normal (mismatch 100.0%) x: array([ 1.20955896, 0.51262444], dtype='float32') y: array([ 1.91911745-0.j, 0.52524889-0.j], dtype='complex64') ====================================================================== FAIL: test_arpack.test_hermitian_modes(True, , 'F', 2, 'SA', None, 0.5, ) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 187, in runTest self.test(*self.arg) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", line 187, in eval_evec err_msg=err) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", line 74, in assert_allclose_cc assert_allclose(actual, conj(desired), **kw) File "/home/bvr/Programs/numpy/numpy/testing/utils.py", line 1167, in assert_allclose verbose=verbose, header=header) File "/home/bvr/Programs/numpy/numpy/testing/utils.py", line 635, in assert_array_compare raise AssertionError(msg) AssertionError: Not equal to tolerance rtol=0.000238419, atol=0.000238419 error for eigsh:standard, typ=F, which=SA, sigma=0.5, mattype=aslinearoperator, OPpart=None, mode=normal (mismatch 100.0%) x: array([ 0.30537534, 0.25563145], dtype='float32') y: array([ 0.11075071-0.j, 0.01126307-0.j], dtype='complex64') ====================================================================== FAIL: test_arpack.test_hermitian_modes(True, , 'F', 2, 'LM', None, 0.5, ) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 187, in runTest self.test(*self.arg) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", line 187, in eval_evec err_msg=err) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", line 74, in assert_allclose_cc assert_allclose(actual, conj(desired), **kw) File "/home/bvr/Programs/numpy/numpy/testing/utils.py", line 1167, in assert_allclose verbose=verbose, header=header) File "/home/bvr/Programs/numpy/numpy/testing/utils.py", line 635, in assert_array_compare raise AssertionError(msg) AssertionError: Not equal to tolerance rtol=0.000238419, atol=0.000238419 error for eigsh:general, typ=F, which=LM, sigma=0.5, mattype=aslinearoperator, OPpart=None, mode=normal (mismatch 100.0%) x: array([ 0.18244773, 0.23630294], dtype='float32') y: array([ 0.02430210-0.j, 0.19741854-0.j], dtype='complex64') ====================================================================== FAIL: test_arpack.test_hermitian_modes(True, , 'F', 2, 'SM', None, 0.5, ) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 187, in runTest self.test(*self.arg) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", line 187, in eval_evec err_msg=err) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", line 74, in assert_allclose_cc assert_allclose(actual, conj(desired), **kw) File "/home/bvr/Programs/numpy/numpy/testing/utils.py", line 1167, in assert_allclose verbose=verbose, header=header) File "/home/bvr/Programs/numpy/numpy/testing/utils.py", line 635, in assert_array_compare raise AssertionError(msg) AssertionError: Not equal to tolerance rtol=0.000238419, atol=0.000238419 error for eigsh:general, typ=F, which=SM, sigma=0.5, mattype=aslinearoperator, OPpart=None, mode=normal (mismatch 100.0%) x: array([ 15.09472656, 3.75197268], dtype='float32') y: array([ 67.63611603-0.j, 8.11402225-0.j], dtype='complex64') ====================================================================== FAIL: test_arpack.test_hermitian_modes(True, , 'F', 2, 'LA', None, 0.5, ) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 187, in runTest self.test(*self.arg) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", line 187, in eval_evec err_msg=err) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", line 74, in assert_allclose_cc assert_allclose(actual, conj(desired), **kw) File "/home/bvr/Programs/numpy/numpy/testing/utils.py", line 1167, in assert_allclose verbose=verbose, header=header) File "/home/bvr/Programs/numpy/numpy/testing/utils.py", line 635, in assert_array_compare raise AssertionError(msg) AssertionError: Not equal to tolerance rtol=0.000238419, atol=0.000238419 error for eigsh:general, typ=F, which=LA, sigma=0.5, mattype=aslinearoperator, OPpart=None, mode=normal (mismatch 100.0%) x: array([ 3.67262006, 1.05869079], dtype='float32') y: array([ 3.80941606-0.j, 1.09445751-0.j], dtype='complex64') ====================================================================== FAIL: test_arpack.test_hermitian_modes(True, , 'F', 2, 'SA', None, 0.5, ) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 187, in runTest self.test(*self.arg) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", line 187, in eval_evec err_msg=err) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", line 74, in assert_allclose_cc assert_allclose(actual, conj(desired), **kw) File "/home/bvr/Programs/numpy/numpy/testing/utils.py", line 1167, in assert_allclose verbose=verbose, header=header) File "/home/bvr/Programs/numpy/numpy/testing/utils.py", line 635, in assert_array_compare raise AssertionError(msg) AssertionError: Not equal to tolerance rtol=0.000238419, atol=0.000238419 error for eigsh:general, typ=F, which=SA, sigma=0.5, mattype=aslinearoperator, OPpart=None, mode=normal (mismatch 100.0%) x: array([ 0.2208195 , 0.09195787], dtype='float32') y: array([ 0.19741854-0.j, 0.02430210-0.j], dtype='complex64') ====================================================================== FAIL: test_arpack.test_real_nonsymmetric_modes(False, , 'f', 2, 'LM', None, (0.1+0.1j), , 'r') ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 187, in runTest self.test(*self.arg) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", line 187, in eval_evec err_msg=err) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", line 74, in assert_allclose_cc assert_allclose(actual, conj(desired), **kw) File "/home/bvr/Programs/numpy/numpy/testing/utils.py", line 1167, in assert_allclose verbose=verbose, header=header) File "/home/bvr/Programs/numpy/numpy/testing/utils.py", line 635, in assert_array_compare raise AssertionError(msg) AssertionError: Not equal to tolerance rtol=0.000238419, atol=0.000238419 error for eigs:standard, typ=f, which=LM, sigma=(0.1+0.1j), mattype=aslinearoperator, OPpart=r, mode=normal (mismatch 100.0%) x: array([ 0.31237626-0.43954465j, 0.31237626+0.43954465j], dtype='complex64') y: array([ 0.42248264-0.j, 0.13942589-0.j], dtype='complex64') ====================================================================== FAIL: test_arpack.test_real_nonsymmetric_modes(False, , 'f', 2, 'LR', None, (0.1+0.1j), , 'r') ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 187, in runTest self.test(*self.arg) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", line 187, in eval_evec err_msg=err) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", line 74, in assert_allclose_cc assert_allclose(actual, conj(desired), **kw) File "/home/bvr/Programs/numpy/numpy/testing/utils.py", line 1167, in assert_allclose verbose=verbose, header=header) File "/home/bvr/Programs/numpy/numpy/testing/utils.py", line 635, in assert_array_compare raise AssertionError(msg) AssertionError: Not equal to tolerance rtol=0.000238419, atol=0.000238419 error for eigs:standard, typ=f, which=LR, sigma=(0.1+0.1j), mattype=aslinearoperator, OPpart=r, mode=normal (mismatch 100.0%) x: array([ 0.31237626+0.4395445j, 0.42248264+0.j ], dtype='complex64') y: array([ 0.42248264-0.j, 0.13942589-0.j], dtype='complex64') ====================================================================== FAIL: test_arpack.test_real_nonsymmetric_modes(False, , 'f', 2, 'LM', None, (0.1+0.1j), , 'r') ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 187, in runTest self.test(*self.arg) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", line 187, in eval_evec err_msg=err) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", line 74, in assert_allclose_cc assert_allclose(actual, conj(desired), **kw) File "/home/bvr/Programs/numpy/numpy/testing/utils.py", line 1167, in assert_allclose verbose=verbose, header=header) File "/home/bvr/Programs/numpy/numpy/testing/utils.py", line 635, in assert_array_compare raise AssertionError(msg) AssertionError: Not equal to tolerance rtol=0.000238419, atol=0.000238419 error for eigs:general, typ=f, which=LM, sigma=(0.1+0.1j), mattype=aslinearoperator, OPpart=r, mode=normal (mismatch 100.0%) x: array([ 0.29470414+0.j, 0.23727453+0.j], dtype='complex64') y: array([ 0.27614349-0.07374702j, 0.27614349+0.07374702j], dtype='complex64') ====================================================================== FAIL: test_arpack.test_real_nonsymmetric_modes(False, , 'f', 2, 'LM', None, (0.1+0.1j), , 'i') ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 187, in runTest self.test(*self.arg) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", line 187, in eval_evec err_msg=err) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", line 74, in assert_allclose_cc assert_allclose(actual, conj(desired), **kw) File "/home/bvr/Programs/numpy/numpy/testing/utils.py", line 1167, in assert_allclose verbose=verbose, header=header) File "/home/bvr/Programs/numpy/numpy/testing/utils.py", line 635, in assert_array_compare raise AssertionError(msg) AssertionError: Not equal to tolerance rtol=0.000238419, atol=0.000238419 error for eigs:general, typ=f, which=LM, sigma=(0.1+0.1j), mattype=aslinearoperator, OPpart=i, mode=normal (mismatch 100.0%) x: array([ 0.26865238-0.09855781j, 0.26865238+0.09855781j], dtype='complex64') y: array([ 0.27614349-0.07374702j, 0.27614349+0.07374702j], dtype='complex64') ====================================================================== FAIL: test_arpack.test_real_nonsymmetric_modes(False, , 'f', 2, 'LR', None, (0.1+0.1j), , 'r') ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 187, in runTest self.test(*self.arg) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", line 187, in eval_evec err_msg=err) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", line 74, in assert_allclose_cc assert_allclose(actual, conj(desired), **kw) File "/home/bvr/Programs/numpy/numpy/testing/utils.py", line 1167, in assert_allclose verbose=verbose, header=header) File "/home/bvr/Programs/numpy/numpy/testing/utils.py", line 635, in assert_array_compare raise AssertionError(msg) AssertionError: Not equal to tolerance rtol=0.000238419, atol=0.000238419 error for eigs:general, typ=f, which=LR, sigma=(0.1+0.1j), mattype=aslinearoperator, OPpart=r, mode=normal (mismatch 100.0%) x: array([ 0.29654661+0.j, 0.21621886+0.j], dtype='complex64') y: array([ 0.27614349-0.07374702j, 0.27614349+0.07374702j], dtype='complex64') ====================================================================== FAIL: test_arpack.test_real_nonsymmetric_modes(False, , 'f', 2, 'LR', None, (0.1+0.1j), , 'i') ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 187, in runTest self.test(*self.arg) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", line 187, in eval_evec err_msg=err) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", line 74, in assert_allclose_cc assert_allclose(actual, conj(desired), **kw) File "/home/bvr/Programs/numpy/numpy/testing/utils.py", line 1167, in assert_allclose verbose=verbose, header=header) File "/home/bvr/Programs/numpy/numpy/testing/utils.py", line 635, in assert_array_compare raise AssertionError(msg) AssertionError: Not equal to tolerance rtol=0.000238419, atol=0.000238419 error for eigs:general, typ=f, which=LR, sigma=(0.1+0.1j), mattype=aslinearoperator, OPpart=i, mode=normal (mismatch 100.0%) x: array([ 0.23599033-0.0561026j, 0.23599033+0.0561026j], dtype='complex64') y: array([ 0.27614349-0.07374702j, 0.27614349+0.07374702j], dtype='complex64') ====================================================================== FAIL: test_arpack.test_real_nonsymmetric_modes(False, , 'f', 2, 'LI', None, (0.1+0.1j), , 'r') ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 187, in runTest self.test(*self.arg) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", line 187, in eval_evec err_msg=err) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", line 74, in assert_allclose_cc assert_allclose(actual, conj(desired), **kw) File "/home/bvr/Programs/numpy/numpy/testing/utils.py", line 1167, in assert_allclose verbose=verbose, header=header) File "/home/bvr/Programs/numpy/numpy/testing/utils.py", line 635, in assert_array_compare raise AssertionError(msg) AssertionError: Not equal to tolerance rtol=0.000238419, atol=0.000238419 error for eigs:general, typ=f, which=LI, sigma=(0.1+0.1j), mattype=aslinearoperator, OPpart=r, mode=normal (mismatch 100.0%) x: array([ 0.27367961-0.0672823j, 0.27367961+0.0672823j], dtype='complex64') y: array([ 0.27614349-0.07374702j, 0.27614349+0.07374702j], dtype='complex64') ====================================================================== FAIL: test_arpack.test_real_nonsymmetric_modes(False, , 'f', 2, 'LI', None, (0.1+0.1j), , 'i') ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 187, in runTest self.test(*self.arg) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", line 187, in eval_evec err_msg=err) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", line 74, in assert_allclose_cc assert_allclose(actual, conj(desired), **kw) File "/home/bvr/Programs/numpy/numpy/testing/utils.py", line 1167, in assert_allclose verbose=verbose, header=header) File "/home/bvr/Programs/numpy/numpy/testing/utils.py", line 635, in assert_array_compare raise AssertionError(msg) AssertionError: Not equal to tolerance rtol=0.000238419, atol=0.000238419 error for eigs:general, typ=f, which=LI, sigma=(0.1+0.1j), mattype=aslinearoperator, OPpart=i, mode=normal (mismatch 100.0%) x: array([ 0.2273801-0.06078465j, 0.2273801+0.06078465j], dtype='complex64') y: array([ 0.27614349-0.07374702j, 0.27614349+0.07374702j], dtype='complex64') ====================================================================== FAIL: test_arpack.test_complex_nonsymmetric_modes(False, , 'F', 2, 'LM', None, (0.1+0.1j), ) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 187, in runTest self.test(*self.arg) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", line 187, in eval_evec err_msg=err) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", line 74, in assert_allclose_cc assert_allclose(actual, conj(desired), **kw) File "/home/bvr/Programs/numpy/numpy/testing/utils.py", line 1167, in assert_allclose verbose=verbose, header=header) File "/home/bvr/Programs/numpy/numpy/testing/utils.py", line 635, in assert_array_compare raise AssertionError(msg) AssertionError: Not equal to tolerance rtol=0.000238419, atol=0.000238419 error for eigs:standard, typ=F, which=LM, sigma=(0.1+0.1j), mattype=aslinearoperator, OPpart=None, mode=normal (mismatch 100.0%) x: array([ 0.18700075-0.16663066j, -0.16835144+0.07243362j], dtype='complex64') y: array([ 0.45363146+0.07962994j, -0.14078493+0.19591773j], dtype='complex64') ====================================================================== FAIL: test_arpack.test_complex_nonsymmetric_modes(False, , 'F', 2, 'LM', None, 0.1, ) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 187, in runTest self.test(*self.arg) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", line 187, in eval_evec err_msg=err) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", line 74, in assert_allclose_cc assert_allclose(actual, conj(desired), **kw) File "/home/bvr/Programs/numpy/numpy/testing/utils.py", line 1167, in assert_allclose verbose=verbose, header=header) File "/home/bvr/Programs/numpy/numpy/testing/utils.py", line 635, in assert_array_compare raise AssertionError(msg) AssertionError: Not equal to tolerance rtol=0.000238419, atol=0.000238419 error for eigs:standard, typ=F, which=LM, sigma=0.1, mattype=aslinearoperator, OPpart=None, mode=normal (mismatch 100.0%) x: array([ 0.23700061-0.21663065j, -0.11835136+0.02243357j], dtype='complex64') y: array([ 0.45363146+0.07962994j, -0.14078493+0.19591773j], dtype='complex64') ====================================================================== FAIL: test_arpack.test_complex_nonsymmetric_modes(False, , 'F', 2, 'LR', None, (0.1+0.1j), ) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 187, in runTest self.test(*self.arg) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", line 187, in eval_evec err_msg=err) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", line 74, in assert_allclose_cc assert_allclose(actual, conj(desired), **kw) File "/home/bvr/Programs/numpy/numpy/testing/utils.py", line 1167, in assert_allclose verbose=verbose, header=header) File "/home/bvr/Programs/numpy/numpy/testing/utils.py", line 635, in assert_array_compare raise AssertionError(msg) AssertionError: Not equal to tolerance rtol=0.000238419, atol=0.000238419 error for eigs:standard, typ=F, which=LR, sigma=(0.1+0.1j), mattype=aslinearoperator, OPpart=None, mode=normal (mismatch 100.0%) x: array([ 0.18700084-0.16663066j, 0.30520070+0.32319868j], dtype='complex64') y: array([ 0.75295496+0.50669056j, 0.45363146+0.07962994j], dtype='complex64') ====================================================================== FAIL: test_arpack.test_complex_nonsymmetric_modes(False, , 'F', 2, 'LR', None, 0.1, ) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 187, in runTest self.test(*self.arg) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", line 187, in eval_evec err_msg=err) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", line 74, in assert_allclose_cc assert_allclose(actual, conj(desired), **kw) File "/home/bvr/Programs/numpy/numpy/testing/utils.py", line 1167, in assert_allclose verbose=verbose, header=header) File "/home/bvr/Programs/numpy/numpy/testing/utils.py", line 635, in assert_array_compare raise AssertionError(msg) AssertionError: Not equal to tolerance rtol=0.000238419, atol=0.000238419 error for eigs:standard, typ=F, which=LR, sigma=0.1, mattype=aslinearoperator, OPpart=None, mode=normal (mismatch 100.0%) x: array([ 0.35520068+0.27319857j, 0.23700085-0.21663088j], dtype='complex64') y: array([ 0.75295496+0.50669056j, 0.45363146+0.07962994j], dtype='complex64') ====================================================================== FAIL: test_arpack.test_complex_nonsymmetric_modes(False, , 'F', 2, 'LI', None, (0.1+0.1j), ) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 187, in runTest self.test(*self.arg) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", line 187, in eval_evec err_msg=err) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", line 74, in assert_allclose_cc assert_allclose(actual, conj(desired), **kw) File "/home/bvr/Programs/numpy/numpy/testing/utils.py", line 1167, in assert_allclose verbose=verbose, header=header) File "/home/bvr/Programs/numpy/numpy/testing/utils.py", line 635, in assert_array_compare raise AssertionError(msg) AssertionError: Not equal to tolerance rtol=0.000238419, atol=0.000238419 error for eigs:standard, typ=F, which=LI, sigma=(0.1+0.1j), mattype=aslinearoperator, OPpart=None, mode=normal (mismatch 100.0%) x: array([ 0.12313220-0.52982181j, 0.18700068-0.16663036j], dtype='complex64') y: array([ 0.45363146+0.07962994j, -0.14078493+0.19591773j], dtype='complex64') ====================================================================== FAIL: test_arpack.test_complex_nonsymmetric_modes(False, , 'F', 2, 'LI', None, 0.1, ) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 187, in runTest self.test(*self.arg) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", line 187, in eval_evec err_msg=err) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", line 74, in assert_allclose_cc assert_allclose(actual, conj(desired), **kw) File "/home/bvr/Programs/numpy/numpy/testing/utils.py", line 1167, in assert_allclose verbose=verbose, header=header) File "/home/bvr/Programs/numpy/numpy/testing/utils.py", line 635, in assert_array_compare raise AssertionError(msg) AssertionError: Not equal to tolerance rtol=0.000238419, atol=0.000238419 error for eigs:standard, typ=F, which=LI, sigma=0.1, mattype=aslinearoperator, OPpart=None, mode=normal (mismatch 100.0%) x: array([ 0.17313209-0.5798226j , 0.23700070-0.21663059j], dtype='complex64') y: array([ 0.75295496+0.50669056j, -0.14078493+0.19591773j], dtype='complex64') ====================================================================== FAIL: test_arpack.test_complex_nonsymmetric_modes(False, , 'F', 2, 'LM', None, (0.1+0.1j), ) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 187, in runTest self.test(*self.arg) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", line 187, in eval_evec err_msg=err) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", line 74, in assert_allclose_cc assert_allclose(actual, conj(desired), **kw) File "/home/bvr/Programs/numpy/numpy/testing/utils.py", line 1167, in assert_allclose verbose=verbose, header=header) File "/home/bvr/Programs/numpy/numpy/testing/utils.py", line 635, in assert_array_compare raise AssertionError(msg) AssertionError: Not equal to tolerance rtol=0.000238419, atol=0.000238419 error for eigs:general, typ=F, which=LM, sigma=(0.1+0.1j), mattype=aslinearoperator, OPpart=None, mode=normal (mismatch 100.0%) x: array([-0.20178697-0.18621147j, 0.31924310+0.09681031j], dtype='complex64') y: array([-0.09499434+0.27649775j, 0.32682878-0.12782857j], dtype='complex64') ====================================================================== FAIL: test_arpack.test_complex_nonsymmetric_modes(False, , 'F', 2, 'LM', None, 0.1, ) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 187, in runTest self.test(*self.arg) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", line 187, in eval_evec err_msg=err) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", line 74, in assert_allclose_cc assert_allclose(actual, conj(desired), **kw) File "/home/bvr/Programs/numpy/numpy/testing/utils.py", line 1167, in assert_allclose verbose=verbose, header=header) File "/home/bvr/Programs/numpy/numpy/testing/utils.py", line 635, in assert_array_compare raise AssertionError(msg) AssertionError: Not equal to tolerance rtol=0.000238419, atol=0.000238419 error for eigs:general, typ=F, which=LM, sigma=0.1, mattype=aslinearoperator, OPpart=None, mode=normal (mismatch 100.0%) x: array([-0.13368231-0.21672826j, 0.33619353+0.07594832j], dtype='complex64') y: array([-0.09499434+0.27649775j, 0.32682878-0.12782857j], dtype='complex64') ====================================================================== FAIL: test_arpack.test_complex_nonsymmetric_modes(False, , 'F', 2, 'LR', None, (0.1+0.1j), ) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 187, in runTest self.test(*self.arg) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", line 187, in eval_evec err_msg=err) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", line 74, in assert_allclose_cc assert_allclose(actual, conj(desired), **kw) File "/home/bvr/Programs/numpy/numpy/testing/utils.py", line 1167, in assert_allclose verbose=verbose, header=header) File "/home/bvr/Programs/numpy/numpy/testing/utils.py", line 635, in assert_array_compare raise AssertionError(msg) AssertionError: Not equal to tolerance rtol=0.000238419, atol=0.000238419 error for eigs:general, typ=F, which=LR, sigma=(0.1+0.1j), mattype=aslinearoperator, OPpart=None, mode=normal (mismatch 100.0%) x: array([ 0.46869966+0.67924678j, 0.31671917+0.08711412j], dtype='complex64') y: array([ 1.26434827+0.579292j , 0.32682878-0.12782857j], dtype='complex64') ====================================================================== FAIL: test_arpack.test_complex_nonsymmetric_modes(False, , 'F', 2, 'LR', None, 0.1, ) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 187, in runTest self.test(*self.arg) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", line 187, in eval_evec err_msg=err) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", line 74, in assert_allclose_cc assert_allclose(actual, conj(desired), **kw) File "/home/bvr/Programs/numpy/numpy/testing/utils.py", line 1167, in assert_allclose verbose=verbose, header=header) File "/home/bvr/Programs/numpy/numpy/testing/utils.py", line 635, in assert_array_compare raise AssertionError(msg) AssertionError: Not equal to tolerance rtol=0.000238419, atol=0.000238419 error for eigs:general, typ=F, which=LR, sigma=0.1, mattype=aslinearoperator, OPpart=None, mode=normal (mismatch 100.0%) x: array([ 0.48504701-0.67845428j, 0.33412224+0.08106201j], dtype='complex64') y: array([ 1.26434827+0.579292j , 0.32682878-0.12782857j], dtype='complex64') ====================================================================== FAIL: test_arpack.test_complex_nonsymmetric_modes(False, , 'F', 2, 'LI', None, (0.1+0.1j), ) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 187, in runTest self.test(*self.arg) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", line 187, in eval_evec err_msg=err) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", line 74, in assert_allclose_cc assert_allclose(actual, conj(desired), **kw) File "/home/bvr/Programs/numpy/numpy/testing/utils.py", line 1167, in assert_allclose verbose=verbose, header=header) File "/home/bvr/Programs/numpy/numpy/testing/utils.py", line 635, in assert_array_compare raise AssertionError(msg) AssertionError: Not equal to tolerance rtol=0.000238419, atol=0.000238419 error for eigs:general, typ=F, which=LI, sigma=(0.1+0.1j), mattype=aslinearoperator, OPpart=None, mode=normal (mismatch 100.0%) x: array([ 0.17345099-0.75199366j, -0.20347327-0.12855324j], dtype='complex64') y: array([ 1.26434827+0.579292j , -0.09499434+0.27649775j], dtype='complex64') ====================================================================== FAIL: test_arpack.test_complex_nonsymmetric_modes(False, , 'F', 2, 'LI', None, 0.1, ) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 187, in runTest self.test(*self.arg) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", line 187, in eval_evec err_msg=err) File "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", line 74, in assert_allclose_cc assert_allclose(actual, conj(desired), **kw) File "/home/bvr/Programs/numpy/numpy/testing/utils.py", line 1167, in assert_allclose verbose=verbose, header=header) File "/home/bvr/Programs/numpy/numpy/testing/utils.py", line 635, in assert_array_compare raise AssertionError(msg) AssertionError: Not equal to tolerance rtol=0.000238419, atol=0.000238419 error for eigs:general, typ=F, which=LI, sigma=0.1, mattype=aslinearoperator, OPpart=None, mode=normal (mismatch 100.0%) x: array([ 0.49928182-0.91036922j, -0.16933820-0.15198432j], dtype='complex64') y: array([ 1.26434827+0.579292j , -0.09499434+0.27649775j], dtype='complex64') ====================================================================== FAIL: test_expon (test_morestats.TestAnderson) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/bvr/Programs/scipy/scipy/stats/tests/test_morestats.py", line 72, in test_expon assert_array_less(crit[:-1], A) File "/home/bvr/Programs/numpy/numpy/testing/utils.py", line 868, in assert_array_less header='Arrays are not less-ordered') File "/home/bvr/Programs/numpy/numpy/testing/utils.py", line 612, in assert_array_compare chk_same_position(x_id, y_id, hasval='inf') File "/home/bvr/Programs/numpy/numpy/testing/utils.py", line 587, in chk_same_position raise AssertionError(msg) AssertionError: Arrays are not less-ordered x and y inf location mismatch: x: array([ 0.911, 1.065, 1.325, 1.587]) y: array(inf) ---------------------------------------------------------------------- Ran 5488 tests in 68.381s FAILED (KNOWNFAIL=12, SKIP=35, errors=47, failures=31) Running unit tests for scipy NumPy version 2.0.0.dev-d82752c NumPy is installed in /home/bvr/Programs/numpy/numpy SciPy version 0.10.0.dev SciPy is installed in /home/bvr/Programs/scipy/scipy Python version 2.7.1 (r271:86832, Apr 12 2011, 16:15:16) [GCC 4.6.0 20110331 (Red Hat 4.6.0-2)] nose version 1.0.0 From pav at iki.fi Tue Jun 21 12:15:07 2011 From: pav at iki.fi (Pauli Virtanen) Date: Tue, 21 Jun 2011 16:15:07 +0000 (UTC) Subject: [SciPy-Dev] Many errors/failures running scipy.test() using latest numpy and scipy References: Message-ID: Tue, 21 Jun 2011 10:51:18 -0500, Benjamin Root wrote: [clip] > The first error has to do with the netcdf file (I thought that was fixed > by now?). Then, some of the errors are related to the gmres module (I > see that is already known). Then, there are many errors for > "test_arpack.test_real_nonsymmetric_modes", > "test_arpack.test_complex_nonsymmetric_modes", and > "test_arpack.test_hermitian_modes". Lastly, there is a single failure > for "test_morestats.TestAnderson". > > I hope this is useful. All of the ARPACK failures are GMRES-related. These appear to be very strongly platform-dependent for some reason. I don't see them, and it is somewhat difficult to believe that the calculation could be this unstable because of rounding error. Can you check if your GMRES works at all, i.e., try a simple 6 x 6 complex-valued matrix? The current test cases don't actually cover it properly, and at least Gfortran 4.5.2 does miscompile the GMRES routines in some cases. Not sure about 4.6.0 that you use, but compiler issues remain a possibility (esp. since it is a .0 release). Maybe using a different gfortran version makes these go away? F90=gfortran-4.4 python setup.py build Pauli From ben.root at ou.edu Tue Jun 21 13:23:54 2011 From: ben.root at ou.edu (Benjamin Root) Date: Tue, 21 Jun 2011 12:23:54 -0500 Subject: [SciPy-Dev] Many errors/failures running scipy.test() using latest numpy and scipy In-Reply-To: References: Message-ID: On Tue, Jun 21, 2011 at 11:15 AM, Pauli Virtanen wrote: > Tue, 21 Jun 2011 10:51:18 -0500, Benjamin Root wrote: > [clip] > > The first error has to do with the netcdf file (I thought that was fixed > > by now?). Then, some of the errors are related to the gmres module (I > > see that is already known). Then, there are many errors for > > "test_arpack.test_real_nonsymmetric_modes", > > "test_arpack.test_complex_nonsymmetric_modes", and > > "test_arpack.test_hermitian_modes". Lastly, there is a single failure > > for "test_morestats.TestAnderson". > > > > I hope this is useful. > > All of the ARPACK failures are GMRES-related. > > These appear to be very strongly platform-dependent for some reason. > I don't see them, and it is somewhat difficult to believe that the > calculation could be this unstable because of rounding error. > > Can you check if your GMRES works at all, i.e., try a simple 6 x 6 > complex-valued matrix? The current test cases don't actually cover > it properly, and at least Gfortran 4.5.2 does miscompile the GMRES > routines in some cases. Not sure about 4.6.0 that you use, but > compiler issues remain a possibility (esp. since it is a .0 release). > > Using the example given in the other mail thread: import numpy as np import scipy.sparse.linalg A = np.random.rand(6, 6) + 1j*np.random.rand(6, 6) b = np.random.rand(6) + 1j*np.random.rand(6) x, info = scipy.sparse.linalg.gmres(A, b) y = np.linalg.solve(A, b) print abs(x - y).max() produces: 0.427293469893 > Maybe using a different gfortran version makes these go away? > > F90=gfortran-4.4 python setup.py build > > I don't see another gfortran available in the repos. I will look further. Ben Root -------------- next part -------------- An HTML attachment was scrubbed... URL: From pav at iki.fi Tue Jun 21 14:43:33 2011 From: pav at iki.fi (Pauli Virtanen) Date: Tue, 21 Jun 2011 18:43:33 +0000 (UTC) Subject: [SciPy-Dev] Many errors/failures running scipy.test() using latest numpy and scipy References: Message-ID: On Tue, 21 Jun 2011 12:23:54 -0500, Benjamin Root wrote: > Using the example given in the other mail thread: > > import numpy as np > import scipy.sparse.linalg > A = np.random.rand(6, 6) + 1j*np.random.rand(6, 6) > b = np.random.rand(6) + 1j*np.random.rand(6) > x, info = scipy.sparse.linalg.gmres(A, b) > y = np.linalg.solve(A, b) > print abs(x - y).max() > > produces: > > 0.427293469893 Yep, that seems broken. I'll add some test cases for the iterative solvers so that we catch this if it occurs. Pauli From ben.root at ou.edu Wed Jun 22 11:06:13 2011 From: ben.root at ou.edu (Benjamin Root) Date: Wed, 22 Jun 2011 10:06:13 -0500 Subject: [SciPy-Dev] Many errors/failures running scipy.test() using latest numpy and scipy In-Reply-To: References: Message-ID: On Tue, Jun 21, 2011 at 1:43 PM, Pauli Virtanen wrote: > On Tue, 21 Jun 2011 12:23:54 -0500, Benjamin Root wrote: > > Using the example given in the other mail thread: > > > > import numpy as np > > import scipy.sparse.linalg > > A = np.random.rand(6, 6) + 1j*np.random.rand(6, 6) > > b = np.random.rand(6) + 1j*np.random.rand(6) > > x, info = scipy.sparse.linalg.gmres(A, b) > > y = np.linalg.solve(A, b) > > print abs(x - y).max() > > > > produces: > > > > 0.427293469893 > > Yep, that seems broken. I'll add some test cases for the iterative solvers > so that we catch this if it occurs. > > Pauli > > I performed the tests on another machine of mine with completely different specs (32-bit, gcc 4.5.2, Ubuntu 11.04), and the arpack errors were much fewer. I still had the other errors (like the netcdf one and the Anderson one), but I attached the relevant ones here. I hope this is helpful, Ben Root -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- Running unit tests for scipy NumPy version 2.0.0.dev-adab903 NumPy is installed in /home/ben/Programs/numpy/numpy SciPy version 0.10.0.dev SciPy is installed in /home/ben/Programs/scipy/scipy Python version 2.7.1+ (r271:86832, Apr 11 2011, 18:05:24) [GCC 4.5.2] nose version 0.11.4 ====================================================================== ERROR: test_arpack.test_hermitian_modes(True, , 'F', 2, 'SM', None, None, ) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/pymodules/python2.7/nose/case.py", line 186, in runTest self.test(*self.arg) File "/home/ben/Programs/scipy/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", line 168, in eval_evec eval, evec = eigs_func(ac, k, bc, **kwargs) File "/home/ben/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 1425, in eigsh OPinv=OPinv) File "/home/ben/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 1251, in eigs params.iterate() File "/home/ben/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 727, in iterate self.workd[yslice] = self.OP(self.workd[xslice]) File "/home/ben/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 641, in self.OP = lambda x: Minv_matvec(matvec(x)) File "/home/ben/Programs/scipy/scipy/sparse/linalg/interface.py", line 123, in matvec y = self._matvec(x) File "/home/ben/Programs/scipy/scipy/sparse/linalg/eigen/arpack/arpack.py", line 945, in _matvec % (self.ifunc.__name__, info)) ValueError: Error in inverting M: function gmres did not converge (info = 60). ====================================================================== FAIL: test_lu (test_decomp.TestLUSolve) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/ben/Programs/scipy/scipy/linalg/tests/test_decomp.py", line 732, in test_lu assert_array_equal(x1,x2) File "/home/ben/Programs/numpy/numpy/testing/utils.py", line 706, in assert_array_equal verbose=verbose, header='Arrays are not equal') File "/home/ben/Programs/numpy/numpy/testing/utils.py", line 635, in assert_array_compare raise AssertionError(msg) AssertionError: Arrays are not equal (mismatch 90.0%) x: array([-0.36278861, 0.75920432, 0.19844271, 0.65479681, 0.40510514, 0.79604687, -1.05344321, -0.25597019, -0.34997286, 0.07080989]) y: array([-0.36278861, 0.75920432, 0.19844271, 0.65479681, 0.40510514, 0.79604687, -1.05344321, -0.25597019, -0.34997286, 0.07080989]) From andrew.smirnov at gmail.com Fri Jun 24 00:21:56 2011 From: andrew.smirnov at gmail.com (Andrey Smirnov) Date: Fri, 24 Jun 2011 11:21:56 +0700 Subject: [SciPy-Dev] Signal: Add type III/IV filter calculation to firwin2 Message-ID: <87ei2jkgez.fsf@gmail.com> Hello everybody, Since current version of firwin2 can only produce type I and type II filters as a result, and circumstances where type III/IV are needed are not unthinkable, I decided to implement said functionality. The results can be seen at: https://github.com/scipy/scipy/pull/39 I would really appreciate your comments on the code itself and on whether it is possible to include this functionality into scipy. Thanks in advance, Andrey Smirnov From schut at sarvision.nl Thu Jun 30 07:20:37 2011 From: schut at sarvision.nl (Vincent Schut) Date: Thu, 30 Jun 2011 13:20:37 +0200 Subject: [SciPy-Dev] Many errors/failures running scipy.test() using latest numpy and scipy In-Reply-To: References: Message-ID: On 06/21/2011 06:15 PM, Pauli Virtanen wrote: > Tue, 21 Jun 2011 10:51:18 -0500, Benjamin Root wrote: > [clip] >> The first error has to do with the netcdf file (I thought that was fixed >> by now?). Then, some of the errors are related to the gmres module (I >> see that is already known). Then, there are many errors for >> "test_arpack.test_real_nonsymmetric_modes", >> "test_arpack.test_complex_nonsymmetric_modes", and >> "test_arpack.test_hermitian_modes". Lastly, there is a single failure >> for "test_morestats.TestAnderson". >> >> I hope this is useful. > > All of the ARPACK failures are GMRES-related. > > These appear to be very strongly platform-dependent for some reason. > I don't see them, and it is somewhat difficult to believe that the > calculation could be this unstable because of rounding error. > > Can you check if your GMRES works at all, i.e., try a simple 6 x 6 > complex-valued matrix? The current test cases don't actually cover > it properly, and at least Gfortran 4.5.2 does miscompile the GMRES > routines in some cases. Not sure about 4.6.0 that you use, but > compiler issues remain a possibility (esp. since it is a .0 release). > > Maybe using a different gfortran version makes these go away? > > F90=gfortran-4.4 python setup.py build > > Pauli Hi, I have these same failures and errors in scipy.test(): (KNOWNFAIL=12, SKIP=24, errors=49, failures=33) Most of these are arpack related. I tried with: F90=g95 python setup.py build instead of the default gfortran, but it makes no difference. I also tried with different blas/lapack, also no difference. downgrading gfortran is not a real option, alas. It's too much fuss to downgrade the entire gcc suite on my system (or could I just install a different gfortran sitting besides the default one?) gcc/gfortran is 4.6.1, cpu is AMD Phenom(tm) II X6 1055T anything I could do to diagnose this further? I'd like to have a working scipy again... Vincent. From schut at sarvision.nl Thu Jun 30 09:03:31 2011 From: schut at sarvision.nl (Vincent Schut) Date: Thu, 30 Jun 2011 15:03:31 +0200 Subject: [SciPy-Dev] Many errors/failures running scipy.test() using latest numpy and scipy In-Reply-To: References: Message-ID: On 06/30/2011 01:20 PM, Vincent Schut wrote: > On 06/21/2011 06:15 PM, Pauli Virtanen wrote: >> Tue, 21 Jun 2011 10:51:18 -0500, Benjamin Root wrote: >> [clip] >>> The first error has to do with the netcdf file (I thought that was fixed >>> by now?). Then, some of the errors are related to the gmres module (I >>> see that is already known). Then, there are many errors for >>> "test_arpack.test_real_nonsymmetric_modes", >>> "test_arpack.test_complex_nonsymmetric_modes", and >>> "test_arpack.test_hermitian_modes". Lastly, there is a single failure >>> for "test_morestats.TestAnderson". >>> >>> I hope this is useful. >> >> All of the ARPACK failures are GMRES-related. >> >> These appear to be very strongly platform-dependent for some reason. >> I don't see them, and it is somewhat difficult to believe that the >> calculation could be this unstable because of rounding error. >> >> Can you check if your GMRES works at all, i.e., try a simple 6 x 6 >> complex-valued matrix? The current test cases don't actually cover >> it properly, and at least Gfortran 4.5.2 does miscompile the GMRES >> routines in some cases. Not sure about 4.6.0 that you use, but >> compiler issues remain a possibility (esp. since it is a .0 release). >> >> Maybe using a different gfortran version makes these go away? >> >> F90=gfortran-4.4 python setup.py build >> >> Pauli > > Hi, > > I have these same failures and errors in scipy.test(): > (KNOWNFAIL=12, SKIP=24, errors=49, failures=33) > Most of these are arpack related. > I tried with: > F90=g95 python setup.py build > instead of the default gfortran, but it makes no difference. I also > tried with different blas/lapack, also no difference. > > downgrading gfortran is not a real option, alas. It's too much fuss to > downgrade the entire gcc suite on my system (or could I just install a > different gfortran sitting besides the default one?) > > gcc/gfortran is 4.6.1, cpu is AMD Phenom(tm) II X6 1055T > > anything I could do to diagnose this further? I'd like to have a working > scipy again... > > Vincent. OK, to follow up on myself: found out how to install gfortran-4.4 alongside 4.6.1. Built scipy with F90=gfortran-4.4, and this resolves most of the errors! I still have 3 errors an d2 failures left, I'll paste them here for reference: ERROR: test_netcdf.test_read_example_data ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 187, in runTest self.test(*self.arg) File "/usr/lib/python2.7/site-packages/scipy/io/tests/test_netcdf.py", line 124, in test_read_example_data f = netcdf_file(fname, 'r') File "/usr/lib/python2.7/site-packages/scipy/io/netcdf.py", line 205, in __init__ self._read() File "/usr/lib/python2.7/site-packages/scipy/io/netcdf.py", line 492, in _read self._read_var_array() File "/usr/lib/python2.7/site-packages/scipy/io/netcdf.py", line 536, in _read_var_array typecode, size, dtype_, begin_, vsize) = self._read_var() File "/usr/lib/python2.7/site-packages/scipy/io/netcdf.py", line 624, in _read_var attributes = self._read_att_array() File "/usr/lib/python2.7/site-packages/scipy/io/netcdf.py", line 522, in _read_att_array attributes[name] = self._read_values() File "/usr/lib/python2.7/site-packages/scipy/io/netcdf.py", line 649, in _read_values values = fromstring(values, dtype='>%s%d' % (typecode, size)) TypeError: data type ">d8" not understood ====================================================================== ERROR: gaussian gradient magnitude filter 1 ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 187, in runTest self.test(*self.arg) File "/usr/lib/python2.7/site-packages/scipy/ndimage/tests/test_ndimage.py", line 670, in test_gaussian_gradient_magnitude01 1.0) File "/usr/lib/python2.7/site-packages/scipy/ndimage/filters.py", line 479, in gaussian_gradient_magnitude cval, extra_arguments = (sigma,)) File "/usr/lib/python2.7/site-packages/scipy/ndimage/filters.py", line 450, in generic_gradient_magnitude numpy.sqrt(output, output) TypeError: ufunc 'sqrt' output (typecode 'd') could not be coerced to provided output parameter (typecode 'i') according to the casting rule 'same_kind' ====================================================================== ERROR: gaussian gradient magnitude filter 2 ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 187, in runTest self.test(*self.arg) File "/usr/lib/python2.7/site-packages/scipy/ndimage/tests/test_ndimage.py", line 685, in test_gaussian_gradient_magnitude02 output) File "/usr/lib/python2.7/site-packages/scipy/ndimage/filters.py", line 479, in gaussian_gradient_magnitude cval, extra_arguments = (sigma,)) File "/usr/lib/python2.7/site-packages/scipy/ndimage/filters.py", line 450, in generic_gradient_magnitude numpy.sqrt(output, output) TypeError: ufunc 'sqrt' output (typecode 'd') could not be coerced to provided output parameter (typecode 'i') according to the casting rule 'same_kind' ====================================================================== FAIL: test_iterative.test_convergence(, ) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 187, in runTest self.test(*self.arg) File "/usr/lib/python2.7/site-packages/scipy/sparse/linalg/isolve/tests/test_iterative.py", line 152, in check_convergence assert_equal(info,0) File "/usr/lib/python2.7/site-packages/numpy/testing/utils.py", line 313, in assert_equal raise AssertionError(msg) AssertionError: Items are not equal: ACTUAL: 100 DESIRED: 0 ====================================================================== FAIL: test_expon (test_morestats.TestAnderson) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/scipy/stats/tests/test_morestats.py", line 72, in test_expon assert_array_less(crit[:-1], A) File "/usr/lib/python2.7/site-packages/numpy/testing/utils.py", line 868, in assert_array_less header='Arrays are not less-ordered') File "/usr/lib/python2.7/site-packages/numpy/testing/utils.py", line 612, in assert_array_compare chk_same_position(x_id, y_id, hasval='inf') File "/usr/lib/python2.7/site-packages/numpy/testing/utils.py", line 587, in chk_same_position raise AssertionError(msg) AssertionError: Arrays are not less-ordered x and y inf location mismatch: x: array([ 0.911, 1.065, 1.325, 1.587]) y: array(inf) ---------------------------------------------------------------------- Ran 5570 tests in 61.753s FAILED (KNOWNFAIL=12, SKIP=24, errors=3, failures=2) From pav at iki.fi Thu Jun 30 16:22:58 2011 From: pav at iki.fi (Pauli Virtanen) Date: Thu, 30 Jun 2011 20:22:58 +0000 (UTC) Subject: [SciPy-Dev] Many errors/failures running scipy.test() using latest numpy and scipy References: Message-ID: On Thu, 30 Jun 2011 13:20:37 +0200, Vincent Schut wrote: [clip] > anything I could do to diagnose this further? This is a bit difficult, or at least time-consuming. One thing that can be done is to diff the assembler output from Gfortran 4.6 and 4.4 of the iterative solvers, find the points where it differs, and then check if the Fortran code does something suspicious at the corresponding point. If someone else wants to spend some quality time with assembler listings before I find time etc. for this, please go ahead :) > I'd like to have a working scipy again... These failures have always been there, it's just that now we have better test coverage so that we actually catch them... Pauli From jason-sage at creativetrax.com Thu Jun 30 17:16:54 2011 From: jason-sage at creativetrax.com (Jason Grout) Date: Thu, 30 Jun 2011 16:16:54 -0500 Subject: [SciPy-Dev] LATEST.txt file has svn instructions Message-ID: <4E0CE7C6.8060603@creativetrax.com> Just FYI, I just noticed that the LATEST.txt file has the old svn instructions still: https://github.com/scipy/scipy/blob/master/LATEST.txt These should probably be updated to github sometime before the next release... Thanks, Jason -- Jason Grout From pav at iki.fi Thu Jun 30 17:33:33 2011 From: pav at iki.fi (Pauli Virtanen) Date: Thu, 30 Jun 2011 21:33:33 +0000 (UTC) Subject: [SciPy-Dev] LATEST.txt file has svn instructions References: <4E0CE7C6.8060603@creativetrax.com> Message-ID: On Thu, 30 Jun 2011 16:16:54 -0500, Jason Grout wrote: > Just FYI, I just noticed that the LATEST.txt file has the old svn > instructions still: > > https://github.com/scipy/scipy/blob/master/LATEST.txt > > These should probably be updated to github sometime before the next > release... Thanks, fixed. From jason-sage at creativetrax.com Thu Jun 30 18:31:27 2011 From: jason-sage at creativetrax.com (Jason Grout) Date: Thu, 30 Jun 2011 17:31:27 -0500 Subject: [SciPy-Dev] license typo Message-ID: <4E0CF93F.80107@creativetrax.com> Usually I'd just correct a small typo and submit a pull request, but this is a typo in the license, so it seems more sticky to correct. Condition (c) of the LICENSE.txt file starts: Neither the name of the Enthought nor the names of its contributors of course, "the Enthought" should probably just be "Enthought". Thanks, Jason -- Jason Grout