From evgeny.burovskiy at gmail.com Wed Mar 1 08:59:13 2017 From: evgeny.burovskiy at gmail.com (Evgeni Burovski) Date: Wed, 1 Mar 2017 16:59:13 +0300 Subject: [SciPy-Dev] GSoC17 - Question about candidacy In-Reply-To: References: Message-ID: On Tue, Feb 28, 2017 at 2:38 PM, ??????? ?????? wrote: > Dear developers > > I'm Yevhenii Hyzyla and I'm an undergraduate student from Taras Shevchenko > National University of Kyiv in Ukraine. I don't have any experience of open > source contributing, but I want to start this way from SciPy. I have good > knowledge of Python (some small pet project) and C on sufficient level > (university course). Also, I have an experience of working with SciPy > library and SciPy stack in general. > > After seeing the wiki page with ideas and I think I could develop > scipy.diff, because I have good knowledge about differential and how to > calculate them using numerical or symbolic methods. (I had courses at > university from Mathematical analysis and Numerical analysis). And my > hobbies are Math and Python. > > 1) If I make some patches to scipy, what chance of being accepted will be? > 2) How many students applies to scipy each year? > Could I get feedback about my candidacy from developers? > > Thank for reading! > > Yevhenii Hi Yevhenii, Glad to see your interest in this project! It's a bit hard to say anything about chances at this point. It'll depend on several things: the number and quality of applications, the availability of mentors, and so on. Our selection process relies a lot on the project proposals. From experience, writing a good proposal takes several iterations. I thus encourage you to write the first iteration and send it to this list. Cheers, Evgeni From aditya.dpsg.15 at gmail.com Wed Mar 1 09:06:44 2017 From: aditya.dpsg.15 at gmail.com (Aditya Singh) Date: Wed, 1 Mar 2017 19:36:44 +0530 Subject: [SciPy-Dev] GSoC 2017 Project- scipy.diff(numerical differentiation) Message-ID: Hello Developers! I am a GSoC enthusiast! any tips on how to begin? I am particularly interested in the project - " Implement scipy.diff(numerical differentiation) " Also this is the first time I am contributing to SciPy, so I need some help getting started! -------------- next part -------------- An HTML attachment was scrubbed... URL: From evgeny.burovskiy at gmail.com Wed Mar 1 09:20:05 2017 From: evgeny.burovskiy at gmail.com (Evgeni Burovski) Date: Wed, 1 Mar 2017 17:20:05 +0300 Subject: [SciPy-Dev] Interested in contributing BILP solver and interior-point method for linprog; SciPy-dev search down? In-Reply-To: References: <20170222070745.GI3818748@phare.normalesup.org> <2ad3a609-d29d-205e-ccfe-5151c9202261@crans.org> Message-ID: On Wed, Mar 1, 2017 at 2:01 AM, Matt Haberland wrote: > Based on positive feedback, I've gone ahead and completed most of the > finishing touches: documentation, pep8 compliance, etc... for the > "interior-point" method of linprog. > > As this is my first contribution to SciPy, I would appreciate a real-time > conversation with somebody regarding some remaining questions. Would an > experienced contributor, like whomever might review the forthcoming pull > request, be willing to schedule a time to chat? > > Thanks! > Matt > > -------- > > P.S. Example questions: > > How strict does PEP8 compliance need to be? For instance, do I really need > to replace lambda functions (defined within functions) with regular > functions? (There are a few other things autopep8 couldn't fix I want to ask > about.) > The code currently spits out warnings using the standard warnings module. Is > that OK or is there some other standard for SciPy? Does there need to to be > an option to disable these, or can we let the user suppress them otherwise > if desired? > I have a several non-essential feature questions like "Do I need to > implement a callback interface like the simplex method does, or can that be > left for an update?" Some of these are technical but each can be explained > with about one sentence of background information. I'm just looking for > opinions from anyone willing to think about it for 10 seconds. > > P.P.S. Re: Pierre's comment: regarding lack of accuracy, you mean when > linprog fails to find a solution when it exists or reports that it has found > a solution when it hasn't? Agreed, I think the interior point method would > help fix that. And its presolve subroutine could help the simplex code avoid > some of those problems. > > However because the simplex method traverses vertices to numerical > precision, its solutions (when it finds them) will typically be more > "exact", whereas interior point methods terminate when a user specified > tolerance is met. Along those lines, interior point methods can return > solutions at the boundary of the polytope but not at a vertex, and so they > do not always identify an optimal basis, which some applications require. > There are "crossover" methods to do this from an interior point solution but > I haven't looked into those yet. > > For that reason, and to allow time for any bugs with the IP code to surface, > should "simplex" remain the default, if the linprog documentation were to > state that "interior-point" could be faster? Hi Matt, Our development process is quite asynchronous at this time, so please don't be discouraged if you don't get much responses about a real-time conversation. It's just that we are spread quite thin all across the globe. Since your code is at the polishing stage already, a way forward can be to send a work-in-progress pull request on GitHub already. This will both give you feedback about style things like pep8 (we have a specialized checker which runs automatically on new PRs), and will hopefully help to attract reviewers. The PR does not need to be perfect from the start, most PRs go over a series of iterations anyway. Cheers, Evgeni From ralf.gommers at gmail.com Thu Mar 2 06:18:20 2017 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Fri, 3 Mar 2017 00:18:20 +1300 Subject: [SciPy-Dev] GSoC'17 candidate - Interested in Nose to Pytest Migration. In-Reply-To: References: <085705b7-ae6c-7fb0-478d-c9f33a13b8b2@mixmax.com>

Message-ID: On Wed, Mar 1, 2017 at 8:01 AM, Robert Kern wrote: > On Tue, Feb 28, 2017 at 1:31 AM, Ralf Gommers > wrote: > > > > On Tue, Feb 28, 2017 at 12:08 PM, Robert Kern > wrote: > >> > >> On Mon, Feb 27, 2017 at 2:32 PM, Charles R Harris < > charlesr.harris at gmail.com> wrote: > >> > > >> > > >> > > >> > On Mon, Feb 27, 2017 at 2:35 PM, Robert Kern > wrote: > >> >> > >> >> On Mon, Feb 27, 2017 at 1:03 PM, Pauli Virtanen wrote: > >> >> > > >> >> > Mon, 27 Feb 2017 19:13:48 +0300, Evgeni Burovski kirjoitti: > >> >> > [clip] > >> >> > > A few scattered thoughts about the project: > >> >> > > > >> >> > > - This is not exactly a transition to pytest as such. The goal > is to > >> >> > > allow an alternative test runner, with minimal changes to the > test > >> >> > > suite. > >> >> > > >> >> > I'd suggest we should consider actually dropping nose, if we make > the > >> >> > suite pytest compatible. > >> >> > > >> >> > I think retaining nose compatibility in the numpy/scipy test > suites does > >> >> > not bring advantages --- if we are planning to retain it, I would > like to > >> >> > understand why. Supporting two systems is more complicated, makes > it > >> >> > harder to add new tests, and if the other one is not regularly > used, > >> >> > it'll probably break often. > >> >> > > >> >> > I think we should avoid temptation to build compatibility layers, > or > >> >> > custom test runners --- there's already complication in > numpy.testing > >> >> > that IIRC originates from working around issues in nose, and I > think not > >> >> > many remember how it works in depth. > >> >> > > >> >> > I think the needs for Scipy and Numpy are not demanding, so > sticking with > >> >> > "vanilla" pytest features and using only its native test runner > would > >> >> > sound best. The main requirement is numerical assert functions, > but AFAIK > >> >> > the ones in numpy.testing are pytest compatible (and independent > of the > >> >> > nose machinery). > >> >> > >> >> If we're migrating test runners, I'd rather drop all dependencies > and target `python -m unittest discover` as the lowest common denominator > rather than target a fuzzy "vanilla" subset of pytest in particular. > >> > > >> > I'd certainly expect to make full use of the pytest features, why use > it otherwise? There is a reason that both nose and pytest extended > unittest. The only advantage I see to unittest is that it is less likely to > become abandon ware. > >> > >> Well, that's definitely not what Pauli was advocating, and my response > was intending to clarify his position. > >> > >> >> This may well be the technical effect of what you are describing, > but I think it's worth explicitly stating that focus. > >> > > >> > I don't think that us where we were headed. Can you make the case for > unittest? > >> > >> There are two places where nose and pytest provide features; they are > each a *test runner* and also a *test framework*. As a test runner, they > provide features for discovering tests (essentially, they let you easily > point to a subset of tests to run) and reporting the test results in a > variety of user-friendly ways. Test discovery functionality works with > plain-old-TestCases, and pretty much any test runner works with the > plain-old-TestCases. These features face the user who is *running* the > tests. > >> > >> The other place they provide features is as test frameworks. This is > where things like the generator tests and additional fixtures come in (i.e. > setup_class, setup_module, etc.). These require you to write your tests in > framework-specific ways. Those written for nose don't necessarily work with > those written for pytest and vice versa. And any other plain test runner is > right out. These features face the developer who is *writing* the tests. > >> > >> Test discovery was the main reason we started using nose over plain > unittest. At that time (and incidentally, when nose and pytest began), > `python -m unittest discover` didn't exist. > > > > As Josef said, "import scipy; scipy.test()" must work (always useful, > but especially important on Windows). > > Okay. And? > No and, just pointing out that `python -m unittest discover` doesn't cut it. > >> To run unit tests, you had to manually collect the TestCases into a > TestSuite and write your own logic for configuring any subsets from user > input. It was a pain in the ass for large hierarchical packages like numpy > and scipy. The test framework features of nose like generator tests were > nice bonuses, but were not the main motivating factor. [Source: me; it was > Jarrod and I who made the decision to use nose at a numpy sprint in > Berkeley.] > >> > >> If we're going to make a switch, I'd rather give up those framework > features (we don't use all that many) in order to get agnosticism on the > test runner front. Being agnostic to the test runner lets us optimize for > multiple use cases simultaneously. That is, the best test runner for "run > the whole suite and record every detail with coverage under time > constraints under Travis CI" is often different from what a developer wants > for "run just the one test module for the thing I'm working on and report > to me only what breaks as fast as possible with minimal clutter". > > > > I don't believe we can live with just plain unittest, we want to move to > a better maintained framework and gain some features in this GSoC project, > not go backwards in functionality. > > Ah, okay. The way the project abstract is written, this is not clear. It > reads as if you want pytest as a mere additional possible test runner > alongside nose. Instead, it seems that you want to migrate away from nose > and to pytest, wholesale. I'm fine with that. But get Pauli on board with > going beyond "vanilla" pytest and rewrite the abstract. Drop the bit about > ideally running the test suite with both nose and pytest. > Fair point. Will try to clean up the abstract over the weekend. > If you're looking to gain functionality, there's no point, just > maintenance headaches. If you want some runner-agnosticism, then unittest > is the layer to do it on. Maintaining runner-agnosticism for just two > runners (only one of which is maintained) is a wasted opportunity. That's > my main contention. > You're right. Runner agnosticism is not what we were aiming at, but if we were then it'd probably have to be plain unittest. Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From karandesai281196 at gmail.com Thu Mar 2 06:30:24 2017 From: karandesai281196 at gmail.com (Karan Desai) Date: Thu, 02 Mar 2017 11:30:24 +0000 Subject: [SciPy-Dev] GSoC'17 candidate - Interested in Nose to Pytest Migration. In-Reply-To: References: <085705b7-ae6c-7fb0-478d-c9f33a13b8b2@mixmax.com>

Message-ID: <0f0e1e24-c88d-a71c-3100-02016158b76e@mixmax.com> Hello developers, I was out of town for a while. Came back to see there's quite a lot of discussion on this idea. Just to acknowledge that it'll take time for me to process all the information above. I'll give in my inputs to discussion or contribute a patch directly in near time. Regards,Karan. On Thu, Mar 2, 2017 4:48 PM, Ralf Gommers ralf.gommers at gmail.com wrote: On Wed, Mar 1, 2017 at 8:01 AM, Robert Kern wrote: On Tue, Feb 28, 2017 at 1:31 AM, Ralf Gommers wrote: > > On Tue, Feb 28, 2017 at 12:08 PM, Robert Kern wrote: >> >> On Mon, Feb 27, 2017 at 2:32 PM, Charles R Harris wrote: >> > >> > >> > >> > On Mon, Feb 27, 2017 at 2:35 PM, Robert Kern wrote: >> >> >> >> On Mon, Feb 27, 2017 at 1:03 PM, Pauli Virtanen wrote: >> >> > >> >> > Mon, 27 Feb 2017 19:13:48 +0300, Evgeni Burovski kirjoitti: >> >> > [clip] >> >> > > A few scattered thoughts about the project: >> >> > > >> >> > > - This is not exactly a transition to pytest as such. The goal is to >> >> > > allow an alternative test runner, with minimal changes to the test >> >> > > suite. >> >> > >> >> > I'd suggest we should consider actually dropping nose, if we make the >> >> > suite pytest compatible. >> >> > >> >> > I think retaining nose compatibility in the numpy/scipy test suites does >> >> > not bring advantages --- if we are planning to retain it, I would like to >> >> > understand why. Supporting two systems is more complicated, makes it >> >> > harder to add new tests, and if the other one is not regularly used, >> >> > it'll probably break often. >> >> > >> >> > I think we should avoid temptation to build compatibility layers, or >> >> > custom test runners --- there's already complication in numpy.testing >> >> > that IIRC originates from working around issues in nose, and I think not >> >> > many remember how it works in depth. >> >> > >> >> > I think the needs for Scipy and Numpy are not demanding, so sticking with >> >> > "vanilla" pytest features and using only its native test runner would >> >> > sound best. The main requirement is numerical assert functions, but AFAIK >> >> > the ones in numpy.testing are pytest compatible (and independent of the >> >> > nose machinery). >> >> >> >> If we're migrating test runners, I'd rather drop all dependencies and target `python -m unittest discover` as the lowest common denominator rather than target a fuzzy "vanilla" subset of pytest in particular. >> > >> > I'd certainly expect to make full use of the pytest features, why use it otherwise? There is a reason that both nose and pytest extended unittest. The only advantage I see to unittest is that it is less likely to become abandon ware. >> >> Well, that's definitely not what Pauli was advocating, and my response was intending to clarify his position. >> >> >> This may well be the technical effect of what you are describing, but I think it's worth explicitly stating that focus. >> > >> > I don't think that us where we were headed. Can you make the case for unittest? >> >> There are two places where nose and pytest provide features; they are each a *test runner* and also a *test framework*. As a test runner, they provide features for discovering tests (essentially, they let you easily point to a subset of tests to run) and reporting the test results in a variety of user-friendly ways. Test discovery functionality works with plain-old-TestCases, and pretty much any test runner works with the plain-old-TestCases. These features face the user who is *running* the tests. >> >> The other place they provide features is as test frameworks. This is where things like the generator tests and additional fixtures come in (i.e. setup_class, setup_module, etc.). These require you to write your tests in framework-specific ways. Those written for nose don't necessarily work with those written for pytest and vice versa. And any other plain test runner is right out. These features face the developer who is *writing* the tests. >> >> Test discovery was the main reason we started using nose over plain unittest. At that time (and incidentally, when nose and pytest began), `python -m unittest discover` didn't exist. > > As Josef said, "import scipy; scipy.test()" must work (always useful, but especially important on Windows). Okay. And? No and, just pointing out that `python -m unittest discover` doesn't cut it. >> To run unit tests, you had to manually collect the TestCases into a TestSuite and write your own logic for configuring any subsets from user input. It was a pain in the ass for large hierarchical packages like numpy and scipy. The test framework features of nose like generator tests were nice bonuses, but were not the main motivating factor. [Source: me; it was Jarrod and I who made the decision to use nose at a numpy sprint in Berkeley.] >> >> If we're going to make a switch, I'd rather give up those framework features (we don't use all that many) in order to get agnosticism on the test runner front. Being agnostic to the test runner lets us optimize for multiple use cases simultaneously. That is, the best test runner for "run the whole suite and record every detail with coverage under time constraints under Travis CI" is often different from what a developer wants for "run just the one test module for the thing I'm working on and report to me only what breaks as fast as possible with minimal clutter". > > I don't believe we can live with just plain unittest, we want to move to a better maintained framework and gain some features in this GSoC project, not go backwards in functionality. Ah, okay. The way the project abstract is written, this is not clear. It reads as if you want pytest as a mere additional possible test runner alongside nose. Instead, it seems that you want to migrate away from nose and to pytest, wholesale. I'm fine with that. But get Pauli on board with going beyond "vanilla" pytest and rewrite the abstract. Drop the bit about ideally running the test suite with both nose and pytest. Fair point. Will try to clean up the abstract over the weekend. If you're looking to gain functionality, there's no point, just maintenance headaches. If you want some runner-agnosticism, then unittest is the layer to do it on. Maintaining runner-agnosticism for just two runners (only one of which is maintained) is a wasted opportunity. That's my main contention. You're right. Runner agnosticism is not what we were aiming at, but if we were then it'd probably have to be plain unittest. Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.gommers at gmail.com Thu Mar 2 06:54:08 2017 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Fri, 3 Mar 2017 00:54:08 +1300 Subject: [SciPy-Dev] Interested in contributing BILP solver and interior-point method for linprog; SciPy-dev search down? In-Reply-To: References: <20170222070745.GI3818748@phare.normalesup.org> <2ad3a609-d29d-205e-ccfe-5151c9202261@crans.org> Message-ID: On Thu, Mar 2, 2017 at 3:20 AM, Evgeni Burovski wrote: > On Wed, Mar 1, 2017 at 2:01 AM, Matt Haberland wrote: > > Based on positive feedback, I've gone ahead and completed most of the > > finishing touches: documentation, pep8 compliance, etc... for the > > "interior-point" method of linprog. > > > > As this is my first contribution to SciPy, I would appreciate a real-time > > conversation with somebody regarding some remaining questions. Would an > > experienced contributor, like whomever might review the forthcoming pull > > request, be willing to schedule a time to chat? > > > > Thanks! > > Matt > > > > -------- > > > > P.S. Example questions: > > > > How strict does PEP8 compliance need to be? For instance, do I really > need > > to replace lambda functions (defined within functions) with regular > > functions? (There are a few other things autopep8 couldn't fix I want to > ask > > about.) > > The code currently spits out warnings using the standard warnings > module. Is > > that OK or is there some other standard for SciPy? Does there need to to > be > > an option to disable these, or can we let the user suppress them > otherwise > > if desired? > > I have a several non-essential feature questions like "Do I need to > > implement a callback interface like the simplex method does, or can that > be > > left for an update?" Some of these are technical but each can be > explained > > with about one sentence of background information. I'm just looking for > > opinions from anyone willing to think about it for 10 seconds. > > > > P.P.S. Re: Pierre's comment: regarding lack of accuracy, you mean when > > linprog fails to find a solution when it exists or reports that it has > found > > a solution when it hasn't? Agreed, I think the interior point method > would > > help fix that. And its presolve subroutine could help the simplex code > avoid > > some of those problems. > > > > However because the simplex method traverses vertices to numerical > > precision, its solutions (when it finds them) will typically be more > > "exact", whereas interior point methods terminate when a user specified > > tolerance is met. Along those lines, interior point methods can return > > solutions at the boundary of the polytope but not at a vertex, and so > they > > do not always identify an optimal basis, which some applications require. > > There are "crossover" methods to do this from an interior point solution > but > > I haven't looked into those yet. > > > > For that reason, and to allow time for any bugs with the IP code to > surface, > > should "simplex" remain the default, if the linprog documentation were to > > state that "interior-point" could be faster? > > > Hi Matt, > > Our development process is quite asynchronous at this time, so please > don't be discouraged if you don't get much responses about a real-time > conversation. It's just that we are spread quite thin all across the > globe. > > Since your code is at the polishing stage already, a way forward can > be to send a work-in-progress pull request on GitHub already. +1 for submitting what you have already (start the PR title with WIP: ), always good to get people to comment on it. I'm happy to have a quick chat though if you prefer that. I'm 21 hours ahead of you; my 8-9am (your 11-12am) works well if you ping me in advance. Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.kern at gmail.com Thu Mar 2 13:06:19 2017 From: robert.kern at gmail.com (Robert Kern) Date: Thu, 2 Mar 2017 10:06:19 -0800 Subject: [SciPy-Dev] GSoC'17 candidate - Interested in Nose to Pytest Migration. In-Reply-To: References: <085705b7-ae6c-7fb0-478d-c9f33a13b8b2@mixmax.com>

Message-ID: On Thu, Mar 2, 2017 at 3:18 AM, Ralf Gommers wrote: > > On Wed, Mar 1, 2017 at 8:01 AM, Robert Kern wrote: >> >> On Tue, Feb 28, 2017 at 1:31 AM, Ralf Gommers wrote: >> > >> > On Tue, Feb 28, 2017 at 12:08 PM, Robert Kern wrote: >> >> Test discovery was the main reason we started using nose over plain unittest. At that time (and incidentally, when nose and pytest began), `python -m unittest discover` didn't exist. >> > >> > As Josef said, "import scipy; scipy.test()" must work (always useful, but especially important on Windows). >> >> Okay. And? > > No and, just pointing out that `python -m unittest discover` doesn't cut it. Ah, I see. When I wrote that, I didn't mean that we'd type in `python -m unittest discover` all the time. I was just referring to modern unittest's builtin test discovery functionality, which makes it a feasible tool to underlie `scipy.test()`. If that had existed at the time, we likely wouldn't have rewritten `scipy.test()` to use nose. -- Robert Kern -------------- next part -------------- An HTML attachment was scrubbed... URL: From evgeny.zhurko at gmail.com Thu Mar 2 19:59:36 2017 From: evgeny.zhurko at gmail.com (Evgeny Zhurko) Date: Fri, 3 Mar 2017 03:59:36 +0300 Subject: [SciPy-Dev] Owen's T function Message-ID: Hi all, I started implementing Owen's T function( https://github.com/scipy/scipy/pull/7120). I have implemented Omen's T1, T2, T4,T6 from "Fast and accurate calculation of Owen's T Function ( https://www.jstatsoft.org/article/view/v005i05/t.pdf) already(not pushed yet). I have problem with T3 and T5. I can't evaluate C2i - obtained from the coefficients of Chebyshes polynomials in T3 and can't evaluate Wi - wieghts and Xi - values of abcissas. As i see in Boost library, they doesn't evaluate C2i, Wi, Xi(constants in source). Maybe someone know how i can evaluate it using scipy or numpy? Best Regards, Evgeny Zhurko -------------- next part -------------- An HTML attachment was scrubbed... URL: From josh.craig.wilson at gmail.com Thu Mar 2 21:02:13 2017 From: josh.craig.wilson at gmail.com (Joshua Wilson) Date: Thu, 2 Mar 2017 20:02:13 -0600 Subject: [SciPy-Dev] Owen's T function In-Reply-To: References: Message-ID: Why not borrow the constants from the Boost source? (Boost is license compatible.) On Thu, Mar 2, 2017 at 6:59 PM, Evgeny Zhurko wrote: > Hi all, > > I started implementing Owen's T > function(https://github.com/scipy/scipy/pull/7120). I have implemented > Omen's T1, T2, T4,T6 from "Fast and accurate calculation of Owen's T > Function (https://www.jstatsoft.org/article/view/v005i05/t.pdf) already(not > pushed yet). > I have problem with T3 and T5. I can't evaluate C2i - obtained from the > coefficients of Chebyshes > polynomials in T3 and can't evaluate Wi - wieghts and Xi - values of > abcissas. > As i see in Boost library, they doesn't evaluate C2i, Wi, Xi(constants in > source). > > Maybe someone know how i can evaluate it using scipy or numpy? > > Best Regards, > Evgeny Zhurko > > > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > https://mail.scipy.org/mailman/listinfo/scipy-dev > From evgeny.zhurko at gmail.com Fri Mar 3 17:54:38 2017 From: evgeny.zhurko at gmail.com (Evgeny Zhurko) Date: Sat, 4 Mar 2017 01:54:38 +0300 Subject: [SciPy-Dev] Owen's T function Message-ID: Maybe someone have borrowed constants before me but i didn't found it. I included all constant and test data from Boost in last commit. But i have new questions: I implemented T1-T6 methods and tried test function on Boost's test data. All tests passed when i use assert_almost_equal with decimal=1. About 30 of 400 examples have deviation 0.01 from real value, 40 of 400 examples have deviation about 1e-10 and the others less then 1e-18. Boost have improvement for some methods ( http://www.boost.org/doc/libs/1_52_0/boost/math/special_functions/owens_t.hpp). Is it enough to insert copyright in source code if i'll implement this algorithm into Scipy? Test data have a very big size(about 100 character per number). I inserted data into test_basic.py . May I move test data into txt or csv file and read it in tests? Is it requires including copyright into file with test data? Test data from Boost not cover all methods(only T2, T4) as a result I want to use Owen, Donald B. "Tables for Computing Bivariate Normal Probabilities." ( http://projecteuclid.org/download/pdf_1/euclid.aoms/1177728074). Pull request: https://github.com/scipy/scipy/pull/7120 -------------- next part -------------- An HTML attachment was scrubbed... URL: From josh.craig.wilson at gmail.com Fri Mar 3 18:04:42 2017 From: josh.craig.wilson at gmail.com (Joshua Wilson) Date: Fri, 3 Mar 2017 17:04:42 -0600 Subject: [SciPy-Dev] Owen's T function In-Reply-To: References: Message-ID: > All tests passed when i use assert_almost_equal with decimal=1 Don't measure accuracy by decimals--with special functions getting a small relative error is more important. In general a relative error of 1e-11 to 1e-14 or so is a good target. Sometimes there are good reasons why one can't achieve a relative error that small (such as a zero of a function). > Is it enough to insert copyright in source code if i'll implement this algorithm into Scipy? That should be fine. > I inserted data into test_basic.py You want to use the framework in `test_data.py`. On Fri, Mar 3, 2017 at 4:54 PM, Evgeny Zhurko wrote: > Maybe someone have borrowed constants before me but i didn't found it. I > included all constant and test data from Boost in last commit. > > But i have new questions: > > I implemented T1-T6 methods and tried test function on Boost's test data. > All tests passed when i use assert_almost_equal with decimal=1. About 30 of > 400 examples have deviation 0.01 from real value, 40 of 400 examples have > deviation about 1e-10 and the others less then 1e-18. Boost have improvement > for some methods > (http://www.boost.org/doc/libs/1_52_0/boost/math/special_functions/owens_t.hpp). > Is it enough to insert copyright in source code if i'll implement this > algorithm into Scipy? > > Test data have a very big size(about 100 character per number). I inserted > data into test_basic.py . May I move test data into txt or csv file and read > it in tests? Is it requires including copyright into file with test data? > > Test data from Boost not cover all methods(only T2, T4) as a result I want > to use > Owen, Donald B. "Tables for Computing Bivariate Normal Probabilities." > (http://projecteuclid.org/download/pdf_1/euclid.aoms/1177728074). > > Pull request: https://github.com/scipy/scipy/pull/7120 > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > https://mail.scipy.org/mailman/listinfo/scipy-dev > From charlesr.harris at gmail.com Mon Mar 6 22:57:25 2017 From: charlesr.harris at gmail.com (Charles R Harris) Date: Mon, 6 Mar 2017 20:57:25 -0700 Subject: [SciPy-Dev] NumPy pre-release 1.12.1rc1 Message-ID: Hi All, I'm pleased to announce the release of NumPy 1.12.1rc1. NumPy 1.12.1rc1 supports Python 2.7 and 3.4 - 3.6 and fixes bugs and regressions found in NumPy 1.12.0. In particular, the regression in f2py constant parsing is fixed. Wheels for Linux, Windows, and OSX can be found on pypi. Archives can be downloaded from github . *Contributors* A total of 10 people contributed to this release. People with a "+" by their names contributed a patch for the first time. * Charles Harris * Eric Wieser * Greg Young * Joerg Behrmann + * John Kirkham * Julian Taylor * Marten van Kerkwijk * Matthew Brett * Shota Kawabuchi * Jean Utke + *Fixes Backported* * #8483: BUG: Fix wrong future nat warning and equiv type logic error... * #8489: BUG: Fix wrong masked median for some special cases * #8490: DOC: Place np.average in inline code * #8491: TST: Work around isfinite inconsistency on i386 * #8494: BUG: Guard against replacing constants without `'_'` spec in f2py. * #8524: BUG: Fix mean for float 16 non-array inputs for 1.12 * #8571: BUG: Fix calling python api with error set and minor leaks for... * #8602: BUG: Make iscomplexobj compatible with custom dtypes again * #8618: BUG: Fix undefined behaviour induced by bad `__array_wrap__` * #8648: BUG: Fix `MaskedArray.__setitem__` * #8659: BUG: PPC64el machines are POWER for Fortran in f2py * #8665: BUG: Look up methods on MaskedArray in `_frommethod` * #8674: BUG: Remove extra digit in `binary_repr` at limit * #8704: BUG: Fix deepcopy regression for empty arrays. * #8707: BUG: Fix ma.median for empty ndarrays Cheers, Chuck -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.gommers at gmail.com Tue Mar 7 16:01:15 2017 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Wed, 8 Mar 2017 10:01:15 +1300 Subject: [SciPy-Dev] Fwd: Docathon Day 1 Update: The Doccening In-Reply-To: <80bb9d960ec9c9896a0cf4b96.2abb39d3c3.20170307025755.cfdc895f86.b6ed6565@mail225.atl121.mcsv.net> References: <80bb9d960ec9c9896a0cf4b96.2abb39d3c3.20170307025755.cfdc895f86.b6ed6565@mail225.atl121.mcsv.net> Message-ID: Hi all, The docathlon has started, and Warren got us off the mark with https://github.com/scipy/scipy/pull/7138 (thanks!). If you want to contribute, an easy way is what Warren did: pick a function with an incomplete docstring (e.g. missing example) and add it. Alternatively, look at one of the issues with the documentation label: https://github.com/scipy/scipy/issues?q=is%3Aopen+is%3Aissue+label%3ADocumentation And remember to start your commit message with DOC:. Cheers, Ralf ---------- Forwarded message ---------- From: The Docathon Team Date: Tue, Mar 7, 2017 at 3:58 PM Subject: Docathon Day 1 Update: The Doccening To: ralf.gommers at gmail.com *To err is human, to document is divine -Docrates* The Docathon is One Day Old! The docathon just turned one (day old)! Here's a quick update to congratulate everybody on a great first day. Updates - We kicked off the week at BIDS by hosting a half-day of Documentation Tutorials . These were live-streamed on youtube for your viewing pleasure! - We also demoed a template repository to help you get sphinx / numpydoc / sphinx-gallery working with your project. Use that along with this guide repository to help you get started! Check out the docboards! My favorite thing about today is that you can totally see a bump in the documentation commits for our projects. You can check that out on our global activity board below: *Global Activity* We should also give a shout out to our docstar projects that showed a big bump in activity today. Here's our docboard for project commits: Three cheers for: - PMagPy , a python project for analyzing paleomagnetic data - cottoncandy , a project for storing and flexibly accessing numpy data on Amazon S3. - Sylius , a platform for e-commerce using PHP We also got a big bump in commits from individual users! Here's what everybody has been up to: Let's give a shout out to this day's docstars *anwarnunez*, *willingc*, and *swanson-hysell*. Keep it going! We look forward to seeing what comes next tomorrow. The working groups will be holding sessions once again, though we've gotten a lot of great contributions from people all over the country! We're making great progress, so let's keep the momentum through tomorrow! Until then, *The Docathon Team* Docathon website Projects page Hosts page Slack channel Github repo all hail the party parrot [image: Email Marketing Powered by MailChimp] All hail the party parrot. Want to change how you receive these emails? You can update your preferences or unsubscribe from this list -------------- next part -------------- An HTML attachment was scrubbed... URL: From sturla.molden at gmail.com Wed Mar 8 08:34:45 2017 From: sturla.molden at gmail.com (Sturla Molden) Date: Wed, 8 Mar 2017 14:34:45 +0100 Subject: [SciPy-Dev] Drop i386 part of OSX wheel build? In-Reply-To: References: Message-ID: On 24/02/2017 19:51, Matthew Brett wrote: > The main reason for this is that, for OSX, we are building twice, > first for i386, then for x86_64, and then combining these builds into > a 'fat' binary to be compatible with either architecture. The builds > take a long time, hence the timeout. With only amd64 (x86_64) we can also use a recent gfortran to build SciPy, e.g. a binary from the GCC wiki. Sturla From evgeny.burovskiy at gmail.com Thu Mar 9 10:54:31 2017 From: evgeny.burovskiy at gmail.com (Evgeni Burovski) Date: Thu, 9 Mar 2017 18:54:31 +0300 Subject: [SciPy-Dev] ANN: SciPy 0.19.0 Message-ID: On behalf of the Scipy development team I am pleased to announce the availability of Scipy 0.19.0. This release contains several great new features and a large number of bug fixes and various improvements, as detailed in the release notes below. 121 people contributed to this release over the course of seven months. Thanks to everyone who contributed! This release requires Python 2.7 or 3.4-3.6 and NumPy 1.8.2 or greater. Source tarballs and release notes can be found at https://github.com/scipy/scipy/releases/tag/v0.19.0. OS X and Linux wheels are available from PyPI. For security-conscious, the wheels themselves are signed with my GPG key. Additionally, you can checksum the wheels and verify the checksums with those listed below or in the README file at https://github.com/scipy/scipy/releases/tag/v0.19.0. Cheers, Evgeni -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 ========================== SciPy 0.19.0 Release Notes ========================== .. contents:: SciPy 0.19.0 is the culmination of 7 months of hard work. It contains many new features, numerous bug-fixes, improved test coverage and better documentation. There have been a number of deprecations and API changes in this release, which are documented below. All users are encouraged to upgrade to this release, as there are a large number of bug-fixes and optimizations. Moreover, our development attention will now shift to bug-fix releases on the 0.19.x branch, and on adding new features on the master branch. This release requires Python 2.7 or 3.4-3.6 and NumPy 1.8.2 or greater. Highlights of this release include: - - A unified foreign function interface layer, `scipy.LowLevelCallable`. - - Cython API for scalar, typed versions of the universal functions from the `scipy.special` module, via `cimport scipy.special.cython_special`. New features ============ Foreign function interface improvements - --------------------------------------- `scipy.LowLevelCallable` provides a new unified interface for wrapping low-level compiled callback functions in the Python space. It supports Cython imported "api" functions, ctypes function pointers, CFFI function pointers, ``PyCapsules``, Numba jitted functions and more. See `gh-6509 `_ for details. `scipy.linalg` improvements - --------------------------- The function `scipy.linalg.solve` obtained two more keywords ``assume_a`` and ``transposed``. The underlying LAPACK routines are replaced with "expert" versions and now can also be used to solve symmetric, hermitian and positive definite coefficient matrices. Moreover, ill-conditioned matrices now cause a warning to be emitted with the estimated condition number information. Old ``sym_pos`` keyword is kept for backwards compatibility reasons however it is identical to using ``assume_a='pos'``. Moreover, the ``debug`` keyword, which had no function but only printing the ``overwrite_`` values, is deprecated. The function `scipy.linalg.matrix_balance` was added to perform the so-called matrix balancing using the LAPACK xGEBAL routine family. This can be used to approximately equate the row and column norms through diagonal similarity transformations. The functions `scipy.linalg.solve_continuous_are` and `scipy.linalg.solve_discrete_are` have numerically more stable algorithms. These functions can also solve generalized algebraic matrix Riccati equations. Moreover, both gained a ``balanced`` keyword to turn balancing on and off. `scipy.spatial` improvements - ---------------------------- `scipy.spatial.SphericalVoronoi.sort_vertices_of_regions` has been re-written in Cython to improve performance. `scipy.spatial.SphericalVoronoi` can handle > 200 k points (at least 10 million) and has improved performance. The function `scipy.spatial.distance.directed_hausdorff` was added to calculate the directed Hausdorff distance. ``count_neighbors`` method of `scipy.spatial.cKDTree` gained an ability to perform weighted pair counting via the new keywords ``weights`` and ``cumulative``. See `gh-5647 `_ for details. `scipy.spatial.distance.pdist` and `scipy.spatial.distance.cdist` now support non-double custom metrics. `scipy.ndimage` improvements - ---------------------------- The callback function C API supports PyCapsules in Python 2.7 Multidimensional filters now allow having different extrapolation modes for different axes. `scipy.optimize` improvements - ----------------------------- The `scipy.optimize.basinhopping` global minimizer obtained a new keyword, `seed`, which can be used to seed the random number generator and obtain repeatable minimizations. The keyword `sigma` in `scipy.optimize.curve_fit` was overloaded to also accept the covariance matrix of errors in the data. `scipy.signal` improvements - --------------------------- The function `scipy.signal.correlate` and `scipy.signal.convolve` have a new optional parameter `method`. The default value of `auto` estimates the fastest of two computation methods, the direct approach and the Fourier transform approach. A new function has been added to choose the convolution/correlation method, `scipy.signal.choose_conv_method` which may be appropriate if convolutions or correlations are performed on many arrays of the same size. New functions have been added to calculate complex short time fourier transforms of an input signal, and to invert the transform to recover the original signal: `scipy.signal.stft` and `scipy.signal.istft`. This implementation also fixes the previously incorrect ouput of `scipy.signal.spectrogram` when complex output data were requested. The function `scipy.signal.sosfreqz` was added to compute the frequency response from second-order sections. The function `scipy.signal.unit_impulse` was added to conveniently generate an impulse function. The function `scipy.signal.iirnotch` was added to design second-order IIR notch filters that can be used to remove a frequency component from a signal. The dual function `scipy.signal.iirpeak` was added to compute the coefficients of a second-order IIR peak (resonant) filter. The function `scipy.signal.minimum_phase` was added to convert linear-phase FIR filters to minimum phase. The functions `scipy.signal.upfirdn` and `scipy.signal.resample_poly` are now substantially faster when operating on some n-dimensional arrays when n > 1. The largest reduction in computation time is realized in cases where the size of the array is small (<1k samples or so) along the axis to be filtered. `scipy.fftpack` improvements - ---------------------------- Fast Fourier transform routines now accept `np.float16` inputs and upcast them to `np.float32`. Previously, they would raise an error. `scipy.cluster` improvements - ---------------------------- Methods ``"centroid"`` and ``"median"`` of `scipy.cluster.hierarchy.linkage` have been significantly sped up. Long-standing issues with using ``linkage`` on large input data (over 16 GB) have been resolved. `scipy.sparse` improvements - --------------------------- The functions `scipy.sparse.save_npz` and `scipy.sparse.load_npz` were added, providing simple serialization for some sparse formats. The `prune` method of classes `bsr_matrix`, `csc_matrix`, and `csr_matrix` was updated to reallocate backing arrays under certain conditions, reducing memory usage. The methods `argmin` and `argmax` were added to classes `coo_matrix`, `csc_matrix`, `csr_matrix`, and `bsr_matrix`. New function `scipy.sparse.csgraph.structural_rank` computes the structural rank of a graph with a given sparsity pattern. New function `scipy.sparse.linalg.spsolve_triangular` solves a sparse linear system with a triangular left hand side matrix. `scipy.special` improvements - ---------------------------- Scalar, typed versions of universal functions from `scipy.special` are available in the Cython space via ``cimport`` from the new module `scipy.special.cython_special`. These scalar functions can be expected to be significantly faster then the universal functions for scalar arguments. See the `scipy.special` tutorial for details. Better control over special-function errors is offered by the functions `scipy.special.geterr` and `scipy.special.seterr` and the context manager `scipy.special.errstate`. The names of orthogonal polynomial root functions have been changed to be consistent with other functions relating to orthogonal polynomials. For example, `scipy.special.j_roots` has been renamed `scipy.special.roots_jacobi` for consistency with the related functions `scipy.special.jacobi` and `scipy.special.eval_jacobi`. To preserve back-compatibility the old names have been left as aliases. Wright Omega function is implemented as `scipy.special.wrightomega`. `scipy.stats` improvements - -------------------------- The function `scipy.stats.weightedtau` was added. It provides a weighted version of Kendall's tau. New class `scipy.stats.multinomial` implements the multinomial distribution. New class `scipy.stats.rv_histogram` constructs a continuous univariate distribution with a piecewise linear CDF from a binned data sample. New class `scipy.stats.argus` implements the Argus distribution. `scipy.interpolate` improvements - -------------------------------- New class `scipy.interpolate.BSpline` represents splines. ``BSpline`` objects contain knots and coefficients and can evaluate the spline. The format is consistent with FITPACK, so that one can do, for example:: >>> t, c, k = splrep(x, y, s=0) >>> spl = BSpline(t, c, k) >>> np.allclose(spl(x), y) ``spl*`` functions, `scipy.interpolate.splev`, `scipy.interpolate.splint`, `scipy.interpolate.splder` and `scipy.interpolate.splantider`, accept both ``BSpline`` objects and ``(t, c, k)`` tuples for backwards compatibility. For multidimensional splines, ``c.ndim > 1``, ``BSpline`` objects are consistent with piecewise polynomials, `scipy.interpolate.PPoly`. This means that ``BSpline`` objects are not immediately consistent with `scipy.interpolate.splprep`, and one *cannot* do ``>>> BSpline(*splprep([x, y])[0])``. Consult the `scipy.interpolate` test suite for examples of the precise equivalence. In new code, prefer using ``scipy.interpolate.BSpline`` objects instead of manipulating ``(t, c, k)`` tuples directly. New function `scipy.interpolate.make_interp_spline` constructs an interpolating spline given data points and boundary conditions. New function `scipy.interpolate.make_lsq_spline` constructs a least-squares spline approximation given data points. `scipy.integrate` improvements - ------------------------------ Now `scipy.integrate.fixed_quad` supports vector-valued functions. Deprecated features =================== `scipy.interpolate.splmake`, `scipy.interpolate.spleval` and `scipy.interpolate.spline` are deprecated. The format used by `splmake/spleval` was inconsistent with `splrep/splev` which was confusing to users. `scipy.special.errprint` is deprecated. Improved functionality is available in `scipy.special.seterr`. calling `scipy.spatial.distance.pdist` or `scipy.spatial.distance.cdist` with arguments not needed by the chosen metric is deprecated. Also, metrics `"old_cosine"` and `"old_cos"` are deprecated. Backwards incompatible changes ============================== The deprecated ``scipy.weave`` submodule was removed. `scipy.spatial.distance.squareform` now returns arrays of the same dtype as the input, instead of always float64. `scipy.special.errprint` now returns a boolean. The function `scipy.signal.find_peaks_cwt` now returns an array instead of a list. `scipy.stats.kendalltau` now computes the correct p-value in case the input contains ties. The p-value is also identical to that computed by `scipy.stats.mstats.kendalltau` and by R. If the input does not contain ties there is no change w.r.t. the previous implementation. The function `scipy.linalg.block_diag` will not ignore zero-sized matrices anymore. Instead it will insert rows or columns of zeros of the appropriate size. See gh-4908 for more details. Other changes ============= SciPy wheels will now report their dependency on ``numpy`` on all platforms. This change was made because Numpy wheels are available, and because the pip upgrade behavior is finally changing for the better (use ``--upgrade-strategy=only-if-needed`` for ``pip >= 8.2``; that behavior will become the default in the next major version of ``pip``). Numerical values returned by `scipy.interpolate.interp1d` with ``kind="cubic"`` and ``"quadratic"`` may change relative to previous scipy versions. If your code depended on specific numeric values (i.e., on implementation details of the interpolators), you may want to double-check your results. Authors ======= * @endolith * Max Argus + * Herv? Audren * Alessandro Pietro Bardelli + * Michael Benfield + * Felix Berkenkamp * Matthew Brett * Per Brodtkorb * Evgeni Burovski * Pierre de Buyl * CJ Carey * Brandon Carter + * Tim Cera * Klesk Chonkin * Christian H?ggstr?m + * Luca Citi * Peadar Coyle + * Daniel da Silva + * Greg Dooper + * John Draper + * drlvk + * David Ellis + * Yu Feng * Baptiste Fontaine + * Jed Frey + * Siddhartha Gandhi + * Wim Glenn + * Akash Goel + * Christoph Gohlke * Ralf Gommers * Alexander Goncearenco + * Richard Gowers + * Alex Griffing * Radoslaw Guzinski + * Charles Harris * Callum Jacob Hays + * Ian Henriksen * Randy Heydon + * Lindsey Hiltner + * Gerrit Holl + * Hiroki IKEDA + * jfinkels + * Mher Kazandjian + * Thomas Keck + * keuj6 + * Kornel Kielczewski + * Sergey B Kirpichev + * Vasily Kokorev + * Eric Larson * Denis Laxalde * Gregory R. Lee * Josh Lefler + * Julien Lhermitte + * Evan Limanto + * Jin-Guo Liu + * Nikolay Mayorov * Geordie McBain + * Josue Melka + * Matthieu Melot * michaelvmartin15 + * Surhud More + * Brett M. Morris + * Chris Mutel + * Paul Nation * Andrew Nelson * David Nicholson + * Aaron Nielsen + * Joel Nothman * nrnrk + * Juan Nunez-Iglesias * Mikhail Pak + * Gavin Parnaby + * Thomas Pingel + * Ilhan Polat + * Aman Pratik + * Sebastian Pucilowski * Ted Pudlik * puenka + * Eric Quintero * Tyler Reddy * Joscha Reimer * Antonio Horta Ribeiro + * Edward Richards + * Roman Ring + * Rafael Rossi + * Colm Ryan + * Sami Salonen + * Alvaro Sanchez-Gonzalez + * Johannes Schmitz * Kari Schoonbee * Yurii Shevchuk + * Jonathan Siebert + * Jonathan Tammo Siebert + * Scott Sievert + * Sourav Singh * Byron Smith + * Srikiran + * Samuel St-Jean + * Yoni Teitelbaum + * Bhavika Tekwani * Martin Thoma * timbalam + * Svend Vanderveken + * Sebastiano Vigna + * Aditya Vijaykumar + * Santi Villalba + * Ze Vinicius * Pauli Virtanen * Matteo Visconti * Yusuke Watanabe + * Warren Weckesser * Phillip Weinberg + * Nils Werner * Jakub Wilk * Josh Wilson * wirew0rm + * David Wolever + * Nathan Woods * ybeltukov + * G Young * Evgeny Zhurko + A total of 121 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 0.19.0 - ------------------------ - - `#1767 `__: Function definitions in __fitpack.h should be moved. (Trac #1240) - - `#1774 `__: _kmeans chokes on large thresholds (Trac #1247) - - `#2089 `__: Integer overflows cause segfault in linkage function with large... - - `#2190 `__: Are odd-length window functions supposed to be always symmetrical?... - - `#2251 `__: solve_discrete_are in scipy.linalg does (sometimes) not solve... - - `#2580 `__: scipy.interpolate.UnivariateSpline (or a new superclass of it)... - - `#2592 `__: scipy.stats.anderson assumes gumbel_l - - `#3054 `__: scipy.linalg.eig does not handle infinite eigenvalues - - `#3160 `__: multinomial pmf / logpmf - - `#3904 `__: scipy.special.ellipj dn wrong values at quarter period - - `#4044 `__: Inconsistent code book initialization in kmeans - - `#4234 `__: scipy.signal.flattop documentation doesn't list a source for... - - `#4831 `__: Bugs in C code in __quadpack.h - - `#4908 `__: bug: unnessesary validity check for block dimension in scipy.sparse.block_diag - - `#4917 `__: BUG: indexing error for sparse matrix with ix_ - - `#4938 `__: Docs on extending ndimage need to be updated. - - `#5056 `__: sparse matrix element-wise multiplying dense matrix returns dense... - - `#5337 `__: Formula in documentation for correlate is wrong - - `#5537 `__: use OrderedDict in io.netcdf - - `#5750 `__: [doc] missing data index value in KDTree, cKDTree - - `#5755 `__: p-value computation in scipy.stats.kendalltau() in broken in... - - `#5757 `__: BUG: Incorrect complex output of signal.spectrogram - - `#5964 `__: ENH: expose scalar versions of scipy.special functions to cython - - `#6107 `__: scipy.cluster.hierarchy.single segmentation fault with 2**16... - - `#6278 `__: optimize.basinhopping should take a RandomState object - - `#6296 `__: InterpolatedUnivariateSpline: check_finite fails when w is unspecified - - `#6306 `__: Anderson-Darling bad results - - `#6314 `__: scipy.stats.kendaltau() p value not in agreement with R, SPSS... - - `#6340 `__: Curve_fit bounds and maxfev - - `#6377 `__: expm_multiply, complex matrices not working using start,stop,ect... - - `#6382 `__: optimize.differential_evolution stopping criterion has unintuitive... - - `#6391 `__: Global Benchmarking times out at 600s. - - `#6397 `__: mmwrite errors with large (but still 64-bit) integers - - `#6413 `__: scipy.stats.dirichlet computes multivariate gaussian differential... - - `#6428 `__: scipy.stats.mstats.mode modifies input - - `#6440 `__: Figure out ABI break policy for scipy.special Cython API - - `#6441 `__: Using Qhull for halfspace intersection : segfault - - `#6442 `__: scipy.spatial : In incremental mode volume is not recomputed - - `#6451 `__: Documentation for scipy.cluster.hierarchy.to_tree is confusing... - - `#6490 `__: interp1d (kind=zero) returns wrong value for rightmost interpolation... - - `#6521 `__: scipy.stats.entropy does *not* calculate the KL divergence - - `#6530 `__: scipy.stats.spearmanr unexpected NaN handling - - `#6541 `__: Test runner does not run scipy._lib/tests? - - `#6552 `__: BUG: misc.bytescale returns unexpected results when using cmin/cmax... - - `#6556 `__: RectSphereBivariateSpline(u, v, r) fails if min(v) >= pi - - `#6559 `__: Differential_evolution maxiter causing memory overflow - - `#6565 `__: Coverage of spectral functions could be improved - - `#6628 `__: Incorrect parameter name in binomial documentation - - `#6634 `__: Expose LAPACK's xGESVX family for linalg.solve ill-conditioned... - - `#6657 `__: Confusing documentation for `scipy.special.sph_harm` - - `#6676 `__: optimize: Incorrect size of Jacobian returned by `minimize(...,... - - `#6681 `__: add a new context manager to wrap `scipy.special.seterr` - - `#6700 `__: BUG: scipy.io.wavfile.read stays in infinite loop, warns on wav... - - `#6721 `__: scipy.special.chebyt(N) throw a 'TypeError' when N > 64 - - `#6727 `__: Documentation for scipy.stats.norm.fit is incorrect - - `#6764 `__: Documentation for scipy.spatial.Delaunay is partially incorrect - - `#6811 `__: scipy.spatial.SphericalVoronoi fails for large number of points - - `#6841 `__: spearmanr fails when nan_policy='omit' is set - - `#6869 `__: Currently in gaussian_kde, the logpdf function is calculated... - - `#6875 `__: SLSQP inconsistent handling of invalid bounds - - `#6876 `__: Python stopped working (Segfault?) with minimum/maximum filter... - - `#6889 `__: dblquad gives different results under scipy 0.17.1 and 0.18.1 - - `#6898 `__: BUG: dblquad ignores error tolerances - - `#6901 `__: Solving sparse linear systems in CSR format with complex values - - `#6903 `__: issue in spatial.distance.pdist docstring - - `#6917 `__: Problem in passing drop_rule to scipy.sparse.linalg.spilu - - `#6926 `__: signature mismatches for LowLevelCallable - - `#6961 `__: Scipy contains shebang pointing to /usr/bin/python and /bin/bash... - - `#6972 `__: BUG: special: `generate_ufuncs.py` is broken - - `#6984 `__: Assert raises test failure for test_ill_condition_warning - - `#6990 `__: BUG: sparse: Bad documentation of the `k` argument in `sparse.linalg.eigs` - - `#6991 `__: Division by zero in linregress() - - `#7011 `__: possible speed improvment in rv_continuous.fit() - - `#7015 `__: Test failure with Python 3.5 and numpy master - - `#7055 `__: SciPy 0.19.0rc1 test errors and failures on Windows - - `#7096 `__: macOS test failues for test_solve_continuous_are - - `#7100 `__: test_distance.test_Xdist_deprecated_args test error in 0.19.0rc2 Pull requests for 0.19.0 - ------------------------ - - `#2908 `__: Scipy 1.0 Roadmap - - `#3174 `__: add b-splines - - `#4606 `__: ENH: Add a unit impulse waveform function - - `#5608 `__: Adds keyword argument to choose faster convolution method - - `#5647 `__: ENH: Faster count_neighour in cKDTree / + weighted input data - - `#6021 `__: Netcdf append - - `#6058 `__: ENH: scipy.signal - Add stft and istft - - `#6059 `__: ENH: More accurate signal.freqresp for zpk systems - - `#6195 `__: ENH: Cython interface for special - - `#6234 `__: DOC: Fixed a typo in ward() help - - `#6261 `__: ENH: add docstring and clean up code for signal.normalize - - `#6270 `__: MAINT: special: add tests for cdflib - - `#6271 `__: Fix for scipy.cluster.hierarchy.is_isomorphic - - `#6273 `__: optimize: rewrite while loops as for loops - - `#6279 `__: MAINT: Bessel tweaks - - `#6291 `__: Fixes gh-6219: remove runtime warning from genextreme distribution - - `#6294 `__: STY: Some PEP8 and cleaning up imports in stats/_continuous_distns.py - - `#6297 `__: Clarify docs in misc/__init__.py - - `#6300 `__: ENH: sparse: Loosen input validation for `diags` with empty inputs - - `#6301 `__: BUG: standardizes check_finite behavior re optional weights,... - - `#6303 `__: Fixing example in _lazyselect docstring. - - `#6307 `__: MAINT: more improvements to gammainc/gammaincc - - `#6308 `__: Clarified documentation of hypergeometric distribution. - - `#6309 `__: BUG: stats: Improve calculation of the Anderson-Darling statistic. - - `#6315 `__: ENH: Descending order of x in PPoly - - `#6317 `__: ENH: stats: Add support for nan_policy to stats.median_test - - `#6321 `__: TST: fix a typo in test name - - `#6328 `__: ENH: sosfreqz - - `#6335 `__: Define LinregressResult outside of linregress - - `#6337 `__: In anderson test, added support for right skewed gumbel distribution. - - `#6341 `__: Accept several spellings for the curve_fit max number of function... - - `#6342 `__: DOC: cluster: clarify hierarchy.linkage usage - - `#6352 `__: DOC: removed brentq from its own 'see also' - - `#6362 `__: ENH: stats: Use explicit formulas for sf, logsf, etc in weibull... - - `#6369 `__: MAINT: special: add a comment to hyp0f1_complex - - `#6375 `__: Added the multinomial distribution. - - `#6387 `__: MAINT: special: improve accuracy of ellipj's `dn` at quarter... - - `#6388 `__: BenchmarkGlobal - getting it to work in Python3 - - `#6394 `__: ENH: scipy.sparse: add save and load functions for sparse matrices - - `#6400 `__: MAINT: moves global benchmark run from setup_cache to track_all - - `#6403 `__: ENH: seed kwd for basinhopping. Closes #6278 - - `#6404 `__: ENH: signal: added irrnotch and iirpeak functions. - - `#6406 `__: ENH: special: extend `sici`/`shichi` to complex arguments - - `#6407 `__: ENH: Window functions should not accept non-integer or negative... - - `#6408 `__: MAINT: _differentialevolution now uses _lib._util.check_random_state - - `#6427 `__: MAINT: Fix gmpy build & test that mpmath uses gmpy - - `#6439 `__: MAINT: ndimage: update callback function c api - - `#6443 `__: BUG: Fix volume computation in incremental mode - - `#6447 `__: Fixes issue #6413 - Minor documentation fix in the entropy function... - - `#6448 `__: ENH: Add halfspace mode to Qhull - - `#6449 `__: ENH: rtol and atol for differential_evolution termination fixes... - - `#6453 `__: DOC: Add some See Also links between similar functions - - `#6454 `__: DOC: linalg: clarify callable signature in `ordqz` - - `#6457 `__: ENH: spatial: enable non-double dtypes in squareform - - `#6459 `__: BUG: Complex matrices not handled correctly by expm_multiply... - - `#6465 `__: TST DOC Window docs, tests, etc. - - `#6469 `__: ENH: linalg: better handling of infinite eigenvalues in `eig`/`eigvals` - - `#6475 `__: DOC: calling interp1d/interp2d with NaNs is undefined - - `#6477 `__: Document magic numbers in optimize.py - - `#6481 `__: TST: Supress some warnings from test_windows - - `#6485 `__: DOC: spatial: correct typo in procrustes - - `#6487 `__: Fix Bray-Curtis formula in pdist docstring - - `#6493 `__: ENH: Add covariance functionality to scipy.optimize.curve_fit - - `#6494 `__: ENH: stats: Use log1p() to improve some calculations. - - `#6495 `__: BUG: Use MST algorithm instead of SLINK for single linkage clustering - - `#6497 `__: MRG: Add minimum_phase filter function - - `#6505 `__: reset scipy.signal.resample window shape to 1-D - - `#6507 `__: BUG: linkage: Raise exception if y contains non-finite elements - - `#6509 `__: ENH: _lib: add common machinery for low-level callback functions - - `#6520 `__: scipy.sparse.base.__mul__ non-numpy/scipy objects with 'shape'... - - `#6522 `__: Replace kl_div by rel_entr in entropy - - `#6524 `__: DOC: add next_fast_len to list of functions - - `#6527 `__: DOC: Release notes to reflect the new covariance feature in optimize.curve_fit - - `#6532 `__: ENH: Simplify _cos_win, document it, add symmetric/periodic arg - - `#6535 `__: MAINT: sparse.csgraph: updating old cython loops - - `#6540 `__: DOC: add to documentation of orthogonal polynomials - - `#6544 `__: TST: Ensure tests for scipy._lib are run by scipy.test() - - `#6546 `__: updated docstring of stats.linregress - - `#6553 `__: commited changes that I originally submitted for scipy.signal.cspline? - - `#6561 `__: BUG: modify signal.find_peaks_cwt() to return array and accept... - - `#6562 `__: DOC: Negative binomial distribution clarification - - `#6563 `__: MAINT: be more liberal in requiring numpy - - `#6567 `__: MAINT: use xrange for iteration in differential_evolution fixes... - - `#6572 `__: BUG: "sp.linalg.solve_discrete_are" fails for random data - - `#6578 `__: BUG: misc: allow both cmin/cmax and low/high params in bytescale - - `#6581 `__: Fix some unfortunate typos - - `#6582 `__: MAINT: linalg: make handling of infinite eigenvalues in `ordqz`... - - `#6585 `__: DOC: interpolate: correct seealso links to ndimage - - `#6588 `__: Update docstring of scipy.spatial.distance_matrix - - `#6592 `__: DOC: Replace 'first' by 'smallest' in mode - - `#6593 `__: MAINT: remove scipy.weave submodule - - `#6594 `__: DOC: distance.squareform: fix html docs, add note about dtype... - - `#6598 `__: [DOC] Fix incorrect error message in medfilt2d - - `#6599 `__: MAINT: linalg: turn a `solve_discrete_are` test back on - - `#6600 `__: DOC: Add SOS goals to roadmap - - `#6601 `__: DEP: Raise minimum numpy version to 1.8.2 - - `#6605 `__: MAINT: 'new' module is deprecated, don't use it - - `#6607 `__: DOC: add note on change in wheel dependency on numpy and pip... - - `#6609 `__: Fixes #6602 - Typo in docs - - `#6616 `__: ENH: generalization of continuous and discrete Riccati solvers... - - `#6621 `__: DOC: improve cluster.hierarchy docstrings. - - `#6623 `__: CS matrix prune method should copy data from large unpruned arrays - - `#6625 `__: DOC: special: complete documentation of `eval_*` functions - - `#6626 `__: TST: special: silence some deprecation warnings - - `#6631 `__: fix parameter name doc for discrete distributions - - `#6632 `__: MAINT: stats: change some instances of `special` to `sc` - - `#6633 `__: MAINT: refguide: py2k long integers are equal to py3k integers - - `#6638 `__: MAINT: change type declaration in cluster.linkage, prevent overflow - - `#6640 `__: BUG: fix issue with duplicate values used in cluster.vq.kmeans - - `#6641 `__: BUG: fix corner case in cluster.vq.kmeans for large thresholds - - `#6643 `__: MAINT: clean up truncation modes of dendrogram - - `#6645 `__: MAINT: special: rename `*_roots` functions - - `#6646 `__: MAINT: clean up mpmath imports - - `#6647 `__: DOC: add sqrt to Mahalanobis description for pdist - - `#6648 `__: DOC: special: add a section on `cython_special` to the tutorial - - `#6649 `__: ENH: Added scipy.spatial.distance.directed_hausdorff - - `#6650 `__: DOC: add Sphinx roles for DOI and arXiv links - - `#6651 `__: BUG: mstats: make sure mode(..., None) does not modify its input - - `#6652 `__: DOC: special: add section to tutorial on functions not in special - - `#6653 `__: ENH: special: add the Wright Omega function - - `#6656 `__: ENH: don't coerce input to double with custom metric in cdist... - - `#6658 `__: Faster/shorter code for computation of discordances - - `#6659 `__: DOC: special: make __init__ summaries and html summaries match - - `#6661 `__: general.rst: Fix a typo - - `#6664 `__: TST: Spectral functions' window correction factor - - `#6665 `__: [DOC] Conditions on v in RectSphereBivariateSpline - - `#6668 `__: DOC: Mention negative masses for center of mass - - `#6675 `__: MAINT: special: remove outdated README - - `#6677 `__: BUG: Fixes computation of p-values. - - `#6679 `__: BUG: optimize: return correct Jacobian for method 'SLSQP' in... - - `#6680 `__: ENH: Add structural rank to sparse.csgraph - - `#6686 `__: TST: Added Airspeed Velocity benchmarks for SphericalVoronoi - - `#6687 `__: DOC: add section "deciding on new features" to developer guide. - - `#6691 `__: ENH: Clearer error when fmin_slsqp obj doesn't return scalar - - `#6702 `__: TST: Added airspeed velocity benchmarks for scipy.spatial.distance.cdist - - `#6707 `__: TST: interpolate: test fitpack wrappers, not _impl - - `#6709 `__: TST: fix a number of test failures on 32-bit systems - - `#6711 `__: MAINT: move function definitions from __fitpack.h to _fitpackmodule.c - - `#6712 `__: MAINT: clean up wishlist in stats.morestats, and copyright statement. - - `#6715 `__: DOC: update the release notes with BSpline et al. - - `#6716 `__: MAINT: scipy.io.wavfile: No infinite loop when trying to read... - - `#6717 `__: some style cleanup - - `#6723 `__: BUG: special: cast to float before in-place multiplication in... - - `#6726 `__: address performance regressions in interp1d - - `#6728 `__: DOC: made code examples in `integrate` tutorial copy-pasteable - - `#6731 `__: DOC: scipy.optimize: Added an example for wrapping complex-valued... - - `#6732 `__: MAINT: cython_special: remove `errprint` - - `#6733 `__: MAINT: special: fix some pyflakes warnings - - `#6734 `__: DOC: sparse.linalg: fixed matrix description in `bicgstab` doc - - `#6737 `__: BLD: update `cythonize.py` to detect changes in pxi files - - `#6740 `__: DOC: special: some small fixes to docstrings - - `#6741 `__: MAINT: remove dead code in interpolate.py - - `#6742 `__: BUG: fix ``linalg.block_diag`` to support zero-sized matrices. - - `#6744 `__: ENH: interpolate: make PPoly.from_spline accept BSpline objects - - `#6746 `__: DOC: special: clarify use of Condon-Shortley phase in `sph_harm`/`lpmv` - - `#6750 `__: ENH: sparse: avoid densification on broadcasted elem-wise mult - - `#6751 `__: sinm doc explained cosm - - `#6753 `__: ENH: special: allow for more fine-tuned error handling - - `#6759 `__: Move logsumexp and pade from scipy.misc to scipy.special and... - - `#6761 `__: ENH: argmax and argmin methods for sparse matrices - - `#6762 `__: DOC: Improve docstrings of sparse matrices - - `#6763 `__: ENH: Weighted tau - - `#6768 `__: ENH: cythonized spherical Voronoi region polygon vertex sorting - - `#6770 `__: Correction of Delaunay class' documentation - - `#6775 `__: ENH: Integrating LAPACK "expert" routines with conditioning warnings... - - `#6776 `__: MAINT: Removing the trivial f2py warnings - - `#6777 `__: DOC: Update rv_continuous.fit doc. - - `#6778 `__: MAINT: cluster.hierarchy: Improved wording of error msgs - - `#6786 `__: BLD: increase minimum Cython version to 0.23.4 - - `#6787 `__: DOC: expand on ``linalg.block_diag`` changes in 0.19.0 release... - - `#6789 `__: ENH: Add further documentation for norm.fit - - `#6790 `__: MAINT: Fix a potential problem in nn_chain linkage algorithm - - `#6791 `__: DOC: Add examples to scipy.ndimage.fourier - - `#6792 `__: DOC: fix some numpydoc / Sphinx issues. - - `#6793 `__: MAINT: fix circular import after moving functions out of misc - - `#6796 `__: TST: test importing each submodule. Regression test for gh-6793. - - `#6799 `__: ENH: stats: Argus distribution - - `#6801 `__: ENH: stats: Histogram distribution - - `#6803 `__: TST: make sure tests for ``_build_utils`` are run. - - `#6804 `__: MAINT: more fixes in `loggamma` - - `#6806 `__: ENH: Faster linkage for 'centroid' and 'median' methods - - `#6810 `__: ENH: speed up upfirdn and resample_poly for n-dimensional arrays - - `#6812 `__: TST: Added ConvexHull asv benchmark code - - `#6814 `__: ENH: Different extrapolation modes for different dimensions in... - - `#6826 `__: Signal spectral window default fix - - `#6828 `__: BUG: SphericalVoronoi Space Complexity (Fixes #6811) - - `#6830 `__: RealData docstring correction - - `#6834 `__: DOC: Added reference for skewtest function. See #6829 - - `#6836 `__: DOC: Added mode='mirror' in the docstring for the functions accepting... - - `#6838 `__: MAINT: sparse: start removing old BSR methods - - `#6844 `__: handle incompatible dimensions when input is not an ndarray in... - - `#6847 `__: Added maxiter to golden search. - - `#6850 `__: BUG: added check for optional param scipy.stats.spearmanr - - `#6858 `__: MAINT: Removing redundant tests - - `#6861 `__: DEP: Fix escape sequences deprecated in Python 3.6. - - `#6862 `__: DOC: dx should be float, not int - - `#6863 `__: updated documentation curve_fit - - `#6866 `__: DOC : added some documentation to j1 referring to spherical_jn - - `#6867 `__: DOC: cdist move long examples list into Notes section - - `#6868 `__: BUG: Make stats.mode return a ModeResult namedtuple on empty... - - `#6871 `__: Corrected documentation. - - `#6874 `__: ENH: gaussian_kde.logpdf based on logsumexp - - `#6877 `__: BUG: ndimage: guard against footprints of all zeros - - `#6881 `__: python 3.6 - - `#6885 `__: Vectorized integrate.fixed_quad - - `#6886 `__: fixed typo - - `#6891 `__: TST: fix failures for linalg.dare/care due to tightened test... - - `#6892