From cimrman3 at ntc.zcu.cz Tue Jul 2 13:00:33 2019 From: cimrman3 at ntc.zcu.cz (Robert Cimrman) Date: Tue, 2 Jul 2019 19:00:33 +0200 Subject: [SciPy-Dev] ANN: SfePy 2019.2 Message-ID: I am pleased to announce release 2019.2 of SfePy. Description ----------- SfePy (simple finite elements in Python) is a software for solving systems of coupled partial differential equations by the finite element method or by the isogeometric analysis (limited support). It is distributed under the new BSD license. Home page: http://sfepy.org Mailing list: https://mail.python.org/mm3/mailman3/lists/sfepy.python.org/ Git (source) repository, issue tracker: https://github.com/sfepy/sfepy Highlights of this release -------------------------- - improved support for time-dependent homogenization problems, - Python 3.7 compatibility For full release notes see [1]. Cheers, Robert Cimrman [1] http://docs.sfepy.org/doc/release_notes.html#id1 --- Contributors to this release in alphabetical order: Robert Cimrman Jan Heczko Lubos Kejzlar Vladimir Lukes From dashohoxha at gmail.com Wed Jul 3 13:41:35 2019 From: dashohoxha at gmail.com (Dashamir Hoxha) Date: Wed, 3 Jul 2019 19:41:35 +0200 Subject: [SciPy-Dev] Sprint at SciPy Conference? In-Reply-To: References:

Message-ID: On Sun, Jun 30, 2019 at 8:11 PM Ralf Gommers wrote: > > > On Sat, Jun 29, 2019 at 8:19 PM Dashamir Hoxha > wrote: > >> On Sun, Jun 23, 2019 at 7:42 AM Matt Haberland >> wrote: >> >>> The SciPy Conference approaches! Who >>> would be interested in a sprint >>> ? >>> Can you participate in-person or virtually? >>> >> >> I would be interested to participate virtually, at least on the tutorial. >> > > There's no tutorial in the sprints normally. The "how to contribute" > tutorial (walk through a first pull request) is centrally done by the > conference organizers, and people at the SciPy sprint typically dive > straight in after some informal discussion with one of the core developers. > > >> What do you usually do for virtual participation? >> > > Usually only via GitHub, and perhaps IRC/Gitter. > > >> Recently I have used successfully Guacamole for collaborating with some >> online students: >> >> https://www.researchgate.net/publication/332469806_Linux_Desktop_In_a_Container >> >> I can also offer my infrastructure for this, if needed: >> https://mint.fs.al:333/guac/ >> It works well, combined with some videoconferencing application, for >> example: https://meet.jit.si/ >> > > I have to admit I've never tried any kind of videoconferencing during a > sprint other than short video calls planned beforehand. I'm not sure it > would work well to be honest. Partcipating via our regular channels would > be better probably. > Having no experience with NumPy/SciPy, I am not sure whether I can be useful somehow on this sprint. But I would like to participate for a short time anyway, just to see what's going on, if nothing else. I hope the details will be announced in time. For example the schedule, the IRC channel, etc. (are we going to use #scipy on freenode?) I don't need to register somewhere, do I? Thanks, Dashamir -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.gommers at gmail.com Wed Jul 3 15:04:38 2019 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Wed, 3 Jul 2019 12:04:38 -0700 Subject: [SciPy-Dev] Combinatorial optimization in scipy.optimize In-Reply-To: <20190627110751.zpcin5yzpsjfwbr4@hackenturet.dk> References: <20190627075201.hna2k5hb6svrzzuj@hackenturet.dk> <20190627080623.6m6pvbnwlvretphx@hackenturet.dk> <20190627110751.zpcin5yzpsjfwbr4@hackenturet.dk> Message-ID: On Thu, Jun 27, 2019 at 4:08 AM S?ren Fuglede J?rgensen < scipy-dev at fuglede.dk> wrote: > Hi SciPy-Dev > > This question is motivated by the recent improvements to > scipy.optimize.linear_sum_assignment. [0] Here, we get a much improved > algorithm for solving minimum weight perfect matching in bipartite graphs > (which is excellent). > > Now, this problem is one in a large family of combinatorial optimization > problems on packing and covering, and what I'm wondering is if SciPy should > be the home for a general class of efficient algorithms for solving those? > > Most of these can be phrased in terms of graph theory, and indeed networkx > already contains implementations of many classical algorithms (and I was > surprised to find that it didn't have anything matching > linear_sum_assignment directly; it does have an implementation of the > Blossom algorithm). So there's some overlap of scope here, but I guess > that's not a problem in and by itself, but it had me wondering where the > split should be? > > Just to phrase this in terms of (a very incomplete list of) examples (some > of which have polynomial solutions, some of which don't), would there be > appetite for including into scipy.optimize algorithms for solving e.g. > > 1. other covering/packing problems (e.g. min set/vertex/edge cover, > maximum matching, ...), > 2. maximum flow, > 3. shortest path, > 4. travelling salesman, > 5. circuit minimization? > Some of these are in scipy.sparse.csgraph already. We indeed don't want to do everything that NetworkX already does, however if it's a well-known algorithm that would fit in with what we already have and focus on performance (which NetworkX does not do) then I think there's scope for more. For sparse.csgraph I think Jake implemented a set of standard algorithms that can be found in a graph algorithms introductory handbook. It also depends to some extent on who writes the code - technical code like that is often not the easiest to maintain, so it would make the conversation and review process a lot easier of there is a person (or two people) with a commitment to maintain the code going forward. Cheers, Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From Dieter at Werthmuller.org Wed Jul 3 16:19:28 2019 From: Dieter at Werthmuller.org (=?UTF-8?Q?Dieter_Werthm=c3=bcller?=) Date: Wed, 3 Jul 2019 22:19:28 +0200 Subject: [SciPy-Dev] numba simple example In-Reply-To: References: <20190627075201.hna2k5hb6svrzzuj@hackenturet.dk> <20190627080623.6m6pvbnwlvretphx@hackenturet.dk> <20190627110751.zpcin5yzpsjfwbr4@hackenturet.dk> Message-ID: <94ed8ea9-dd36-7930-393f-7083be0657ca@Werthmuller.org> Just as information, might be useful. I remember that it was discussed something over a year ago whether or not having numba as a dependency. I think it was Ralf who said that it would be nice if one could achieve with a simple decorator a speed-up with numba - if it is installed, and otherwise just keep the status quo. The following simple wrap resulted in a speed-up of a factor 2; the speed up was pretty constant (in my short tests) for arrays say from a couple of ten-thousands to 1e9 complex elements; for smaller array the gain was even higher. @nb.njit(nogil=True, fastmath=True, cache=True) def l2norm(x): """Jitted version of np.linalg.norm(x, ord=None).""" return np.linalg.norm(x) Again, just for the record, for future discussions on the topic. From juanlu001 at gmail.com Thu Jul 4 03:07:22 2019 From: juanlu001 at gmail.com (=?UTF-8?Q?Juan_Luis_Cano_Rodr=c3=adguez?=) Date: Thu, 4 Jul 2019 09:07:22 +0200 Subject: [SciPy-Dev] numba simple example In-Reply-To: <94ed8ea9-dd36-7930-393f-7083be0657ca@Werthmuller.org> References: <20190627075201.hna2k5hb6svrzzuj@hackenturet.dk> <20190627080623.6m6pvbnwlvretphx@hackenturet.dk> <20190627110751.zpcin5yzpsjfwbr4@hackenturet.dk> <94ed8ea9-dd36-7930-393f-7083be0657ca@Werthmuller.org> Message-ID: <39a55ddd-4a2c-2c85-67a1-5ee145d03243@gmail.com> On 7/3/19 10:19 PM, Dieter Werthm?ller wrote: > I think it was Ralf who said that it would be nice if one could > achieve with a simple decorator a speed-up with numba - if it is > installed, and otherwise just keep the status quo. This is what we do in poliastro for example: https://github.com/poliastro/poliastro/blob/v0.12.0/src/poliastro/core/_jit.py Also works on PyPy, which in theory should not need numba: install_requires = ??? ... ??? numba>=0.39 ; implementation_name=='cpython' Regards, Juan Luis From josh.craig.wilson at gmail.com Thu Jul 4 03:22:35 2019 From: josh.craig.wilson at gmail.com (Joshua Wilson) Date: Thu, 4 Jul 2019 00:22:35 -0700 Subject: [SciPy-Dev] Enabling use of scipy.special from Numba In-Reply-To: References:

Message-ID: Ok, returning to the special functions in Numba topic: here's a small repo that generates overloads for a few special functions: https://github.com/person142/numba_special/tree/master/numba_special Taking Nathaniel's point that coming up with an ad-hoc metadata format is probably not a good idea, it instead uses a little bit of Cython to pull out the function pointers: https://github.com/person142/numba_special/blob/master/numba_special/function_pointers.pyx and then you grab those on the Numba side to create the overloads: https://github.com/person142/numba_special/blob/master/numba_special/numba_overloads.py You can see that the overloads are working as expected in the tests: https://github.com/person142/numba_special/blob/master/numba_special/tests/test_functions.py (Note that the development version of Numba is required because of this issue: https://github.com/numba/numba/issues/4133) Of course the pointers/overloads that you're creating are highly structured, so you can just generate the necessary glue code: https://github.com/person142/numba_special/blob/master/generate_overloads.py though it only handles simple function signatures right now. All in all I think it works pretty well-you only use 100% officially supported pieces of all the libraries involved. I'll probably work on extending it more in the next couple of days. On Thu, Jun 20, 2019 at 5:31 PM Nathaniel Smith wrote: > > On Thu, Jun 20, 2019 at 1:41 PM Stanley Seibert wrote: > > > > Well, we'd prefer not to have an unnecessary indirection (and the overhead of making a nested call to the scalar inside the length 1 loop) since the user is doing their own iteration in Numba, but if that's the only option, we can certainly work around it. > > Well, it's computers, so there's never just one option :-). But if you > can consume existing ufuncs and get 95% of the performance, then it > might not be worth building custom infrastructure to expose > scipy.special's raw scalar functions + an ad hoc metadata format + ad > hoc tools to consume the metadata. Intuitively it seems like a few > extra integer operations at entry and exit might not be noticeable at > all compared to the cost of computing a bessel function or whatever, > but I haven't checked. > > -n > > -- > Nathaniel J. Smith -- https://vorpus.org > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at python.org > https://mail.python.org/mailman/listinfo/scipy-dev From serge.guelton at telecom-bretagne.eu Thu Jul 4 03:36:53 2019 From: serge.guelton at telecom-bretagne.eu (Serge Guelton) Date: Thu, 4 Jul 2019 09:36:53 +0200 Subject: [SciPy-Dev] numba simple example In-Reply-To: <39a55ddd-4a2c-2c85-67a1-5ee145d03243@gmail.com> References: <20190627075201.hna2k5hb6svrzzuj@hackenturet.dk> <20190627080623.6m6pvbnwlvretphx@hackenturet.dk> <20190627110751.zpcin5yzpsjfwbr4@hackenturet.dk> <94ed8ea9-dd36-7930-393f-7083be0657ca@Werthmuller.org> <39a55ddd-4a2c-2c85-67a1-5ee145d03243@gmail.com> Message-ID: <20190704073653.GA10860@sguelton.remote.csb> On Thu, Jul 04, 2019 at 09:07:22AM +0200, Juan Luis Cano Rodr?guez wrote: > On 7/3/19 10:19 PM, Dieter Werthm?ller wrote: > > I think it was Ralf who said that it would be nice if one could > > achieve with a simple decorator a speed-up with numba - if it is > > installed, and otherwise just keep the status quo. > > This is what we do in poliastro for example: > > https://github.com/poliastro/poliastro/blob/v0.12.0/src/poliastro/core/_jit.py > > Also works on PyPy, which in theory should not need numba: > > install_requires = > ??? ... > ??? numba>=0.39 ; implementation_name=='cpython' (a bit of self-advertisement here) IMHO, this is where Pythran[0] shines: the input code is pure, high-level Python. And unlike numba, there's no need to explicit loop over arrays, numpy operations are supported so the performance loss when falling back to python is acceptable. Just a maintainer opinion though :-) ++ Serge [0] https://github.com/serge-sans-paille/pythran From ralf.gommers at gmail.com Thu Jul 4 14:08:35 2019 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Thu, 4 Jul 2019 11:08:35 -0700 Subject: [SciPy-Dev] pybind11 dependency (was: scipy.fft submodule) In-Reply-To: References: Message-ID: Hi all, Given that a few people were surprised that SciPy master now has a pybind11 dependency and asked if it was discussed on this list (to which I didn't have an immediate answer), replying to this thread with a more explicit subject. On Tue, Jun 11, 2019 at 4:21 AM Ralf Gommers wrote: > > > On Mon, Jun 10, 2019 at 4:22 PM Peter Bell wrote: > >> Following on from some of the discussion surrounding my backend proposal >> and the discussion on gh-10175 >> ; I?ve been working on >> adding a new scipy.fft submodule. This is now working, tested, >> documented and ready for review in gh-10238 >> . >> >> >> >> The new submodule is almost a drop-in replacement for numpy.fft and >> scipy.fftpack, with a few exceptions: >> >> - Does not include NumPy?s Hermitian transforms (hfft, ihfft) (but >> would be simple to add) >> - Uses numpy?s conventions for rfft (complex array) instead of fftpack?s >> (complex values packed into a real array) >> - Convolutions and pseudo-differential operators from fftpack are not >> included >> >> >> >> The new submodule adds pocketfft to implement the normal FFTs (not yet >> DCT and DST) which adds several new features beyond scipy.fftpack: >> >> - long double transforms >> - multi-dimensional real FFTs (rfftn) >> - Orthonormal transforms (norm=?ortho? argument) >> - Bluestein?s algorithm to avoid the worst case O(n^2) complexity of >> FFTPACK >> >> >> >> A few implementation details worth noting: >> >> - Unlike NumPy?s version of pocketfft, this is C++ and uses templates >> to supporting the different floating point types >> - pocketfft also uses pybind11 which both adds a new build-time >> dependency and requires C++11. I believe this is the first use of C++11 in >> SciPy. >> >> I've looked into this a little more. Compiler support for pybind11 is > given in https://github.com/pybind/pybind11#supported-compilers. > > MSVC 2015 Update 3 seems compatible with the lowest version we need as far > as I can tell (Python 3.5/3.6 require MSVC 14.0 == 2015; the "Update 3" > part should be fine). > > GCC 4.8 is already the minimum we need today I believe. > > Minimum Clang versions needed are from 2013, so that's fine too. > > For Intel compilers a version from 2016 is needed. I think we're fine > requiring a more recent version of the Intel compilers. > > For more exotic platforms, recent enough GCC versions will also do the > job. So good to go I think. > So far pybind11 seems to have worked fine, except that it's not yet documented in all our build instructions (there's open PRs for this though, it's just waiting for Matt's larger devdocs overhaul), and that we seem to require a fairly recent version of pybind11. If there's any other missing docs or concerns, please bring them up here. Cheers, Ralf > >> - pocketfft has optional support for multithreading using OpenMP but >> this is currently disabled (and not compiled in at all). >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.gommers at gmail.com Thu Jul 4 18:57:31 2019 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Thu, 4 Jul 2019 15:57:31 -0700 Subject: [SciPy-Dev] numba simple example In-Reply-To: <20190704073653.GA10860@sguelton.remote.csb> References: <20190627075201.hna2k5hb6svrzzuj@hackenturet.dk> <20190627080623.6m6pvbnwlvretphx@hackenturet.dk> <20190627110751.zpcin5yzpsjfwbr4@hackenturet.dk> <94ed8ea9-dd36-7930-393f-7083be0657ca@Werthmuller.org> <39a55ddd-4a2c-2c85-67a1-5ee145d03243@gmail.com> <20190704073653.GA10860@sguelton.remote.csb> Message-ID: On Thu, Jul 4, 2019 at 12:37 AM Serge Guelton < serge.guelton at telecom-bretagne.eu> wrote: > On Thu, Jul 04, 2019 at 09:07:22AM +0200, Juan Luis Cano Rodr?guez wrote: > > On 7/3/19 10:19 PM, Dieter Werthm?ller wrote: > > > I think it was Ralf who said that it would be nice if one could > > > achieve with a simple decorator a speed-up with numba - if it is > > > installed, and otherwise just keep the status quo. > I think there was some pushback on this idea, because it only works for a limited set of functionality. If the speed difference is 100x from some pure-Python for-loop code, the non-numba performance may be unacceptably slow. So it's only helpful for cases like speeding up np.linalg (aside: that particular one we shouldn't use, we have scipy.linalg). I've talked with multiple people about Numba recently, and I think the broad consensus was that while @jit is nice during development, Numba needs better support for ahead-of-time compilation. > > > This is what we do in poliastro for example: > > > > > https://github.com/poliastro/poliastro/blob/v0.12.0/src/poliastro/core/_jit.py > > > > Also works on PyPy, which in theory should not need numba: > > > > install_requires = > > ... > > numba>=0.39 ; implementation_name=='cpython' > > (a bit of self-advertisement here) > Thanks Serge. I appreciate your updates on Pythran. My impression is that Pythran is gaining in popularity, and with it being usable within Cython, adopted by Xtensor, and a new project like Transonic (and maybe more?), the maintenance situation and risk of adopting Pythran seems to be going down. > IMHO, this is where Pythran[0] shines: the input code is pure, high-level > Python. > And unlike numba, there's no need to explicit loop over arrays, Numba understands those too I believe. Anyway, many of the more interesting cases for Cython/Numba/Pythran are when pure numpy isn't an option because the algorithm isn't nicely expressable in vectorized form. Cheers, Ralf numpy operations > are supported so the performance loss when falling back to python is > acceptable. > > Just a maintainer opinion though :-) > > ++ > Serge > > [0] https://github.com/serge-sans-paille/pythran > _______________________________________________ > 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 Jul 4 18:59:25 2019 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Thu, 4 Jul 2019 15:59:25 -0700 Subject: [SciPy-Dev] Enabling use of scipy.special from Numba In-Reply-To: References:

Message-ID: On Thu, Jul 4, 2019 at 12:23 AM Joshua Wilson wrote: > Ok, returning to the special functions in Numba topic: here's a small > repo that generates overloads for a few special functions: > > https://github.com/person142/numba_special/tree/master/numba_special > > Taking Nathaniel's point that coming up with an ad-hoc metadata format > is probably not a good idea, it instead uses a little bit of Cython to > pull out the function pointers: > > > https://github.com/person142/numba_special/blob/master/numba_special/function_pointers.pyx > > and then you grab those on the Numba side to create the overloads: > > > https://github.com/person142/numba_special/blob/master/numba_special/numba_overloads.py > > You can see that the overloads are working as expected in the tests: > > > https://github.com/person142/numba_special/blob/master/numba_special/tests/test_functions.py > > (Note that the development version of Numba is required because of > this issue: https://github.com/numba/numba/issues/4133) > > Of course the pointers/overloads that you're creating are highly > structured, so you can just generate the necessary glue code: > > > https://github.com/person142/numba_special/blob/master/generate_overloads.py > > though it only handles simple function signatures right now. All in > all I think it works pretty well-you only use 100% officially > supported pieces of all the libraries involved. I'll probably work on > extending it more in the next couple of days. > Very nice, thanks Josh. That's all pretty clean and understandable code. Cheers, Ralf > On Thu, Jun 20, 2019 at 5:31 PM Nathaniel Smith wrote: > > > > On Thu, Jun 20, 2019 at 1:41 PM Stanley Seibert > wrote: > > > > > > Well, we'd prefer not to have an unnecessary indirection (and the > overhead of making a nested call to the scalar inside the length 1 loop) > since the user is doing their own iteration in Numba, but if that's the > only option, we can certainly work around it. > > > > Well, it's computers, so there's never just one option :-). But if you > > can consume existing ufuncs and get 95% of the performance, then it > > might not be worth building custom infrastructure to expose > > scipy.special's raw scalar functions + an ad hoc metadata format + ad > > hoc tools to consume the metadata. Intuitively it seems like a few > > extra integer operations at entry and exit might not be noticeable at > > all compared to the cost of computing a bessel function or whatever, > > but I haven't checked. > > > > -n > > > > -- > > Nathaniel J. Smith -- https://vorpus.org > > _______________________________________________ > > 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 Jul 4 19:03:15 2019 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Thu, 4 Jul 2019 16:03:15 -0700 Subject: [SciPy-Dev] Sprint at SciPy Conference? In-Reply-To: References:

Message-ID: On Wed, Jul 3, 2019 at 10:42 AM Dashamir Hoxha wrote: > > On Sun, Jun 30, 2019 at 8:11 PM Ralf Gommers > wrote: > >> >> >> On Sat, Jun 29, 2019 at 8:19 PM Dashamir Hoxha >> wrote: >> >>> On Sun, Jun 23, 2019 at 7:42 AM Matt Haberland >>> wrote: >>> >>>> The SciPy Conference approaches! >>>> Who would be interested in a sprint >>>> ? >>>> Can you participate in-person or virtually? >>>> >>> >>> I would be interested to participate virtually, at least on the tutorial. >>> >> >> There's no tutorial in the sprints normally. The "how to contribute" >> tutorial (walk through a first pull request) is centrally done by the >> conference organizers, and people at the SciPy sprint typically dive >> straight in after some informal discussion with one of the core developers. >> >> >>> What do you usually do for virtual participation? >>> >> >> Usually only via GitHub, and perhaps IRC/Gitter. >> >> >>> Recently I have used successfully Guacamole for collaborating with some >>> online students: >>> >>> https://www.researchgate.net/publication/332469806_Linux_Desktop_In_a_Container >>> >>> I can also offer my infrastructure for this, if needed: >>> https://mint.fs.al:333/guac/ >>> It works well, combined with some videoconferencing application, for >>> example: https://meet.jit.si/ >>> >> >> I have to admit I've never tried any kind of videoconferencing during a >> sprint other than short video calls planned beforehand. I'm not sure it >> would work well to be honest. Partcipating via our regular channels would >> be better probably. >> > > Having no experience with NumPy/SciPy, I am not sure whether I can be > useful somehow on this sprint. But I would like to participate for a short > time anyway, just to see what's going on, if nothing else. I hope the > details will be announced in time. For example the schedule, the IRC > channel, etc. (are we going to use #scipy on freenode?) I don't need to > register somewhere, do I? > We will do that. Start time should be Sat July 13th around 9am CT. There's be an issue posted on GitHub with a summary of suggestions of what newcomers can work on. GitHub and mailing lists are the most reliable way to get feedback on comments/questions, but I'll try to log in on IRC as well. Cheers, Ralf > Thanks, > Dashamir > _______________________________________________ > 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 josh.craig.wilson at gmail.com Sun Jul 7 02:17:06 2019 From: josh.craig.wilson at gmail.com (Joshua Wilson) Date: Sat, 6 Jul 2019 23:17:06 -0700 Subject: [SciPy-Dev] Enabling use of scipy.special from Numba In-Reply-To: References:

Message-ID: Final update-an initial release of the package is up on PyPI: https://pypi.org/project/numba-special/ There's more work to be done, but you can see a list what can currently be used from Numba here: https://numba-special.readthedocs.io/en/latest/numba_special.html On Thu, Jul 4, 2019 at 4:00 PM Ralf Gommers wrote: > > > > On Thu, Jul 4, 2019 at 12:23 AM Joshua Wilson wrote: >> >> Ok, returning to the special functions in Numba topic: here's a small >> repo that generates overloads for a few special functions: >> >> https://github.com/person142/numba_special/tree/master/numba_special >> >> Taking Nathaniel's point that coming up with an ad-hoc metadata format >> is probably not a good idea, it instead uses a little bit of Cython to >> pull out the function pointers: >> >> https://github.com/person142/numba_special/blob/master/numba_special/function_pointers.pyx >> >> and then you grab those on the Numba side to create the overloads: >> >> https://github.com/person142/numba_special/blob/master/numba_special/numba_overloads.py >> >> You can see that the overloads are working as expected in the tests: >> >> https://github.com/person142/numba_special/blob/master/numba_special/tests/test_functions.py >> >> (Note that the development version of Numba is required because of >> this issue: https://github.com/numba/numba/issues/4133) >> >> Of course the pointers/overloads that you're creating are highly >> structured, so you can just generate the necessary glue code: >> >> https://github.com/person142/numba_special/blob/master/generate_overloads.py >> >> though it only handles simple function signatures right now. All in >> all I think it works pretty well-you only use 100% officially >> supported pieces of all the libraries involved. I'll probably work on >> extending it more in the next couple of days. > > > Very nice, thanks Josh. That's all pretty clean and understandable code. > > Cheers, > Ralf > >> >> On Thu, Jun 20, 2019 at 5:31 PM Nathaniel Smith wrote: >> > >> > On Thu, Jun 20, 2019 at 1:41 PM Stanley Seibert wrote: >> > > >> > > Well, we'd prefer not to have an unnecessary indirection (and the overhead of making a nested call to the scalar inside the length 1 loop) since the user is doing their own iteration in Numba, but if that's the only option, we can certainly work around it. >> > >> > Well, it's computers, so there's never just one option :-). But if you >> > can consume existing ufuncs and get 95% of the performance, then it >> > might not be worth building custom infrastructure to expose >> > scipy.special's raw scalar functions + an ad hoc metadata format + ad >> > hoc tools to consume the metadata. Intuitively it seems like a few >> > extra integer operations at entry and exit might not be noticeable at >> > all compared to the cost of computing a bessel function or whatever, >> > but I haven't checked. >> > >> > -n >> > >> > -- >> > Nathaniel J. Smith -- https://vorpus.org >> > _______________________________________________ >> > 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 From andyfaff at gmail.com Sun Jul 7 18:10:41 2019 From: andyfaff at gmail.com (Andrew Nelson) Date: Mon, 8 Jul 2019 08:10:41 +1000 Subject: [SciPy-Dev] pybind11 dependency (was: scipy.fft submodule) In-Reply-To: References: Message-ID: On Fri, 5 Jul 2019 at 04:09, Ralf Gommers wrote: > Given that a few people were surprised that SciPy master now has a > pybind11 dependency and asked if it was discussed on this list (to which I > didn't have an immediate answer), replying to this thread with a more > explicit subject. > > So far pybind11 seems to have worked fine, except that it's not yet > documented in all our build instructions (there's open PRs for this though, > it's just waiting for Matt's larger devdocs overhaul), and that we seem to > require a fairly recent version of pybind11. > If there's any other missing docs or concerns, please bring them up here. > Sigh. Having difficulties installing pybind on macOS, Python3.7.2, with pip 19.1.1. I guess I'll have to delve into this further. I was expecting the install to be straightforward. (dev3) 192-168-1-101:scipy-articles andrew$ pip install pybind Collecting pybind Using cached https://files.pythonhosted.org/packages/39/25/357918ab3113ac886ae5a24413063633040ab9bba66a95c0a13f8f42315e/pybind-0.1.35.tar.gz Collecting pyangbind-brcd>=0.6.14 (from pybind) Using cached https://files.pythonhosted.org/packages/2d/12/299ccb698d0bfc0da6a7fc7165e1697160c178e4839df286bac45843f2d2/pyangbind-brcd-0.6.14.tar.gz ERROR: Complete output from command python setup.py egg_info: ERROR: Traceback (most recent call last): File "", line 1, in File "/private/var/folders/m8/gwtcncws12jf60xw5n6knwnw0000gn/T/pip-install-1enlx25j/pyangbind-brcd/setup.py", line 2, in from pip.req import parse_requirements ModuleNotFoundError: No module named 'pip.req' ---------------------------------------- ERROR: Command "python setup.py egg_info" failed with error code 1 in /private/var/folders/m8/gwtcncws12jf60xw5n6knwnw0000gn/T/pip-install-1enlx25j/pyangbind-brcd/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthieu.brucher at gmail.com Sun Jul 7 18:13:18 2019 From: matthieu.brucher at gmail.com (Matthieu Brucher) Date: Sun, 7 Jul 2019 23:13:18 +0100 Subject: [SciPy-Dev] pybind11 dependency (was: scipy.fft submodule) In-Reply-To: References:

Message-ID: pybind11, not pybind ;) Le dim. 7 juil. 2019 ? 23:11, Andrew Nelson a ?crit : > On Fri, 5 Jul 2019 at 04:09, Ralf Gommers wrote: > >> Given that a few people were surprised that SciPy master now has a >> pybind11 dependency and asked if it was discussed on this list (to which I >> didn't have an immediate answer), replying to this thread with a more >> explicit subject. >> > > > > >> So far pybind11 seems to have worked fine, except that it's not yet >> documented in all our build instructions (there's open PRs for this though, >> it's just waiting for Matt's larger devdocs overhaul), and that we seem to >> require a fairly recent version of pybind11. >> If there's any other missing docs or concerns, please bring them up here. >> > > Sigh. Having difficulties installing pybind on macOS, Python3.7.2, with > pip 19.1.1. I guess I'll have to delve into this further. I was expecting > the install to be straightforward. > > > (dev3) 192-168-1-101:scipy-articles andrew$ pip install pybind > > Collecting pybind > > Using cached > https://files.pythonhosted.org/packages/39/25/357918ab3113ac886ae5a24413063633040ab9bba66a95c0a13f8f42315e/pybind-0.1.35.tar.gz > > Collecting pyangbind-brcd>=0.6.14 (from pybind) > > Using cached > https://files.pythonhosted.org/packages/2d/12/299ccb698d0bfc0da6a7fc7165e1697160c178e4839df286bac45843f2d2/pyangbind-brcd-0.6.14.tar.gz > > ERROR: Complete output from command python setup.py egg_info: > > ERROR: Traceback (most recent call last): > > File "", line 1, in > > File > "/private/var/folders/m8/gwtcncws12jf60xw5n6knwnw0000gn/T/pip-install-1enlx25j/pyangbind-brcd/setup.py", > line 2, in > > from pip.req import parse_requirements > > ModuleNotFoundError: No module named 'pip.req' > > ---------------------------------------- > > ERROR: Command "python setup.py egg_info" failed with error code 1 in > /private/var/folders/m8/gwtcncws12jf60xw5n6knwnw0000gn/T/pip-install-1enlx25j/pyangbind-brcd/ > > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at python.org > https://mail.python.org/mailman/listinfo/scipy-dev > -- Quantitative researcher, Ph.D. Blog: http://blog.audio-tk.com/ LinkedIn: http://www.linkedin.com/in/matthieubrucher -------------- next part -------------- An HTML attachment was scrubbed... URL: From andyfaff at gmail.com Sun Jul 7 18:16:19 2019 From: andyfaff at gmail.com (Andrew Nelson) Date: Mon, 8 Jul 2019 08:16:19 +1000 Subject: [SciPy-Dev] pybind11 dependency (was: scipy.fft submodule) In-Reply-To: References:

Message-ID: On Mon, 8 Jul 2019 at 08:14, Matthieu Brucher wrote: > pybind11, not pybind ;) > >> Thank you, that fixed it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sseibert at anaconda.com Mon Jul 8 08:59:59 2019 From: sseibert at anaconda.com (Stanley Seibert) Date: Mon, 8 Jul 2019 07:59:59 -0500 Subject: [SciPy-Dev] Enabling use of scipy.special from Numba In-Reply-To: References:

Message-ID: This is great! Thanks for doing this. (We're aiming to get the Numba release with the required patches for overloading NumPy functions out in about 2 weeks.) On Sun, Jul 7, 2019 at 1:18 AM Joshua Wilson wrote: > Final update-an initial release of the package is up on PyPI: > > https://pypi.org/project/numba-special/ > > There's more work to be done, but you can see a list what can > currently be used from Numba here: > > https://numba-special.readthedocs.io/en/latest/numba_special.html > > On Thu, Jul 4, 2019 at 4:00 PM Ralf Gommers > wrote: > > > > > > > > On Thu, Jul 4, 2019 at 12:23 AM Joshua Wilson < > josh.craig.wilson at gmail.com> wrote: > >> > >> Ok, returning to the special functions in Numba topic: here's a small > >> repo that generates overloads for a few special functions: > >> > >> https://github.com/person142/numba_special/tree/master/numba_special > >> > >> Taking Nathaniel's point that coming up with an ad-hoc metadata format > >> is probably not a good idea, it instead uses a little bit of Cython to > >> pull out the function pointers: > >> > >> > https://github.com/person142/numba_special/blob/master/numba_special/function_pointers.pyx > >> > >> and then you grab those on the Numba side to create the overloads: > >> > >> > https://github.com/person142/numba_special/blob/master/numba_special/numba_overloads.py > >> > >> You can see that the overloads are working as expected in the tests: > >> > >> > https://github.com/person142/numba_special/blob/master/numba_special/tests/test_functions.py > >> > >> (Note that the development version of Numba is required because of > >> this issue: https://github.com/numba/numba/issues/4133) > >> > >> Of course the pointers/overloads that you're creating are highly > >> structured, so you can just generate the necessary glue code: > >> > >> > https://github.com/person142/numba_special/blob/master/generate_overloads.py > >> > >> though it only handles simple function signatures right now. All in > >> all I think it works pretty well-you only use 100% officially > >> supported pieces of all the libraries involved. I'll probably work on > >> extending it more in the next couple of days. > > > > > > Very nice, thanks Josh. That's all pretty clean and understandable code. > > > > Cheers, > > Ralf > > > >> > >> On Thu, Jun 20, 2019 at 5:31 PM Nathaniel Smith wrote: > >> > > >> > On Thu, Jun 20, 2019 at 1:41 PM Stanley Seibert < > sseibert at anaconda.com> wrote: > >> > > > >> > > Well, we'd prefer not to have an unnecessary indirection (and the > overhead of making a nested call to the scalar inside the length 1 loop) > since the user is doing their own iteration in Numba, but if that's the > only option, we can certainly work around it. > >> > > >> > Well, it's computers, so there's never just one option :-). But if you > >> > can consume existing ufuncs and get 95% of the performance, then it > >> > might not be worth building custom infrastructure to expose > >> > scipy.special's raw scalar functions + an ad hoc metadata format + ad > >> > hoc tools to consume the metadata. Intuitively it seems like a few > >> > extra integer operations at entry and exit might not be noticeable at > >> > all compared to the cost of computing a bessel function or whatever, > >> > but I haven't checked. > >> > > >> > -n > >> > > >> > -- > >> > Nathaniel J. Smith -- https://vorpus.org > >> > _______________________________________________ > >> > 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 mahendri.md at gmail.com Wed Jul 10 09:50:43 2019 From: mahendri.md at gmail.com (Mahendri Dwicahyo) Date: Wed, 10 Jul 2019 20:50:43 +0700 Subject: [SciPy-Dev] Adding Poisson Mean Test to SciPy Message-ID: Hello scipy-dev community, I am Mahendri, an undergraduate student majoring in Computational Statistics. I notice that as of now, SciPy does not have two sample mean difference test from poisson distribution data. So I search for poisson mean test and I am interested in E-test written by Krishnamoorthy and Thomson because it has more power than its predecessor (C-test) and provide the code. The paper also quite popular with 126 citations. The code is written in Fortran but I am able to port that into python. The python implementation have dependencies for numpy and scipy.stats.poisson, the loop is removed and odd behavior found at original code is solved. Do you think it is possible to incorporate the test into SciPy? Thank you -- Mahendri Dwicahyo Computational Statistics, Polytechnic of Statistics STIS-BPS 15.8727 at stis.ac.id | mahendri.md at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From PeterBell10 at live.co.uk Thu Jul 11 12:11:13 2019 From: PeterBell10 at live.co.uk (Peter Bell) Date: Thu, 11 Jul 2019 16:11:13 +0000 Subject: [SciPy-Dev] macOS minimum version and scipy.fft Message-ID: Hello All, Does anyone know what the minimum macOS version is that SciPy currently targets? And are there any objections to raising this to 10.9? The context for this is that in gh-10383 I am using uarray to add backend support to scipy.fft. uarray was recently rewritten in C++ and uses the thread_local keyword to support context-local backends. It's this single language feature that limits the version as older AppleClang versions didn't implement it. It can be worked around if support is an issue though. - Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.gommers at gmail.com Sat Jul 13 09:15:55 2019 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Sat, 13 Jul 2019 06:15:55 -0700 Subject: [SciPy-Dev] macOS minimum version and scipy.fft In-Reply-To: References: Message-ID: On Thu, Jul 11, 2019 at 9:11 AM Peter Bell wrote: > Hello All, > > > > Does anyone know what the minimum macOS version is that SciPy currently > targets? And are there any objections to raising this to 10.9? > I got lucky, a 10.8 user just found the issue I couldn't remember by commenting that numpy 1.16 didn't work anymore on <10.9. This happened when NumPy (and SciPy) dropped Accelerate support: https://github.com/numpy/numpy/issues/12939#issuecomment-461006715 Cheers, Ralf The context for this is that in gh-10383 > I am using uarray > to add backend > support to scipy.fft. uarray was recently rewritten in C++ and uses the > thread_local keyword to support context-local backends. It?s this single > language feature that limits the version as older AppleClang versions > didn?t implement it. It can be worked around if support is an issue though. > > - Peter > _______________________________________________ > 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 Tue Jul 16 11:15:15 2019 From: charlesr.harris at gmail.com (Charles R Harris) Date: Tue, 16 Jul 2019 09:15:15 -0600 Subject: [SciPy-Dev] NumPy 1.17.0rc2 released In-Reply-To: References: Message-ID: Hi All, On behalf of the NumPy team I am pleased to announce the release of NumPy 1.17.0rc2. The 1.17 release contains a number of new features that should substantially improve its performance and usefulness. The Python versions supported are 3.5-3.7, note that Python 2.7 has been dropped. Python 3.8b2 should work with the released source packages, but there are no guarantees about future releases. Highlights of this release are: - A new extensible random module along with four selectable random number generators and improved seeding designed for use in parallel processes has been added. The currently available bit generators are MT19937, PCG64, Philox, and SFC64. - NumPy's FFT implementation was changed from fftpack to pocketfft, resulting in faster, more accurate transforms and better handling of datasets of prime length. - New radix sort and timsort sorting methods. It is currently not possible to choose which will be used, but they are hardwired to the datatype and used when either ``stable`` or ``mergesort`` is passed as the method. - Overriding numpy functions is now possible by default Downstream developers should use Cython >= 0.29.10 for Python 3.8 support and OpenBLAS >= 3.7 (not currently out) to avoid problems on the Skylake architecture. The NumPy wheels on PyPI are built from the OpenBLAS development branch in order to avoid those problems. Wheels for this release can be downloaded from PyPI , source archives and release notes are available from Github . *Contributors* A total of 146 people contributed to this release. People with a "+" by their names contributed a patch for the first time. - Aaron Voelker + - Abdur Rehman + - Abdur-Rahmaan Janhangeer + - Abhinav Sagar + - Adam J. Stewart + - Adam Orr + - Albert Thomas + - Alex Watt + - Alexander Blinne + - Alexander Shadchin - Allan Haldane - Ander Ustarroz + - Andras Deak - Andrea Pattori + - Andreas Schwab - Andrew Naguib + - Andy Scholand + - Ankit Shukla + - Anthony Sottile - Antoine Pitrou - Antony Lee - Arcesio Castaneda Medina + - Assem + - Bernardt Duvenhage + - Bharat Raghunathan + - Bharat123rox + - Bran + - Bruce Merry + - Charles Harris - Chirag Nighut + - Christoph Gohlke - Christopher Whelan + - Chuanzhu Xu + - Dan Allan + - Daniel Hrisca - Daniel Lawrence + - Debsankha Manik + - Dennis Zollo + - Dieter Werthm?ller + - Dominic Jack + - EelcoPeacs + - Eric Larson - Eric Wieser - Fabrice Fontaine + - Gary Gurlaskie + - Gregory Lee + - Gregory R. Lee - Guillaume Horel + - Hameer Abbasi - Haoyu Sun + - He Jia + - Hunter Damron + - Ian Sanders + - Ilja + - Isaac Virshup + - Isaiah Norton + - Jaime Fernandez - Jakub Wilk - Jan S. (Milania1) + - Jarrod Millman - Javier Dehesa + - Jeremy Lay + - Jim Turner + - Jingbei Li + - Joachim Hereth + - Johannes Hampp + - John Belmonte + - John Kirkham - John Law + - Jonas Jensen - Joseph Fox-Rabinovitz - Joseph Martinot-Lagarde - Josh Wilson - Juan Luis Cano Rodr?guez - Julian Taylor - J?r?mie du Boisberranger + - Kai Striega + - Katharine Hyatt + - Kevin Sheppard - Kexuan Sun - Kiko Correoso + - Kriti Singh + - Lars Grueter + - Maksim Shabunin + - Manvi07 + - Mark Harfouche - Marten van Kerkwijk - Martin Reinecke + - Matthew Brett - Matthias Bussonnier - Matti Picus - Michel Fruchart + - Mike Lui + - Mike Taves + - Min ho Kim + - Mircea Akos Bruma - Nick Minkyu Lee - Nick Papior - Nick R. Papior + - Nicola Soranzo + - Nimish Telang + - OBATA Akio + - Oleksandr Pavlyk - Ori Broda + - Paul Ivanov - Pauli Virtanen - Peter Andreas Entschev + - Peter Bell + - Pierre de Buyl - Piyush Jaipuriayar + - Prithvi MK + - Raghuveer Devulapalli + - Ralf Gommers - Richard Harris + - Rishabh Chakrabarti + - Riya Sharma + - Robert Kern - Roman Yurchak - Ryan Levy + - Sebastian Berg - Sergei Lebedev + - Shekhar Prasad Rajak + - Stefan van der Walt - Stephan Hoyer - Steve Stagg + - SuryaChand P + - S?ren Rasmussen + - Thibault Hallouin + - Thomas A Caswell - Tobias Uelwer + - Tony LaTorre + - Toshiki Kataoka - Tyler Moncur + - Tyler Reddy - Valentin Haenel - Vrinda Narayan + - Warren Weckesser - Weitang Li - Wojtek Ruszczewski - Yu Feng - Yu Kobayashi + - Yury Kirienko + - @aashuli + - @luzpaz - @parul + - @spacescientist + Cheers, Charles Harris -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.gommers at gmail.com Tue Jul 16 18:16:38 2019 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Tue, 16 Jul 2019 15:16:38 -0700 Subject: [SciPy-Dev] welcome Peter and Greg to the core team Message-ID: Hi all, On behalf of the SciPy developers I'd like to welcome Peter Bell and Gregory Lee as members of the core team. Peter is our current GSoC participant, and he's doing a really amazing job on scipy.fft. Also, he's commenting on other PRs/issues and pitching in in other places. Here is an overview of his SciPy PRs: https://github.com/scipy/scipy/pulls/peterbell10 Greg is one of the mentors on Peter's GSoC project (together with Eric Larson), has contributed to SciPy regularly in the past, and is also a maintainer of both PyWavelets and PyFFTW. Here is an overview of his SciPy PRs: https://github.com/scipy/scipy/pulls/grlee77 I'm looking forward to Peter and Greg's continued contributions! Cheers, Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From warren.weckesser at gmail.com Tue Jul 16 18:42:00 2019 From: warren.weckesser at gmail.com (Warren Weckesser) Date: Tue, 16 Jul 2019 18:42:00 -0400 Subject: [SciPy-Dev] welcome Peter and Greg to the core team In-Reply-To: References: Message-ID: On 7/16/19, Ralf Gommers wrote: > Hi all, > > On behalf of the SciPy developers I'd like to welcome Peter Bell and > Gregory Lee as members of the core team. > > Peter is our current GSoC participant, and he's doing a really amazing job > on scipy.fft. Also, he's commenting on other PRs/issues and pitching in in > other places. > Here is an overview of his SciPy PRs: > https://github.com/scipy/scipy/pulls/peterbell10 > > Greg is one of the mentors on Peter's GSoC project (together with Eric > Larson), has contributed to SciPy regularly in the past, and is also a > maintainer of both PyWavelets and PyFFTW. > Here is an overview of his SciPy PRs: > https://github.com/scipy/scipy/pulls/grlee77 Welcome Peter and Greg! Thanks for the great work so far, looking forward to more... Warren > > I'm looking forward to Peter and Greg's continued contributions! > > Cheers, > Ralf > From einstein.edison at gmail.com Tue Jul 16 18:46:00 2019 From: einstein.edison at gmail.com (Hameer Abbasi) Date: Tue, 16 Jul 2019 22:46:00 +0000 Subject: [SciPy-Dev] welcome Peter and Greg to the core team In-Reply-To: References: Message-ID: Welcome Peter and Greg! I?ve had the pleasure of working personally with Peter and am really amazed by his skill level. Hameer Abbasi From: SciPy-Dev on behalf of Ralf Gommers Reply-To: SciPy Developers List Date: Wednesday, 17. July 2019 at 00:16 To: SciPy Developers List Subject: [SciPy-Dev] welcome Peter and Greg to the core team Hi all, On behalf of the SciPy developers I'd like to welcome Peter Bell and Gregory Lee as members of the core team. Peter is our current GSoC participant, and he's doing a really amazing job on scipy.fft. Also, he's commenting on other PRs/issues and pitching in in other places. Here is an overview of his SciPy PRs: https://github.com/scipy/scipy/pulls/peterbell10 Greg is one of the mentors on Peter's GSoC project (together with Eric Larson), has contributed to SciPy regularly in the past, and is also a maintainer of both PyWavelets and PyFFTW. Here is an overview of his SciPy PRs: https://github.com/scipy/scipy/pulls/grlee77 I'm looking forward to Peter and Greg's continued contributions! Cheers, Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From insertinterestingnamehere at gmail.com Tue Jul 16 18:50:58 2019 From: insertinterestingnamehere at gmail.com (Ian Henriksen) Date: Tue, 16 Jul 2019 17:50:58 -0500 Subject: [SciPy-Dev] welcome Peter and Greg to the core team In-Reply-To: References: Message-ID: Welcome! On Tue, Jul 16, 2019 at 5:17 PM Ralf Gommers wrote: > Hi all, > > On behalf of the SciPy developers I'd like to welcome Peter Bell and > Gregory Lee as members of the core team. > > Peter is our current GSoC participant, and he's doing a really amazing job > on scipy.fft. Also, he's commenting on other PRs/issues and pitching in in > other places. > Here is an overview of his SciPy PRs: > https://github.com/scipy/scipy/pulls/peterbell10 > > Greg is one of the mentors on Peter's GSoC project (together with Eric > Larson), has contributed to SciPy regularly in the past, and is also a > maintainer of both PyWavelets and PyFFTW. > Here is an overview of his SciPy PRs: > https://github.com/scipy/scipy/pulls/grlee77 > > I'm looking forward to Peter and Greg's continued contributions! > > 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 evgeny.burovskiy at gmail.com Wed Jul 17 03:01:52 2019 From: evgeny.burovskiy at gmail.com (Evgeni Burovski) Date: Wed, 17 Jul 2019 10:01:52 +0300 Subject: [SciPy-Dev] welcome Peter and Greg to the core team In-Reply-To: References: Message-ID: Welcome Greg and Peter! ??, 17 ???. 2019 ?., 1:52 Ian Henriksen : > Welcome! > > On Tue, Jul 16, 2019 at 5:17 PM Ralf Gommers > wrote: > >> Hi all, >> >> On behalf of the SciPy developers I'd like to welcome Peter Bell and >> Gregory Lee as members of the core team. >> >> Peter is our current GSoC participant, and he's doing a really amazing >> job on scipy.fft. Also, he's commenting on other PRs/issues and pitching in >> in other places. >> Here is an overview of his SciPy PRs: >> https://github.com/scipy/scipy/pulls/peterbell10 >> >> Greg is one of the mentors on Peter's GSoC project (together with Eric >> Larson), has contributed to SciPy regularly in the past, and is also a >> maintainer of both PyWavelets and PyFFTW. >> Here is an overview of his SciPy PRs: >> https://github.com/scipy/scipy/pulls/grlee77 >> >> I'm looking forward to Peter and Greg's continued contributions! >> >> 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 ralf.gommers at gmail.com Wed Jul 17 20:13:28 2019 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Wed, 17 Jul 2019 19:13:28 -0500 Subject: [SciPy-Dev] to our Season of Docs applicants Message-ID: Hi everyone, To start with, I want to thank all of you who applied for GSoD! There's a lot of interest in helping improve SciPy's documentation and web presence, which is awesome to see. During the application phase, we have interacted with some of you already, and I will reach out to others over the next few days. I'm just writing this email to say thank you and to confirm that yes we did receive your application. Due to the volume of applications, it will be difficult to reach out personally to all of you (I'll do my best though!), hence this email. Really looking forward to what will happen next! Cheers, Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From scipy-dev at fuglede.dk Mon Jul 22 15:50:29 2019 From: scipy-dev at fuglede.dk (=?iso-8859-1?Q?S=F8ren_Fuglede_J=F8rgensen?=) Date: Mon, 22 Jul 2019 21:50:29 +0200 Subject: [SciPy-Dev] Combinatorial optimization in scipy.optimize In-Reply-To: References: <20190627075201.hna2k5hb6svrzzuj@hackenturet.dk> <20190627080623.6m6pvbnwlvretphx@hackenturet.dk> <20190627110751.zpcin5yzpsjfwbr4@hackenturet.dk> Message-ID: <20190722195029.nxifvbhtop33zsod@hackenturet.dk> On Wed, Jul 03, 2019 at 12:04:38PM -0700, Ralf Gommers wrote: > Some of these are in scipy.sparse.csgraph already. Thanks for the reference to scipy.sparse.csgraph; I had indeed missed that completely, and had I known about it, I might have actually expected something like linear_sum_assignment to live there, as touched upon in https://github.com/scipy/scipy/pull/10296. > We indeed don't want to do everything that NetworkX already does, however > if it's a well-known algorithm that would fit in with what we already have > and focus on performance (which NetworkX does not do) then I think there's > scope for more. For sparse.csgraph I think Jake implemented a set of > standard algorithms that can be found in a graph algorithms introductory > handbook. I think it's definitely possible to find a handful of algorithms that match that description; the first that came to mind here would be the Edmonds--Karp and push--relabel algorithms for computing maximum flow. > It also depends to some extent on who writes the code - technical code like > that is often not the easiest to maintain, so it would make the > conversation and review process a lot easier of there is a person (or two > people) with a commitment to maintain the code going forward. Makes sense. And I can see how that would also make you favor simpler versions of whatever algorithms might be relevant. S?ren From ralf.gommers at gmail.com Wed Jul 24 22:19:00 2019 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Wed, 24 Jul 2019 19:19:00 -0700 Subject: [SciPy-Dev] Season of Docs applications In-Reply-To: References: Message-ID: Hi all, Here is a short update on Season of Docs. We are very happy and impressed with the number and quality of tech writers who applied to NumPy and SciPy. We decided we would really like to accept more people than the number of slots Google is likely to give us. We have found some more funding and mentoring bandwidth to be able to do so. After Google announces which candidates have been accepted, we will reach out to the next people on our shortlist and offer them the same mentoring and funding for their proposed projects as the accepted GSoD writers. I'm really looking forward to an interesting and productive fall working with several of you. Stay tuned! Cheers, Ralf On Wed, Jul 17, 2019 at 5:12 PM Ralf Gommers wrote: > Hi GSoD applicants, > > To start with, I want to thank all of you who applied! There's a lot of > interest in helping improve NumPy's documentation and web presence, which > is awesome to see. During the application phase, we have interacted with > some of you already, and I will reach out to others over the next few days. > I'm just writing this email to say thank you and to confirm that yes we did > receive your application. Due to the volume of applications, it will be > difficult to reach out personally to all of you (I'll do my best though!), > hence this email. > > Really looking forward to what will happen next! > > Cheers, > Ralf > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From PeterBell10 at live.co.uk Thu Jul 25 11:00:28 2019 From: PeterBell10 at live.co.uk (Peter Bell) Date: Thu, 25 Jul 2019 15:00:28 +0000 Subject: [SciPy-Dev] Removal of fortran FFTPACK Message-ID: Hello all, As of gh-10493, pypocketfft now implements the discrete sine and cosine transforms meaning it is a complete replacement for the fortran FFTPACK library. In gh-10507, I have proposed removing the fortran code from scipy completely and having scipy.fftpack depend on scipy.fft. This means that scipy.fftpack will now see some of the additional benefits of scipy.fft such as: long double transforms, GIL release, bluestein's algorithm, improved accuracy and improved multi-dimensional transform performance. However, there may be some cases where this affects users. For example, it will break anyone importing the private scipy.fftpack._fftpack submodule and the DCT and DST type-I are now about two times slower (but orders of magnitude more accurate). Regards, Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: From tyler.je.reddy at gmail.com Thu Jul 25 11:38:04 2019 From: tyler.je.reddy at gmail.com (Tyler Reddy) Date: Thu, 25 Jul 2019 09:38:04 -0600 Subject: [SciPy-Dev] SciPy 1.0 preprint is up Message-ID: The community may like to know that the arXiv preprint of the SciPy 1.0 paper is up: https://arxiv.org/abs/1907.10121 The email with password to claim ownership on the paper should start circulating to co-authors soon. Submitting the manuscript to a peer reviewed journal is also likely to happen soon (again). Best wishes, Tyler -------------- next part -------------- An HTML attachment was scrubbed... URL: From pinakinathc at gmail.com Thu Jul 25 11:58:50 2019 From: pinakinathc at gmail.com (Pinaki Nath Chowdhury) Date: Thu, 25 Jul 2019 21:28:50 +0530 Subject: [SciPy-Dev] SciPy 1.0 preprint is up In-Reply-To: References: Message-ID: wow this is great!! thanks. On Thu, 25 Jul, 2019, 21:09 Tyler Reddy, wrote: > The community may like to know that the arXiv preprint of the SciPy 1.0 > paper is up: https://arxiv.org/abs/1907.10121 > > The email with password to claim ownership on the paper should start > circulating to co-authors soon. > > Submitting the manuscript to a peer reviewed journal is also likely to > happen soon (again). > > Best wishes, > Tyler > _______________________________________________ > 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 larson.eric.d at gmail.com Thu Jul 25 14:08:21 2019 From: larson.eric.d at gmail.com (Eric Larson) Date: Thu, 25 Jul 2019 14:08:21 -0400 Subject: [SciPy-Dev] Removal of fortran FFTPACK In-Reply-To: References: Message-ID: I plan to merge Peter's PR this coming Monday unless there are objections. Eric On Thu, Jul 25, 2019 at 11:00 AM Peter Bell wrote: > Hello all, > > > > As of gh-10493 , pypocketfft > now implements the discrete sine and cosine transforms meaning it is a > complete replacement for the fortran FFTPACK library. In gh-10507 > , I have proposed removing the > fortran code from scipy completely and having scipy.fftpack depend on > scipy.fft. > > > > This means that scipy.fftpack will now see some of the additional benefits > of scipy.fft > > such as: long double transforms, GIL release, bluestein?s algorithm, > improved accuracy and improved multi-dimensional transform performance. > > > > However, there may be some cases where this affects users. For example, it > will break anyone importing the private scipy.fftpack._fftpack submodule > and the DCT and DST type-I are now about two times slower (but orders of > magnitude more accurate). > > > > Regards, > > Peter > > > > > _______________________________________________ > 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 Jul 25 14:37:54 2019 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Thu, 25 Jul 2019 11:37:54 -0700 Subject: [SciPy-Dev] Removal of fortran FFTPACK In-Reply-To: References:

Message-ID: On Thu, Jul 25, 2019 at 11:08 AM Eric Larson wrote: > I plan to merge Peter's PR this coming Monday unless there are objections. > Sounds good to me. Cheers, Ralf > Eric > > > On Thu, Jul 25, 2019 at 11:00 AM Peter Bell > wrote: > >> Hello all, >> >> >> >> As of gh-10493 , pypocketfft >> now implements the discrete sine and cosine transforms meaning it is a >> complete replacement for the fortran FFTPACK library. In gh-10507 >> , I have proposed removing >> the fortran code from scipy completely and having scipy.fftpack depend on >> scipy.fft. >> >> >> >> This means that scipy.fftpack will now see some of the additional benefits >> of scipy.fft >> >> such as: long double transforms, GIL release, bluestein?s algorithm, >> improved accuracy and improved multi-dimensional transform performance. >> >> >> >> However, there may be some cases where this affects users. For example, >> it will break anyone importing the private scipy.fftpack._fftpack submodule >> and the DCT and DST type-I are now about two times slower (but orders of >> magnitude more accurate). >> >> >> >> Regards, >> >> Peter >> >> >> >> >> _______________________________________________ >> 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 spanda3 at jhu.edu Thu Jul 25 19:01:46 2019 From: spanda3 at jhu.edu (Sambit Panda) Date: Thu, 25 Jul 2019 23:01:46 +0000 Subject: [SciPy-Dev] PR for the addition of scipy.stats.mgc Message-ID: <91BB4268-0C8F-47CD-9C28-D6A977AE674B@contoso.com> Hello all, For the past few weeks, I have been working on integrating MGC into scipy.stats as an additional ?correlation function? (https://github.com/scipy/scipy/pull/10524). Just for reference, I had sent previous messages about this here: https://mail.python.org/pipermail/scipy-dev/2019-June/023544.html and https://mail.python.org/pipermail/scipy-dev/2019-June/023566.html. For the time being, I have only added MGC and not any of the other implementations (will do this during the next few weeks). I followed the SciPy development workflow instructions and invite your review. Thank you, Sambit Panda -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.gommers at gmail.com Fri Jul 26 00:07:59 2019 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Thu, 25 Jul 2019 23:07:59 -0500 Subject: [SciPy-Dev] PR for the addition of scipy.stats.mgc In-Reply-To: <91BB4268-0C8F-47CD-9C28-D6A977AE674B@contoso.com> References: <91BB4268-0C8F-47CD-9C28-D6A977AE674B@contoso.com> Message-ID: On Thu, Jul 25, 2019 at 6:17 PM Sambit Panda wrote: > Hello all, > > > > For the past few weeks, I have been working on integrating MGC into > scipy.stats as an additional ?correlation function? ( > https://github.com/scipy/scipy/pull/10524). Just for reference, I had > sent previous messages about this here: > https://mail.python.org/pipermail/scipy-dev/2019-June/023544.html and > https://mail.python.org/pipermail/scipy-dev/2019-June/023566.html. > > > > For the time being, I have only added MGC and not any of the other > implementations (will do this during the next few weeks). I followed the > SciPy development workflow instructions and invite your review. > Hi Sambit, that looks promising, thank you! Cheers, Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From charlesr.harris at gmail.com Fri Jul 26 15:02:06 2019 From: charlesr.harris at gmail.com (Charles R Harris) Date: Fri, 26 Jul 2019 13:02:06 -0600 Subject: [SciPy-Dev] NumPy 1.17.0 released In-Reply-To: References: Message-ID: Hi All, On behalf of the NumPy team I am pleased to announce the release of NumPy 1.17.0. The 1.17.0 release contains a number of new features that should substantially improve its performance and usefulness. The Python versions supported are 3.5-3.7, note that Python 2.7 has been dropped. Python 3.8b2 should work with the released source packages, but there are no guarantees about future releases. Highlights of this release are: - A new extensible random module along with four selectable random number generators and improved seeding designed for use in parallel processes has been added. The currently available bit generators are MT19937, PCG64, Philox, and SFC64. - NumPy's FFT implementation was changed from fftpack to pocketfft, resulting in faster, more accurate transforms and better handling of datasets of prime length. - New radix sort and timsort sorting methods. It is currently not possible to choose which will be used, but they are hardwired to the datatype and used when either ``stable`` or ``mergesort`` is passed as the method. - Overriding numpy functions is now possible by default Downstream developers should use Cython >= 0.29.10 for Python 3.8 support and OpenBLAS >= 3.7 (not currently out) to avoid problems on the Skylake architecture. The NumPy wheels on PyPI are built from the OpenBLAS development branch in order to avoid those problems. Wheels for this release can be downloaded from PyPI , source archives and release notes are available from Github . *Contributors* A total of 150 people contributed to this release. People with a "+" by their names contributed a patch for the first time. - Aaron Voelker + - Abdur Rehman + - Abdur-Rahmaan Janhangeer + - Abhinav Sagar + - Adam J. Stewart + - Adam Orr + - Albert Thomas + - Alex Watt + - Alexander Blinne + - Alexander Shadchin - Allan Haldane - Ander Ustarroz + - Andras Deak - Andrea Pattori + - Andreas Schwab - Andrew Naguib + - Andy Scholand + - Ankit Shukla + - Anthony Sottile - Antoine Pitrou - Antony Lee - Arcesio Castaneda Medina + - Assem + - Bernardt Duvenhage + - Bharat Raghunathan + - Bharat123rox + - Bran + - Bruce Merry + - Charles Harris - Chirag Nighut + - Christoph Gohlke - Christopher Whelan + - Chuanzhu Xu + - Colin Snyder + - Dan Allan + - Daniel Hrisca - Daniel Lawrence + - Debsankha Manik + - Dennis Zollo + - Dieter Werthm?ller + - Dominic Jack + - EelcoPeacs + - Eric Larson - Eric Wieser - Fabrice Fontaine + - Gary Gurlaskie + - Gregory Lee + - Gregory R. Lee - Guillaume Horel + - Hameer Abbasi - Haoyu Sun + - Harmon + - He Jia + - Hunter Damron + - Ian Sanders + - Ilja + - Isaac Virshup + - Isaiah Norton + - Jackie Leng + - Jaime Fernandez - Jakub Wilk - Jan S. (Milania1) + - Jarrod Millman - Javier Dehesa + - Jeremy Lay + - Jim Turner + - Jingbei Li + - Joachim Hereth + - Johannes Hampp + - John Belmonte + - John Kirkham - John Law + - Jonas Jensen - Joseph Fox-Rabinovitz - Joseph Martinot-Lagarde - Josh Wilson - Juan Luis Cano Rodr?guez - Julian Taylor - J?r?mie du Boisberranger + - Kai Striega + - Katharine Hyatt + - Kevin Sheppard - Kexuan Sun - Kiko Correoso + - Kriti Singh + - Lars Grueter + - Luis Pedro Coelho - Maksim Shabunin + - Manvi07 + - Mark Harfouche - Marten van Kerkwijk - Martin Reinecke + - Matthew Brett - Matthias Bussonnier - Matti Picus - Michel Fruchart + - Mike Lui + - Mike Taves + - Min ho Kim + - Mircea Akos Bruma - Nick Minkyu Lee - Nick Papior - Nick R. Papior + - Nicola Soranzo + - Nimish Telang + - OBATA Akio + - Oleksandr Pavlyk - Ori Broda + - Paul Ivanov - Pauli Virtanen - Peter Andreas Entschev + - Peter Bell + - Pierre de Buyl - Piyush Jaipuriayar + - Prithvi MK + - Raghuveer Devulapalli + - Ralf Gommers - Richard Harris + - Rishabh Chakrabarti + - Riya Sharma + - Robert Kern - Roman Yurchak - Ryan Levy + - Sebastian Berg - Sergei Lebedev + - Shekhar Prasad Rajak + - Stefan van der Walt - Stephan Hoyer - Steve Stagg + - SuryaChand P + - S?ren Rasmussen + - Thibault Hallouin + - Thomas A Caswell - Tobias Uelwer + - Tony LaTorre + - Toshiki Kataoka - Tyler Moncur + - Tyler Reddy - Valentin Haenel - Vrinda Narayan + - Warren Weckesser - Weitang Li - Wojtek Ruszczewski - Yu Feng - Yu Kobayashi + - Yury Kirienko + - @aashuli + - @luzpaz - @parul + - @spacescientist + Cheers, Charles Harris -------------- next part -------------- An HTML attachment was scrubbed... URL: