From dieter at werthmuller.org Thu Nov 1 08:21:05 2018 From: dieter at werthmuller.org (=?UTF-8?Q?Dieter_Werthm=c3=bcller?=) Date: Thu, 1 Nov 2018 06:21:05 -0600 Subject: [SciPy-Dev] bicgstab Message-ID: <2be12162-6c05-ddaf-bc50-bf4e1fb510c2@werthmuller.org> Hi everyone, I've got some questions related to scipy.sparse.linalg.bicgstab. I try to move some code from Matlab to Python. Now, in the Matlab-bicgstab the matrix A and the preconditioner M can be function handles; from the docs: "A can be a function handle, afun, such that afun(x) returns A*x." and similar "M can be a function handle mfun, such that mfun(x) returns M\x." This can be very useful, because you can avoid creating the matrices A and M explicitly. As far as I can see, this is not possible in scipy.sparse.linalg.bicgstab. Therefore my questions: - Is that correct, it is not possible with scipy.sparse.linalg.bicgstab, or do I miss something? (Are there any examples online? I couldn't find much in the docs.) - Is there a trick to achieve the same behaviour in scipy.sparse.linalg.bicgstab? - If not, do you know of other packages in Python that provide that feature? Thanks a lot, Dieter From pav at iki.fi Thu Nov 1 08:35:03 2018 From: pav at iki.fi (Pauli Virtanen) Date: Thu, 01 Nov 2018 13:35:03 +0100 Subject: [SciPy-Dev] bicgstab In-Reply-To: <2be12162-6c05-ddaf-bc50-bf4e1fb510c2@werthmuller.org> References: <2be12162-6c05-ddaf-bc50-bf4e1fb510c2@werthmuller.org> Message-ID: to, 2018-11-01 kello 06:21 -0600, Dieter Werthm?ller kirjoitti: > - Is that correct, it is not possible with > scipy.sparse.linalg.bicgstab, > or do I miss something? (Are there any examples online? I couldn't > find > much in the docs.) It's possible: https://docs.scipy.org/doc/scipy/reference/generated/scipy.sparse.linalg.LinearOperator.html > - Is there a trick to achieve the same behaviour in > scipy.sparse.linalg.bicgstab? > > - If not, do you know of other packages in Python that provide that > feature? > > Thanks a lot, > Dieter > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at python.org > https://mail.python.org/mailman/listinfo/scipy-dev From dieter at werthmuller.org Thu Nov 1 08:43:10 2018 From: dieter at werthmuller.org (=?UTF-8?Q?Dieter_Werthm=c3=bcller?=) Date: Thu, 1 Nov 2018 06:43:10 -0600 Subject: [SciPy-Dev] bicgstab In-Reply-To: References: <2be12162-6c05-ddaf-bc50-bf4e1fb510c2@werthmuller.org> Message-ID: <4ab1ea71-5f3e-e845-f0e6-84e64a9ecd11@werthmuller.org> Indeed, thanks Pauli! This might be something that could be clarified in the docstring. Although it states "{sparse matrix, dense matrix, LinearOperator}" it then only specifies "The real or complex N-by-N matrix". Adding that it could be a callable f(v) with returns A*v using scipy.sparse.linalg.LinearOperator might clarify things for new users. From scipy.sparse.linalg.bicgstab-docstring: Parameters ---------- A : {sparse matrix, dense matrix, LinearOperator} The real or complex N-by-N matrix of the linear system. On 01/11/2018 06:35, Pauli Virtanen wrote: > to, 2018-11-01 kello 06:21 -0600, Dieter Werthm?ller kirjoitti: >> - Is that correct, it is not possible with >> scipy.sparse.linalg.bicgstab, >> or do I miss something? (Are there any examples online? I couldn't >> find >> much in the docs.) > > It's possible: > https://docs.scipy.org/doc/scipy/reference/generated/scipy.sparse.linalg.LinearOperator.html > >> - Is there a trick to achieve the same behaviour in >> scipy.sparse.linalg.bicgstab? >> >> - If not, do you know of other packages in Python that provide that >> feature? >> >> Thanks a lot, >> Dieter >> _______________________________________________ >> SciPy-Dev mailing list >> SciPy-Dev at python.org >> https://mail.python.org/mailman/listinfo/scipy-dev > > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at python.org > https://mail.python.org/mailman/listinfo/scipy-dev > From stefanv at berkeley.edu Thu Nov 1 15:04:28 2018 From: stefanv at berkeley.edu (Stefan van der Walt) Date: Thu, 1 Nov 2018 12:04:28 -0700 Subject: [SciPy-Dev] bicgstab In-Reply-To: <4ab1ea71-5f3e-e845-f0e6-84e64a9ecd11@werthmuller.org> References: <2be12162-6c05-ddaf-bc50-bf4e1fb510c2@werthmuller.org> <4ab1ea71-5f3e-e845-f0e6-84e64a9ecd11@werthmuller.org> Message-ID: <20181101190428.wq2vi3woi4fgy4bg@carbo> Hi Dieter, On Thu, 01 Nov 2018 06:43:10 -0600, Dieter Werthm?ller wrote: > This might be something that could be clarified in the docstring. Although > it states "{sparse matrix, dense matrix, LinearOperator}" it then only > specifies "The real or complex N-by-N matrix". Adding that it could be a > callable f(v) with returns A*v using scipy.sparse.linalg.LinearOperator > might clarify things for new users. I can see how that would be confusing, and the same probably holds for other sparse functions. Perhaps a "Notes" section in the docstring would help or, as you recommend, expanding the parameter description. Would you be interested in filing a pull request? I can help review. Best regards, St?fan From dieter at werthmuller.org Thu Nov 1 15:10:53 2018 From: dieter at werthmuller.org (=?UTF-8?Q?Dieter_Werthm=c3=bcller?=) Date: Thu, 1 Nov 2018 13:10:53 -0600 Subject: [SciPy-Dev] bicgstab In-Reply-To: <20181101190428.wq2vi3woi4fgy4bg@carbo> References: <2be12162-6c05-ddaf-bc50-bf4e1fb510c2@werthmuller.org> <4ab1ea71-5f3e-e845-f0e6-84e64a9ecd11@werthmuller.org> <20181101190428.wq2vi3woi4fgy4bg@carbo> Message-ID: Hi St?fan, I will do, thanks for the feedback. Just give me a week or two, until I get comfortable with it. Not that I expand the parameter description now and redo it in two weeks time when I got a better handling and understanding of it. Taking the opportunity for another question: Is it possible to create `LinearOperator`s with more than one input variable, and provide it to, e.g., `bigstabc`? Thanks, Dieter On 01/11/2018 13:04, Stefan van der Walt wrote: > Hi Dieter, > > On Thu, 01 Nov 2018 06:43:10 -0600, Dieter Werthm?ller wrote: >> This might be something that could be clarified in the docstring. Although >> it states "{sparse matrix, dense matrix, LinearOperator}" it then only >> specifies "The real or complex N-by-N matrix". Adding that it could be a >> callable f(v) with returns A*v using scipy.sparse.linalg.LinearOperator >> might clarify things for new users. > > I can see how that would be confusing, and the same probably holds for > other sparse functions. Perhaps a "Notes" section in the docstring > would help or, as you recommend, expanding the parameter description. > > Would you be interested in filing a pull request? I can help review. > > Best regards, > St?fan From andyfaff at gmail.com Thu Nov 1 17:04:33 2018 From: andyfaff at gmail.com (Andrew Nelson) Date: Fri, 2 Nov 2018 08:04:33 +1100 Subject: [SciPy-Dev] Parallelised brute Message-ID: In #9428 I've added a workers keyword that adds the ability to parallelise `optimize.brute`. It's not an enormous change, and it makes use of the machinery that was used in `differential_evolution`. Is it too late for it to go in before the next branch? Tests are passing, and I've added a test to check that the parallelised version gives the same result as a serial version. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.gommers at gmail.com Thu Nov 1 19:11:40 2018 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Thu, 1 Nov 2018 16:11:40 -0700 Subject: [SciPy-Dev] building scipy for WebAssembly In-Reply-To: References: Message-ID: On Tue, Oct 30, 2018 at 4:56 PM Roman Yurchak wrote: > Hello, > > I am currently working on building scipy for WebAssembly as part of > pyodide project (https://github.com/iodide-project/pyodide) and I was > hoping for some feedback on that process. There is a preliminary build > in https://github.com/iodide-project/pyodide/pull/211 > > Currently, this build uses scipy 0.17.1 as from what I understood, that > was one of the last versions that only included f77 without any f90 > (https://github.com/scipy/scipy/issues/2829#issuecomment-223764054). In > the WebAssembly environment there is currently no reliably working > Fortran compiler (https://github.com/iodide-project/pyodide/issues/184), > and f90 cannot be converted to C with f2c unlike f77. > > If one wanted to (experimentally) compile the latest version of scipy > without a Fortran compiler what would be your suggestions? i.e. > - are there any alternatives to f2c that you think might work for f90 > - or any automatic converter f90 to f77 (so that f2c could be used) > I did search but maybe I missed something. > Alternatively, if that's really not realistic, could someone please > comment on the rate of adoption for f90/f95 in the scipy code base? The > decision to support f90 was taken before the 0.18 release in 2016 but > I'm not sure what impact it had on the code base. In other words maybe > there is a later version than 0.17.1 that might (mostly) work? > There has been very little new Fortran code added since then. The PR that gh-2829 linked to (odeint rewrite) was not merged in the end. I wouldn't be surprised if current master turns out to be f77 compliant. > Another point is linking BLAS/LAPACK. Currently reference BLAS and > CLAPACK are linked statically as I haven't managed to do this > dynamically yet. The issue is the package size. As LAPACK, which is > quite large, gets repeatedly included in around ~10 different .so > modules, resulting in a 170MB large package (after compression), as > opposed to ~30MB compressed package without BLAS/LAPACK. That is quite > problematic when one is expected to download the dependencies at each > page load (excluding caching). I'm not sure if there are other > distributions of scipy that use static linking of LAPACK? or other > things worth trying to reduce the package size, short of trying to make > dynamic linking work or try to detect and strip unused symbols? > Nothing I can think of worth trying really. > Also in scipy/linalg/setup.py I was wondering why/how the ATLAS_INFO > macro defined the existence of `scipy.linalg._clapack`? For instance, > when using CLAPACK (with libf2c), would the following be correct? > > lapack_opt = {'libraries': ['f2c', 'blas', 'lapack'], > 'include_dirs': [], > 'library_dirs': [''], > 'language': 'f77', > 'define_macros': [('NO_ATLAS_INFO', 1), > ('HAVE_CBLAS', None)]} > > which does not appear to build `scipy.linalg._clapack`. > You're asking about pretty arcane details:) Don't know the answer, sorry. > Finally, in later scipy versions, > https://scipy.github.io/devdocs/building/linux.html suggests that with > ?export LAPACK=? one can build scipy without LAPACK, but then _flapack > is still a mandatory import in scipy.linalg.__init___ (via .lapack) as > far as I can tell. Is scipy.linalg (and anything that depends on it) > expected to produce import errors in the latter case then? > Yes. I'm not sure when that sentence was written, but you definitely don't want a SciPy without LAPACK - lots of things will not work. Cheers, Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.gommers at gmail.com Thu Nov 1 20:14:15 2018 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Thu, 1 Nov 2018 17:14:15 -0700 Subject: [SciPy-Dev] Parallelised brute In-Reply-To: References: Message-ID: On Thu, Nov 1, 2018 at 2:04 PM Andrew Nelson wrote: > In #9428 I've added a workers keyword that adds the ability to parallelise > `optimize.brute`. It's not an enormous change, and it makes use of the > machinery that was used in `differential_evolution`. > Makes sense to me. Is it too late for it to go in before the next branch? > I had a quick browse. In principle not a problem I think, it's not a risky PR to merge right before branching. Someone needs to review in detail though. Cheers, Ralf Tests are passing, and I've added a test to check that the parallelised > version gives the same result as a serial version. > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at python.org > https://mail.python.org/mailman/listinfo/scipy-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefanv at berkeley.edu Fri Nov 2 02:20:14 2018 From: stefanv at berkeley.edu (Stefan van der Walt) Date: Thu, 1 Nov 2018 23:20:14 -0700 Subject: [SciPy-Dev] bicgstab In-Reply-To: References: <2be12162-6c05-ddaf-bc50-bf4e1fb510c2@werthmuller.org> <4ab1ea71-5f3e-e845-f0e6-84e64a9ecd11@werthmuller.org> <20181101190428.wq2vi3woi4fgy4bg@carbo> Message-ID: <20181102062014.mnnjhx5hekrq6e6z@carbo> On Thu, 01 Nov 2018 13:10:53 -0600, Dieter Werthm?ller wrote: > Taking the opportunity for another question: Is it possible to create > `LinearOperator`s with more than one input variable, and provide it to, > e.g., `bigstabc`? You can construct LinearOperators however you like, as long as they provide the API outlined in the docstring of `scipy.sparse.LinearOperator`. I presumed you meant that you wanted to parameterize the construction of your operator, but I may have misunderstood. Best regards, St?fan From rth.yurchak at pm.me Fri Nov 2 12:27:00 2018 From: rth.yurchak at pm.me (Roman Yurchak) Date: Fri, 02 Nov 2018 16:27:00 +0000 Subject: [SciPy-Dev] building scipy for WebAssembly In-Reply-To: References: Message-ID: On 02/11/2018 00:11, Ralf Gommers wrote: > The decision to support f90 was taken before the 0.18 release in 2016 but > I'm not sure what impact it had on the code base. > > There has been very little new Fortran code added since then. The PR > that gh-2829 linked to (odeint rewrite) was not merged in the end. I > wouldn't be surprised if current master turns out to be f77 compliant. That is very useful to know, thanks. Also thank you for confirming the other points, -- Roman From dieter at werthmuller.org Fri Nov 2 13:16:07 2018 From: dieter at werthmuller.org (=?UTF-8?Q?Dieter_Werthm=c3=bcller?=) Date: Fri, 2 Nov 2018 11:16:07 -0600 Subject: [SciPy-Dev] bicgstab In-Reply-To: <20181102062014.mnnjhx5hekrq6e6z@carbo> References: <2be12162-6c05-ddaf-bc50-bf4e1fb510c2@werthmuller.org> <4ab1ea71-5f3e-e845-f0e6-84e64a9ecd11@werthmuller.org> <20181101190428.wq2vi3woi4fgy4bg@carbo> <20181102062014.mnnjhx5hekrq6e6z@carbo> Message-ID: <68cad87d-ded3-ed77-5e40-dcae340df5aa@werthmuller.org> On 02/11/2018 00:20, Stefan van der Walt wrote: > On Thu, 01 Nov 2018 13:10:53 -0600, Dieter Werthm?ller wrote: >> Taking the opportunity for another question: Is it possible to create >> `LinearOperator`s with more than one input variable, and provide it to, >> e.g., `bigstabc`? > > You can construct LinearOperators however you like, as long as they > provide the API outlined in the docstring of > `scipy.sparse.LinearOperator`. I guess my doubt/question is if the other variables are updated. If I define the matrix M in the following form (for brevity with lambda, but equally with a function or with a class I guess) M = LinearOperator((len(y), len(z)), matvec=lambda x: myfunc(x, y, z)) are the variables y and z then updated within M if they get changed during the call to, e.g., bicgstab? (My concern is specifically related to the preconditioner M for A, not for A itself.) I might have a knot here in my thinking. Thanks St?fan. I will make a pull request next week regarding the docs. Dieter > I presumed you meant that you wanted to parameterize the construction of > your operator, but I may have misunderstood. > > Best regards, > St?fan From ali.cetin at outlook.com Sun Nov 4 10:01:36 2018 From: ali.cetin at outlook.com (Ali Cetin) Date: Sun, 4 Nov 2018 15:01:36 +0000 Subject: [SciPy-Dev] Truncated distributions Message-ID: Hi all, I note that quite a few truncated distribution functions are available in SciPy - nice! However, I find the usefulness of these functions somewhat limited when it is desired to fit them to data; in most common scenarios the truncation point is known (or even determined by the user/experimenter), and therefore do not need to be treated as a free parameter. In the current scipy.stats framework, the truncation parameters are accepted as "shape" parameters. Therefore, it is only possible to lock the "normalized" truncation point during fitting. This is a catch-22, since the user is required to provide loc and scale parameters a priori, which are unknown. I would like to propose a solution that only require minor adjustment of the current framework: allow the user to supply the truncation point as part of the data array -> for left and right truncation, the 0th and the Nth element of the array is poped out and used as truncation parameters, respectively. Is this a viable solution? Cheers, Ali -------------- next part -------------- An HTML attachment was scrubbed... URL: From charlesr.harris at gmail.com Sun Nov 4 12:31:05 2018 From: charlesr.harris at gmail.com (Charles R Harris) Date: Sun, 4 Nov 2018 10:31:05 -0700 Subject: [SciPy-Dev] NumPy 1.15.4 release Message-ID: Hi All, On behalf of the NumPy team, I am pleased to announce the release of NumPy 1.15.4. This is a bugfix release for bugs and regressions reported following the 1.15.3 release. The most noticeable fix is probably having a boolean type fill value for masked arrays after the use of `==` and `!=`. The Python versions supported by this release are 2.7, 3.4-3.7. Wheels for this release can be downloaded from PyPI , source archives are available from Github . Compatibility Note ================== The NumPy 1.15.x OS X wheels released on PyPI no longer contain 32-bit binaries. That will also be the case in future releases. See `#11625 < https://github.com/numpy/numpy/issues/11625>`__ for the related discussion. Those needing 32-bit support should look elsewhere or build from source. Contributors ============ A total of 4 people contributed to this release. People with a "+" by their names contributed a patch for the first time. - Charles Harris - Matti Picus - Sebastian Berg - bbbbbbbbba + Pull requests merged ==================== A total of 4 pull requests were merged for this release. - `#12296 `__: BUG: Dealloc cached buffer info - `#12297 `__: BUG: Fix fill value in masked array '==' and '!=' ops. - `#12307 `__: DOC: Correct the default value of `optimize` in `numpy.einsum` - `#12320 `__: REL: Prepare for the NumPy 1.15.4 release Cheers, Charles Harris -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.gommers at gmail.com Mon Nov 5 01:26:39 2018 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Sun, 4 Nov 2018 22:26:39 -0800 Subject: [SciPy-Dev] SciPy 1.2.0 release schedule In-Reply-To: References: Message-ID: On Fri, Oct 26, 2018 at 7:03 PM Mark Alexander Mikofski < mikofski at berkeley.edu> wrote: > Hi Tyler and others, > > Thanks for managing the v1.2 release. > > I think PR #8431, Cython optimize zeros API, is ready, hopefully, to > merge. It's been through several rounds of reviews and I think I've > accommodated all of the recommendations, all tests are passing, and there's > been strong support. Anyone please take a look. > > https://github.com/scipy/scipy/pull/8431 > > Thanks, > Mark > > On Fri, Oct 26, 2018, 2:38 PM Ralf Gommers wrote: > >> >> >> On Thu, Oct 25, 2018 at 12:55 PM Tyler Reddy >> wrote: >> >>> Hi all, >>> >>> It is almost 6 months after the 1.1.0 release on May 5, so probably time >>> to plan the 1.2.0 release. It would be a good idea to look over the PRs >>> with a 1.2.0 milestone >>> , >>> and tag anything else that should have this milestone appropriately. >>> >>> I'd like to propose the following schedule: >>> >>> Nov. 5: branch 1.2.x >>> Nov. 8: rc1 >>> Nov. 21: rc2 (if needed) >>> Nov. 30: final release >>> >>> Thoughts? >>> >> >> This looks like a good schedule to me. We'll probably struggle to get >> some PRs marked for 1.2.0 merged, but that's always the case. >> > Hi Tyler, could we shift the branch date by 2-3 days (or up to a week)? There's a couple of PRs that I'd really like to see merged or decided on (for optimize and stats mainly), and there's right now still 18 open PRs marked for 1.2.0. A note on the open PRs: what we want to aim for is to have the list of open PRs and open blocking issues at zero, and have at most some non-blocking issues under the milestone left. Normally the release manager starts making those decisions, or pinging people, if other reviewers haven't done so in time. Of course it would be ideal if everyone has another look at https://github.com/scipy/scipy/pulls?q=is%3Aopen+is%3Apr+milestone%3A1.2.0 and bumps or finished off PRs he/she is involved in. Cheers, Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.gommers at gmail.com Mon Nov 5 01:35:33 2018 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Sun, 4 Nov 2018 22:35:33 -0800 Subject: [SciPy-Dev] Truncated distributions In-Reply-To: References: Message-ID: On Sun, Nov 4, 2018 at 7:01 AM Ali Cetin wrote: > Hi all, > > I note that quite a few truncated distribution functions are available in > SciPy - nice! > > However, I find the usefulness of these functions somewhat limited when it > is desired to fit them to data; in most common scenarios the truncation > point is known (or even determined by the user/experimenter), and therefore > do not need to be treated as a free parameter. In the current scipy.stats > framework, the truncation parameters are accepted as "shape" parameters. > Therefore, it is only possible to lock the "normalized" truncation point > during fitting. This is a catch-22, since the user is required to provide > loc and scale parameters a priori, which are unknown. > I'm not sure I follow. The fit() docstring says: "Return MLEs for shape (if applicable), location, and scale parameters from data." So it should be fitting everything. Could you provide an example perhaps? > I would like to propose a solution that only require minor adjustment of > the current framework: allow the user to supply the truncation point as > part of the data array -> for left and right truncation, the 0th and the > Nth element of the array is poped out and used as truncation parameters, > respectively. > That doesn't look like a viable solution. Let's first establish if there really is an issue like you're describing, and then look for a cleaner addition to the API. Cheers, Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.kern at gmail.com Mon Nov 5 01:58:12 2018 From: robert.kern at gmail.com (Robert Kern) Date: Sun, 4 Nov 2018 22:58:12 -0800 Subject: [SciPy-Dev] Truncated distributions In-Reply-To: References: Message-ID: On Sun, Nov 4, 2018 at 10:36 PM Ralf Gommers wrote: > > On Sun, Nov 4, 2018 at 7:01 AM Ali Cetin wrote: >> >> Hi all, >> >> I note that quite a few truncated distribution functions are available in SciPy - nice! >> >> However, I find the usefulness of these functions somewhat limited when it is desired to fit them to data; in most common scenarios the truncation point is known (or even determined by the user/experimenter), and therefore do not need to be treated as a free parameter. In the current scipy.stats framework, the truncation parameters are accepted as "shape" parameters. Therefore, it is only possible to lock the "normalized" truncation point during fitting. This is a catch-22, since the user is required to provide loc and scale parameters a priori, which are unknown. > > I'm not sure I follow. The fit() docstring says: "Return MLEs for shape (if applicable), location, and scale parameters from data." So it should be fitting everything. Could you provide an example perhaps? The problem is with how we defined the truncation parameters of these distributions, not `fit()` per se. You are supposed to specify them *relative* to the `loc` and `scale`. So you could fit `truncnorm()` such that the bounds are fixed to, say, (-3*sigma, +3*sigma) where `sigma` is freely being adjusted during the fit but not to (-10, +10) regardless of the `scale`. Ali wants to do the latter. `fit()` doesn't work for this use case. >> I would like to propose a solution that only require minor adjustment of the current framework: allow the user to supply the truncation point as part of the data array -> for left and right truncation, the 0th and the Nth element of the array is poped out and used as truncation parameters, respectively. > > That doesn't look like a viable solution. Let's first establish if there really is an issue like you're describing, and then look for a cleaner addition to the API. I agree that this is not the right approach. Personally, I think that it's hard to get all of the corner cases right to make `fit()` Just Work(TM). The distributions API has a lot of them. Most of `fit()`'s implementation is just trying to work around as many of them as it can in order to be general. But the core of it is pretty straightforward: use a `scipy.optimize` minimizer on the `nnlf()` method. This is the way I approach it: if `fit()` does what I want it to do, great, I'll use it. But if it looks hard to shoehorn what I want into `fit()`, I'll just go ahead and call `scipy.optimize.minimize()` myself. `fit()` is a good convenience when it works in the easy cases, but the alternative is straightforward for the harder ones. I don't see much benefit to trying to make `fit()` scale to the harder, weirder cases. I'd rather document the path up to `scipy.optimize`. Ali's example would be a good recipe to demonstrate this. -- Robert Kern -------------- next part -------------- An HTML attachment was scrubbed... URL: From warren.weckesser at gmail.com Mon Nov 5 04:20:51 2018 From: warren.weckesser at gmail.com (Warren Weckesser) Date: Mon, 5 Nov 2018 04:20:51 -0500 Subject: [SciPy-Dev] Truncated distributions In-Reply-To: References: Message-ID: On 11/5/18, Robert Kern wrote: > On Sun, Nov 4, 2018 at 10:36 PM Ralf Gommers > wrote: >> >> On Sun, Nov 4, 2018 at 7:01 AM Ali Cetin wrote: >>> >>> Hi all, >>> >>> I note that quite a few truncated distribution functions are available > in SciPy - nice! >>> >>> However, I find the usefulness of these functions somewhat limited when > it is desired to fit them to data; in most common scenarios the truncation > point is known (or even determined by the user/experimenter), and therefore > do not need to be treated as a free parameter. In the current scipy.stats > framework, the truncation parameters are accepted as "shape" parameters. > Therefore, it is only possible to lock the "normalized" truncation point > during fitting. This is a catch-22, since the user is required to provide > loc and scale parameters a priori, which are unknown. >> >> I'm not sure I follow. The fit() docstring says: "Return MLEs for shape > (if applicable), location, and scale parameters from data." So it should be > fitting everything. Could you provide an example perhaps? > > The problem is with how we defined the truncation parameters of these > distributions, not `fit()` per se. You are supposed to specify them > *relative* to the `loc` and `scale`. So you could fit `truncnorm()` such > that the bounds are fixed to, say, (-3*sigma, +3*sigma) where `sigma` is > freely being adjusted during the fit but not to (-10, +10) regardless of > the `scale`. Ali wants to do the latter. `fit()` doesn't work for this use > case. > >>> I would like to propose a solution that only require minor adjustment of > the current framework: allow the user to supply the truncation point as > part of the data array -> for left and right truncation, the 0th and the > Nth element of the array is poped out and used as truncation parameters, > respectively. >> >> That doesn't look like a viable solution. Let's first establish if there > really is an issue like you're describing, and then look for a cleaner > addition to the API. > > I agree that this is not the right approach. > > Personally, I think that it's hard to get all of the corner cases right to > make `fit()` Just Work(TM). The distributions API has a lot of them. Most > of `fit()`'s implementation is just trying to work around as many of them > as it can in order to be general. But the core of it is pretty > straightforward: use a `scipy.optimize` minimizer on the `nnlf()` method. > > This is the way I approach it: if `fit()` does what I want it to do, great, > I'll use it. But if it looks hard to shoehorn what I want into `fit()`, > I'll just go ahead and call `scipy.optimize.minimize()` myself. `fit()` is > a good convenience when it works in the easy cases, but the alternative is > straightforward for the harder ones. I don't see much benefit to trying to > make `fit()` scale to the harder, weirder cases. I'd rather document the > path up to `scipy.optimize`. Ali's example would be a good recipe to > demonstrate this. I agree, and I recently did just this in an answer on stackoverflow: https://stackoverflow.com/questions/53125437/fitting-data-using-scipy-truncnorm Warren > > -- > Robert Kern > From ali.cetin at outlook.com Mon Nov 5 05:54:09 2018 From: ali.cetin at outlook.com (Ali Cetin) Date: Mon, 5 Nov 2018 10:54:09 +0000 Subject: [SciPy-Dev] Truncated distributions In-Reply-To: References: , Message-ID: ________________________________ From: SciPy-Dev on behalf of Warren Weckesser Sent: Monday, November 5, 2018 10:20 To: SciPy Developers List Subject: Re: [SciPy-Dev] Truncated distributions On 11/5/18, Robert Kern wrote: > On Sun, Nov 4, 2018 at 10:36 PM Ralf Gommers > wrote: >> >> On Sun, Nov 4, 2018 at 7:01 AM Ali Cetin wrote: >>> >>> Hi all, >>> >>> I note that quite a few truncated distribution functions are available > in SciPy - nice! >>> >>> However, I find the usefulness of these functions somewhat limited when > it is desired to fit them to data; in most common scenarios the truncation > point is known (or even determined by the user/experimenter), and therefore > do not need to be treated as a free parameter. In the current scipy.stats > framework, the truncation parameters are accepted as "shape" parameters. > Therefore, it is only possible to lock the "normalized" truncation point > during fitting. This is a catch-22, since the user is required to provide > loc and scale parameters a priori, which are unknown. >> >> I'm not sure I follow. The fit() docstring says: "Return MLEs for shape > (if applicable), location, and scale parameters from data." So it should be > fitting everything. Could you provide an example perhaps? > > The problem is with how we defined the truncation parameters of these > distributions, not `fit()` per se. You are supposed to specify them > *relative* to the `loc` and `scale`. So you could fit `truncnorm()` such > that the bounds are fixed to, say, (-3*sigma, +3*sigma) where `sigma` is > freely being adjusted during the fit but not to (-10, +10) regardless of > the `scale`. Ali wants to do the latter. `fit()` doesn't work for this use > case. > >>> I would like to propose a solution that only require minor adjustment of > the current framework: allow the user to supply the truncation point as > part of the data array -> for left and right truncation, the 0th and the > Nth element of the array is poped out and used as truncation parameters, > respectively. >> >> That doesn't look like a viable solution. Let's first establish if there > really is an issue like you're describing, and then look for a cleaner > addition to the API. > > I agree that this is not the right approach. > > Personally, I think that it's hard to get all of the corner cases right to > make `fit()` Just Work(TM). The distributions API has a lot of them. Most > of `fit()`'s implementation is just trying to work around as many of them > as it can in order to be general. But the core of it is pretty > straightforward: use a `scipy.optimize` minimizer on the `nnlf()` method. > > This is the way I approach it: if `fit()` does what I want it to do, great, > I'll use it. But if it looks hard to shoehorn what I want into `fit()`, > I'll just go ahead and call `scipy.optimize.minimize()` myself. `fit()` is > a good convenience when it works in the easy cases, but the alternative is > straightforward for the harder ones. I don't see much benefit to trying to > make `fit()` scale to the harder, weirder cases. I'd rather document the > path up to `scipy.optimize`. Ali's example would be a good recipe to > demonstrate this. I agree, and I recently did just this in an answer on stackoverflow: https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstackoverflow.com%2Fquestions%2F53125437%2Ffitting-data-using-scipy-truncnorm&data=02%7C01%7C%7C076bdbb82e12488e888508d643000bd8%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636770064812506740&sdata=ecii5FOijuccC49X54%2BGVZsSJNhPow%2Fl%2BFc%2FeMZWBYQ%3D&reserved=0 Warren Thanks for chiming in on this guys. I have created a issue on GitHub (https://github.com/scipy/scipy/issues/9439) with an example. (I hate reading and writing code on mail ?). Anyway, I do agree with Robert and Warren that this is achievable with a few lines of code (as I also included in the example). However, is it fair to expect that a user without advanced understanding in statistics/optimization problems to deal with this? (Furthermore, you can make this argument about the regular fit method. Should we just remove the method altogether then? Of course not.). I mean, most of my colleagues in the industry are highly capable engineers, but statistics and probability theory is more or less a "black-box" to them. I think it would be better for the end-users to alter the API to natively accommodate for truncated distributions (as Ralf suggests). Cheers, Ali > > -- > Robert Kern > _______________________________________________ SciPy-Dev mailing list SciPy-Dev at python.org https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.python.org%2Fmailman%2Flistinfo%2Fscipy-dev&data=02%7C01%7C%7C076bdbb82e12488e888508d643000bd8%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636770064812506740&sdata=AB7%2BTYDh9r%2F%2FoR6sn9c3%2BoJbEsj5X7QfFQ4DzQcDPUU%3D&reserved=0 -------------- next part -------------- An HTML attachment was scrubbed... URL: From tyler.je.reddy at gmail.com Mon Nov 5 08:42:15 2018 From: tyler.je.reddy at gmail.com (Tyler Reddy) Date: Mon, 5 Nov 2018 05:42:15 -0800 Subject: [SciPy-Dev] SciPy 1.2.0 release schedule In-Reply-To: References: Message-ID: Alright, I'll extend to Thursday Nov. 8th & see if I can reduce that list a bit On Sun, 4 Nov 2018 at 22:27, Ralf Gommers wrote: > > > On Fri, Oct 26, 2018 at 7:03 PM Mark Alexander Mikofski < > mikofski at berkeley.edu> wrote: > >> Hi Tyler and others, >> >> Thanks for managing the v1.2 release. >> >> I think PR #8431, Cython optimize zeros API, is ready, hopefully, to >> merge. It's been through several rounds of reviews and I think I've >> accommodated all of the recommendations, all tests are passing, and there's >> been strong support. Anyone please take a look. >> >> https://github.com/scipy/scipy/pull/8431 >> >> Thanks, >> Mark >> >> On Fri, Oct 26, 2018, 2:38 PM Ralf Gommers >> wrote: >> >>> >>> >>> On Thu, Oct 25, 2018 at 12:55 PM Tyler Reddy >>> wrote: >>> >>>> Hi all, >>>> >>>> It is almost 6 months after the 1.1.0 release on May 5, so probably >>>> time to plan the 1.2.0 release. It would be a good idea to look over the PRs >>>> with a 1.2.0 milestone >>>> , >>>> and tag anything else that should have this milestone appropriately. >>>> >>>> I'd like to propose the following schedule: >>>> >>>> Nov. 5: branch 1.2.x >>>> Nov. 8: rc1 >>>> Nov. 21: rc2 (if needed) >>>> Nov. 30: final release >>>> >>>> Thoughts? >>>> >>> >>> This looks like a good schedule to me. We'll probably struggle to get >>> some PRs marked for 1.2.0 merged, but that's always the case. >>> >> > Hi Tyler, could we shift the branch date by 2-3 days (or up to a week)? > There's a couple of PRs that I'd really like to see merged or decided on > (for optimize and stats mainly), and there's right now still 18 open PRs > marked for 1.2.0. > > A note on the open PRs: what we want to aim for is to have the list of > open PRs and open blocking issues at zero, and have at most some > non-blocking issues under the milestone left. Normally the release manager > starts making those decisions, or pinging people, if other reviewers > haven't done so in time. Of course it would be ideal if everyone has > another look at > https://github.com/scipy/scipy/pulls?q=is%3Aopen+is%3Apr+milestone%3A1.2.0 > and bumps or finished off PRs he/she is involved in. > > Cheers, > Ralf > > > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at python.org > https://mail.python.org/mailman/listinfo/scipy-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.gommers at gmail.com Tue Nov 6 01:45:46 2018 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Mon, 5 Nov 2018 22:45:46 -0800 Subject: [SciPy-Dev] Truncated distributions In-Reply-To: References: Message-ID: On Mon, Nov 5, 2018 at 2:54 AM Ali Cetin wrote: > > ------------------------------ > > *From:* SciPy-Dev on > behalf of Warren Weckesser > *Sent:* Monday, November 5, 2018 10:20 > *To:* SciPy Developers List > *Subject:* Re: [SciPy-Dev] Truncated distributions > > On 11/5/18, Robert Kern wrote: > > On Sun, Nov 4, 2018 at 10:36 PM Ralf Gommers > > wrote: > >> > >> On Sun, Nov 4, 2018 at 7:01 AM Ali Cetin wrote: > >>> > >>> Hi all, > >>> > >>> I note that quite a few truncated distribution functions are available > > in SciPy - nice! > >>> > >>> However, I find the usefulness of these functions somewhat limited when > > it is desired to fit them to data; in most common scenarios the > truncation > > point is known (or even determined by the user/experimenter), and > therefore > > do not need to be treated as a free parameter. In the current scipy.stats > > framework, the truncation parameters are accepted as "shape" parameters. > > Therefore, it is only possible to lock the "normalized" truncation point > > during fitting. This is a catch-22, since the user is required to provide > > loc and scale parameters a priori, which are unknown. > >> > >> I'm not sure I follow. The fit() docstring says: "Return MLEs for shape > > (if applicable), location, and scale parameters from data." So it should > be > > fitting everything. Could you provide an example perhaps? > > > > The problem is with how we defined the truncation parameters of these > > distributions, not `fit()` per se. You are supposed to specify them > > *relative* to the `loc` and `scale`. So you could fit `truncnorm()` such > > that the bounds are fixed to, say, (-3*sigma, +3*sigma) where `sigma` is > > freely being adjusted during the fit but not to (-10, +10) regardless of > > the `scale`. Ali wants to do the latter. `fit()` doesn't work for this > use > > case. > > Thanks, that helps. > > > >>> I would like to propose a solution that only require minor adjustment > of > > the current framework: allow the user to supply the truncation point as > > part of the data array -> for left and right truncation, the 0th and the > > Nth element of the array is poped out and used as truncation parameters, > > respectively. > >> > >> That doesn't look like a viable solution. Let's first establish if there > > really is an issue like you're describing, and then look for a cleaner > > addition to the API. > > > > I agree that this is not the right approach. > > > > Personally, I think that it's hard to get all of the corner cases right > to > > make `fit()` Just Work(TM). The distributions API has a lot of them. Most > > of `fit()`'s implementation is just trying to work around as many of them > > as it can in order to be general. But the core of it is pretty > > straightforward: use a `scipy.optimize` minimizer on the `nnlf()` method. > > > > This is the way I approach it: if `fit()` does what I want it to do, > great, > > I'll use it. But if it looks hard to shoehorn what I want into `fit()`, > > I'll just go ahead and call `scipy.optimize.minimize()` myself. `fit()` > is > > a good convenience when it works in the easy cases, but the alternative > is > > straightforward for the harder ones. I don't see much benefit to trying > to > > make `fit()` scale to the harder, weirder cases. I'd rather document the > > path up to `scipy.optimize`. Ali's example would be a good recipe to > > demonstrate this. > > > I agree, and I recently did just this in an answer on stackoverflow: > > https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstackoverflow.com%2Fquestions%2F53125437%2Ffitting-data-using-scipy-truncnorm&data=02%7C01%7C%7C076bdbb82e12488e888508d643000bd8%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636770064812506740&sdata=ecii5FOijuccC49X54%2BGVZsSJNhPow%2Fl%2BFc%2FeMZWBYQ%3D&reserved=0 > > Warren > > > Thanks for chiming in on this guys. > I have created a issue on GitHub ( > https://github.com/scipy/scipy/issues/9439) with an example. (I hate > reading and writing code on mail ?). > > Anyway, I do agree with Robert and Warren that this is achievable with a > few lines of code (as I also included in the example). However, is it fair > to expect that a user without advanced understanding in > statistics/optimization problems to deal with this? (Furthermore, you can > make this argument about the regular fit method. Should we just remove the > method altogether then? Of course not.). I mean, most of my colleagues in > the industry are highly capable engineers, but statistics and probability > theory is more or less a "black-box" to them. > > I think it would be better for the end-users to alter the API to natively > accommodate for truncated distributions (as Ralf suggests). > The problem is that we're going to have corner cases like this for many distributions, and we'd spend a lot of effort trying to cover them (and failing to achieve full coverage). I agree with Robert and Warren, clearly documenting how to deal with such cases is the better solution here. A discussion and worked example in the user guide, and linking to that from the rv_continuous.fit docstring is probably the right place. Cheers, Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From ali.cetin at outlook.com Tue Nov 6 04:51:58 2018 From: ali.cetin at outlook.com (Ali Cetin) Date: Tue, 6 Nov 2018 09:51:58 +0000 Subject: [SciPy-Dev] Truncated distributions In-Reply-To: References: , Message-ID: ________________________________ From: SciPy-Dev on behalf of Ralf Gommers Sent: Tuesday, November 6, 2018 07:45 To: SciPy Developers List Subject: Re: [SciPy-Dev] Truncated distributions On Mon, Nov 5, 2018 at 2:54 AM Ali Cetin > wrote: ________________________________ From: SciPy-Dev > on behalf of Warren Weckesser > Sent: Monday, November 5, 2018 10:20 To: SciPy Developers List Subject: Re: [SciPy-Dev] Truncated distributions On 11/5/18, Robert Kern > wrote: > On Sun, Nov 4, 2018 at 10:36 PM Ralf Gommers > > wrote: >> >> On Sun, Nov 4, 2018 at 7:01 AM Ali Cetin > wrote: >>> >>> Hi all, >>> >>> I note that quite a few truncated distribution functions are available > in SciPy - nice! >>> >>> However, I find the usefulness of these functions somewhat limited when > it is desired to fit them to data; in most common scenarios the truncation > point is known (or even determined by the user/experimenter), and therefore > do not need to be treated as a free parameter. In the current scipy.stats > framework, the truncation parameters are accepted as "shape" parameters. > Therefore, it is only possible to lock the "normalized" truncation point > during fitting. This is a catch-22, since the user is required to provide > loc and scale parameters a priori, which are unknown. >> >> I'm not sure I follow. The fit() docstring says: "Return MLEs for shape > (if applicable), location, and scale parameters from data." So it should be > fitting everything. Could you provide an example perhaps? > > The problem is with how we defined the truncation parameters of these > distributions, not `fit()` per se. You are supposed to specify them > *relative* to the `loc` and `scale`. So you could fit `truncnorm()` such > that the bounds are fixed to, say, (-3*sigma, +3*sigma) where `sigma` is > freely being adjusted during the fit but not to (-10, +10) regardless of > the `scale`. Ali wants to do the latter. `fit()` doesn't work for this use > case. Thanks, that helps. > >>> I would like to propose a solution that only require minor adjustment of > the current framework: allow the user to supply the truncation point as > part of the data array -> for left and right truncation, the 0th and the > Nth element of the array is poped out and used as truncation parameters, > respectively. >> >> That doesn't look like a viable solution. Let's first establish if there > really is an issue like you're describing, and then look for a cleaner > addition to the API. > > I agree that this is not the right approach. > > Personally, I think that it's hard to get all of the corner cases right to > make `fit()` Just Work(TM). The distributions API has a lot of them. Most > of `fit()`'s implementation is just trying to work around as many of them > as it can in order to be general. But the core of it is pretty > straightforward: use a `scipy.optimize` minimizer on the `nnlf()` method. > > This is the way I approach it: if `fit()` does what I want it to do, great, > I'll use it. But if it looks hard to shoehorn what I want into `fit()`, > I'll just go ahead and call `scipy.optimize.minimize()` myself. `fit()` is > a good convenience when it works in the easy cases, but the alternative is > straightforward for the harder ones. I don't see much benefit to trying to > make `fit()` scale to the harder, weirder cases. I'd rather document the > path up to `scipy.optimize`. Ali's example would be a good recipe to > demonstrate this. I agree, and I recently did just this in an answer on stackoverflow: https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstackoverflow.com%2Fquestions%2F53125437%2Ffitting-data-using-scipy-truncnorm&data=02%7C01%7C%7C076bdbb82e12488e888508d643000bd8%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636770064812506740&sdata=ecii5FOijuccC49X54%2BGVZsSJNhPow%2Fl%2BFc%2FeMZWBYQ%3D&reserved=0 Warren Thanks for chiming in on this guys. I have created a issue on GitHub (https://github.com/scipy/scipy/issues/9439) with an example. (I hate reading and writing code on mail ?). Anyway, I do agree with Robert and Warren that this is achievable with a few lines of code (as I also included in the example). However, is it fair to expect that a user without advanced understanding in statistics/optimization problems to deal with this? (Furthermore, you can make this argument about the regular fit method. Should we just remove the method altogether then? Of course not.). I mean, most of my colleagues in the industry are highly capable engineers, but statistics and probability theory is more or less a "black-box" to them. I think it would be better for the end-users to alter the API to natively accommodate for truncated distributions (as Ralf suggests). The problem is that we're going to have corner cases like this for many distributions, and we'd spend a lot of effort trying to cover them (and failing to achieve full coverage). I agree with Robert and Warren, clearly documenting how to deal with such cases is the better solution here. A discussion and worked example in the user guide, and linking to that from the rv_continuous.fit docstring is probably the right place. Cheers, Ralf I can contribute with documenting this, just direct me towards the right place. But we have to keep in mind that it is a private method (rv_continous._penalized_nnlf) is used internally by the optimizer, and not the public nnlf method. The private method provides some boiler plate and safe guards. How about renaming it to rv_continous._penalized_nnlf -> rv_continous.objective_function, thus making the "work around" you suggest more transparent. Also, this allows the users to define custom objective functions when needed, without messing around with internal methods. Cheers, Ali -------------- next part -------------- An HTML attachment was scrubbed... URL: From serge.guelton at telecom-bretagne.eu Tue Nov 6 09:44:08 2018 From: serge.guelton at telecom-bretagne.eu (serge guelton) Date: Tue, 6 Nov 2018 15:44:08 +0100 Subject: [SciPy-Dev] Pythran 0.9.0 - kozhamzer Message-ID: <20181106144408.GA20301@lakota> Hi all, It is my pleasure to announce the release of version 0.9.0 of the Pythran compiler, a compiler for numerical kernels written in Python. It is available for download on PyPI; pip install pythran And on Conda through conda-forge: conda install -c conda-forge pythran The major change of this release is undoubtedly the use of xsimd [0] as the new vectorization engine, which in turns enables vectorization of complex number expressions! All the details are in the changelog reproduced below. And an outstanding new: looks like Pythran is used at least in one research team at Facebook \o/ In spite of the short window, we received *a lot* of bug report, thanks a lot to @DerWeh, @KOLANICH, @RalphFS, @ashwinvis, @diorcety, @h-vetinari, @jeanlaroche, @lw3259111, @paugier, @vgroff for reporting and sometimes fixing issues. Special thanks go to @wolfv and @JohanMabille for the xsimd support. We're getting closer to 1.0, which will probably be the first one to drop 2.7 support (goal: 2020). Until then, happy computations! -- Serge [0] https://github.com/QuantStack/xsimd ===== 2018-11-06 Serge Guelton * Moving to xsimd as vectorization engine, requires -DUSE_XSIMD * Better support of view conversion from Python to Pythran * Improved Cython integration * Improved documentation, add example section * Updated ArchLinux Packaging * Remove useless warnings during compilation * Faster ``abs(x**2)`` for complex numbers * IPython magic now accepts most optimization flags * Automatic detection of partially (or fully) constant shape for arrays * Add ignoreflags settings to .pythranrc to skip some compiler flags * Quad number (aka long double) basic support * And many minor bugfixes, as usual :-) From dodier at ohsu.edu Tue Nov 6 22:03:46 2018 From: dodier at ohsu.edu (Robert Dodier) Date: Wed, 7 Nov 2018 03:03:46 +0000 Subject: [SciPy-Dev] trying to understand how zi is used in lfilter Message-ID: <695A3AC8E6A07243A2F7DE0B163BF4D92D9C37D4@EXMB10.ohsu.edu> Hi, I working on translating scipy.signal.lfilter into another programming language (or at least enough of it for the current project). I am looking at the source code of Scipy 1.1.0 for that purpose. lfilter takes an optional argument zi. I see that lfilter_zi can compute a value for zi, and in the examples I've found, lfilter is called with zi = zi_foo * x[0] where zi_foo is the output from lfilter_zi and x[0] is the first input datum. I understand that zi represents the steady state value for the filter and that's great, no problem there. What I don't understand is how zi is taken into account in lfilter. lfilter punts to sigtools._linear_filter, which punts to RawFilter, and at that point I can't figure out what's going on anymore. Can anyone guide me to any description of the use of zi in lfilter, _linear_filter, or RawFilter? A formula, some comments, a Wikipedia page, anything would be very helpful. Thanks very much for any light you can shed on this question. Robert Dodier From tyler.je.reddy at gmail.com Wed Nov 7 00:02:52 2018 From: tyler.je.reddy at gmail.com (Tyler Reddy) Date: Tue, 6 Nov 2018 21:02:52 -0800 Subject: [SciPy-Dev] SciPy 1.2.0 release schedule In-Reply-To: References: Message-ID: 7 PRs : https://github.com/scipy/scipy/pulls?q=is%3Aopen+is%3Apr+milestone%3A1.2.0 3 issues: https://github.com/scipy/scipy/issues?q=is%3Aopen+is%3Aissue+milestone%3A1.2.0 Target: branch sometime on November 8th On Mon, 5 Nov 2018 at 05:42, Tyler Reddy wrote: > Alright, I'll extend to Thursday Nov. 8th & see if I can reduce that list > a bit > > On Sun, 4 Nov 2018 at 22:27, Ralf Gommers wrote: > >> >> >> On Fri, Oct 26, 2018 at 7:03 PM Mark Alexander Mikofski < >> mikofski at berkeley.edu> wrote: >> >>> Hi Tyler and others, >>> >>> Thanks for managing the v1.2 release. >>> >>> I think PR #8431, Cython optimize zeros API, is ready, hopefully, to >>> merge. It's been through several rounds of reviews and I think I've >>> accommodated all of the recommendations, all tests are passing, and there's >>> been strong support. Anyone please take a look. >>> >>> https://github.com/scipy/scipy/pull/8431 >>> >>> Thanks, >>> Mark >>> >>> On Fri, Oct 26, 2018, 2:38 PM Ralf Gommers >>> wrote: >>> >>>> >>>> >>>> On Thu, Oct 25, 2018 at 12:55 PM Tyler Reddy >>>> wrote: >>>> >>>>> Hi all, >>>>> >>>>> It is almost 6 months after the 1.1.0 release on May 5, so probably >>>>> time to plan the 1.2.0 release. It would be a good idea to look over the PRs >>>>> with a 1.2.0 milestone >>>>> , >>>>> and tag anything else that should have this milestone appropriately. >>>>> >>>>> I'd like to propose the following schedule: >>>>> >>>>> Nov. 5: branch 1.2.x >>>>> Nov. 8: rc1 >>>>> Nov. 21: rc2 (if needed) >>>>> Nov. 30: final release >>>>> >>>>> Thoughts? >>>>> >>>> >>>> This looks like a good schedule to me. We'll probably struggle to get >>>> some PRs marked for 1.2.0 merged, but that's always the case. >>>> >>> >> Hi Tyler, could we shift the branch date by 2-3 days (or up to a week)? >> There's a couple of PRs that I'd really like to see merged or decided on >> (for optimize and stats mainly), and there's right now still 18 open PRs >> marked for 1.2.0. >> >> A note on the open PRs: what we want to aim for is to have the list of >> open PRs and open blocking issues at zero, and have at most some >> non-blocking issues under the milestone left. Normally the release manager >> starts making those decisions, or pinging people, if other reviewers >> haven't done so in time. Of course it would be ideal if everyone has >> another look at >> https://github.com/scipy/scipy/pulls?q=is%3Aopen+is%3Apr+milestone%3A1.2.0 >> and bumps or finished off PRs he/she is involved in. >> >> Cheers, >> Ralf >> >> >> >> _______________________________________________ >> SciPy-Dev mailing list >> SciPy-Dev at python.org >> https://mail.python.org/mailman/listinfo/scipy-dev >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.gommers at gmail.com Wed Nov 7 00:06:59 2018 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Tue, 6 Nov 2018 21:06:59 -0800 Subject: [SciPy-Dev] SciPy 1.2.0 release schedule In-Reply-To: References: Message-ID: On Tue, Nov 6, 2018 at 9:03 PM Tyler Reddy wrote: > 7 PRs : > https://github.com/scipy/scipy/pulls?q=is%3Aopen+is%3Apr+milestone%3A1.2.0 > 3 issues: > https://github.com/scipy/scipy/issues?q=is%3Aopen+is%3Aissue+milestone%3A1.2.0 > Awesome, getting there:) > Target: branch sometime on November 8th > > On Mon, 5 Nov 2018 at 05:42, Tyler Reddy wrote: > >> Alright, I'll extend to Thursday Nov. 8th & see if I can reduce that list >> a bit >> >> On Sun, 4 Nov 2018 at 22:27, Ralf Gommers wrote: >> >>> >>> >>> On Fri, Oct 26, 2018 at 7:03 PM Mark Alexander Mikofski < >>> mikofski at berkeley.edu> wrote: >>> >>>> Hi Tyler and others, >>>> >>>> Thanks for managing the v1.2 release. >>>> >>>> I think PR #8431, Cython optimize zeros API, is ready, hopefully, to >>>> merge. It's been through several rounds of reviews and I think I've >>>> accommodated all of the recommendations, all tests are passing, and there's >>>> been strong support. Anyone please take a look. >>>> >>>> https://github.com/scipy/scipy/pull/8431 >>>> >>>> Thanks, >>>> Mark >>>> >>>> On Fri, Oct 26, 2018, 2:38 PM Ralf Gommers >>>> wrote: >>>> >>>>> >>>>> >>>>> On Thu, Oct 25, 2018 at 12:55 PM Tyler Reddy >>>>> wrote: >>>>> >>>>>> Hi all, >>>>>> >>>>>> It is almost 6 months after the 1.1.0 release on May 5, so probably >>>>>> time to plan the 1.2.0 release. It would be a good idea to look over the PRs >>>>>> with a 1.2.0 milestone >>>>>> , >>>>>> and tag anything else that should have this milestone appropriately. >>>>>> >>>>>> I'd like to propose the following schedule: >>>>>> >>>>>> Nov. 5: branch 1.2.x >>>>>> Nov. 8: rc1 >>>>>> Nov. 21: rc2 (if needed) >>>>>> Nov. 30: final release >>>>>> >>>>>> Thoughts? >>>>>> >>>>> >>>>> This looks like a good schedule to me. We'll probably struggle to get >>>>> some PRs marked for 1.2.0 merged, but that's always the case. >>>>> >>>> >>> Hi Tyler, could we shift the branch date by 2-3 days (or up to a week)? >>> There's a couple of PRs that I'd really like to see merged or decided on >>> (for optimize and stats mainly), and there's right now still 18 open PRs >>> marked for 1.2.0. >>> >>> A note on the open PRs: what we want to aim for is to have the list of >>> open PRs and open blocking issues at zero, and have at most some >>> non-blocking issues under the milestone left. Normally the release manager >>> starts making those decisions, or pinging people, if other reviewers >>> haven't done so in time. Of course it would be ideal if everyone has >>> another look at >>> https://github.com/scipy/scipy/pulls?q=is%3Aopen+is%3Apr+milestone%3A1.2.0 >>> and bumps or finished off PRs he/she is involved in. >>> >>> Cheers, >>> Ralf >>> >>> >>> >>> _______________________________________________ >>> SciPy-Dev mailing list >>> SciPy-Dev at python.org >>> https://mail.python.org/mailman/listinfo/scipy-dev >>> >> _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at python.org > https://mail.python.org/mailman/listinfo/scipy-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ilhanpolat at gmail.com Wed Nov 7 12:51:20 2018 From: ilhanpolat at gmail.com (Ilhan Polat) Date: Wed, 7 Nov 2018 18:51:20 +0100 Subject: [SciPy-Dev] SciPy 1.2.0 release schedule In-Reply-To: References: Message-ID: Hang in there Tyler :) Awesome job so far. On Wed, Nov 7, 2018, 06:08 Ralf Gommers wrote: > > > On Tue, Nov 6, 2018 at 9:03 PM Tyler Reddy > wrote: > >> 7 PRs : >> https://github.com/scipy/scipy/pulls?q=is%3Aopen+is%3Apr+milestone%3A1.2.0 >> 3 issues: >> https://github.com/scipy/scipy/issues?q=is%3Aopen+is%3Aissue+milestone%3A1.2.0 >> > > Awesome, getting there:) > > >> Target: branch sometime on November 8th >> >> On Mon, 5 Nov 2018 at 05:42, Tyler Reddy >> wrote: >> >>> Alright, I'll extend to Thursday Nov. 8th & see if I can reduce that >>> list a bit >>> >>> On Sun, 4 Nov 2018 at 22:27, Ralf Gommers >>> wrote: >>> >>>> >>>> >>>> On Fri, Oct 26, 2018 at 7:03 PM Mark Alexander Mikofski < >>>> mikofski at berkeley.edu> wrote: >>>> >>>>> Hi Tyler and others, >>>>> >>>>> Thanks for managing the v1.2 release. >>>>> >>>>> I think PR #8431, Cython optimize zeros API, is ready, hopefully, to >>>>> merge. It's been through several rounds of reviews and I think I've >>>>> accommodated all of the recommendations, all tests are passing, and there's >>>>> been strong support. Anyone please take a look. >>>>> >>>>> https://github.com/scipy/scipy/pull/8431 >>>>> >>>>> Thanks, >>>>> Mark >>>>> >>>>> On Fri, Oct 26, 2018, 2:38 PM Ralf Gommers >>>>> wrote: >>>>> >>>>>> >>>>>> >>>>>> On Thu, Oct 25, 2018 at 12:55 PM Tyler Reddy < >>>>>> tyler.je.reddy at gmail.com> wrote: >>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> It is almost 6 months after the 1.1.0 release on May 5, so probably >>>>>>> time to plan the 1.2.0 release. It would be a good idea to look over the PRs >>>>>>> with a 1.2.0 milestone >>>>>>> , >>>>>>> and tag anything else that should have this milestone appropriately. >>>>>>> >>>>>>> I'd like to propose the following schedule: >>>>>>> >>>>>>> Nov. 5: branch 1.2.x >>>>>>> Nov. 8: rc1 >>>>>>> Nov. 21: rc2 (if needed) >>>>>>> Nov. 30: final release >>>>>>> >>>>>>> Thoughts? >>>>>>> >>>>>> >>>>>> This looks like a good schedule to me. We'll probably struggle to get >>>>>> some PRs marked for 1.2.0 merged, but that's always the case. >>>>>> >>>>> >>>> Hi Tyler, could we shift the branch date by 2-3 days (or up to a week)? >>>> There's a couple of PRs that I'd really like to see merged or decided on >>>> (for optimize and stats mainly), and there's right now still 18 open PRs >>>> marked for 1.2.0. >>>> >>>> A note on the open PRs: what we want to aim for is to have the list of >>>> open PRs and open blocking issues at zero, and have at most some >>>> non-blocking issues under the milestone left. Normally the release manager >>>> starts making those decisions, or pinging people, if other reviewers >>>> haven't done so in time. Of course it would be ideal if everyone has >>>> another look at >>>> https://github.com/scipy/scipy/pulls?q=is%3Aopen+is%3Apr+milestone%3A1.2.0 >>>> and bumps or finished off PRs he/she is involved in. >>>> >>>> Cheers, >>>> Ralf >>>> >>>> >>>> >>>> _______________________________________________ >>>> SciPy-Dev mailing list >>>> SciPy-Dev at python.org >>>> https://mail.python.org/mailman/listinfo/scipy-dev >>>> >>> _______________________________________________ >> SciPy-Dev mailing list >> SciPy-Dev at python.org >> https://mail.python.org/mailman/listinfo/scipy-dev >> > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at python.org > https://mail.python.org/mailman/listinfo/scipy-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dodier at ohsu.edu Wed Nov 7 20:48:25 2018 From: dodier at ohsu.edu (Robert Dodier) Date: Thu, 8 Nov 2018 01:48:25 +0000 Subject: [SciPy-Dev] trying to understand how zi is used in lfilter In-Reply-To: <695A3AC8E6A07243A2F7DE0B163BF4D92D9C37D4@EXMB10.ohsu.edu> References: <695A3AC8E6A07243A2F7DE0B163BF4D92D9C37D4@EXMB10.ohsu.edu> Message-ID: <695A3AC8E6A07243A2F7DE0B163BF4D92D9C383A@EXMB10.ohsu.edu> Hi, I'm answering my own question here -- I think I got it sorted out. zi as computed by lfilter_zi is supposed to be internal state of the filter, which are represented by the variables d[0] through d[N - 1] in the comment header for lfilter. So the way that zi comes into play is by assigning zi[k] to d[k] at the outset of lfilter. From there on out, the d values are updated from x and y values. Maybe this information will be helpful to someone someday. best, Robert Dodier From tyler.je.reddy at gmail.com Thu Nov 8 17:35:42 2018 From: tyler.je.reddy at gmail.com (Tyler Reddy) Date: Thu, 8 Nov 2018 14:35:42 -0800 Subject: [SciPy-Dev] SciPy 1.2.0 release schedule In-Reply-To: References: Message-ID: There are 0 remaining PRs with a 1.2.0 milestone. There is one issue left with a 1.2.0 milestone: https://github.com/scipy/scipy/issues/9441 Please do take a look over the release notes WIP PR based on the wiki: https://github.com/scipy/scipy/pull/9461 Target is to branch in 5-6 hours or so. Let me know if you see any issues of course -- Ralf has been coaching me through pretty well so far I think. On Wed, 7 Nov 2018 at 09:52, Ilhan Polat wrote: > Hang in there Tyler :) > > Awesome job so far. > > > On Wed, Nov 7, 2018, 06:08 Ralf Gommers wrote: > >> >> >> On Tue, Nov 6, 2018 at 9:03 PM Tyler Reddy >> wrote: >> >>> 7 PRs : >>> https://github.com/scipy/scipy/pulls?q=is%3Aopen+is%3Apr+milestone%3A1.2.0 >>> 3 issues: >>> https://github.com/scipy/scipy/issues?q=is%3Aopen+is%3Aissue+milestone%3A1.2.0 >>> >> >> Awesome, getting there:) >> >> >>> Target: branch sometime on November 8th >>> >>> On Mon, 5 Nov 2018 at 05:42, Tyler Reddy >>> wrote: >>> >>>> Alright, I'll extend to Thursday Nov. 8th & see if I can reduce that >>>> list a bit >>>> >>>> On Sun, 4 Nov 2018 at 22:27, Ralf Gommers >>>> wrote: >>>> >>>>> >>>>> >>>>> On Fri, Oct 26, 2018 at 7:03 PM Mark Alexander Mikofski < >>>>> mikofski at berkeley.edu> wrote: >>>>> >>>>>> Hi Tyler and others, >>>>>> >>>>>> Thanks for managing the v1.2 release. >>>>>> >>>>>> I think PR #8431, Cython optimize zeros API, is ready, hopefully, to >>>>>> merge. It's been through several rounds of reviews and I think I've >>>>>> accommodated all of the recommendations, all tests are passing, and there's >>>>>> been strong support. Anyone please take a look. >>>>>> >>>>>> https://github.com/scipy/scipy/pull/8431 >>>>>> >>>>>> Thanks, >>>>>> Mark >>>>>> >>>>>> On Fri, Oct 26, 2018, 2:38 PM Ralf Gommers >>>>>> wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On Thu, Oct 25, 2018 at 12:55 PM Tyler Reddy < >>>>>>> tyler.je.reddy at gmail.com> wrote: >>>>>>> >>>>>>>> Hi all, >>>>>>>> >>>>>>>> It is almost 6 months after the 1.1.0 release on May 5, so probably >>>>>>>> time to plan the 1.2.0 release. It would be a good idea to look over the PRs >>>>>>>> with a 1.2.0 milestone >>>>>>>> , >>>>>>>> and tag anything else that should have this milestone appropriately. >>>>>>>> >>>>>>>> I'd like to propose the following schedule: >>>>>>>> >>>>>>>> Nov. 5: branch 1.2.x >>>>>>>> Nov. 8: rc1 >>>>>>>> Nov. 21: rc2 (if needed) >>>>>>>> Nov. 30: final release >>>>>>>> >>>>>>>> Thoughts? >>>>>>>> >>>>>>> >>>>>>> This looks like a good schedule to me. We'll probably struggle to >>>>>>> get some PRs marked for 1.2.0 merged, but that's always the case. >>>>>>> >>>>>> >>>>> Hi Tyler, could we shift the branch date by 2-3 days (or up to a >>>>> week)? There's a couple of PRs that I'd really like to see merged or >>>>> decided on (for optimize and stats mainly), and there's right now still 18 >>>>> open PRs marked for 1.2.0. >>>>> >>>>> A note on the open PRs: what we want to aim for is to have the list of >>>>> open PRs and open blocking issues at zero, and have at most some >>>>> non-blocking issues under the milestone left. Normally the release manager >>>>> starts making those decisions, or pinging people, if other reviewers >>>>> haven't done so in time. Of course it would be ideal if everyone has >>>>> another look at >>>>> https://github.com/scipy/scipy/pulls?q=is%3Aopen+is%3Apr+milestone%3A1.2.0 >>>>> and bumps or finished off PRs he/she is involved in. >>>>> >>>>> Cheers, >>>>> Ralf >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> SciPy-Dev mailing list >>>>> SciPy-Dev at python.org >>>>> https://mail.python.org/mailman/listinfo/scipy-dev >>>>> >>>> _______________________________________________ >>> SciPy-Dev mailing list >>> SciPy-Dev at python.org >>> https://mail.python.org/mailman/listinfo/scipy-dev >>> >> _______________________________________________ >> SciPy-Dev mailing list >> SciPy-Dev at python.org >> https://mail.python.org/mailman/listinfo/scipy-dev >> > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at python.org > https://mail.python.org/mailman/listinfo/scipy-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tyler.je.reddy at gmail.com Fri Nov 9 01:49:17 2018 From: tyler.je.reddy at gmail.com (Tyler Reddy) Date: Thu, 8 Nov 2018 22:49:17 -0800 Subject: [SciPy-Dev] SciPy 1.2.0 release schedule In-Reply-To: References: Message-ID: Release note PR is hopefully taking shape now -- I'll allow (another) delay for the branch until tomorrow (morning?) for some (hopefully final) checks on that. On Thu, 8 Nov 2018 at 14:35, Tyler Reddy wrote: > There are 0 remaining PRs with a 1.2.0 milestone. > > There is one issue left with a 1.2.0 milestone: > https://github.com/scipy/scipy/issues/9441 > > Please do take a look over the release notes WIP PR based on the wiki: > https://github.com/scipy/scipy/pull/9461 > > Target is to branch in 5-6 hours or so. Let me know if you see any issues > of course -- Ralf has been coaching > me through pretty well so far I think. > > On Wed, 7 Nov 2018 at 09:52, Ilhan Polat wrote: > >> Hang in there Tyler :) >> >> Awesome job so far. >> >> >> On Wed, Nov 7, 2018, 06:08 Ralf Gommers wrote: >> >>> >>> >>> On Tue, Nov 6, 2018 at 9:03 PM Tyler Reddy >>> wrote: >>> >>>> 7 PRs : >>>> https://github.com/scipy/scipy/pulls?q=is%3Aopen+is%3Apr+milestone%3A1.2.0 >>>> 3 issues: >>>> https://github.com/scipy/scipy/issues?q=is%3Aopen+is%3Aissue+milestone%3A1.2.0 >>>> >>> >>> Awesome, getting there:) >>> >>> >>>> Target: branch sometime on November 8th >>>> >>>> On Mon, 5 Nov 2018 at 05:42, Tyler Reddy >>>> wrote: >>>> >>>>> Alright, I'll extend to Thursday Nov. 8th & see if I can reduce that >>>>> list a bit >>>>> >>>>> On Sun, 4 Nov 2018 at 22:27, Ralf Gommers >>>>> wrote: >>>>> >>>>>> >>>>>> >>>>>> On Fri, Oct 26, 2018 at 7:03 PM Mark Alexander Mikofski < >>>>>> mikofski at berkeley.edu> wrote: >>>>>> >>>>>>> Hi Tyler and others, >>>>>>> >>>>>>> Thanks for managing the v1.2 release. >>>>>>> >>>>>>> I think PR #8431, Cython optimize zeros API, is ready, hopefully, to >>>>>>> merge. It's been through several rounds of reviews and I think I've >>>>>>> accommodated all of the recommendations, all tests are passing, and there's >>>>>>> been strong support. Anyone please take a look. >>>>>>> >>>>>>> https://github.com/scipy/scipy/pull/8431 >>>>>>> >>>>>>> Thanks, >>>>>>> Mark >>>>>>> >>>>>>> On Fri, Oct 26, 2018, 2:38 PM Ralf Gommers >>>>>>> wrote: >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Thu, Oct 25, 2018 at 12:55 PM Tyler Reddy < >>>>>>>> tyler.je.reddy at gmail.com> wrote: >>>>>>>> >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> It is almost 6 months after the 1.1.0 release on May 5, so >>>>>>>>> probably time to plan the 1.2.0 release. It would be a good idea to look >>>>>>>>> over the PRs with a 1.2.0 milestone >>>>>>>>> , >>>>>>>>> and tag anything else that should have this milestone appropriately. >>>>>>>>> >>>>>>>>> I'd like to propose the following schedule: >>>>>>>>> >>>>>>>>> Nov. 5: branch 1.2.x >>>>>>>>> Nov. 8: rc1 >>>>>>>>> Nov. 21: rc2 (if needed) >>>>>>>>> Nov. 30: final release >>>>>>>>> >>>>>>>>> Thoughts? >>>>>>>>> >>>>>>>> >>>>>>>> This looks like a good schedule to me. We'll probably struggle to >>>>>>>> get some PRs marked for 1.2.0 merged, but that's always the case. >>>>>>>> >>>>>>> >>>>>> Hi Tyler, could we shift the branch date by 2-3 days (or up to a >>>>>> week)? There's a couple of PRs that I'd really like to see merged or >>>>>> decided on (for optimize and stats mainly), and there's right now still 18 >>>>>> open PRs marked for 1.2.0. >>>>>> >>>>>> A note on the open PRs: what we want to aim for is to have the list >>>>>> of open PRs and open blocking issues at zero, and have at most some >>>>>> non-blocking issues under the milestone left. Normally the release manager >>>>>> starts making those decisions, or pinging people, if other reviewers >>>>>> haven't done so in time. Of course it would be ideal if everyone has >>>>>> another look at >>>>>> https://github.com/scipy/scipy/pulls?q=is%3Aopen+is%3Apr+milestone%3A1.2.0 >>>>>> and bumps or finished off PRs he/she is involved in. >>>>>> >>>>>> Cheers, >>>>>> Ralf >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> SciPy-Dev mailing list >>>>>> SciPy-Dev at python.org >>>>>> https://mail.python.org/mailman/listinfo/scipy-dev >>>>>> >>>>> _______________________________________________ >>>> SciPy-Dev mailing list >>>> SciPy-Dev at python.org >>>> https://mail.python.org/mailman/listinfo/scipy-dev >>>> >>> _______________________________________________ >>> SciPy-Dev mailing list >>> SciPy-Dev at python.org >>> https://mail.python.org/mailman/listinfo/scipy-dev >>> >> _______________________________________________ >> SciPy-Dev mailing list >> SciPy-Dev at python.org >> https://mail.python.org/mailman/listinfo/scipy-dev >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tyler.je.reddy at gmail.com Fri Nov 9 11:40:46 2018 From: tyler.je.reddy at gmail.com (Tyler Reddy) Date: Fri, 9 Nov 2018 08:40:46 -0800 Subject: [SciPy-Dev] SciPy 1.2.0 release schedule In-Reply-To: References: Message-ID: I branched 1.2.x around 8:30 am Pacific time on Nov. 9, 2018. Working on the follow up master branch PR to bump version number / notes file, etc. now. On Thu, 8 Nov 2018 at 22:49, Tyler Reddy wrote: > Release note PR is hopefully taking shape now -- I'll allow (another) > delay for the branch until tomorrow (morning?) for some (hopefully final) > checks on that. > > On Thu, 8 Nov 2018 at 14:35, Tyler Reddy wrote: > >> There are 0 remaining PRs with a 1.2.0 milestone. >> >> There is one issue left with a 1.2.0 milestone: >> https://github.com/scipy/scipy/issues/9441 >> >> Please do take a look over the release notes WIP PR based on the wiki: >> https://github.com/scipy/scipy/pull/9461 >> >> Target is to branch in 5-6 hours or so. Let me know if you see any issues >> of course -- Ralf has been coaching >> me through pretty well so far I think. >> >> On Wed, 7 Nov 2018 at 09:52, Ilhan Polat wrote: >> >>> Hang in there Tyler :) >>> >>> Awesome job so far. >>> >>> >>> On Wed, Nov 7, 2018, 06:08 Ralf Gommers wrote: >>> >>>> >>>> >>>> On Tue, Nov 6, 2018 at 9:03 PM Tyler Reddy >>>> wrote: >>>> >>>>> 7 PRs : >>>>> https://github.com/scipy/scipy/pulls?q=is%3Aopen+is%3Apr+milestone%3A1.2.0 >>>>> 3 issues: >>>>> https://github.com/scipy/scipy/issues?q=is%3Aopen+is%3Aissue+milestone%3A1.2.0 >>>>> >>>> >>>> Awesome, getting there:) >>>> >>>> >>>>> Target: branch sometime on November 8th >>>>> >>>>> On Mon, 5 Nov 2018 at 05:42, Tyler Reddy >>>>> wrote: >>>>> >>>>>> Alright, I'll extend to Thursday Nov. 8th & see if I can reduce that >>>>>> list a bit >>>>>> >>>>>> On Sun, 4 Nov 2018 at 22:27, Ralf Gommers >>>>>> wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On Fri, Oct 26, 2018 at 7:03 PM Mark Alexander Mikofski < >>>>>>> mikofski at berkeley.edu> wrote: >>>>>>> >>>>>>>> Hi Tyler and others, >>>>>>>> >>>>>>>> Thanks for managing the v1.2 release. >>>>>>>> >>>>>>>> I think PR #8431, Cython optimize zeros API, is ready, hopefully, >>>>>>>> to merge. It's been through several rounds of reviews and I think I've >>>>>>>> accommodated all of the recommendations, all tests are passing, and there's >>>>>>>> been strong support. Anyone please take a look. >>>>>>>> >>>>>>>> https://github.com/scipy/scipy/pull/8431 >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Mark >>>>>>>> >>>>>>>> On Fri, Oct 26, 2018, 2:38 PM Ralf Gommers >>>>>>>> wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Thu, Oct 25, 2018 at 12:55 PM Tyler Reddy < >>>>>>>>> tyler.je.reddy at gmail.com> wrote: >>>>>>>>> >>>>>>>>>> Hi all, >>>>>>>>>> >>>>>>>>>> It is almost 6 months after the 1.1.0 release on May 5, so >>>>>>>>>> probably time to plan the 1.2.0 release. It would be a good idea to look >>>>>>>>>> over the PRs with a 1.2.0 milestone >>>>>>>>>> , >>>>>>>>>> and tag anything else that should have this milestone appropriately. >>>>>>>>>> >>>>>>>>>> I'd like to propose the following schedule: >>>>>>>>>> >>>>>>>>>> Nov. 5: branch 1.2.x >>>>>>>>>> Nov. 8: rc1 >>>>>>>>>> Nov. 21: rc2 (if needed) >>>>>>>>>> Nov. 30: final release >>>>>>>>>> >>>>>>>>>> Thoughts? >>>>>>>>>> >>>>>>>>> >>>>>>>>> This looks like a good schedule to me. We'll probably struggle to >>>>>>>>> get some PRs marked for 1.2.0 merged, but that's always the case. >>>>>>>>> >>>>>>>> >>>>>>> Hi Tyler, could we shift the branch date by 2-3 days (or up to a >>>>>>> week)? There's a couple of PRs that I'd really like to see merged or >>>>>>> decided on (for optimize and stats mainly), and there's right now still 18 >>>>>>> open PRs marked for 1.2.0. >>>>>>> >>>>>>> A note on the open PRs: what we want to aim for is to have the list >>>>>>> of open PRs and open blocking issues at zero, and have at most some >>>>>>> non-blocking issues under the milestone left. Normally the release manager >>>>>>> starts making those decisions, or pinging people, if other reviewers >>>>>>> haven't done so in time. Of course it would be ideal if everyone has >>>>>>> another look at >>>>>>> https://github.com/scipy/scipy/pulls?q=is%3Aopen+is%3Apr+milestone%3A1.2.0 >>>>>>> and bumps or finished off PRs he/she is involved in. >>>>>>> >>>>>>> Cheers, >>>>>>> Ralf >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> SciPy-Dev mailing list >>>>>>> SciPy-Dev at python.org >>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev >>>>>>> >>>>>> _______________________________________________ >>>>> SciPy-Dev mailing list >>>>> SciPy-Dev at python.org >>>>> https://mail.python.org/mailman/listinfo/scipy-dev >>>>> >>>> _______________________________________________ >>>> SciPy-Dev mailing list >>>> SciPy-Dev at python.org >>>> https://mail.python.org/mailman/listinfo/scipy-dev >>>> >>> _______________________________________________ >>> SciPy-Dev mailing list >>> SciPy-Dev at python.org >>> https://mail.python.org/mailman/listinfo/scipy-dev >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.gommers at gmail.com Sat Nov 10 22:22:33 2018 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Sat, 10 Nov 2018 19:22:33 -0800 Subject: [SciPy-Dev] dropping python 2.7 and numpy <1.13.3 Message-ID: Hi all, I've always had in mind that SciPy would follow NumPy in its timeline for dropping Python 2.7. However, as far as I can tell we've never had the discussion on this list. So here's the proposal: Let's follow NumPy's timeline [1], which says that from 1 Jan 2019 onwards new releases will be Python 3 only, and the last release before that date will be an LTS release. That means SciPy 1.2.0 will be the LTS release, and 1.3.0 will be >= py3.5. Also, we haven't changed the minimum numpy version we support in quite a while, we're still at 1.8.2. And that will have to change anyway after dropping Python 2.7. The current minimum numpy versions we require are: - py27: 1.8.2 - py35: 1.9.3 - py36: 1.12.1 - py37: 1.13.1 We have always aimed to support at least 4 numpy versions (i.e. 2 year old versions). The differences per Python version in minimum numpy version are annoying (we don't consistently check that in our main __init__.py or in setup.py even), so I propose that for SciPy 1.3.0 we raise the minimum required NumPy version to 1.13.3. That'll still be 4 supported releases, 1.13.3-1.16.x. Cheers, Ralf [1] http://www.numpy.org/neps/nep-0014-dropping-python2.7-proposal.html [2] NumPy thread on dropping py27: https://mail.python.org/pipermail/numpy-discussion/2017-November/077341.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From evgeny.burovskiy at gmail.com Sun Nov 11 05:07:31 2018 From: evgeny.burovskiy at gmail.com (Evgeni Burovski) Date: Sun, 11 Nov 2018 13:07:31 +0300 Subject: [SciPy-Dev] dropping python 2.7 and numpy <1.13.3 In-Reply-To: References: Message-ID: Hi, > > Let's follow NumPy's timeline [1], which says that from 1 Jan 2019 onwards > new releases will be Python 3 only, and the last release before that date > will be an LTS release. That means SciPy 1.2.0 will be the LTS release, and > 1.3.0 will be >= py3.5. > +1 We should also think a bit about the timeline for cleanups and removals of py2/py3 workarounds. Maybe it's useful to postpone large-scale cleanups a bit. For example, how about we state that we allow new code to be py3-only, but we do not remove existing py2 constructs puntil scipy 1.14? Or for the duration of the LTS support. Also, we haven't changed the minimum numpy version we support in quite a > while, we're still at 1.8.2. And that will have to change anyway after > dropping Python 2.7. The current minimum numpy versions we require are: > - py27: 1.8.2 > - py35: 1.9.3 > - py36: 1.12.1 > - py37: 1.13.1 > We have always aimed to support at least 4 numpy versions (i.e. 2 year old > versions). The differences per Python version in minimum numpy version are > annoying (we don't consistently check that in our main __init__.py or in > setup.py even), so I propose that for SciPy 1.3.0 we raise the minimum > required NumPy version to 1.13.3. That'll still be 4 supported releases, > 1.13.3-1.16.x. > +1 in general. However numpy 1.13.0 has been released in July 2017, so it makes it less then two full years. I don't have a firm opinion on what is the optimum time from the last supported numpy version though. Cheers, > Ralf > > [1] http://www.numpy.org/neps/nep-0014-dropping-python2.7-proposal.html > [2] NumPy thread on dropping py27: > https://mail.python.org/pipermail/numpy-discussion/2017-November/077341.html > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at python.org > https://mail.python.org/mailman/listinfo/scipy-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From p.vanmulbregt at comcast.net Sun Nov 11 13:23:07 2018 From: p.vanmulbregt at comcast.net (Paul van Mulbregt) Date: Sun, 11 Nov 2018 13:23:07 -0500 Subject: [SciPy-Dev] dropping python 2.7 and numpy <1.13.3 In-Reply-To: References: Message-ID: <7AFCB2C5-1AF7-4118-BE52-5BDE97104553@comcast.net> Py 2.7 means more than just "Python2.7". We have tool chains for the various versions of Python, with (perhaps hidden) dependencies. In particular, I?m thinking of Python2.7 on Windows, which is built with MSVisualC++ v9. Since MSVC9 isn?t fully C99 compliant, SciPy has had to forgo many features of C99 to stay compatible, let alone C11 or C18. Perhaps now would be a good time to list our dependencies explicitly and think about the toolchain roadmap in general? BTW, Py3.5 and 3.6 are built with VisualC++ v14.0. See https://wiki.python.org/moin/WindowsCompilers#Which_Microsoft_Visual_C.2B-.2B-_compiler_to_use_with_a_specific_Python_version_.3F -Paul > On Nov 11, 2018, at 5:07 AM, Evgeni Burovski wrote: > > Hi, > > > > Let's follow NumPy's timeline [1], which says that from 1 Jan 2019 onwards new releases will be Python 3 only, and the last release before that date will be an LTS release. That means SciPy 1.2.0 will be the LTS release, and 1.3.0 will be >= py3.5. > > +1 > > We should also think a bit about the timeline for cleanups and removals of py2/py3 workarounds. > Maybe it's useful to postpone large-scale cleanups a bit. > For example, how about we state that we allow new code to be py3-only, but we do not remove existing py2 constructs puntil scipy 1.14? Or for the duration of the LTS support. > > > > Also, we haven't changed the minimum numpy version we support in quite a while, we're still at 1.8.2. And that will have to change anyway after dropping Python 2.7. The current minimum numpy versions we require are: > - py27: 1.8.2 > - py35: 1.9.3 > - py36: 1.12.1 > - py37: 1.13.1 > We have always aimed to support at least 4 numpy versions (i.e. 2 year old versions). The differences per Python version in minimum numpy version are annoying (we don't consistently check that in our main __init__.py or in setup.py even), so I propose that for SciPy 1.3.0 we raise the minimum required NumPy version to 1.13.3. That'll still be 4 supported releases, 1.13.3-1.16.x. > > +1 in general. > > However numpy 1.13.0 has been released in July 2017, so it makes it less then two full years. I don't have a firm opinion on what is the optimum time from the last supported numpy version though. > > > Cheers, > Ralf > > [1] http://www.numpy.org/neps/nep-0014-dropping-python2.7-proposal.html > [2] NumPy thread on dropping py27: https://mail.python.org/pipermail/numpy-discussion/2017-November/077341.html > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at python.org > https://mail.python.org/mailman/listinfo/scipy-dev > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at python.org > https://mail.python.org/mailman/listinfo/scipy-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.gommers at gmail.com Sun Nov 11 14:51:54 2018 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Sun, 11 Nov 2018 11:51:54 -0800 Subject: [SciPy-Dev] dropping python 2.7 and numpy <1.13.3 In-Reply-To: <7AFCB2C5-1AF7-4118-BE52-5BDE97104553@comcast.net> References: <7AFCB2C5-1AF7-4118-BE52-5BDE97104553@comcast.net> Message-ID: On Sun, Nov 11, 2018 at 10:28 AM Paul van Mulbregt < p.vanmulbregt at comcast.net> wrote: > Py 2.7 means more than just "Python2.7". We have tool chains for the > various versions of Python, with (perhaps hidden) dependencies. In > particular, I?m thinking of Python2.7 on Windows, which is built with > MSVisualC++ v9. Since MSVC9 isn?t fully C99 compliant, SciPy has had to > forgo many features of C99 to stay compatible, let alone C11 or C18. > Yes, a more recent MSVC is an important benefit. We'll still have to deal with more minor non-C99-compliance on mor exotic platforms (AIX, Solaris, etc.) but that's less of a problem. > Perhaps now would be a good time to list our dependencies explicitly and > think about the toolchain roadmap in general? > There's: - Cython: we always require a recent one, are about to bump to >0.28.5 or 0.29 - NumPy: proposed >1.13.3 - compilers: in general, whatever works for the Python versions we target. and we're accepting patches as needed for more exotic compilers supported by numpy.distutils(issue volume is very low). - LAPACK: >=3.4.1 - OpenBLAS: whichever recent version works (usually only 1-2 versions that are non-buggy enough). - Sphinx + numpydoc: whatever recent versions work. >= 1.6.6 for Sphinx and 0.8.0 for numpydoc I believe. - pytest/asv/wheel/multibuild: same, something recent. This is documented in various places, but usually not very complete or up-to-date unfortunately. Most of those dependencies are independent from each other. Cheers, Ralf > > BTW, Py3.5 and 3.6 are built with VisualC++ v14.0. See > > https://wiki.python.org/moin/WindowsCompilers#Which_Microsoft_Visual_C.2B-.2B-_compiler_to_use_with_a_specific_Python_version_.3F > > -Paul > > > On Nov 11, 2018, at 5:07 AM, Evgeni Burovski > wrote: > > Hi, > > >> >> Let's follow NumPy's timeline [1], which says that from 1 Jan 2019 >> onwards new releases will be Python 3 only, and the last release before >> that date will be an LTS release. That means SciPy 1.2.0 will be the LTS >> release, and 1.3.0 will be >= py3.5. >> > > +1 > > We should also think a bit about the timeline for cleanups and removals of > py2/py3 workarounds. > Maybe it's useful to postpone large-scale cleanups a bit. > For example, how about we state that we allow new code to be py3-only, but > we do not remove existing py2 constructs puntil scipy 1.14? Or for the > duration of the LTS support. > > > > Also, we haven't changed the minimum numpy version we support in quite a >> while, we're still at 1.8.2. And that will have to change anyway after >> dropping Python 2.7. The current minimum numpy versions we require are: >> - py27: 1.8.2 >> - py35: 1.9.3 >> - py36: 1.12.1 >> - py37: 1.13.1 >> We have always aimed to support at least 4 numpy versions (i.e. 2 year >> old versions). The differences per Python version in minimum numpy version >> are annoying (we don't consistently check that in our main __init__.py or >> in setup.py even), so I propose that for SciPy 1.3.0 we raise the minimum >> required NumPy version to 1.13.3. That'll still be 4 supported releases, >> 1.13.3-1.16.x. >> > > +1 in general. > > However numpy 1.13.0 has been released in July 2017, so it makes it less > then two full years. I don't have a firm opinion on what is the optimum > time from the last supported numpy version though. > > > Cheers, >> Ralf >> >> [1] http://www.numpy.org/neps/nep-0014-dropping-python2.7-proposal.html >> [2] NumPy thread on dropping py27: >> https://mail.python.org/pipermail/numpy-discussion/2017-November/077341.html >> >> _______________________________________________ >> SciPy-Dev mailing list >> SciPy-Dev at python.org >> https://mail.python.org/mailman/listinfo/scipy-dev >> > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at python.org > https://mail.python.org/mailman/listinfo/scipy-dev > > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at python.org > https://mail.python.org/mailman/listinfo/scipy-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From p.vanmulbregt at comcast.net Mon Nov 12 22:34:26 2018 From: p.vanmulbregt at comcast.net (Paul van Mulbregt) Date: Mon, 12 Nov 2018 22:34:26 -0500 Subject: [SciPy-Dev] dropping python 2.7 and numpy <1.13.3 In-Reply-To: References: <7AFCB2C5-1AF7-4118-BE52-5BDE97104553@comcast.net> Message-ID: <202A102A-02A1-47C4-A528-FB5E9A0E5C02@comcast.net> Just read the NumPy discussion thread. Some suggestions in that thread: 1. Bump the major version number after the LTS release. 2. Allow cleaning up of the code after the LTS release to take advantage of the newly allowed features. Counter suggestion: Don't clean up the code, in either the py3 codebase or the LTS release. That would make it easier to back-port PRs as needed. I didn?t see mention one way or the other in https://github.com/numpy/numpy/blob/master/doc/neps/dropping-python2.7-proposal.rst Did NumPy come to a decision on these? SciPy doesn't appear to be a signatory to http://www.python3statement.org/ Should it be? -Paul > On Nov 11, 2018, at 2:51 PM, Ralf Gommers wrote: > > > > On Sun, Nov 11, 2018 at 10:28 AM Paul van Mulbregt > wrote: > Py 2.7 means more than just "Python2.7". We have tool chains for the various versions of Python, with (perhaps hidden) dependencies. In particular, I?m thinking of Python2.7 on Windows, which is built with MSVisualC++ v9. Since MSVC9 isn?t fully C99 compliant, SciPy has had to forgo many features of C99 to stay compatible, let alone C11 or C18. > > Yes, a more recent MSVC is an important benefit. We'll still have to deal with more minor non-C99-compliance on mor exotic platforms (AIX, Solaris, etc.) but that's less of a problem. > > > Perhaps now would be a good time to list our dependencies explicitly and think about the toolchain roadmap in general? > > There's: > - Cython: we always require a recent one, are about to bump to >0.28.5 or 0.29 > - NumPy: proposed >1.13.3 > - compilers: in general, whatever works for the Python versions we target. and we're accepting patches as needed for more exotic compilers supported by numpy.distutils(issue volume is very low). > - LAPACK: >=3.4.1 > - OpenBLAS: whichever recent version works (usually only 1-2 versions that are non-buggy enough). > - Sphinx + numpydoc: whatever recent versions work. >= 1.6.6 for Sphinx and 0.8.0 for numpydoc I believe. > - pytest/asv/wheel/multibuild: same, something recent. > > This is documented in various places, but usually not very complete or up-to-date unfortunately. Most of those dependencies are independent from each other. > > Cheers, > Ralf > > > BTW, Py3.5 and 3.6 are built with VisualC++ v14.0. See > https://wiki.python.org/moin/WindowsCompilers#Which_Microsoft_Visual_C.2B-.2B-_compiler_to_use_with_a_specific_Python_version_.3F > > -Paul > > >> On Nov 11, 2018, at 5:07 AM, Evgeni Burovski > wrote: >> >> Hi, >> >> >> >> Let's follow NumPy's timeline [1], which says that from 1 Jan 2019 onwards new releases will be Python 3 only, and the last release before that date will be an LTS release. That means SciPy 1.2.0 will be the LTS release, and 1.3.0 will be >= py3.5. >> >> +1 >> >> We should also think a bit about the timeline for cleanups and removals of py2/py3 workarounds. >> Maybe it's useful to postpone large-scale cleanups a bit. >> For example, how about we state that we allow new code to be py3-only, but we do not remove existing py2 constructs puntil scipy 1.14? Or for the duration of the LTS support. >> >> >> >> Also, we haven't changed the minimum numpy version we support in quite a while, we're still at 1.8.2. And that will have to change anyway after dropping Python 2.7. The current minimum numpy versions we require are: >> - py27: 1.8.2 >> - py35: 1.9.3 >> - py36: 1.12.1 >> - py37: 1.13.1 >> We have always aimed to support at least 4 numpy versions (i.e. 2 year old versions). The differences per Python version in minimum numpy version are annoying (we don't consistently check that in our main __init__.py or in setup.py even), so I propose that for SciPy 1.3.0 we raise the minimum required NumPy version to 1.13.3. That'll still be 4 supported releases, 1.13.3-1.16.x. >> >> +1 in general. >> >> However numpy 1.13.0 has been released in July 2017, so it makes it less then two full years. I don't have a firm opinion on what is the optimum time from the last supported numpy version though. >> >> >> Cheers, >> Ralf >> >> [1] http://www.numpy.org/neps/nep-0014-dropping-python2.7-proposal.html >> [2] NumPy thread on dropping py27: https://mail.python.org/pipermail/numpy-discussion/2017-November/077341.html >> >> _______________________________________________ >> SciPy-Dev mailing list >> SciPy-Dev at python.org >> https://mail.python.org/mailman/listinfo/scipy-dev >> _______________________________________________ >> SciPy-Dev mailing list >> SciPy-Dev at python.org >> https://mail.python.org/mailman/listinfo/scipy-dev > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at python.org > https://mail.python.org/mailman/listinfo/scipy-dev > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at python.org > https://mail.python.org/mailman/listinfo/scipy-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikofski at berkeley.edu Mon Nov 12 23:00:17 2018 From: mikofski at berkeley.edu (Mark Alexander Mikofski) Date: Mon, 12 Nov 2018 20:00:17 -0800 Subject: [SciPy-Dev] dropping python 2.7 and numpy <1.13.3 In-Reply-To: <202A102A-02A1-47C4-A528-FB5E9A0E5C02@comcast.net> References: <7AFCB2C5-1AF7-4118-BE52-5BDE97104553@comcast.net> <202A102A-02A1-47C4-A528-FB5E9A0E5C02@comcast.net> Message-ID: > SciPy doesn't appear to be a signatory to http://www.python3statement.org/ Should it be? IMO yes, instructions are here: https://github.com/python3statement/python3statement.github.io On Mon, Nov 12, 2018 at 7:40 PM Paul van Mulbregt wrote: > Just read the NumPy discussion thread. Some suggestions in that thread: > 1. Bump the major version number after the LTS release. > 2. Allow cleaning up of the code after the LTS release to take advantage > of the newly allowed features. > Counter suggestion: Don't clean up the code, in either the py3 codebase or > the LTS release. That would make it easier to back-port PRs as needed. > > I didn?t see mention one way or the other in > https://github.com/numpy/numpy/blob/master/doc/neps/dropping-python2.7-proposal.rst > Did NumPy come to a decision on these? > > SciPy doesn't appear to be a signatory to http://www.python3statement.org/ > Should it be? > > -Paul > > > On Nov 11, 2018, at 2:51 PM, Ralf Gommers wrote: > > > > On Sun, Nov 11, 2018 at 10:28 AM Paul van Mulbregt < > p.vanmulbregt at comcast.net> wrote: > >> Py 2.7 means more than just "Python2.7". We have tool chains for the >> various versions of Python, with (perhaps hidden) dependencies. In >> particular, I?m thinking of Python2.7 on Windows, which is built with >> MSVisualC++ v9. Since MSVC9 isn?t fully C99 compliant, SciPy has had to >> forgo many features of C99 to stay compatible, let alone C11 or C18. >> > > Yes, a more recent MSVC is an important benefit. We'll still have to deal > with more minor non-C99-compliance on mor exotic platforms (AIX, Solaris, > etc.) but that's less of a problem. > > >> Perhaps now would be a good time to list our dependencies explicitly and >> think about the toolchain roadmap in general? >> > > There's: > - Cython: we always require a recent one, are about to bump to >0.28.5 or > 0.29 > - NumPy: proposed >1.13.3 > - compilers: in general, whatever works for the Python versions we target. > and we're accepting patches as needed for more exotic compilers supported > by numpy.distutils(issue volume is very low). > - LAPACK: >=3.4.1 > - OpenBLAS: whichever recent version works (usually only 1-2 versions that > are non-buggy enough). > - Sphinx + numpydoc: whatever recent versions work. >= 1.6.6 for Sphinx > and 0.8.0 for numpydoc I believe. > - pytest/asv/wheel/multibuild: same, something recent. > > This is documented in various places, but usually not very complete or > up-to-date unfortunately. Most of those dependencies are independent from > each other. > > Cheers, > Ralf > > >> >> BTW, Py3.5 and 3.6 are built with VisualC++ v14.0. See >> >> https://wiki.python.org/moin/WindowsCompilers#Which_Microsoft_Visual_C.2B-.2B-_compiler_to_use_with_a_specific_Python_version_.3F >> >> -Paul >> >> >> On Nov 11, 2018, at 5:07 AM, Evgeni Burovski >> wrote: >> >> Hi, >> >> >>> >>> Let's follow NumPy's timeline [1], which says that from 1 Jan 2019 >>> onwards new releases will be Python 3 only, and the last release before >>> that date will be an LTS release. That means SciPy 1.2.0 will be the LTS >>> release, and 1.3.0 will be >= py3.5. >>> >> >> +1 >> >> We should also think a bit about the timeline for cleanups and removals >> of py2/py3 workarounds. >> Maybe it's useful to postpone large-scale cleanups a bit. >> For example, how about we state that we allow new code to be py3-only, >> but we do not remove existing py2 constructs puntil scipy 1.14? Or for the >> duration of the LTS support. >> >> >> >> Also, we haven't changed the minimum numpy version we support in quite a >>> while, we're still at 1.8.2. And that will have to change anyway after >>> dropping Python 2.7. The current minimum numpy versions we require are: >>> - py27: 1.8.2 >>> - py35: 1.9.3 >>> - py36: 1.12.1 >>> - py37: 1.13.1 >>> We have always aimed to support at least 4 numpy versions (i.e. 2 year >>> old versions). The differences per Python version in minimum numpy version >>> are annoying (we don't consistently check that in our main __init__.py or >>> in setup.py even), so I propose that for SciPy 1.3.0 we raise the minimum >>> required NumPy version to 1.13.3. That'll still be 4 supported releases, >>> 1.13.3-1.16.x. >>> >> >> +1 in general. >> >> However numpy 1.13.0 has been released in July 2017, so it makes it less >> then two full years. I don't have a firm opinion on what is the optimum >> time from the last supported numpy version though. >> >> >> Cheers, >>> Ralf >>> >>> [1] http://www.numpy.org/neps/nep-0014-dropping-python2.7-proposal.html >>> [2] NumPy thread on dropping py27: >>> https://mail.python.org/pipermail/numpy-discussion/2017-November/077341.html >>> >>> _______________________________________________ >>> SciPy-Dev mailing list >>> SciPy-Dev at python.org >>> https://mail.python.org/mailman/listinfo/scipy-dev >>> >> _______________________________________________ >> SciPy-Dev mailing list >> SciPy-Dev at python.org >> https://mail.python.org/mailman/listinfo/scipy-dev >> >> >> _______________________________________________ >> SciPy-Dev mailing list >> SciPy-Dev at python.org >> https://mail.python.org/mailman/listinfo/scipy-dev >> > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at python.org > https://mail.python.org/mailman/listinfo/scipy-dev > > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at python.org > https://mail.python.org/mailman/listinfo/scipy-dev > -- Mark Mikofski, PhD (2005) *Fiat Lux* -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefanv at berkeley.edu Tue Nov 13 02:20:27 2018 From: stefanv at berkeley.edu (Stefan van der Walt) Date: Mon, 12 Nov 2018 23:20:27 -0800 Subject: [SciPy-Dev] dropping python 2.7 and numpy <1.13.3 In-Reply-To: References: Message-ID: <20181113072027.4grl5kbws2yafcht@carbo> On Sat, 10 Nov 2018 19:22:33 -0800, Ralf Gommers wrote: > I've always had in mind that SciPy would follow NumPy in its timeline for > dropping Python 2.7. However, as far as I can tell we've never had the > discussion on this list. So here's the proposal: > Let's follow NumPy's timeline [1], which says that from 1 Jan 2019 onwards > new releases will be Python 3 only, and the last release before that date > will be an LTS release. That means SciPy 1.2.0 will be the LTS release, and > 1.3.0 will be >= py3.5. scikit-image made the same move at the end of May, and the only technical issue that arose was managing the large number of backports. For that, Matthias Bussonier's MeeSeeksDev bot has been invaluable (it automatically backports PRs on request, or by adding the issue to an appropriately tagged milestone). > setup.py even), so I propose that for SciPy 1.3.0 we raise the minimum > required NumPy version to 1.13.3. That'll still be 4 supported releases, > 1.13.3-1.16.x. +1; having per-Python-version NumPy dependencies is an unnecessary developer burden. St?fan From christoph.baumgarten at gmail.com Wed Nov 14 16:22:41 2018 From: christoph.baumgarten at gmail.com (Christoph Baumgarten) Date: Wed, 14 Nov 2018 22:22:41 +0100 Subject: [SciPy-Dev] Building From Source on Windows Message-ID: Hi, I tried to follow the instructions on https://github.com/scipy/scipy/blob/master/doc/source/building/windows.rst to build scipy on Windows. When trying to clone the repo https://github.com/matthew-brett/build-openblas.git, I noted that this repo has been moved: "This repository retired in favor of https://github.com/matthew-brett/openblas-libs" However, that link is broken. Should it be https://github.com/matthew-brett/OpenBLAS instead? If that is the case, I still don't know how to continue: The scipy guide says to start the build with ./build_openblas.sh whereas the readme in https://github.com/matthew-brett/OpenBLAS mentions the command "make" Am I looking at the right place? Maybe someone can help. Thanks Christoph -------------- next part -------------- An HTML attachment was scrubbed... URL: From tyler.je.reddy at gmail.com Wed Nov 14 16:34:47 2018 From: tyler.je.reddy at gmail.com (Tyler Reddy) Date: Wed, 14 Nov 2018 13:34:47 -0800 Subject: [SciPy-Dev] Building From Source on Windows In-Reply-To: References: Message-ID: Passing on / better documenting some of the some of the openblas-related build knowledge from Matthew Brett is also something that came out as a priority form the NumPy dev call / meeting today too. I've been struggling to deal with some doc inconsistencies / openblas issues for CI things lately as well. On Wed, 14 Nov 2018 at 13:23, Christoph Baumgarten < christoph.baumgarten at gmail.com> wrote: > > Hi, > > I tried to follow the instructions on > > https://github.com/scipy/scipy/blob/master/doc/source/building/windows.rst > > to build scipy on Windows. > > When trying to clone the repo > https://github.com/matthew-brett/build-openblas.git, > I noted that this repo has been moved: > > "This repository retired in favor of > https://github.com/matthew-brett/openblas-libs" > > However, that link is broken. Should it be > https://github.com/matthew-brett/OpenBLAS instead? > > If that is the case, I still don't know how to continue: > > The scipy guide says to start the build with ./build_openblas.sh whereas > the readme in https://github.com/matthew-brett/OpenBLAS mentions the > command "make" > > Am I looking at the right place? Maybe someone can help. > > Thanks > > Christoph > > > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at python.org > https://mail.python.org/mailman/listinfo/scipy-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.gommers at gmail.com Wed Nov 14 23:45:51 2018 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Wed, 14 Nov 2018 20:45:51 -0800 Subject: [SciPy-Dev] Building From Source on Windows In-Reply-To: References: Message-ID: On Wed, Nov 14, 2018 at 1:35 PM Tyler Reddy wrote: > Passing on / better documenting some of the some of the openblas-related > build knowledge from Matthew Brett is also something that came out as a > priority form the NumPy dev call / meeting today too. > > I've been struggling to deal with some doc inconsistencies / openblas > issues for CI things lately as well. > > On Wed, 14 Nov 2018 at 13:23, Christoph Baumgarten < > christoph.baumgarten at gmail.com> wrote: > >> >> Hi, >> >> I tried to follow the instructions on >> >> https://github.com/scipy/scipy/blob/master/doc/source/building/windows.rst >> >> to build scipy on Windows. >> > This is a never-ending pain unfortunately. >> When trying to clone the repo >> https://github.com/matthew-brett/build-openblas.git, >> I noted that this repo has been moved: >> >> "This repository retired in favor of >> https://github.com/matthew-brett/openblas-libs" >> >> However, that link is broken. Should it be >> https://github.com/matthew-brett/OpenBLAS instead? >> > I strongly suspect it's https://github.com/MacPython/openblas-libs. If you just want to get OpenBLAS to work right now, I suggest to grab it from the exact same place as we do for building our release wheels, see the link at https://github.com/MacPython/scipy-wheels/blob/master/appveyor.yml#L16 >> If that is the case, I still don't know how to continue: >> >> The scipy guide says to start the build with ./build_openblas.sh whereas >> the readme in https://github.com/matthew-brett/OpenBLAS mentions the >> command "make" >> >> Am I looking at the right place? Maybe someone can help. >> > There's basically two options: 1. If you have access to an Intel Fortran (ifort) compiler. Then use MSVC + ifort or icc + ifort. Will work out of the box with the current numpy.distutils and a `python setup.py install`. 2. If you don't have ifort, then the only option is MSVC + gfortran. This requires a bit of hackery, and a numpy.distutils patch. Following appveyor.yml from https://github.com/MacPython/scipy-wheels is the way to get that to work (not fun, sorry). The doc page you linked above is an outdated version of what happens at https://github.com/MacPython/scipy-wheels. Cheers, Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.gommers at gmail.com Wed Nov 14 23:48:36 2018 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Wed, 14 Nov 2018 20:48:36 -0800 Subject: [SciPy-Dev] dropping python 2.7 and numpy <1.13.3 In-Reply-To: <20181113072027.4grl5kbws2yafcht@carbo> References: <20181113072027.4grl5kbws2yafcht@carbo> Message-ID: On Mon, Nov 12, 2018 at 11:20 PM Stefan van der Walt wrote: > On Sat, 10 Nov 2018 19:22:33 -0800, Ralf Gommers wrote: > > I've always had in mind that SciPy would follow NumPy in its timeline for > > dropping Python 2.7. However, as far as I can tell we've never had the > > discussion on this list. So here's the proposal: > > Let's follow NumPy's timeline [1], which says that from 1 Jan 2019 > onwards > > new releases will be Python 3 only, and the last release before that date > > will be an LTS release. That means SciPy 1.2.0 will be the LTS release, > and > > 1.3.0 will be >= py3.5. > > scikit-image made the same move at the end of May, and the only > technical issue that arose was managing the large number of backports. > Thanks Stefan, good to know. For that, Matthias Bussonier's MeeSeeksDev bot has been invaluable (it > automatically backports PRs on request, or by adding the issue to an > appropriately tagged milestone). > I'd suggest to wait with installing that until it's really clear we need it. So far, we haven't had a bot that wasn't more trouble than it's worth I think. Cheers, Ralf > > setup.py even), so I propose that for SciPy 1.3.0 we raise the minimum > > required NumPy version to 1.13.3. That'll still be 4 supported releases, > > 1.13.3-1.16.x. > > +1; having per-Python-version NumPy dependencies is an unnecessary > developer burden. > > St?fan > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at python.org > https://mail.python.org/mailman/listinfo/scipy-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.gommers at gmail.com Wed Nov 14 23:52:32 2018 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Wed, 14 Nov 2018 20:52:32 -0800 Subject: [SciPy-Dev] dropping python 2.7 and numpy <1.13.3 In-Reply-To: References: <7AFCB2C5-1AF7-4118-BE52-5BDE97104553@comcast.net> <202A102A-02A1-47C4-A528-FB5E9A0E5C02@comcast.net> Message-ID: On Mon, Nov 12, 2018 at 8:00 PM Mark Alexander Mikofski < mikofski at berkeley.edu> wrote: > > SciPy doesn't appear to be a signatory to > http://www.python3statement.org/ Should it be? > > IMO yes, instructions are here: > https://github.com/python3statement/python3statement.github.io > Yes, if the proposal is accepted, then we should add ourselves there. It seems that the proposal is uncontroversial. I propose to accept it if no significant objections have been made in 3 days (so 1 week after the start of this thread). > On Mon, Nov 12, 2018 at 7:40 PM Paul van Mulbregt < > p.vanmulbregt at comcast.net> wrote: > >> Just read the NumPy discussion thread. Some suggestions in that thread: >> 1. Bump the major version number after the LTS release. >> 2. Allow cleaning up of the code after the LTS release to take advantage >> of the newly allowed features. >> Counter suggestion: Don't clean up the code, in either the py3 codebase >> or the LTS release. That would make it easier to back-port PRs as needed. >> > For now I'd suggest no cleanups - backports will be needed for a while. >> I didn?t see mention one way or the other in >> https://github.com/numpy/numpy/blob/master/doc/neps/dropping-python2.7-proposal.rst >> Did NumPy come to a decision on these? >> > No hard decision IIRC, but leaning towards no cleanups. Cheers, Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From tyler.je.reddy at gmail.com Fri Nov 16 13:34:42 2018 From: tyler.je.reddy at gmail.com (Tyler Reddy) Date: Fri, 16 Nov 2018 10:34:42 -0800 Subject: [SciPy-Dev] SciPy 1.2.0 release schedule In-Reply-To: References: Message-ID: Current delays / issues I'm working on--feel free to chime in on those: - a few test failures in wheel building matrix: https://github.com/MacPython/scipy-wheels/pull/37 - hard-to-understand putative patch for one of the failures: https://github.com/scipy/scipy/pull/9486 On Fri, 9 Nov 2018 at 08:40, Tyler Reddy wrote: > I branched 1.2.x around 8:30 am Pacific time on Nov. 9, 2018. > > Working on the follow up master branch PR to bump version number / notes > file, etc. now. > > On Thu, 8 Nov 2018 at 22:49, Tyler Reddy wrote: > >> Release note PR is hopefully taking shape now -- I'll allow (another) >> delay for the branch until tomorrow (morning?) for some (hopefully final) >> checks on that. >> >> On Thu, 8 Nov 2018 at 14:35, Tyler Reddy >> wrote: >> >>> There are 0 remaining PRs with a 1.2.0 milestone. >>> >>> There is one issue left with a 1.2.0 milestone: >>> https://github.com/scipy/scipy/issues/9441 >>> >>> Please do take a look over the release notes WIP PR based on the wiki: >>> https://github.com/scipy/scipy/pull/9461 >>> >>> Target is to branch in 5-6 hours or so. Let me know if you see any >>> issues of course -- Ralf has been coaching >>> me through pretty well so far I think. >>> >>> On Wed, 7 Nov 2018 at 09:52, Ilhan Polat wrote: >>> >>>> Hang in there Tyler :) >>>> >>>> Awesome job so far. >>>> >>>> >>>> On Wed, Nov 7, 2018, 06:08 Ralf Gommers wrote: >>>> >>>>> >>>>> >>>>> On Tue, Nov 6, 2018 at 9:03 PM Tyler Reddy >>>>> wrote: >>>>> >>>>>> 7 PRs : >>>>>> https://github.com/scipy/scipy/pulls?q=is%3Aopen+is%3Apr+milestone%3A1.2.0 >>>>>> 3 issues: >>>>>> https://github.com/scipy/scipy/issues?q=is%3Aopen+is%3Aissue+milestone%3A1.2.0 >>>>>> >>>>> >>>>> Awesome, getting there:) >>>>> >>>>> >>>>>> Target: branch sometime on November 8th >>>>>> >>>>>> On Mon, 5 Nov 2018 at 05:42, Tyler Reddy >>>>>> wrote: >>>>>> >>>>>>> Alright, I'll extend to Thursday Nov. 8th & see if I can reduce that >>>>>>> list a bit >>>>>>> >>>>>>> On Sun, 4 Nov 2018 at 22:27, Ralf Gommers >>>>>>> wrote: >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Fri, Oct 26, 2018 at 7:03 PM Mark Alexander Mikofski < >>>>>>>> mikofski at berkeley.edu> wrote: >>>>>>>> >>>>>>>>> Hi Tyler and others, >>>>>>>>> >>>>>>>>> Thanks for managing the v1.2 release. >>>>>>>>> >>>>>>>>> I think PR #8431, Cython optimize zeros API, is ready, hopefully, >>>>>>>>> to merge. It's been through several rounds of reviews and I think I've >>>>>>>>> accommodated all of the recommendations, all tests are passing, and there's >>>>>>>>> been strong support. Anyone please take a look. >>>>>>>>> >>>>>>>>> https://github.com/scipy/scipy/pull/8431 >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Mark >>>>>>>>> >>>>>>>>> On Fri, Oct 26, 2018, 2:38 PM Ralf Gommers >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Thu, Oct 25, 2018 at 12:55 PM Tyler Reddy < >>>>>>>>>> tyler.je.reddy at gmail.com> wrote: >>>>>>>>>> >>>>>>>>>>> Hi all, >>>>>>>>>>> >>>>>>>>>>> It is almost 6 months after the 1.1.0 release on May 5, so >>>>>>>>>>> probably time to plan the 1.2.0 release. It would be a good idea to look >>>>>>>>>>> over the PRs with a 1.2.0 milestone >>>>>>>>>>> , >>>>>>>>>>> and tag anything else that should have this milestone appropriately. >>>>>>>>>>> >>>>>>>>>>> I'd like to propose the following schedule: >>>>>>>>>>> >>>>>>>>>>> Nov. 5: branch 1.2.x >>>>>>>>>>> Nov. 8: rc1 >>>>>>>>>>> Nov. 21: rc2 (if needed) >>>>>>>>>>> Nov. 30: final release >>>>>>>>>>> >>>>>>>>>>> Thoughts? >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> This looks like a good schedule to me. We'll probably struggle to >>>>>>>>>> get some PRs marked for 1.2.0 merged, but that's always the case. >>>>>>>>>> >>>>>>>>> >>>>>>>> Hi Tyler, could we shift the branch date by 2-3 days (or up to a >>>>>>>> week)? There's a couple of PRs that I'd really like to see merged or >>>>>>>> decided on (for optimize and stats mainly), and there's right now still 18 >>>>>>>> open PRs marked for 1.2.0. >>>>>>>> >>>>>>>> A note on the open PRs: what we want to aim for is to have the list >>>>>>>> of open PRs and open blocking issues at zero, and have at most some >>>>>>>> non-blocking issues under the milestone left. Normally the release manager >>>>>>>> starts making those decisions, or pinging people, if other reviewers >>>>>>>> haven't done so in time. Of course it would be ideal if everyone has >>>>>>>> another look at >>>>>>>> https://github.com/scipy/scipy/pulls?q=is%3Aopen+is%3Apr+milestone%3A1.2.0 >>>>>>>> and bumps or finished off PRs he/she is involved in. >>>>>>>> >>>>>>>> Cheers, >>>>>>>> Ralf >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> SciPy-Dev mailing list >>>>>>>> SciPy-Dev at python.org >>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev >>>>>>>> >>>>>>> _______________________________________________ >>>>>> SciPy-Dev mailing list >>>>>> SciPy-Dev at python.org >>>>>> https://mail.python.org/mailman/listinfo/scipy-dev >>>>>> >>>>> _______________________________________________ >>>>> SciPy-Dev mailing list >>>>> SciPy-Dev at python.org >>>>> https://mail.python.org/mailman/listinfo/scipy-dev >>>>> >>>> _______________________________________________ >>>> SciPy-Dev mailing list >>>> SciPy-Dev at python.org >>>> https://mail.python.org/mailman/listinfo/scipy-dev >>>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From ilhanpolat at gmail.com Sat Nov 17 13:26:34 2018 From: ilhanpolat at gmail.com (Ilhan Polat) Date: Sat, 17 Nov 2018 19:26:34 +0100 Subject: [SciPy-Dev] SciPy 1.2.0 release schedule In-Reply-To: References: Message-ID: Good stuff Tyler. I have to also add to that list the recent pypy3 run failures appearing sporadically (though consistent on my PRs). I am trying triangulate the cause but probably will have to wait until at least tomorrow. Feedback is more than welcome. They seem to be related to cython/numpy versions but one can never be sure. ?lhan On Fri, Nov 16, 2018, 19:35 Tyler Reddy wrote: > Current delays / issues I'm working on--feel free to chime in on those: > > - a few test failures in wheel building matrix: > https://github.com/MacPython/scipy-wheels/pull/37 > - hard-to-understand putative patch for one of the failures: > https://github.com/scipy/scipy/pull/9486 > > On Fri, 9 Nov 2018 at 08:40, Tyler Reddy wrote: > >> I branched 1.2.x around 8:30 am Pacific time on Nov. 9, 2018. >> >> Working on the follow up master branch PR to bump version number / notes >> file, etc. now. >> >> On Thu, 8 Nov 2018 at 22:49, Tyler Reddy >> wrote: >> >>> Release note PR is hopefully taking shape now -- I'll allow (another) >>> delay for the branch until tomorrow (morning?) for some (hopefully final) >>> checks on that. >>> >>> On Thu, 8 Nov 2018 at 14:35, Tyler Reddy >>> wrote: >>> >>>> There are 0 remaining PRs with a 1.2.0 milestone. >>>> >>>> There is one issue left with a 1.2.0 milestone: >>>> https://github.com/scipy/scipy/issues/9441 >>>> >>>> Please do take a look over the release notes WIP PR based on the wiki: >>>> https://github.com/scipy/scipy/pull/9461 >>>> >>>> Target is to branch in 5-6 hours or so. Let me know if you see any >>>> issues of course -- Ralf has been coaching >>>> me through pretty well so far I think. >>>> >>>> On Wed, 7 Nov 2018 at 09:52, Ilhan Polat wrote: >>>> >>>>> Hang in there Tyler :) >>>>> >>>>> Awesome job so far. >>>>> >>>>> >>>>> On Wed, Nov 7, 2018, 06:08 Ralf Gommers >>>>> wrote: >>>>> >>>>>> >>>>>> >>>>>> On Tue, Nov 6, 2018 at 9:03 PM Tyler Reddy >>>>>> wrote: >>>>>> >>>>>>> 7 PRs : >>>>>>> https://github.com/scipy/scipy/pulls?q=is%3Aopen+is%3Apr+milestone%3A1.2.0 >>>>>>> 3 issues: >>>>>>> https://github.com/scipy/scipy/issues?q=is%3Aopen+is%3Aissue+milestone%3A1.2.0 >>>>>>> >>>>>> >>>>>> Awesome, getting there:) >>>>>> >>>>>> >>>>>>> Target: branch sometime on November 8th >>>>>>> >>>>>>> On Mon, 5 Nov 2018 at 05:42, Tyler Reddy >>>>>>> wrote: >>>>>>> >>>>>>>> Alright, I'll extend to Thursday Nov. 8th & see if I can reduce >>>>>>>> that list a bit >>>>>>>> >>>>>>>> On Sun, 4 Nov 2018 at 22:27, Ralf Gommers >>>>>>>> wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Fri, Oct 26, 2018 at 7:03 PM Mark Alexander Mikofski < >>>>>>>>> mikofski at berkeley.edu> wrote: >>>>>>>>> >>>>>>>>>> Hi Tyler and others, >>>>>>>>>> >>>>>>>>>> Thanks for managing the v1.2 release. >>>>>>>>>> >>>>>>>>>> I think PR #8431, Cython optimize zeros API, is ready, hopefully, >>>>>>>>>> to merge. It's been through several rounds of reviews and I think I've >>>>>>>>>> accommodated all of the recommendations, all tests are passing, and there's >>>>>>>>>> been strong support. Anyone please take a look. >>>>>>>>>> >>>>>>>>>> https://github.com/scipy/scipy/pull/8431 >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Mark >>>>>>>>>> >>>>>>>>>> On Fri, Oct 26, 2018, 2:38 PM Ralf Gommers < >>>>>>>>>> ralf.gommers at gmail.com> wrote: >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Thu, Oct 25, 2018 at 12:55 PM Tyler Reddy < >>>>>>>>>>> tyler.je.reddy at gmail.com> wrote: >>>>>>>>>>> >>>>>>>>>>>> Hi all, >>>>>>>>>>>> >>>>>>>>>>>> It is almost 6 months after the 1.1.0 release on May 5, so >>>>>>>>>>>> probably time to plan the 1.2.0 release. It would be a good idea to look >>>>>>>>>>>> over the PRs with a 1.2.0 milestone >>>>>>>>>>>> , >>>>>>>>>>>> and tag anything else that should have this milestone appropriately. >>>>>>>>>>>> >>>>>>>>>>>> I'd like to propose the following schedule: >>>>>>>>>>>> >>>>>>>>>>>> Nov. 5: branch 1.2.x >>>>>>>>>>>> Nov. 8: rc1 >>>>>>>>>>>> Nov. 21: rc2 (if needed) >>>>>>>>>>>> Nov. 30: final release >>>>>>>>>>>> >>>>>>>>>>>> Thoughts? >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> This looks like a good schedule to me. We'll probably struggle >>>>>>>>>>> to get some PRs marked for 1.2.0 merged, but that's always the case. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> Hi Tyler, could we shift the branch date by 2-3 days (or up to a >>>>>>>>> week)? There's a couple of PRs that I'd really like to see merged or >>>>>>>>> decided on (for optimize and stats mainly), and there's right now still 18 >>>>>>>>> open PRs marked for 1.2.0. >>>>>>>>> >>>>>>>>> A note on the open PRs: what we want to aim for is to have the >>>>>>>>> list of open PRs and open blocking issues at zero, and have at most some >>>>>>>>> non-blocking issues under the milestone left. Normally the release manager >>>>>>>>> starts making those decisions, or pinging people, if other reviewers >>>>>>>>> haven't done so in time. Of course it would be ideal if everyone has >>>>>>>>> another look at >>>>>>>>> https://github.com/scipy/scipy/pulls?q=is%3Aopen+is%3Apr+milestone%3A1.2.0 >>>>>>>>> and bumps or finished off PRs he/she is involved in. >>>>>>>>> >>>>>>>>> Cheers, >>>>>>>>> Ralf >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> SciPy-Dev mailing list >>>>>>>>> SciPy-Dev at python.org >>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev >>>>>>>>> >>>>>>>> _______________________________________________ >>>>>>> SciPy-Dev mailing list >>>>>>> SciPy-Dev at python.org >>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev >>>>>>> >>>>>> _______________________________________________ >>>>>> SciPy-Dev mailing list >>>>>> SciPy-Dev at python.org >>>>>> https://mail.python.org/mailman/listinfo/scipy-dev >>>>>> >>>>> _______________________________________________ >>>>> SciPy-Dev mailing list >>>>> SciPy-Dev at python.org >>>>> https://mail.python.org/mailman/listinfo/scipy-dev >>>>> >>>> _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at python.org > https://mail.python.org/mailman/listinfo/scipy-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ssouravsingh12 at gmail.com Mon Nov 19 08:45:38 2018 From: ssouravsingh12 at gmail.com (Sourav Singh) Date: Mon, 19 Nov 2018 19:15:38 +0530 Subject: [SciPy-Dev] Preparing project proposal for GSoC 2019 Message-ID: Hello, I am writing the mail regarding project proposal for GSoC 2019. I am interested in working with SciPy for the upcoming Google Summer of Code and I am interested in either working on enhancing the randomized numerical linear algebra functionality or fixing the scipy.fftpack module. I understand that it is quite early to talk, since the organization proposals haven't started yet, but I would like to know if a project proposal can be started right now so that the proposals can be better fleshed out by the time the application period starts? Regards, Sourav -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.gommers at gmail.com Mon Nov 19 13:32:43 2018 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Mon, 19 Nov 2018 10:32:43 -0800 Subject: [SciPy-Dev] dropping python 2.7 and numpy <1.13.3 In-Reply-To: References: <7AFCB2C5-1AF7-4118-BE52-5BDE97104553@comcast.net> <202A102A-02A1-47C4-A528-FB5E9A0E5C02@comcast.net> Message-ID: On Wed, Nov 14, 2018 at 8:52 PM Ralf Gommers wrote: > > > On Mon, Nov 12, 2018 at 8:00 PM Mark Alexander Mikofski < > mikofski at berkeley.edu> wrote: > >> > SciPy doesn't appear to be a signatory to >> http://www.python3statement.org/ Should it be? >> >> IMO yes, instructions are here: >> https://github.com/python3statement/python3statement.github.io >> > > Yes, if the proposal is accepted, then we should add ourselves there. > > It seems that the proposal is uncontroversial. I propose to accept it if > no significant objections have been made in 3 days (so 1 week after the > start of this thread). > Okay, looks like we agree on this! I'll send a doc PR for the release notes, as well as a PR to python3statement. Cheers, Ralf > >> On Mon, Nov 12, 2018 at 7:40 PM Paul van Mulbregt < >> p.vanmulbregt at comcast.net> wrote: >> >>> Just read the NumPy discussion thread. Some suggestions in that thread: >>> 1. Bump the major version number after the LTS release. >>> 2. Allow cleaning up of the code after the LTS release to take advantage >>> of the newly allowed features. >>> Counter suggestion: Don't clean up the code, in either the py3 codebase >>> or the LTS release. That would make it easier to back-port PRs as needed. >>> >> > For now I'd suggest no cleanups - backports will be needed for a while. > > >>> I didn?t see mention one way or the other in >>> https://github.com/numpy/numpy/blob/master/doc/neps/dropping-python2.7-proposal.rst >>> Did NumPy come to a decision on these? >>> >> > No hard decision IIRC, but leaning towards no cleanups. > > Cheers, > Ralf > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.gommers at gmail.com Tue Nov 20 02:40:16 2018 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Mon, 19 Nov 2018 23:40:16 -0800 Subject: [SciPy-Dev] heads up - removed deprecated functions for 1.3.0 Message-ID: Hi all, Just a heads up that in master we removed many deprecated functions just now (in https://github.com/scipy/scipy/pull/9325). The ones from scipy.interpolate not many people are going to care about, however the image-related functions from scipy.misc used to be popular (they've been deprecated for a while though). In particular misc.imread. The misc namespace is getting empty. If the new datasets package that Warren is working on lands, only 6 functions left.... Cheers, Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From pav at iki.fi Tue Nov 20 15:39:30 2018 From: pav at iki.fi (Pauli Virtanen) Date: Tue, 20 Nov 2018 21:39:30 +0100 Subject: [SciPy-Dev] dropping python 2.7 and numpy <1.13.3 In-Reply-To: References: Message-ID: <8d703632a62095260114abc9b0eab515e084aa4e.camel@iki.fi> Hi, la, 2018-11-10 kello 19:22 -0800, Ralf Gommers kirjoitti: > I've always had in mind that SciPy would follow NumPy in its timeline > for dropping Python 2.7. However, as far as I can tell we've never > had the discussion on this list. So here's the proposal: > Let's follow NumPy's timeline [1], which says that from 1 Jan 2019 > onwards new releases will be Python 3 only, and the last release > before that date will be an LTS release. That means SciPy 1.2.0 will > be the LTS release, and 1.3.0 will be >= py3.5. Following Numpy on the Py3 plan sounds good to me. On the cleaning up thing, it may indeed be best to avoid unnecessarily removing the Py2 workarounds, as the more the LTS branch diverges, the more work is required in backporting things to it. New code of course can follow Py3 only. > Also, we haven't changed the minimum numpy version we support in quite a > while, we're still at 1.8.2. And that will have to change anyway after > dropping Python 2.7. The current minimum numpy versions we require are: > - py27: 1.8.2 > - py35: 1.9.3 > - py36: 1.12.1 > - py37: 1.13.1 > We have always aimed to support at least 4 numpy versions (i.e. 2 year old > versions). The differences per Python version in minimum numpy version are > annoying (we don't consistently check that in our main __init__.py or in > setup.py even), so I propose that for SciPy 1.3.0 we raise the minimum > required NumPy version to 1.13.3. That'll still be 4 supported releases, > 1.13.3-1.16.x. That's probably fine, 1.13.3 is from 2017. Situations where you are able to upgrade Scipy but not Numpy are also somewhat rare, so this seems a low-risk decision. Pauli From tyler.je.reddy at gmail.com Wed Nov 21 12:32:27 2018 From: tyler.je.reddy at gmail.com (Tyler Reddy) Date: Wed, 21 Nov 2018 09:32:27 -0800 Subject: [SciPy-Dev] SciPy 1.2.0 release schedule In-Reply-To: References: Message-ID: I've pushed the v1.2.x wheels branch -- initially this will aim to confirm that SciPy master branch is now passing the Travis & Appveyor wheel builds. If that is the case, I will proceed with the 3 connected backport PRs to the maintenance branch. Then, I will point the v.1.2.x wheels branch to an appropriate commit on the patched maintenance branch for release candidate wheel builds. On Sat, 17 Nov 2018 at 10:27, Ilhan Polat wrote: > Good stuff Tyler. I have to also add to that list the recent pypy3 run > failures appearing sporadically (though consistent on my PRs). > > I am trying triangulate the cause but probably will have to wait until at > least tomorrow. Feedback is more than welcome. They seem to be related to > cython/numpy versions but one can never be sure. > > ?lhan > > > On Fri, Nov 16, 2018, 19:35 Tyler Reddy wrote: > >> Current delays / issues I'm working on--feel free to chime in on those: >> >> - a few test failures in wheel building matrix: >> https://github.com/MacPython/scipy-wheels/pull/37 >> - hard-to-understand putative patch for one of the failures: >> https://github.com/scipy/scipy/pull/9486 >> >> On Fri, 9 Nov 2018 at 08:40, Tyler Reddy >> wrote: >> >>> I branched 1.2.x around 8:30 am Pacific time on Nov. 9, 2018. >>> >>> Working on the follow up master branch PR to bump version number / notes >>> file, etc. now. >>> >>> On Thu, 8 Nov 2018 at 22:49, Tyler Reddy >>> wrote: >>> >>>> Release note PR is hopefully taking shape now -- I'll allow (another) >>>> delay for the branch until tomorrow (morning?) for some (hopefully final) >>>> checks on that. >>>> >>>> On Thu, 8 Nov 2018 at 14:35, Tyler Reddy >>>> wrote: >>>> >>>>> There are 0 remaining PRs with a 1.2.0 milestone. >>>>> >>>>> There is one issue left with a 1.2.0 milestone: >>>>> https://github.com/scipy/scipy/issues/9441 >>>>> >>>>> Please do take a look over the release notes WIP PR based on the wiki: >>>>> https://github.com/scipy/scipy/pull/9461 >>>>> >>>>> Target is to branch in 5-6 hours or so. Let me know if you see any >>>>> issues of course -- Ralf has been coaching >>>>> me through pretty well so far I think. >>>>> >>>>> On Wed, 7 Nov 2018 at 09:52, Ilhan Polat wrote: >>>>> >>>>>> Hang in there Tyler :) >>>>>> >>>>>> Awesome job so far. >>>>>> >>>>>> >>>>>> On Wed, Nov 7, 2018, 06:08 Ralf Gommers >>>>>> wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On Tue, Nov 6, 2018 at 9:03 PM Tyler Reddy >>>>>>> wrote: >>>>>>> >>>>>>>> 7 PRs : >>>>>>>> https://github.com/scipy/scipy/pulls?q=is%3Aopen+is%3Apr+milestone%3A1.2.0 >>>>>>>> 3 issues: >>>>>>>> https://github.com/scipy/scipy/issues?q=is%3Aopen+is%3Aissue+milestone%3A1.2.0 >>>>>>>> >>>>>>> >>>>>>> Awesome, getting there:) >>>>>>> >>>>>>> >>>>>>>> Target: branch sometime on November 8th >>>>>>>> >>>>>>>> On Mon, 5 Nov 2018 at 05:42, Tyler Reddy >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Alright, I'll extend to Thursday Nov. 8th & see if I can reduce >>>>>>>>> that list a bit >>>>>>>>> >>>>>>>>> On Sun, 4 Nov 2018 at 22:27, Ralf Gommers >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Fri, Oct 26, 2018 at 7:03 PM Mark Alexander Mikofski < >>>>>>>>>> mikofski at berkeley.edu> wrote: >>>>>>>>>> >>>>>>>>>>> Hi Tyler and others, >>>>>>>>>>> >>>>>>>>>>> Thanks for managing the v1.2 release. >>>>>>>>>>> >>>>>>>>>>> I think PR #8431, Cython optimize zeros API, is ready, >>>>>>>>>>> hopefully, to merge. It's been through several rounds of reviews and I >>>>>>>>>>> think I've accommodated all of the recommendations, all tests are passing, >>>>>>>>>>> and there's been strong support. Anyone please take a look. >>>>>>>>>>> >>>>>>>>>>> https://github.com/scipy/scipy/pull/8431 >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Mark >>>>>>>>>>> >>>>>>>>>>> On Fri, Oct 26, 2018, 2:38 PM Ralf Gommers < >>>>>>>>>>> ralf.gommers at gmail.com> wrote: >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Thu, Oct 25, 2018 at 12:55 PM Tyler Reddy < >>>>>>>>>>>> tyler.je.reddy at gmail.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Hi all, >>>>>>>>>>>>> >>>>>>>>>>>>> It is almost 6 months after the 1.1.0 release on May 5, so >>>>>>>>>>>>> probably time to plan the 1.2.0 release. It would be a good idea to look >>>>>>>>>>>>> over the PRs with a 1.2.0 milestone >>>>>>>>>>>>> , >>>>>>>>>>>>> and tag anything else that should have this milestone appropriately. >>>>>>>>>>>>> >>>>>>>>>>>>> I'd like to propose the following schedule: >>>>>>>>>>>>> >>>>>>>>>>>>> Nov. 5: branch 1.2.x >>>>>>>>>>>>> Nov. 8: rc1 >>>>>>>>>>>>> Nov. 21: rc2 (if needed) >>>>>>>>>>>>> Nov. 30: final release >>>>>>>>>>>>> >>>>>>>>>>>>> Thoughts? >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> This looks like a good schedule to me. We'll probably struggle >>>>>>>>>>>> to get some PRs marked for 1.2.0 merged, but that's always the case. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> Hi Tyler, could we shift the branch date by 2-3 days (or up to a >>>>>>>>>> week)? There's a couple of PRs that I'd really like to see merged or >>>>>>>>>> decided on (for optimize and stats mainly), and there's right now still 18 >>>>>>>>>> open PRs marked for 1.2.0. >>>>>>>>>> >>>>>>>>>> A note on the open PRs: what we want to aim for is to have the >>>>>>>>>> list of open PRs and open blocking issues at zero, and have at most some >>>>>>>>>> non-blocking issues under the milestone left. Normally the release manager >>>>>>>>>> starts making those decisions, or pinging people, if other reviewers >>>>>>>>>> haven't done so in time. Of course it would be ideal if everyone has >>>>>>>>>> another look at >>>>>>>>>> https://github.com/scipy/scipy/pulls?q=is%3Aopen+is%3Apr+milestone%3A1.2.0 >>>>>>>>>> and bumps or finished off PRs he/she is involved in. >>>>>>>>>> >>>>>>>>>> Cheers, >>>>>>>>>> Ralf >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> SciPy-Dev mailing list >>>>>>>>>> SciPy-Dev at python.org >>>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev >>>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>> SciPy-Dev mailing list >>>>>>>> SciPy-Dev at python.org >>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> SciPy-Dev mailing list >>>>>>> SciPy-Dev at python.org >>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev >>>>>>> >>>>>> _______________________________________________ >>>>>> SciPy-Dev mailing list >>>>>> SciPy-Dev at python.org >>>>>> https://mail.python.org/mailman/listinfo/scipy-dev >>>>>> >>>>> _______________________________________________ >> SciPy-Dev mailing list >> SciPy-Dev at python.org >> https://mail.python.org/mailman/listinfo/scipy-dev >> > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at python.org > https://mail.python.org/mailman/listinfo/scipy-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.gommers at gmail.com Wed Nov 21 18:07:17 2018 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Wed, 21 Nov 2018 15:07:17 -0800 Subject: [SciPy-Dev] SciPy 1.2.0 release schedule In-Reply-To: References: Message-ID: On Wed, Nov 21, 2018 at 9:32 AM Tyler Reddy wrote: > I've pushed the v1.2.x wheels branch -- initially this will aim to confirm > that SciPy master branch is now passing the Travis & Appveyor wheel builds. > > If that is the case, I will proceed with the 3 connected backport PRs to > the maintenance branch. > > Then, I will point the v.1.2.x wheels branch to an appropriate commit on > the patched maintenance branch for release candidate wheel builds. > Sounds like a plan! Ralf > > On Sat, 17 Nov 2018 at 10:27, Ilhan Polat wrote: > >> Good stuff Tyler. I have to also add to that list the recent pypy3 run >> failures appearing sporadically (though consistent on my PRs). >> >> I am trying triangulate the cause but probably will have to wait until at >> least tomorrow. Feedback is more than welcome. They seem to be related to >> cython/numpy versions but one can never be sure. >> >> ?lhan >> >> >> On Fri, Nov 16, 2018, 19:35 Tyler Reddy wrote: >> >>> Current delays / issues I'm working on--feel free to chime in on those: >>> >>> - a few test failures in wheel building matrix: >>> https://github.com/MacPython/scipy-wheels/pull/37 >>> - hard-to-understand putative patch for one of the failures: >>> https://github.com/scipy/scipy/pull/9486 >>> >>> On Fri, 9 Nov 2018 at 08:40, Tyler Reddy >>> wrote: >>> >>>> I branched 1.2.x around 8:30 am Pacific time on Nov. 9, 2018. >>>> >>>> Working on the follow up master branch PR to bump version number / >>>> notes file, etc. now. >>>> >>>> On Thu, 8 Nov 2018 at 22:49, Tyler Reddy >>>> wrote: >>>> >>>>> Release note PR is hopefully taking shape now -- I'll allow (another) >>>>> delay for the branch until tomorrow (morning?) for some (hopefully final) >>>>> checks on that. >>>>> >>>>> On Thu, 8 Nov 2018 at 14:35, Tyler Reddy >>>>> wrote: >>>>> >>>>>> There are 0 remaining PRs with a 1.2.0 milestone. >>>>>> >>>>>> There is one issue left with a 1.2.0 milestone: >>>>>> https://github.com/scipy/scipy/issues/9441 >>>>>> >>>>>> Please do take a look over the release notes WIP PR based on the >>>>>> wiki: https://github.com/scipy/scipy/pull/9461 >>>>>> >>>>>> Target is to branch in 5-6 hours or so. Let me know if you see any >>>>>> issues of course -- Ralf has been coaching >>>>>> me through pretty well so far I think. >>>>>> >>>>>> On Wed, 7 Nov 2018 at 09:52, Ilhan Polat >>>>>> wrote: >>>>>> >>>>>>> Hang in there Tyler :) >>>>>>> >>>>>>> Awesome job so far. >>>>>>> >>>>>>> >>>>>>> On Wed, Nov 7, 2018, 06:08 Ralf Gommers >>>>>>> wrote: >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Tue, Nov 6, 2018 at 9:03 PM Tyler Reddy < >>>>>>>> tyler.je.reddy at gmail.com> wrote: >>>>>>>> >>>>>>>>> 7 PRs : >>>>>>>>> https://github.com/scipy/scipy/pulls?q=is%3Aopen+is%3Apr+milestone%3A1.2.0 >>>>>>>>> 3 issues: >>>>>>>>> https://github.com/scipy/scipy/issues?q=is%3Aopen+is%3Aissue+milestone%3A1.2.0 >>>>>>>>> >>>>>>>> >>>>>>>> Awesome, getting there:) >>>>>>>> >>>>>>>> >>>>>>>>> Target: branch sometime on November 8th >>>>>>>>> >>>>>>>>> On Mon, 5 Nov 2018 at 05:42, Tyler Reddy >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Alright, I'll extend to Thursday Nov. 8th & see if I can reduce >>>>>>>>>> that list a bit >>>>>>>>>> >>>>>>>>>> On Sun, 4 Nov 2018 at 22:27, Ralf Gommers >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Fri, Oct 26, 2018 at 7:03 PM Mark Alexander Mikofski < >>>>>>>>>>> mikofski at berkeley.edu> wrote: >>>>>>>>>>> >>>>>>>>>>>> Hi Tyler and others, >>>>>>>>>>>> >>>>>>>>>>>> Thanks for managing the v1.2 release. >>>>>>>>>>>> >>>>>>>>>>>> I think PR #8431, Cython optimize zeros API, is ready, >>>>>>>>>>>> hopefully, to merge. It's been through several rounds of reviews and I >>>>>>>>>>>> think I've accommodated all of the recommendations, all tests are passing, >>>>>>>>>>>> and there's been strong support. Anyone please take a look. >>>>>>>>>>>> >>>>>>>>>>>> https://github.com/scipy/scipy/pull/8431 >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Mark >>>>>>>>>>>> >>>>>>>>>>>> On Fri, Oct 26, 2018, 2:38 PM Ralf Gommers < >>>>>>>>>>>> ralf.gommers at gmail.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Thu, Oct 25, 2018 at 12:55 PM Tyler Reddy < >>>>>>>>>>>>> tyler.je.reddy at gmail.com> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Hi all, >>>>>>>>>>>>>> >>>>>>>>>>>>>> It is almost 6 months after the 1.1.0 release on May 5, so >>>>>>>>>>>>>> probably time to plan the 1.2.0 release. It would be a good idea to look >>>>>>>>>>>>>> over the PRs with a 1.2.0 milestone >>>>>>>>>>>>>> , >>>>>>>>>>>>>> and tag anything else that should have this milestone appropriately. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I'd like to propose the following schedule: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Nov. 5: branch 1.2.x >>>>>>>>>>>>>> Nov. 8: rc1 >>>>>>>>>>>>>> Nov. 21: rc2 (if needed) >>>>>>>>>>>>>> Nov. 30: final release >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thoughts? >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> This looks like a good schedule to me. We'll probably struggle >>>>>>>>>>>>> to get some PRs marked for 1.2.0 merged, but that's always the case. >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> Hi Tyler, could we shift the branch date by 2-3 days (or up to a >>>>>>>>>>> week)? There's a couple of PRs that I'd really like to see merged or >>>>>>>>>>> decided on (for optimize and stats mainly), and there's right now still 18 >>>>>>>>>>> open PRs marked for 1.2.0. >>>>>>>>>>> >>>>>>>>>>> A note on the open PRs: what we want to aim for is to have the >>>>>>>>>>> list of open PRs and open blocking issues at zero, and have at most some >>>>>>>>>>> non-blocking issues under the milestone left. Normally the release manager >>>>>>>>>>> starts making those decisions, or pinging people, if other reviewers >>>>>>>>>>> haven't done so in time. Of course it would be ideal if everyone has >>>>>>>>>>> another look at >>>>>>>>>>> https://github.com/scipy/scipy/pulls?q=is%3Aopen+is%3Apr+milestone%3A1.2.0 >>>>>>>>>>> and bumps or finished off PRs he/she is involved in. >>>>>>>>>>> >>>>>>>>>>> Cheers, >>>>>>>>>>> Ralf >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> SciPy-Dev mailing list >>>>>>>>>>> SciPy-Dev at python.org >>>>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev >>>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>> SciPy-Dev mailing list >>>>>>>>> SciPy-Dev at python.org >>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev >>>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> SciPy-Dev mailing list >>>>>>>> SciPy-Dev at python.org >>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> SciPy-Dev mailing list >>>>>>> SciPy-Dev at python.org >>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev >>>>>>> >>>>>> _______________________________________________ >>> SciPy-Dev mailing list >>> SciPy-Dev at python.org >>> https://mail.python.org/mailman/listinfo/scipy-dev >>> >> _______________________________________________ >> SciPy-Dev mailing list >> SciPy-Dev at python.org >> https://mail.python.org/mailman/listinfo/scipy-dev >> > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at python.org > https://mail.python.org/mailman/listinfo/scipy-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aronne.merrelli at gmail.com Wed Nov 21 18:18:50 2018 From: aronne.merrelli at gmail.com (Aronne Merrelli) Date: Wed, 21 Nov 2018 17:18:50 -0600 Subject: [SciPy-Dev] memory leak in LinearNDInterpolator? Message-ID: Hello, I am having a problem with the LinearNDInterpolator in SciPy, where it looks like there is a memory leak. I have a simple example here, all I do is setup a very small LinearNDInterpolator object and call the interpolator many times in a loop: https://gist.github.com/aronnem/707dfeec07b74888fb7390d828684184 Note that if the "pts_list" and "vals" are swapped with the integer versions, there is no leak. Using the floats seems to produce the leak. I have tried both conda and Canopy installed environments, they all seem to have the same behavior. For example, here is the output I get with a scipy 1.1.0 compiled with Cython 0.28.5, numpy 1.13.3 on Mac OS X: rss_used= 4 KB vms_used= 0 KB rss_used= 2516 KB vms_used= 2560 KB rss_used= 4836 KB vms_used= 5188 KB rss_used= 6880 KB vms_used= 6664 KB rss_used= 9408 KB vms_used= 10248 KB rss_used= 11680 KB vms_used= 12076 KB rss_used= 14356 KB vms_used= 15872 KB rss_used= 16736 KB vms_used= 17792 KB rss_used= 19416 KB vms_used= 20496 KB rss_used= 22100 KB vms_used= 23472 KB The only workaround I have found so far is to downgrade my numpy version to 1.11.3. So that seems to suggest it is a numpy problem; however this function is implemented in cython, so I am not sure how to tell whether this is a numpy, scipy, or cython problem. Regards, Aronne -------------- next part -------------- An HTML attachment was scrubbed... URL: From deak.andris at gmail.com Wed Nov 21 18:54:17 2018 From: deak.andris at gmail.com (Andras Deak) Date: Thu, 22 Nov 2018 00:54:17 +0100 Subject: [SciPy-Dev] memory leak in LinearNDInterpolator? In-Reply-To: References: Message-ID: On Thu, Nov 22, 2018 at 12:19 AM Aronne Merrelli wrote: > > Hello, > > I am having a problem with the LinearNDInterpolator in SciPy, where it looks like there is a memory leak. I have a simple example here, all I do is setup a very small LinearNDInterpolator object and call the interpolator many times in a loop: > > https://gist.github.com/aronnem/707dfeec07b74888fb7390d828684184 > > Note that if the "pts_list" and "vals" are swapped with the integer versions, there is no leak. Using the floats seems to produce the leak. I have tried both conda and Canopy installed environments, they all seem to have the same behavior. For example, here is the output I get with a scipy 1.1.0 compiled with Cython 0.28.5, numpy 1.13.3 on Mac OS X: I can reproduce what you see on scipy 1.1.0, cython 0.28.2, numpy 1.15.4 on debian. Also, the behaviour seems to depend on the type of `vals`; leaving `pts_list` as floats doesn't trigger the problem. Andr?s From lucamerio89 at gmail.com Fri Nov 23 14:54:49 2018 From: lucamerio89 at gmail.com (Luca) Date: Fri, 23 Nov 2018 19:54:49 +0000 Subject: [SciPy-Dev] Added functionality to find_peaks tool Message-ID: Hi everybody First of all, this is my first post here, so excuse me if I do anything wrong. I'm mostly a user of SciPy, but recently I needed few functionalities from find_peaks that I discovered weren't implemented. I therefore decided to implement them myself. I'm now wondering if they could be useful for everybody and not just for me. Unfortunately I almost never worked on big projects on Git, so I'm a bit struggling understanding how should I proceed. First of all. The changes I'm talking of are: - Allow to work with unevenly spaced samples specifying a abscissas array x. More specifically: - Filter peaks depending on their distance with not-uniformly spaced points - Evaluate width and width's intersection points correctly with not-uniformly spaced points - Allow the above-mentioned abscissas to be a np.datetime64 array. In this case the minimum distance between two objects can (must) be specified as a np.timedelta64 value and the width of the peaks is also returned as an array of np.timedelta64 values. - Allow the output peaks to be sorted, either ascending or descending, depending either on their height or their prominence. - Allow to specify a maximum number of peaks to be returned. The output would then depend on the sorting method one has chosen. I would therefore ask you: - do you think these changes could be considered useful for the community? - could someone help me in my first-time submission process? Thank you very much and please tell me if I'm doing anything wrong Best regards Luca Amerio Luca -------------- next part -------------- An HTML attachment was scrubbed... URL: From eryole at gmail.com Fri Nov 23 16:00:19 2018 From: eryole at gmail.com (Nicolas Cellier) Date: Fri, 23 Nov 2018 22:00:19 +0100 Subject: [SciPy-Dev] Added functionality to find_peaks tool In-Reply-To: References: Message-ID: <8145350d-621e-4b75-8e0b-1c07da776c4c@gmail.com> First two point seems interesting. Each of the next can be achieved in one line (with lexsort and fancy indexing) : it may be better to let that out of the function. I find these change interesting, but other opinion have to be considered. I can help you with the github workflow if you need so. Nicolas Cellier Post Doc Fellowship Universit? Savoie Mont-Blanc LAMA / LOCIE? Le 23 nov. 2018 ? 20:55, ? 20:55, Luca a ?crit: >Hi everybody > >First of all, this is my first post here, so excuse me if I do anything >wrong. > >I'm mostly a user of SciPy, but recently I needed few functionalities >from >find_peaks that I discovered weren't implemented. I therefore decided >to >implement them myself. >I'm now wondering if they could be useful for everybody and not just >for >me. Unfortunately I almost never worked on big projects on Git, so I'm >a >bit struggling understanding how should I proceed. > >First of all. The changes I'm talking of are: > > - Allow to work with unevenly spaced samples specifying a abscissas > array x. More specifically: > - Filter peaks depending on their distance with not-uniformly spaced > points > - Evaluate width and width's intersection points correctly with > not-uniformly spaced points > - Allow the above-mentioned abscissas to be a np.datetime64 array. In >this case the minimum distance between two objects can (must) be >specified >as a np.timedelta64 value and the width of the peaks is also returned >as an > array of np.timedelta64 values. > - Allow the output peaks to be sorted, either ascending or descending, > depending either on their height or their prominence. >- Allow to specify a maximum number of peaks to be returned. The output > would then depend on the sorting method one has chosen. > > >I would therefore ask you: > > - do you think these changes could be considered useful for the > community? > - could someone help me in my first-time submission process? > >Thank you very much and please tell me if I'm doing anything wrong > >Best regards >Luca Amerio >Luca > > >------------------------------------------------------------------------ > >_______________________________________________ >SciPy-Dev mailing list >SciPy-Dev at python.org >https://mail.python.org/mailman/listinfo/scipy-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From lagru at mailbox.org Fri Nov 23 18:48:33 2018 From: lagru at mailbox.org (=?UTF-8?Q?Lars_Gr=c3=bcter?=) Date: Sat, 24 Nov 2018 00:48:33 +0100 Subject: [SciPy-Dev] Added functionality to find_peaks tool In-Reply-To: <8145350d-621e-4b75-8e0b-1c07da776c4c@gmail.com> References: <8145350d-621e-4b75-8e0b-1c07da776c4c@gmail.com> Message-ID: An HTML attachment was scrubbed... URL: From ralf.gommers at gmail.com Sat Nov 24 14:19:27 2018 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Sat, 24 Nov 2018 11:19:27 -0800 Subject: [SciPy-Dev] memory leak in LinearNDInterpolator? In-Reply-To: References: Message-ID: On Wed, Nov 21, 2018 at 3:19 PM Aronne Merrelli wrote: > Hello, > > I am having a problem with the LinearNDInterpolator in SciPy, where it > looks like there is a memory leak. I have a simple example here, all I do > is setup a very small LinearNDInterpolator object and call the interpolator > many times in a loop: > > https://gist.github.com/aronnem/707dfeec07b74888fb7390d828684184 > > Note that if the "pts_list" and "vals" are swapped with the integer > versions, there is no leak. Using the floats seems to produce the leak. I > have tried both conda and Canopy installed environments, they all seem to > have the same behavior. For example, here is the output I get with a scipy > 1.1.0 compiled with Cython 0.28.5, numpy 1.13.3 on Mac OS X: > I can reproduce that as well with numpy 1.14.3, cython 0.29.0, scipy master. > rss_used= 4 KB vms_used= 0 KB > rss_used= 2516 KB vms_used= 2560 KB > rss_used= 4836 KB vms_used= 5188 KB > rss_used= 6880 KB vms_used= 6664 KB > rss_used= 9408 KB vms_used= 10248 KB > rss_used= 11680 KB vms_used= 12076 KB > rss_used= 14356 KB vms_used= 15872 KB > rss_used= 16736 KB vms_used= 17792 KB > rss_used= 19416 KB vms_used= 20496 KB > rss_used= 22100 KB vms_used= 23472 KB > > > The only workaround I have found so far is to downgrade my numpy version > to 1.11.3. So that seems to suggest it is a numpy problem; however this > function is implemented in cython, so I am not sure how to tell whether > this is a numpy, scipy, or cython problem. > It does look like a real memory leak, not the memory allocator holding on to allocations for longer than it has to. Given that numpy 1.11.3 didn't show this behavior, it would be helpful to use git bisect on the range numy v1.11.3-v1.13.3 to find when the numpy behavior changed. I just checked that v1.11.3 still builds with Cython 0.29.0, so I would suggest cython 0.29.0 and scipy master. Depending on your OS, you may need this small patch for older numpy: diff --git a/numpy/core/src/multiarray/numpyos.c b/numpy/core/src/multiarray/numpyos.c index 450ec40b6..ec1e5bc2c 100644 --- a/numpy/core/src/multiarray/numpyos.c +++ b/numpy/core/src/multiarray/numpyos.c @@ -15,7 +15,9 @@ #ifdef HAVE_STRTOLD_L #include -#include +#ifdef HAVE_XLOCALE_H + #include +#endif #endif Cheers, Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.gommers at gmail.com Sat Nov 24 14:26:58 2018 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Sat, 24 Nov 2018 11:26:58 -0800 Subject: [SciPy-Dev] Preparing project proposal for GSoC 2019 In-Reply-To: References: Message-ID: Hi Sourav, On Mon, Nov 19, 2018 at 5:47 AM Sourav Singh wrote: > Hello, > > I am writing the mail regarding project proposal for GSoC 2019. > > I am interested in working with SciPy for the upcoming Google Summer of > Code and I am interested in either working on enhancing the randomized > numerical linear algebra functionality or fixing the scipy.fftpack module. > > I understand that it is quite early to talk, since the organization > proposals haven't started yet, but I would like to know if a project > proposal can be started right now so that the proposals can be better > fleshed out by the time the application period starts? > That's the earliest start I've seen (which is a good thing)! I suspect that we'll have trouble finding a mentor for the randomized linear algebra, however fftpack could be a good topic. Have you seen https://github.com/numpy/numpy/pull/11888? I suspect that by the time GSoC starts, we'll have merged that into NumPy, and would like to take it over for SciPy. A related topic would be to add a backend system for fft implementations (pyfftw, mkl-fft) Cheers, Ralf > Regards, > > Sourav > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at python.org > https://mail.python.org/mailman/listinfo/scipy-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.gommers at gmail.com Sat Nov 24 17:49:11 2018 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Sat, 24 Nov 2018 14:49:11 -0800 Subject: [SciPy-Dev] Preparing project proposal for GSoC 2019 In-Reply-To: References: Message-ID: On Sat, Nov 24, 2018 at 11:26 AM Ralf Gommers wrote: > Hi Sourav, > > > On Mon, Nov 19, 2018 at 5:47 AM Sourav Singh > wrote: > >> Hello, >> >> I am writing the mail regarding project proposal for GSoC 2019. >> >> I am interested in working with SciPy for the upcoming Google Summer of >> Code and I am interested in either working on enhancing the randomized >> numerical linear algebra functionality or fixing the scipy.fftpack module. >> >> I understand that it is quite early to talk, since the organization >> proposals haven't started yet, but I would like to know if a project >> proposal can be started right now so that the proposals can be better >> fleshed out by the time the application period starts? >> > > That's the earliest start I've seen (which is a good thing)! > > I suspect that we'll have trouble finding a mentor for the randomized > linear algebra, however fftpack could be a good topic. Have you seen > https://github.com/numpy/numpy/pull/11888? I suspect that by the time > GSoC starts, we'll have merged that into NumPy, and would like to take it > over for SciPy. A related topic would be to add a backend system for fft > implementations (pyfftw, mkl-fft). > And a third topic would be to make the APIs of numpy.fft and scipy.fftpack agree. That would be the lowest on my list because it's hard (requiring lots of discussion on impact on users if we deprecate things etc.), but it's an important one as well. Ralf > Cheers, > Ralf > > > >> Regards, >> >> Sourav >> _______________________________________________ >> SciPy-Dev mailing list >> SciPy-Dev at python.org >> https://mail.python.org/mailman/listinfo/scipy-dev >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ssouravsingh12 at gmail.com Sun Nov 25 08:20:24 2018 From: ssouravsingh12 at gmail.com (Sourav Singh) Date: Sun, 25 Nov 2018 18:50:24 +0530 Subject: [SciPy-Dev] Preparing project proposal for GSoC 2019 In-Reply-To: References: Message-ID: Hello, > > On Sat, Nov 24, 2018 at 11:26 AM Ralf Gommers > wrote: > >> Hi Sourav, >> >> >> On Mon, Nov 19, 2018 at 5:47 AM Sourav Singh >> wrote: >> >>> Hello, >>> >>> I am writing the mail regarding project proposal for GSoC 2019. >>> >>> I am interested in working with SciPy for the upcoming Google Summer of >>> Code and I am interested in either working on enhancing the randomized >>> numerical linear algebra functionality or fixing the scipy.fftpack module. >>> >>> I understand that it is quite early to talk, since the organization >>> proposals haven't started yet, but I would like to know if a project >>> proposal can be started right now so that the proposals can be better >>> fleshed out by the time the application period starts? >>> >> >> That's the earliest start I've seen (which is a good thing)! >> >> I suspect that we'll have trouble finding a mentor for the randomized >> linear algebra, however fftpack could be a good topic. Have you seen >> https://github.com/numpy/numpy/pull/11888? I suspect that by the time >> GSoC starts, we'll have merged that into NumPy, and would like to take it >> over for SciPy. A related topic would be to add a backend system for fft >> implementations (pyfftw, mkl-fft). >> > > And a third topic would be to make the APIs of numpy.fft and scipy.fftpack > agree. That would be the lowest on my list because it's hard (requiring > lots of discussion on impact on users if we deprecate things etc.), but > it's an important one as well. > I am interested in adding pocketfft to scipy, which is linked in the numpy PR. Would it be possible to combine this with the backend system project for scipy? Regards, Sourav -------------- next part -------------- An HTML attachment was scrubbed... URL: From aronne.merrelli at gmail.com Sun Nov 25 14:08:01 2018 From: aronne.merrelli at gmail.com (Aronne Merrelli) Date: Sun, 25 Nov 2018 13:08:01 -0600 Subject: [SciPy-Dev] memory leak in LinearNDInterpolator? In-Reply-To: References: Message-ID: On Sat, Nov 24, 2018 at 1:20 PM Ralf Gommers wrote: > > > On Wed, Nov 21, 2018 at 3:19 PM Aronne Merrelli > wrote: > >> Hello, >> >> I am having a problem with the LinearNDInterpolator in SciPy, where it >> looks like there is a memory leak. I have a simple example here, all I do >> is setup a very small LinearNDInterpolator object and call the interpolator >> many times in a loop: >> >> https://gist.github.com/aronnem/707dfeec07b74888fb7390d828684184 >> >> Note that if the "pts_list" and "vals" are swapped with the integer >> versions, there is no leak. Using the floats seems to produce the leak. I >> have tried both conda and Canopy installed environments, they all seem to >> have the same behavior. For example, here is the output I get with a scipy >> 1.1.0 compiled with Cython 0.28.5, numpy 1.13.3 on Mac OS X: >> > > I can reproduce that as well with numpy 1.14.3, cython 0.29.0, scipy > master. > > >> rss_used= 4 KB vms_used= 0 KB >> rss_used= 2516 KB vms_used= 2560 KB >> rss_used= 4836 KB vms_used= 5188 KB >> rss_used= 6880 KB vms_used= 6664 KB >> rss_used= 9408 KB vms_used= 10248 KB >> rss_used= 11680 KB vms_used= 12076 KB >> rss_used= 14356 KB vms_used= 15872 KB >> rss_used= 16736 KB vms_used= 17792 KB >> rss_used= 19416 KB vms_used= 20496 KB >> rss_used= 22100 KB vms_used= 23472 KB >> >> >> The only workaround I have found so far is to downgrade my numpy version >> to 1.11.3. So that seems to suggest it is a numpy problem; however this >> function is implemented in cython, so I am not sure how to tell whether >> this is a numpy, scipy, or cython problem. >> > > It does look like a real memory leak, not the memory allocator holding on > to allocations for longer than it has to. Given that numpy 1.11.3 didn't > show this behavior, it would be helpful to use git bisect on the range numy > v1.11.3-v1.13.3 to find when the numpy behavior changed. I just checked > that v1.11.3 still builds with Cython 0.29.0, so I would suggest cython > 0.29.0 and scipy master. > > Hi - Thank you both for confirming. I did manage to use bisect. All versions compiled without needing Ralf's small patch. The actual bisected commits aren't really relevant, because it looks like the behavior is controlled by value of the NPY_RELAXED_STRIDES_CHECKING variable. This environment variable changed to default to 1/True in numpy 1.12.1, if it was not set in the shell. In earlier versions, it defaulted to 0/False if not set in the shell. It also looks like I can prevent the memory leak behavior in newer numpy (at least, I checked 1.12.1 and 1.15.4), if I rebuild numpy NPY_RELAXED_STRIDES_CHECKING=0. I do not understand what that variable is controlling, so I am still not sure if this is numpy, scipy, or cython issue. Anyone have a suggestion? Otherwise, at least I've found a relatively simple workaround! thanks Aronne > Depending on your OS, you may need this small patch for older numpy: > > diff --git a/numpy/core/src/multiarray/numpyos.c > b/numpy/core/src/multiarray/numpyos.c > index 450ec40b6..ec1e5bc2c 100644 > --- a/numpy/core/src/multiarray/numpyos.c > +++ b/numpy/core/src/multiarray/numpyos.c > @@ -15,7 +15,9 @@ > > #ifdef HAVE_STRTOLD_L > #include > -#include > +#ifdef HAVE_XLOCALE_H > + #include > +#endif > #endif > > Cheers, > Ralf > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at python.org > https://mail.python.org/mailman/listinfo/scipy-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From charlesr.harris at gmail.com Sun Nov 25 14:31:15 2018 From: charlesr.harris at gmail.com (Charles R Harris) Date: Sun, 25 Nov 2018 12:31:15 -0700 Subject: [SciPy-Dev] memory leak in LinearNDInterpolator? In-Reply-To: References: Message-ID: On Sun, Nov 25, 2018 at 12:10 PM Aronne Merrelli wrote: > > > On Sat, Nov 24, 2018 at 1:20 PM Ralf Gommers > wrote: > >> >> >> On Wed, Nov 21, 2018 at 3:19 PM Aronne Merrelli < >> aronne.merrelli at gmail.com> wrote: >> >>> Hello, >>> >>> I am having a problem with the LinearNDInterpolator in SciPy, where it >>> looks like there is a memory leak. I have a simple example here, all I do >>> is setup a very small LinearNDInterpolator object and call the interpolator >>> many times in a loop: >>> >>> https://gist.github.com/aronnem/707dfeec07b74888fb7390d828684184 >>> >>> Note that if the "pts_list" and "vals" are swapped with the integer >>> versions, there is no leak. Using the floats seems to produce the leak. I >>> have tried both conda and Canopy installed environments, they all seem to >>> have the same behavior. For example, here is the output I get with a scipy >>> 1.1.0 compiled with Cython 0.28.5, numpy 1.13.3 on Mac OS X: >>> >> >> I can reproduce that as well with numpy 1.14.3, cython 0.29.0, scipy >> master. >> >> >>> rss_used= 4 KB vms_used= 0 KB >>> rss_used= 2516 KB vms_used= 2560 KB >>> rss_used= 4836 KB vms_used= 5188 KB >>> rss_used= 6880 KB vms_used= 6664 KB >>> rss_used= 9408 KB vms_used= 10248 KB >>> rss_used= 11680 KB vms_used= 12076 KB >>> rss_used= 14356 KB vms_used= 15872 KB >>> rss_used= 16736 KB vms_used= 17792 KB >>> rss_used= 19416 KB vms_used= 20496 KB >>> rss_used= 22100 KB vms_used= 23472 KB >>> >>> >>> The only workaround I have found so far is to downgrade my numpy version >>> to 1.11.3. So that seems to suggest it is a numpy problem; however this >>> function is implemented in cython, so I am not sure how to tell whether >>> this is a numpy, scipy, or cython problem. >>> >> >> It does look like a real memory leak, not the memory allocator holding on >> to allocations for longer than it has to. Given that numpy 1.11.3 didn't >> show this behavior, it would be helpful to use git bisect on the range numy >> v1.11.3-v1.13.3 to find when the numpy behavior changed. I just checked >> that v1.11.3 still builds with Cython 0.29.0, so I would suggest cython >> 0.29.0 and scipy master. >> >> > > Hi - Thank you both for confirming. > > I did manage to use bisect. All versions compiled without needing Ralf's > small patch. The actual bisected commits aren't really relevant, because it > looks like the behavior is controlled by value of the NPY_RELAXED_STRIDES_CHECKING > variable. This environment variable changed to default to 1/True in numpy > 1.12.1, if it was not set in the shell. In earlier versions, it defaulted > to 0/False if not set in the shell. > > It also looks like I can prevent the memory leak behavior in newer numpy > (at least, I checked 1.12.1 and 1.15.4), if I rebuild numpy > NPY_RELAXED_STRIDES_CHECKING=0. > > I do not understand what that variable is controlling, so I am still not > sure if this is numpy, scipy, or cython issue. Anyone have a suggestion? > > Otherwise, at least I've found a relatively simple workaround! > > thanks > Aronne > What happens if you set `NPY_RELAXED_STRIDES_DEBUG=1` with the problem compile? Chuck -------------- next part -------------- An HTML attachment was scrubbed... URL: From aronne.merrelli at gmail.com Sun Nov 25 15:49:57 2018 From: aronne.merrelli at gmail.com (Aronne Merrelli) Date: Sun, 25 Nov 2018 14:49:57 -0600 Subject: [SciPy-Dev] memory leak in LinearNDInterpolator? In-Reply-To: References: Message-ID: On Sun, Nov 25, 2018 at 1:32 PM Charles R Harris wrote: > > > On Sun, Nov 25, 2018 at 12:10 PM Aronne Merrelli < > aronne.merrelli at gmail.com> wrote: > >> >> >> On Sat, Nov 24, 2018 at 1:20 PM Ralf Gommers >> wrote: >> >>> >>> >>> On Wed, Nov 21, 2018 at 3:19 PM Aronne Merrelli < >>> aronne.merrelli at gmail.com> wrote: >>> >>>> Hello, >>>> >>>> I am having a problem with the LinearNDInterpolator in SciPy, where it >>>> looks like there is a memory leak. I have a simple example here, all I do >>>> is setup a very small LinearNDInterpolator object and call the interpolator >>>> many times in a loop: >>>> >>>> https://gist.github.com/aronnem/707dfeec07b74888fb7390d828684184 >>>> >>>> Note that if the "pts_list" and "vals" are swapped with the integer >>>> versions, there is no leak. Using the floats seems to produce the leak. I >>>> have tried both conda and Canopy installed environments, they all seem to >>>> have the same behavior. For example, here is the output I get with a scipy >>>> 1.1.0 compiled with Cython 0.28.5, numpy 1.13.3 on Mac OS X: >>>> >>> >>> I can reproduce that as well with numpy 1.14.3, cython 0.29.0, scipy >>> master. >>> >>> >>>> rss_used= 4 KB vms_used= 0 KB >>>> rss_used= 2516 KB vms_used= 2560 KB >>>> rss_used= 4836 KB vms_used= 5188 KB >>>> rss_used= 6880 KB vms_used= 6664 KB >>>> rss_used= 9408 KB vms_used= 10248 KB >>>> rss_used= 11680 KB vms_used= 12076 KB >>>> rss_used= 14356 KB vms_used= 15872 KB >>>> rss_used= 16736 KB vms_used= 17792 KB >>>> rss_used= 19416 KB vms_used= 20496 KB >>>> rss_used= 22100 KB vms_used= 23472 KB >>>> >>>> >>>> The only workaround I have found so far is to downgrade my numpy >>>> version to 1.11.3. So that seems to suggest it is a numpy problem; however >>>> this function is implemented in cython, so I am not sure how to tell >>>> whether this is a numpy, scipy, or cython problem. >>>> >>> >>> It does look like a real memory leak, not the memory allocator holding >>> on to allocations for longer than it has to. Given that numpy 1.11.3 didn't >>> show this behavior, it would be helpful to use git bisect on the range numy >>> v1.11.3-v1.13.3 to find when the numpy behavior changed. I just checked >>> that v1.11.3 still builds with Cython 0.29.0, so I would suggest cython >>> 0.29.0 and scipy master. >>> >>> >> >> Hi - Thank you both for confirming. >> >> I did manage to use bisect. All versions compiled without needing Ralf's >> small patch. The actual bisected commits aren't really relevant, because it >> looks like the behavior is controlled by value of the NPY_RELAXED_STRIDES_CHECKING >> variable. This environment variable changed to default to 1/True in numpy >> 1.12.1, if it was not set in the shell. In earlier versions, it defaulted >> to 0/False if not set in the shell. >> >> It also looks like I can prevent the memory leak behavior in newer numpy >> (at least, I checked 1.12.1 and 1.15.4), if I rebuild numpy >> NPY_RELAXED_STRIDES_CHECKING=0. >> >> I do not understand what that variable is controlling, so I am still not >> sure if this is numpy, scipy, or cython issue. Anyone have a suggestion? >> >> Otherwise, at least I've found a relatively simple workaround! >> >> thanks >> Aronne >> > > What happens if you set `NPY_RELAXED_STRIDES_DEBUG=1` with the problem > compile? > > Chuck > Hi - I do not see any change with the DEBUG flag enabled. This is with: Python 3.7.1, numpy 1.15.4, scipy 1.1.0, CentOS 6.1. > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at python.org > https://mail.python.org/mailman/listinfo/scipy-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tyler.je.reddy at gmail.com Mon Nov 26 13:47:47 2018 From: tyler.je.reddy at gmail.com (Tyler Reddy) Date: Mon, 26 Nov 2018 10:47:47 -0800 Subject: [SciPy-Dev] ANN: SciPy 1.2.0rc1 -- please test Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi all, On behalf of the SciPy development team I'm pleased to announce the release candidate SciPy 1.2.0rc1. Please help us test out this release candidate -- the 1.2.x series will be an LTS release and the last to support Python 2.7. Sources and binary wheels can be found at: https://pypi.python.org/pypi/scipy and at: https://github.com/scipy/scipy/releases/tag/v1.2.0rc1 To install the release candidate with pip: pip install scipy==1.2.0rc1 ========================== SciPy 1.2.0 Release Notes ========================== Note: Scipy 1.2.0 is not released yet! SciPy 1.2.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. Before upgrading, we recommend that users check that their own code does not use deprecated SciPy functionality (to do so, run your code with ``python -Wd`` and check for ``DeprecationWarning`` s). Our development attention will now shift to bug-fix releases on the 1.2.x branch, and on adding new features on the master branch. This release requires Python 2.7 or 3.4+ and NumPy 1.8.2 or greater. Note: This will be the last SciPy release to support Python 2.7. Consequently, the 1.2.x series will be a long term support (LTS) release; we will backport bug fixes until 1 Jan 2020. For running on PyPy, PyPy3 6.0+ and NumPy 1.15.0 are required. Highlights of this release ---------------------------- - - 1-D root finding improvements with a new solver, ``toms748``, and a new unified interface, ``root_scalar`` - - New ``dual_annealing`` optimization method that combines stochastic and local deterministic searching - - A new optimization algorithm, ``shgo`` (simplicial homology global optimization) for derivative free optimization problems - - A new category of quaternion-based transformations are available in `scipy.spatial.transform` New features ============ `scipy.ndimage` improvements - -------------------------------- Proper spline coefficient calculations have been added for the ``mirror``, ``wrap``, and ``reflect`` modes of `scipy.ndimage.rotate` `scipy.fftpack` improvements - -------------------------------- DCT-IV, DST-IV, DCT-I, and DST-I orthonormalization are now supported in `scipy.fftpack`. `scipy.interpolate` improvements - -------------------------------- `scipy.interpolate.pade` now accepts a new argument for the order of the numerator `scipy.cluster` improvements - ---------------------------- `scipy.cluster.vq.kmeans2` gained a new initialization method, kmeans++. `scipy.special` improvements - ---------------------------- The function ``softmax`` was added to `scipy.special`. `scipy.optimize` improvements - ----------------------------- The one-dimensional nonlinear solvers have been given a unified interface `scipy.optimize.root_scalar`, similar to the `scipy.optimize.root` interface for multi-dimensional solvers. ``scipy.optimize.root_scalar(f, bracket=[a ,b], method="brenth")`` is equivalent to ``scipy.optimize.brenth(f, a ,b)``. If no ``method`` is specified, an appropriate one will be selected based upon the bracket and the number of derivatives available. The so-called Algorithm 748 of Alefeld, Potra and Shi for root-finding within an enclosing interval has been added as `scipy.optimize.toms748`. This provides guaranteed convergence to a root with convergence rate per function evaluation of approximately 1.65 (for sufficiently well-behaved functions.) ``differential_evolution`` now has the ``updating`` and ``workers`` keywords. The first chooses between continuous updating of the best solution vector (the default), or once per generation. Continuous updating can lead to faster convergence. The ``workers`` keyword accepts an ``int`` or map-like callable, and parallelises the solver (having the side effect of updating once per generation). Supplying an ``int`` evaluates the trial solutions in N parallel parts. Supplying a map-like callable allows other parallelisation approaches (such as ``mpi4py``, or ``joblib``) to be used. ``dual_annealing`` (and ``shgo`` below) is a powerful new general purpose global optizimation (GO) algorithm. ``dual_annealing`` uses two annealing processes to accelerate the convergence towards the global minimum of an objective mathematical function. The first annealing process controls the stochastic Markov chain searching and the second annealing process controls the deterministic minimization. So, dual annealing is a hybrid method that takes advantage of stochastic and local deterministic searching in an efficient way. ``shgo`` (simplicial homology global optimization) is a similar algorithm appropriate for solving black box and derivative free optimization (DFO) problems. The algorithm generally converges to the global solution in finite time. The convergence holds for non-linear inequality and equality constraints. In addition to returning a global minimum, the algorithm also returns any other global and local minima found after every iteration. This makes it useful for exploring the solutions in a domain. `scipy.optimize.newton` can now accept a scalar or an array ``MINPACK`` usage is now thread-safe, such that ``MINPACK`` + callbacks may be used on multiple threads. `scipy.signal` improvements - --------------------------- Digital filter design functions now include a parameter to specify the sampling rate. Previously, digital filters could only be specified using normalized frequency, but different functions used different scales (e.g. 0 to 1 for ``butter`` vs 0 to ? for ``freqz``), leading to errors and confusion. With the ``fs`` parameter, ordinary frequencies can now be entered directly into functions, with the normalization handled internally. ``find_peaks`` and related functions no longer raise an exception if the properties of a peak have unexpected values (e.g. a prominence of 0). A ``PeakPropertyWarning`` is given instead. The new keyword argument ``plateau_size`` was added to ``find_peaks``. ``plateau_size`` may be used to select peaks based on the length of the flat top of a peak. ``welch()`` and ``csd()`` methods in `scipy.signal` now support calculation of a median average PSD, using ``average='mean'`` keyword `scipy.sparse` improvements - --------------------------- The `scipy.sparse.bsr_matrix.tocsr` method is now implemented directly instead of converting via COO format, and the `scipy.sparse.bsr_matrix.tocsc` method is now also routed via CSR conversion instead of COO. The efficiency of both conversions is now improved. The issue where SuperLU or UMFPACK solvers crashed on matrices with non-canonical format in `scipy.sparse.linalg` was fixed. The solver wrapper canonicalizes the matrix if necessary before calling the SuperLU or UMFPACK solver. The ``largest`` option of `scipy.sparse.linalg.lobpcg()` was fixed to have a correct (and expected) behavior. The order of the eigenvalues was made consistent with the ARPACK solver (``eigs()``), i.e. ascending for the smallest eigenvalues, and descending for the largest eigenvalues. The `scipy.sparse.random` function is now faster and also supports integer and complex values by passing the appropriate value to the ``dtype`` argument. `scipy.spatial` improvements - ---------------------------- The function `scipy.spatial.distance.jaccard` was modified to return 0 instead of ``np.nan`` when two all-zero vectors are compared. Support for the Jensen Shannon distance, the square-root of the divergence, has been added under `scipy.spatial.distance.jensenshannon` An optional keyword was added to the function `scipy.spatial.cKDTree.query_ball_point()` to sort or not sort the returned indices. Not sorting the indices can speed up calls. A new category of quaternion-based transformations are available in `scipy.spatial.transform`, including spherical linear interpolation of rotations (``Slerp``), conversions to and from quaternions, Euler angles, and general rotation and inversion capabilities (`spatial.transform.Rotation`), and uniform random sampling of 3D rotations (`spatial.transform.Rotation.random`). `scipy.stats` improvements - -------------------------- The Yeo-Johnson power transformation is now supported (``yeojohnson``, ``yeojohnson_llf``, ``yeojohnson_normmax``, ``yeojohnson_normplot``). Unlike the Box-Cox transformation, the Yeo-Johnson transformation can accept negative values. Added a general method to sample random variates based on the density only, in the new function ``rvs_ratio_uniforms``. The Yule-Simon distribution (``yulesimon``) was added -- this is a new discrete probability distribution. ``stats`` and ``mstats`` now have access to a new regression method, ``siegelslopes``, a robust linear regression algorithm `scipy.stats.gaussian_kde` now has the ability to deal with weighted samples, and should have a modest improvement in performance Levy Stable Parameter Estimation, PDF, and CDF calculations are now supported for `scipy.stats.levy_stable`. The Brunner-Munzel test is now available as ``brunnermunzel`` in ``stats`` and ``mstats`` `scipy.linalg` improvements - -------------------------- `scipy.linalg.lapack` now exposes the LAPACK routines using the Rectangular Full Packed storage (RFP) for upper triangular, lower triangular, symmetric, or Hermitian matrices; the upper trapezoidal fat matrix RZ decomposition routines are now available as well. Deprecated features =================== The functions ``hyp2f0``, ``hyp1f2`` and ``hyp3f0`` in ``scipy.special`` have been deprecated. Backwards incompatible changes ============================== LAPACK version 3.4.0 or later is now required. Building with Apple Accelerate is no longer supported. The function ``scipy.linalg.subspace_angles(A, B)`` now gives correct results for all angles. Before this, the function only returned correct values for those angles which were greater than pi/4. Support for the Bento build system has been removed. Bento has not been maintained for several years, and did not have good Python 3 or wheel support, hence it was time to remove it. The required signature of `scipy.optimize.lingprog` ``method=simplex`` callback function has changed. Before iteration begins, the simplex solver first converts the problem into a standard form that does not, in general, have the same variables or constraints as the problem defined by the user. Previously, the simplex solver would pass a user-specified callback function several separate arguments, such as the current solution vector ``xk``, corresponding to this standard form problem. Unfortunately, the relationship between the standard form problem and the user-defined problem was not documented, limiting the utility of the information passed to the callback function. In addition to numerous bug fix changes, the simplex solver now passes a user-specified callback function a single ``OptimizeResult`` object containing information that corresponds directly to the user-defined problem. In future releases, this ``OptimizeResult`` object may be expanded to include additional information, such as variables corresponding to the standard-form problem and information concerning the relationship between the standard-form and user-defined problems. The implementation of `scipy.sparse.random` has changed, and this affects the numerical values returned for both ``sparse.random`` and ``sparse.rand`` for some matrix shapes and a given seed. `scipy.optimize.newton` will no longer use Halley's method in cases where it negatively impacts convergence Other changes ============= Authors ======= * @endolith * @luzpaz * Hameer Abbasi + * akahard2dj + * Anton Akhmerov * Joseph Albert * alexthomas93 + * ashish + * atpage + * Blair Azzopardi + * Yoshiki V?zquez Baeza * Bence Bagi + * Christoph Baumgarten * Lucas Bellomo + * BH4 + * Aditya Bharti * Max Bolingbroke * Fran?ois Boulogne * Ward Bradt + * Matthew Brett * Evgeni Burovski * Rafa? Byczek + * Alfredo Canziani + * CJ Carey * Luc?a Cheung + * Poom Chiarawongse + * Jeanne Choo + * Robert Cimrman * Graham Clenaghan + * cynthia-rempel + * Johannes Damp + * Jaime Fernandez del Rio * Dowon + * emmi474 + * Stefan Endres + * Thomas Etherington + * Alex Fikl + * fo40225 + * Joseph Fox-Rabinovitz * Lars G * Abhinav Gautam + * Stiaan Gerber + * C.A.M. Gerlach + * Ralf Gommers * Todd Goodall * Lars Grueter + * Sylvain Gubian + * Matt Haberland * David Hagen * Will Handley + * Charles Harris * Ian Henriksen * Thomas Hisch + * Theodore Hu * Michael Hudson-Doyle + * Nicolas Hug + * jakirkham + * Jakob Jakobson + * James + * Jan Schl?ter * jeanpauphilet + * josephmernst + * Kai + * Kai-Striega + * kalash04 + * Toshiki Kataoka + * Konrad0 + * Tom Krauss + * Johannes Kulick * Lars Gr?ter + * Eric Larson * Denis Laxalde * Will Lee + * Katrin Leinweber + * Yin Li + * P. L. Lim + * Jesse Livezey + * Duncan Macleod + * MatthewFlamm + * Nikolay Mayorov * Mike McClurg + * Christian Meyer + * Mark Mikofski * Naoto Mizuno + * mohmmadd + * Nathan Musoke * Anju Geetha Nair + * Andrew Nelson * Ayappan P + * Nick Papior * Haesun Park + * Ronny Pfannschmidt + * pijyoi + * Ilhan Polat * Anthony Polloreno + * Ted Pudlik * puenka * Eric Quintero * Pradeep Reddy Raamana + * Vyas Ramasubramani + * Ramon Vi?as + * Tyler Reddy * Joscha Reimer * Antonio H Ribeiro * richardjgowers + * Rob + * robbystk + * Lucas Roberts + * rohan + * Joaquin Derrac Rus + * Josua Sassen + * Bruce Sharpe + * Max Shinn + * Scott Sievert * Sourav Singh * Strahinja Luki? + * Kai Striega + * Shinya SUZUKI + * Mike Toews + * Piotr Uchwat * Miguel de Val-Borro + * Nicky van Foreest * Paul van Mulbregt * Gael Varoquaux * Pauli Virtanen * Stefan van der Walt * Warren Weckesser * Joshua Wharton + * Bernhard M. Wiedemann + * Eric Wieser * Josh Wilson * Tony Xiang + * Roman Yurchak + * Roy Zywina + A total of 137 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. Issues closed for 1.2.0 - ----------------------- * `#1240 `__: Allowing multithreaded use of minpack through scipy.optimize... * `#1432 `__: scipy.stats.mode extremely slow (Trac #905) * `#3372 `__: Please add Sphinx search field to online scipy html docs * `#3678 `__: _clough_tocher_2d_single direction between centroids * `#4174 `__: lobpcg "largest" option invalid? * `#5493 `__: anderson_ksamp p-values>1 * `#5743 `__: slsqp fails to detect infeasible problem * `#6139 `__: scipy.optimize.linprog failed to find a feasible starting point... * `#6358 `__: stats: docstring for `vonmises_line` points to `vonmises_line`... * `#6498 `__: runtests.py is missing in pypi distfile * `#7426 `__: scipy.stats.ksone(n).pdf(x) returns nan for positive values of... * `#7455 `__: scipy.stats.ksone.pdf(2,x) return incorrect values for x near... * `#7456 `__: scipy.special.smirnov and scipy.special.smirnovi have accuracy... * `#7492 `__: scipy.special.kolmogorov(x)/kolmogi(p) inefficient, inaccurate... * `#7914 `__: TravisCI not failing when it should for -OO run * `#8064 `__: linalg.solve test crashes on Windows * `#8212 `__: LAPACK Rectangular Full Packed routines * `#8256 `__: differential_evolution bug converges to wrong results in complex... * `#8443 `__: Deprecate `hyp2f0`, `hyp1f2`, and `hyp3f0`? * `#8452 `__: DOC: ARPACK tutorial has two conflicting equations * `#8680 `__: scipy fails compilation when building from source * `#8686 `__: Division by zero in _trustregion.py when x0 is exactly equal... * `#8700 `__: _MINPACK_LOCK not held when calling into minpack from least_squares * `#8786 `__: erroneous moment values for t-distribution * `#8791 `__: Checking COLA condition in istft should be optional (or omitted) * `#8843 `__: imresize cannot be deprecated just yet * `#8844 `__: Inverse Wishart Log PDF Incorrect for Non-diagonal Scale Matrix? * `#8878 `__: vonmises and vonmises_line in stats: vonmises wrong and superfluous? * `#8895 `__: v1.1.0 `ndi.rotate` documentation ? reused parameters not filled... * `#8900 `__: Missing complex conjugation in scipy.sparse.linalg.LinearOperator * `#8904 `__: BUG: if zero derivative at root, then Newton fails with RuntimeWarning * `#8911 `__: make_interp_spline bc_type incorrect input interpretation * `#8942 `__: MAINT: Refactor `_linprog.py` and `_linprog_ip.py` to remove... * `#8947 `__: np.int64 in scipy.fftpack.next_fast_len * `#9020 `__: BUG: linalg.subspace_angles gives wrong results * `#9033 `__: scipy.stats.normaltest sometimes gives incorrect returns b/c... * `#9036 `__: Bizarre times for `scipy.sparse.rand` function with 'low' density... * `#9044 `__: optimize.minimize(method=`trust-constr`) result dict does not... * `#9071 `__: doc/linalg: add cho_solve_banded to see also of cholesky_banded * `#9082 `__: eigenvalue sorting in scipy.sparse.linalg.eigsh * `#9086 `__: signaltools.py:491: FutureWarning: Using a non-tuple sequence... * `#9091 `__: test_spline_filter failure on 32-bit * `#9122 `__: Typo on scipy minimization tutorial * `#9135 `__: doc error at https://docs.scipy.org/doc/scipy/reference/tutorial/stats/discrete_poisson.html * `#9167 `__: DOC: BUG: typo in ndimage LowLevelCallable tutorial example * `#9169 `__: truncnorm does not work if b < a in scipy.stats * `#9250 `__: scipy.special.tests.test_mpmath::TestSystematic::test_pcfw fails... * `#9259 `__: rv.expect() == rv.mean() is false for rv.mean() == nan (and inf) * `#9286 `__: DOC: Rosenbrock expression in optimize.minimize tutorial * `#9316 `__: SLSQP fails in nested optimization * `#9337 `__: scipy.signal.find_peaks key typo in documentation * `#9345 `__: Example from documentation of scipy.sparse.linalg.eigs raises... * `#9383 `__: Default value for "mode" in "ndimage.shift" * `#9419 `__: dual_annealing off by one in the number of iterations * `#9442 `__: Error in Defintion of Rosenbrock Function * `#9453 `__: TST: test_eigs_consistency() doesn't have consistent results Pull requests for 1.2.0 - ----------------------- * `#7352 `__: ENH: add Brunner Munzel test to scipy.stats. * `#7373 `__: BUG: Jaccard distance for all-zero arrays would return np.nan * `#7374 `__: ENH: Add PDF, CDF and parameter estimation for Stable Distributions * `#8098 `__: ENH: Add shgo for global optimization of NLPs. * `#8203 `__: ENH: adding simulated dual annealing to optimize * `#8259 `__: Option to follow original Storn and Price algorithm and its parallelisation * `#8293 `__: ENH add ratio-of-uniforms method for rv generation to scipy.stats * `#8294 `__: BUG: Fix slowness in stats.mode * `#8295 `__: ENH: add Jensen Shannon distance to `scipy.spatial.distance` * `#8357 `__: ENH: vectorize scalar zero-search-functions * `#8397 `__: Add `fs=` parameter to filter design functions * `#8537 `__: ENH: Implement mode parameter for spline filtering. * `#8558 `__: ENH: small speedup for stats.gaussian_kde * `#8560 `__: BUG: fix p-value calc of anderson_ksamp in scipy.stats * `#8614 `__: ENH: correct p-values for stats.kendalltau and stats.mstats.kendalltau * `#8670 `__: ENH: Require Lapack 3.4.0 * `#8683 `__: Correcting kmeans documentation * `#8725 `__: MAINT: Cleanup scipy.optimize.leastsq * `#8726 `__: BUG: Fix _get_output in scipy.ndimage to support string * `#8733 `__: MAINT: stats: A bit of clean up. * `#8737 `__: BUG: Improve numerical precision/convergence failures of smirnov/kolmogorov * `#8738 `__: MAINT: stats: A bit of clean up in test_distributions.py. * `#8740 `__: BF/ENH: make minpack thread safe * `#8742 `__: BUG: Fix division by zero in trust-region optimization methods * `#8746 `__: MAINT: signal: Fix a docstring of a private function, and fix... * `#8750 `__: DOC clarified description of norminvgauss in scipy.stats * `#8753 `__: DOC: signal: Fix a plot title in the chirp docstring. * `#8755 `__: DOC: MAINT: Fix link to the wheel documentation in developer... * `#8760 `__: BUG: stats: boltzmann wasn't setting the upper bound. * `#8763 `__: [DOC] Improved scipy.cluster.hierarchy documentation * `#8765 `__: DOC: added example for scipy.stat.mstats.tmin * `#8788 `__: DOC: fix definition of optional `disp` parameter * `#8802 `__: MAINT: Suppress dd_real unused function compiler warnings. * `#8803 `__: ENH: Add full_output support to optimize.newton() * `#8804 `__: MAINT: stats cleanup * `#8808 `__: DOC: add note about isinstance for frozen rvs * `#8812 `__: Updated numpydoc submodule * `#8813 `__: MAINT: stats: Fix multinomial docstrings, and do some clean up. * `#8816 `__: BUG: fixed _stats of t-distribution in scipy.stats * `#8817 `__: BUG: ndimage: Fix validation of the origin argument in correlate... * `#8822 `__: BUG: integrate: Fix crash with repeated t values in odeint. * `#8832 `__: Hyperlink DOIs against preferred resolver * `#8837 `__: BUG: sparse: Ensure correct dtype for sparse comparison operations. * `#8839 `__: DOC: stats: A few tweaks to the linregress docstring. * `#8846 `__: BUG: stats: Fix logpdf method of invwishart. * `#8849 `__: DOC: signal: Fixed mistake in the firwin docstring. * `#8854 `__: DOC: fix type descriptors in ltisys documentation * `#8865 `__: Fix tiny typo in docs for chi2 pdf * `#8870 `__: Fixes related to invertibility of STFT * `#8872 `__: ENH: special: Add the softmax function * `#8874 `__: DOC correct gamma function in docstrings in scipy.stats * `#8876 `__: ENH: Added TOMS Algorithm 748 as 1-d root finder; 17 test function... * `#8882 `__: ENH: Only use Halley's adjustment to Newton if close enough. * `#8883 `__: FIX: optimize: make jac and hess truly optional for 'trust-constr' * `#8885 `__: TST: Do not error on warnings raised about non-tuple indexing. * `#8887 `__: MAINT: filter out np.matrix PendingDeprecationWarning's in numpy... * `#8889 `__: DOC: optimize: separate legacy interfaces from new ones * `#8890 `__: ENH: Add optimize.root_scalar() as a universal dispatcher for... * `#8899 `__: DCT-IV, DST-IV and DCT-I, DST-I orthonormalization support in... * `#8901 `__: MAINT: Reorganize flapack.pyf.src file * `#8907 `__: BUG: ENH: Check if guess for newton is already zero before checking... * `#8908 `__: ENH: Make sorting optional for cKDTree.query_ball_point() * `#8910 `__: DOC: sparse.csgraph simple examples. * `#8914 `__: DOC: interpolate: fix equivalences of string aliases * `#8918 `__: add float_control(precise, on) to _fpumode.c * `#8919 `__: MAINT: interpolate: improve error messages for common `bc_type`... * `#8920 `__: DOC: update Contributing to SciPy to say "prefer no PEP8 only... * `#8924 `__: MAINT: special: deprecate `hyp2f0`, `hyp1f2`, and `hyp3f0` * `#8927 `__: MAINT: special: remove `errprint` * `#8932 `__: Fix broadcasting scale arg of entropy * `#8936 `__: Fix (some) non-tuple index warnings * `#8937 `__: ENH: implement sparse matrix BSR to CSR conversion directly. * `#8938 `__: DOC: add @_ni_docstrings.docfiller in ndimage.rotate * `#8940 `__: Update _discrete_distns.py * `#8943 `__: DOC: Finish dangling sentence in `convolve` docstring * `#8944 `__: MAINT: Address tuple indexing and warnings * `#8945 `__: ENH: spatial.transform.Rotation [GSOC2018] * `#8950 `__: csgraph Dijkstra function description rewording * `#8953 `__: DOC, MAINT: HTTP -> HTTPS, and other linkrot fixes * `#8955 `__: BUG: np.int64 in scipy.fftpack.next_fast_len * `#8958 `__: MAINT: Add more descriptive error message for phase one simplex. * `#8962 `__: BUG: sparse.linalg: add missing conjugate to _ScaledLinearOperator.adjoint * `#8963 `__: BUG: sparse.linalg: downgrade LinearOperator TypeError to warning * `#8965 `__: ENH: Wrapped RFP format and RZ decomposition routines * `#8969 `__: MAINT: doc and code fixes for optimize.newton * `#8970 `__: Added 'average' keyword for welch/csd to enable median averaging * `#8971 `__: Better imresize deprecation warning * `#8972 `__: MAINT: Switch np.where(c) for np.nonzero(c) * `#8975 `__: MAINT: Fix warning-based failures * `#8979 `__: DOC: fix description of count_sort keyword of dendrogram * `#8982 `__: MAINT: optimize: Fixed minor mistakes in test_linprog.py (#8978) * `#8984 `__: BUG: sparse.linalg: ensure expm casts integer inputs to float * `#8986 `__: BUG: optimize/slsqp: do not exit with convergence on steps where... * `#8989 `__: MAINT: use collections.abc in basinhopping * `#8990 `__: ENH extend p-values of anderson_ksamp in scipy.stats * `#8991 `__: ENH: Weighted kde * `#8993 `__: ENH: spatial.transform.Rotation.random [GSOC 2018] * `#8994 `__: ENH: spatial.transform.Slerp [GSOC 2018] * `#8995 `__: TST: time.time in test * `#9007 `__: Fix typo in fftpack.rst * `#9013 `__: Added correct plotting code for two sided output from spectrogram * `#9014 `__: BUG: differential_evolution with inf objective functions * `#9017 `__: BUG: fixed #8446 corner case for asformat(array|dense) * `#9018 `__: MAINT: _lib/ccallback: remove unused code * `#9021 `__: BUG: Issue with subspace_angles * `#9022 `__: DOC: Added "See Also" section to lombscargle docstring * `#9034 `__: BUG: Fix tolerance printing behavior, remove meaningless tol... * `#9035 `__: TST: improve signal.bsplines test coverage * `#9037 `__: ENH: add a new init method for k-means * `#9039 `__: DOC: Add examples to fftpack.irfft docstrings * `#9048 `__: ENH: scipy.sparse.random * `#9050 `__: BUG: scipy.io.hb_write: fails for matrices not in csc format * `#9051 `__: MAINT: Fix slow sparse.rand for k < mn/3 (#9036). * `#9054 `__: MAINT: spatial: Explicitly initialize LAPACK output parameters. * `#9055 `__: DOC: Add examples to scipy.special docstrings * `#9056 `__: ENH: Use one thread in OpenBLAS * `#9059 `__: DOC: Update README with link to Code of Conduct * `#9060 `__: BLD: remove support for the Bento build system. * `#9062 `__: DOC add sections to overview in scipy.stats * `#9066 `__: BUG: Correct "remez" error message * `#9069 `__: DOC: update linalg section of roadmap for LAPACK versions. * `#9079 `__: MAINT: add spatial.transform to refguide check; complete some... * `#9081 `__: MAINT: Add warnings if pivot value is close to tolerance in linprog(method='simplex') * `#9084 `__: BUG fix incorrect p-values of kurtosistest in scipy.stats * `#9095 `__: DOC: add sections to mstats overview in scipy.stats * `#9096 `__: BUG: Add test for Stackoverflow example from issue 8174. * `#9101 `__: ENH: add Siegel slopes (robust regression) to scipy.stats * `#9105 `__: allow resample_poly() to output float32 for float32 inputs. * `#9112 `__: MAINT: optimize: make trust-constr accept constraint dict (#9043) * `#9118 `__: Add doc entry to cholesky_banded * `#9120 `__: eigsh documentation parameters * `#9125 `__: interpolative: correctly reconstruct full rank matrices * `#9126 `__: MAINT: Use warnings for unexpected peak properties * `#9129 `__: BUG: Do not catch and silence KeyboardInterrupt * `#9131 `__: DOC: Correct the typo in scipy.optimize tutorial page * `#9133 `__: FIX: Avoid use of bare except * `#9134 `__: DOC: Update of 'return_eigenvectors' description * `#9137 `__: DOC: typo fixes for discrete Poisson tutorial * `#9139 `__: FIX: Doctest failure in optimize tutorial * `#9143 `__: DOC: missing sigma in Pearson r formula * `#9145 `__: MAINT: Refactor linear programming solvers * `#9149 `__: FIX: Make scipy.odr.ODR ifixx equal to its data.fix if given * `#9156 `__: DOC: special: Mention the sigmoid function in the expit docstring. * `#9160 `__: Fixed a latex delimiter error in levy() * `#9170 `__: DOC: correction / update of docstrings of distributions in scipy.stats * `#9171 `__: better description of the hierarchical clustering parameter * `#9174 `__: domain check for a < b in stats.truncnorm * `#9175 `__: DOC: Minor grammar fix * `#9176 `__: BUG: CloughTocher2DInterpolator: fix miscalculation at neighborless... * `#9177 `__: BUILD: Document the "clean" target in the doc/Makefile. * `#9178 `__: MAINT: make refguide-check more robust for printed numpy arrays * `#9186 `__: MAINT: Remove np.ediff1d occurence * `#9188 `__: DOC: correct typo in extending ndimage with C * `#9190 `__: ENH: Support specifying axes for fftconvolve * `#9192 `__: MAINT: optimize: fixed @pv style suggestions from #9112 * `#9200 `__: Fix make_interp_spline(..., k=0 or 1, axis<0) * `#9201 `__: BUG: sparse.linalg/gmres: use machine eps in breakdown check * `#9204 `__: MAINT: fix up stats.spearmanr and match mstats.spearmanr with... * `#9206 `__: MAINT: include benchmarks and dev files in sdist. * `#9208 `__: TST: signal: bump bsplines test tolerance for complex data * `#9210 `__: TST: mark tests as slow, fix missing random seed * `#9211 `__: ENH: add capability to specify orders in pade func * `#9217 `__: MAINT: Include ``success`` and ``nit`` in OptimizeResult returned... * `#9222 `__: ENH: interpolate: Use scipy.spatial.distance to speed-up Rbf * `#9229 `__: MNT: Fix Fourier filter double case * `#9233 `__: BUG: spatial/distance: fix pdist/cdist performance regression... * `#9234 `__: FIX: Proper suppression * `#9235 `__: BENCH: rationalize slow benchmarks + miscellaneous fixes * `#9238 `__: BENCH: limit number of parameter combinations in spatial.*KDTree... * `#9239 `__: DOC: stats: Fix LaTeX markup of a couple distribution PDFs. * `#9241 `__: ENH: Evaluate plateau size during peak finding * `#9242 `__: ENH: stats: Implement _ppf and _logpdf for crystalball, and do... * `#9246 `__: DOC: Properly render versionadded directive in HTML documentation * `#9255 `__: DOC: mention RootResults in optimization reference guide * `#9260 `__: TST: relax some tolerances so tests pass with x87 math * `#9264 `__: TST Use assert_raises "match" parameter instead of the "message"... * `#9267 `__: DOC: clarify expect() return val when moment is inf/nan * `#9272 `__: DOC: Add description of default bounds to linprog * `#9277 `__: MAINT: sparse/linalg: make test deterministic * `#9278 `__: MAINT: interpolate: pep8 cleanup in test_polyint * `#9279 `__: Fixed docstring for resample * `#9280 `__: removed first check for float in get_sum_dtype * `#9281 `__: BUG: only accept 1d input for bartlett / levene in scipy.stats * `#9282 `__: MAINT: dense_output and t_eval are mutually exclusive inputs * `#9283 `__: MAINT: add docs and do some cleanups in interpolate.Rbf * `#9288 `__: Run distance_transform_edt tests on all types * `#9294 `__: DOC: fix the formula typo * `#9298 `__: MAINT: optimize/trust-constr: restore .niter attribute for backward-compat * `#9299 `__: DOC: clarification of default rvs method in scipy.stats * `#9301 `__: MAINT: removed unused import sys * `#9302 `__: MAINT: removed unused imports * `#9303 `__: DOC: signal: Refer to fs instead of nyq in the firwin docstring. * `#9305 `__: ENH: Added Yeo-Johnson power transformation * `#9306 `__: ENH - add dual annealing * `#9309 `__: ENH add the yulesimon distribution to scipy.stats * `#9317 `__: Nested SLSQP bug fix. * `#9320 `__: MAINT: stats: avoid underflow in stats.geom.ppf * `#9326 `__: Add example for Rosenbrock function * `#9332 `__: Sort file lists * `#9340 `__: Fix typo in find_peaks documentation * `#9343 `__: MAINT Use np.full when possible * `#9344 `__: DOC: added examples to docstring of dirichlet class * `#9346 `__: DOC: Fix import of scipy.sparse.linalg in example (#9345) * `#9350 `__: Fix interpolate read only * `#9351 `__: MAINT: special.erf: use the x->-x symmetry * `#9356 `__: Fix documentation typo * `#9358 `__: DOC: improve doc for ksone and kstwobign in scipy.stats * `#9362 `__: DOC: Change datatypes of A matrices in linprog * `#9364 `__: MAINT: Adds implicit none to fftpack fortran sources * `#9369 `__: DOC: minor tweak to CoC (updated NumFOCUS contact address). * `#9373 `__: Fix exception if python is called with -OO option * `#9374 `__: FIX: AIX compilation issue with NAN and INFINITY * `#9376 `__: COBLYA -> COBYLA in docs * `#9377 `__: DOC: Add examples integrate: fixed_quad and quadrature * `#9379 `__: MAINT: TST: Make tests NumPy 1.8 compatible * `#9385 `__: CI: On Travis matrix "OPTIMIZE=-OO" flag ignored * `#9387 `__: Fix defaut value for 'mode' in 'ndimage.shift' in the doc * `#9392 `__: BUG: rank has to be integer in rank_filter: fixed issue 9388 * `#9399 `__: DOC: Misc. typos * `#9400 `__: TST: stats: Fix the expected r-value of a linregress test. * `#9405 `__: BUG: np.hstack does not accept generator expressions * `#9408 `__: ENH: linalg: Shorter ill-conditioned warning message * `#9418 `__: DOC: Fix ndimage docstrings and reduce doc build warnings * `#9421 `__: DOC: Add missing docstring examples in scipy.spatial * `#9422 `__: DOC: Add an example to integrate.newton_cotes * `#9427 `__: BUG: Fixed defect with maxiter #9419 in dual annealing * `#9431 `__: BENCH: Add dual annealing to scipy benchmark (see #9415) * `#9435 `__: DOC: Add docstring examples for stats.binom_test * `#9443 `__: DOC: Fix the order of indices in optimize tutorial * `#9444 `__: MAINT: interpolate: use operator.index for checking/coercing... * `#9445 `__: DOC: Added missing example to stats.mstats.kruskal * `#9446 `__: DOC: Add note about version changed for jaccard distance * `#9447 `__: BLD: version-script handling in setup.py * `#9448 `__: TST: skip a problematic linalg test * `#9449 `__: TST: fix missing seed in lobpcg test. * `#9456 `__: TST: test_eigs_consistency() now sorts output Checksums ========= MD5 ~~~ 47d309402d2e5574be8fa261fadfaf58 scipy-1.2.0rc1-cp27-cp27m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl 911dfde5be66403c07c60e19aa631dc2 scipy-1.2.0rc1-cp27-cp27m-manylinux1_i686.whl a693189336365595b42b0d93f825b826 scipy-1.2.0rc1-cp27-cp27m-manylinux1_x86_64.whl ec5abd33480761ed9701f7fd2274fc47 scipy-1.2.0rc1-cp27-cp27m-win32.whl bc3d40311f057b12f8fea97166ef8112 scipy-1.2.0rc1-cp27-cp27m-win_amd64.whl 33848233e6438b1ff9183d8a4794daed scipy-1.2.0rc1-cp27-cp27mu-manylinux1_i686.whl c2cb1166ce0071e1fe42ed1c3e60b75e scipy-1.2.0rc1-cp27-cp27mu-manylinux1_x86_64.whl a04b5a758f555e05e6431b8a1f035888 scipy-1.2.0rc1-cp34-cp34m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl ad511246d0742cf0669fedf292cc01bb scipy-1.2.0rc1-cp34-cp34m-manylinux1_i686.whl 15aa08ef43a6c5cb320bc015f01087ad scipy-1.2.0rc1-cp34-cp34m-manylinux1_x86_64.whl 86a59b81a3e6894d9054139311a2c51f scipy-1.2.0rc1-cp34-cp34m-win32.whl 8b6e33253579916ea873c45989ee5bea scipy-1.2.0rc1-cp34-cp34m-win_amd64.whl db7a4de02828471bf9f800814ff68627 scipy-1.2.0rc1-cp35-cp35m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl c296b6270d29d3ec6dafddf8ceae67fb scipy-1.2.0rc1-cp35-cp35m-manylinux1_i686.whl 3ba7a825f61822128d960fa728010e51 scipy-1.2.0rc1-cp35-cp35m-manylinux1_x86_64.whl c083c8287da110b707d181f6638ce122 scipy-1.2.0rc1-cp35-cp35m-win32.whl 2242eac92681085258535ed96bd040d7 scipy-1.2.0rc1-cp35-cp35m-win_amd64.whl d5c238903c00e91a40d56023f1a27ed4 scipy-1.2.0rc1-cp36-cp36m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl e8ab7487a9a53b86a6510772c45af787 scipy-1.2.0rc1-cp36-cp36m-manylinux1_i686.whl 9991b5958d736488bef638eea463945d scipy-1.2.0rc1-cp36-cp36m-manylinux1_x86_64.whl 9c108a9d7e967b8c9a5e5143b1a15b40 scipy-1.2.0rc1-cp36-cp36m-win32.whl 54d63041f0315d341d9ffb028a98e767 scipy-1.2.0rc1-cp36-cp36m-win_amd64.whl 534276c864ab3139811561c022608cc3 scipy-1.2.0rc1-cp37-cp37m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl 4bd26c179a10891087bd81a658573683 scipy-1.2.0rc1-cp37-cp37m-manylinux1_i686.whl 1a3170b4f1df42f28efbe197e54eb9a3 scipy-1.2.0rc1-cp37-cp37m-manylinux1_x86_64.whl 72b89f7e2c1d13dc8dbb21600fb184da scipy-1.2.0rc1-cp37-cp37m-win32.whl 433ef294c4a015da0a6e0f063289a658 scipy-1.2.0rc1-cp37-cp37m-win_amd64.whl 83abb1befce326916e0435d428b36e62 scipy-1.2.0rc1.tar.gz 21b7570fb577543807feb4b4c1fdad8a scipy-1.2.0rc1.tar.xz 11221dc23e0d3b316b5564f2f435aaf1 scipy-1.2.0rc1.zip SHA256 ~~~~~~ a3282027743e89d5fcb6cd7a9e4ecdbbde61bf8126fd19683e97b69f5f6a2163 scipy-1.2.0rc1-cp27-cp27m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl 8b8841e03620d4d704f4efd3daed575e23a6272ae9c9be2c4cc751febee984f7 scipy-1.2.0rc1-cp27-cp27m-manylinux1_i686.whl 254ea2f7f3c5afef9f02c0192d2dbd8f5336c1b1c53efae7ef64a8880cccc299 scipy-1.2.0rc1-cp27-cp27m-manylinux1_x86_64.whl d449832419df3e37a3942778b46c140fd61d1e4f38f9e34bed278a77aacdbd31 scipy-1.2.0rc1-cp27-cp27m-win32.whl e57f3e3eaa88cd7bc93466122fca48c36863e03aeb24f9d570a2e6b2ea3cbf92 scipy-1.2.0rc1-cp27-cp27m-win_amd64.whl 00dcb606101fa10951ee235af69dbff55d999b01c9bb2bc0f64df5fc3aff4eb6 scipy-1.2.0rc1-cp27-cp27mu-manylinux1_i686.whl 38857eb49f7e38d3ec079772225a79235d0bd847e24d2fa8c9a9fa70ee69f0a2 scipy-1.2.0rc1-cp27-cp27mu-manylinux1_x86_64.whl 9b9950278f36c4e7779148cc9a719d41a305024c70005f994412845172ade346 scipy-1.2.0rc1-cp34-cp34m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl c8a2fc15c64f1b162b02f86d28153b65f64720ca64e832bcf5bfae060a507949 scipy-1.2.0rc1-cp34-cp34m-manylinux1_i686.whl 4e205e0e5e88fe2105c594a706ac9fa558fe7a4daa2bef2c86b343ab507d8bd6 scipy-1.2.0rc1-cp34-cp34m-manylinux1_x86_64.whl b04fb8ba796198d83614138d7f96e88791d83f5f4e31e628cce51fda1a092f66 scipy-1.2.0rc1-cp34-cp34m-win32.whl c34e4ce9a8c62c85f322d7897a257a839a4bb7fd94e08701044e9b1cc1bb15a6 scipy-1.2.0rc1-cp34-cp34m-win_amd64.whl cb7f4c289c06514c6e224263868a98d5e6aa6e8a90f2304b16ff276aa96030ce scipy-1.2.0rc1-cp35-cp35m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl dcaeed34e7e965e935ba252fd3290c04cafb7d84f6f44c9c08269504aa2e0a05 scipy-1.2.0rc1-cp35-cp35m-manylinux1_i686.whl 13b234b4fbda1368474a667fc29e8365b622c4c607ed490f00643625c8f50cca scipy-1.2.0rc1-cp35-cp35m-manylinux1_x86_64.whl 073560d6598b97b8f214a31856a1d43c96701b46c5cc9805789f962c3b8a0e97 scipy-1.2.0rc1-cp35-cp35m-win32.whl 600cf596b83f185dca3455d03ca802de0b4de98cb4c8d041226089d78d04c2bc scipy-1.2.0rc1-cp35-cp35m-win_amd64.whl 77b7ed8e13f03a843d2f11bd140f224abe62fb56656f35348578e3838ff4d528 scipy-1.2.0rc1-cp36-cp36m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl 98786b516d1955592f921c2b36505840ff921c9e82f5c28a6c2a580fb3e96af1 scipy-1.2.0rc1-cp36-cp36m-manylinux1_i686.whl 8f62fc6ac6b842d7c3c499269150ec81d26a0dea5ce818aef3b0e9e14e53c5c7 scipy-1.2.0rc1-cp36-cp36m-manylinux1_x86_64.whl 213cfc35ec2fbf86c5957d1ada99a1fe1eacccdb498d4790089af9cf50cadab4 scipy-1.2.0rc1-cp36-cp36m-win32.whl 287e46f87399eb9897c726c6d358c893f6c769300599bc5da95cbf3397a00aa7 scipy-1.2.0rc1-cp36-cp36m-win_amd64.whl 7116d193da4baca6f7cd1cd7810548fa03ed4a06e05f325978b2f0018b05ead9 scipy-1.2.0rc1-cp37-cp37m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl 9cd3fe767225b0dcfcc9f09ed18288b51c29b35ca16dc4e5a6f3587b4ac7d7b5 scipy-1.2.0rc1-cp37-cp37m-manylinux1_i686.whl 4024aea96a01ca05af701f93fd227a7f646258116903899a75b1f4a1f0134bf8 scipy-1.2.0rc1-cp37-cp37m-manylinux1_x86_64.whl eccd0e6d321585b6e2ee18fa0ee1db4fe042e52fb4ae8e28a3d223df6bcd6a8e scipy-1.2.0rc1-cp37-cp37m-win32.whl 96f6c69b2d8f63dad5612385521d0cf8b62f665a62f56b6b3d3fb7042a63c34c scipy-1.2.0rc1-cp37-cp37m-win_amd64.whl ca9ba36bb271dcb4273e330c0bd418a1c3566ff76248dd634efecbe0e9c1721c scipy-1.2.0rc1.tar.gz b8fe757f377b43c733a0ba235b990fb4b3722bd6f5930a26359d16752e94560c scipy-1.2.0rc1.tar.xz da1980e7e037e2275821d7611a91eadafdc157b096f36f41d05cc0ea4ae539bc scipy-1.2.0rc1.zip -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEgfAqrOuERrV4fwr6XCLdIy4FKasFAlv8LB8ACgkQXCLdIy4F KauhWw//cFUboxtuNZeEh98Pn2mfVIqRF8hc6VK7jeXU64qiAdOnbBRKXfoXWpbt 8fEckTFVVt2CQzIEZju429P0eWv8psfvn90cNnj5VHz7h46AH5gQee/cfP1kNWGO mxcYczqZN8+ldDnww4hfk0R+3IrpfmQbVSMEqBF84uottfgUjUzPtcFHJmmmcOF2 7XWhAP5IWMctcwq3r3WAa8yLUmlEIB3Fs9mPPr1We7e0QiXnEueUrXVZF9Oz3UpJ UFiTwX5nxnNdxZJwtLbBXhxJUbvPnooby0x1NwxFG6AwrWaPG3my0e9kIzpwqfsf 0B7Pt/xPEHWIizaqMyfUiaS7FZOUfvq6xs5aCyQeP9Wtnwherm6SQ/Qs+LFSb8E2 9cgyFmaBeslrTMd3f1YMcb6d1hmNSjbBmWccZEXCqjC9UClxbAQDHDcdmTl+4vp7 xATCxWkYVP9lOLH5TtIC1Bo0AZXiOxI3JnojQS65JH0w4unh1IJJkENurzCATh4/ vnyddy0x2e1ok5bX8fpVFrCc8lSdO8aDY5cYEU55XZhkyroet3IaOYqwPzPQPwoJ QgYEsqxa2Urn0faV5uuDFTscnCAHK0EVXhr3yyL0YoIGOPffM8JaswEAUaFwLrq0 KEbOavdImtSwqL9v6x5tDyYXh/mHQ70GGtPS68iSc1NexRrwLAw= =F/+Z -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From charlesr.harris at gmail.com Mon Nov 26 16:16:04 2018 From: charlesr.harris at gmail.com (Charles R Harris) Date: Mon, 26 Nov 2018 14:16:04 -0700 Subject: [SciPy-Dev] [Numpy-discussion] ANN: SciPy 1.2.0rc1 -- please test In-Reply-To: References: Message-ID: Congratulations on your first release. May there be many more :) Chuck On Mon, Nov 26, 2018 at 11:48 AM Tyler Reddy wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Hi all, > > On behalf of the SciPy development team I'm pleased to announce > the release candidate SciPy 1.2.0rc1. Please help us test out this > release candidate -- the 1.2.x series will be an LTS release and the > last to support Python 2.7. > > Sources and binary wheels can be found at: > https://pypi.python.org/pypi/scipy > and at: > https://github.com/scipy/scipy/releases/tag/v1.2.0rc1 > > To install the release candidate with pip: > > pip install scipy==1.2.0rc1 > > > ========================== > SciPy 1.2.0 Release Notes > ========================== > > Note: Scipy 1.2.0 is not released yet! > > SciPy 1.2.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. Before upgrading, we recommend that users check that > their own code does not use deprecated SciPy functionality (to do so, > run your code with ``python -Wd`` and check for ``DeprecationWarning`` s). > Our development attention will now shift to bug-fix releases on the > 1.2.x branch, and on adding new features on the master branch. > > This release requires Python 2.7 or 3.4+ and NumPy 1.8.2 or greater. > > Note: This will be the last SciPy release to support Python 2.7. > Consequently, the 1.2.x series will be a long term support (LTS) > release; we will backport bug fixes until 1 Jan 2020. > > For running on PyPy, PyPy3 6.0+ and NumPy 1.15.0 are required. > > Highlights of this release > ---------------------------- > > - - 1-D root finding improvements with a new solver, ``toms748``, and a new > unified interface, ``root_scalar`` > - - New ``dual_annealing`` optimization method that combines stochastic and > local deterministic searching > - - A new optimization algorithm, ``shgo`` (simplicial homology > global optimization) for derivative free optimization problems > - - A new category of quaternion-based transformations are available in > `scipy.spatial.transform` > > New features > ============ > > `scipy.ndimage` improvements > - -------------------------------- > > Proper spline coefficient calculations have been added for the ``mirror``, > ``wrap``, and ``reflect`` modes of `scipy.ndimage.rotate` > > `scipy.fftpack` improvements > - -------------------------------- > > DCT-IV, DST-IV, DCT-I, and DST-I orthonormalization are now supported in > `scipy.fftpack`. > > `scipy.interpolate` improvements > - -------------------------------- > > `scipy.interpolate.pade` now accepts a new argument for the order of the > numerator > > `scipy.cluster` improvements > - ---------------------------- > > `scipy.cluster.vq.kmeans2` gained a new initialization method, kmeans++. > > `scipy.special` improvements > - ---------------------------- > > The function ``softmax`` was added to `scipy.special`. > > `scipy.optimize` improvements > - ----------------------------- > > The one-dimensional nonlinear solvers have been given a unified interface > `scipy.optimize.root_scalar`, similar to the `scipy.optimize.root` > interface > for multi-dimensional solvers. ``scipy.optimize.root_scalar(f, bracket=[a > ,b], > method="brenth")`` is equivalent to ``scipy.optimize.brenth(f, a ,b)``. > If no > ``method`` is specified, an appropriate one will be selected based upon the > bracket and the number of derivatives available. > > The so-called Algorithm 748 of Alefeld, Potra and Shi for root-finding > within > an enclosing interval has been added as `scipy.optimize.toms748`. This > provides > guaranteed convergence to a root with convergence rate per function > evaluation > of approximately 1.65 (for sufficiently well-behaved functions.) > > ``differential_evolution`` now has the ``updating`` and ``workers`` > keywords. > The first chooses between continuous updating of the best solution vector > (the > default), or once per generation. Continuous updating can lead to faster > convergence. The ``workers`` keyword accepts an ``int`` or map-like > callable, > and parallelises the solver (having the side effect of updating once per > generation). Supplying an ``int`` evaluates the trial solutions in N > parallel > parts. Supplying a map-like callable allows other parallelisation > approaches > (such as ``mpi4py``, or ``joblib``) to be used. > > ``dual_annealing`` (and ``shgo`` below) is a powerful new general purpose > global optizimation (GO) algorithm. ``dual_annealing`` uses two annealing > processes to accelerate the convergence towards the global minimum of an > objective mathematical function. The first annealing process controls the > stochastic Markov chain searching and the second annealing process > controls the > deterministic minimization. So, dual annealing is a hybrid method that > takes > advantage of stochastic and local deterministic searching in an efficient > way. > > ``shgo`` (simplicial homology global optimization) is a similar algorithm > appropriate for solving black box and derivative free optimization (DFO) > problems. The algorithm generally converges to the global solution in > finite > time. The convergence holds for non-linear inequality and > equality constraints. In addition to returning a global minimum, the > algorithm also returns any other global and local minima found after every > iteration. This makes it useful for exploring the solutions in a domain. > > `scipy.optimize.newton` can now accept a scalar or an array > > ``MINPACK`` usage is now thread-safe, such that ``MINPACK`` + callbacks may > be used on multiple threads. > > `scipy.signal` improvements > - --------------------------- > > Digital filter design functions now include a parameter to specify the > sampling > rate. Previously, digital filters could only be specified using normalized > frequency, but different functions used different scales (e.g. 0 to 1 for > ``butter`` vs 0 to ? for ``freqz``), leading to errors and confusion. With > the ``fs`` parameter, ordinary frequencies can now be entered directly into > functions, with the normalization handled internally. > > ``find_peaks`` and related functions no longer raise an exception if the > properties of a peak have unexpected values (e.g. a prominence of 0). A > ``PeakPropertyWarning`` is given instead. > > The new keyword argument ``plateau_size`` was added to ``find_peaks``. > ``plateau_size`` may be used to select peaks based on the length of the > flat top of a peak. > > ``welch()`` and ``csd()`` methods in `scipy.signal` now support calculation > of a median average PSD, using ``average='mean'`` keyword > > `scipy.sparse` improvements > - --------------------------- > > The `scipy.sparse.bsr_matrix.tocsr` method is now implemented directly > instead > of converting via COO format, and the `scipy.sparse.bsr_matrix.tocsc` > method > is now also routed via CSR conversion instead of COO. The efficiency of > both > conversions is now improved. > > The issue where SuperLU or UMFPACK solvers crashed on matrices with > non-canonical format in `scipy.sparse.linalg` was fixed. The solver wrapper > canonicalizes the matrix if necessary before calling the SuperLU or UMFPACK > solver. > > The ``largest`` option of `scipy.sparse.linalg.lobpcg()` was fixed to have > a correct (and expected) behavior. The order of the eigenvalues was made > consistent with the ARPACK solver (``eigs()``), i.e. ascending for the > smallest eigenvalues, and descending for the largest eigenvalues. > > The `scipy.sparse.random` function is now faster and also supports integer > and > complex values by passing the appropriate value to the ``dtype`` argument. > > `scipy.spatial` improvements > - ---------------------------- > > The function `scipy.spatial.distance.jaccard` was modified to return 0 > instead > of ``np.nan`` when two all-zero vectors are compared. > > Support for the Jensen Shannon distance, the square-root of the > divergence, has > been added under `scipy.spatial.distance.jensenshannon` > > An optional keyword was added to the function > `scipy.spatial.cKDTree.query_ball_point()` to sort or not sort the returned > indices. Not sorting the indices can speed up calls. > > A new category of quaternion-based transformations are available in > `scipy.spatial.transform`, including spherical linear interpolation of > rotations (``Slerp``), conversions to and from quaternions, Euler angles, > and general rotation and inversion capabilities > (`spatial.transform.Rotation`), and uniform random sampling of 3D > rotations (`spatial.transform.Rotation.random`). > > `scipy.stats` improvements > - -------------------------- > > The Yeo-Johnson power transformation is now supported (``yeojohnson``, > ``yeojohnson_llf``, ``yeojohnson_normmax``, ``yeojohnson_normplot``). > Unlike > the Box-Cox transformation, the Yeo-Johnson transformation can accept > negative > values. > > Added a general method to sample random variates based on the density > only, in > the new function ``rvs_ratio_uniforms``. > > The Yule-Simon distribution (``yulesimon``) was added -- this is a new > discrete probability distribution. > > ``stats`` and ``mstats`` now have access to a new regression method, > ``siegelslopes``, a robust linear regression algorithm > > `scipy.stats.gaussian_kde` now has the ability to deal with weighted > samples, > and should have a modest improvement in performance > > Levy Stable Parameter Estimation, PDF, and CDF calculations are now > supported > for `scipy.stats.levy_stable`. > > The Brunner-Munzel test is now available as ``brunnermunzel`` in ``stats`` > and ``mstats`` > > `scipy.linalg` improvements > - -------------------------- > > `scipy.linalg.lapack` now exposes the LAPACK routines using the Rectangular > Full Packed storage (RFP) for upper triangular, lower triangular, > symmetric, > or Hermitian matrices; the upper trapezoidal fat matrix RZ decomposition > routines are now available as well. > > Deprecated features > =================== > The functions ``hyp2f0``, ``hyp1f2`` and ``hyp3f0`` in ``scipy.special`` > have > been deprecated. > > > Backwards incompatible changes > ============================== > > LAPACK version 3.4.0 or later is now required. Building with > Apple Accelerate is no longer supported. > > The function ``scipy.linalg.subspace_angles(A, B)`` now gives correct > results for all angles. Before this, the function only returned > correct values for those angles which were greater than pi/4. > > Support for the Bento build system has been removed. Bento has not been > maintained for several years, and did not have good Python 3 or wheel > support, > hence it was time to remove it. > > The required signature of `scipy.optimize.lingprog` ``method=simplex`` > callback function has changed. Before iteration begins, the simplex solver > first converts the problem into a standard form that does not, in general, > have the same variables or constraints > as the problem defined by the user. Previously, the simplex solver would > pass a > user-specified callback function several separate arguments, such as the > current solution vector ``xk``, corresponding to this standard form > problem. > Unfortunately, the relationship between the standard form problem and the > user-defined problem was not documented, limiting the utility of the > information passed to the callback function. > > In addition to numerous bug fix changes, the simplex solver now passes a > user-specified callback function a single ``OptimizeResult`` object > containing > information that corresponds directly to the user-defined problem. In > future > releases, this ``OptimizeResult`` object may be expanded to include > additional > information, such as variables corresponding to the standard-form problem > and > information concerning the relationship between the standard-form and > user-defined problems. > > The implementation of `scipy.sparse.random` has changed, and this affects > the > numerical values returned for both ``sparse.random`` and ``sparse.rand`` > for > some matrix shapes and a given seed. > > `scipy.optimize.newton` will no longer use Halley's method in cases where > it > negatively impacts convergence > > Other changes > ============= > > > Authors > ======= > > * @endolith > * @luzpaz > * Hameer Abbasi + > * akahard2dj + > * Anton Akhmerov > * Joseph Albert > * alexthomas93 + > * ashish + > * atpage + > * Blair Azzopardi + > * Yoshiki V?zquez Baeza > * Bence Bagi + > * Christoph Baumgarten > * Lucas Bellomo + > * BH4 + > * Aditya Bharti > * Max Bolingbroke > * Fran?ois Boulogne > * Ward Bradt + > * Matthew Brett > * Evgeni Burovski > * Rafa? Byczek + > * Alfredo Canziani + > * CJ Carey > * Luc?a Cheung + > * Poom Chiarawongse + > * Jeanne Choo + > * Robert Cimrman > * Graham Clenaghan + > * cynthia-rempel + > * Johannes Damp + > * Jaime Fernandez del Rio > * Dowon + > * emmi474 + > * Stefan Endres + > * Thomas Etherington + > * Alex Fikl + > * fo40225 + > * Joseph Fox-Rabinovitz > * Lars G > * Abhinav Gautam + > * Stiaan Gerber + > * C.A.M. Gerlach + > * Ralf Gommers > * Todd Goodall > * Lars Grueter + > * Sylvain Gubian + > * Matt Haberland > * David Hagen > * Will Handley + > * Charles Harris > * Ian Henriksen > * Thomas Hisch + > * Theodore Hu > * Michael Hudson-Doyle + > * Nicolas Hug + > * jakirkham + > * Jakob Jakobson + > * James + > * Jan Schl?ter > * jeanpauphilet + > * josephmernst + > * Kai + > * Kai-Striega + > * kalash04 + > * Toshiki Kataoka + > * Konrad0 + > * Tom Krauss + > * Johannes Kulick > * Lars Gr?ter + > * Eric Larson > * Denis Laxalde > * Will Lee + > * Katrin Leinweber + > * Yin Li + > * P. L. Lim + > * Jesse Livezey + > * Duncan Macleod + > * MatthewFlamm + > * Nikolay Mayorov > * Mike McClurg + > * Christian Meyer + > * Mark Mikofski > * Naoto Mizuno + > * mohmmadd + > * Nathan Musoke > * Anju Geetha Nair + > * Andrew Nelson > * Ayappan P + > * Nick Papior > * Haesun Park + > * Ronny Pfannschmidt + > * pijyoi + > * Ilhan Polat > * Anthony Polloreno + > * Ted Pudlik > * puenka > * Eric Quintero > * Pradeep Reddy Raamana + > * Vyas Ramasubramani + > * Ramon Vi?as + > * Tyler Reddy > * Joscha Reimer > * Antonio H Ribeiro > * richardjgowers + > * Rob + > * robbystk + > * Lucas Roberts + > * rohan + > * Joaquin Derrac Rus + > * Josua Sassen + > * Bruce Sharpe + > * Max Shinn + > * Scott Sievert > * Sourav Singh > * Strahinja Luki? + > * Kai Striega + > * Shinya SUZUKI + > * Mike Toews + > * Piotr Uchwat > * Miguel de Val-Borro + > * Nicky van Foreest > * Paul van Mulbregt > * Gael Varoquaux > * Pauli Virtanen > * Stefan van der Walt > * Warren Weckesser > * Joshua Wharton + > * Bernhard M. Wiedemann + > * Eric Wieser > * Josh Wilson > * Tony Xiang + > * Roman Yurchak + > * Roy Zywina + > > A total of 137 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. > > Issues closed for 1.2.0 > - ----------------------- > > * `#1240 `__: Allowing > multithreaded use of minpack through scipy.optimize... > * `#1432 `__: > scipy.stats.mode extremely slow (Trac #905) > * `#3372 `__: Please add > Sphinx search field to online scipy html docs > * `#3678 `__: > _clough_tocher_2d_single direction between centroids > * `#4174 `__: lobpcg > "largest" option invalid? > * `#5493 `__: anderson_ksamp > p-values>1 > * `#5743 `__: slsqp fails to > detect infeasible problem > * `#6139 `__: > scipy.optimize.linprog failed to find a feasible starting point... > * `#6358 `__: stats: > docstring for `vonmises_line` points to `vonmises_line`... > * `#6498 `__: runtests.py is > missing in pypi distfile > * `#7426 `__: > scipy.stats.ksone(n).pdf(x) returns nan for positive values of... > * `#7455 `__: > scipy.stats.ksone.pdf(2,x) return incorrect values for x near... > * `#7456 `__: > scipy.special.smirnov and scipy.special.smirnovi have accuracy... > * `#7492 `__: > scipy.special.kolmogorov(x)/kolmogi(p) inefficient, inaccurate... > * `#7914 `__: TravisCI not > failing when it should for -OO run > * `#8064 `__: linalg.solve > test crashes on Windows > * `#8212 `__: LAPACK > Rectangular Full Packed routines > * `#8256 `__: > differential_evolution bug converges to wrong results in complex... > * `#8443 `__: Deprecate > `hyp2f0`, `hyp1f2`, and `hyp3f0`? > * `#8452 `__: DOC: ARPACK > tutorial has two conflicting equations > * `#8680 `__: scipy fails > compilation when building from source > * `#8686 `__: Division by > zero in _trustregion.py when x0 is exactly equal... > * `#8700 `__: _MINPACK_LOCK > not held when calling into minpack from least_squares > * `#8786 `__: erroneous > moment values for t-distribution > * `#8791 `__: Checking COLA > condition in istft should be optional (or omitted) > * `#8843 `__: imresize cannot > be deprecated just yet > * `#8844 `__: Inverse Wishart > Log PDF Incorrect for Non-diagonal Scale Matrix? > * `#8878 `__: vonmises and > vonmises_line in stats: vonmises wrong and superfluous? > * `#8895 `__: v1.1.0 > `ndi.rotate` documentation ? reused parameters not filled... > * `#8900 `__: Missing complex > conjugation in scipy.sparse.linalg.LinearOperator > * `#8904 `__: BUG: if zero > derivative at root, then Newton fails with RuntimeWarning > * `#8911 `__: > make_interp_spline bc_type incorrect input interpretation > * `#8942 `__: MAINT: Refactor > `_linprog.py` and `_linprog_ip.py` to remove... > * `#8947 `__: np.int64 in > scipy.fftpack.next_fast_len > * `#9020 `__: BUG: > linalg.subspace_angles gives wrong results > * `#9033 `__: > scipy.stats.normaltest sometimes gives incorrect returns b/c... > * `#9036 `__: Bizarre times > for `scipy.sparse.rand` function with 'low' density... > * `#9044 `__: > optimize.minimize(method=`trust-constr`) result dict does not... > * `#9071 `__: doc/linalg: add > cho_solve_banded to see also of cholesky_banded > * `#9082 `__: eigenvalue > sorting in scipy.sparse.linalg.eigsh > * `#9086 `__: > signaltools.py:491: FutureWarning: Using a non-tuple sequence... > * `#9091 `__: > test_spline_filter failure on 32-bit > * `#9122 `__: Typo on scipy > minimization tutorial > * `#9135 `__: doc error at > https://docs.scipy.org/doc/scipy/reference/tutorial/stats/discrete_poisson.html > * `#9167 `__: DOC: BUG: typo > in ndimage LowLevelCallable tutorial example > * `#9169 `__: truncnorm does > not work if b < a in scipy.stats > * `#9250 `__: > scipy.special.tests.test_mpmath::TestSystematic::test_pcfw fails... > * `#9259 `__: rv.expect() == > rv.mean() is false for rv.mean() == nan (and inf) > * `#9286 `__: DOC: Rosenbrock > expression in optimize.minimize tutorial > * `#9316 `__: SLSQP fails in > nested optimization > * `#9337 `__: > scipy.signal.find_peaks key typo in documentation > * `#9345 `__: Example from > documentation of scipy.sparse.linalg.eigs raises... > * `#9383 `__: Default value > for "mode" in "ndimage.shift" > * `#9419 `__: dual_annealing > off by one in the number of iterations > * `#9442 `__: Error in > Defintion of Rosenbrock Function > * `#9453 `__: TST: > test_eigs_consistency() doesn't have consistent results > > > Pull requests for 1.2.0 > - ----------------------- > > * `#7352 `__: ENH: add Brunner > Munzel test to scipy.stats. > * `#7373 `__: BUG: Jaccard > distance for all-zero arrays would return np.nan > * `#7374 `__: ENH: Add PDF, CDF > and parameter estimation for Stable Distributions > * `#8098 `__: ENH: Add shgo for > global optimization of NLPs. > * `#8203 `__: ENH: adding > simulated dual annealing to optimize > * `#8259 `__: Option to follow > original Storn and Price algorithm and its parallelisation > * `#8293 `__: ENH add > ratio-of-uniforms method for rv generation to scipy.stats > * `#8294 `__: BUG: Fix slowness > in stats.mode > * `#8295 `__: ENH: add Jensen > Shannon distance to `scipy.spatial.distance` > * `#8357 `__: ENH: vectorize > scalar zero-search-functions > * `#8397 `__: Add `fs=` > parameter to filter design functions > * `#8537 `__: ENH: Implement > mode parameter for spline filtering. > * `#8558 `__: ENH: small > speedup for stats.gaussian_kde > * `#8560 `__: BUG: fix p-value > calc of anderson_ksamp in scipy.stats > * `#8614 `__: ENH: correct > p-values for stats.kendalltau and stats.mstats.kendalltau > * `#8670 `__: ENH: Require > Lapack 3.4.0 > * `#8683 `__: Correcting kmeans > documentation > * `#8725 `__: MAINT: Cleanup > scipy.optimize.leastsq > * `#8726 `__: BUG: Fix > _get_output in scipy.ndimage to support string > * `#8733 `__: MAINT: stats: A > bit of clean up. > * `#8737 `__: BUG: Improve > numerical precision/convergence failures of smirnov/kolmogorov > * `#8738 `__: MAINT: stats: A > bit of clean up in test_distributions.py. > * `#8740 `__: BF/ENH: make > minpack thread safe > * `#8742 `__: BUG: Fix division > by zero in trust-region optimization methods > * `#8746 `__: MAINT: signal: > Fix a docstring of a private function, and fix... > * `#8750 `__: DOC clarified > description of norminvgauss in scipy.stats > * `#8753 `__: DOC: signal: Fix > a plot title in the chirp docstring. > * `#8755 `__: DOC: MAINT: Fix > link to the wheel documentation in developer... > * `#8760 `__: BUG: stats: > boltzmann wasn't setting the upper bound. > * `#8763 `__: [DOC] Improved > scipy.cluster.hierarchy documentation > * `#8765 `__: DOC: added > example for scipy.stat.mstats.tmin > * `#8788 `__: DOC: fix > definition of optional `disp` parameter > * `#8802 `__: MAINT: Suppress > dd_real unused function compiler warnings. > * `#8803 `__: ENH: Add > full_output support to optimize.newton() > * `#8804 `__: MAINT: stats > cleanup > * `#8808 `__: DOC: add note > about isinstance for frozen rvs > * `#8812 `__: Updated numpydoc > submodule > * `#8813 `__: MAINT: stats: Fix > multinomial docstrings, and do some clean up. > * `#8816 `__: BUG: fixed _stats > of t-distribution in scipy.stats > * `#8817 `__: BUG: ndimage: Fix > validation of the origin argument in correlate... > * `#8822 `__: BUG: integrate: > Fix crash with repeated t values in odeint. > * `#8832 `__: Hyperlink DOIs > against preferred resolver > * `#8837 `__: BUG: sparse: > Ensure correct dtype for sparse comparison operations. > * `#8839 `__: DOC: stats: A few > tweaks to the linregress docstring. > * `#8846 `__: BUG: stats: Fix > logpdf method of invwishart. > * `#8849 `__: DOC: signal: > Fixed mistake in the firwin docstring. > * `#8854 `__: DOC: fix type > descriptors in ltisys documentation > * `#8865 `__: Fix tiny typo in > docs for chi2 pdf > * `#8870 `__: Fixes related to > invertibility of STFT > * `#8872 `__: ENH: special: Add > the softmax function > * `#8874 `__: DOC correct gamma > function in docstrings in scipy.stats > * `#8876 `__: ENH: Added TOMS > Algorithm 748 as 1-d root finder; 17 test function... > * `#8882 `__: ENH: Only use > Halley's adjustment to Newton if close enough. > * `#8883 `__: FIX: optimize: > make jac and hess truly optional for 'trust-constr' > * `#8885 `__: TST: Do not error > on warnings raised about non-tuple indexing. > * `#8887 `__: MAINT: filter out > np.matrix PendingDeprecationWarning's in numpy... > * `#8889 `__: DOC: optimize: > separate legacy interfaces from new ones > * `#8890 `__: ENH: Add > optimize.root_scalar() as a universal dispatcher for... > * `#8899 `__: DCT-IV, DST-IV > and DCT-I, DST-I orthonormalization support in... > * `#8901 `__: MAINT: Reorganize > flapack.pyf.src file > * `#8907 `__: BUG: ENH: Check > if guess for newton is already zero before checking... > * `#8908 `__: ENH: Make sorting > optional for cKDTree.query_ball_point() > * `#8910 `__: DOC: > sparse.csgraph simple examples. > * `#8914 `__: DOC: interpolate: > fix equivalences of string aliases > * `#8918 `__: add > float_control(precise, on) to _fpumode.c > * `#8919 `__: MAINT: > interpolate: improve error messages for common `bc_type`... > * `#8920 `__: DOC: update > Contributing to SciPy to say "prefer no PEP8 only... > * `#8924 `__: MAINT: special: > deprecate `hyp2f0`, `hyp1f2`, and `hyp3f0` > * `#8927 `__: MAINT: special: > remove `errprint` > * `#8932 `__: Fix broadcasting > scale arg of entropy > * `#8936 `__: Fix (some) > non-tuple index warnings > * `#8937 `__: ENH: implement > sparse matrix BSR to CSR conversion directly. > * `#8938 `__: DOC: add > @_ni_docstrings.docfiller in ndimage.rotate > * `#8940 `__: Update > _discrete_distns.py > * `#8943 `__: DOC: Finish > dangling sentence in `convolve` docstring > * `#8944 `__: MAINT: Address > tuple indexing and warnings > * `#8945 `__: ENH: > spatial.transform.Rotation [GSOC2018] > * `#8950 `__: csgraph Dijkstra > function description rewording > * `#8953 `__: DOC, MAINT: HTTP > -> HTTPS, and other linkrot fixes > * `#8955 `__: BUG: np.int64 in > scipy.fftpack.next_fast_len > * `#8958 `__: MAINT: Add more > descriptive error message for phase one simplex. > * `#8962 `__: BUG: > sparse.linalg: add missing conjugate to _ScaledLinearOperator.adjoint > * `#8963 `__: BUG: > sparse.linalg: downgrade LinearOperator TypeError to warning > * `#8965 `__: ENH: Wrapped RFP > format and RZ decomposition routines > * `#8969 `__: MAINT: doc and > code fixes for optimize.newton > * `#8970 `__: Added 'average' > keyword for welch/csd to enable median averaging > * `#8971 `__: Better imresize > deprecation warning > * `#8972 `__: MAINT: Switch > np.where(c) for np.nonzero(c) > * `#8975 `__: MAINT: Fix > warning-based failures > * `#8979 `__: DOC: fix > description of count_sort keyword of dendrogram > * `#8982 `__: MAINT: optimize: > Fixed minor mistakes in test_linprog.py (#8978) > * `#8984 `__: BUG: > sparse.linalg: ensure expm casts integer inputs to float > * `#8986 `__: BUG: > optimize/slsqp: do not exit with convergence on steps where... > * `#8989 `__: MAINT: use > collections.abc in basinhopping > * `#8990 `__: ENH extend > p-values of anderson_ksamp in scipy.stats > * `#8991 `__: ENH: Weighted kde > * `#8993 `__: ENH: > spatial.transform.Rotation.random [GSOC 2018] > * `#8994 `__: ENH: > spatial.transform.Slerp [GSOC 2018] > * `#8995 `__: TST: time.time in > test > * `#9007 `__: Fix typo in > fftpack.rst > * `#9013 `__: Added correct > plotting code for two sided output from spectrogram > * `#9014 `__: BUG: > differential_evolution with inf objective functions > * `#9017 `__: BUG: fixed #8446 > corner case for asformat(array|dense) > * `#9018 `__: MAINT: > _lib/ccallback: remove unused code > * `#9021 `__: BUG: Issue with > subspace_angles > * `#9022 `__: DOC: Added "See > Also" section to lombscargle docstring > * `#9034 `__: BUG: Fix > tolerance printing behavior, remove meaningless tol... > * `#9035 `__: TST: improve > signal.bsplines test coverage > * `#9037 `__: ENH: add a new > init method for k-means > * `#9039 `__: DOC: Add examples > to fftpack.irfft docstrings > * `#9048 `__: ENH: > scipy.sparse.random > * `#9050 `__: BUG: > scipy.io.hb_write: fails for matrices not in csc format > * `#9051 `__: MAINT: Fix slow > sparse.rand for k < mn/3 (#9036). > * `#9054 `__: MAINT: spatial: > Explicitly initialize LAPACK output parameters. > * `#9055 `__: DOC: Add examples > to scipy.special docstrings > * `#9056 `__: ENH: Use one > thread in OpenBLAS > * `#9059 `__: DOC: Update > README with link to Code of Conduct > * `#9060 `__: BLD: remove > support for the Bento build system. > * `#9062 `__: DOC add sections > to overview in scipy.stats > * `#9066 `__: BUG: Correct > "remez" error message > * `#9069 `__: DOC: update > linalg section of roadmap for LAPACK versions. > * `#9079 `__: MAINT: add > spatial.transform to refguide check; complete some... > * `#9081 `__: MAINT: Add > warnings if pivot value is close to tolerance in linprog(method='simplex') > * `#9084 `__: BUG fix incorrect > p-values of kurtosistest in scipy.stats > * `#9095 `__: DOC: add sections > to mstats overview in scipy.stats > * `#9096 `__: BUG: Add test for > Stackoverflow example from issue 8174. > * `#9101 `__: ENH: add Siegel > slopes (robust regression) to scipy.stats > * `#9105 `__: allow > resample_poly() to output float32 for float32 inputs. > * `#9112 `__: MAINT: optimize: > make trust-constr accept constraint dict (#9043) > * `#9118 `__: Add doc entry to > cholesky_banded > * `#9120 `__: eigsh > documentation parameters > * `#9125 `__: interpolative: > correctly reconstruct full rank matrices > * `#9126 `__: MAINT: Use > warnings for unexpected peak properties > * `#9129 `__: BUG: Do not catch > and silence KeyboardInterrupt > * `#9131 `__: DOC: Correct the > typo in scipy.optimize tutorial page > * `#9133 `__: FIX: Avoid use of > bare except > * `#9134 `__: DOC: Update of > 'return_eigenvectors' description > * `#9137 `__: DOC: typo fixes > for discrete Poisson tutorial > * `#9139 `__: FIX: Doctest > failure in optimize tutorial > * `#9143 `__: DOC: missing > sigma in Pearson r formula > * `#9145 `__: MAINT: Refactor > linear programming solvers > * `#9149 `__: FIX: Make > scipy.odr.ODR ifixx equal to its data.fix if given > * `#9156 `__: DOC: special: > Mention the sigmoid function in the expit docstring. > * `#9160 `__: Fixed a latex > delimiter error in levy() > * `#9170 `__: DOC: correction / > update of docstrings of distributions in scipy.stats > * `#9171 `__: better > description of the hierarchical clustering parameter > * `#9174 `__: domain check for > a < b in stats.truncnorm > * `#9175 `__: DOC: Minor > grammar fix > * `#9176 `__: BUG: > CloughTocher2DInterpolator: fix miscalculation at neighborless... > * `#9177 `__: BUILD: Document > the "clean" target in the doc/Makefile. > * `#9178 `__: MAINT: make > refguide-check more robust for printed numpy arrays > * `#9186 `__: MAINT: Remove > np.ediff1d occurence > * `#9188 `__: DOC: correct typo > in extending ndimage with C > * `#9190 `__: ENH: Support > specifying axes for fftconvolve > * `#9192 `__: MAINT: optimize: > fixed @pv style suggestions from #9112 > * `#9200 `__: Fix > make_interp_spline(..., k=0 or 1, axis<0) > * `#9201 `__: BUG: > sparse.linalg/gmres: use machine eps in breakdown check > * `#9204 `__: MAINT: fix up > stats.spearmanr and match mstats.spearmanr with... > * `#9206 `__: MAINT: include > benchmarks and dev files in sdist. > * `#9208 `__: TST: signal: bump > bsplines test tolerance for complex data > * `#9210 `__: TST: mark tests > as slow, fix missing random seed > * `#9211 `__: ENH: add > capability to specify orders in pade func > * `#9217 `__: MAINT: Include > ``success`` and ``nit`` in OptimizeResult returned... > * `#9222 `__: ENH: interpolate: > Use scipy.spatial.distance to speed-up Rbf > * `#9229 `__: MNT: Fix Fourier > filter double case > * `#9233 `__: BUG: > spatial/distance: fix pdist/cdist performance regression... > * `#9234 `__: FIX: Proper > suppression > * `#9235 `__: BENCH: > rationalize slow benchmarks + miscellaneous fixes > * `#9238 `__: BENCH: limit > number of parameter combinations in spatial.*KDTree... > * `#9239 `__: DOC: stats: Fix > LaTeX markup of a couple distribution PDFs. > * `#9241 `__: ENH: Evaluate > plateau size during peak finding > * `#9242 `__: ENH: stats: > Implement _ppf and _logpdf for crystalball, and do... > * `#9246 `__: DOC: Properly > render versionadded directive in HTML documentation > * `#9255 `__: DOC: mention > RootResults in optimization reference guide > * `#9260 `__: TST: relax some > tolerances so tests pass with x87 math > * `#9264 `__: TST Use > assert_raises "match" parameter instead of the "message"... > * `#9267 `__: DOC: clarify > expect() return val when moment is inf/nan > * `#9272 `__: DOC: Add > description of default bounds to linprog > * `#9277 `__: MAINT: > sparse/linalg: make test deterministic > * `#9278 `__: MAINT: > interpolate: pep8 cleanup in test_polyint > * `#9279 `__: Fixed docstring > for resample > * `#9280 `__: removed first > check for float in get_sum_dtype > * `#9281 `__: BUG: only accept > 1d input for bartlett / levene in scipy.stats > * `#9282 `__: MAINT: > dense_output and t_eval are mutually exclusive inputs > * `#9283 `__: MAINT: add docs > and do some cleanups in interpolate.Rbf > * `#9288 `__: Run > distance_transform_edt tests on all types > * `#9294 `__: DOC: fix the > formula typo > * `#9298 `__: MAINT: > optimize/trust-constr: restore .niter attribute for backward-compat > * `#9299 `__: DOC: > clarification of default rvs method in scipy.stats > * `#9301 `__: MAINT: removed > unused import sys > * `#9302 `__: MAINT: removed > unused imports > * `#9303 `__: DOC: signal: > Refer to fs instead of nyq in the firwin docstring. > * `#9305 `__: ENH: Added > Yeo-Johnson power transformation > * `#9306 `__: ENH - add dual > annealing > * `#9309 `__: ENH add the > yulesimon distribution to scipy.stats > * `#9317 `__: Nested SLSQP bug > fix. > * `#9320 `__: MAINT: stats: > avoid underflow in stats.geom.ppf > * `#9326 `__: Add example for > Rosenbrock function > * `#9332 `__: Sort file lists > * `#9340 `__: Fix typo in > find_peaks documentation > * `#9343 `__: MAINT Use np.full > when possible > * `#9344 `__: DOC: added > examples to docstring of dirichlet class > * `#9346 `__: DOC: Fix import > of scipy.sparse.linalg in example (#9345) > * `#9350 `__: Fix interpolate > read only > * `#9351 `__: MAINT: > special.erf: use the x->-x symmetry > * `#9356 `__: Fix documentation > typo > * `#9358 `__: DOC: improve doc > for ksone and kstwobign in scipy.stats > * `#9362 `__: DOC: Change > datatypes of A matrices in linprog > * `#9364 `__: MAINT: Adds > implicit none to fftpack fortran sources > * `#9369 `__: DOC: minor tweak > to CoC (updated NumFOCUS contact address). > * `#9373 `__: Fix exception if > python is called with -OO option > * `#9374 `__: FIX: AIX > compilation issue with NAN and INFINITY > * `#9376 `__: COBLYA -> COBYLA > in docs > * `#9377 `__: DOC: Add examples > integrate: fixed_quad and quadrature > * `#9379 `__: MAINT: TST: Make > tests NumPy 1.8 compatible > * `#9385 `__: CI: On Travis > matrix "OPTIMIZE=-OO" flag ignored > * `#9387 `__: Fix defaut value > for 'mode' in 'ndimage.shift' in the doc > * `#9392 `__: BUG: rank has to > be integer in rank_filter: fixed issue 9388 > * `#9399 `__: DOC: Misc. typos > * `#9400 `__: TST: stats: Fix > the expected r-value of a linregress test. > * `#9405 `__: BUG: np.hstack > does not accept generator expressions > * `#9408 `__: ENH: linalg: > Shorter ill-conditioned warning message > * `#9418 `__: DOC: Fix ndimage > docstrings and reduce doc build warnings > * `#9421 `__: DOC: Add missing > docstring examples in scipy.spatial > * `#9422 `__: DOC: Add an > example to integrate.newton_cotes > * `#9427 `__: BUG: Fixed defect > with maxiter #9419 in dual annealing > * `#9431 `__: BENCH: Add dual > annealing to scipy benchmark (see #9415) > * `#9435 `__: DOC: Add > docstring examples for stats.binom_test > * `#9443 `__: DOC: Fix the > order of indices in optimize tutorial > * `#9444 `__: MAINT: > interpolate: use operator.index for checking/coercing... > * `#9445 `__: DOC: Added > missing example to stats.mstats.kruskal > * `#9446 `__: DOC: Add note > about version changed for jaccard distance > * `#9447 `__: BLD: > version-script handling in setup.py > * `#9448 `__: TST: skip a > problematic linalg test > * `#9449 `__: TST: fix missing > seed in lobpcg test. > * `#9456 `__: TST: > test_eigs_consistency() now sorts output > > Checksums > ========= > > MD5 > ~~~ > > 47d309402d2e5574be8fa261fadfaf58 > scipy-1.2.0rc1-cp27-cp27m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl > 911dfde5be66403c07c60e19aa631dc2 > scipy-1.2.0rc1-cp27-cp27m-manylinux1_i686.whl > a693189336365595b42b0d93f825b826 > scipy-1.2.0rc1-cp27-cp27m-manylinux1_x86_64.whl > ec5abd33480761ed9701f7fd2274fc47 scipy-1.2.0rc1-cp27-cp27m-win32.whl > bc3d40311f057b12f8fea97166ef8112 scipy-1.2.0rc1-cp27-cp27m-win_amd64.whl > 33848233e6438b1ff9183d8a4794daed > scipy-1.2.0rc1-cp27-cp27mu-manylinux1_i686.whl > c2cb1166ce0071e1fe42ed1c3e60b75e > scipy-1.2.0rc1-cp27-cp27mu-manylinux1_x86_64.whl > a04b5a758f555e05e6431b8a1f035888 > scipy-1.2.0rc1-cp34-cp34m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl > ad511246d0742cf0669fedf292cc01bb > scipy-1.2.0rc1-cp34-cp34m-manylinux1_i686.whl > 15aa08ef43a6c5cb320bc015f01087ad > scipy-1.2.0rc1-cp34-cp34m-manylinux1_x86_64.whl > 86a59b81a3e6894d9054139311a2c51f scipy-1.2.0rc1-cp34-cp34m-win32.whl > 8b6e33253579916ea873c45989ee5bea scipy-1.2.0rc1-cp34-cp34m-win_amd64.whl > db7a4de02828471bf9f800814ff68627 > scipy-1.2.0rc1-cp35-cp35m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl > c296b6270d29d3ec6dafddf8ceae67fb > scipy-1.2.0rc1-cp35-cp35m-manylinux1_i686.whl > 3ba7a825f61822128d960fa728010e51 > scipy-1.2.0rc1-cp35-cp35m-manylinux1_x86_64.whl > c083c8287da110b707d181f6638ce122 scipy-1.2.0rc1-cp35-cp35m-win32.whl > 2242eac92681085258535ed96bd040d7 scipy-1.2.0rc1-cp35-cp35m-win_amd64.whl > d5c238903c00e91a40d56023f1a27ed4 > scipy-1.2.0rc1-cp36-cp36m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl > e8ab7487a9a53b86a6510772c45af787 > scipy-1.2.0rc1-cp36-cp36m-manylinux1_i686.whl > 9991b5958d736488bef638eea463945d > scipy-1.2.0rc1-cp36-cp36m-manylinux1_x86_64.whl > 9c108a9d7e967b8c9a5e5143b1a15b40 scipy-1.2.0rc1-cp36-cp36m-win32.whl > 54d63041f0315d341d9ffb028a98e767 scipy-1.2.0rc1-cp36-cp36m-win_amd64.whl > 534276c864ab3139811561c022608cc3 > scipy-1.2.0rc1-cp37-cp37m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl > 4bd26c179a10891087bd81a658573683 > scipy-1.2.0rc1-cp37-cp37m-manylinux1_i686.whl > 1a3170b4f1df42f28efbe197e54eb9a3 > scipy-1.2.0rc1-cp37-cp37m-manylinux1_x86_64.whl > 72b89f7e2c1d13dc8dbb21600fb184da scipy-1.2.0rc1-cp37-cp37m-win32.whl > 433ef294c4a015da0a6e0f063289a658 scipy-1.2.0rc1-cp37-cp37m-win_amd64.whl > 83abb1befce326916e0435d428b36e62 scipy-1.2.0rc1.tar.gz > 21b7570fb577543807feb4b4c1fdad8a scipy-1.2.0rc1.tar.xz > 11221dc23e0d3b316b5564f2f435aaf1 scipy-1.2.0rc1.zip > > SHA256 > ~~~~~~ > > a3282027743e89d5fcb6cd7a9e4ecdbbde61bf8126fd19683e97b69f5f6a2163 > scipy-1.2.0rc1-cp27-cp27m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl > 8b8841e03620d4d704f4efd3daed575e23a6272ae9c9be2c4cc751febee984f7 > scipy-1.2.0rc1-cp27-cp27m-manylinux1_i686.whl > 254ea2f7f3c5afef9f02c0192d2dbd8f5336c1b1c53efae7ef64a8880cccc299 > scipy-1.2.0rc1-cp27-cp27m-manylinux1_x86_64.whl > d449832419df3e37a3942778b46c140fd61d1e4f38f9e34bed278a77aacdbd31 > scipy-1.2.0rc1-cp27-cp27m-win32.whl > e57f3e3eaa88cd7bc93466122fca48c36863e03aeb24f9d570a2e6b2ea3cbf92 > scipy-1.2.0rc1-cp27-cp27m-win_amd64.whl > 00dcb606101fa10951ee235af69dbff55d999b01c9bb2bc0f64df5fc3aff4eb6 > scipy-1.2.0rc1-cp27-cp27mu-manylinux1_i686.whl > 38857eb49f7e38d3ec079772225a79235d0bd847e24d2fa8c9a9fa70ee69f0a2 > scipy-1.2.0rc1-cp27-cp27mu-manylinux1_x86_64.whl > 9b9950278f36c4e7779148cc9a719d41a305024c70005f994412845172ade346 > scipy-1.2.0rc1-cp34-cp34m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl > c8a2fc15c64f1b162b02f86d28153b65f64720ca64e832bcf5bfae060a507949 > scipy-1.2.0rc1-cp34-cp34m-manylinux1_i686.whl > 4e205e0e5e88fe2105c594a706ac9fa558fe7a4daa2bef2c86b343ab507d8bd6 > scipy-1.2.0rc1-cp34-cp34m-manylinux1_x86_64.whl > b04fb8ba796198d83614138d7f96e88791d83f5f4e31e628cce51fda1a092f66 > scipy-1.2.0rc1-cp34-cp34m-win32.whl > c34e4ce9a8c62c85f322d7897a257a839a4bb7fd94e08701044e9b1cc1bb15a6 > scipy-1.2.0rc1-cp34-cp34m-win_amd64.whl > cb7f4c289c06514c6e224263868a98d5e6aa6e8a90f2304b16ff276aa96030ce > scipy-1.2.0rc1-cp35-cp35m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl > dcaeed34e7e965e935ba252fd3290c04cafb7d84f6f44c9c08269504aa2e0a05 > scipy-1.2.0rc1-cp35-cp35m-manylinux1_i686.whl > 13b234b4fbda1368474a667fc29e8365b622c4c607ed490f00643625c8f50cca > scipy-1.2.0rc1-cp35-cp35m-manylinux1_x86_64.whl > 073560d6598b97b8f214a31856a1d43c96701b46c5cc9805789f962c3b8a0e97 > scipy-1.2.0rc1-cp35-cp35m-win32.whl > 600cf596b83f185dca3455d03ca802de0b4de98cb4c8d041226089d78d04c2bc > scipy-1.2.0rc1-cp35-cp35m-win_amd64.whl > 77b7ed8e13f03a843d2f11bd140f224abe62fb56656f35348578e3838ff4d528 > scipy-1.2.0rc1-cp36-cp36m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl > 98786b516d1955592f921c2b36505840ff921c9e82f5c28a6c2a580fb3e96af1 > scipy-1.2.0rc1-cp36-cp36m-manylinux1_i686.whl > 8f62fc6ac6b842d7c3c499269150ec81d26a0dea5ce818aef3b0e9e14e53c5c7 > scipy-1.2.0rc1-cp36-cp36m-manylinux1_x86_64.whl > 213cfc35ec2fbf86c5957d1ada99a1fe1eacccdb498d4790089af9cf50cadab4 > scipy-1.2.0rc1-cp36-cp36m-win32.whl > 287e46f87399eb9897c726c6d358c893f6c769300599bc5da95cbf3397a00aa7 > scipy-1.2.0rc1-cp36-cp36m-win_amd64.whl > 7116d193da4baca6f7cd1cd7810548fa03ed4a06e05f325978b2f0018b05ead9 > scipy-1.2.0rc1-cp37-cp37m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl > 9cd3fe767225b0dcfcc9f09ed18288b51c29b35ca16dc4e5a6f3587b4ac7d7b5 > scipy-1.2.0rc1-cp37-cp37m-manylinux1_i686.whl > 4024aea96a01ca05af701f93fd227a7f646258116903899a75b1f4a1f0134bf8 > scipy-1.2.0rc1-cp37-cp37m-manylinux1_x86_64.whl > eccd0e6d321585b6e2ee18fa0ee1db4fe042e52fb4ae8e28a3d223df6bcd6a8e > scipy-1.2.0rc1-cp37-cp37m-win32.whl > 96f6c69b2d8f63dad5612385521d0cf8b62f665a62f56b6b3d3fb7042a63c34c > scipy-1.2.0rc1-cp37-cp37m-win_amd64.whl > ca9ba36bb271dcb4273e330c0bd418a1c3566ff76248dd634efecbe0e9c1721c > scipy-1.2.0rc1.tar.gz > b8fe757f377b43c733a0ba235b990fb4b3722bd6f5930a26359d16752e94560c > scipy-1.2.0rc1.tar.xz > da1980e7e037e2275821d7611a91eadafdc157b096f36f41d05cc0ea4ae539bc > scipy-1.2.0rc1.zip > -----BEGIN PGP SIGNATURE----- > > iQIzBAEBCAAdFiEEgfAqrOuERrV4fwr6XCLdIy4FKasFAlv8LB8ACgkQXCLdIy4F > KauhWw//cFUboxtuNZeEh98Pn2mfVIqRF8hc6VK7jeXU64qiAdOnbBRKXfoXWpbt > 8fEckTFVVt2CQzIEZju429P0eWv8psfvn90cNnj5VHz7h46AH5gQee/cfP1kNWGO > mxcYczqZN8+ldDnww4hfk0R+3IrpfmQbVSMEqBF84uottfgUjUzPtcFHJmmmcOF2 > 7XWhAP5IWMctcwq3r3WAa8yLUmlEIB3Fs9mPPr1We7e0QiXnEueUrXVZF9Oz3UpJ > UFiTwX5nxnNdxZJwtLbBXhxJUbvPnooby0x1NwxFG6AwrWaPG3my0e9kIzpwqfsf > 0B7Pt/xPEHWIizaqMyfUiaS7FZOUfvq6xs5aCyQeP9Wtnwherm6SQ/Qs+LFSb8E2 > 9cgyFmaBeslrTMd3f1YMcb6d1hmNSjbBmWccZEXCqjC9UClxbAQDHDcdmTl+4vp7 > xATCxWkYVP9lOLH5TtIC1Bo0AZXiOxI3JnojQS65JH0w4unh1IJJkENurzCATh4/ > vnyddy0x2e1ok5bX8fpVFrCc8lSdO8aDY5cYEU55XZhkyroet3IaOYqwPzPQPwoJ > QgYEsqxa2Urn0faV5uuDFTscnCAHK0EVXhr3yyL0YoIGOPffM8JaswEAUaFwLrq0 > KEbOavdImtSwqL9v6x5tDyYXh/mHQ70GGtPS68iSc1NexRrwLAw= > =F/+Z > -----END PGP SIGNATURE----- > > > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at python.org > https://mail.python.org/mailman/listinfo/numpy-discussion > -------------- next part -------------- An HTML attachment was scrubbed... URL: From abhinav.nanhey at gmail.com Mon Nov 26 16:22:38 2018 From: abhinav.nanhey at gmail.com (Abhinav Gautam) Date: Tue, 27 Nov 2018 02:52:38 +0530 Subject: [SciPy-Dev] [Numpy-discussion] ANN: SciPy 1.2.0rc1 -- please test In-Reply-To: References: Message-ID: Congratulations ? On Tue, Nov 27, 2018, 02:48 Charles R Harris wrote: > Congratulations on your first release. May there be many more :) > > Chuck > > On Mon, Nov 26, 2018 at 11:48 AM Tyler Reddy > wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA256 >> >> Hi all, >> >> On behalf of the SciPy development team I'm pleased to announce >> the release candidate SciPy 1.2.0rc1. Please help us test out this >> release candidate -- the 1.2.x series will be an LTS release and the >> last to support Python 2.7. >> >> Sources and binary wheels can be found at: >> https://pypi.python.org/pypi/scipy >> and at: >> https://github.com/scipy/scipy/releases/tag/v1.2.0rc1 >> >> To install the release candidate with pip: >> >> pip install scipy==1.2.0rc1 >> >> >> ========================== >> SciPy 1.2.0 Release Notes >> ========================== >> >> Note: Scipy 1.2.0 is not released yet! >> >> SciPy 1.2.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. Before upgrading, we recommend that users check that >> their own code does not use deprecated SciPy functionality (to do so, >> run your code with ``python -Wd`` and check for ``DeprecationWarning`` s). >> Our development attention will now shift to bug-fix releases on the >> 1.2.x branch, and on adding new features on the master branch. >> >> This release requires Python 2.7 or 3.4+ and NumPy 1.8.2 or greater. >> >> Note: This will be the last SciPy release to support Python 2.7. >> Consequently, the 1.2.x series will be a long term support (LTS) >> release; we will backport bug fixes until 1 Jan 2020. >> >> For running on PyPy, PyPy3 6.0+ and NumPy 1.15.0 are required. >> >> Highlights of this release >> ---------------------------- >> >> - - 1-D root finding improvements with a new solver, ``toms748``, and a >> new >> unified interface, ``root_scalar`` >> - - New ``dual_annealing`` optimization method that combines stochastic >> and >> local deterministic searching >> - - A new optimization algorithm, ``shgo`` (simplicial homology >> global optimization) for derivative free optimization problems >> - - A new category of quaternion-based transformations are available in >> `scipy.spatial.transform` >> >> New features >> ============ >> >> `scipy.ndimage` improvements >> - -------------------------------- >> >> Proper spline coefficient calculations have been added for the ``mirror``, >> ``wrap``, and ``reflect`` modes of `scipy.ndimage.rotate` >> >> `scipy.fftpack` improvements >> - -------------------------------- >> >> DCT-IV, DST-IV, DCT-I, and DST-I orthonormalization are now supported in >> `scipy.fftpack`. >> >> `scipy.interpolate` improvements >> - -------------------------------- >> >> `scipy.interpolate.pade` now accepts a new argument for the order of the >> numerator >> >> `scipy.cluster` improvements >> - ---------------------------- >> >> `scipy.cluster.vq.kmeans2` gained a new initialization method, kmeans++. >> >> `scipy.special` improvements >> - ---------------------------- >> >> The function ``softmax`` was added to `scipy.special`. >> >> `scipy.optimize` improvements >> - ----------------------------- >> >> The one-dimensional nonlinear solvers have been given a unified interface >> `scipy.optimize.root_scalar`, similar to the `scipy.optimize.root` >> interface >> for multi-dimensional solvers. ``scipy.optimize.root_scalar(f, bracket=[a >> ,b], >> method="brenth")`` is equivalent to ``scipy.optimize.brenth(f, a ,b)``. >> If no >> ``method`` is specified, an appropriate one will be selected based upon >> the >> bracket and the number of derivatives available. >> >> The so-called Algorithm 748 of Alefeld, Potra and Shi for root-finding >> within >> an enclosing interval has been added as `scipy.optimize.toms748`. This >> provides >> guaranteed convergence to a root with convergence rate per function >> evaluation >> of approximately 1.65 (for sufficiently well-behaved functions.) >> >> ``differential_evolution`` now has the ``updating`` and ``workers`` >> keywords. >> The first chooses between continuous updating of the best solution vector >> (the >> default), or once per generation. Continuous updating can lead to faster >> convergence. The ``workers`` keyword accepts an ``int`` or map-like >> callable, >> and parallelises the solver (having the side effect of updating once per >> generation). Supplying an ``int`` evaluates the trial solutions in N >> parallel >> parts. Supplying a map-like callable allows other parallelisation >> approaches >> (such as ``mpi4py``, or ``joblib``) to be used. >> >> ``dual_annealing`` (and ``shgo`` below) is a powerful new general purpose >> global optizimation (GO) algorithm. ``dual_annealing`` uses two annealing >> processes to accelerate the convergence towards the global minimum of an >> objective mathematical function. The first annealing process controls the >> stochastic Markov chain searching and the second annealing process >> controls the >> deterministic minimization. So, dual annealing is a hybrid method that >> takes >> advantage of stochastic and local deterministic searching in an efficient >> way. >> >> ``shgo`` (simplicial homology global optimization) is a similar algorithm >> appropriate for solving black box and derivative free optimization (DFO) >> problems. The algorithm generally converges to the global solution in >> finite >> time. The convergence holds for non-linear inequality and >> equality constraints. In addition to returning a global minimum, the >> algorithm also returns any other global and local minima found after every >> iteration. This makes it useful for exploring the solutions in a domain. >> >> `scipy.optimize.newton` can now accept a scalar or an array >> >> ``MINPACK`` usage is now thread-safe, such that ``MINPACK`` + callbacks >> may >> be used on multiple threads. >> >> `scipy.signal` improvements >> - --------------------------- >> >> Digital filter design functions now include a parameter to specify the >> sampling >> rate. Previously, digital filters could only be specified using normalized >> frequency, but different functions used different scales (e.g. 0 to 1 for >> ``butter`` vs 0 to ? for ``freqz``), leading to errors and confusion. >> With >> the ``fs`` parameter, ordinary frequencies can now be entered directly >> into >> functions, with the normalization handled internally. >> >> ``find_peaks`` and related functions no longer raise an exception if the >> properties of a peak have unexpected values (e.g. a prominence of 0). A >> ``PeakPropertyWarning`` is given instead. >> >> The new keyword argument ``plateau_size`` was added to ``find_peaks``. >> ``plateau_size`` may be used to select peaks based on the length of the >> flat top of a peak. >> >> ``welch()`` and ``csd()`` methods in `scipy.signal` now support >> calculation >> of a median average PSD, using ``average='mean'`` keyword >> >> `scipy.sparse` improvements >> - --------------------------- >> >> The `scipy.sparse.bsr_matrix.tocsr` method is now implemented directly >> instead >> of converting via COO format, and the `scipy.sparse.bsr_matrix.tocsc` >> method >> is now also routed via CSR conversion instead of COO. The efficiency of >> both >> conversions is now improved. >> >> The issue where SuperLU or UMFPACK solvers crashed on matrices with >> non-canonical format in `scipy.sparse.linalg` was fixed. The solver >> wrapper >> canonicalizes the matrix if necessary before calling the SuperLU or >> UMFPACK >> solver. >> >> The ``largest`` option of `scipy.sparse.linalg.lobpcg()` was fixed to have >> a correct (and expected) behavior. The order of the eigenvalues was made >> consistent with the ARPACK solver (``eigs()``), i.e. ascending for the >> smallest eigenvalues, and descending for the largest eigenvalues. >> >> The `scipy.sparse.random` function is now faster and also supports >> integer and >> complex values by passing the appropriate value to the ``dtype`` argument. >> >> `scipy.spatial` improvements >> - ---------------------------- >> >> The function `scipy.spatial.distance.jaccard` was modified to return 0 >> instead >> of ``np.nan`` when two all-zero vectors are compared. >> >> Support for the Jensen Shannon distance, the square-root of the >> divergence, has >> been added under `scipy.spatial.distance.jensenshannon` >> >> An optional keyword was added to the function >> `scipy.spatial.cKDTree.query_ball_point()` to sort or not sort the >> returned >> indices. Not sorting the indices can speed up calls. >> >> A new category of quaternion-based transformations are available in >> `scipy.spatial.transform`, including spherical linear interpolation of >> rotations (``Slerp``), conversions to and from quaternions, Euler angles, >> and general rotation and inversion capabilities >> (`spatial.transform.Rotation`), and uniform random sampling of 3D >> rotations (`spatial.transform.Rotation.random`). >> >> `scipy.stats` improvements >> - -------------------------- >> >> The Yeo-Johnson power transformation is now supported (``yeojohnson``, >> ``yeojohnson_llf``, ``yeojohnson_normmax``, ``yeojohnson_normplot``). >> Unlike >> the Box-Cox transformation, the Yeo-Johnson transformation can accept >> negative >> values. >> >> Added a general method to sample random variates based on the density >> only, in >> the new function ``rvs_ratio_uniforms``. >> >> The Yule-Simon distribution (``yulesimon``) was added -- this is a new >> discrete probability distribution. >> >> ``stats`` and ``mstats`` now have access to a new regression method, >> ``siegelslopes``, a robust linear regression algorithm >> >> `scipy.stats.gaussian_kde` now has the ability to deal with weighted >> samples, >> and should have a modest improvement in performance >> >> Levy Stable Parameter Estimation, PDF, and CDF calculations are now >> supported >> for `scipy.stats.levy_stable`. >> >> The Brunner-Munzel test is now available as ``brunnermunzel`` in ``stats`` >> and ``mstats`` >> >> `scipy.linalg` improvements >> - -------------------------- >> >> `scipy.linalg.lapack` now exposes the LAPACK routines using the >> Rectangular >> Full Packed storage (RFP) for upper triangular, lower triangular, >> symmetric, >> or Hermitian matrices; the upper trapezoidal fat matrix RZ decomposition >> routines are now available as well. >> >> Deprecated features >> =================== >> The functions ``hyp2f0``, ``hyp1f2`` and ``hyp3f0`` in ``scipy.special`` >> have >> been deprecated. >> >> >> Backwards incompatible changes >> ============================== >> >> LAPACK version 3.4.0 or later is now required. Building with >> Apple Accelerate is no longer supported. >> >> The function ``scipy.linalg.subspace_angles(A, B)`` now gives correct >> results for all angles. Before this, the function only returned >> correct values for those angles which were greater than pi/4. >> >> Support for the Bento build system has been removed. Bento has not been >> maintained for several years, and did not have good Python 3 or wheel >> support, >> hence it was time to remove it. >> >> The required signature of `scipy.optimize.lingprog` ``method=simplex`` >> callback function has changed. Before iteration begins, the simplex solver >> first converts the problem into a standard form that does not, in general, >> have the same variables or constraints >> as the problem defined by the user. Previously, the simplex solver would >> pass a >> user-specified callback function several separate arguments, such as the >> current solution vector ``xk``, corresponding to this standard form >> problem. >> Unfortunately, the relationship between the standard form problem and the >> user-defined problem was not documented, limiting the utility of the >> information passed to the callback function. >> >> In addition to numerous bug fix changes, the simplex solver now passes a >> user-specified callback function a single ``OptimizeResult`` object >> containing >> information that corresponds directly to the user-defined problem. In >> future >> releases, this ``OptimizeResult`` object may be expanded to include >> additional >> information, such as variables corresponding to the standard-form problem >> and >> information concerning the relationship between the standard-form and >> user-defined problems. >> >> The implementation of `scipy.sparse.random` has changed, and this affects >> the >> numerical values returned for both ``sparse.random`` and ``sparse.rand`` >> for >> some matrix shapes and a given seed. >> >> `scipy.optimize.newton` will no longer use Halley's method in cases where >> it >> negatively impacts convergence >> >> Other changes >> ============= >> >> >> Authors >> ======= >> >> * @endolith >> * @luzpaz >> * Hameer Abbasi + >> * akahard2dj + >> * Anton Akhmerov >> * Joseph Albert >> * alexthomas93 + >> * ashish + >> * atpage + >> * Blair Azzopardi + >> * Yoshiki V?zquez Baeza >> * Bence Bagi + >> * Christoph Baumgarten >> * Lucas Bellomo + >> * BH4 + >> * Aditya Bharti >> * Max Bolingbroke >> * Fran?ois Boulogne >> * Ward Bradt + >> * Matthew Brett >> * Evgeni Burovski >> * Rafa? Byczek + >> * Alfredo Canziani + >> * CJ Carey >> * Luc?a Cheung + >> * Poom Chiarawongse + >> * Jeanne Choo + >> * Robert Cimrman >> * Graham Clenaghan + >> * cynthia-rempel + >> * Johannes Damp + >> * Jaime Fernandez del Rio >> * Dowon + >> * emmi474 + >> * Stefan Endres + >> * Thomas Etherington + >> * Alex Fikl + >> * fo40225 + >> * Joseph Fox-Rabinovitz >> * Lars G >> * Abhinav Gautam + >> * Stiaan Gerber + >> * C.A.M. Gerlach + >> * Ralf Gommers >> * Todd Goodall >> * Lars Grueter + >> * Sylvain Gubian + >> * Matt Haberland >> * David Hagen >> * Will Handley + >> * Charles Harris >> * Ian Henriksen >> * Thomas Hisch + >> * Theodore Hu >> * Michael Hudson-Doyle + >> * Nicolas Hug + >> * jakirkham + >> * Jakob Jakobson + >> * James + >> * Jan Schl?ter >> * jeanpauphilet + >> * josephmernst + >> * Kai + >> * Kai-Striega + >> * kalash04 + >> * Toshiki Kataoka + >> * Konrad0 + >> * Tom Krauss + >> * Johannes Kulick >> * Lars Gr?ter + >> * Eric Larson >> * Denis Laxalde >> * Will Lee + >> * Katrin Leinweber + >> * Yin Li + >> * P. L. Lim + >> * Jesse Livezey + >> * Duncan Macleod + >> * MatthewFlamm + >> * Nikolay Mayorov >> * Mike McClurg + >> * Christian Meyer + >> * Mark Mikofski >> * Naoto Mizuno + >> * mohmmadd + >> * Nathan Musoke >> * Anju Geetha Nair + >> * Andrew Nelson >> * Ayappan P + >> * Nick Papior >> * Haesun Park + >> * Ronny Pfannschmidt + >> * pijyoi + >> * Ilhan Polat >> * Anthony Polloreno + >> * Ted Pudlik >> * puenka >> * Eric Quintero >> * Pradeep Reddy Raamana + >> * Vyas Ramasubramani + >> * Ramon Vi?as + >> * Tyler Reddy >> * Joscha Reimer >> * Antonio H Ribeiro >> * richardjgowers + >> * Rob + >> * robbystk + >> * Lucas Roberts + >> * rohan + >> * Joaquin Derrac Rus + >> * Josua Sassen + >> * Bruce Sharpe + >> * Max Shinn + >> * Scott Sievert >> * Sourav Singh >> * Strahinja Luki? + >> * Kai Striega + >> * Shinya SUZUKI + >> * Mike Toews + >> * Piotr Uchwat >> * Miguel de Val-Borro + >> * Nicky van Foreest >> * Paul van Mulbregt >> * Gael Varoquaux >> * Pauli Virtanen >> * Stefan van der Walt >> * Warren Weckesser >> * Joshua Wharton + >> * Bernhard M. Wiedemann + >> * Eric Wieser >> * Josh Wilson >> * Tony Xiang + >> * Roman Yurchak + >> * Roy Zywina + >> >> A total of 137 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. >> >> Issues closed for 1.2.0 >> - ----------------------- >> >> * `#1240 `__: Allowing >> multithreaded use of minpack through scipy.optimize... >> * `#1432 `__: >> scipy.stats.mode extremely slow (Trac #905) >> * `#3372 `__: Please add >> Sphinx search field to online scipy html docs >> * `#3678 `__: >> _clough_tocher_2d_single direction between centroids >> * `#4174 `__: lobpcg >> "largest" option invalid? >> * `#5493 `__: anderson_ksamp >> p-values>1 >> * `#5743 `__: slsqp fails to >> detect infeasible problem >> * `#6139 `__: >> scipy.optimize.linprog failed to find a feasible starting point... >> * `#6358 `__: stats: >> docstring for `vonmises_line` points to `vonmises_line`... >> * `#6498 `__: runtests.py is >> missing in pypi distfile >> * `#7426 `__: >> scipy.stats.ksone(n).pdf(x) returns nan for positive values of... >> * `#7455 `__: >> scipy.stats.ksone.pdf(2,x) return incorrect values for x near... >> * `#7456 `__: >> scipy.special.smirnov and scipy.special.smirnovi have accuracy... >> * `#7492 `__: >> scipy.special.kolmogorov(x)/kolmogi(p) inefficient, inaccurate... >> * `#7914 `__: TravisCI not >> failing when it should for -OO run >> * `#8064 `__: linalg.solve >> test crashes on Windows >> * `#8212 `__: LAPACK >> Rectangular Full Packed routines >> * `#8256 `__: >> differential_evolution bug converges to wrong results in complex... >> * `#8443 `__: Deprecate >> `hyp2f0`, `hyp1f2`, and `hyp3f0`? >> * `#8452 `__: DOC: ARPACK >> tutorial has two conflicting equations >> * `#8680 `__: scipy fails >> compilation when building from source >> * `#8686 `__: Division by >> zero in _trustregion.py when x0 is exactly equal... >> * `#8700 `__: _MINPACK_LOCK >> not held when calling into minpack from least_squares >> * `#8786 `__: erroneous >> moment values for t-distribution >> * `#8791 `__: Checking COLA >> condition in istft should be optional (or omitted) >> * `#8843 `__: imresize >> cannot be deprecated just yet >> * `#8844 `__: Inverse >> Wishart Log PDF Incorrect for Non-diagonal Scale Matrix? >> * `#8878 `__: vonmises and >> vonmises_line in stats: vonmises wrong and superfluous? >> * `#8895 `__: v1.1.0 >> `ndi.rotate` documentation ? reused parameters not filled... >> * `#8900 `__: Missing >> complex conjugation in scipy.sparse.linalg.LinearOperator >> * `#8904 `__: BUG: if zero >> derivative at root, then Newton fails with RuntimeWarning >> * `#8911 `__: >> make_interp_spline bc_type incorrect input interpretation >> * `#8942 `__: MAINT: >> Refactor `_linprog.py` and `_linprog_ip.py` to remove... >> * `#8947 `__: np.int64 in >> scipy.fftpack.next_fast_len >> * `#9020 `__: BUG: >> linalg.subspace_angles gives wrong results >> * `#9033 `__: >> scipy.stats.normaltest sometimes gives incorrect returns b/c... >> * `#9036 `__: Bizarre times >> for `scipy.sparse.rand` function with 'low' density... >> * `#9044 `__: >> optimize.minimize(method=`trust-constr`) result dict does not... >> * `#9071 `__: doc/linalg: >> add cho_solve_banded to see also of cholesky_banded >> * `#9082 `__: eigenvalue >> sorting in scipy.sparse.linalg.eigsh >> * `#9086 `__: >> signaltools.py:491: FutureWarning: Using a non-tuple sequence... >> * `#9091 `__: >> test_spline_filter failure on 32-bit >> * `#9122 `__: Typo on scipy >> minimization tutorial >> * `#9135 `__: doc error at >> https://docs.scipy.org/doc/scipy/reference/tutorial/stats/discrete_poisson.html >> * `#9167 `__: DOC: BUG: typo >> in ndimage LowLevelCallable tutorial example >> * `#9169 `__: truncnorm does >> not work if b < a in scipy.stats >> * `#9250 `__: >> scipy.special.tests.test_mpmath::TestSystematic::test_pcfw fails... >> * `#9259 `__: rv.expect() == >> rv.mean() is false for rv.mean() == nan (and inf) >> * `#9286 `__: DOC: >> Rosenbrock expression in optimize.minimize tutorial >> * `#9316 `__: SLSQP fails in >> nested optimization >> * `#9337 `__: >> scipy.signal.find_peaks key typo in documentation >> * `#9345 `__: Example from >> documentation of scipy.sparse.linalg.eigs raises... >> * `#9383 `__: Default value >> for "mode" in "ndimage.shift" >> * `#9419 `__: dual_annealing >> off by one in the number of iterations >> * `#9442 `__: Error in >> Defintion of Rosenbrock Function >> * `#9453 `__: TST: >> test_eigs_consistency() doesn't have consistent results >> >> >> Pull requests for 1.2.0 >> - ----------------------- >> >> * `#7352 `__: ENH: add Brunner >> Munzel test to scipy.stats. >> * `#7373 `__: BUG: Jaccard >> distance for all-zero arrays would return np.nan >> * `#7374 `__: ENH: Add PDF, >> CDF and parameter estimation for Stable Distributions >> * `#8098 `__: ENH: Add shgo >> for global optimization of NLPs. >> * `#8203 `__: ENH: adding >> simulated dual annealing to optimize >> * `#8259 `__: Option to follow >> original Storn and Price algorithm and its parallelisation >> * `#8293 `__: ENH add >> ratio-of-uniforms method for rv generation to scipy.stats >> * `#8294 `__: BUG: Fix >> slowness in stats.mode >> * `#8295 `__: ENH: add Jensen >> Shannon distance to `scipy.spatial.distance` >> * `#8357 `__: ENH: vectorize >> scalar zero-search-functions >> * `#8397 `__: Add `fs=` >> parameter to filter design functions >> * `#8537 `__: ENH: Implement >> mode parameter for spline filtering. >> * `#8558 `__: ENH: small >> speedup for stats.gaussian_kde >> * `#8560 `__: BUG: fix p-value >> calc of anderson_ksamp in scipy.stats >> * `#8614 `__: ENH: correct >> p-values for stats.kendalltau and stats.mstats.kendalltau >> * `#8670 `__: ENH: Require >> Lapack 3.4.0 >> * `#8683 `__: Correcting >> kmeans documentation >> * `#8725 `__: MAINT: Cleanup >> scipy.optimize.leastsq >> * `#8726 `__: BUG: Fix >> _get_output in scipy.ndimage to support string >> * `#8733 `__: MAINT: stats: A >> bit of clean up. >> * `#8737 `__: BUG: Improve >> numerical precision/convergence failures of smirnov/kolmogorov >> * `#8738 `__: MAINT: stats: A >> bit of clean up in test_distributions.py. >> * `#8740 `__: BF/ENH: make >> minpack thread safe >> * `#8742 `__: BUG: Fix >> division by zero in trust-region optimization methods >> * `#8746 `__: MAINT: signal: >> Fix a docstring of a private function, and fix... >> * `#8750 `__: DOC clarified >> description of norminvgauss in scipy.stats >> * `#8753 `__: DOC: signal: Fix >> a plot title in the chirp docstring. >> * `#8755 `__: DOC: MAINT: Fix >> link to the wheel documentation in developer... >> * `#8760 `__: BUG: stats: >> boltzmann wasn't setting the upper bound. >> * `#8763 `__: [DOC] Improved >> scipy.cluster.hierarchy documentation >> * `#8765 `__: DOC: added >> example for scipy.stat.mstats.tmin >> * `#8788 `__: DOC: fix >> definition of optional `disp` parameter >> * `#8802 `__: MAINT: Suppress >> dd_real unused function compiler warnings. >> * `#8803 `__: ENH: Add >> full_output support to optimize.newton() >> * `#8804 `__: MAINT: stats >> cleanup >> * `#8808 `__: DOC: add note >> about isinstance for frozen rvs >> * `#8812 `__: Updated numpydoc >> submodule >> * `#8813 `__: MAINT: stats: >> Fix multinomial docstrings, and do some clean up. >> * `#8816 `__: BUG: fixed >> _stats of t-distribution in scipy.stats >> * `#8817 `__: BUG: ndimage: >> Fix validation of the origin argument in correlate... >> * `#8822 `__: BUG: integrate: >> Fix crash with repeated t values in odeint. >> * `#8832 `__: Hyperlink DOIs >> against preferred resolver >> * `#8837 `__: BUG: sparse: >> Ensure correct dtype for sparse comparison operations. >> * `#8839 `__: DOC: stats: A >> few tweaks to the linregress docstring. >> * `#8846 `__: BUG: stats: Fix >> logpdf method of invwishart. >> * `#8849 `__: DOC: signal: >> Fixed mistake in the firwin docstring. >> * `#8854 `__: DOC: fix type >> descriptors in ltisys documentation >> * `#8865 `__: Fix tiny typo in >> docs for chi2 pdf >> * `#8870 `__: Fixes related to >> invertibility of STFT >> * `#8872 `__: ENH: special: >> Add the softmax function >> * `#8874 `__: DOC correct >> gamma function in docstrings in scipy.stats >> * `#8876 `__: ENH: Added TOMS >> Algorithm 748 as 1-d root finder; 17 test function... >> * `#8882 `__: ENH: Only use >> Halley's adjustment to Newton if close enough. >> * `#8883 `__: FIX: optimize: >> make jac and hess truly optional for 'trust-constr' >> * `#8885 `__: TST: Do not >> error on warnings raised about non-tuple indexing. >> * `#8887 `__: MAINT: filter >> out np.matrix PendingDeprecationWarning's in numpy... >> * `#8889 `__: DOC: optimize: >> separate legacy interfaces from new ones >> * `#8890 `__: ENH: Add >> optimize.root_scalar() as a universal dispatcher for... >> * `#8899 `__: DCT-IV, DST-IV >> and DCT-I, DST-I orthonormalization support in... >> * `#8901 `__: MAINT: >> Reorganize flapack.pyf.src file >> * `#8907 `__: BUG: ENH: Check >> if guess for newton is already zero before checking... >> * `#8908 `__: ENH: Make >> sorting optional for cKDTree.query_ball_point() >> * `#8910 `__: DOC: >> sparse.csgraph simple examples. >> * `#8914 `__: DOC: >> interpolate: fix equivalences of string aliases >> * `#8918 `__: add >> float_control(precise, on) to _fpumode.c >> * `#8919 `__: MAINT: >> interpolate: improve error messages for common `bc_type`... >> * `#8920 `__: DOC: update >> Contributing to SciPy to say "prefer no PEP8 only... >> * `#8924 `__: MAINT: special: >> deprecate `hyp2f0`, `hyp1f2`, and `hyp3f0` >> * `#8927 `__: MAINT: special: >> remove `errprint` >> * `#8932 `__: Fix broadcasting >> scale arg of entropy >> * `#8936 `__: Fix (some) >> non-tuple index warnings >> * `#8937 `__: ENH: implement >> sparse matrix BSR to CSR conversion directly. >> * `#8938 `__: DOC: add >> @_ni_docstrings.docfiller in ndimage.rotate >> * `#8940 `__: Update >> _discrete_distns.py >> * `#8943 `__: DOC: Finish >> dangling sentence in `convolve` docstring >> * `#8944 `__: MAINT: Address >> tuple indexing and warnings >> * `#8945 `__: ENH: >> spatial.transform.Rotation [GSOC2018] >> * `#8950 `__: csgraph Dijkstra >> function description rewording >> * `#8953 `__: DOC, MAINT: HTTP >> -> HTTPS, and other linkrot fixes >> * `#8955 `__: BUG: np.int64 in >> scipy.fftpack.next_fast_len >> * `#8958 `__: MAINT: Add more >> descriptive error message for phase one simplex. >> * `#8962 `__: BUG: >> sparse.linalg: add missing conjugate to _ScaledLinearOperator.adjoint >> * `#8963 `__: BUG: >> sparse.linalg: downgrade LinearOperator TypeError to warning >> * `#8965 `__: ENH: Wrapped RFP >> format and RZ decomposition routines >> * `#8969 `__: MAINT: doc and >> code fixes for optimize.newton >> * `#8970 `__: Added 'average' >> keyword for welch/csd to enable median averaging >> * `#8971 `__: Better imresize >> deprecation warning >> * `#8972 `__: MAINT: Switch >> np.where(c) for np.nonzero(c) >> * `#8975 `__: MAINT: Fix >> warning-based failures >> * `#8979 `__: DOC: fix >> description of count_sort keyword of dendrogram >> * `#8982 `__: MAINT: optimize: >> Fixed minor mistakes in test_linprog.py (#8978) >> * `#8984 `__: BUG: >> sparse.linalg: ensure expm casts integer inputs to float >> * `#8986 `__: BUG: >> optimize/slsqp: do not exit with convergence on steps where... >> * `#8989 `__: MAINT: use >> collections.abc in basinhopping >> * `#8990 `__: ENH extend >> p-values of anderson_ksamp in scipy.stats >> * `#8991 `__: ENH: Weighted kde >> * `#8993 `__: ENH: >> spatial.transform.Rotation.random [GSOC 2018] >> * `#8994 `__: ENH: >> spatial.transform.Slerp [GSOC 2018] >> * `#8995 `__: TST: time.time >> in test >> * `#9007 `__: Fix typo in >> fftpack.rst >> * `#9013 `__: Added correct >> plotting code for two sided output from spectrogram >> * `#9014 `__: BUG: >> differential_evolution with inf objective functions >> * `#9017 `__: BUG: fixed #8446 >> corner case for asformat(array|dense) >> * `#9018 `__: MAINT: >> _lib/ccallback: remove unused code >> * `#9021 `__: BUG: Issue with >> subspace_angles >> * `#9022 `__: DOC: Added "See >> Also" section to lombscargle docstring >> * `#9034 `__: BUG: Fix >> tolerance printing behavior, remove meaningless tol... >> * `#9035 `__: TST: improve >> signal.bsplines test coverage >> * `#9037 `__: ENH: add a new >> init method for k-means >> * `#9039 `__: DOC: Add >> examples to fftpack.irfft docstrings >> * `#9048 `__: ENH: >> scipy.sparse.random >> * `#9050 `__: BUG: >> scipy.io.hb_write: fails for matrices not in csc format >> * `#9051 `__: MAINT: Fix slow >> sparse.rand for k < mn/3 (#9036). >> * `#9054 `__: MAINT: spatial: >> Explicitly initialize LAPACK output parameters. >> * `#9055 `__: DOC: Add >> examples to scipy.special docstrings >> * `#9056 `__: ENH: Use one >> thread in OpenBLAS >> * `#9059 `__: DOC: Update >> README with link to Code of Conduct >> * `#9060 `__: BLD: remove >> support for the Bento build system. >> * `#9062 `__: DOC add sections >> to overview in scipy.stats >> * `#9066 `__: BUG: Correct >> "remez" error message >> * `#9069 `__: DOC: update >> linalg section of roadmap for LAPACK versions. >> * `#9079 `__: MAINT: add >> spatial.transform to refguide check; complete some... >> * `#9081 `__: MAINT: Add >> warnings if pivot value is close to tolerance in linprog(method='simplex') >> * `#9084 `__: BUG fix >> incorrect p-values of kurtosistest in scipy.stats >> * `#9095 `__: DOC: add >> sections to mstats overview in scipy.stats >> * `#9096 `__: BUG: Add test >> for Stackoverflow example from issue 8174. >> * `#9101 `__: ENH: add Siegel >> slopes (robust regression) to scipy.stats >> * `#9105 `__: allow >> resample_poly() to output float32 for float32 inputs. >> * `#9112 `__: MAINT: optimize: >> make trust-constr accept constraint dict (#9043) >> * `#9118 `__: Add doc entry to >> cholesky_banded >> * `#9120 `__: eigsh >> documentation parameters >> * `#9125 `__: interpolative: >> correctly reconstruct full rank matrices >> * `#9126 `__: MAINT: Use >> warnings for unexpected peak properties >> * `#9129 `__: BUG: Do not >> catch and silence KeyboardInterrupt >> * `#9131 `__: DOC: Correct the >> typo in scipy.optimize tutorial page >> * `#9133 `__: FIX: Avoid use >> of bare except >> * `#9134 `__: DOC: Update of >> 'return_eigenvectors' description >> * `#9137 `__: DOC: typo fixes >> for discrete Poisson tutorial >> * `#9139 `__: FIX: Doctest >> failure in optimize tutorial >> * `#9143 `__: DOC: missing >> sigma in Pearson r formula >> * `#9145 `__: MAINT: Refactor >> linear programming solvers >> * `#9149 `__: FIX: Make >> scipy.odr.ODR ifixx equal to its data.fix if given >> * `#9156 `__: DOC: special: >> Mention the sigmoid function in the expit docstring. >> * `#9160 `__: Fixed a latex >> delimiter error in levy() >> * `#9170 `__: DOC: correction >> / update of docstrings of distributions in scipy.stats >> * `#9171 `__: better >> description of the hierarchical clustering parameter >> * `#9174 `__: domain check for >> a < b in stats.truncnorm >> * `#9175 `__: DOC: Minor >> grammar fix >> * `#9176 `__: BUG: >> CloughTocher2DInterpolator: fix miscalculation at neighborless... >> * `#9177 `__: BUILD: Document >> the "clean" target in the doc/Makefile. >> * `#9178 `__: MAINT: make >> refguide-check more robust for printed numpy arrays >> * `#9186 `__: MAINT: Remove >> np.ediff1d occurence >> * `#9188 `__: DOC: correct >> typo in extending ndimage with C >> * `#9190 `__: ENH: Support >> specifying axes for fftconvolve >> * `#9192 `__: MAINT: optimize: >> fixed @pv style suggestions from #9112 >> * `#9200 `__: Fix >> make_interp_spline(..., k=0 or 1, axis<0) >> * `#9201 `__: BUG: >> sparse.linalg/gmres: use machine eps in breakdown check >> * `#9204 `__: MAINT: fix up >> stats.spearmanr and match mstats.spearmanr with... >> * `#9206 `__: MAINT: include >> benchmarks and dev files in sdist. >> * `#9208 `__: TST: signal: >> bump bsplines test tolerance for complex data >> * `#9210 `__: TST: mark tests >> as slow, fix missing random seed >> * `#9211 `__: ENH: add >> capability to specify orders in pade func >> * `#9217 `__: MAINT: Include >> ``success`` and ``nit`` in OptimizeResult returned... >> * `#9222 `__: ENH: >> interpolate: Use scipy.spatial.distance to speed-up Rbf >> * `#9229 `__: MNT: Fix Fourier >> filter double case >> * `#9233 `__: BUG: >> spatial/distance: fix pdist/cdist performance regression... >> * `#9234 `__: FIX: Proper >> suppression >> * `#9235 `__: BENCH: >> rationalize slow benchmarks + miscellaneous fixes >> * `#9238 `__: BENCH: limit >> number of parameter combinations in spatial.*KDTree... >> * `#9239 `__: DOC: stats: Fix >> LaTeX markup of a couple distribution PDFs. >> * `#9241 `__: ENH: Evaluate >> plateau size during peak finding >> * `#9242 `__: ENH: stats: >> Implement _ppf and _logpdf for crystalball, and do... >> * `#9246 `__: DOC: Properly >> render versionadded directive in HTML documentation >> * `#9255 `__: DOC: mention >> RootResults in optimization reference guide >> * `#9260 `__: TST: relax some >> tolerances so tests pass with x87 math >> * `#9264 `__: TST Use >> assert_raises "match" parameter instead of the "message"... >> * `#9267 `__: DOC: clarify >> expect() return val when moment is inf/nan >> * `#9272 `__: DOC: Add >> description of default bounds to linprog >> * `#9277 `__: MAINT: >> sparse/linalg: make test deterministic >> * `#9278 `__: MAINT: >> interpolate: pep8 cleanup in test_polyint >> * `#9279 `__: Fixed docstring >> for resample >> * `#9280 `__: removed first >> check for float in get_sum_dtype >> * `#9281 `__: BUG: only accept >> 1d input for bartlett / levene in scipy.stats >> * `#9282 `__: MAINT: >> dense_output and t_eval are mutually exclusive inputs >> * `#9283 `__: MAINT: add docs >> and do some cleanups in interpolate.Rbf >> * `#9288 `__: Run >> distance_transform_edt tests on all types >> * `#9294 `__: DOC: fix the >> formula typo >> * `#9298 `__: MAINT: >> optimize/trust-constr: restore .niter attribute for backward-compat >> * `#9299 `__: DOC: >> clarification of default rvs method in scipy.stats >> * `#9301 `__: MAINT: removed >> unused import sys >> * `#9302 `__: MAINT: removed >> unused imports >> * `#9303 `__: DOC: signal: >> Refer to fs instead of nyq in the firwin docstring. >> * `#9305 `__: ENH: Added >> Yeo-Johnson power transformation >> * `#9306 `__: ENH - add dual >> annealing >> * `#9309 `__: ENH add the >> yulesimon distribution to scipy.stats >> * `#9317 `__: Nested SLSQP bug >> fix. >> * `#9320 `__: MAINT: stats: >> avoid underflow in stats.geom.ppf >> * `#9326 `__: Add example for >> Rosenbrock function >> * `#9332 `__: Sort file lists >> * `#9340 `__: Fix typo in >> find_peaks documentation >> * `#9343 `__: MAINT Use >> np.full when possible >> * `#9344 `__: DOC: added >> examples to docstring of dirichlet class >> * `#9346 `__: DOC: Fix import >> of scipy.sparse.linalg in example (#9345) >> * `#9350 `__: Fix interpolate >> read only >> * `#9351 `__: MAINT: >> special.erf: use the x->-x symmetry >> * `#9356 `__: Fix >> documentation typo >> * `#9358 `__: DOC: improve doc >> for ksone and kstwobign in scipy.stats >> * `#9362 `__: DOC: Change >> datatypes of A matrices in linprog >> * `#9364 `__: MAINT: Adds >> implicit none to fftpack fortran sources >> * `#9369 `__: DOC: minor tweak >> to CoC (updated NumFOCUS contact address). >> * `#9373 `__: Fix exception if >> python is called with -OO option >> * `#9374 `__: FIX: AIX >> compilation issue with NAN and INFINITY >> * `#9376 `__: COBLYA -> COBYLA >> in docs >> * `#9377 `__: DOC: Add >> examples integrate: fixed_quad and quadrature >> * `#9379 `__: MAINT: TST: Make >> tests NumPy 1.8 compatible >> * `#9385 `__: CI: On Travis >> matrix "OPTIMIZE=-OO" flag ignored >> * `#9387 `__: Fix defaut value >> for 'mode' in 'ndimage.shift' in the doc >> * `#9392 `__: BUG: rank has to >> be integer in rank_filter: fixed issue 9388 >> * `#9399 `__: DOC: Misc. typos >> * `#9400 `__: TST: stats: Fix >> the expected r-value of a linregress test. >> * `#9405 `__: BUG: np.hstack >> does not accept generator expressions >> * `#9408 `__: ENH: linalg: >> Shorter ill-conditioned warning message >> * `#9418 `__: DOC: Fix ndimage >> docstrings and reduce doc build warnings >> * `#9421 `__: DOC: Add missing >> docstring examples in scipy.spatial >> * `#9422 `__: DOC: Add an >> example to integrate.newton_cotes >> * `#9427 `__: BUG: Fixed >> defect with maxiter #9419 in dual annealing >> * `#9431 `__: BENCH: Add dual >> annealing to scipy benchmark (see #9415) >> * `#9435 `__: DOC: Add >> docstring examples for stats.binom_test >> * `#9443 `__: DOC: Fix the >> order of indices in optimize tutorial >> * `#9444 `__: MAINT: >> interpolate: use operator.index for checking/coercing... >> * `#9445 `__: DOC: Added >> missing example to stats.mstats.kruskal >> * `#9446 `__: DOC: Add note >> about version changed for jaccard distance >> * `#9447 `__: BLD: >> version-script handling in setup.py >> * `#9448 `__: TST: skip a >> problematic linalg test >> * `#9449 `__: TST: fix missing >> seed in lobpcg test. >> * `#9456 `__: TST: >> test_eigs_consistency() now sorts output >> >> Checksums >> ========= >> >> MD5 >> ~~~ >> >> 47d309402d2e5574be8fa261fadfaf58 >> scipy-1.2.0rc1-cp27-cp27m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl >> 911dfde5be66403c07c60e19aa631dc2 >> scipy-1.2.0rc1-cp27-cp27m-manylinux1_i686.whl >> a693189336365595b42b0d93f825b826 >> scipy-1.2.0rc1-cp27-cp27m-manylinux1_x86_64.whl >> ec5abd33480761ed9701f7fd2274fc47 scipy-1.2.0rc1-cp27-cp27m-win32.whl >> bc3d40311f057b12f8fea97166ef8112 scipy-1.2.0rc1-cp27-cp27m-win_amd64.whl >> 33848233e6438b1ff9183d8a4794daed >> scipy-1.2.0rc1-cp27-cp27mu-manylinux1_i686.whl >> c2cb1166ce0071e1fe42ed1c3e60b75e >> scipy-1.2.0rc1-cp27-cp27mu-manylinux1_x86_64.whl >> a04b5a758f555e05e6431b8a1f035888 >> scipy-1.2.0rc1-cp34-cp34m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl >> ad511246d0742cf0669fedf292cc01bb >> scipy-1.2.0rc1-cp34-cp34m-manylinux1_i686.whl >> 15aa08ef43a6c5cb320bc015f01087ad >> scipy-1.2.0rc1-cp34-cp34m-manylinux1_x86_64.whl >> 86a59b81a3e6894d9054139311a2c51f scipy-1.2.0rc1-cp34-cp34m-win32.whl >> 8b6e33253579916ea873c45989ee5bea scipy-1.2.0rc1-cp34-cp34m-win_amd64.whl >> db7a4de02828471bf9f800814ff68627 >> scipy-1.2.0rc1-cp35-cp35m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl >> c296b6270d29d3ec6dafddf8ceae67fb >> scipy-1.2.0rc1-cp35-cp35m-manylinux1_i686.whl >> 3ba7a825f61822128d960fa728010e51 >> scipy-1.2.0rc1-cp35-cp35m-manylinux1_x86_64.whl >> c083c8287da110b707d181f6638ce122 scipy-1.2.0rc1-cp35-cp35m-win32.whl >> 2242eac92681085258535ed96bd040d7 scipy-1.2.0rc1-cp35-cp35m-win_amd64.whl >> d5c238903c00e91a40d56023f1a27ed4 >> scipy-1.2.0rc1-cp36-cp36m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl >> e8ab7487a9a53b86a6510772c45af787 >> scipy-1.2.0rc1-cp36-cp36m-manylinux1_i686.whl >> 9991b5958d736488bef638eea463945d >> scipy-1.2.0rc1-cp36-cp36m-manylinux1_x86_64.whl >> 9c108a9d7e967b8c9a5e5143b1a15b40 scipy-1.2.0rc1-cp36-cp36m-win32.whl >> 54d63041f0315d341d9ffb028a98e767 scipy-1.2.0rc1-cp36-cp36m-win_amd64.whl >> 534276c864ab3139811561c022608cc3 >> scipy-1.2.0rc1-cp37-cp37m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl >> 4bd26c179a10891087bd81a658573683 >> scipy-1.2.0rc1-cp37-cp37m-manylinux1_i686.whl >> 1a3170b4f1df42f28efbe197e54eb9a3 >> scipy-1.2.0rc1-cp37-cp37m-manylinux1_x86_64.whl >> 72b89f7e2c1d13dc8dbb21600fb184da scipy-1.2.0rc1-cp37-cp37m-win32.whl >> 433ef294c4a015da0a6e0f063289a658 scipy-1.2.0rc1-cp37-cp37m-win_amd64.whl >> 83abb1befce326916e0435d428b36e62 scipy-1.2.0rc1.tar.gz >> 21b7570fb577543807feb4b4c1fdad8a scipy-1.2.0rc1.tar.xz >> 11221dc23e0d3b316b5564f2f435aaf1 scipy-1.2.0rc1.zip >> >> SHA256 >> ~~~~~~ >> >> a3282027743e89d5fcb6cd7a9e4ecdbbde61bf8126fd19683e97b69f5f6a2163 >> scipy-1.2.0rc1-cp27-cp27m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl >> 8b8841e03620d4d704f4efd3daed575e23a6272ae9c9be2c4cc751febee984f7 >> scipy-1.2.0rc1-cp27-cp27m-manylinux1_i686.whl >> 254ea2f7f3c5afef9f02c0192d2dbd8f5336c1b1c53efae7ef64a8880cccc299 >> scipy-1.2.0rc1-cp27-cp27m-manylinux1_x86_64.whl >> d449832419df3e37a3942778b46c140fd61d1e4f38f9e34bed278a77aacdbd31 >> scipy-1.2.0rc1-cp27-cp27m-win32.whl >> e57f3e3eaa88cd7bc93466122fca48c36863e03aeb24f9d570a2e6b2ea3cbf92 >> scipy-1.2.0rc1-cp27-cp27m-win_amd64.whl >> 00dcb606101fa10951ee235af69dbff55d999b01c9bb2bc0f64df5fc3aff4eb6 >> scipy-1.2.0rc1-cp27-cp27mu-manylinux1_i686.whl >> 38857eb49f7e38d3ec079772225a79235d0bd847e24d2fa8c9a9fa70ee69f0a2 >> scipy-1.2.0rc1-cp27-cp27mu-manylinux1_x86_64.whl >> 9b9950278f36c4e7779148cc9a719d41a305024c70005f994412845172ade346 >> scipy-1.2.0rc1-cp34-cp34m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl >> c8a2fc15c64f1b162b02f86d28153b65f64720ca64e832bcf5bfae060a507949 >> scipy-1.2.0rc1-cp34-cp34m-manylinux1_i686.whl >> 4e205e0e5e88fe2105c594a706ac9fa558fe7a4daa2bef2c86b343ab507d8bd6 >> scipy-1.2.0rc1-cp34-cp34m-manylinux1_x86_64.whl >> b04fb8ba796198d83614138d7f96e88791d83f5f4e31e628cce51fda1a092f66 >> scipy-1.2.0rc1-cp34-cp34m-win32.whl >> c34e4ce9a8c62c85f322d7897a257a839a4bb7fd94e08701044e9b1cc1bb15a6 >> scipy-1.2.0rc1-cp34-cp34m-win_amd64.whl >> cb7f4c289c06514c6e224263868a98d5e6aa6e8a90f2304b16ff276aa96030ce >> scipy-1.2.0rc1-cp35-cp35m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl >> dcaeed34e7e965e935ba252fd3290c04cafb7d84f6f44c9c08269504aa2e0a05 >> scipy-1.2.0rc1-cp35-cp35m-manylinux1_i686.whl >> 13b234b4fbda1368474a667fc29e8365b622c4c607ed490f00643625c8f50cca >> scipy-1.2.0rc1-cp35-cp35m-manylinux1_x86_64.whl >> 073560d6598b97b8f214a31856a1d43c96701b46c5cc9805789f962c3b8a0e97 >> scipy-1.2.0rc1-cp35-cp35m-win32.whl >> 600cf596b83f185dca3455d03ca802de0b4de98cb4c8d041226089d78d04c2bc >> scipy-1.2.0rc1-cp35-cp35m-win_amd64.whl >> 77b7ed8e13f03a843d2f11bd140f224abe62fb56656f35348578e3838ff4d528 >> scipy-1.2.0rc1-cp36-cp36m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl >> 98786b516d1955592f921c2b36505840ff921c9e82f5c28a6c2a580fb3e96af1 >> scipy-1.2.0rc1-cp36-cp36m-manylinux1_i686.whl >> 8f62fc6ac6b842d7c3c499269150ec81d26a0dea5ce818aef3b0e9e14e53c5c7 >> scipy-1.2.0rc1-cp36-cp36m-manylinux1_x86_64.whl >> 213cfc35ec2fbf86c5957d1ada99a1fe1eacccdb498d4790089af9cf50cadab4 >> scipy-1.2.0rc1-cp36-cp36m-win32.whl >> 287e46f87399eb9897c726c6d358c893f6c769300599bc5da95cbf3397a00aa7 >> scipy-1.2.0rc1-cp36-cp36m-win_amd64.whl >> 7116d193da4baca6f7cd1cd7810548fa03ed4a06e05f325978b2f0018b05ead9 >> scipy-1.2.0rc1-cp37-cp37m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl >> 9cd3fe767225b0dcfcc9f09ed18288b51c29b35ca16dc4e5a6f3587b4ac7d7b5 >> scipy-1.2.0rc1-cp37-cp37m-manylinux1_i686.whl >> 4024aea96a01ca05af701f93fd227a7f646258116903899a75b1f4a1f0134bf8 >> scipy-1.2.0rc1-cp37-cp37m-manylinux1_x86_64.whl >> eccd0e6d321585b6e2ee18fa0ee1db4fe042e52fb4ae8e28a3d223df6bcd6a8e >> scipy-1.2.0rc1-cp37-cp37m-win32.whl >> 96f6c69b2d8f63dad5612385521d0cf8b62f665a62f56b6b3d3fb7042a63c34c >> scipy-1.2.0rc1-cp37-cp37m-win_amd64.whl >> ca9ba36bb271dcb4273e330c0bd418a1c3566ff76248dd634efecbe0e9c1721c >> scipy-1.2.0rc1.tar.gz >> b8fe757f377b43c733a0ba235b990fb4b3722bd6f5930a26359d16752e94560c >> scipy-1.2.0rc1.tar.xz >> da1980e7e037e2275821d7611a91eadafdc157b096f36f41d05cc0ea4ae539bc >> scipy-1.2.0rc1.zip >> -----BEGIN PGP SIGNATURE----- >> >> iQIzBAEBCAAdFiEEgfAqrOuERrV4fwr6XCLdIy4FKasFAlv8LB8ACgkQXCLdIy4F >> KauhWw//cFUboxtuNZeEh98Pn2mfVIqRF8hc6VK7jeXU64qiAdOnbBRKXfoXWpbt >> 8fEckTFVVt2CQzIEZju429P0eWv8psfvn90cNnj5VHz7h46AH5gQee/cfP1kNWGO >> mxcYczqZN8+ldDnww4hfk0R+3IrpfmQbVSMEqBF84uottfgUjUzPtcFHJmmmcOF2 >> 7XWhAP5IWMctcwq3r3WAa8yLUmlEIB3Fs9mPPr1We7e0QiXnEueUrXVZF9Oz3UpJ >> UFiTwX5nxnNdxZJwtLbBXhxJUbvPnooby0x1NwxFG6AwrWaPG3my0e9kIzpwqfsf >> 0B7Pt/xPEHWIizaqMyfUiaS7FZOUfvq6xs5aCyQeP9Wtnwherm6SQ/Qs+LFSb8E2 >> 9cgyFmaBeslrTMd3f1YMcb6d1hmNSjbBmWccZEXCqjC9UClxbAQDHDcdmTl+4vp7 >> xATCxWkYVP9lOLH5TtIC1Bo0AZXiOxI3JnojQS65JH0w4unh1IJJkENurzCATh4/ >> vnyddy0x2e1ok5bX8fpVFrCc8lSdO8aDY5cYEU55XZhkyroet3IaOYqwPzPQPwoJ >> QgYEsqxa2Urn0faV5uuDFTscnCAHK0EVXhr3yyL0YoIGOPffM8JaswEAUaFwLrq0 >> KEbOavdImtSwqL9v6x5tDyYXh/mHQ70GGtPS68iSc1NexRrwLAw= >> =F/+Z >> -----END PGP SIGNATURE----- >> >> >> >> _______________________________________________ >> NumPy-Discussion mailing list >> NumPy-Discussion at python.org >> https://mail.python.org/mailman/listinfo/numpy-discussion >> > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at python.org > https://mail.python.org/mailman/listinfo/scipy-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tyler.je.reddy at gmail.com Wed Nov 28 13:05:19 2018 From: tyler.je.reddy at gmail.com (Tyler Reddy) Date: Wed, 28 Nov 2018 10:05:19 -0800 Subject: [SciPy-Dev] SciPy 1.2.0 release schedule In-Reply-To: References: Message-ID: I'm tentatively suggesting that we do a second release candidate, rc2, on or at least close to December 3rd. My notes currently show the PRs/ issues below on the "backport radar." In particular, I think Ralf noticed an API inconsistency in one of the big optimize enhancements. https://github.com/scipy/scipy/pull/9541 https://github.com/scipy/scipy/issues/9547 https://github.com/scipy/scipy/pull/9550 On Wed, 21 Nov 2018 at 15:07, Ralf Gommers wrote: > > > On Wed, Nov 21, 2018 at 9:32 AM Tyler Reddy > wrote: > >> I've pushed the v1.2.x wheels branch -- initially this will aim to >> confirm that SciPy master branch is now passing the Travis & Appveyor wheel >> builds. >> >> If that is the case, I will proceed with the 3 connected backport PRs to >> the maintenance branch. >> >> Then, I will point the v.1.2.x wheels branch to an appropriate commit on >> the patched maintenance branch for release candidate wheel builds. >> > > Sounds like a plan! > > Ralf > > >> >> On Sat, 17 Nov 2018 at 10:27, Ilhan Polat wrote: >> >>> Good stuff Tyler. I have to also add to that list the recent pypy3 run >>> failures appearing sporadically (though consistent on my PRs). >>> >>> I am trying triangulate the cause but probably will have to wait until >>> at least tomorrow. Feedback is more than welcome. They seem to be related >>> to cython/numpy versions but one can never be sure. >>> >>> ?lhan >>> >>> >>> On Fri, Nov 16, 2018, 19:35 Tyler Reddy >>> wrote: >>> >>>> Current delays / issues I'm working on--feel free to chime in on those: >>>> >>>> - a few test failures in wheel building matrix: >>>> https://github.com/MacPython/scipy-wheels/pull/37 >>>> - hard-to-understand putative patch for one of the failures: >>>> https://github.com/scipy/scipy/pull/9486 >>>> >>>> On Fri, 9 Nov 2018 at 08:40, Tyler Reddy >>>> wrote: >>>> >>>>> I branched 1.2.x around 8:30 am Pacific time on Nov. 9, 2018. >>>>> >>>>> Working on the follow up master branch PR to bump version number / >>>>> notes file, etc. now. >>>>> >>>>> On Thu, 8 Nov 2018 at 22:49, Tyler Reddy >>>>> wrote: >>>>> >>>>>> Release note PR is hopefully taking shape now -- I'll allow (another) >>>>>> delay for the branch until tomorrow (morning?) for some (hopefully final) >>>>>> checks on that. >>>>>> >>>>>> On Thu, 8 Nov 2018 at 14:35, Tyler Reddy >>>>>> wrote: >>>>>> >>>>>>> There are 0 remaining PRs with a 1.2.0 milestone. >>>>>>> >>>>>>> There is one issue left with a 1.2.0 milestone: >>>>>>> https://github.com/scipy/scipy/issues/9441 >>>>>>> >>>>>>> Please do take a look over the release notes WIP PR based on the >>>>>>> wiki: https://github.com/scipy/scipy/pull/9461 >>>>>>> >>>>>>> Target is to branch in 5-6 hours or so. Let me know if you see any >>>>>>> issues of course -- Ralf has been coaching >>>>>>> me through pretty well so far I think. >>>>>>> >>>>>>> On Wed, 7 Nov 2018 at 09:52, Ilhan Polat >>>>>>> wrote: >>>>>>> >>>>>>>> Hang in there Tyler :) >>>>>>>> >>>>>>>> Awesome job so far. >>>>>>>> >>>>>>>> >>>>>>>> On Wed, Nov 7, 2018, 06:08 Ralf Gommers >>>>>>>> wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Tue, Nov 6, 2018 at 9:03 PM Tyler Reddy < >>>>>>>>> tyler.je.reddy at gmail.com> wrote: >>>>>>>>> >>>>>>>>>> 7 PRs : >>>>>>>>>> https://github.com/scipy/scipy/pulls?q=is%3Aopen+is%3Apr+milestone%3A1.2.0 >>>>>>>>>> 3 issues: >>>>>>>>>> https://github.com/scipy/scipy/issues?q=is%3Aopen+is%3Aissue+milestone%3A1.2.0 >>>>>>>>>> >>>>>>>>> >>>>>>>>> Awesome, getting there:) >>>>>>>>> >>>>>>>>> >>>>>>>>>> Target: branch sometime on November 8th >>>>>>>>>> >>>>>>>>>> On Mon, 5 Nov 2018 at 05:42, Tyler Reddy < >>>>>>>>>> tyler.je.reddy at gmail.com> wrote: >>>>>>>>>> >>>>>>>>>>> Alright, I'll extend to Thursday Nov. 8th & see if I can reduce >>>>>>>>>>> that list a bit >>>>>>>>>>> >>>>>>>>>>> On Sun, 4 Nov 2018 at 22:27, Ralf Gommers < >>>>>>>>>>> ralf.gommers at gmail.com> wrote: >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Fri, Oct 26, 2018 at 7:03 PM Mark Alexander Mikofski < >>>>>>>>>>>> mikofski at berkeley.edu> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Hi Tyler and others, >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks for managing the v1.2 release. >>>>>>>>>>>>> >>>>>>>>>>>>> I think PR #8431, Cython optimize zeros API, is ready, >>>>>>>>>>>>> hopefully, to merge. It's been through several rounds of reviews and I >>>>>>>>>>>>> think I've accommodated all of the recommendations, all tests are passing, >>>>>>>>>>>>> and there's been strong support. Anyone please take a look. >>>>>>>>>>>>> >>>>>>>>>>>>> https://github.com/scipy/scipy/pull/8431 >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Mark >>>>>>>>>>>>> >>>>>>>>>>>>> On Fri, Oct 26, 2018, 2:38 PM Ralf Gommers < >>>>>>>>>>>>> ralf.gommers at gmail.com> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Thu, Oct 25, 2018 at 12:55 PM Tyler Reddy < >>>>>>>>>>>>>> tyler.je.reddy at gmail.com> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hi all, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> It is almost 6 months after the 1.1.0 release on May 5, so >>>>>>>>>>>>>>> probably time to plan the 1.2.0 release. It would be a good idea to look >>>>>>>>>>>>>>> over the PRs with a 1.2.0 milestone >>>>>>>>>>>>>>> , >>>>>>>>>>>>>>> and tag anything else that should have this milestone appropriately. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I'd like to propose the following schedule: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Nov. 5: branch 1.2.x >>>>>>>>>>>>>>> Nov. 8: rc1 >>>>>>>>>>>>>>> Nov. 21: rc2 (if needed) >>>>>>>>>>>>>>> Nov. 30: final release >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thoughts? >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> This looks like a good schedule to me. We'll probably >>>>>>>>>>>>>> struggle to get some PRs marked for 1.2.0 merged, but that's always the >>>>>>>>>>>>>> case. >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> Hi Tyler, could we shift the branch date by 2-3 days (or up to >>>>>>>>>>>> a week)? There's a couple of PRs that I'd really like to see merged or >>>>>>>>>>>> decided on (for optimize and stats mainly), and there's right now still 18 >>>>>>>>>>>> open PRs marked for 1.2.0. >>>>>>>>>>>> >>>>>>>>>>>> A note on the open PRs: what we want to aim for is to have the >>>>>>>>>>>> list of open PRs and open blocking issues at zero, and have at most some >>>>>>>>>>>> non-blocking issues under the milestone left. Normally the release manager >>>>>>>>>>>> starts making those decisions, or pinging people, if other reviewers >>>>>>>>>>>> haven't done so in time. Of course it would be ideal if everyone has >>>>>>>>>>>> another look at >>>>>>>>>>>> https://github.com/scipy/scipy/pulls?q=is%3Aopen+is%3Apr+milestone%3A1.2.0 >>>>>>>>>>>> and bumps or finished off PRs he/she is involved in. >>>>>>>>>>>> >>>>>>>>>>>> Cheers, >>>>>>>>>>>> Ralf >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> SciPy-Dev mailing list >>>>>>>>>>>> SciPy-Dev at python.org >>>>>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev >>>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>> SciPy-Dev mailing list >>>>>>>>>> SciPy-Dev at python.org >>>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev >>>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> SciPy-Dev mailing list >>>>>>>>> SciPy-Dev at python.org >>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev >>>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> SciPy-Dev mailing list >>>>>>>> SciPy-Dev at python.org >>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev >>>>>>>> >>>>>>> _______________________________________________ >>>> SciPy-Dev mailing list >>>> SciPy-Dev at python.org >>>> https://mail.python.org/mailman/listinfo/scipy-dev >>>> >>> _______________________________________________ >>> SciPy-Dev mailing list >>> SciPy-Dev at python.org >>> https://mail.python.org/mailman/listinfo/scipy-dev >>> >> _______________________________________________ >> SciPy-Dev mailing list >> SciPy-Dev at python.org >> https://mail.python.org/mailman/listinfo/scipy-dev >> > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at python.org > https://mail.python.org/mailman/listinfo/scipy-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.gommers at gmail.com Thu Nov 29 22:32:27 2018 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Thu, 29 Nov 2018 19:32:27 -0800 Subject: [SciPy-Dev] SciPy 1.2.0 release schedule In-Reply-To: References: Message-ID: On Wed, Nov 28, 2018 at 10:05 AM Tyler Reddy wrote: > I'm tentatively suggesting that we do a second release candidate, rc2, on > or at least close to December 3rd. > Yes, that makes sense. There's enough changes to justify a new release candidate. Ralf > My notes currently show the PRs/ issues below on the "backport radar." In > particular, I think Ralf noticed > an API inconsistency in one of the big optimize enhancements. > > https://github.com/scipy/scipy/pull/9541 > https://github.com/scipy/scipy/issues/9547 > https://github.com/scipy/scipy/pull/9550 > > On Wed, 21 Nov 2018 at 15:07, Ralf Gommers wrote: > >> >> >> On Wed, Nov 21, 2018 at 9:32 AM Tyler Reddy >> wrote: >> >>> I've pushed the v1.2.x wheels branch -- initially this will aim to >>> confirm that SciPy master branch is now passing the Travis & Appveyor wheel >>> builds. >>> >>> If that is the case, I will proceed with the 3 connected backport PRs to >>> the maintenance branch. >>> >>> Then, I will point the v.1.2.x wheels branch to an appropriate commit on >>> the patched maintenance branch for release candidate wheel builds. >>> >> >> Sounds like a plan! >> >> Ralf >> >> >>> >>> On Sat, 17 Nov 2018 at 10:27, Ilhan Polat wrote: >>> >>>> Good stuff Tyler. I have to also add to that list the recent pypy3 run >>>> failures appearing sporadically (though consistent on my PRs). >>>> >>>> I am trying triangulate the cause but probably will have to wait until >>>> at least tomorrow. Feedback is more than welcome. They seem to be related >>>> to cython/numpy versions but one can never be sure. >>>> >>>> ?lhan >>>> >>>> >>>> On Fri, Nov 16, 2018, 19:35 Tyler Reddy >>>> wrote: >>>> >>>>> Current delays / issues I'm working on--feel free to chime in on those: >>>>> >>>>> - a few test failures in wheel building matrix: >>>>> https://github.com/MacPython/scipy-wheels/pull/37 >>>>> - hard-to-understand putative patch for one of the failures: >>>>> https://github.com/scipy/scipy/pull/9486 >>>>> >>>>> On Fri, 9 Nov 2018 at 08:40, Tyler Reddy >>>>> wrote: >>>>> >>>>>> I branched 1.2.x around 8:30 am Pacific time on Nov. 9, 2018. >>>>>> >>>>>> Working on the follow up master branch PR to bump version number / >>>>>> notes file, etc. now. >>>>>> >>>>>> On Thu, 8 Nov 2018 at 22:49, Tyler Reddy >>>>>> wrote: >>>>>> >>>>>>> Release note PR is hopefully taking shape now -- I'll allow >>>>>>> (another) delay for the branch until tomorrow (morning?) for some >>>>>>> (hopefully final) checks on that. >>>>>>> >>>>>>> On Thu, 8 Nov 2018 at 14:35, Tyler Reddy >>>>>>> wrote: >>>>>>> >>>>>>>> There are 0 remaining PRs with a 1.2.0 milestone. >>>>>>>> >>>>>>>> There is one issue left with a 1.2.0 milestone: >>>>>>>> https://github.com/scipy/scipy/issues/9441 >>>>>>>> >>>>>>>> Please do take a look over the release notes WIP PR based on the >>>>>>>> wiki: https://github.com/scipy/scipy/pull/9461 >>>>>>>> >>>>>>>> Target is to branch in 5-6 hours or so. Let me know if you see any >>>>>>>> issues of course -- Ralf has been coaching >>>>>>>> me through pretty well so far I think. >>>>>>>> >>>>>>>> On Wed, 7 Nov 2018 at 09:52, Ilhan Polat >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Hang in there Tyler :) >>>>>>>>> >>>>>>>>> Awesome job so far. >>>>>>>>> >>>>>>>>> >>>>>>>>> On Wed, Nov 7, 2018, 06:08 Ralf Gommers >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Tue, Nov 6, 2018 at 9:03 PM Tyler Reddy < >>>>>>>>>> tyler.je.reddy at gmail.com> wrote: >>>>>>>>>> >>>>>>>>>>> 7 PRs : >>>>>>>>>>> https://github.com/scipy/scipy/pulls?q=is%3Aopen+is%3Apr+milestone%3A1.2.0 >>>>>>>>>>> 3 issues: >>>>>>>>>>> https://github.com/scipy/scipy/issues?q=is%3Aopen+is%3Aissue+milestone%3A1.2.0 >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Awesome, getting there:) >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Target: branch sometime on November 8th >>>>>>>>>>> >>>>>>>>>>> On Mon, 5 Nov 2018 at 05:42, Tyler Reddy < >>>>>>>>>>> tyler.je.reddy at gmail.com> wrote: >>>>>>>>>>> >>>>>>>>>>>> Alright, I'll extend to Thursday Nov. 8th & see if I can reduce >>>>>>>>>>>> that list a bit >>>>>>>>>>>> >>>>>>>>>>>> On Sun, 4 Nov 2018 at 22:27, Ralf Gommers < >>>>>>>>>>>> ralf.gommers at gmail.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Fri, Oct 26, 2018 at 7:03 PM Mark Alexander Mikofski < >>>>>>>>>>>>> mikofski at berkeley.edu> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Hi Tyler and others, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks for managing the v1.2 release. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I think PR #8431, Cython optimize zeros API, is ready, >>>>>>>>>>>>>> hopefully, to merge. It's been through several rounds of reviews and I >>>>>>>>>>>>>> think I've accommodated all of the recommendations, all tests are passing, >>>>>>>>>>>>>> and there's been strong support. Anyone please take a look. >>>>>>>>>>>>>> >>>>>>>>>>>>>> https://github.com/scipy/scipy/pull/8431 >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> Mark >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Fri, Oct 26, 2018, 2:38 PM Ralf Gommers < >>>>>>>>>>>>>> ralf.gommers at gmail.com> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Thu, Oct 25, 2018 at 12:55 PM Tyler Reddy < >>>>>>>>>>>>>>> tyler.je.reddy at gmail.com> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Hi all, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> It is almost 6 months after the 1.1.0 release on May 5, so >>>>>>>>>>>>>>>> probably time to plan the 1.2.0 release. It would be a good idea to look >>>>>>>>>>>>>>>> over the PRs with a 1.2.0 milestone >>>>>>>>>>>>>>>> , >>>>>>>>>>>>>>>> and tag anything else that should have this milestone appropriately. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I'd like to propose the following schedule: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Nov. 5: branch 1.2.x >>>>>>>>>>>>>>>> Nov. 8: rc1 >>>>>>>>>>>>>>>> Nov. 21: rc2 (if needed) >>>>>>>>>>>>>>>> Nov. 30: final release >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thoughts? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> This looks like a good schedule to me. We'll probably >>>>>>>>>>>>>>> struggle to get some PRs marked for 1.2.0 merged, but that's always the >>>>>>>>>>>>>>> case. >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> Hi Tyler, could we shift the branch date by 2-3 days (or up to >>>>>>>>>>>>> a week)? There's a couple of PRs that I'd really like to see merged or >>>>>>>>>>>>> decided on (for optimize and stats mainly), and there's right now still 18 >>>>>>>>>>>>> open PRs marked for 1.2.0. >>>>>>>>>>>>> >>>>>>>>>>>>> A note on the open PRs: what we want to aim for is to have the >>>>>>>>>>>>> list of open PRs and open blocking issues at zero, and have at most some >>>>>>>>>>>>> non-blocking issues under the milestone left. Normally the release manager >>>>>>>>>>>>> starts making those decisions, or pinging people, if other reviewers >>>>>>>>>>>>> haven't done so in time. Of course it would be ideal if everyone has >>>>>>>>>>>>> another look at >>>>>>>>>>>>> https://github.com/scipy/scipy/pulls?q=is%3Aopen+is%3Apr+milestone%3A1.2.0 >>>>>>>>>>>>> and bumps or finished off PRs he/she is involved in. >>>>>>>>>>>>> >>>>>>>>>>>>> Cheers, >>>>>>>>>>>>> Ralf >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> SciPy-Dev mailing list >>>>>>>>>>>>> SciPy-Dev at python.org >>>>>>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev >>>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>> SciPy-Dev mailing list >>>>>>>>>>> SciPy-Dev at python.org >>>>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev >>>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> SciPy-Dev mailing list >>>>>>>>>> SciPy-Dev at python.org >>>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev >>>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> SciPy-Dev mailing list >>>>>>>>> SciPy-Dev at python.org >>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev >>>>>>>>> >>>>>>>> _______________________________________________ >>>>> SciPy-Dev mailing list >>>>> SciPy-Dev at python.org >>>>> https://mail.python.org/mailman/listinfo/scipy-dev >>>>> >>>> _______________________________________________ >>>> SciPy-Dev mailing list >>>> SciPy-Dev at python.org >>>> https://mail.python.org/mailman/listinfo/scipy-dev >>>> >>> _______________________________________________ >>> SciPy-Dev mailing list >>> SciPy-Dev at python.org >>> https://mail.python.org/mailman/listinfo/scipy-dev >>> >> _______________________________________________ >> SciPy-Dev mailing list >> SciPy-Dev at python.org >> https://mail.python.org/mailman/listinfo/scipy-dev >> > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at python.org > https://mail.python.org/mailman/listinfo/scipy-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.gommers at gmail.com Fri Nov 30 01:39:02 2018 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Thu, 29 Nov 2018 22:39:02 -0800 Subject: [SciPy-Dev] Preparing project proposal for GSoC 2019 In-Reply-To: References: Message-ID: On Sun, Nov 25, 2018 at 5:22 AM Sourav Singh wrote: > Hello, > > >> >> On Sat, Nov 24, 2018 at 11:26 AM Ralf Gommers >> wrote: >> >>> Hi Sourav, >>> >>> >>> On Mon, Nov 19, 2018 at 5:47 AM Sourav Singh >>> wrote: >>> >>>> Hello, >>>> >>>> I am writing the mail regarding project proposal for GSoC 2019. >>>> >>>> I am interested in working with SciPy for the upcoming Google Summer of >>>> Code and I am interested in either working on enhancing the randomized >>>> numerical linear algebra functionality or fixing the scipy.fftpack module. >>>> >>>> I understand that it is quite early to talk, since the organization >>>> proposals haven't started yet, but I would like to know if a project >>>> proposal can be started right now so that the proposals can be better >>>> fleshed out by the time the application period starts? >>>> >>> >>> That's the earliest start I've seen (which is a good thing)! >>> >>> I suspect that we'll have trouble finding a mentor for the randomized >>> linear algebra, however fftpack could be a good topic. Have you seen >>> https://github.com/numpy/numpy/pull/11888? I suspect that by the time >>> GSoC starts, we'll have merged that into NumPy, and would like to take it >>> over for SciPy. A related topic would be to add a backend system for fft >>> implementations (pyfftw, mkl-fft). >>> >> >> And a third topic would be to make the APIs of numpy.fft and >> scipy.fftpack agree. That would be the lowest on my list because it's hard >> (requiring lots of discussion on impact on users if we deprecate things >> etc.), but it's an important one as well. >> > > I am interested in adding pocketfft to scipy, which is linked in the numpy > PR. Would it be possible to combine this with the backend system project > for scipy? > Yes, this would be possible - that certainly should fit in a single GSoC. It's also possible that Pocketfft will already be merged by then, given that the author of Pocketfft is quite proactive. The NumPy PR is only waiting for the branching of the 1.16.x release, after which it can in principle be merged (C99 is the blocker now). In that case, implementing a backend system + working on matching signatures for numpy and scipy would still be a nice project. Cheers, Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From oarend at googlemail.com Fri Nov 30 10:50:56 2018 From: oarend at googlemail.com (Oliver Arend) Date: Fri, 30 Nov 2018 16:50:56 +0100 Subject: [SciPy-Dev] PR 9556: Using convex hull centroids instead of tetrahedron circumcenters as Spherical Voronoi vertices In-Reply-To: References: Message-ID: Hello everybody, I started a pull request https://github.com/scipy/scipy/pull/9556 that gives the user the ability to select a method to determine the vertices of a Voronoi tesselation of a spherical surface. I also expanded the tests accordingly. Someone more experienced should please do a code review on it. To see what that kind of difference (or not) it can make, look at e.g. https://www.redblobgames.com/x/1842-delaunay-voronoi-sphere/#voronoi I needed this functionality and found it easiest to just extend the existing scipy.spatial.SphericalVoronoi class. Others might find it useful as well. Oliver From grlee77 at gmail.com Fri Nov 30 15:09:42 2018 From: grlee77 at gmail.com (Gregory Lee) Date: Fri, 30 Nov 2018 15:09:42 -0500 Subject: [SciPy-Dev] Preparing project proposal for GSoC 2019 In-Reply-To: References: Message-ID: On Fri, Nov 30, 2018 at 1:39 AM Ralf Gommers wrote: > > > On Sun, Nov 25, 2018 at 5:22 AM Sourav Singh > wrote: > >> Hello, >> >> >>> >>> On Sat, Nov 24, 2018 at 11:26 AM Ralf Gommers >>> wrote: >>> >>>> Hi Sourav, >>>> >>>> >>>> On Mon, Nov 19, 2018 at 5:47 AM Sourav Singh >>>> wrote: >>>> >>>>> Hello, >>>>> >>>>> I am writing the mail regarding project proposal for GSoC 2019. >>>>> >>>>> I am interested in working with SciPy for the upcoming Google Summer >>>>> of Code and I am interested in either working on enhancing the randomized >>>>> numerical linear algebra functionality or fixing the scipy.fftpack module. >>>>> >>>>> I understand that it is quite early to talk, since the organization >>>>> proposals haven't started yet, but I would like to know if a project >>>>> proposal can be started right now so that the proposals can be better >>>>> fleshed out by the time the application period starts? >>>>> >>>> >>>> That's the earliest start I've seen (which is a good thing)! >>>> >>>> I suspect that we'll have trouble finding a mentor for the randomized >>>> linear algebra, however fftpack could be a good topic. Have you seen >>>> https://github.com/numpy/numpy/pull/11888? I suspect that by the time >>>> GSoC starts, we'll have merged that into NumPy, and would like to take it >>>> over for SciPy. A related topic would be to add a backend system for fft >>>> implementations (pyfftw, mkl-fft). >>>> >>> >>> And a third topic would be to make the APIs of numpy.fft and >>> scipy.fftpack agree. That would be the lowest on my list because it's hard >>> (requiring lots of discussion on impact on users if we deprecate things >>> etc.), but it's an important one as well. >>> >> >> I am interested in adding pocketfft to scipy, which is linked in the >> numpy PR. Would it be possible to combine this with the backend system >> project for scipy? >> > > Yes, this would be possible - that certainly should fit in a single GSoC. > It's also possible that Pocketfft will already be merged by then, given > that the author of Pocketfft is quite proactive. The NumPy PR is only > waiting for the branching of the 1.16.x release, after which it can in > principle be merged (C99 is the blocker now). In that case, implementing a > backend system + working on matching signatures for numpy and scipy would > still be a nice project. > > Cheers, > Ralf > I would be happy to help mentor an FFT-related project and think having a backend system would be very nice. pyFFTW's scipy interfaces are mostly complete, aside from some real-valued transforms for which work was started in: https://github.com/pyFFTW/pyFFTW/pull/95 There were also GPU-based FFTs matching the scipy API proposed recently in https://github.com/cupy/cupy/pull/1745 -------------- next part -------------- An HTML attachment was scrubbed... URL: