Mailman 3 January 2019 - SciPy-Dev

SciPy 1.2.0 release schedule
by Tyler Reddy 07 Feb '19

07 Feb '19

Hi all, It is almost 6 months after the 1.1.0 release on May 5, so probably time to plan the 1.2.0 release. It would be a good idea to look over the PRs with a 1.2.0 milestone <https://github.com/scipy/scipy/pulls?q=is%3Aopen+is%3Apr+milestone%3A1.2.0>, and tag anything else that should have this milestone appropriately. I'd like to propose the following schedule: Nov. 5: branch 1.2.x Nov. 8: rc1 Nov. 21: rc2 (if needed) Nov. 30: final release Thoughts? Best wishes, Tyler

5 25

SciPy GSoC'15 participation?
by Ralf Gommers 07 Feb '19

07 Feb '19

Hi all, It's the time of the year where GSoC kicks off again. Below email from Terri, the lead PSF organizer, explains some of the deadlines and things that are different from last year. So: do we want to participate again this year? We already have one serious proposal from a student in preparation, about scipy.fftpack (see earlier thread on this list). If we do want to participate, do we have volunteers for mentors and a sub-org admin? I've done the latter for the last years, but this year I really do not have the time (if you're interested: it doesn't take much time compared to mentoring). Cheers, Ralf ---------- Forwarded message --------- From: Terri Oda <terri(a)toybox.ca> Date: Tue, Jan 1, 2019 at 11:02 PM Subject: [GSoC-mentors] Python in GSoC 2019! To: <gsoc-mentors(a)python.org> Happy new year, everyone! As you may have seen, we're starting to prepare Python's application for GSoC 2019, and we need your ideas. We've got a few eager students already asking what you'd like them to work on. The website has been updated for 2019: http://python-gsoc.org New and notable: - GSoC org applications open early this year, starting January 15th! Google moves the dates around every year so students in different countries with different schedules get opportunities to participate more easily when the times line up with their scholastic year, and this is one of the early years. - We're asking for sub-orgs to get as many ideas ready as they can by Feb 4th so that we have lots of ideas ready for when Google judges our umbrella org ideas page. We need well-formed ideas if we want to get accepted, and now's a great time to catch the eye of the most eager students! Once you've got some ideas ready, you can make a pull request to get yourself added to the page here: https://github.com/python-gsoc/python-gsoc.github.io - John has set up a Slack channel for Python GSoC. It's bridged in to link to the IRC channel, but may be a more familiar interface/mobile app for people who aren't regular IRC users. I know, it's not open source, but we didn't have much luck with Zulip and while Matrix has been good it's not quite solving the usability problem we have with the students, so we're trying out the more popular Slack. We'll see how it works this year and if it's worth keeping, so if this is a thing you want us to support, please use it! (And if you see problems, please report them to gsoc-admins(a)python.org so we can get them fixed.) You can snag a Slack invite here: https://join.slack.com/t/python-gsoc/shared_invite/enQtNDg0NDgwNjMyNTE2LTNl… - We've got space for some new sub-orgs this year! If you know of any projects that might want to try out GSoC with us this year, let us know, or tell them to email gsoc-admins(a)python.org (or join irc/matrix/slack, or whatever) to chat with us! Terri _______________________________________________ GSoC-mentors mailing list GSoC-mentors(a)python.org https://mail.python.org/mailman/listinfo/gsoc-mentors

3 4

curve_fit() should require initial values for parameters
by Matt Newville 04 Feb '19

04 Feb '19

Hi All, First, I apologize in advance if this sounds un-appreciative of the efforts made in scipy and scipy.optimize. I am a very big fan, and very appreciative of the work done here. With lmfit we have tried to take the "rough edges" from optimization and curve-fitting with python, but we're very much in favor of building wrappers on top of the core of scipy.optimize. Still, many people use `curve_fit` because it comes built-in with scipy, is well advertised, and is well-suited for simple uses. It is clearly aimed at novices and tries to hide many of the complexities of using optimization routines for curve fitting. I try to help people with questions about using `curve_fit` and `scipy.optimize` as well as `lmfit`. In trying to help people using `curve_fit`, I've noticed a disturbing trend. When a novice or even experienced user asks for help using `curve_fit` because a fit "doesn't work" there is a very good chance that they did not specify `p0` for the initial values and that the default behavior of setting all starting values to 1.0 will cause their fit to fail to converge, or really to even start. This failure is understandable to an experienced user, but apparently not to the novice. Curve-fitting problems are by nature local solvers and are always sensitive to initial values. For some problems, parameter values of 1.0 are simply inappropriate, and the numerical derivatives for some parameters near values of 1.0 will be 0. Indeed, there is no value that is always a reasonable starting value for all parameters. FWIW, in lmfit, we simply refuse to let a user run a curve-fitting problem without initial values. I believe that most other curve-fitting interfaces also require initial values for all parameters. Unfortunately, faced with no initial parameter values, `curve_fit` silently chooses initial values. It doesn't try to make an informed decision, it simply chooses '1.0', which can easily be so far off as to prevent a solution from being found. When this happens, `curve_fit` gives no information to the user of what the problem is. Indeed it allows initial values to not be set, giving the impression that they are not important. This impression is wrong: initial values are always important. `curve_fit` is mistaken in having a default starting value. I've made a Pull Request at https://github.com/scipy/scipy/pull/9701 to fix this misbehavior, so that `curve_fit()` requires starting values. It was suggested there that this topic should be discussed here. I'm happy to do so. It was suggested in the github Issue that forcing the user to give initial values was "annoying". It was also suggested that a deprecation cycle would be required. I should say that I don't actually use `curve_fit()` myself, I'm just trying to help make this commonly used routine be completely wrong less often. Cheers, --Matt Newville

13 35

Discussion on backend system for scipy.fftpack
by Sourav Singh 04 Feb '19

04 Feb '19

Hello, I am writing the mail to start a discussion on the backend system for scipy.fftpack. I am currently looking into ways of implementing a backend system and have found that the Keras library's method for backend to be elegant. The Keras library maintains separate modules for each backend, which has their own classes and functions for operations and session creation. The default backend can be set up through a configuration or a flag of some kind. So far we have numpy.fft, scipy.fftpack, pyFFTW and cupy(I am not sure about having this) for FFT ops. I would like to discuss further about the decisions on the kind of backend system that would be required so I can design a document containing class diagrams and such. Thanks for taking the time to read my email and have a great day! Regards, Sourav

2 1

Build failures (PR 9523)
by Blair Azzopardi 31 Jan '19

31 Jan '19

Hi all I recently refreshed my PR with latest master and have some build failures that I'm not sure how to handle. One appears to be an issue with a new azure pipeline check. This produces some cryptic messages including powershell failure codes. https://github.com/scipy/scipy/pull/9523/checks?check_run_id=56360311 Another is a typical spurious error in Travis, where it fails to download a python 3.5 tar ball. I tested the link and the tarball exists so might have been caused by an intermittent network issue. https://travis-ci.org/scipy/scipy/jobs/486160253 Any suggestions? It would be useful if a PR owner was able to re-trigger the travis build somehow. Perhaps not possible. Kind regards Blair

2 1

Better __repr__ for scipy.stats distributions
by Andrew Nelson 30 Jan '19

30 Jan '19

I'm using various rv_continuous distributions as priors for a Bayesian analysis package I'm writing. Part of the GUI functionality is to produce code fragments from the GUI state to encourage scientific reproducibility. i.e. set up the analysis objects in a GUI, then output code that could be run from a script. I'm making a lot of use of __repr__ to produce text that can be used to build the objects. However, I'm stalled at recreating the scipy.stats distributions, and would like to propose that the __repr__ of these classes be improved to a point where the repr can be used to reproduce the distribution. e.g instead of: >>> from scipy.stats import norm >>> print(repr(norm(0, 1))) <scipy.stats._distn_infrastructure.rv_frozen object at 0x1a17c8f898> one would get: norm(0, 1) This would require that all the initialisation variables be accessible from the object (which I think was discussed recently if I remember rightly). Would others find this useful? Andrew. -- _____________________________________ Dr. Andrew Nelson _____________________________________

2 1

SciPy 1.0 paper writing proposal
by Ralf Gommers 30 Jan '19

30 Jan '19

Hi all, TL;DR, let's write the long journal paper on SciPy that we've wanted for a while, let's form a small committee to coordinate, and get it out the door in 2-3 months. Motivation --------------- (credits for most of this text: Evgeni) Many scipy contributors' day jobs are in academia. Bibliometry -- papers in refereed journals and citations of papers by other papers -- is one of the main performance indicators in most academic establishments. Since we do not generate papers, scipy contributions are all but invisible for the purposes of a contributor's annual report. Of course, details vary wildly; in many cases a contributor manages to balance their time, or to argue common sense with their superiors, or get an approval for scipy work, or just ignores the issue altogether -- but sooner or later there is a form to be filled or boxes to be checked, and scipy contributions simply do not fit in. A peer-reviewed journal paper on scipy will help contributors get the academic credit they deserve. We can write *the* paper for SciPy 1.0, with overall project structure, goals, etc., and for specific features/modules a focus on say the last 3 years. History ---------- For SciPy 1.0 we had three targets on the publicity/credits front: an interesting release announcement, interesting blogs/stories (NumFOCUS blog, Hacker News, etc.) and a paper. We didn't have the bandwidth for a paper in the end, the rest was successful. [1] is a previous announcement on this list about writing (a) paper(s) on SciPy. We wanted both "short papers" to cover one or two releases (target journal JOSS) and a full paper as the authoritative reference for SciPy. We had an earlier attempt for a "short paper", it's mostly written but has stalled (see [2]). We ran out of steam on that one. To avoid that this time around, it would be good to have a clear public plan, target dates, and a small committee rather than one person to drive things forward. Proposal ------------ Here's a proposal for all aspects of this exercise that I can think about now. Some parts stolen from the AstroPy paper [3] (because their process worked quite well). Form a small coordination committee of 3-5 people that set up the paper structure, move things along when parts stall, propose/take decisions as needed, invite co-authors, and organise paper submission/rework. Paper writing to be done by whoever volunteers for a section, not just the coordination committee. First outline/structure to be done by committee, which then asks for review of structure and volunteers for section writing. Scope: a 6-10 page paper, covering history, package scope and structure, community/organisational aspects, key features and recent enhancements per module, and roadmap. Authorship: anyone who made a substantial contribution in the history of the project. Here "substantial" is interpreted as anything beyond a one-line doc fix. Rationale: better to be too inclusive than exclusive. Sign-up via a web form, we send the link to that form to all email addresses in the commit history till v1.0. Author order (details tbd by committee): 1. The SciPy Developers 2. Maintainers, paper writers, other key contributors - in order of contribution level 3. All other authors - alphabetically ordered Submission target: mid-April, to either PeerJ Computer Science or Journal of Open Research Software (tbd by committee). Comments? Volunteers for committee? References ---------------- [1] https://mail.python.org/pipermail/scipy-dev/2016-August/021474.html [2] https://github.com/scipy/scipy-articles/pull/4 [3] https://github.com/astropy/astropy-v2.0-paper Cheers, Ralf

12 19

ANN: SMIL - Small Morphological Image Library
by Jose-Marcio Martins da Cruz 30 Jan '19

30 Jan '19

Hi all, I'm the maintainer of SMIL and I'd like to, eventually integrate SMIL into SciPy or Scikit-image. Announcement: SMIL 0.9.1 ======================== I'm pleased to announce SMIL - Simple Morphological Image Library - v. 0.9.1 SMIL is a library with all basic and some advanced mathematical morphology features which can be extended with plugins and user modules. Among its features it can handle 2D and 3D images and can handle data from/to NumPy data. It's been developed in C++ and has a Python interface thanks to Swig. SMIL is a product of CMM, the research Center of Mathematical Morphology of Mines-Paristech, where the discipline of Mathematical Morphology was created in the 60's by Jean Serra and Georges Matheron. SMIL is distributed with GPL license. We use SMIL in our research and teaching activities in the field. You can find SMIL - binaries and documentation - at our web site : http://smil.cmm.mines-paristech.fr or the source code at : https://github.com/ensmp-cmm/smil Thanks Jose-Marcio -- --------------------------------------------------------------- Jose Marcio MARTINS DA CRUZ, Ph.D. Ecole des Mines de Paris CMM - Centre de Morphologie Mathématique --------------------------------------------------------------- Spam : http://amzn.to/LEscRu ou http://bit.ly/SpamJM ---------------------------------------------------------------

4 6

ppc64le linux in CI
by Tyler Reddy 24 Jan '19

24 Jan '19

In a recent PR ( https://github.com/scipy/scipy/pull/9684 ) it was suggested to bring this discussion to the mailing list. In short, do we want to have ppc64le linux testing in our CI? This would follow suit from NumPy, since IBM has made the nodes available on Travis, but could have drawbacks too re: CI times and maintenance burden. Thoughts? Tyler

1 0

ANN: scikit-image 0.14.2
by Stefan van der Walt 19 Jan '19

19 Jan '19

Announcement: scikit-image 0.14.2 ================================= This release handles an incompatibility between scikit-image and NumPy 1.16.0, released on January 13th 2019. It contains the following changes from 0.14.1: API changes ----------- - ``skimage.measure.regionprops`` no longer removes singleton dimensions from label images (#3284). To recover the old behavior, replace ``regionprops(label_image)`` calls with ``regionprops(np.squeeze(label_image))`` Bug fixes --------- - Address deprecation of NumPy ``_validate_lengths`` (backport of #3556) - Correctly handle the maximum number of lines in Hough transforms (backport of #3514) - Correctly implement early stopping criterion for rank kernel noise filter (backport of #3503) - Fix ``skimage.measure.regionprops`` for 1x1 inputs (backport of #3284) Enhancements ------------ - Rewrite of ``local_maxima`` with flood-fill (backport of #3022, #3447) Build Process & Testing ----------------------- - Dedicate a ``--pre`` build in appveyor (backport of #3222) - Avoid Travis-CI failure regarding ``skimage.lookfor`` (backport of #3477) - Stop using the ``pytest.fixtures`` decorator (#3558) - Filter out DeprecationPendingWarning for matrix subclass (#3637) - Fix matplotlib test warnings and circular import (#3632) Contributors & Reviewers ------------------------ - François Boulogne - Emmanuelle Gouillart - Lars Grüter - Mark Harfouche - Juan Nunez-Iglesias - Egor Panfilov - Stefan van der Walt

1 0