Mailman 3 May 2021 - SciPy-Dev

Re: [SciPy-Dev] Unpacking the mailing list: Discourse, Slack = Mailing list
by Pamphile Roy May 20, 2021

May 20, 2021

> On 20 May 2021, at 17:14, Tyler Reddy <tyler.je.reddy(a)gmail.com> wrote: > > Just keep the discourse stuff for onboarding/mentoring/informal stuff and mailing list for "votes"/substantive decisions IMO. What you describe is not suitable for Discourse but more Slack or Discord (which is working well IMO as the sprint showed). Discourse is more a forum with topics (like a mailing list) than a medium to have active discussions. Having Discourse and the mail list would for sure fragment the community. Cheers, Pamphile

5 5

Regarding contribution in Scipy organization for GSoC 21
by Amulya Gupta May 20, 2021

May 20, 2021

Dear Sir/Ma'am, I am Amulya Gupta, a sophomore from BITS,Pilani. I have been coding for the past 3 years. I am profound in Python(Modules: nose test, poetry, numpy, matplotlib, cmake, pipenv, tkinter, turtle and currently learning mypy etc), C++, Mysql, Java script. I have experience in open source with an internship with an organisation called NumFocus. I want to openly contribute to the project "*Add type annotations to a submodule*" from SciPy. Please can I talk to the mentor about his expectations from the student applying. How many more students have applied for the same project and how does the mentor has pre-planned about the project and his inputs for the proposal buildup. Regards Amulya Gupta

2 7

welcome Xingyu and Tirth as GSoC students!
by Ralf Gommers May 17, 2021

May 17, 2021

Hi all, Google just announced the accepted GSoC students for this year. Congratulations to Xingyu Liu and Tirth Patel! Xingyu's project is titled "Improve performance through the use of Pythran", her project summary can be found at https://summerofcode.withgoogle.com/projects/#5526713011798016. The mentors are Serge Guelton and myself. Tirth's project is titled "Integrate library UNU.RAN into scipy.stats", his project summary can be found at https://summerofcode.withgoogle.com/projects/#5912428874825728. The mentors are Christoph Baumgarten and Nicholas McKibben. Both projects are exciting, and I'm looking forward to Tirth and Xingyu's work and interaction with the community. >From today till June 7th is "community bonding period". Xingyu and Tirth have already been contributing for a little while, but please do give them a hand or say hi! That we had the first community meeting in a long time today and plan to have regular community calls going forward is also nice, should help with the bonding:) For the full GSoC timeline, please see https://summerofcode.withgoogle.com/how-it-works/#timeline. There are also a number of other students who worked hard on their proposals, and we had more students we wished we could have accepted if we had had more slots. Thanks to those students for all that hard work and creativity! I hope that you are still interested in contributing to SciPy. And for some of you, there is hopefully a chance to participate next year. Cheers, Ralf

9 10

Marginals/sensitivity analysis for linprog HiGHS
by Nicholas McKibben May 17, 2021

May 17, 2021

Hi all, gh-13893 <https://github.com/scipy/scipy/pull/13893>is under review and provides sensitivity analysis for the SciPy HiGHS LP solvers. For each of the three constraint types -- equality constraints, inequality constraints, and lower/upper bounds -- we want to convey three pieces of information: marginals (also commonly referred to as "Lagrange multipliers", "dual values", or "shadow prices"), ranging information (to be added in a future PR), as well as some measure of the distance between the solution and the constraints. Many LP solvers return this information but unfortunately there is little agreement in the field on how it should be labeled or presented. This comment <https://github.com/mckib2/scipy/pull/10#issuecomment-782120346> gives a brief overview of the different conventions other popular LP solvers follow. For SciPy, we have settled on organizing the OptimizeResult object in the following way according to the right-hand diagram in this file <https://www.dropbox.com/s/8j27rgdc2hp79o8/OptimizeResult.pptx?dl=0>. Specifically: - "slack" and "con" fields are doc-deprecated - new nested OptimizeResults objects "ineqlin" (corresponding to inequality constraints), "eqlin" (equality constraints), "lower", and "upper" (bound constraints) are added, containing: - "ineqlin": "slack", "marginals" - "eqlin": "violation", "marginals" - "lower": "freedom", "marginals" - "upper": "freedom", "marginals" Notes: - "marginals" is chosen over e.g. "shadow price" to avoid jargon that is associated with a particular field - "slack" is obvious - "freedom" was suggested by Julian Hall, creator and maintainer of HiGHS - "violation", "eqlin", "ineqlin" are inspired by Matlab's result interface - the new nested OptimizeResult objects will also house future ranging sensitivity information - this functionality is only available for the HiGHS solvers, i.e. method='highs', 'highs-ds', or 'highs-ipm' Please join us in the discussion on the PR or send feedback here. Thanks, Nicholas

1 0

ENH: (Stats) Studentized Range Distribution
by Dominic C. May 17, 2021

May 17, 2021

Hi all, We've implemented the studentized range distribution to support the upcoming addition of Tukey's HSD test. We used Cython and SciPy's LowLevelCallables to speed up the integration of its CDF, PDF, and moments, and the integrands are logarithmized to make it robust to inputs over several orders of magnitude. Accuracy is tested against tabulated values, R's ptukey, and a slow but accurate implementation in mpmath. If you're interested, please come take a look at https://github.com/scipy/scipy/pull/13732.

1 0

Custom __repr__?
by Pamphile Roy May 14, 2021

May 14, 2021

Hi everyone, I was wondering if we would want to improve our __repr__/__str__ functions. This just came out with the Matplotlib release: https://matplotlib.org/stable/users/whats_new.html#ipython-representations-… <https://matplotlib.org/stable/users/whats_new.html#ipython-representations-…> I can imagine something like this to display distributions for instance. There are many possible applications as you can imagine. FYI, this extra capabilities are available thanks to iPython reading extra _repr_xxx functions: https://ipython.readthedocs.io/en/stable/api/generated/IPython.display.html… <https://ipython.readthedocs.io/en/stable/api/generated/IPython.display.html…> Let me know what you think. Cheers, Pamphile p.s.: don’t forget to register for SciPy’s next community meetup https://mail.python.org/pipermail/scipy-dev/2021-May/024763.html <https://mail.python.org/pipermail/scipy-dev/2021-May/024763.html>

5 17

SciPy virtual sprint @ PyCon
by Ralf Gommers May 13, 2021

May 13, 2021

Hi all, After the NumPy sprint last Sunday, which was fun and successful, I got an invite to participate during the PyCon mentored sprints the coming weekend (see https://us.pycon.org/2021/summits/mentored-sprints/). They are run on the same infrastructure (Discord), it works quite well. There are multiple projects participating, I signed up for one sprint "table" for SciPy - noon to 4pm CEST this Saturday (May 15th). Are there other people who would like to help out and mentor newcomers make their first contribution to SciPy? Note that there are also Americas and Asia-Pacific 4 hour time slots, see the link above. Cheers, Ralf

3 5

Importing numpy as np in examples in docstrings
by Warren Weckesser May 12, 2021

May 12, 2021

Hey all, The question of including `import numpy as np` in the examples in docstrings has come up in some recent pull requests, and there is an issue for it at https://github.com/scipy/scipy/issues/13049. For many years, the policy has been to not include the import. The NumPy docstring standard (https://numpydoc.readthedocs.io/en/latest/format.html#examples) says "The examples may assume that `import numpy as np` is executed before the example code in numpy." Note that it says "*may* assume"--it does not say that the import must not be included. The question is whether the SciPy policy should (continue to) be "The import *must* not be included." If you would like to provide input, head over to the github issue and let us know what you think. Warren

1 0

pythran 0.9.10 - troer-biñsoù
by Serge Guelton May 11, 2021

May 11, 2021

Hi pythraners, /pythran is an ahead of time compiler for high-level scientific kernels written in Python./ I did a quick release of the pythran compiler today. It's only a few months since the previous release, but this one fixes an important memory leak with transposed arguments, so here it comes. Changelog: https://github.com/serge-sans-paille/pythran/blob/0.9.10/Changelog On Github: https://github.com/serge-sans-paille/pythran/tree/0.9.10 On Pypi: https://pypi.org/project/pythran/ Release on conda-forge and on fedora-rawhide should come soon. We recieved a lot more third party contributions than usual for this release, so let me thank Angus Gibson David Brochart Konrad Kleine ocaisa Pierre Augier Ralf Gommers Stefan van der Walt Sylvain Corlay

2 1

NumPy 1.20.3 release
by Charles R Harris May 10, 2021

May 10, 2021

Hi All, On behalf of the NumPy team I am pleased to announce the release of NumPy 1.20.3. NumPy 1,20.3 is a bugfix release containing several fixes merged to the main branch after the NumPy 1.20.2 release. The Python versions supported for this release are 3.7-3.9. Wheels can be downloaded from PyPI <https://pypi.org/project/numpy/1.20.3/>; source archives, release notes, and wheel hashes are available on Github <https://github.com/numpy/numpy/releases/tag/v1.20.3>. Linux users will need pip >= 0.19.3 in order to install manylinux2010 and manylinux2014 wheels. *Contributors* A total of 7 people contributed to this release. People with a "+" by their names contributed a patch for the first time. - Anne Archibald - Bas van Beek - Charles Harris - Dong Keun Oh + - Kamil Choudhury + - Sayed Adel - Sebastian Berg *Pull requests merged* A total of 15 pull requests were merged for this release. - #18763: BUG: Correct ``datetime64`` missing type overload for ``datetime.date``... - #18764: MAINT: Remove ``__all__`` in favor of explicit re-exports - #18768: BLD: Strip extra newline when dumping gfortran version on MacOS - #18769: BUG: fix segfault in object/longdouble operations - #18794: MAINT: Use towncrier build explicitly - #18887: MAINT: Relax certain integer-type constraints - #18915: MAINT: Remove unsafe unions and ABCs from return-annotations - #18921: MAINT: Allow more recursion depth for scalar tests. - #18922: BUG: Initialize the full nditer buffer in case of error - #18923: BLD: remove unnecessary flag ``-faltivec`` on macOS - #18924: MAINT, CI: treats _SIMD module build warnings as errors through... - #18925: BUG: for MINGW, threads.h existence test requires GLIBC > 2.12 - #18941: BUG: Make changelog recognize gh- as a PR number prefix. - #18948: REL, DOC: Prepare for the NumPy 1.20.3 release. - #18953: BUG: Fix failing mypy test in 1.20.x. Cheers, Charles Harris

1 0