Mailman 3 September 2016 - SciPy-Dev

dense output option in integrate.ode
by Evgeni Burovski Feb. 20, 2017

Feb. 20, 2017

Hi David, Hi Jim, > I am new to SciPy-dev. Will the dense output option in scipy.integrate.ode > become available in 0.17.0? This is a feature already available in the > original FORTAN, but wasn't implemented in the wrapper. If the feature is sent as a pull request against the scipy master branch, the PR is reviewed by the maintainers of the integrate package and merged into master before the release split, then yes, it would be available in 0.17.0. So far I do not see any progress towards it. > I wrote these dense output extensions that you listed: > > https://github.com/jddmartin/scipy/tree/dense_output_from_dopri5_and_dop853 > https://github.com/jddmartin/dense_output_example_usage > > but I didn't issue any pull request to scipy. I sent this message to the > scipy developers list: > http://article.gmane.org/gmane.comp.python.scientific.devel/19635/ > explaining the changes. I was hoping for some feedback before issuing a > pull request. Ah, I see that the email likely fell through the cracks back in April. Sorry about that. You might want to ping that email thread once more or send a pull request on github (or both). <snip> Cheers, Evgeni

3 5

SciPy governance model
by Ralf Gommers Jan. 18, 2017

Jan. 18, 2017

Hi all, Starting with the summary of my email of earlier today: I'd like to push on with agreeing on a governance model and document. We had some discussions and a hangout on that last year [1]. In the hangout we decided to give people some time to read up on provided info on how this worked in other projects, the Karl Fogel book, etc. I was supposed to organize a follow-up, but failed to do so until now. I will send a separate email about this shortly. We're now at a point where most other major projects in the scientific Python ecosystem have a formal governance model. Many are modeled after the Jupyter one [2], which defines a BDFL, a steering council and contributors, and a voting system to make decisions (simplified, there's much more - the whole document is worth reading). NumPy chose another model, with a steering council and consensus-based decision making [3]. >From the outside, the Jupyter model seems to be working for them. The NumPy model hasn't been exercised too much yet, but should work well too. There are variations on those two models in use as well (like the Jupyter model minus the BDFL). An email discussion on this topic without a concrete proposal or summary document is likely to go on for a long time and may not converge easily. A video conference is also tricky, with dates/timezones and discussion often going off on tangents. So I have the following proposal: - We start by drafting an extended summary of the various models and getting a sense of which model the core team prefers. - We then work out that model, and bring it back to this list for discussion/finetuning/acceptance. - "We" here is the group of people who indicate, on this list or to me off-list, that they want to participate by the end of this week. Thoughts? Volunteers? Ralf [1] https://mail.scipy.org/pipermail/scipy-dev/2015-April/020636.html [2] Jupyter governance doc: https://github.com/jupyter/governance [3] NumPy governance doc: http://docs.scipy.org/doc/numpy-dev/dev/governance/index.html [4] Producing Open Source software (Karl Fogel): http://producingoss.com/

10 33

Moving SciPy project organization forward
by Ralf Gommers Oct. 14, 2016

Oct. 14, 2016

Hi all, The next weeks/months I should have quite a bit of bandwidth, which I'd like to use to push forward a few things related to project organization that we've mostly discussed before but never really finalized. The below is a summary of my view on where we are and where we need to go. To discuss individual topics I'll send separate follow-up emails with separate subjects. What we have: - Reasonably good docs for new contributors and core devs. - Established community process for communication and decision making. - A healthy group of active contributors and core devs. - A project that's overall in good shape. What we need: - Set up a mailing list for the core team. - Draft and accept a governance model & docs. - Draft and accept a Code of Conduct (CoC) or "community guidelines" [1] or similar. - Agree on an FSA with NumFOCUS. - Merge the roadmap PR. - Agree on when to do a 1.0 release, and what still has to happen for that. Mailing list ------------ This is not so we do more in private, but just to be more efficient in the small number of conversations that already happens in private (like giving out commit rights). The core team has grown large enough that we tend to forget people or use an old email address. I will set this one up within a week, probably using Google Groups (if anyone has a better idea, please speak up). My plan is to add all active core devs, and send other people with commit rights a personal email about this to ask if they want to be on it (because not everyone follows this list). Governance model & docs ----------------------- We had some discussions and a hangout on that last year [2]. In the hangout we decided to give people some time to read up on provided info on how this worked in other projects, the Karl Fogel book [4], etc. I was supposed to organize a follow-up, but failed to do so until now. I will send a separate email about this shortly. CoC or similar -------------- This is pretty standard to have nowadays, can be welcoming to new people, and is required now by all projects that join NumFOCUS. I'll send a separate email about this later on - probably right after we've merged a governance document. Fiscal Sponsorship Agreement (FSA) ---------------------------------- We need this so we have all our ducks in a row to start dealing with funding/donations in a better way. We did get donations in the past, and even used that money to support the MingwPy project to help improve our Fortran-on-Windows situation. This was OK as a one-off for a very small amount of money, but this needs to be organized better. We also do get people who come up with ideas that would improve SciPy a lot and that we could have supported with some money, had we had the infrastructure for that in place. Let's come back to this as well once we have governance and CoC documents (those are prerequisites). Roadmap PR (gh-2908) -------------------- Let's just pick a date at which the thing [3] has to be merged, in the state it is in then (updated for comments received). And then start improving it with new PRs if needed. Leaving the PR open until everything is perfect hasn't quite worked so far. I'll propose a date 2 weeks from now on the PR itself. SciPy 1.0 --------- We've discussed this several times before. We're now at the point where most of the major gaps have been filled though, so it looks to me like it's time to just pick a date for it (either after or instead of 0.19.0) and then fix up the last things that we think we really need for a 1.0 release. I'll send a separate email about this shortly. Ralf [1] https://github.com/scikit-image/scikit-image-web/pull/36 [2] https://mail.scipy.org/pipermail/scipy-dev/2015-April/020636.html [3] https://github.com/scipy/scipy/pull/2908 [4] http://producingoss.com/

4 13

ANN: SfePy 2016.3
by Robert Cimrman Sept. 30, 2016

Sept. 30, 2016

I am pleased to announce release 2016.3 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: http://groups.google.com/group/sfepy-devel Git (source) repository, issue tracker: http://github.com/sfepy/sfepy Highlights of this release -------------------------- - Python 3 support - testing with Travis CI - new classes for homogenized coefficients - using argparse instead of optparse For full release notes see http://docs.sfepy.org/doc/release_notes.html#id1 (rather long and technical). Cheers, Robert Cimrman --- Contributors to this release in alphabetical order: Robert Cimrman Jan Heczko Thomas Kluyver Vladimir Lukes

1 0

scipy 0.18.1 release
by Evgeni Burovski Sept. 29, 2016

Sept. 29, 2016

Hi, It seems to me that we have enough material for a bugfix release 0.18.1. Here's the milestone contents: https://github.com/scipy/scipy/milestone/31 At the moment, remaining issues without a fix are: * A regression in stats.circmean, https://github.com/scipy/scipy/issues/6420; there is a PR which needs finishing https://github.com/scipy/scipy/pull/6424. The PR just needs a test. * A regression in stats.ks_2samp, https://github.com/scipy/scipy/issues/6435. >From the discussion in the issue, it seems that https://github.com/scipy/scipy/pull/5938 changed behavior more than expected, and figuring out the "correct" thing to do needs more effort that anyone can spend in the short term. So the suggestion is to undo gh-5938 for 0.18.1. If someone thinks something else needs to be included please speak up, here in this thread or comment on a relevant GH issue. I think we should aim to release 0.18.1 by the end of September. Thoughts? Cheers, Evgeni

3 4

Probabilistic Data Structures
by Robert Lucente - Pipeline Sept. 26, 2016

Sept. 26, 2016

>Data structures that are mostly applicable for big data or streaming applications >are outside the scope of SciPy, so I don't think we'd consider adding them. Thanks for keeping scipy focused.

1 0

Feature enhancement
by Parul Sethi Sept. 26, 2016

Sept. 26, 2016

Hi, Can I work on Normal inverse gamma distribution’s addition to Scipy (Issue #6528), if no one has taken that up yet. And as I’m a bit new to Open source, so please brief, if any, implementation details to make the PR suitable for scipy. Thanks. -- Parul Sethi (student) B.Tech (IT & Mathematical innovation) Cluster Innovation Centre Delhi University

2 3

removing scipy.weave
by Ralf Gommers Sept. 26, 2016

Sept. 26, 2016

Hi all, scipy.weave has been deprecated since 0.15.0. It has been available as a standalone package (https://github.com/scipy/weave) for 2.5 years now. So I think it's time to remove it for the next release. PR https://github.com/scipy/scipy/pull/6593 does that. If you think there's a reason to leave it in for a little bit longer, please comment. Cheers, Ralf

3 3

Welcome Josh Wilson to the core team
by Evgeni Burovski Sept. 26, 2016

Sept. 26, 2016

Hi, On behalf of the Scipy developers I'd like to welcome Josh Wilson as a member of the core dev team. He contributes since last October, to several subpackages including scipy.special, scipy.optimize and linalg. He authored the cython_special interface, and made multiple nice improvements in scipy.special and other subpackages. I'm looking forward for his continued contributions! Evgeni

3 2

Probabilistic Data Structures
by Robert Lucente - Pipeline Sept. 26, 2016

Sept. 26, 2016

I am a newbie and not an expert. I ran across the concept of probabilistic data structures. I was wondering if SciPy would consider adding them? Bloom filters seem to fall into this category. Paco Nathan seems to have a really good video at https://www.oreilly.com/learning/probabilistic-data-structures-in-python-new The full version is online available via paid Safari but you can get a free 10 day trial https://www.safaribooksonline.com/oriole/probabilistic-data-structures-in-py thon

2 1

IDR(s) iterative method
by Pauli Virtanen Sept. 19, 2016

Sept. 19, 2016

Hi, There's a suggestion to add IDR(s) iterative method to Scipy here: https://github.com/scipy/scipy/issues/6596 I would be positive for this, I don't think there problems in adding some more iterative methods, even if they're not "classical", as once (correctly) implemented there's no tuning to do. -- Pauli Virtanen

1 0

cKDTree
by Robert Lucente Sept. 14, 2016

Sept. 14, 2016

Please note that I am a newbie and just a lurker. I noticed in a recent email that cKDTree was mentioned. Q: What is the relationship if any between SciPy an scikit-learn when it comes to cKDTree? The reason that I ask are the following 2 links https://jakevdp.github.io/blog/2013/04/29/benchmarking-nearest-neighbor-sea… https://github.com/scikit-learn/scikit-learn/issues/3682

8 22

Build/install scipy in a conda environment.
by Andrew Nelson Sept. 13, 2016

Sept. 13, 2016

Hi all, given the discussion about scipy installation happening on github I realised I have a question relating to build and install from source (OS X 10.9.5, clang-600.0.5, gfortran 4.9.0) I'm working in a Python 3 conda environment. The mkl version of numpy is installed via conda. When I try to build scipy from source it fails on a linker step against the mkl libraries because I don't have them. Is there a definitive guide on how to compile scipy in this fashion? (i.e. which Intel download I need, any config changes required, etc). A -- _____________________________________ Dr. Andrew Nelson _____________________________________

2 1

scipy.io.wavfile to read byte array directly?
by Miles Sept. 11, 2016

Sept. 11, 2016

Joseph, Ralf, Thank you both for your responses! I'm still very much new and unfamiliar with Python and it's libraries, so I appreciate your quick and courteous replies. The BytesIO library was exactly what I needed. I was able to load the WAV byte array data into scipy using that as a wrapper. If it's of any interest, my code roughly looked like this: ``` import boto3 import scipy.io.wavfile as sciwav from io import BytesIO s3 = boto3.resource('s3') #access bucket, get WAV data (i.e., b'RIFF\x86x.\x01WAVEfmt ...') object = s3.Object(bucket_name, key) result = object.get()['Body'].read() # wrap data and submit wrapper = BytesIO(result) wav_file = sciwav.read(wrapper) ``` I will also go back and review the documentation regarding using file-like objects and can add those details. Thank you again, Miles

1 0

scipy.io.wavfile to read byte array directly?
by Miles Dowe Sept. 10, 2016

Sept. 10, 2016

Hi all, I was interested in the creation of a function for the scipy.io.wavfile utility. Rather than requiring that read() only be performed on a file, I'd like to add a read() function where a byte array of WAV data can be provided directly. Here's some background behind this motivation. I am a student with the University of Washington and I have been working with a former student's machine learning algorithm. The aim of the algorithm is to detect human laughter and it utilizes SciPy and NumPy. We're aiming to create a service-oriented architecture maintained in AWS and our audio data is stored within S3. I've been experimenting with the Boto3 library, which returns a byte array, and I'd like to provide that data directly to the machine learning script (instead of writing to the disk and reading from it). I'd like to hear your thoughts and might experiment with this idea until approval is expressed by the community. Thank you for your time, Miles -- Miles

3 2

New simulated annealing implementation (PR 6197)
by Ralf Gommers Sept. 10, 2016

Sept. 10, 2016

<edited subject> On Fri, Sep 9, 2016 at 12:24 AM, Gubian, Sylvain <Sylvain.Gubian(a)pmi.com> wrote: > Dear All, > > Following the discussion regarding DE and simulating annealing, I have > made a PR for proposing a new implementation for simulating annealing (that > is a generalized one). > https://github.com/scipy/scipy/pull/6197 (already kindly commented by > Ralf and Andrew). > The homemade (parallelized) benchmarks are showing very good results > especially in terms of successful rate. > Since, Andrew has fixed the benchmark code for python3. In order to > consider this enhancement proposal, what do you guys recommend me to do. > The idea is to benchmark it with the new fixed benchmark (using the PR > branch for having this new optimizer). I presented a poster in EuroSciPy in > Erlangen describing the performance of this approach and had a nice talk > with Olivier Grisel about it. > Any thoughts to move this forward? > > Thanks a lot in advance. > Hi Sylvain, thanks for reminding us of your PR. Now that the issue with the benchmarks is fixed, I'd say you can indeed just add your gensa to the existing benchmarks I'd say. Then if those look good as well (I'd expect so, given the amount of work you put in your own benchmark) then let's try to get your PR merged. If you have your poster somewhere public, it would be nice to link it from the PR. I'd be interested to have a look at it. Cheers, Ralf

1 0

Re: [SciPy-Dev] SciPy-Dev Digest, Vol 155, Issue 12
by Gubian, Sylvain Sept. 8, 2016

Sept. 8, 2016

Dear All, Following the discussion regarding DE and simulating annealing, I have made a PR for proposing a new implementation for simulating annealing (that is a generalized one). https://github.com/scipy/scipy/pull/6197 (already kindly commented by Ralf and Andrew). The homemade (parallelized) benchmarks are showing very good results especially in terms of successful rate. Since, Andrew has fixed the benchmark code for python3. In order to consider this enhancement proposal, what do you guys recommend me to do. The idea is to benchmark it with the new fixed benchmark (using the PR branch for having this new optimizer). I presented a poster in EuroSciPy in Erlangen describing the performance of this approach and had a nice talk with Olivier Grisel about it. Any thoughts to move this forward? Thanks a lot in advance. Sylvain. -----Original Message----- From: SciPy-Dev [mailto:scipy-dev-bounces@scipy.org] On Behalf Of scipy-dev-request(a)scipy.org Sent: jeudi 8 septembre 2016 10:19 To: scipy-dev(a)scipy.org Subject: SciPy-Dev Digest, Vol 155, Issue 12 Send SciPy-Dev mailing list submissions to scipy-dev(a)scipy.org To subscribe or unsubscribe via the World Wide Web, visit https://mail.scipy.org/mailman/listinfo/scipy-dev or, via email, send a message with subject or body 'help' to scipy-dev-request(a)scipy.org You can reach the person managing the list at scipy-dev-owner(a)scipy.org When replying, please edit your Subject line so it is more specific than "Re: Contents of SciPy-Dev digest..." Today's Topics: 1. Re: misc.bytescale bug (Greg Dooper) 2. Re: cKDTree (Ralf Gommers) 3. Re: cKDTree (Ralf Gommers) ---------------------------------------------------------------------- Message: 1 Date: Wed, 7 Sep 2016 23:37:46 -0600 From: Greg Dooper <greg.dooper(a)gmail.com> To: SciPy Developers List <scipy-dev(a)scipy.org> Subject: Re: [SciPy-Dev] misc.bytescale bug Message-ID: <CAKYMPC8XqK1kACAj9fPDNEmMhypVj4aMGcpLyRau7uLK1YVsqQ(a)mail.gmail.com> Content-Type: text/plain; charset="utf-8" I have a pull request up for this bug ( https://github.com/scipy/scipy/pull/6554). I should probably squash some of the commits together, but I'd rather wait on feedback first. -Greg On Tue, Sep 6, 2016 at 11:10 PM, Warren Weckesser < warren.weckesser(a)gmail.com> wrote: > > > On Wed, Sep 7, 2016 at 12:56 AM, Greg Dooper <greg.dooper(a)gmail.com> > wrote: > >> Hello, >> It seems like there is a bug in misc.bytescale. Or I am not >> understanding what the intended behavior should be. What I think is a >> bug shows up when you try to bytescale an array with both cmin/cmax >> parameters and low/high parameters. >> >> I think it's a pretty simple fix that I would like to tackle. >> >> What is the next step for me? Creating an issue on github with some >> example code and data? >> > > Yes, that would be great. Be sure to include an example that > demonstrates the problem. > > Warren > > > >> Thanks for the input. >> >> -Greg Dooper >> >> _______________________________________________ >> SciPy-Dev mailing list >> SciPy-Dev(a)scipy.org >> https://mail.scipy.org/mailman/listinfo/scipy-dev >> >> > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev(a)scipy.org > https://mail.scipy.org/mailman/listinfo/scipy-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://mail.scipy.org/pipermail/scipy-dev/attachments/20160907/2a3ad533/at…> ------------------------------ Message: 2 Date: Thu, 8 Sep 2016 20:11:51 +1200 From: Ralf Gommers <ralf.gommers(a)gmail.com> To: SciPy Developers List <scipy-dev(a)scipy.org> Subject: Re: [SciPy-Dev] cKDTree Message-ID: <CABL7CQi1ZZh4JKxTHb+4ztRa-t71eYhwCT0ZmqFE9kXXbhWuQQ(a)mail.gmail.com> Content-Type: text/plain; charset="utf-8" On Wed, Sep 7, 2016 at 11:19 AM, Pauli Virtanen <pav(a)iki.fi> wrote: > Tue, 06 Sep 2016 20:23:05 +0200, Sylvain Corlay kirjoitti: > [clip] > > This sort of raises the question of the scope of scipy. Should scipy > > go through the same sort of "big split" as Jupyter or more ? la > > d3js? Is amount of specialized knowledge required to understand a > > methods part of what defines the line of division in what should be or not be in scipy? > > To write a bit more on this, although I think it's difficult to give > hard rules on what "generally useful and generally agreed to work" > means, I would perhaps weigh the following against each other: > > - Is the method used/useful in different domains in practice? > How much domain-specific background knowledge is needed to use it > properly? > > - Consider the stuff already in the module. Is what you are adding > an omission? Does it solve a problem that you'd expect the module > be able to solve? Does it supplement an existing feature in > a significant way? > > - Consider the equivalence class of similar methods / features usually > expected. Among them, what would in principle be the minimal set so > that there's not a glaring omission in the offered features remaining? > How much stuff would that be? Does including a representative one of > them cover most use cases? Would it in principle sound reasonable to > include everything from the minimal set in the module? > > - Is what you are adding something that is well understood in the > literature? If not, how sure are you that it will turn out well? > Does the method perform well compared to other similar ones? > > - Note that the twice-a-year release cycle and backward-compat > policy makes correcting things later on more difficult. > > The scopes of the submodules also vary, so it's probably best to > consider each as if a separate project --- "numerical evaluation of > special functions" is relatively well-defined, but "commonly needed > optimization algorithms" less so. > > On a meta-level, it's probably also bad to be too restrictive on the > scope, as telling people to go away can result to just that. > Thanks Pauli, this and your other mail are the best summary yet of how to judge suitability for inclusion. I propose to stick this almost verbatim in the developer docs. Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://mail.scipy.org/pipermail/scipy-dev/attachments/20160908/7d53013f/at…> ------------------------------ Message: 3 Date: Thu, 8 Sep 2016 20:18:56 +1200 From: Ralf Gommers <ralf.gommers(a)gmail.com> To: SciPy Developers List <scipy-dev(a)scipy.org> Subject: Re: [SciPy-Dev] cKDTree Message-ID: <CABL7CQhhT6VYaWSq4r1fKtMq3TMBksSnN4PM+Xotejycja+qDQ(a)mail.gmail.com> Content-Type: text/plain; charset="utf-8" On Wed, Sep 7, 2016 at 6:23 AM, Sylvain Corlay <sylvain.corlay(a)gmail.com> wrote: > I understand (especially about the scikits), although I was surprised > by some recently added features in scipy, such as differential > evolution > > DE is more of a "recipe" which has been studied empirically for which > there is no theoretical convergence rate. Even though it may "work well" > for certain problems, it causes some issues such as defining on which > basis it should even be "improved", and what should be the foundation > for a change. (Recently a result on convergence in probability (with > no error > rate) on a bounded domain has been published, but no result exists on > the speed of convergence afaik...) > > Evolutionary optimization is definitely cool and may work strikingly > well for certain problems, but I was surprised that it got elected to > inclusion in scipy. DE would have been a nice seed for a scikit-evolution. > > For those interested in stochastic algorithms for global multivariate > optimization for which we have proven convergence results and an > abundant literature, we have at least the two following categories of > methods > > - *MCMC* (Markov Chain Monte Carlo) which comprises simulated > annealing, for which there are nice results of convergence in distribution. > - *Robbins-Monro* methods, which comprise stochastic gradient > methods, for which we have almost-sure convergence and central-limit - type theorems. > I think it's fair to summarize the reason for the current status and inclusion of DE as: theoretical convergence rates and papers are nice, but code that actually works on a good set of benchmarks is way more important. Some years ago we had only bad global optimizers. We did have simulated annealing, but it just didn't work for most problems. No one stepped up to improve it, so we deprecated and removed it. DE was benchmarked quite thoroughly (on the benchmark functions from benchmarks/benchmarks/test_go_benchmark_functions.py) and came out looking good. It solved problems that the only other good optimizer we had (basinhopping) did not do well on. So that means there was value in adding it. Cheers, Ralf > This sort of raises the question of the scope of scipy. Should scipy > go through the same sort of "big split" as Jupyter or more ? la d3js? > Is amount of specialized knowledge required to understand a methods > part of what defines the line of division in what should be or not be in scipy? > > Sylvain > > On Tue, Sep 6, 2016 at 8:08 PM, Jacob Vanderplas < > jakevdp(a)cs.washington.edu> wrote: > >> As for adding more functionality along those lines, I would advocate >> creation of a new package or perhaps a scikit. As we've seen with >> scikit-learn, useful features can filter-up into scipy (e.g. >> sparse.csgraph) and the development of new features within an >> independent package is *much* easier than development from within a scipy PR. >> Jake >> >> Jake VanderPlas >> Senior Data Science Fellow >> Director of Research in Physical Sciences University of Washington >> eScience Institute >> >> On Tue, Sep 6, 2016 at 11:03 AM, Sylvain Corlay >> <sylvain.corlay(a)gmail.com >> > wrote: >> >>> Would you guys consider in scope for scipy to have implementation of >>> faster nearest neighbor search methods than KdTree? >>> >>> Some methods are fairly simple... e.g principal axis tree which use >>> the principal direction of the dataset to split the dataset into >>> smaller subsets. As soon as intrinsic dimensionality is >>> significantly smaller than the dimension of the space, it is significantly faster. >>> >>> Besides, only having to compute the (an approximate) principal axis >>> is much faster than doing an actual PCA. >>> >>> On Tue, Sep 6, 2016 at 4:14 AM, Jacob Vanderplas < >>> jakevdp(a)cs.washington.edu> wrote: >>> >>>> From my own casual benchmarks, the new scipy cKDTree is much faster >>>> than any of the scikit-learn options, though it still only supports >>>> axis-aligned euclidean-like metrics (where sklearn's BallTree >>>> supports dozens of additional metrics). The cKDTree also has a >>>> limited range of query types compared to scikit-learn's trees, >>>> Jake >>>> >>>> Jake VanderPlas >>>> Senior Data Science Fellow >>>> Director of Research in Physical Sciences University of >>>> Washington eScience Institute >>>> >>>> On Mon, Sep 5, 2016 at 12:46 AM, Da?id <davidmenhur(a)gmail.com> wrote: >>>> >>>>> On 4 September 2016 at 23:00, Robert Lucente >>>>> <rlucente(a)pipeline.com> >>>>> wrote: >>>>> > Please note that I am a newbie and just a lurker. >>>>> > >>>>> > I noticed in a recent email that cKDTree was mentioned. >>>>> > >>>>> > Q: What is the relationship if any between SciPy an scikit-learn >>>>> when it comes to cKDTree? >>>>> > >>>>> > The reason that I ask are the following 2 links >>>>> > >>>>> > https://jakevdp.github.io/blog/2013/04/29/benchmarking-neare >>>>> st-neighbor-searches-in-python/ >>>>> > >>>>> > https://github.com/scikit-learn/scikit-learn/issues/3682 >>>>> >>>>> Note that these benchmarks are from 2013 and 2014. Scipy's KDTree >>>>> has seen its performance recently improved, twice. Scikit's last >>>>> update to its KDTree was in 2015. So, we need to run the benchmarks again. >>>>> >>>>> /David. >>>>> _______________________________________________ >>>>> SciPy-Dev mailing list >>>>> SciPy-Dev(a)scipy.org >>>>> https://mail.scipy.org/mailman/listinfo/scipy-dev >>>>> >>>> >>>> >>>> _______________________________________________ >>>> SciPy-Dev mailing list >>>> SciPy-Dev(a)scipy.org >>>> https://mail.scipy.org/mailman/listinfo/scipy-dev >>>> >>>> >>> >>> _______________________________________________ >>> SciPy-Dev mailing list >>> SciPy-Dev(a)scipy.org >>> https://mail.scipy.org/mailman/listinfo/scipy-dev >>> >>> >> >> _______________________________________________ >> SciPy-Dev mailing list >> SciPy-Dev(a)scipy.org >> https://mail.scipy.org/mailman/listinfo/scipy-dev >> >> > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev(a)scipy.org > https://mail.scipy.org/mailman/listinfo/scipy-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://mail.scipy.org/pipermail/scipy-dev/attachments/20160908/597b9be4/at…> ------------------------------ Subject: Digest Footer _______________________________________________ SciPy-Dev mailing list SciPy-Dev(a)scipy.org https://mail.scipy.org/mailman/listinfo/scipy-dev ------------------------------ End of SciPy-Dev Digest, Vol 155, Issue 12 ******************************************

1 0

misc.bytescale bug
by Greg Dooper Sept. 8, 2016

Sept. 8, 2016

Hello, It seems like there is a bug in misc.bytescale. Or I am not understanding what the intended behavior should be. What I think is a bug shows up when you try to bytescale an array with both cmin/cmax parameters and low/high parameters. I think it's a pretty simple fix that I would like to tackle. What is the next step for me? Creating an issue on github with some example code and data? Thanks for the input. -Greg Dooper

2 2

Fwd: PyData Community Cookbook - August Update
by Ralf Gommers Sept. 6, 2016

Sept. 6, 2016

Hi all, Is anyone interested to write or contribute to a chapter about SciPy for a PyData Community Cookbook? We're a bit late (but so are most people), so ideally we get this organized within a day or two. It can be a single-author or multi-author effort. The projects that submitted an abstract so far all seem to do 2 or 3 authors: https://github.com/pydata/pydata-cookbook. I'm happy to contribute, or if there's a lot of interest leave it to others. Would like to see it happen though - SciPy should really not be missing in this book. Cheers, Ralf ---------- Forwarded message ---------- From: Andy Ray Terrel <andy(a)numfocus.org> Date: Sun, Aug 21, 2016 at 12:14 AM Subject: PyData Community Cookbook - August Update To: Cc: pydata-cookbook(a)numfocus.org Hello everyone, You are receiving this email because you were either invited and committed to join our project. Please feel free to forward this message to a more appropriate list or person. For questions please email pydata-cookbook(a)numfocus.org. Katy Huff and myself are starting a project to build a cookbook of advanced material for the PyData community. The cookbook will be published by Addison-Wesley. We have invited a number of contributors to see if such a project would have some interest and received overwhelmingly positive feedback. The book will cover several major topics, organized as such, with some sample packages: - IDE: IPython/Jupyter - Data Structures / Numerics: NumPy, Pandas, Xray, PyTables - Viz: Matplotlib, Bokeh, Seaborn, yt - Algorithms / Science: SciPy, Scikit-learn, Scikit-image, statsmodels, sympy, gensim - Performance / Scale: Cython, Numexpr, Numba, Dask, pyspark We expect each submission to be about 15 - 20 pages describing an example of the power of each library. While we have reached out to the projects about putting each submission together we are happy to accept chapters for libraries we did not initially identify. To facilitate the book we have put together a repository for collecting and reviewing submissions at https://github.com/pydata/pydata-cookbook . We are asking for submissions in rst but would appreciate any other files, such as jupyter notebooks or code, for a digital appendix as well. If you read this far and are interested in contributing. The proposed schedule is the following: Sept 1: Submit a pull request with a title, abstract and author list for the submission. Nov 15: Submit a completed chapter. Dec 31: Reviews for chapters finished. Jan 31: All chapter revisions due. Thanks for you time! -- Andy R. Terrel, PhD President, NumFOCUS andy(a)numfocus.org

5 9

Timing of SciPy 1.0
by Ralf Gommers Sept. 5, 2016

Sept. 5, 2016

Hi all, Starting with the summary of my email of earlier today: I'd like to pick a time for when we release SciPy 1.0, and what is still essential to do for that version number. We've discussed this a couple of times before [1,2]. We're now at the point where most of the major gaps have been filled though, so it looks to me like it's time to just pick a date for it (either after or instead of 0.19.0) and then fix up the last things that we think we really need for a 1.0 release. Here are the things that I see as essential: - Getting project organization in order: governance and CoC at least (see my other email of today). - scipy.signal: clean up the messes in wavelets and B-splines. - scipy.signal: unified filter API [3] - scipy.spatial: remove Python implementation of KDTree, just keep cKDTree - scipy.interpolate: not sure of the details, but I think there are some new interpolator classes and a spline PR that aren't quite finished? - Remove some deprecated items (weave is the biggest one), and decide now if there's anything else we need to deprecate. - Merge or close more PRs. We've stabilized them at around 120-130 open ones, but that's not really good enough if there are (almost) finished PRs that no one has looked at in a year. This may be the single biggest task. We shouldn't make the above list too long, otherwise we won't get there. Really, SciPy is production quality software (with a few dusty corners), so we should limit ourselves to listing what is essential here. Timing: I suspect that we want to deprecate some more things, and that 4 months is a little too short to get to the point where we want to be. So I would propose to still do a 0.19.0, make sure that all deprecations are in there, merge PRs quite aggressively for 0.19.0 as well, and then plan 1.0 as the next release (can be shorter than 6 months after 0.19.0). So maybe Nov/Dec for 0.19.0 and say March '17 for 1.0. Thoughts? Ralf [1] https://github.com/scipy/scipy/pull/2908 [2] https://mail.scipy.org/pipermail/scipy-dev/2013-September/019238.html [3] https://github.com/scipy/scipy/issues/6137

3 3