From evgeny.burovskiy at gmail.com Sat Jun 4 09:10:59 2016 From: evgeny.burovskiy at gmail.com (Evgeni Burovski) Date: Sat, 4 Jun 2016 14:10:59 +0100 Subject: [SciPy-Dev] scipy 0.18 release Message-ID: Hi, It's seems to be about time to start planning the release of scipy 0.18. I volunteer to do the legwork for this release. The proposed schedule would be: 20 June: rc1 27 June: rc2 (if necessary) 11 July: final release Thoughts? Here's the current contents of the milestone: https://github.com/scipy/scipy/milestones/0.18.0 Any help with addressing open issues and reviewing/merging open PRs would be most appreciated. Cheers, Evgeni From ralf.gommers at gmail.com Sat Jun 4 11:52:42 2016 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Sat, 4 Jun 2016 17:52:42 +0200 Subject: [SciPy-Dev] scipy 0.18 release In-Reply-To: References: Message-ID: On Sat, Jun 4, 2016 at 3:10 PM, Evgeni Burovski wrote: > Hi, > > It's seems to be about time to start planning the release of scipy 0.18. > > I volunteer to do the legwork for this release. Thanks Evgeni! > The proposed schedule would be: > > 20 June: rc1 > 27 June: rc2 (if necessary) > 11 July: final release > > Thoughts? > That schedule looks fine to me. Seems doable given the list of what's currently tagged for 0.18.0. And most of that list are not blocking anyway. Ralf > > Here's the current contents of the milestone: > https://github.com/scipy/scipy/milestones/0.18.0 > > Any help with addressing open issues and reviewing/merging open PRs > would be most appreciated. > > Cheers, > > Evgeni > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > https://mail.scipy.org/mailman/listinfo/scipy-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fberkenkamp at gmail.com Tue Jun 7 17:23:50 2016 From: fberkenkamp at gmail.com (Felix Berkenkamp) Date: Tue, 07 Jun 2016 21:23:50 +0000 Subject: [SciPy-Dev] PR: Deprecate lti cross-class properties/setters In-Reply-To: References: Message-ID: Hi all, I may be a bit late, but I just opened a PR that I would preferably still like to see go into 0.18. It deprecates historic properties/setters of lti systems, such as the ability to set the numerator of a StateSpace system. Internally these kind of operations are very hacky and numerically inaccurate, so I think it is best to deprecate them. https://github.com/scipy/scipy/pull/6224 Best, Felix -------------- next part -------------- An HTML attachment was scrubbed... URL: From gfyoung17 at gmail.com Wed Jun 8 08:57:14 2016 From: gfyoung17 at gmail.com (G Young) Date: Wed, 8 Jun 2016 13:57:14 +0100 Subject: [SciPy-Dev] raise on boolean sparse.__neg__ Message-ID: Hi, I have had a PR open for quite some time now that raises when we attempt to take the negative of a boolean sparse matrix. While this has been given the +1 by @perimosocordiae , as this is a backwards-incompatible change, he wanted to make sure others were okay with this change before merging. The rationale for raising on a boolean sparse matrix is nicely explained by here , and I wanted to send this out to the mailing list to see if other maintainers and developers agree with this logic. Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From josh.craig.wilson at gmail.com Sun Jun 12 15:23:30 2016 From: josh.craig.wilson at gmail.com (Joshua Wilson) Date: Sun, 12 Jun 2016 14:23:30 -0500 Subject: [SciPy-Dev] PR adding a cython interface for special Message-ID: Hello all, This is a request for comments on https://github.com/scipy/scipy/pull/6195 which adds a cython interface for scalar, typed versions of most of the functions in scipy.special. The documentation can be found here: https://circle-artifacts.com/gh/scipy/scipy/52/artifacts/0/home/ubuntu/scipy/doc/build/html-scipyorg/linalg.cython_special.html - Josh -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.gommers at gmail.com Mon Jun 13 15:55:28 2016 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Mon, 13 Jun 2016 21:55:28 +0200 Subject: [SciPy-Dev] PR: Deprecate lti cross-class properties/setters In-Reply-To: References: Message-ID: On Tue, Jun 7, 2016 at 11:23 PM, Felix Berkenkamp wrote: > Hi all, > > I may be a bit late, but I just opened a PR that I would preferably still > like to see go into 0.18. It deprecates historic properties/setters of lti > systems, such as the ability to set the numerator of a StateSpace system. > > Internally these kind of operations are very hacky and numerically > inaccurate, so I think it is best to deprecate them. > +1 let's try to merge it this week so it's in 0.18.0 Ralf > > https://github.com/scipy/scipy/pull/6224 > > Best, > Felix > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > https://mail.scipy.org/mailman/listinfo/scipy-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andyfaff at gmail.com Tue Jun 14 19:19:45 2016 From: andyfaff at gmail.com (Andrew Nelson) Date: Wed, 15 Jun 2016 09:19:45 +1000 Subject: [SciPy-Dev] optimize: what should happen if objective functions return non-finite numbers? Message-ID: Consider the following example which raises an AssertionError: import numpy as np from scipy.optimize import minimize def func1(x): return np.nan x0 = np.array([1.3, 0.7, 0.8, 1.9, 1.2]) res = minimize(func1, x0, method='l-bfgs-b') assert(res.success = False) minimize simply returns the starting values of: res.x == x0. The reason I came up with this example is that unsanitised datasets sometimes contain nan or inf. Thus, if func1 was calculating chi2 and you were using minimize then the entire fit would appear to succeed (res.success is True), but the output would be garbage. Ok, so res.message is CONVERGENCE: NORM_OF_PROJECTED_GRADIENT_<=_PGTOL, but it's not an clear indicator that something went wrong. A second example is: import numpy as np from scipy.optimize import curve_fit def func2(x, a, b, c): return a * np.exp(-b * x) + c def func3(x, a, b, c): return np.nan xdata = np.linspace(0, 4, 50) y = func2(xdata, 2.5, 1.3, 0.5) ydata = y + 0.2 * np.random.normal(size=len(xdata)) popt, pcov = curve_fit(func3, xdata, ydata) print(popt) Whilst there is a warning (OptimizeWarning: Covariance of the parameters could not be estimated) it's not a clear indicator that something has gone wrong. The behaviour one might expect in both examples could be to see a ValueError raised if there arenp.nan values returned from the objective function. I'm not totally sure of what to do if +/- np.inf is returned (-inf would be a very good global minimum). -- _____________________________________ Dr. Andrew Nelson _____________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From josef.pktd at gmail.com Tue Jun 14 22:40:59 2016 From: josef.pktd at gmail.com (josef.pktd at gmail.com) Date: Tue, 14 Jun 2016 22:40:59 -0400 Subject: [SciPy-Dev] optimize: what should happen if objective functions return non-finite numbers? In-Reply-To: References: Message-ID: On Tue, Jun 14, 2016 at 7:19 PM, Andrew Nelson wrote: > Consider the following example which raises an AssertionError: > > import numpy as np > from scipy.optimize import minimize > def func1(x): > return np.nan > x0 = np.array([1.3, 0.7, 0.8, 1.9, 1.2]) > res = minimize(func1, x0, method='l-bfgs-b') > assert(res.success = False) > > minimize simply returns the starting values of: res.x == x0. The reason I > came up with this example is that unsanitised datasets sometimes contain > nan or inf. Thus, if func1 was calculating chi2 and you were using minimize > then the entire fit would appear to succeed (res.success is True), but the > output would be garbage. Ok, so res.message is CONVERGENCE: > NORM_OF_PROJECTED_GRADIENT_<=_PGTOL, but it's not an clear indicator that > something went wrong. > A second example is: > > import numpy as np > from scipy.optimize import curve_fit > def func2(x, a, b, c): > return a * np.exp(-b * x) + c > > def func3(x, a, b, c): > return np.nan > > xdata = np.linspace(0, 4, 50) > y = func2(xdata, 2.5, 1.3, 0.5) > ydata = y + 0.2 * np.random.normal(size=len(xdata)) > > popt, pcov = curve_fit(func3, xdata, ydata) > print(popt) > > Whilst there is a warning (OptimizeWarning: Covariance of the parameters > could not be estimated) it's not a clear indicator that something has gone > wrong. > The behaviour one might expect in both examples could be to see a > ValueError raised if there arenp.nan values returned from the objective > function. I'm not totally sure of what to do if +/- np.inf is returned > (-inf would be a very good global minimum). > In my opinion optimizers should not (never?) raise exception, warn and return whatever is available so the user can investigate. I'm seeing nans every once in a while, but even if the objective function returns nan, we often have finite parameters that can be used to investigate for example gradients and similar. In statsmodels we just got a bug report for NegativeBinomial/Poisson similar to the exp example that had nans because of overflow. I was surprised that converged=True showed up in that case (but disp and our summary shows the nans). about nan in the objective functions: A few years ago I played with several examples where I put a segment in the parameter space where the objective function returned nan . Several of the optimizers managed to avoid that region, AFAIR. In the case of optimizers, the user can always put additional checks into the objective function, and raise there if desired. I tried to convert nans to some proper values, but, AFAIR, the behavior of different optimizers varies widely and I didn't find a solution that would work in general. aside: bfgs was recently changed so it should have fewer problems with extreme stepsizes as in the exp example. I still haven't tried out the trust-region newton methods that have been added a while ago with the statsmodels optimization problems. Josef > > > -- > _____________________________________ > Dr. Andrew Nelson > > > _____________________________________ > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > https://mail.scipy.org/mailman/listinfo/scipy-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From newville at cars.uchicago.edu Wed Jun 15 08:19:00 2016 From: newville at cars.uchicago.edu (Matt Newville) Date: Wed, 15 Jun 2016 07:19:00 -0500 Subject: [SciPy-Dev] SciPy-Dev Digest, Vol 152, Issue 6 In-Reply-To: References: Message-ID: On Wed, Jun 15, 2016 at 7: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 > https://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. optimize: what should happen if objective functions return > non-finite numbers? (Andrew Nelson) > 2. Re: optimize: what should happen if objective functions > return non-finite numbers? (josef.pktd at gmail.com) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 15 Jun 2016 09:19:45 +1000 > From: Andrew Nelson > To: SciPy Developers List > Subject: [SciPy-Dev] optimize: what should happen if objective > functions return non-finite numbers? > Message-ID: > < > CAAbtOZdiCO-_bcqF0UPy-Bn6SmmqZfcOPZmdEBAiQchbCpf_zA at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Consider the following example which raises an AssertionError: > > import numpy as np > from scipy.optimize import minimize > def func1(x): > return np.nan > x0 = np.array([1.3, 0.7, 0.8, 1.9, 1.2]) > res = minimize(func1, x0, method='l-bfgs-b') > assert(res.success = False) > > minimize simply returns the starting values of: res.x == x0. The reason I > came up with this example is that unsanitised datasets sometimes contain > nan or inf. Thus, if func1 was calculating chi2 and you were using minimize > then the entire fit would appear to succeed (res.success is True), but the > output would be garbage. Ok, so res.message is CONVERGENCE: > NORM_OF_PROJECTED_GRADIENT_<=_PGTOL, but it's not an clear indicator that > something went wrong. > A second example is: > > import numpy as np > from scipy.optimize import curve_fit > def func2(x, a, b, c): > return a * np.exp(-b * x) + c > > def func3(x, a, b, c): > return np.nan > > xdata = np.linspace(0, 4, 50) > y = func2(xdata, 2.5, 1.3, 0.5) > ydata = y + 0.2 * np.random.normal(size=len(xdata)) > > popt, pcov = curve_fit(func3, xdata, ydata) > print(popt) > > Whilst there is a warning (OptimizeWarning: Covariance of the parameters > could not be estimated) it's not a clear indicator that something has gone > wrong. > The behaviour one might expect in both examples could be to see a > ValueError raised if there arenp.nan values returned from the objective > function. I'm not totally sure of what to do if +/- np.inf is returned > (-inf would be a very good global minimum). > > > -- > _____________________________________ > Dr. Andrew Nelson > > > _____________________________________ > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://mail.scipy.org/pipermail/scipy-dev/attachments/20160615/1ec5735c/attachment-0001.html > > > > ------------------------------ > > Message: 2 > Date: Tue, 14 Jun 2016 22:40:59 -0400 > From: josef.pktd at gmail.com > To: SciPy Developers List > Subject: Re: [SciPy-Dev] optimize: what should happen if objective > functions return non-finite numbers? > Message-ID: > eh5kNgdGrag4mew7s51JJpnVEqdRg at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > On Tue, Jun 14, 2016 at 7:19 PM, Andrew Nelson wrote: > > > Consider the following example which raises an AssertionError: > > > > import numpy as np > > from scipy.optimize import minimize > > def func1(x): > > return np.nan > > x0 = np.array([1.3, 0.7, 0.8, 1.9, 1.2]) > > res = minimize(func1, x0, method='l-bfgs-b') > > assert(res.success = False) > > > > minimize simply returns the starting values of: res.x == x0. The reason I > > came up with this example is that unsanitised datasets sometimes contain > > nan or inf. Thus, if func1 was calculating chi2 and you were using > minimize > > then the entire fit would appear to succeed (res.success is True), but > the > > output would be garbage. Ok, so res.message is CONVERGENCE: > > NORM_OF_PROJECTED_GRADIENT_<=_PGTOL, but it's not an clear indicator that > > something went wrong. > > A second example is: > > > > import numpy as np > > from scipy.optimize import curve_fit > > def func2(x, a, b, c): > > return a * np.exp(-b * x) + c > > > > def func3(x, a, b, c): > > return np.nan > > > > xdata = np.linspace(0, 4, 50) > > y = func2(xdata, 2.5, 1.3, 0.5) > > ydata = y + 0.2 * np.random.normal(size=len(xdata)) > > > > popt, pcov = curve_fit(func3, xdata, ydata) > > print(popt) > > > > Whilst there is a warning (OptimizeWarning: Covariance of the parameters > > could not be estimated) it's not a clear indicator that something has > gone > > wrong. > > The behaviour one might expect in both examples could be to see a > > ValueError raised if there arenp.nan values returned from the objective > > function. I'm not totally sure of what to do if +/- np.inf is returned > > (-inf would be a very good global minimum). > > > > > In my opinion optimizers should not (never?) raise exception, warn and > return whatever is available so the user can investigate. > I'm seeing nans every once in a while, but even if the objective function > returns nan, we often have finite parameters that can be used to > investigate for example gradients and similar. > > We do see questions related to NaNs with lmfit, rather often. It might be that the lmfit users are somewhat less meticulous than scipy developers when fitting data. My first reaction to Andrews suggestion was also to use a Warning, but he convinced me that an Exception is better. Just as a general Python Philosophy question, what does "ValueError" mean? To me, it means "this Value caused an Error". And, NaNs (and Infs) definitely cause the Fortran/C routines doing optimization to not even try to improve the solution -- that is, to do what they are supposed to do. My view is that saying, "Warning, you got bad results because of bad data" would be too easy to ignore. --Matt Newville -------------- next part -------------- An HTML attachment was scrubbed... URL: From shoyer at gmail.com Wed Jun 15 13:32:12 2016 From: shoyer at gmail.com (Stephan Hoyer) Date: Wed, 15 Jun 2016 10:32:12 -0700 Subject: [SciPy-Dev] optimize: what should happen if objective functions return non-finite numbers? In-Reply-To: References: Message-ID: On Tue, Jun 14, 2016 at 4:19 PM, Andrew Nelson wrote: > The behaviour one might expect in both examples could be to see a > ValueError raised if there arenp.nan values returned from the objective > function. I'm not totally sure of what to do if +/- np.inf is returned > (-inf would be a very good global minimum). > It's not uncommon get pathological objective function values when you optimize complex models (e.g., that integrate an ode). I agree that the sane default behavior is to raise a ValueError when NaN is encountered, but sometimes it's better to treat such data points as invalid. The exact strategy would depend on the optimizer, but I think +np.inf is a perfectly reasonable sentinel value to use to indicate that function value is "bad" in a generic way. It would be nice if the scipy optimizers handled this consistently. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pav at iki.fi Wed Jun 15 14:53:22 2016 From: pav at iki.fi (Pauli Virtanen) Date: Wed, 15 Jun 2016 18:53:22 +0000 (UTC) Subject: [SciPy-Dev] optimize: what should happen if objective functions return non-finite numbers? References: Message-ID: Wed, 15 Jun 2016 09:19:45 +1000, Andrew Nelson kirjoitti: > Consider the following example which raises an AssertionError: > > import numpy as np from scipy.optimize import minimize > def func1(x): > return np.nan > x0 = np.array([1.3, 0.7, 0.8, 1.9, 1.2]) > res = minimize(func1, x0, method='l-bfgs-b') > assert(res.success = False) The design decision so far has been to not communicate this type of failure with exceptions. Rather, the optimizer should assume the point is out of the domain of the objective function. Whether the optimizer can continue, depends on the method. If it cannot, it should return with success=False, and an appropriate error message set. > minimize simply returns the starting values of: res.x == x0. The reason > I came up with this example is that unsanitised datasets sometimes > contain nan or inf. Thus, if func1 was calculating chi2 and you were > using minimize then the entire fit would appear to succeed (res.success > is True), but the output would be garbage. Why would res.success be true? If it is true when it is clear local minimum is not reached, that is a bug. > import numpy as np from scipy.optimize import curve_fit > def func2(x, a, b, c): > return a * np.exp(-b * x) + c > > def func3(x, a, b, c): > return np.nan > > xdata = np.linspace(0, 4, 50) > y = func2(xdata, 2.5, 1.3, 0.5) > ydata = y + 0.2 * np.random.normal(size=len(xdata)) > > popt, pcov = curve_fit(func3, xdata, ydata) > print(popt) > > Whilst there is a warning (OptimizeWarning: Covariance of the parameters > could not be estimated) it's not a clear indicator that something has > gone wrong. > The behaviour one might expect in both examples could be to see a > ValueError raised if there arenp.nan values returned from the objective > function. I'm not totally sure of what to do if +/- np.inf is returned > (-inf would be a very good global minimum). I think this is a different issue --- the only way curve_fit communicates fit failures in general is via setting the estimated covariances to infinity. This is not so convenient, but that's how it works currently. -- Pauli Virtanen From pav at iki.fi Wed Jun 15 15:02:37 2016 From: pav at iki.fi (Pauli Virtanen) Date: Wed, 15 Jun 2016 19:02:37 +0000 (UTC) Subject: [SciPy-Dev] optimize: what should happen if objective functions return non-finite numbers? References: Message-ID: Wed, 15 Jun 2016 18:53:22 +0000, Pauli Virtanen kirjoitti: [clip] > I think this is a different issue --- the only way curve_fit > communicates fit failures in general is via setting the estimated > covariances to infinity. This is not so convenient, but that's how it > works currently. Sorry, this was wrong --- it's supposed to raise a RuntimeError, iow., works differently from minimize(). However, nan values confuse leastsq() to think it converged --- this can and should be fixed. From andyfaff at gmail.com Wed Jun 15 23:29:49 2016 From: andyfaff at gmail.com (Andrew Nelson) Date: Thu, 16 Jun 2016 13:29:49 +1000 Subject: [SciPy-Dev] optimize: what should happen if objective functions return non-finite numbers? In-Reply-To: References: Message-ID: On 16 June 2016 at 04:53, Pauli Virtanen wrote: > Wed, 15 Jun 2016 09:19:45 +1000, Andrew Nelson kirjoitti: > > Consider the following example which raises an AssertionError: > > > > import numpy as np from scipy.optimize import minimize > > def func1(x): > > return np.nan > > x0 = np.array([1.3, 0.7, 0.8, 1.9, 1.2]) > > res = minimize(func1, x0, method='l-bfgs-b') > > assert(res.success = False) > > > > Whether the optimizer can continue, depends on the method. If it cannot, > it should return with success=False, and an appropriate error message set. > > > minimize simply returns the starting values of: res.x == x0. The reason > > I came up with this example is that unsanitised datasets sometimes > > contain nan or inf. Thus, if func1 was calculating chi2 and you were > > using minimize then the entire fit would appear to succeed (res.success > > is True), but the output would be garbage. > > Why would res.success be true? If it is true when it is clear local > minimum is not reached, that is a bug. In the example above res.success is True. On further inspection both 'L-BFGS-B' and 'CG' give res.success is True, the rest give res.success is False. It's interesting that when I try this with 'COBYLA', then the minimize function never returns. -------------- next part -------------- An HTML attachment was scrubbed... URL: From andyfaff at gmail.com Wed Jun 15 23:36:39 2016 From: andyfaff at gmail.com (Andrew Nelson) Date: Thu, 16 Jun 2016 13:36:39 +1000 Subject: [SciPy-Dev] optimize: what should happen if objective functions return non-finite numbers? In-Reply-To: References: Message-ID: > > > I think this is a different issue --- the only way curve_fit > > communicates fit failures in general is via setting the estimated > > covariances to infinity. This is not so convenient, but that's how it > > works currently. > > Sorry, this was wrong --- it's supposed to raise a RuntimeError, iow., > works differently from minimize(). > > However, nan values confuse leastsq() to think it converged --- this can > and should be fixed. To clarify here - is the expected behaviour that curve_fit and leastsq raise a RuntimeError if the user function returns NaN? What about np.inf, -np.inf? Note: least_squares raises a ValueError if the "Residuals are not finite in the initial point". -------------- next part -------------- An HTML attachment was scrubbed... URL: From pav at iki.fi Thu Jun 16 14:16:46 2016 From: pav at iki.fi (Pauli Virtanen) Date: Thu, 16 Jun 2016 18:16:46 +0000 (UTC) Subject: [SciPy-Dev] optimize: what should happen if objective functions return non-finite numbers? References: Message-ID: Thu, 16 Jun 2016 13:36:39 +1000, Andrew Nelson kirjoitti: > To clarify here - is the expected behaviour that curve_fit and leastsq > raise a RuntimeError if the user function returns NaN? What about > np.inf, -np.inf? > Note: least_squares raises a ValueError if the "Residuals are not finite > in the initial point". Returning NaN in some part of the parameter space does not necessarily mean that the algorithm cannot find a local minimum somewhere else. This is why raising an error immediately if NaN is returned is not necessarily correct. The same for infinities. However, returning NaN may mean that the algorithm cannot continue. This can immediately lead to a convergence failure (the algorithm doesn't know how to continue), but it should be reported in the same way as the algorithm reports all other types of convergence failure. Specifically, you should look at how the different functions handle other error conditions. This is rather varying due to historical reasons: * curve_fit raises a RuntimeError * minimize() returns with success==False * leastsq() raises warnings or errors if full_output==False, or returns with an error code set if full_output==True From bhavicka.7992 at gmail.com Sun Jun 19 05:18:02 2016 From: bhavicka.7992 at gmail.com (Bhavika Tekwani) Date: Sun, 19 Jun 2016 14:48:02 +0530 Subject: [SciPy-Dev] Review pull request #6285: BUG: stats: Inconsistency in the multivariate_normal docstring #6263 Message-ID: Hey everyone, I just submitted a pull request attempting to close issue #6263 regarding the pdf and logpdf methods in multivariate_normal. As I understood - the bug was simply an absence of default parameters in pdf and logpdf methods within class multivariate_normal_gen. I've submitted this change along with a test for default values. Please see the PR here - https://github.com/scipy/scipy/pull/6285 I hope this is correct and I welcome guidance if it is not. Thank you, Bhavika T. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.gommers at gmail.com Sun Jun 19 05:42:59 2016 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Sun, 19 Jun 2016 11:42:59 +0200 Subject: [SciPy-Dev] Review pull request #6285: BUG: stats: Inconsistency in the multivariate_normal docstring #6263 In-Reply-To: References: Message-ID: On Sun, Jun 19, 2016 at 11:18 AM, Bhavika Tekwani wrote: > Hey everyone, > > I just submitted a pull request attempting to close issue #6263 regarding > the pdf and logpdf methods in multivariate_normal. > As I understood - the bug was simply an absence of default parameters in > pdf and logpdf methods within class multivariate_normal_gen. > > I've submitted this change along with a test for default values. > > Please see the PR here - https://github.com/scipy/scipy/pull/6285 > > I hope this is correct and I welcome guidance if it is not. > Hi Bhavika, thanks for the PR. And welcome! Looks like you did everything right. Normally for bugfixes it's not necessary to explain them on this mailing list; for new features and backwards incompatible changes it is. I'll go review your PR in a minute. Cheers, Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From evgeny.burovskiy at gmail.com Mon Jun 20 08:51:33 2016 From: evgeny.burovskiy at gmail.com (Evgeni Burovski) Date: Mon, 20 Jun 2016 13:51:33 +0100 Subject: [SciPy-Dev] maintenance/0.18.x tagged Message-ID: Hi, 0.18.x has been tagged and master is now open for 0.19.0 development. I'll upload the source tarballs to GH releases shortly. Cheers, Evgeni From evgeny.burovskiy at gmail.com Mon Jun 20 09:31:44 2016 From: evgeny.burovskiy at gmail.com (Evgeni Burovski) Date: Mon, 20 Jun 2016 14:31:44 +0100 Subject: [SciPy-Dev] scipy 0.18 release candidate 1 Message-ID: Hi, I'm pleased to announce the availability of the first release candidate for scipy 0.18.0. Please try this release and report any issues on Github tracker, https://github.com/scipy/scipy, or scipy-dev mailing list. Source tarballs and release notes are available from Github releases, https://github.com/scipy/scipy/releases/tag/v0.18.0rc1 Please note that this is a source-only release. We do not provide Windows binaries for this release. OS X and Linux wheels will be provided for the final release. The current release schedule is 27 June: rc2 (if necessary) 11 July: final release Thanks to everyone who contributed to this release! Cheers, Evgeni A part of the release notes follows: ========================== SciPy 0.18.0 Release Notes ========================== .. note:: Scipy 0.18.0 is not released yet! .. contents:: SciPy 0.18.0 is the culmination of 6 months of hard work. It contains many new features, numerous bug-fixes, improved test coverage and better documentation. There have been a number of deprecations and API changes in this release, which are documented below. All users are encouraged to upgrade to this release, as there are a large number of bug-fixes and optimizations. Moreover, our development attention will now shift to bug-fix releases on the 0.19.x branch, and on adding new features on the master branch. This release requires Python 2.7 or 3.4-3.5 and NumPy 1.7.1 or greater. Highlights of this release include: - - A new ODE solver for two-point boundary value problems, `scipy.optimize.solve_bvp`. - - A new class, `CubicSpline`, for cubic spline interpolation of data. - - N-dimensional tensor product polynomials, `scipy.interpolate.NdPPoly`. - - Spherical Voronoi diagrams, `scipy.spatial.SphericalVoronoi`. - - Support for discrete-time linear systems, `scipy.signal.dlti`. New features ============ `scipy.integrate` improvements - ------------------------------ A solver of two-point boundary value problems for ODE systems has been implemented in `scipy.integrate.solve_bvp`. The solver allows for non-separated boundary conditions, unknown parameters and certain singular terms. It finds a C1 continious solution using a fourth-order collocation algorithm. `scipy.interpolate` improvements - -------------------------------- Cubic spline interpolation is now available via `scipy.interpolate.CubicSpline`. This class represents a piecewise cubic polynomial passing through given points and C2 continuous. It is represented in the standard polynomial basis on each segment. A representation of n-dimensional tensor product piecewise polynomials is available as the `scipy.interpolate.NdPPoly` class. Univariate piecewise polynomial classes, `PPoly` and `Bpoly`, can now be evaluated on periodic domains. Use ``extrapolate="periodic"`` keyword argument for this. `scipy.fftpack` improvements - ---------------------------- `scipy.fftpack.next_fast_len` function computes the next "regular" number for FFTPACK. Padding the input to this length can give significant performance increase for `scipy.fftpack.fft`. `scipy.signal` improvements - --------------------------- Resampling using polyphase filtering has been implemented in the function `scipy.signal.resample_poly`. This method upsamples a signal, applies a zero-phase low-pass FIR filter, and downsamples using `scipy.signal.upfirdn` (which is also new in 0.18.0). This method can be faster than FFT-based filtering provided by `scipy.signal.resample` for some signals. `scipy.signal.firls`, which constructs FIR filters using least-squares error minimization, was added. `scipy.signal.sosfiltfilt`, which does forward-backward filtering like `scipy.signal.filtfilt` but for second-order sections, was added. Discrete-time linear systems ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ `scipy.signal.dlti` provides an implementation of discrete-time linear systems. Accordingly, the `StateSpace`, `TransferFunction` and `ZerosPolesGain` classes have learned a the new keyword, `dt`, which can be used to create discrete-time instances of the corresponding system representation. `scipy.sparse` improvements - --------------------------- The functions `sum`, `max`, `mean`, `min`, `transpose`, and `reshape` in `scipy.sparse` have had their signatures augmented with additional arguments and functionality so as to improve compatibility with analogously defined functions in `numpy`. Sparse matrices now have a `count_nonzero` method, which counts the number of nonzero elements in the matrix. Unlike `getnnz()` and ``nnz`` propety, which return the number of stored entries (the length of the data attribute), this method counts the actual number of non-zero entries in data. `scipy.optimize` improvements - ----------------------------- The implementation of Nelder-Mead minimization, `scipy.minimize(..., method="Nelder-Mead")`, obtained a new keyword, `initial_simplex`, which can be used to specify the initial simplex for the optimization process. Initial step size selection in CG and BFGS minimizers has been improved. We expect that this change will improve numeric stability of optimization in some cases. See pull request gh-5536 for details. Handling of infinite bounds in SLSQP optimization has been improved. We expect that this change will improve numeric stability of optimization in the some cases. See pull request gh-6024 for details. A large suite of global optimization benchmarks has been added to ``scipy/benchmarks/go_benchmark_functions``. See pull request gh-4191 for details. Nelder-Mead and Powell minimization will now only set defaults for maximum iterations or function evaluations if neither limit is set by the caller. In some cases with a slow converging function and only 1 limit set, the minimization may continue for longer than with previous versions and so is more likely to reach convergence. See issue gh-5966. `scipy.stats` improvements - -------------------------- Trapezoidal distribution has been implemented as `scipy.stats.trapz`. Skew normal distribution has been implemented as `scipy.stats.skewnorm`. Burr type XII distribution has been implemented as `scipy.stats.burr12`. Three- and four-parameter kappa distributions have been implemented as `scipy.stats.kappa3` and `scipy.stats.kappa4`, respectively. New `scipy.stats.iqr` function computes the interquartile region of a distribution. Random matrices ~~~~~~~~~~~~~~~ `scipy.stats.special_ortho_group` and `scipy.stats.ortho_group` provide generators of random matrices in the SO(N) and O(N) groups, respectively. They generate matrices in the Haar distribution, the only uniform distribution on these group manifolds. `scipy.stats.random_correlation` provides a generator for random correlation matrices, given specified eigenvalues. `scipy.linalg` improvements - --------------------------- `scipy.linalg.svd` gained a new keyword argument, ``lapack_driver``. Available drivers are ``gesdd`` (default) and ``gesvd``. `scipy.linalg.lapack.ilaver` returns the version of the LAPACK library SciPy links to. `scipy.spatial` improvements - ---------------------------- Boolean distances, `scipy.spatial.pdist`, have been sped up. Improvements vary by the function and the input size. In many cases, one can expect a speed-up of x2--x10. New class `scipy.spatial.SphericalVoronoi` constructs Voronoi diagrams on the surface of a sphere. See pull request gh-5232 for details. `scipy.cluster` improvements - ---------------------------- A new clustering algorithm, the nearest neighbor chain algorithm, has been implemented for `scipy.cluster.hierarchy.linkage`. As a result, one can expect a significant algorithmic improvement (:math:`O(N^2)` instead of :math:`O(N^3)`) for several linkage methods. `scipy.special` improvements - ---------------------------- The new function `scipy.special.loggamma` computes the principal branch of the logarithm of the Gamma function. For real input, ``loggamma`` is compatible with `scipy.special.gammaln`. For complex input, it has more consistent behavior in the complex plane and should be preferred over ``gammaln``. Vectorized forms of spherical Bessel functions have been implemented as `scipy.special.spherical_jn`, `scipy.special.spherical_kn`, `scipy.special.spherical_in` and `scipy.special.spherical_yn`. They are recommended for use over ``sph_*`` functions, which are now deprecated. Several special functions have been extended to the complex domain and/or have seen domain/stability improvements. This includes `spence`, `digamma`, `log1p` and several others. Deprecated features =================== The cross-class properties of `lti` systems have been deprecated. The following properties/setters will raise a `DeprecationWarning`: Name - (accessing/setting raises warning) - (setting raises warning) * StateSpace - (`num`, `den`, `gain`) - (`zeros`, `poles`) * TransferFunction (`A`, `B`, `C`, `D`, `gain`) - (`zeros`, `poles`) * ZerosPolesGain (`A`, `B`, `C`, `D`, `num`, `den`) - () Spherical Bessel functions, ``sph_in``, ``sph_jn``, ``sph_kn``, ``sph_yn``, ``sph_jnyn`` and ``sph_inkn`` have been deprecated in favor of `scipy.special.spherical_jn` and ``spherical_kn``, ``spherical_yn``, ``spherical_in``. The following functions in `scipy.constants` are deprecated: ``C2K``, ``K2C``, ``C2F``, ``F2C``, ``F2K`` and ``K2F``. They are superceded by a new function `scipy.constants.convert_temperature` that can perform all those conversions plus to/from the Rankine temperature scale. Backwards incompatible changes ============================== `scipy.optimize` - ---------------- The convergence criterion for ``optimize.bisect``, ``optimize.brentq``, ``optimize.brenth``, and ``optimize.ridder`` now works the same as ``numpy.allclose``. `scipy.ndimage` - --------------- The offset in ``ndimage.iterpolation.affine_transform`` is now consistently added after the matrix is applied, independent of if the matrix is specified using a one-dimensional or a two-dimensional array. `scipy.stats` - ------------- ``stats.ks_2samp`` used to return nonsensical values if the input was not real or contained nans. It now raises an exception for such inputs. Several deprecated methods of `scipy.stats` distributions have been removed: ``est_loc_scale``, ``vecfunc``, ``veccdf`` and ``vec_generic_moment``. Deprecated functions ``nanmean``, ``nanstd`` and ``nanmedian`` have been removed from `scipy.stats`. These functions were deprecated in scipy 0.15.0 in favor of their `numpy` equivalents. A bug in the ``rvs()`` method of the distributions in `scipy.stats` has been fixed. When arguments to ``rvs()`` were given that were shaped for broadcasting, in many cases the returned random samples were not random. A simple example of the problem is ``stats.norm.rvs(loc=np.zeros(10))``. Because of the bug, that call would return 10 identical values. The bug only affected code that relied on the broadcasting of the shape, location and scale parameters. The ``rvs()`` method also accepted some arguments that it should not have. There is a potential for backwards incompatibility in cases where ``rvs()`` accepted arguments that are not, in fact, compatible with broadcasting. An example is stats.gamma.rvs([2, 5, 10, 15], size=(2,2)) The shape of the first argument is not compatible with the requested size, but the function still returned an array with shape (2, 2). In scipy 0.18, that call generates a ``ValueError``. `scipy.io` - ---------- `scipy.io.netcdf` masking now gives precedence to the ``_FillValue`` attribute over the ``missing_value`` attribute, if both are given. Also, data are only treated as missing if they match one of these attributes exactly: values that differ by roundoff from ``_FillValue`` or ``missing_value`` are no longer treated as missing values. `scipy.interpolate` - ------------------- `scipy.interpolate.PiecewisePolynomial` class has been removed. It has been deprecated in scipy 0.14.0, and `scipy.interpolate.BPoly.from_derivatives` serves as a drop-in replacement. Other changes ============= Scipy now uses ``setuptools`` for its builds instead of plain distutils. This fixes usage of ``install_requires='scipy'`` in the ``setup.py`` files of projects that depend on Scipy (see Numpy issue gh-6551 for details). It potentially affects the way that build/install methods for Scipy itself behave though. Please report any unexpected behavior on the Scipy issue tracker. PR `#6240 `__ changes the interpretation of the `maxfun` option in `L-BFGS-B` based routines in the `scipy.optimize` module. An `L-BFGS-B` search consists of multiple iterations, with each iteration consisting of one or more function evaluations. Whereas the old search strategy terminated immediately upon reaching `maxfun` function evaluations, the new strategy allows the current iteration to finish despite reaching `maxfun`. The bundled copy of Qhull in the `scipy.spatial` subpackage has been upgraded to version 2015.2. The bundled copy of ARPACK in the `scipy.sparse.linalg` subpackage has been upgraded to arpack-ng 3.3.0. The bundled copy of SuperLU in the `scipy.sparse` subpackage has been upgraded to version 5.1.1. Authors ======= * @endolith * @yanxun827 + * @kleskjr + * @MYheavyGo + * @solarjoe + * Gregory Allen + * Gilles Aouizerate + * Tom Augspurger + * Henrik Bengtsson + * Felix Berkenkamp * Per Brodtkorb * Lars Buitinck * Daniel Bunting + * Evgeni Burovski * CJ Carey * Tim Cera * Grey Christoforo + * Robert Cimrman * Philip DeBoer + * Yves Delley + * D?vid Bodn?r + * Ion Elberdin + * Gabriele Farina + * Yu Feng * Andrew Fowlie + * Joseph Fox-Rabinovitz * Simon Gibbons + * Neil Girdhar + * Kolja Glogowski + * Christoph Gohlke * Ralf Gommers * Todd Goodall + * Johnnie Gray + * Alex Griffing * Olivier Grisel * Thomas Haslwanter + * Michael Hirsch + * Derek Homeier * Golnaz Irannejad + * Marek Jacob + * InSuk Joung + * Tetsuo Koyama + * Eugene Krokhalev + * Eric Larson * Denis Laxalde * Antony Lee * Jerry Li + * Henry Lin + * Nelson Liu + * Lo?c Est?ve * Lei Ma + * Osvaldo Martin + * Stefano Martina + * Nikolay Mayorov * Matthieu Melot + * Sturla Molden * Eric Moore * Alistair Muldal + * Maniteja Nandana * Tavi Nathanson + * Andrew Nelson * Joel Nothman * Behzad Nouri * Nikolai Nowaczyk + * Juan Nunez-Iglesias + * Ted Pudlik * Eric Quintero * Yoav Ram * Jonas Rauber + * Tyler Reddy + * Juha Remes * Garrett Reynolds + * Ariel Rokem + * Fabian Rost + * Bill Sacks + * Jona Sassenhagen + * Marcello Seri + * Sourav Singh + * Martin Spacek + * S?ren Fuglede J?rgensen + * Bhavika Tekwani + * Martin Thoma + * Sam Tygier + * Meet Udeshi + * Utkarsh Upadhyay * Bram Vandekerckhove + * Sebasti?n Vanrell + * Ze Vinicius + * Pauli Virtanen * Stefan van der Walt * Warren Weckesser * Jakub Wilk + * Josh Wilson * Phillip J. Wolfram + * Nathan Woods * Haochen Wu * G Young + A total of 99 people contributed to this release. People with a "+" by their names contributed a patch for the first time. This list of names is automatically generated, and may not be fully complete. From matthew.brett at gmail.com Mon Jun 20 23:27:21 2016 From: matthew.brett at gmail.com (Matthew Brett) Date: Mon, 20 Jun 2016 20:27:21 -0700 Subject: [SciPy-Dev] [Numpy-discussion] scipy 0.18 release candidate 1 In-Reply-To: References: Message-ID: Hi, On Mon, Jun 20, 2016 at 6:31 AM, Evgeni Burovski wrote: > Hi, > > I'm pleased to announce the availability of the first release > candidate for scipy 0.18.0. > Please try this release and report any issues on Github tracker, > https://github.com/scipy/scipy, or scipy-dev mailing list. > Source tarballs and release notes are available from Github releases, > https://github.com/scipy/scipy/releases/tag/v0.18.0rc1 > > Please note that this is a source-only release. We do not provide > Windows binaries for this release. OS X and Linux wheels will be > provided for the final release. > > The current release schedule is > > 27 June: rc2 (if necessary) > 11 July: final release > > Thanks to everyone who contributed to this release! > > Cheers, > > Evgeni > > > A part of the release notes follows: > > > > ========================== > SciPy 0.18.0 Release Notes > ========================== > > .. note:: Scipy 0.18.0 is not released yet! > > .. contents:: > > SciPy 0.18.0 is the culmination of 6 months of hard work. It contains > many new features, numerous bug-fixes, improved test coverage and > better documentation. There have been a number of deprecations and > API changes in this release, which are documented below. All users > are encouraged to upgrade to this release, as there are a large number > of bug-fixes and optimizations. Moreover, our development attention > will now shift to bug-fix releases on the 0.19.x branch, and on adding > new features on the master branch. > > This release requires Python 2.7 or 3.4-3.5 and NumPy 1.7.1 or greater. Thanks a lot for taking on the release. I put the manylinux1 and OSX wheel building into a single repo to test 64- and 32-bit linux wheels. There's a test run with the 0.18.0rc1 code here: https://travis-ci.org/MacPython/scipy-wheels/builds/139084454 For Python 3 I am getting these errors: https://github.com/scipy/scipy/issues/6292 For all 32-bit builds I am getting this error: https://github.com/scipy/scipy/issues/6093 For the Python 3 32-bit builds I am also getting this error: https://github.com/scipy/scipy/issues/6101 For the builds that succeeded without failure (all OSX and manylinux1 for 64 bit Python 2.7), you can test with: python -m pip install -U pip pip install --trusted-host wheels.scipy.org -f https://wheels.scipy.org -U --pre scipy Thanks again, sorry for the tiring news, Matthew From ralf.gommers at gmail.com Tue Jun 21 15:20:19 2016 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Tue, 21 Jun 2016 21:20:19 +0200 Subject: [SciPy-Dev] [Numpy-discussion] scipy 0.18 release candidate 1 In-Reply-To: References: Message-ID: On Tue, Jun 21, 2016 at 7:29 PM, Evgeni Burovski wrote: > On Tue, Jun 21, 2016 at 4:27 AM, Matthew Brett > wrote: > > Hi, > > > > On Mon, Jun 20, 2016 at 6:31 AM, Evgeni Burovski > > wrote: > >> Hi, > >> > >> I'm pleased to announce the availability of the first release > >> candidate for scipy 0.18.0. > >> Please try this release and report any issues on Github tracker, > >> https://github.com/scipy/scipy, or scipy-dev mailing list. > >> Source tarballs and release notes are available from Github releases, > >> https://github.com/scipy/scipy/releases/tag/v0.18.0rc1 > >> > >> Please note that this is a source-only release. We do not provide > >> Windows binaries for this release. OS X and Linux wheels will be > >> provided for the final release. > >> > >> The current release schedule is > >> > >> 27 June: rc2 (if necessary) > >> 11 July: final release > >> > >> Thanks to everyone who contributed to this release! > >> > >> Cheers, > >> > >> Evgeni > >> > >> > >> A part of the release notes follows: > >> > >> > >> > >> ========================== > >> SciPy 0.18.0 Release Notes > >> ========================== > >> > >> .. note:: Scipy 0.18.0 is not released yet! > >> > >> .. contents:: > >> > >> SciPy 0.18.0 is the culmination of 6 months of hard work. It contains > >> many new features, numerous bug-fixes, improved test coverage and > >> better documentation. There have been a number of deprecations and > >> API changes in this release, which are documented below. All users > >> are encouraged to upgrade to this release, as there are a large number > >> of bug-fixes and optimizations. Moreover, our development attention > >> will now shift to bug-fix releases on the 0.19.x branch, and on adding > >> new features on the master branch. > >> > >> This release requires Python 2.7 or 3.4-3.5 and NumPy 1.7.1 or greater. > > > > Thanks a lot for taking on the release. > > > > I put the manylinux1 and OSX wheel building into a single repo to test > > 64- and 32-bit linux wheels. There's a test run with the 0.18.0rc1 > > code here: > > > > https://travis-ci.org/MacPython/scipy-wheels/builds/139084454 > > > > For Python 3 I am getting these errors: > > https://github.com/scipy/scipy/issues/6292 > > > > For all 32-bit builds I am getting this error: > > https://github.com/scipy/scipy/issues/6093 > > > > For the Python 3 32-bit builds I am also getting this error: > > https://github.com/scipy/scipy/issues/6101 > > > > For the builds that succeeded without failure (all OSX and manylinux1 > > for 64 bit Python 2.7), you can test with: > > > > python -m pip install -U pip > > pip install --trusted-host wheels.scipy.org -f > > https://wheels.scipy.org -U --pre scipy > > > > Thanks again, sorry for the tiring news, > > > > Matthew > > _______________________________________________ > > NumPy-Discussion mailing list > > NumPy-Discussion at scipy.org > > https://mail.scipy.org/mailman/listinfo/numpy-discussion > > > > Thanks Matthew for testing and reporting these! > Indeed, thanks! Would it make sense to put these wheels on PyPI, so people can test them with ``pip install scipy --pre``? We do that with Numpy wheels as well now. Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From evgeny.burovskiy at gmail.com Tue Jun 21 15:39:11 2016 From: evgeny.burovskiy at gmail.com (Evgeni Burovski) Date: Tue, 21 Jun 2016 20:39:11 +0100 Subject: [SciPy-Dev] [Numpy-discussion] scipy 0.18 release candidate 1 In-Reply-To: References: Message-ID: > Would it make sense to put these wheels on PyPI, so people can test them > with ``pip install scipy --pre``? We do that with Numpy wheels as well now. Is there some incantation at upload time to mark them as pre-release, so that `pip install scipy` does not pick them up? From njs at pobox.com Tue Jun 21 15:46:01 2016 From: njs at pobox.com (Nathaniel Smith) Date: Tue, 21 Jun 2016 12:46:01 -0700 Subject: [SciPy-Dev] [Numpy-discussion] scipy 0.18 release candidate 1 In-Reply-To: References: Message-ID: It's keyed off the version number -- sdists or wheels whose version number contains alpha/beta/rc/dev tags are skipped by pip by default, unless --pre was passed. -n On Jun 21, 2016 12:39 PM, "Evgeni Burovski" wrote: > > > > Would it make sense to put these wheels on PyPI, so people can test them > > with ``pip install scipy --pre``? We do that with Numpy wheels as well > now. > > Is there some incantation at upload time to mark them as pre-release, > so that `pip install scipy` does not pick them up? > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > https://mail.scipy.org/mailman/listinfo/scipy-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthew.brett at gmail.com Tue Jun 21 16:16:18 2016 From: matthew.brett at gmail.com (Matthew Brett) Date: Tue, 21 Jun 2016 13:16:18 -0700 Subject: [SciPy-Dev] [Numpy-discussion] scipy 0.18 release candidate 1 In-Reply-To: References: Message-ID: On Tue, Jun 21, 2016 at 12:46 PM, Nathaniel Smith wrote: > It's keyed off the version number -- sdists or wheels whose version number > contains alpha/beta/rc/dev tags are skipped by pip by default, unless --pre > was passed. > > -n > > On Jun 21, 2016 12:39 PM, "Evgeni Burovski" > wrote: >> >> >> >> > Would it make sense to put these wheels on PyPI, so people can test them >> > with ``pip install scipy --pre``? We do that with Numpy wheels as well >> > now. We don't have built manylinux wheels for Python 3 because of the test failures, but the incantation to upload the wheels that are built is (I think): git clone https://github.com/MacPython/terryfy.git python terryfy/wheel-uploader -r warehouse -v -s -t manylinux1 scipy 0.18.0rc1 python terryfy/wheel-uploader -r warehouse -v -s -t macosx scipy 0.18.0rc1 You'll also need a 'warehouse' section in your ~/.pypirc, as in: [distutils] index-servers = pypi warehouse [pypi] username: my_user password: my_password [warehouse] repository: https://upload.pypi.io/legacy/ username: my_warehouse_user password: my_warehouse_password and installations of "twine" and "beautifulsoup4". Cheers, Matthew From evgeny.burovskiy at gmail.com Tue Jun 21 17:37:47 2016 From: evgeny.burovskiy at gmail.com (Evgeni Burovski) Date: Tue, 21 Jun 2016 22:37:47 +0100 Subject: [SciPy-Dev] [Numpy-discussion] scipy 0.18 release candidate 1 In-Reply-To: References: Message-ID: On Tue, Jun 21, 2016 at 9:16 PM, Matthew Brett wrote: > On Tue, Jun 21, 2016 at 12:46 PM, Nathaniel Smith wrote: >> It's keyed off the version number -- sdists or wheels whose version number >> contains alpha/beta/rc/dev tags are skipped by pip by default, unless --pre >> was passed. >> >> -n >> >> On Jun 21, 2016 12:39 PM, "Evgeni Burovski" >> wrote: >>> >>> >>> >>> > Would it make sense to put these wheels on PyPI, so people can test them >>> > with ``pip install scipy --pre``? We do that with Numpy wheels as well >>> > now. > > We don't have built manylinux wheels for Python 3 because of the test > failures, but the incantation to upload the wheels that are built is > (I think): > > git clone https://github.com/MacPython/terryfy.git > python terryfy/wheel-uploader -r warehouse -v -s -t manylinux1 scipy 0.18.0rc1 > python terryfy/wheel-uploader -r warehouse -v -s -t macosx scipy 0.18.0rc1 > > You'll also need a 'warehouse' section in your ~/.pypirc, as in: > > [distutils] > index-servers = > pypi > warehouse > > [pypi] > username: my_user > password: my_password > > [warehouse] > repository: https://upload.pypi.io/legacy/ > username: my_warehouse_user > password: my_warehouse_password > > and installations of "twine" and "beautifulsoup4". > > Cheers, > > Matthew Thanks! One question --- equally applicable to both pre-release and final releases: Security. If we download the wheels from the build farm and then upload to PyPI, how can a user check that what they download has not be tampered with? For source tarballs (and previously, Windows installers), we PGP sign the git tag and include checksums in the README file. This way they can at least verify the checksums. From njs at pobox.com Tue Jun 21 20:23:59 2016 From: njs at pobox.com (Nathaniel Smith) Date: Tue, 21 Jun 2016 17:23:59 -0700 Subject: [SciPy-Dev] [Numpy-discussion] scipy 0.18 release candidate 1 In-Reply-To: References: Message-ID: On Jun 21, 2016 14:37, "Evgeni Burovski" wrote: > > One question --- equally applicable to both pre-release and final > releases: Security. If we download the wheels from the build farm and > then upload to PyPI, how can a user check that what they download has > not be tampered with? > > For source tarballs (and previously, Windows installers), we PGP sign > the git tag and include checksums in the README file. This way they > can at least verify the checksums. I'm dubious that this really accomplishes much: https://caremad.io/2013/07/packaging-signing-not-holy-grail/ But, if you want to include checksums in the README, you can do that by just downloading the build farm wheels and checksumming them. This doesn't protect against a compromised build farm, but neither does anything else. (Even PGP signing doesn't protect you if your release manager's laptop is compromised, and realistically any laptop that has write permissions on the repository could add a backdoor with no one noticing, just by pushing it directly to master with an innocuous commit message.) OTOH even this crude download and checksum approach does at least make life more difficult for anyone who tries to compromise the packages later after the checksum is made. -n -------------- next part -------------- An HTML attachment was scrubbed... URL: From andyfaff at gmail.com Tue Jun 21 23:08:32 2016 From: andyfaff at gmail.com (Andrew Nelson) Date: Wed, 22 Jun 2016 13:08:32 +1000 Subject: [SciPy-Dev] [scipy/scipy] 0.18.0 release candidate 1 In-Reply-To: References: Message-ID: The release candidate passes all the tests on my machine. OSX 10.9.5 python 3.4.4 (conda) numpy 1.12.0.dev0+6ab89b8 On 20 June 2016 at 23:17, Evgeni Burovski wrote: > This is the first release candidate for scipy 0.18.0. See > https://github.com/scipy/scipy/blob/maintenance/0.18.x/doc/release/0.18.0-notes.rst > for the release notes. > > Please note that this is a source-only release. > > If no issues are reported for this release, it will become the final > 0.18.0 release. Issues can be reported via Github or on the scipy-dev > mailing list (see http://scipy.org/scipylib/mailing-lists.html). > > ? > You are receiving this because you are subscribed to this thread. > View it on GitHub > or mute the thread > > . > -- _____________________________________ Dr. Andrew Nelson _____________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From evgeny.burovskiy at gmail.com Wed Jun 22 01:52:56 2016 From: evgeny.burovskiy at gmail.com (Evgeni Burovski) Date: Wed, 22 Jun 2016 06:52:56 +0100 Subject: [SciPy-Dev] [scipy/scipy] 0.18.0 release candidate 1 In-Reply-To: References: Message-ID: On Jun 22, 2016 6:08 AM, "Andrew Nelson" wrote: > > The release candidate passes all the tests on my machine. > > OSX 10.9.5 > python 3.4.4 (conda) > numpy 1.12.0.dev0+6ab89b8 Thank you for testing it Andrew! -------------- next part -------------- An HTML attachment was scrubbed... URL: From pav at iki.fi Thu Jun 23 14:22:37 2016 From: pav at iki.fi (Pauli Virtanen) Date: Thu, 23 Jun 2016 18:22:37 +0000 (UTC) Subject: [SciPy-Dev] [Numpy-discussion] scipy 0.18 release candidate 1 References: Message-ID: Tue, 21 Jun 2016 17:23:59 -0700, Nathaniel Smith kirjoitti: > On Jun 21, 2016 14:37, "Evgeni Burovski" > wrote: >> >> One question --- equally applicable to both pre-release and final >> releases: Security. If we download the wheels from the build farm and >> then upload to PyPI, how can a user check that what they download has >> not be tampered with? >> >> For source tarballs (and previously, Windows installers), we PGP sign >> the git tag and include checksums in the README file. This way they can >> at least verify the checksums. > > I'm dubious that this really accomplishes much: > https://caremad.io/2013/07/packaging-signing-not-holy-grail/ Well, security is best done in depth, and signing source tarballs is little extra work. That article talks about package signing, but it is only from the point of view of a random user. If it later becomes necessary to try to find out whether some tarballs are compromised by someone replacing release files on Github (or sourceforge injecting adware) etc., this is possible for me to do. I have my own key, and the keys by Ralf and Evgeni that I know are with high likelihood valid (assuming their laptops are not compromised). -- Pauli Virtanen From njs at pobox.com Thu Jun 23 14:47:37 2016 From: njs at pobox.com (Nathaniel Smith) Date: Thu, 23 Jun 2016 11:47:37 -0700 Subject: [SciPy-Dev] [Numpy-discussion] scipy 0.18 release candidate 1 In-Reply-To: References: Message-ID: On Jun 23, 2016 11:23 AM, "Pauli Virtanen" wrote: > > Tue, 21 Jun 2016 17:23:59 -0700, Nathaniel Smith kirjoitti: > > > On Jun 21, 2016 14:37, "Evgeni Burovski" > > wrote: > >> > >> One question --- equally applicable to both pre-release and final > >> releases: Security. If we download the wheels from the build farm and > >> then upload to PyPI, how can a user check that what they download has > >> not be tampered with? > >> > >> For source tarballs (and previously, Windows installers), we PGP sign > >> the git tag and include checksums in the README file. This way they can > >> at least verify the checksums. > > > > I'm dubious that this really accomplishes much: > > https://caremad.io/2013/07/packaging-signing-not-holy-grail/ > > Well, security is best done in depth, and signing source tarballs is > little extra work. > > That article talks about package signing, but it is only from the point > of view of a random user. > > If it later becomes necessary to try to find out whether some tarballs > are compromised by someone replacing release files on Github (or > sourceforge injecting adware) etc., this is possible for me to do. I have > my own key, and the keys by Ralf and Evgeni that I know are with high > likelihood valid (assuming their laptops are not compromised). I believe the question was specifically about wheels that aren't being built by any of those three people though? But anyway, yeah, that is the main situation where this kind of package signing might help, and which I addressed in the second half of the email :-). But note that it would also work just as well to, say, keep a text file in the scipy repo that has the sha256 of every file uploaded to pypi. (Maybe even better, because someone who attacked pypi could delete the PGP signatures to confuse matters, and do you have backups?) -n -------------- next part -------------- An HTML attachment was scrubbed... URL: From pav at iki.fi Thu Jun 23 14:55:12 2016 From: pav at iki.fi (Pauli Virtanen) Date: Thu, 23 Jun 2016 18:55:12 +0000 (UTC) Subject: [SciPy-Dev] [Numpy-discussion] scipy 0.18 release candidate 1 References: Message-ID: Thu, 23 Jun 2016 11:47:37 -0700, Nathaniel Smith kirjoitti: [clip] > I believe the question was specifically about wheels that aren't being > built by any of those three people though? But anyway, yeah, that is the > main situation where this kind of package signing might help, and which > I addressed in the second half of the email :-). But note that it would > also work just as well to, say, keep a text file in the scipy repo that > has the sha256 of every file uploaded to pypi. (Maybe even better, > because someone who attacked pypi could delete the PGP signatures to > confuse matters, and do you have backups?) How do I know one of these people pushed the commit that changed the checksums to the Scipy repository? PGP signatures do add stronger guarantees than just trusting Github, provided they you know the people whose keys are in question. From njs at pobox.com Thu Jun 23 15:17:36 2016 From: njs at pobox.com (Nathaniel Smith) Date: Thu, 23 Jun 2016 12:17:36 -0700 Subject: [SciPy-Dev] [Numpy-discussion] scipy 0.18 release candidate 1 In-Reply-To: References: Message-ID: On Thu, Jun 23, 2016 at 11:55 AM, Pauli Virtanen wrote: > Thu, 23 Jun 2016 11:47:37 -0700, Nathaniel Smith kirjoitti: > [clip] >> I believe the question was specifically about wheels that aren't being >> built by any of those three people though? But anyway, yeah, that is the >> main situation where this kind of package signing might help, and which >> I addressed in the second half of the email :-). But note that it would >> also work just as well to, say, keep a text file in the scipy repo that >> has the sha256 of every file uploaded to pypi. (Maybe even better, >> because someone who attacked pypi could delete the PGP signatures to >> confuse matters, and do you have backups?) > > How do I know one of these people pushed the commit that changed the > checksums to the Scipy repository? Because it was pushed by their SSH key at the same time as they were doing the release, and then replicated to people's computers all over the world, making it impossible for anyone (even them, or even people who later steal their SSH/PGP keys) to alter later without creating incriminating entries in 'git log'. (This doesn't even require trusting github, really, so long as you trust that the people doing the release *did* intentionally look at this file and add some entries -- as long as you know that they did, and you know that only one entry was ever made to the file, then it must have been their entry.) > PGP signatures do add stronger guarantees than just trusting Github, > provided they you know the people whose keys are in question. Sure, in some situations. The main points I wanted to make are just (a) PGP-signing releases is less important than many people think, because it only helps in certain narrow situations (like trying to do forensics after an exploit is noticed), and (b) for those particular situations, there are several options that work fine, so we shouldn't stress out about PGP signatures -- if they work, great, if not, then there are other options that have slightly different behavior in edge cases but that still address the same threat model in an adequate way. -n -- Nathaniel J. Smith -- https://vorpus.org From evgeny.burovskiy at gmail.com Thu Jun 23 15:34:21 2016 From: evgeny.burovskiy at gmail.com (Evgeni Burovski) Date: Thu, 23 Jun 2016 20:34:21 +0100 Subject: [SciPy-Dev] [Numpy-discussion] scipy 0.18 release candidate 1 In-Reply-To: References: Message-ID: OK, here's what I'm going to do: I'll download the wheels from Matthew's build farm, checksum them along with the source tarballs, and add the checksums to the README file which is clearsigned with my PGP signature. That file gets uploaded to PyPI, Github releases and sent along with the release announcement to a bunch of mailing lists. (like this, https://mail.scipy.org/pipermail/scipy-dev/2016-January/021189.html) AFAICS, this would cover the main vectors, apart from (i) the build farm producing malicious stuff, (ii) RM or RM's laptop doing what it shouldn't be doing, or (iii) someone patching the wheels en route from the build farm to RM's laptop. I don't see how to address two first points or whether we actually need to address those. The third one can be taken care of by checksumming the wheels on the build farm, so that RM can verify them on before uploading. This is probably not too hard to do with some tweaks to MacPython's build scripts and/or terryfy download machinery Matthew described upthread (I'm still to figure out how to use that machinery, but that's separate). On Thu, Jun 23, 2016 at 7:55 PM, Pauli Virtanen wrote: > Thu, 23 Jun 2016 11:47:37 -0700, Nathaniel Smith kirjoitti: > [clip] >> I believe the question was specifically about wheels that aren't being >> built by any of those three people though? But anyway, yeah, that is the >> main situation where this kind of package signing might help, and which >> I addressed in the second half of the email :-). But note that it would >> also work just as well to, say, keep a text file in the scipy repo that >> has the sha256 of every file uploaded to pypi. (Maybe even better, >> because someone who attacked pypi could delete the PGP signatures to >> confuse matters, and do you have backups?) > > How do I know one of these people pushed the commit that changed the > checksums to the Scipy repository? > > PGP signatures do add stronger guarantees than just trusting Github, > provided they you know the people whose keys are in question. > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > https://mail.scipy.org/mailman/listinfo/scipy-dev From charlesr.harris at gmail.com Thu Jun 23 18:36:42 2016 From: charlesr.harris at gmail.com (Charles R Harris) Date: Thu, 23 Jun 2016 16:36:42 -0600 Subject: [SciPy-Dev] [Numpy-discussion] scipy 0.18 release candidate 1 In-Reply-To: References: Message-ID: On Thu, Jun 23, 2016 at 1:34 PM, Evgeni Burovski wrote: > OK, here's what I'm going to do: I'll download the wheels from > Matthew's build farm, checksum them along with the source tarballs, > and add the checksums to the README file which is clearsigned with my > PGP signature. > That file gets uploaded to PyPI, Github releases and sent along with > the release announcement to a bunch of mailing lists. > (like this, > https://mail.scipy.org/pipermail/scipy-dev/2016-January/021189.html) > > AFAICS, this would cover the main vectors, apart from (i) the build > farm producing malicious stuff, (ii) RM or RM's laptop doing what it > shouldn't be doing, or (iii) someone patching the wheels en route from > the build farm to RM's laptop. > > I don't see how to address two first points or whether we actually > need to address those. The third one can be taken care of by > checksumming the wheels on the build farm, so that RM can verify them > on before uploading. > > This is probably not too hard to do with some tweaks to MacPython's > build scripts and/or terryfy download machinery Matthew described > upthread (I'm still to figure out how to use that machinery, but > that's separate). > I think there were problems with the terryfy machinery and signing, I asked Mathew about that before re NumPy. If you just download the built wheels, you can use twine to upload them with signatures, same with source files. Chuck -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthew.brett at gmail.com Thu Jun 23 18:43:52 2016 From: matthew.brett at gmail.com (Matthew Brett) Date: Thu, 23 Jun 2016 15:43:52 -0700 Subject: [SciPy-Dev] [Numpy-discussion] scipy 0.18 release candidate 1 In-Reply-To: References: Message-ID: Hi, On Thu, Jun 23, 2016 at 3:36 PM, Charles R Harris wrote: > > > On Thu, Jun 23, 2016 at 1:34 PM, Evgeni Burovski > wrote: >> >> OK, here's what I'm going to do: I'll download the wheels from >> Matthew's build farm, checksum them along with the source tarballs, >> and add the checksums to the README file which is clearsigned with my >> PGP signature. >> That file gets uploaded to PyPI, Github releases and sent along with >> the release announcement to a bunch of mailing lists. >> (like this, >> https://mail.scipy.org/pipermail/scipy-dev/2016-January/021189.html) >> >> AFAICS, this would cover the main vectors, apart from (i) the build >> farm producing malicious stuff, (ii) RM or RM's laptop doing what it >> shouldn't be doing, or (iii) someone patching the wheels en route from >> the build farm to RM's laptop. >> >> I don't see how to address two first points or whether we actually >> need to address those. The third one can be taken care of by >> checksumming the wheels on the build farm, so that RM can verify them >> on before uploading. >> >> This is probably not too hard to do with some tweaks to MacPython's >> build scripts and/or terryfy download machinery Matthew described >> upthread (I'm still to figure out how to use that machinery, but >> that's separate). > > > I think there were problems with the terryfy machinery and signing, I asked > Mathew about that before re NumPy. If you just download the built wheels, > you can use twine to upload them with signatures, same with source files. There were - I think that was to do with twine not accepting the flag as it should - but it appears to work now. For example, this command: python terryfy/wheel-uploader -r warehouse -v -s -t manylinux1 scipy 0.18.0rc1 has the `-s` flag which gets passed into twine, and so prompts you to sign each wheel. It would also be a good idea to prefer the https URL for the wheels, as in: python terryfy/wheel-uploader -u https://3f23b170c54c2533c070-1c8a9b3114517dc5fe17b7c3f8c63a43.ssl.cf2.rackcdn.com -r warehouse -v -s -t manylinux1 scipy 0.18.0rc1 although the https directory listing and files appear to be updated later than then http directory. Cheers, Matthew From pav at iki.fi Fri Jun 24 15:05:40 2016 From: pav at iki.fi (Pauli Virtanen) Date: Fri, 24 Jun 2016 21:05:40 +0200 Subject: [SciPy-Dev] Benchmark regression feeds Message-ID: <576D8484.7030801@iki.fi> Hi, In case someone is interested in getting notifications of performance regressions in the Numpy and Scipy benchmarks, this is available as Atom feeds at: https://pv.github.io/numpy-bench/regressions.xml https://pv.github.io/scipy-bench/regressions.xml -- Pauli Virtanen From davidgshi at yahoo.co.uk Sat Jun 25 17:10:07 2016 From: davidgshi at yahoo.co.uk (David Shi) Date: Sat, 25 Jun 2016 21:10:07 +0000 (UTC) Subject: [SciPy-Dev] How best to turn JSON into a CSV or Pandas data frame table? References: <1827931572.2383452.1466889007036.JavaMail.yahoo.ref@mail.yahoo.com> Message-ID: <1827931572.2383452.1466889007036.JavaMail.yahoo@mail.yahoo.com> Which are the best ways to turn a JSON object into a CSV or Pandas data frame table? Looking forward to hearing from you. Regards. David -------------- next part -------------- An HTML attachment was scrubbed... URL: From davidgshi at yahoo.co.uk Sat Jun 25 17:50:57 2016 From: davidgshi at yahoo.co.uk (David Shi) Date: Sat, 25 Jun 2016 21:50:57 +0000 (UTC) Subject: [SciPy-Dev] How best to turn JSON into a CSV or Pandas data frame table? In-Reply-To: <1827931572.2383452.1466889007036.JavaMail.yahoo@mail.yahoo.com> References: <1827931572.2383452.1466889007036.JavaMail.yahoo.ref@mail.yahoo.com> <1827931572.2383452.1466889007036.JavaMail.yahoo@mail.yahoo.com> Message-ID: <1171511771.2353445.1466891458011.JavaMail.yahoo@mail.yahoo.com> Which are the best ways to turn a JSON object into a CSV or Pandas data frame table? Looking forward to hearing from you. Regards. David -------------- next part -------------- An HTML attachment was scrubbed... URL: From charlesr.harris at gmail.com Sun Jun 26 12:36:28 2016 From: charlesr.harris at gmail.com (Charles R Harris) Date: Sun, 26 Jun 2016 10:36:28 -0600 Subject: [SciPy-Dev] Numpy 1.11.1 release Message-ID: Hi All, I'm pleased to announce the release of Numpy 1.11.1. This release supports Python 2.6 - 2.7, and 3.2 - 3.5 and fixes bugs and regressions found in Numpy 1.11.0 as well as making several build related improvements. Wheels for Linux, Windows, and OSX can be found on PyPI. Sources are available on both PyPI and Sourceforge . Thanks to all who were involved in this release, and a special thanks to Matthew Brett for his work on the Linux and Windows wheel infrastructure. The following pull requests have been merged: - 7506 BUG: Make sure numpy imports on python 2.6 when nose is unavailable. - 7530 BUG: Floating exception with invalid axis in np.lexsort. - 7535 BUG: Extend glibc complex trig functions blacklist to glibc < 2.18. - 7551 BUG: Allow graceful recovery for no compiler. - 7558 BUG: Constant padding expected wrong type in constant_values. - 7578 BUG: Fix OverflowError in Python 3.x. in swig interface. - 7590 BLD: Fix configparser.InterpolationSyntaxError. - 7597 BUG: Make np.ma.take work on scalars. - 7608 BUG: linalg.norm(): Don't convert object arrays to float. - 7638 BLD: Correct C compiler customization in system_info.py. - 7654 BUG: ma.median of 1d array should return a scalar. - 7656 BLD: Remove hardcoded Intel compiler flag -xSSE4.2. - 7660 BUG: Temporary fix for str(mvoid) for object field types. - 7665 BUG: Fix incorrect printing of 1D masked arrays. - 7670 BUG: Correct initial index estimate in histogram. - 7671 BUG: Boolean assignment no GIL release when transfer needs API. - 7676 BUG: Fix handling of right edge of final histogram bin. - 7680 BUG: Fix np.clip bug NaN handling for Visual Studio 2015. - 7724 BUG: Fix segfaults in np.random.shuffle. - 7731 MAINT: Change mkl_info.dir_env_var from MKL to MKLROOT. - 7737 BUG: Fix issue on OS X with Python 3.x, npymath.ini not installed. The following developers contributed to this release, developers marked with a '+' are first time contributors. - Allan Haldane - Amit Aronovitch+ - Andrei Kucharavy+ - Charles Harris - Eric Wieser+ - Evgeni Burovski - Lo?c Est?ve+ - Mathieu Lamarre+ - Matthew Brett - Matthias Geier - Nathaniel J. Smith - Nikola Forr?+ - Ralf Gommers - Ray Donnelly+ - Robert Kern - Sebastian Berg - Simon Conseil - Simon Gibbons - Sorin Sbarnea+ Chuck -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.gommers at gmail.com Sun Jun 26 18:43:20 2016 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Mon, 27 Jun 2016 00:43:20 +0200 Subject: [SciPy-Dev] welcome Nikolay to the core team Message-ID: Hi all, On behalf of the Scipy developers I'd like to welcome Nikolay Mayorov as member of the core dev team. Nikolay started contributing as a GSoC student last year, then he added optimize.lsq_linear/least_squares. Since then he's made many other contributions, for example: optimize.solve_bvp, interpolate.CubicSpline and a nearest neighbor chain algorithm to speed up cluster.linkage. See https://github.com/scipy/scipy/pulls/nmayorov Keep them coming Nikolay! Cheers, Ralf @other-newer-core-devs: if you're wondering if we all agreed on offering Nikolay commit rights, that happened already half a year ago via email (it just took a while before the acceptance came in:)). -------------- next part -------------- An HTML attachment was scrubbed... URL: From warren.weckesser at gmail.com Sun Jun 26 19:14:33 2016 From: warren.weckesser at gmail.com (Warren Weckesser) Date: Sun, 26 Jun 2016 19:14:33 -0400 Subject: [SciPy-Dev] welcome Nikolay to the core team In-Reply-To: References: Message-ID: On Sun, Jun 26, 2016 at 6:43 PM, Ralf Gommers wrote: > Hi all, > > On behalf of the Scipy developers I'd like to welcome Nikolay Mayorov as > member of the core dev team. > > Nikolay started contributing as a GSoC student last year, then he added > optimize.lsq_linear/least_squares. Since then he's made many other > contributions, for example: optimize.solve_bvp, interpolate.CubicSpline and > a nearest neighbor chain algorithm to speed up cluster.linkage. See > https://github.com/scipy/scipy/pulls/nmayorov > > Keep them coming Nikolay! > > Cheers, > Ralf > > @other-newer-core-devs: if you're wondering if we all agreed on offering > Nikolay commit rights, that happened already half a year ago via email (it > just took a while before the acceptance came in:)). > > > Nikolay, thanks for the solid contributions so far. Keep up the great work! Warren > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > https://mail.scipy.org/mailman/listinfo/scipy-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From evgeny.burovskiy at gmail.com Mon Jun 27 07:24:53 2016 From: evgeny.burovskiy at gmail.com (Evgeni Burovski) Date: Mon, 27 Jun 2016 12:24:53 +0100 Subject: [SciPy-Dev] welcome Nikolay to the core team In-Reply-To: References: Message-ID: Great to have you onboard Nikolay! From andyfaff at gmail.com Mon Jun 27 09:51:24 2016 From: andyfaff at gmail.com (Andrew Nelson) Date: Mon, 27 Jun 2016 23:51:24 +1000 Subject: [SciPy-Dev] welcome Nikolay to the core team In-Reply-To: References: Message-ID: Welcome Nikolay. On 27 Jun 2016 8:43 am, "Ralf Gommers" wrote: > Hi all, > > On behalf of the Scipy developers I'd like to welcome Nikolay Mayorov as > member of the core dev team. > > Nikolay started contributing as a GSoC student last year, then he added > optimize.lsq_linear/least_squares. Since then he's made many other > contributions, for example: optimize.solve_bvp, interpolate.CubicSpline and > a nearest neighbor chain algorithm to speed up cluster.linkage. See > https://github.com/scipy/scipy/pulls/nmayorov > > Keep them coming Nikolay! > > Cheers, > Ralf > > @other-newer-core-devs: if you're wondering if we all agreed on offering > Nikolay commit rights, that happened already half a year ago via email (it > just took a while before the acceptance came in:)). > > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > https://mail.scipy.org/mailman/listinfo/scipy-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From insertinterestingnamehere at gmail.com Mon Jun 27 11:23:26 2016 From: insertinterestingnamehere at gmail.com (Ian Henriksen) Date: Mon, 27 Jun 2016 15:23:26 +0000 Subject: [SciPy-Dev] welcome Nikolay to the core team In-Reply-To: References: Message-ID: Welcome! On Mon, Jun 27, 2016 at 7:51 AM Andrew Nelson wrote: > Welcome Nikolay. > On 27 Jun 2016 8:43 am, "Ralf Gommers" wrote: > >> Hi all, >> >> On behalf of the Scipy developers I'd like to welcome Nikolay Mayorov as >> member of the core dev team. >> >> Nikolay started contributing as a GSoC student last year, then he added >> optimize.lsq_linear/least_squares. Since then he's made many other >> contributions, for example: optimize.solve_bvp, interpolate.CubicSpline and >> a nearest neighbor chain algorithm to speed up cluster.linkage. See >> https://github.com/scipy/scipy/pulls/nmayorov >> >> Keep them coming Nikolay! >> >> Cheers, >> Ralf >> >> @other-newer-core-devs: if you're wondering if we all agreed on offering >> Nikolay commit rights, that happened already half a year ago via email (it >> just took a while before the acceptance came in:)). >> >> >> _______________________________________________ >> SciPy-Dev mailing list >> SciPy-Dev at scipy.org >> https://mail.scipy.org/mailman/listinfo/scipy-dev >> >> _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > https://mail.scipy.org/mailman/listinfo/scipy-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From charlesr.harris at gmail.com Mon Jun 27 11:25:09 2016 From: charlesr.harris at gmail.com (Charles R Harris) Date: Mon, 27 Jun 2016 09:25:09 -0600 Subject: [SciPy-Dev] welcome Nikolay to the core team In-Reply-To: References: Message-ID: On Sun, Jun 26, 2016 at 4:43 PM, Ralf Gommers wrote: > Hi all, > > On behalf of the Scipy developers I'd like to welcome Nikolay Mayorov as > member of the core dev team. > > Nikolay started contributing as a GSoC student last year, then he added > optimize.lsq_linear/least_squares. Since then he's made many other > contributions, for example: optimize.solve_bvp, interpolate.CubicSpline and > a nearest neighbor chain algorithm to speed up cluster.linkage. See > https://github.com/scipy/scipy/pulls/nmayorov > > Keep them coming Nikolay! > > Cheers, > Ralf > > @other-newer-core-devs: if you're wondering if we all agreed on offering > Nikolay commit rights, that happened already half a year ago via email (it > just took a while before the acceptance came in:)). > > Welcome aboard Nikolay, and thanks for your contributions. Chuck -------------- next part -------------- An HTML attachment was scrubbed... URL: From nikolay.mayorov at zoho.com Tue Jun 28 03:51:29 2016 From: nikolay.mayorov at zoho.com (Nikolay Mayorov) Date: Tue, 28 Jun 2016 12:51:29 +0500 Subject: [SciPy-Dev] welcome Nikolay to the core team In-Reply-To: References: Message-ID: <15595fdda4c.f938244f186.8518235069970207789@zoho.com> Thanks to all. I'm glad to be a part of this great community. Nikolay. ---- On Mon, 27 Jun 2016 20:25:09 +0500 Charles R Harris <charlesr.harris at gmail.com>wrote ---- On Sun, Jun 26, 2016 at 4:43 PM, Ralf Gommers <ralf.gommers at gmail.com> wrote: Hi all, On behalf of the Scipy developers I'd like to welcome Nikolay Mayorov as member of the core dev team. Nikolay started contributing as a GSoC student last year, then he added optimize.lsq_linear/least_squares. Since then he's made many other contributions, for example: optimize.solve_bvp, interpolate.CubicSpline and a nearest neighbor chain algorithm to speed up cluster.linkage. See https://github.com/scipy/scipy/pulls/nmayorov Keep them coming Nikolay! Cheers, Ralf @other-newer-core-devs: if you're wondering if we all agreed on offering Nikolay commit rights, that happened already half a year ago via email (it just took a while before the acceptance came in:)). Welcome aboard Nikolay, and thanks for your contributions. Chuck _______________________________________________ SciPy-Dev mailing list SciPy-Dev at scipy.org https://mail.scipy.org/mailman/listinfo/scipy-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: