From serge.guelton at telecom-bretagne.eu Wed Nov 6 16:38:52 2019 From: serge.guelton at telecom-bretagne.eu (Serge Guelton) Date: Wed, 6 Nov 2019 22:38:52 +0100 Subject: [SciPy-Dev] [pythran] Pythran 0.9.4 - Hollsent In-Reply-To: <20191031063225.GA24775@sguelton.remote.csb> References: <20191031063225.GA24775@sguelton.remote.csb> Message-ID: <20191106213852.GA13672@sguelton.remote.csb> On Thu, Oct 31, 2019 at 07:32:25AM +0100, Serge Guelton wrote: > Hi folks, > > It's always a pleasure to announce a Pythran release, and here we go for a > version bump! > [...] For those of you who are interested in technical details, http://serge-sans-paille.github.io/pythran-stories/pythran-094-hollsent.html may be an interesting read! ++ Serge From ralf.gommers at gmail.com Thu Nov 7 21:02:59 2019 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Thu, 7 Nov 2019 21:02:59 -0500 Subject: [SciPy-Dev] a small history rewrite on master Message-ID: Hi all, This is a heads up that I just did a force-push to master - I know that's bad form, but it was a necessary tweak. My apologies. If you've pulled from master in the last couple of hours, you may get a conflict. If so, you can fix it with: git checkout master git fetch upstream git reset --hard upstream/master Cheers, Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From maja.gwozdz.mkg33 at gmail.com Sat Nov 9 11:37:34 2019 From: maja.gwozdz.mkg33 at gmail.com (Maja Gwozdz) Date: Sat, 9 Nov 2019 17:37:34 +0100 Subject: [SciPy-Dev] Fwd: User survey results In-Reply-To: References: Message-ID: Hi everyone, first of all, I'd like to take this opportunity to thank everyone who took part in our user survey and spread the word. Your feedback has been very helpful! I've prepared a summary of the results, you can read it here: https://github.com/mkg33/GSoD/blob/master/user_survey_summary.pdf. In case you're interested in the comprehensive results, you can access them here: https://docs.google.com/spreadsheets/d/149Zie4unVkmyVKuc6X-RmWkaaOrxOyEy3j7sn-Ayz-c/edit?usp=sharing . All the best, Maja -------------- next part -------------- An HTML attachment was scrubbed... URL: From tyler.je.reddy at gmail.com Sat Nov 9 17:10:15 2019 From: tyler.je.reddy at gmail.com (Tyler Reddy) Date: Sat, 9 Nov 2019 15:10:15 -0700 Subject: [SciPy-Dev] ANN: SciPy 1.3.2 Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi all, On behalf of the SciPy development team I'm pleased to announce the release of SciPy 1.3.2, a maintenance and bug fix release that adds support for Python 3.8. Sources and binary wheels can be found at: https://pypi.org/project/scipy/ and at: https://github.com/scipy/scipy/releases/tag/v1.3.2 One of a few ways to install this release with pip: pip install scipy==1.3.2 ========================== SciPy 1.3.2 Release Notes ========================== SciPy 1.3.2 is a bug-fix and maintenance release that adds support for Python 3.8. Authors ======= * CJ Carey * Dany Vohl * Martin Gauch + * Ralf Gommers * Matt Haberland * Eric Larson * Nikolay Mayorov * Sam McCormack + * Andrew Nelson * Tyler Reddy * Pauli Virtanen * Huize Wang + * Warren Weckesser * Joseph Weston + A total of 14 people contributed to this release. People with a "+" by their names contributed a patch for the first time. This list of names is automatically generated, and may not be fully complete. Issues closed for 1.3.2 ------------------------------- * `#4915 `__: Bug in unique_roots in scipy.signal.signaltools.py for roots... * `#5161 `__: Optimizers reporting success when the minimum is NaN * `#5546 `__: ValueError raised if scipy.sparse.linalg.expm recieves array... * `#10124 `__: linprog(method='revised simplex') doctest bug * `#10609 `__: Graph shortest path with Floyd-Warshall removes explicit zeros. * `#10658 `__: BUG: stats: Formula for the variance of the noncentral F distribution... * `#10695 `__: BUG: Assignation issues in csr_matrix with fancy indexing * `#10846 `__: root_scalar fails when passed a function wrapped with functools.lru_cache * `#10902 `__: CI: travis osx build failure * `#10967 `__: macOS build failure in SuperLU on maintenance/1.3.x * `#10976 `__: Typo in sp.stats.wilcoxon docstring Pull requests for 1.3.2 ------------------------------ * `#10498 `__: TST: optimize: fixed \`linprog\` \`"disp": True\` bug * `#10536 `__: CI: add 3.8-dev to travis * `#10671 `__: BUG: stats: Fix the formula for the variance of the noncentral... * `#10693 `__: BUG: ScalarFunction stores original array * `#10700 `__: BUG: sparse: Loosen checks on sparse fancy assignment * `#10709 `__: BUG: Fix floyd_warshall to support zero-weight edges * `#10756 `__: BUG: optimize: ensure solvers exit with success=False for nan... * `#10833 `__: BUG: Fix subspace_angles for complex values * `#10882 `__: BUG: sparse/arpack: fix incorrect code for complex hermitian... * `#10891 `__: BUG: make C-implemented root finders work with functools.lru_cache * `#10906 `__: BUG: sparse/linalg: fix expm for np.matrix inputs * `#10917 `__: CI: fix travis osx CI * `#10930 `__: MAINT: Updates for 3.8 * `#10938 `__: MAINT: Add Python 3.8 to pyproject.toml * `#10943 `__: BLD: update Cython version to 0.29.13 * `#10961 `__: BUG: Fix signal.unique_roots * `#10971 `__: MAINT: use 3.8 stable in CI * `#10977 `__: DOC: Fix typo in sp.stats.wilcoxon docsting * `#11025 `__: Update _peak_finding.py Checksums ========= MD5 ~~~ 5acb33b69d73d369b05f10aaf24220c4 scipy-1.3.2-cp35-cp35m-macosx_10_6_intel.whl 2afea38680dc72f356965178c128747d scipy-1.3.2-cp35-cp35m-manylinux1_i686.whl 97d2aa748499111d348c283b4e435755 scipy-1.3.2-cp35-cp35m-manylinux1_x86_64.whl 22cbe9c7a2bef004cda3b18355b5d277 scipy-1.3.2-cp35-cp35m-win32.whl e6e3d77c7e7d92344263e55b7f7f14ba scipy-1.3.2-cp35-cp35m-win_amd64.whl 6abb6cdc43950ad31456559dc442571b scipy-1.3.2-cp36-cp36m-macosx_10_6_intel.whl 6ffd1eb60e209d1e329c65db9064ba01 scipy-1.3.2-cp36-cp36m-manylinux1_i686.whl 1c549d17701e2a42836857dfed876854 scipy-1.3.2-cp36-cp36m-manylinux1_x86_64.whl 89895563ebad22c42678002402d7f000 scipy-1.3.2-cp36-cp36m-win32.whl f1f19a0307fa1ce5e5e3fae288e6d317 scipy-1.3.2-cp36-cp36m-win_amd64.whl b12328c09d018bf0958096bd29e528a8 scipy-1.3.2-cp37-cp37m-macosx_10_6_intel.whl 6b268afa77f99fbdf02d43255365b6e7 scipy-1.3.2-cp37-cp37m-manylinux1_i686.whl 5a258b29cae36f2f35167b08c79a5b3c scipy-1.3.2-cp37-cp37m-manylinux1_x86_64.whl 2639b1c67a33c23ee5b0d4d3057106e2 scipy-1.3.2-cp37-cp37m-win32.whl 5201e48b5e3fca2e056fbe4e4b79f2c3 scipy-1.3.2-cp37-cp37m-win_amd64.whl 43087f7b2e363f8f953d037d608dd53f scipy-1.3.2-cp38-cp38-macosx_10_9_x86_64.whl 0a5444f72721ceaf1eb875ac9ac2b31f scipy-1.3.2-cp38-cp38-manylinux1_i686.whl 44372a0125d0e2d8a3041e89fe01a944 scipy-1.3.2-cp38-cp38-manylinux1_x86_64.whl 345c6459a52f81d2e3f3b490b932be4a scipy-1.3.2-cp38-cp38-win32.whl 8ff866aadbc56067c9d09551ce072d7f scipy-1.3.2-cp38-cp38-win_amd64.whl 019eabd9ef410bb7bf2e7eda09cefc4d scipy-1.3.2.tar.gz 742eb61ce825d8cb6a419e5d1dfd822c scipy-1.3.2.tar.xz b1ece516b97390ece5153dfc3dc4bc75 scipy-1.3.2.zip SHA256 ~~~~~~ 7a0477929e6f9d5928fe81fe75d00b7da9545a49109e66028d85848b18aeef99 scipy-1.3.2-cp35-cp35m-macosx_10_6_intel.whl 0f81e71149539ac09053a3f9165659367b060eceef3bbde11e6600e1c341f1f2 scipy-1.3.2-cp35-cp35m-manylinux1_i686.whl ecfd45ca0ce1d6c13bef17794b4052cc9a9574f4be8d44c9bcfd7e34294bd2d7 scipy-1.3.2-cp35-cp35m-manylinux1_x86_64.whl ee5888c62cd83c9bf9927ffcee08434e7d5c81a8f31e5b85af5470e511022c08 scipy-1.3.2-cp35-cp35m-win32.whl 07673b5b96dbe28c88f3a53ca9af67f802aa853de7402e31f473b4dd6501c799 scipy-1.3.2-cp35-cp35m-win_amd64.whl 2e4b5fdb635dd425bf46fbd6381612692d3c795f1eb6fe62410305a440691d46 scipy-1.3.2-cp36-cp36m-macosx_10_6_intel.whl 4ad7a3ae9831d2085d6f50b81bfcd76368293eafdf31f4ac9f109c6061309c24 scipy-1.3.2-cp36-cp36m-manylinux1_i686.whl df4dbd3d40db3f667e0145dba5f50954bf28b2dd5b8b400c79d5e3fe8cb67ce2 scipy-1.3.2-cp36-cp36m-manylinux1_x86_64.whl 470d8fc76ccab6cfff60a9de4ce316a23ee7f63615d948c7446dc7c1bb45042d scipy-1.3.2-cp36-cp36m-win32.whl f018892621b787b9abf76d51d1f0c21611c71752ebb1891ccf7992e0bf973708 scipy-1.3.2-cp36-cp36m-win_amd64.whl 34c48d922760782732d6f8f4532e320984d1280763c6787c6582021d34c8ad79 scipy-1.3.2-cp37-cp37m-macosx_10_6_intel.whl 33ac3213ee617bbc0eac84d02b130d69093ed7738afb281dfdeb12a9dbdf1530 scipy-1.3.2-cp37-cp37m-manylinux1_i686.whl 9c3221039da50f3b60da70b65d6b020ea26cefbb097116cfec696010432d1f6c scipy-1.3.2-cp37-cp37m-manylinux1_x86_64.whl 2dc26e5b3eb86b7adad506b6b04020f6a87e1102c9acd039e937d28bdcee7fa6 scipy-1.3.2-cp37-cp37m-win32.whl 0359576d8cc058bd615999cf985e2423dc6cc824666d60e8b8d4810569a04655 scipy-1.3.2-cp37-cp37m-win_amd64.whl e837c8068bd1929a533e9d51562faf6584ddb5303d9e218d8c11aa4719dcd617 scipy-1.3.2-cp38-cp38-macosx_10_9_x86_64.whl 61812a7db0d9bc3f13653e52b8ddb1935cf444ec55f39160fc2778aeb2719057 scipy-1.3.2-cp38-cp38-manylinux1_i686.whl 3f556f63e070e9596624e42e99d23b259d8f0fc63ec093bef97a9f1c579565b2 scipy-1.3.2-cp38-cp38-manylinux1_x86_64.whl 125aa82f7b3d4bd7f77fed6c3c6e31be47e33f129d829799569389ae59f913e7 scipy-1.3.2-cp38-cp38-win32.whl f2d5db81d90d14a32d4aff920f52fca5639bcaaaf87b4f61bce83a1d238f49fc scipy-1.3.2-cp38-cp38-win_amd64.whl a03939b431994289f39373c57bbe452974a7da724ae7f9620a1beee575434da4 scipy-1.3.2.tar.gz 1d2f09bcb6c4b66a65d9f49d21fa065f5396c940edac8285b87947b8d21b55f8 scipy-1.3.2.tar.xz aa18ee47e2e606ececc5b0df672705e0ee413d249bf9c129be2fd280dcd21a32 scipy-1.3.2.zip -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJdxx+LAAoJELD/41ZX0J71CooQAJwQGqTxyG0FCXNk5EffrRC0 CL+4nnD8eonzjZE+Oc7Lj4uiTITgJ+E7bd0WHhmaLAHZe2mGhZJlPS1c6Nb3nURB knJwKyIIgf2IAbnO+bBg7txosuU1RQidwq3xmofGJTXadUfVc1S1iEqnxpFN0GmN dlZcvuPMnWwMawM3ort+JVB01t338PlMso3bOdP4yUJXdaxUmj4TESbJV4gLUaHg e8s2i4ASKBz7GaJ4bkiKDgxJdP807gu6KEKqOQDLRYoN0kQ1yp+KaAcjEnTMSsPa 8mVa9R/CZF+J/YX1MxyITs7hr/czMPGRVHQbTDh3Lc0BqRJdidgswgQQ8IChhIEm lFW6PefS18Un9dHD9jTQ+GI4WCKBpsN08qeCpFn+cwBnL7bdloS3CcPV1JDChjdK SI56wCw9vwc+w7R3Rg4n+KO2UUoxar0jNJXU0wT6ZdbX0A367i/7XJ57ToWXI5ax DUchJNj9SIOKEzoPwO/XR16KeurLeJcoJbon4kj4JjfrNI7Z03sw0hn4ALLQpOP5 /l49Nwa5VJGxWvSJCNaLV9qPjhzbFDyG+adLxFiMDvbvFaNrnm7Zkp4vPCcjNe+m r+0k1bfUrzE1eyZCuHGU+e9Vz7nSPODqhuenxz3PWBnqVJSSaBtgDGEiNddjstbW YvhHlfbIYBst7HvxR7xQ =roJQ -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From evgeny.burovskiy at gmail.com Sat Nov 9 17:31:17 2019 From: evgeny.burovskiy at gmail.com (Evgeni Burovski) Date: Sun, 10 Nov 2019 01:31:17 +0300 Subject: [SciPy-Dev] [Numpy-discussion] ANN: SciPy 1.3.2 In-Reply-To: References: Message-ID: Thanks Tyler for managing this release! On Sun, Nov 10, 2019 at 1:10 AM Tyler Reddy wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Hi all, > > On behalf of the SciPy development team I'm pleased to announce > the release of SciPy 1.3.2, a maintenance and bug fix release that > adds support for Python 3.8. > > Sources and binary wheels can be found at: > https://pypi.org/project/scipy/ > and at: https://github.com/scipy/scipy/releases/tag/v1.3.2 > > One of a few ways to install this release with pip: > > pip install scipy==1.3.2 > > ========================== > SciPy 1.3.2 Release Notes > ========================== > > SciPy 1.3.2 is a bug-fix and maintenance release that adds > support for Python 3.8. > > Authors > ======= > > * CJ Carey > * Dany Vohl > * Martin Gauch + > * Ralf Gommers > * Matt Haberland > * Eric Larson > * Nikolay Mayorov > * Sam McCormack + > * Andrew Nelson > * Tyler Reddy > * Pauli Virtanen > * Huize Wang + > * Warren Weckesser > * Joseph Weston + > > A total of 14 people contributed to this release. > People with a "+" by their names contributed a patch for the first time. > This list of names is automatically generated, and may not be fully complete. > > Issues closed for 1.3.2 > ------------------------------- > > * `#4915 `__: Bug in unique_roots in scipy.signal.signaltools.py for roots... > * `#5161 `__: Optimizers reporting success when the minimum is NaN > * `#5546 `__: ValueError raised if scipy.sparse.linalg.expm recieves array... > * `#10124 `__: linprog(method='revised simplex') doctest bug > * `#10609 `__: Graph shortest path with Floyd-Warshall removes explicit zeros. > * `#10658 `__: BUG: stats: Formula for the variance of the noncentral F distribution... > * `#10695 `__: BUG: Assignation issues in csr_matrix with fancy indexing > * `#10846 `__: root_scalar fails when passed a function wrapped with functools.lru_cache > * `#10902 `__: CI: travis osx build failure > * `#10967 `__: macOS build failure in SuperLU on maintenance/1.3.x > * `#10976 `__: Typo in sp.stats.wilcoxon docstring > > > Pull requests for 1.3.2 > ------------------------------ > > * `#10498 `__: TST: optimize: fixed \`linprog\` \`"disp": True\` bug > * `#10536 `__: CI: add 3.8-dev to travis > * `#10671 `__: BUG: stats: Fix the formula for the variance of the noncentral... > * `#10693 `__: BUG: ScalarFunction stores original array > * `#10700 `__: BUG: sparse: Loosen checks on sparse fancy assignment > * `#10709 `__: BUG: Fix floyd_warshall to support zero-weight edges > * `#10756 `__: BUG: optimize: ensure solvers exit with success=False for nan... > * `#10833 `__: BUG: Fix subspace_angles for complex values > * `#10882 `__: BUG: sparse/arpack: fix incorrect code for complex hermitian... > * `#10891 `__: BUG: make C-implemented root finders work with functools.lru_cache > * `#10906 `__: BUG: sparse/linalg: fix expm for np.matrix inputs > * `#10917 `__: CI: fix travis osx CI > * `#10930 `__: MAINT: Updates for 3.8 > * `#10938 `__: MAINT: Add Python 3.8 to pyproject.toml > * `#10943 `__: BLD: update Cython version to 0.29.13 > * `#10961 `__: BUG: Fix signal.unique_roots > * `#10971 `__: MAINT: use 3.8 stable in CI > * `#10977 `__: DOC: Fix typo in sp.stats.wilcoxon docsting > * `#11025 `__: Update _peak_finding.py > > Checksums > ========= > > MD5 > ~~~ > > 5acb33b69d73d369b05f10aaf24220c4 scipy-1.3.2-cp35-cp35m-macosx_10_6_intel.whl > 2afea38680dc72f356965178c128747d scipy-1.3.2-cp35-cp35m-manylinux1_i686.whl > 97d2aa748499111d348c283b4e435755 scipy-1.3.2-cp35-cp35m-manylinux1_x86_64.whl > 22cbe9c7a2bef004cda3b18355b5d277 scipy-1.3.2-cp35-cp35m-win32.whl > e6e3d77c7e7d92344263e55b7f7f14ba scipy-1.3.2-cp35-cp35m-win_amd64.whl > 6abb6cdc43950ad31456559dc442571b scipy-1.3.2-cp36-cp36m-macosx_10_6_intel.whl > 6ffd1eb60e209d1e329c65db9064ba01 scipy-1.3.2-cp36-cp36m-manylinux1_i686.whl > 1c549d17701e2a42836857dfed876854 scipy-1.3.2-cp36-cp36m-manylinux1_x86_64.whl > 89895563ebad22c42678002402d7f000 scipy-1.3.2-cp36-cp36m-win32.whl > f1f19a0307fa1ce5e5e3fae288e6d317 scipy-1.3.2-cp36-cp36m-win_amd64.whl > b12328c09d018bf0958096bd29e528a8 scipy-1.3.2-cp37-cp37m-macosx_10_6_intel.whl > 6b268afa77f99fbdf02d43255365b6e7 scipy-1.3.2-cp37-cp37m-manylinux1_i686.whl > 5a258b29cae36f2f35167b08c79a5b3c scipy-1.3.2-cp37-cp37m-manylinux1_x86_64.whl > 2639b1c67a33c23ee5b0d4d3057106e2 scipy-1.3.2-cp37-cp37m-win32.whl > 5201e48b5e3fca2e056fbe4e4b79f2c3 scipy-1.3.2-cp37-cp37m-win_amd64.whl > 43087f7b2e363f8f953d037d608dd53f scipy-1.3.2-cp38-cp38-macosx_10_9_x86_64.whl > 0a5444f72721ceaf1eb875ac9ac2b31f scipy-1.3.2-cp38-cp38-manylinux1_i686.whl > 44372a0125d0e2d8a3041e89fe01a944 scipy-1.3.2-cp38-cp38-manylinux1_x86_64.whl > 345c6459a52f81d2e3f3b490b932be4a scipy-1.3.2-cp38-cp38-win32.whl > 8ff866aadbc56067c9d09551ce072d7f scipy-1.3.2-cp38-cp38-win_amd64.whl > 019eabd9ef410bb7bf2e7eda09cefc4d scipy-1.3.2.tar.gz > 742eb61ce825d8cb6a419e5d1dfd822c scipy-1.3.2.tar.xz > b1ece516b97390ece5153dfc3dc4bc75 scipy-1.3.2.zip > > SHA256 > ~~~~~~ > > 7a0477929e6f9d5928fe81fe75d00b7da9545a49109e66028d85848b18aeef99 scipy-1.3.2-cp35-cp35m-macosx_10_6_intel.whl > 0f81e71149539ac09053a3f9165659367b060eceef3bbde11e6600e1c341f1f2 scipy-1.3.2-cp35-cp35m-manylinux1_i686.whl > ecfd45ca0ce1d6c13bef17794b4052cc9a9574f4be8d44c9bcfd7e34294bd2d7 scipy-1.3.2-cp35-cp35m-manylinux1_x86_64.whl > ee5888c62cd83c9bf9927ffcee08434e7d5c81a8f31e5b85af5470e511022c08 scipy-1.3.2-cp35-cp35m-win32.whl > 07673b5b96dbe28c88f3a53ca9af67f802aa853de7402e31f473b4dd6501c799 scipy-1.3.2-cp35-cp35m-win_amd64.whl > 2e4b5fdb635dd425bf46fbd6381612692d3c795f1eb6fe62410305a440691d46 scipy-1.3.2-cp36-cp36m-macosx_10_6_intel.whl > 4ad7a3ae9831d2085d6f50b81bfcd76368293eafdf31f4ac9f109c6061309c24 scipy-1.3.2-cp36-cp36m-manylinux1_i686.whl > df4dbd3d40db3f667e0145dba5f50954bf28b2dd5b8b400c79d5e3fe8cb67ce2 scipy-1.3.2-cp36-cp36m-manylinux1_x86_64.whl > 470d8fc76ccab6cfff60a9de4ce316a23ee7f63615d948c7446dc7c1bb45042d scipy-1.3.2-cp36-cp36m-win32.whl > f018892621b787b9abf76d51d1f0c21611c71752ebb1891ccf7992e0bf973708 scipy-1.3.2-cp36-cp36m-win_amd64.whl > 34c48d922760782732d6f8f4532e320984d1280763c6787c6582021d34c8ad79 scipy-1.3.2-cp37-cp37m-macosx_10_6_intel.whl > 33ac3213ee617bbc0eac84d02b130d69093ed7738afb281dfdeb12a9dbdf1530 scipy-1.3.2-cp37-cp37m-manylinux1_i686.whl > 9c3221039da50f3b60da70b65d6b020ea26cefbb097116cfec696010432d1f6c scipy-1.3.2-cp37-cp37m-manylinux1_x86_64.whl > 2dc26e5b3eb86b7adad506b6b04020f6a87e1102c9acd039e937d28bdcee7fa6 scipy-1.3.2-cp37-cp37m-win32.whl > 0359576d8cc058bd615999cf985e2423dc6cc824666d60e8b8d4810569a04655 scipy-1.3.2-cp37-cp37m-win_amd64.whl > e837c8068bd1929a533e9d51562faf6584ddb5303d9e218d8c11aa4719dcd617 scipy-1.3.2-cp38-cp38-macosx_10_9_x86_64.whl > 61812a7db0d9bc3f13653e52b8ddb1935cf444ec55f39160fc2778aeb2719057 scipy-1.3.2-cp38-cp38-manylinux1_i686.whl > 3f556f63e070e9596624e42e99d23b259d8f0fc63ec093bef97a9f1c579565b2 scipy-1.3.2-cp38-cp38-manylinux1_x86_64.whl > 125aa82f7b3d4bd7f77fed6c3c6e31be47e33f129d829799569389ae59f913e7 scipy-1.3.2-cp38-cp38-win32.whl > f2d5db81d90d14a32d4aff920f52fca5639bcaaaf87b4f61bce83a1d238f49fc scipy-1.3.2-cp38-cp38-win_amd64.whl > a03939b431994289f39373c57bbe452974a7da724ae7f9620a1beee575434da4 scipy-1.3.2.tar.gz > 1d2f09bcb6c4b66a65d9f49d21fa065f5396c940edac8285b87947b8d21b55f8 scipy-1.3.2.tar.xz > aa18ee47e2e606ececc5b0df672705e0ee413d249bf9c129be2fd280dcd21a32 scipy-1.3.2.zip > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 > > iQIcBAEBCAAGBQJdxx+LAAoJELD/41ZX0J71CooQAJwQGqTxyG0FCXNk5EffrRC0 > CL+4nnD8eonzjZE+Oc7Lj4uiTITgJ+E7bd0WHhmaLAHZe2mGhZJlPS1c6Nb3nURB > knJwKyIIgf2IAbnO+bBg7txosuU1RQidwq3xmofGJTXadUfVc1S1iEqnxpFN0GmN > dlZcvuPMnWwMawM3ort+JVB01t338PlMso3bOdP4yUJXdaxUmj4TESbJV4gLUaHg > e8s2i4ASKBz7GaJ4bkiKDgxJdP807gu6KEKqOQDLRYoN0kQ1yp+KaAcjEnTMSsPa > 8mVa9R/CZF+J/YX1MxyITs7hr/czMPGRVHQbTDh3Lc0BqRJdidgswgQQ8IChhIEm > lFW6PefS18Un9dHD9jTQ+GI4WCKBpsN08qeCpFn+cwBnL7bdloS3CcPV1JDChjdK > SI56wCw9vwc+w7R3Rg4n+KO2UUoxar0jNJXU0wT6ZdbX0A367i/7XJ57ToWXI5ax > DUchJNj9SIOKEzoPwO/XR16KeurLeJcoJbon4kj4JjfrNI7Z03sw0hn4ALLQpOP5 > /l49Nwa5VJGxWvSJCNaLV9qPjhzbFDyG+adLxFiMDvbvFaNrnm7Zkp4vPCcjNe+m > r+0k1bfUrzE1eyZCuHGU+e9Vz7nSPODqhuenxz3PWBnqVJSSaBtgDGEiNddjstbW > YvhHlfbIYBst7HvxR7xQ > =roJQ > -----END PGP SIGNATURE----- > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at python.org > https://mail.python.org/mailman/listinfo/numpy-discussion From charlesr.harris at gmail.com Sat Nov 9 19:52:17 2019 From: charlesr.harris at gmail.com (Charles R Harris) Date: Sat, 9 Nov 2019 17:52:17 -0700 Subject: [SciPy-Dev] [Numpy-discussion] ANN: SciPy 1.3.2 In-Reply-To: References: Message-ID: On Sat, Nov 9, 2019 at 3:11 PM Tyler Reddy wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Hi all, > > On behalf of the SciPy development team I'm pleased to announce > the release of SciPy 1.3.2, a maintenance and bug fix release that > adds support for Python 3.8. > > Good job... Chuck > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tyler.je.reddy at gmail.com Sat Nov 9 23:40:12 2019 From: tyler.je.reddy at gmail.com (Tyler Reddy) Date: Sat, 9 Nov 2019 21:40:12 -0700 Subject: [SciPy-Dev] Proposed SciPy 1.4.0 Release Schedule In-Reply-To: References: Message-ID: We currently sit at 31 open PRs and 20 open issues with 1.4.0 milestone. That's a substantial drop in PRs but a rise in issues since the last accounting. Things got a little hectic with Python 3.8 for 1.3.2, but hopefully the wheels stuff is in good shape for 1.4.x series now. Branching in about 5 days is ambitious, but let's aim to stay reasonably on track if possible. On Mon, 21 Oct 2019 at 13:39, Matt Haberland wrote: > Re: 1.2.3 release, I did get a request in gh-10915 > for gh-10498 > to be backported to 1.2. > > On Mon, Oct 21, 2019 at 8:47 AM Ralf Gommers > wrote: > >> >> >> On Sat, Oct 19, 2019 at 12:24 AM Tyler Reddy >> wrote: >> >>> Hi, >>> >>> SciPy 1.3.0 was released May 17 (5 months ago), and I think we'd like to >>> keep a roughly biannual release cadence. >>> >>> I'd like to propose the following schedule for 1.4.0: >>> - November 14: branch 1.4.x >>> - November 17: rc1 >>> - December 1: rc2 (if needed) >>> - December 10: final release >>> >> >> Sounds good to me. >> >>> >>> The arrival of Python 3.8 and simultaneous responsibility to get at >>> least one more 1.2.x LTS Python 2.7 release out the door means things will >>> probably be busy on the release front until 2020. >>> >> >> True. I think supporting 3.8 is fairly high-prio, there's a lot of demand >> for it. Doing a 1.3.2 release that supports it would make sense I guess. >> >> There don't seem to be any new commits on the 1.2.x branch nor urgent >> Python 2.7 fixes that need to go out. So do we need a 1.2.3 release? >> >> Cheers, >> Ralf >> >> >> >>> As always, it is a good idea to start tagging things that should be in >>> 1.4.0 & please do help with reviewing PRs/issues that are tagged--current >>> counts are: >>> >>> - PRs: 40 open with 1.4.0 milestone >>> - issues: 17 open with 1.4.0 milestone >>> >>> While helping with that, also great if the release notes wiki is updated >>> for appropriate changes: >>> https://github.com/scipy/scipy/wiki/Release-note-entries-for-SciPy-1.4.0 >>> >>> Curating those final notes can be painful if the wiki isn't updated. >>> >>> Thoughts/objections for the schedule? >>> >>> Best wishes, >>> Tyler >>> _______________________________________________ >>> 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 >> > > > -- > Matt Haberland > Assistant Adjunct Professor in the Program in Computing > Department of Mathematics > 6617A Math Sciences Building, UCLA > _______________________________________________ > 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 jh at physics.ucf.edu Sun Nov 10 09:21:18 2019 From: jh at physics.ucf.edu (Joe Harrington) Date: Sun, 10 Nov 2019 09:21:18 -0500 Subject: [SciPy-Dev] Fwd: User survey results In-Reply-To: References: Message-ID: <459b1916-9b82-7993-6519-06bff82df9a0@physics.ucf.edu> The survey results are quite consistent with my own experience, so I have a thought to offer on one of the recurring themes.? In some areas, such as stats, different communities use different terms for the same thing, or focus on different aspects of an area.? Documentation sometimes assumes that the reader knows the theory and just needs a mapping of concepts to functionality.? In reality, the reader is often a non-expert in stats who may know basic principles there but is learning about the practical application of stats as much as how to access scipy's functionality.? They're probably even filling in gaps in their stats knowledge. So, tutorial documentation that works examples while explaining stats principles could really be useful.? The idea is not to deliver Stats 101, but rather to remind those who took Stats 101 years ago what the process is for doing various things, and to fill in the gaps for the many of us who never even had Stats 101, but instead have picked up dribs and drabs of stats from various classes and readings.? Reference to free, external, online sources that are not highly theoretical dives into statsmania will be especially good. There is such a thing as going too far with this, and that's where external sources come in.? For the equivalent problem in programming, I rely on ThinkPython, by Allen Downey, whom I met at a SciPy conference long ago.? He also has a book called ThinkStats, and several others in the stats-data-science realm. These teach those concepts using SciPy (not the other way around), and could be good grounding bases for docs that covered more of SciPy than the books do (e.g., go read chapter N of ThinkStats for a grounding in this concept, then come back here to exercise the whole library through some examples). Of course, there are a million such books, I just happen to think his are excellent, in the sense that they teach the basics solidly, without going into such depth that they take forever to read or are mainly of interest to specialists in stats, rather than other science areas.? Ideally, we'd want to be agnostic of the external resources and not endorse (or rely on the continued existence of) any particular resource.? On the other hand, Sturgeon's Law applies in academic publishing at least as much as in science fiction, so we should at least point to some resources that are actually good, and that integrate well with our docs. --jh-- On 11/9/19 11:37 AM, Maja Gwozdz wrote: > Hi everyone, > > first of all, I'd like to take this opportunity to thank everyone who > took part in our user survey and spread the word. Your feedback has > been very helpful! > > I've prepared a summary of the results, you can read it here: > https://github.com/mkg33/GSoD/blob/master/user_survey_summary.pdf. > > In case you're interested in the comprehensive results, you can access > them here: > https://docs.google.com/spreadsheets/d/149Zie4unVkmyVKuc6X-RmWkaaOrxOyEy3j7sn-Ayz-c/edit?usp=sharing. > > All the best, > Maja > > > _______________________________________________ > 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 maja.gwozdz.mkg33 at gmail.com Sun Nov 10 15:34:19 2019 From: maja.gwozdz.mkg33 at gmail.com (Maja Gwozdz) Date: Sun, 10 Nov 2019 21:34:19 +0100 Subject: [SciPy-Dev] Fwd: User survey results In-Reply-To: <459b1916-9b82-7993-6519-06bff82df9a0@physics.ucf.edu> References: <459b1916-9b82-7993-6519-06bff82df9a0@physics.ucf.edu> Message-ID: Hi Joe, thanks for the message. I think this is a very reasonable approach to improving the current documentation. It's all about striking a balance between the necessary details and general concepts. I've recorded your ideas in my 'TODO list' that I'm making based on the survey results and other suggestions. Best, Maja On Sun, Nov 10, 2019 at 3:28 PM Joe Harrington wrote: > The survey results are quite consistent with my own experience, so I have > a thought to offer on one of the recurring themes. In some areas, such as > stats, different communities use different terms for the same thing, or > focus on different aspects of an area. Documentation sometimes assumes > that the reader knows the theory and just needs a mapping of concepts to > functionality. In reality, the reader is often a non-expert in stats who > may know basic principles there but is learning about the practical > application of stats as much as how to access scipy's functionality. > They're probably even filling in gaps in their stats knowledge. > > So, tutorial documentation that works examples while explaining stats > principles could really be useful. The idea is not to deliver Stats 101, > but rather to remind those who took Stats 101 years ago what the process is > for doing various things, and to fill in the gaps for the many of us who > never even had Stats 101, but instead have picked up dribs and drabs of > stats from various classes and readings. Reference to free, external, > online sources that are not highly theoretical dives into statsmania will > be especially good. > > There is such a thing as going too far with this, and that's where > external sources come in. For the equivalent problem in programming, I > rely on ThinkPython, by Allen Downey, whom I met at a SciPy conference long > ago. He also has a book called ThinkStats, and several others in the > stats-data-science realm. These teach those concepts using SciPy (not the > other way around), and could be good grounding bases for docs that covered > more of SciPy than the books do (e.g., go read chapter N of ThinkStats for > a grounding in this concept, then come back here to exercise the whole > library through some examples). > > Of course, there are a million such books, I just happen to think his are > excellent, in the sense that they teach the basics solidly, without going > into such depth that they take forever to read or are mainly of interest to > specialists in stats, rather than other science areas. Ideally, we'd want > to be agnostic of the external resources and not endorse (or rely on the > continued existence of) any particular resource. On the other hand, > Sturgeon's Law applies in academic publishing at least as much as in > science fiction, so we should at least point to some resources that are > actually good, and that integrate well with our docs. > > --jh-- > On 11/9/19 11:37 AM, Maja Gwozdz wrote: > > Hi everyone, > > first of all, I'd like to take this opportunity to thank everyone who took > part in our user survey and spread the word. Your feedback has been very > helpful! > > I've prepared a summary of the results, you can read it here: > https://github.com/mkg33/GSoD/blob/master/user_survey_summary.pdf. > > In case you're interested in the comprehensive results, you can access > them here: > https://docs.google.com/spreadsheets/d/149Zie4unVkmyVKuc6X-RmWkaaOrxOyEy3j7sn-Ayz-c/edit?usp=sharing > . > > All the best, > Maja > > > _______________________________________________ > SciPy-Dev mailing listSciPy-Dev at python.orghttps://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 charlesr.harris at gmail.com Sun Nov 10 21:32:41 2019 From: charlesr.harris at gmail.com (Charles R Harris) Date: Sun, 10 Nov 2019 19:32:41 -0700 Subject: [SciPy-Dev] NumPy 1.17.4 release. Message-ID: Hi All, On behalf of the NumPy team I am pleased to announce that NumPy 1.17.4 has been released. This is a bugfix release. The Python versions supported in this release are 3.5-3.8. Downstream developers should use Cython >= 0.29.13 for Python 3.8 support and OpenBLAS >= 3.7 to avoid wrong results on the Skylake architecture. The NumPy Wheels for this release can be downloaded from PyPI , source archives and release notes are available from Github . *Highlights* - Fixed `random.random_integers` biased generation of 8 and 16 bit integers. - Fixed `np.einsum` regression on Power9 and z/Linux. - Fixed histogram problem with signed integer arrays *Contributors* A total of 5 people contributed to this release. People with a "+" by their names contributed a patch for the first time. - Charles Harris - Chris Burr + - Matti Picus - Qiming Sun + - Warren Weckesser *Pull requests merged* A total of 8 pull requests were merged for this release. - gh-14758: BLD: Declare support for python 3.8 - gh-14781: BUG: Random: biased samples from integers() with 8 or 16 bit... - gh-14851: BUG: Fix `_ctypes` class circular reference. (gh-13808) - gh-14852: BLD: Add 'apt update' to shippable - gh-14855: BUG: Fix `np.einsum` errors on Power9 Linux and z/Linux - gh-14857: BUG: Fix histogram problem with signed integer arrays. - gh-14858: BLD: Prevent -flto from optimising long double representation... - gh-14866: MAINT: move buffer.h -> npy_buffer.h to avoid conflicts Cheers, Charles Harris -------------- next part -------------- An HTML attachment was scrubbed... URL: From adrianmpw at gmail.com Tue Nov 12 10:28:50 2019 From: adrianmpw at gmail.com (Adrian Price-Whelan) Date: Tue, 12 Nov 2019 10:28:50 -0500 Subject: [SciPy-Dev] Allow specifying inverse-variance matrix to multivariate_normal (scipy.stats) Message-ID: Hi all -- scipy.stats.multivariate_normal currently accepts a mean and covariance matrix, and always computes the inverse-variance matrix internally and explicitly. But I often have covariance matrices with inverses that can be computed through other linear algebra tricks or identities. It would therefore be great if scipy.stats.multivariate_normal would allow optionally passing in an inverse-variance matrix, which is sometimes useful for (a) performance, or (b) numerical precision issues with covariance matrices with large values. To be clear: I'm just suggesting that the MVN distribution could accept an inverse-variance matrix to bypass the inverse calculation, I'm not suggesting implementing or supporting linear algebra identities. To get around this in the past, e.g., to compute the log-PDF values at some positions, I've typically implemented by own custom function, or have used the implementation in astroML (https://github.com/astroML/astroML/blob/master/astroML/utils/utils.py#L22). It would be nice to have this supported in scipy directly! Thoughts? (Note: I made an issue for this idea, but was told to start discussion here instead https://github.com/scipy/scipy/issues/11053) best, - adrian -- Adrian M. Price-Whelan Flatiron Institute, NYC http://adrn.github.io From tyler.je.reddy at gmail.com Tue Nov 12 11:30:37 2019 From: tyler.je.reddy at gmail.com (Tyler Reddy) Date: Tue, 12 Nov 2019 09:30:37 -0700 Subject: [SciPy-Dev] Proposed SciPy 1.4.0 Release Schedule In-Reply-To: References: Message-ID: Down to 12 open PRs with 1.4.0 milestone--getting closer! On Sat, 9 Nov 2019 at 21:40, Tyler Reddy wrote: > We currently sit at 31 open PRs and 20 open issues with 1.4.0 milestone. > > That's a substantial drop in PRs but a rise in issues since the last > accounting. Things got > a little hectic with Python 3.8 for 1.3.2, but hopefully the wheels stuff > is in good shape > for 1.4.x series now. > > Branching in about 5 days is ambitious, but let's aim to stay reasonably > on track if possible. > > On Mon, 21 Oct 2019 at 13:39, Matt Haberland wrote: > >> Re: 1.2.3 release, I did get a request in gh-10915 >> for gh-10498 >> to be backported to 1.2. >> >> On Mon, Oct 21, 2019 at 8:47 AM Ralf Gommers >> wrote: >> >>> >>> >>> On Sat, Oct 19, 2019 at 12:24 AM Tyler Reddy >>> wrote: >>> >>>> Hi, >>>> >>>> SciPy 1.3.0 was released May 17 (5 months ago), and I think we'd like >>>> to keep a roughly biannual release cadence. >>>> >>>> I'd like to propose the following schedule for 1.4.0: >>>> - November 14: branch 1.4.x >>>> - November 17: rc1 >>>> - December 1: rc2 (if needed) >>>> - December 10: final release >>>> >>> >>> Sounds good to me. >>> >>>> >>>> The arrival of Python 3.8 and simultaneous responsibility to get at >>>> least one more 1.2.x LTS Python 2.7 release out the door means things will >>>> probably be busy on the release front until 2020. >>>> >>> >>> True. I think supporting 3.8 is fairly high-prio, there's a lot of >>> demand for it. Doing a 1.3.2 release that supports it would make sense I >>> guess. >>> >>> There don't seem to be any new commits on the 1.2.x branch nor urgent >>> Python 2.7 fixes that need to go out. So do we need a 1.2.3 release? >>> >>> Cheers, >>> Ralf >>> >>> >>> >>>> As always, it is a good idea to start tagging things that should be in >>>> 1.4.0 & please do help with reviewing PRs/issues that are tagged--current >>>> counts are: >>>> >>>> - PRs: 40 open with 1.4.0 milestone >>>> - issues: 17 open with 1.4.0 milestone >>>> >>>> While helping with that, also great if the release notes wiki is >>>> updated for appropriate changes: >>>> https://github.com/scipy/scipy/wiki/Release-note-entries-for-SciPy-1.4.0 >>>> >>>> Curating those final notes can be painful if the wiki isn't updated. >>>> >>>> Thoughts/objections for the schedule? >>>> >>>> Best wishes, >>>> Tyler >>>> _______________________________________________ >>>> 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 >>> >> >> >> -- >> Matt Haberland >> Assistant Adjunct Professor in the Program in Computing >> Department of Mathematics >> 6617A Math Sciences Building, UCLA >> _______________________________________________ >> 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 Tue Nov 12 19:10:27 2019 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Tue, 12 Nov 2019 16:10:27 -0800 Subject: [SciPy-Dev] [Numpy-discussion] ANN: SciPy 1.3.2 In-Reply-To: References: Message-ID: On Sat, Nov 9, 2019 at 2:31 PM Evgeni Burovski wrote: > Thanks Tyler for managing this release! > +1 thanks Tyler! > On Sun, Nov 10, 2019 at 1:10 AM Tyler Reddy > wrote: > > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA256 > > > > Hi all, > > > > On behalf of the SciPy development team I'm pleased to announce > > the release of SciPy 1.3.2, a maintenance and bug fix release that > > adds support for Python 3.8. > > > > Sources and binary wheels can be found at: > > https://pypi.org/project/scipy/ > > and at: https://github.com/scipy/scipy/releases/tag/v1.3.2 > Conda-forge builds are also available. Also worth mentioning is that for the very first time there's a Windows conda-forge package (Python 3.8 only)! Cheers, Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From koumura at cycentum.com Wed Nov 13 00:04:46 2019 From: koumura at cycentum.com (Takuya Koumura) Date: Wed, 13 Nov 2019 14:04:46 +0900 Subject: [SciPy-Dev] Adding logsoftmax function to scipy.special Message-ID: Hello, I raised a GitHub issue (#11058) and was suggested to post it to scipy-dev. I?m considering to send a PR to add logsoftmax function in scipy.special. Before that, I would like to hear your opinion (partly because it?s my first time to send a PR to scipy). I would like to implement logsoftmax(x) as x-logsumexp(x). Actually, special.softmax(x) = np.exp(x-logsumexp(x)), so it is trivial for those who read the source code of softmax, but I think including logsoftmax as a separate function will be useful for other users. Logsoftmax is more accurate with inputs that make softmax saturate, eg: When x=[1000, 0], np.log(softmax(x))=[0, -Inf] (maybe depending on the floating point precision), while logsoftmax(x)=[0, -1000]. I am planning to add the new function at the bottom of special/_logsumexp.py following the softmax function, and add some unit tests in special/test/test_logsumexp.py. If you have comments, I?d appreciate any. Best wishes, -- Takuya KOUMURA koumura at cycentum.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.gommers at gmail.com Wed Nov 13 22:20:45 2019 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Wed, 13 Nov 2019 19:20:45 -0800 Subject: [SciPy-Dev] Proposed SciPy 1.4.0 Release Schedule In-Reply-To: References: Message-ID: Hi Tyler, are you still planning to branch 1.4.x tomorrow? It looks like there's no real blockers, but there's a bunch of stuff that people seem to be scrambling to get in, so perhaps a 24-48 hour bump could be useful. Cheers, Ralf On Tue, Nov 12, 2019 at 8:31 AM Tyler Reddy wrote: > Down to 12 open PRs with 1.4.0 milestone--getting closer! > > On Sat, 9 Nov 2019 at 21:40, Tyler Reddy wrote: > >> We currently sit at 31 open PRs and 20 open issues with 1.4.0 milestone. >> >> That's a substantial drop in PRs but a rise in issues since the last >> accounting. Things got >> a little hectic with Python 3.8 for 1.3.2, but hopefully the wheels stuff >> is in good shape >> for 1.4.x series now. >> >> Branching in about 5 days is ambitious, but let's aim to stay reasonably >> on track if possible. >> >> On Mon, 21 Oct 2019 at 13:39, Matt Haberland wrote: >> >>> Re: 1.2.3 release, I did get a request in gh-10915 >>> for gh-10498 >>> to be backported to 1.2. >>> >>> On Mon, Oct 21, 2019 at 8:47 AM Ralf Gommers >>> wrote: >>> >>>> >>>> >>>> On Sat, Oct 19, 2019 at 12:24 AM Tyler Reddy >>>> wrote: >>>> >>>>> Hi, >>>>> >>>>> SciPy 1.3.0 was released May 17 (5 months ago), and I think we'd like >>>>> to keep a roughly biannual release cadence. >>>>> >>>>> I'd like to propose the following schedule for 1.4.0: >>>>> - November 14: branch 1.4.x >>>>> - November 17: rc1 >>>>> - December 1: rc2 (if needed) >>>>> - December 10: final release >>>>> >>>> >>>> Sounds good to me. >>>> >>>>> >>>>> The arrival of Python 3.8 and simultaneous responsibility to get at >>>>> least one more 1.2.x LTS Python 2.7 release out the door means things will >>>>> probably be busy on the release front until 2020. >>>>> >>>> >>>> True. I think supporting 3.8 is fairly high-prio, there's a lot of >>>> demand for it. Doing a 1.3.2 release that supports it would make sense I >>>> guess. >>>> >>>> There don't seem to be any new commits on the 1.2.x branch nor urgent >>>> Python 2.7 fixes that need to go out. So do we need a 1.2.3 release? >>>> >>>> Cheers, >>>> Ralf >>>> >>>> >>>> >>>>> As always, it is a good idea to start tagging things that should be in >>>>> 1.4.0 & please do help with reviewing PRs/issues that are tagged--current >>>>> counts are: >>>>> >>>>> - PRs: 40 open with 1.4.0 milestone >>>>> - issues: 17 open with 1.4.0 milestone >>>>> >>>>> While helping with that, also great if the release notes wiki is >>>>> updated for appropriate changes: >>>>> https://github.com/scipy/scipy/wiki/Release-note-entries-for-SciPy-1.4.0 >>>>> >>>>> Curating those final notes can be painful if the wiki isn't updated. >>>>> >>>>> Thoughts/objections for the schedule? >>>>> >>>>> Best wishes, >>>>> Tyler >>>>> _______________________________________________ >>>>> 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 >>>> >>> >>> >>> -- >>> Matt Haberland >>> Assistant Adjunct Professor in the Program in Computing >>> Department of Mathematics >>> 6617A Math Sciences Building, UCLA >>> _______________________________________________ >>> 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 tyler.je.reddy at gmail.com Wed Nov 13 22:35:30 2019 From: tyler.je.reddy at gmail.com (Tyler Reddy) Date: Wed, 13 Nov 2019 20:35:30 -0700 Subject: [SciPy-Dev] Proposed SciPy 1.4.0 Release Schedule In-Reply-To: References: Message-ID: Alright, shall we aim for a two-day bump on the branching to Nov. 16th (Saturday)? I see we're at ~8 PRs with the milestone now, but I also still have to work on release notes, etc. I'm also expecting one or two surprises to pop up in the wheels repo given major release + 3.8. On Wed, 13 Nov 2019 at 20:21, Ralf Gommers wrote: > Hi Tyler, are you still planning to branch 1.4.x tomorrow? It looks like > there's no real blockers, but there's a bunch of stuff that people seem to > be scrambling to get in, so perhaps a 24-48 hour bump could be useful. > > Cheers, > Ralf > > > On Tue, Nov 12, 2019 at 8:31 AM Tyler Reddy > wrote: > >> Down to 12 open PRs with 1.4.0 milestone--getting closer! >> >> On Sat, 9 Nov 2019 at 21:40, Tyler Reddy >> wrote: >> >>> We currently sit at 31 open PRs and 20 open issues with 1.4.0 milestone. >>> >>> That's a substantial drop in PRs but a rise in issues since the last >>> accounting. Things got >>> a little hectic with Python 3.8 for 1.3.2, but hopefully the wheels >>> stuff is in good shape >>> for 1.4.x series now. >>> >>> Branching in about 5 days is ambitious, but let's aim to stay reasonably >>> on track if possible. >>> >>> On Mon, 21 Oct 2019 at 13:39, Matt Haberland wrote: >>> >>>> Re: 1.2.3 release, I did get a request in gh-10915 >>>> for gh-10498 >>>> to be backported to 1.2. >>>> >>>> On Mon, Oct 21, 2019 at 8:47 AM Ralf Gommers >>>> wrote: >>>> >>>>> >>>>> >>>>> On Sat, Oct 19, 2019 at 12:24 AM Tyler Reddy >>>>> wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> SciPy 1.3.0 was released May 17 (5 months ago), and I think we'd like >>>>>> to keep a roughly biannual release cadence. >>>>>> >>>>>> I'd like to propose the following schedule for 1.4.0: >>>>>> - November 14: branch 1.4.x >>>>>> - November 17: rc1 >>>>>> - December 1: rc2 (if needed) >>>>>> - December 10: final release >>>>>> >>>>> >>>>> Sounds good to me. >>>>> >>>>>> >>>>>> The arrival of Python 3.8 and simultaneous responsibility to get at >>>>>> least one more 1.2.x LTS Python 2.7 release out the door means things will >>>>>> probably be busy on the release front until 2020. >>>>>> >>>>> >>>>> True. I think supporting 3.8 is fairly high-prio, there's a lot of >>>>> demand for it. Doing a 1.3.2 release that supports it would make sense I >>>>> guess. >>>>> >>>>> There don't seem to be any new commits on the 1.2.x branch nor urgent >>>>> Python 2.7 fixes that need to go out. So do we need a 1.2.3 release? >>>>> >>>>> Cheers, >>>>> Ralf >>>>> >>>>> >>>>> >>>>>> As always, it is a good idea to start tagging things that should be >>>>>> in 1.4.0 & please do help with reviewing PRs/issues that are >>>>>> tagged--current counts are: >>>>>> >>>>>> - PRs: 40 open with 1.4.0 milestone >>>>>> - issues: 17 open with 1.4.0 milestone >>>>>> >>>>>> While helping with that, also great if the release notes wiki is >>>>>> updated for appropriate changes: >>>>>> https://github.com/scipy/scipy/wiki/Release-note-entries-for-SciPy-1.4.0 >>>>>> >>>>>> Curating those final notes can be painful if the wiki isn't updated. >>>>>> >>>>>> Thoughts/objections for the schedule? >>>>>> >>>>>> Best wishes, >>>>>> Tyler >>>>>> _______________________________________________ >>>>>> 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 >>>>> >>>> >>>> >>>> -- >>>> Matt Haberland >>>> Assistant Adjunct Professor in the Program in Computing >>>> Department of Mathematics >>>> 6617A Math Sciences Building, UCLA >>>> _______________________________________________ >>>> 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 ralf.gommers at gmail.com Wed Nov 13 23:27:18 2019 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Wed, 13 Nov 2019 20:27:18 -0800 Subject: [SciPy-Dev] Proposed SciPy 1.4.0 Release Schedule In-Reply-To: References: Message-ID: On Wed, Nov 13, 2019 at 7:35 PM Tyler Reddy wrote: > Alright, shall we aim for a two-day bump on the branching to Nov. 16th > (Saturday)? I see we're at ~8 PRs with the milestone now, but I also still > have to work on release notes, etc. > Thanks, that sounds good! > I'm also expecting one or two surprises to pop up in the wheels repo given > major release + 3.8. > > On Wed, 13 Nov 2019 at 20:21, Ralf Gommers wrote: > >> Hi Tyler, are you still planning to branch 1.4.x tomorrow? It looks like >> there's no real blockers, but there's a bunch of stuff that people seem to >> be scrambling to get in, so perhaps a 24-48 hour bump could be useful. >> >> Cheers, >> Ralf >> >> >> On Tue, Nov 12, 2019 at 8:31 AM Tyler Reddy >> wrote: >> >>> Down to 12 open PRs with 1.4.0 milestone--getting closer! >>> >>> On Sat, 9 Nov 2019 at 21:40, Tyler Reddy >>> wrote: >>> >>>> We currently sit at 31 open PRs and 20 open issues with 1.4.0 milestone. >>>> >>>> That's a substantial drop in PRs but a rise in issues since the last >>>> accounting. Things got >>>> a little hectic with Python 3.8 for 1.3.2, but hopefully the wheels >>>> stuff is in good shape >>>> for 1.4.x series now. >>>> >>>> Branching in about 5 days is ambitious, but let's aim to stay >>>> reasonably on track if possible. >>>> >>>> On Mon, 21 Oct 2019 at 13:39, Matt Haberland >>>> wrote: >>>> >>>>> Re: 1.2.3 release, I did get a request in gh-10915 >>>>> for gh-10498 >>>>> to be backported to 1.2. >>>>> >>>>> On Mon, Oct 21, 2019 at 8:47 AM Ralf Gommers >>>>> wrote: >>>>> >>>>>> >>>>>> >>>>>> On Sat, Oct 19, 2019 at 12:24 AM Tyler Reddy < >>>>>> tyler.je.reddy at gmail.com> wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> SciPy 1.3.0 was released May 17 (5 months ago), and I think we'd >>>>>>> like to keep a roughly biannual release cadence. >>>>>>> >>>>>>> I'd like to propose the following schedule for 1.4.0: >>>>>>> - November 14: branch 1.4.x >>>>>>> - November 17: rc1 >>>>>>> - December 1: rc2 (if needed) >>>>>>> - December 10: final release >>>>>>> >>>>>> >>>>>> Sounds good to me. >>>>>> >>>>>>> >>>>>>> The arrival of Python 3.8 and simultaneous responsibility to get at >>>>>>> least one more 1.2.x LTS Python 2.7 release out the door means things will >>>>>>> probably be busy on the release front until 2020. >>>>>>> >>>>>> >>>>>> True. I think supporting 3.8 is fairly high-prio, there's a lot of >>>>>> demand for it. Doing a 1.3.2 release that supports it would make sense I >>>>>> guess. >>>>>> >>>>>> There don't seem to be any new commits on the 1.2.x branch nor urgent >>>>>> Python 2.7 fixes that need to go out. So do we need a 1.2.3 release? >>>>>> >>>>>> Cheers, >>>>>> Ralf >>>>>> >>>>>> >>>>>> >>>>>>> As always, it is a good idea to start tagging things that should be >>>>>>> in 1.4.0 & please do help with reviewing PRs/issues that are >>>>>>> tagged--current counts are: >>>>>>> >>>>>>> - PRs: 40 open with 1.4.0 milestone >>>>>>> - issues: 17 open with 1.4.0 milestone >>>>>>> >>>>>>> While helping with that, also great if the release notes wiki is >>>>>>> updated for appropriate changes: >>>>>>> https://github.com/scipy/scipy/wiki/Release-note-entries-for-SciPy-1.4.0 >>>>>>> >>>>>>> Curating those final notes can be painful if the wiki isn't updated. >>>>>>> >>>>>>> Thoughts/objections for the schedule? >>>>>>> >>>>>>> Best wishes, >>>>>>> Tyler >>>>>>> _______________________________________________ >>>>>>> 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 >>>>>> >>>>> >>>>> >>>>> -- >>>>> Matt Haberland >>>>> Assistant Adjunct Professor in the Program in Computing >>>>> Department of Mathematics >>>>> 6617A Math Sciences Building, UCLA >>>>> _______________________________________________ >>>>> 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 ralf.gommers at gmail.com Thu Nov 14 06:42:10 2019 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Thu, 14 Nov 2019 03:42:10 -0800 Subject: [SciPy-Dev] Allow specifying inverse-variance matrix to multivariate_normal (scipy.stats) In-Reply-To: References: Message-ID: On Tue, Nov 12, 2019 at 7:29 AM Adrian Price-Whelan wrote: > Hi all -- > > scipy.stats.multivariate_normal currently accepts a mean and > covariance matrix, and always computes the inverse-variance matrix > internally and explicitly. But I often have covariance matrices with > inverses that can be computed through other linear algebra tricks or > identities. It would therefore be great if > scipy.stats.multivariate_normal would allow optionally passing in an > inverse-variance matrix, which is sometimes useful for (a) > performance, or (b) numerical precision issues with covariance > matrices with large values. To be clear: I'm just suggesting that the > MVN distribution could accept an inverse-variance matrix to bypass the > inverse calculation, I'm not suggesting implementing or supporting > linear algebra identities. > > To get around this in the past, e.g., to compute the log-PDF values at > some positions, I've typically implemented by own custom function, or > have used the implementation in astroML > (https://github.com/astroML/astroML/blob/master/astroML/utils/utils.py#L22 > ). > It would be nice to have this supported in scipy directly! > > Thoughts? > This sounds like a potentially useful change. It just adds one keyword to the six public methods, and there's similar changes we make in other functions for performance or accuracy reasons. So go for it I'd say. Cheers, Ralf > (Note: I made an issue for this idea, but was told to start discussion > here instead https://github.com/scipy/scipy/issues/11053) > > best, > - adrian > > -- > Adrian M. Price-Whelan > Flatiron Institute, NYC > http://adrn.github.io > _______________________________________________ > 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 reed at cs.unc.edu Fri Nov 15 16:00:45 2019 From: reed at cs.unc.edu (Andrew Reed) Date: Fri, 15 Nov 2019 16:00:45 -0500 Subject: [SciPy-Dev] Optimization to stats.dlaplace.rvs Message-ID: All, Some of you may have seen a message I sent to the NumPy mailing list about adding a two-sided geometric distribution and/or the comments to my PR on Github: https://mail.python.org/pipermail/numpy-discussion/2019-November/080223.html https://github.com/numpy/numpy/pull/14890 Bottom line, rather than add it as a distribution to NumPy, it was suggested that I look into adding it to stats.dlaplace.rvs (which currently uses the inverted CDF) and I was provided with some code to get me started. I have been able to add the suggested code, with only minor tweaks, to SciPy. A few tests with timeit seem to confirm that the new code provides a speedup of about 250% on my machine. Furthermore, the default rvs function would get killed when I tried to generate 100 million samples, whereas this new code can generate at least 100 million samples (I get a MemoryError on my VM when I try to go any higher). I think I'm at the point now where I need to start working through some broadcasting errors, but before I do, I wanted to gauge the potential interest in these improvements. I imagine that implementing a new method for rvs will probability break the repeatability of previous versions of SciPy, and I'm not sure if this is a distribution that warrants optimization. Thanks, Andrew -------------- next part -------------- An HTML attachment was scrubbed... URL: From evgeny.burovskiy at gmail.com Fri Nov 15 17:06:23 2019 From: evgeny.burovskiy at gmail.com (Evgeni Burovski) Date: Sat, 16 Nov 2019 01:06:23 +0300 Subject: [SciPy-Dev] Optimization to stats.dlaplace.rvs In-Reply-To: References: Message-ID: Yes, an efficient implementation of dlaplace._rvs would be in scope, I'd think. ??, 16 ????. 2019 ?., 0:01 Andrew Reed : > All, > > Some of you may have seen a message I sent to the NumPy mailing list about > adding a two-sided geometric distribution and/or the comments to my PR on > Github: > > https://mail.python.org/pipermail/numpy-discussion/2019-November/080223.html > https://github.com/numpy/numpy/pull/14890 > > Bottom line, rather than add it as a distribution to NumPy, it was > suggested that I look into adding it to stats.dlaplace.rvs (which currently > uses the inverted CDF) and I was provided with some code to get me started. > > I have been able to add the suggested code, with only minor tweaks, to > SciPy. A few tests with timeit seem to confirm that the new code provides > a speedup of about 250% on my machine. Furthermore, the default rvs > function would get killed when I tried to generate 100 million samples, > whereas this new code can generate at least 100 million samples (I get a > MemoryError on my VM when I try to go any higher). > > I think I'm at the point now where I need to start working through some > broadcasting errors, but before I do, I wanted to gauge the potential > interest in these improvements. > > I imagine that implementing a new method for rvs will probability break > the repeatability of previous versions of SciPy, and I'm not sure if this > is a distribution that warrants optimization. > > Thanks, > Andrew > > _______________________________________________ > 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 robert.kern at gmail.com Fri Nov 15 17:13:44 2019 From: robert.kern at gmail.com (Robert Kern) Date: Fri, 15 Nov 2019 17:13:44 -0500 Subject: [SciPy-Dev] Optimization to stats.dlaplace.rvs In-Reply-To: References: Message-ID: On Fri, Nov 15, 2019 at 4:01 PM Andrew Reed wrote > I imagine that implementing a new method for rvs will probability break > the repeatability of previous versions of SciPy, and I'm not sure if this > is a distribution that warrants optimization. > I don't think we've ever made such guarantees for the `rvs()` distribution methods. In any case, moving from the inefficient default inversion to a reasonably efficient sampling algorithm would win the argument over stability. Tweaking an existing efficient algorithm, maybe you could argue more in favor of stability, but as you point out, this is a GO/NO-GO kind of improvement. -- Robert Kern -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.gommers at gmail.com Fri Nov 15 20:16:35 2019 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Fri, 15 Nov 2019 17:16:35 -0800 Subject: [SciPy-Dev] Adding logsoftmax function to scipy.special In-Reply-To: References: Message-ID: Hi Takuya, On Tue, Nov 12, 2019 at 9:05 PM Takuya Koumura wrote: > Hello, > > I raised a GitHub issue (#11058) and was suggested to post it to scipy-dev. > > I?m considering to send a PR to add logsoftmax function in scipy.special. > Before that, I would like to hear your opinion (partly because it?s my > first time to send a PR to scipy). > Welcome! Thanks for proposing that. logsoftmax is fairly popular at least in deep learning, so it makes sense I think, and we already have a bunch of other log* functions in scipy.special. I noticed that both PyTorch and Tensorflow name this function `log_softmax` rather than `logsoftmax`. The latter would be a little more consistent with other functions (although we also have `special.log_ndtr`), while the former is consistent with other implementations of the same functionality. I'd be okay with either, with a slight preference for `log_softmax`. > I would like to implement logsoftmax(x) as x-logsumexp(x). Actually, > special.softmax(x) = np.exp(x-logsumexp(x)), so it is trivial for those who > read the source code of softmax, but I think including logsoftmax as a > separate function will be useful for other users. Logsoftmax is more > accurate with inputs that make softmax saturate, eg: When x=[1000, 0], > np.log(softmax(x))=[0, -Inf] (maybe depending on the floating point > precision), while logsoftmax(x)=[0, -1000]. > > I am planning to add the new function at the bottom of > special/_logsumexp.py following the softmax function, and add some unit > tests in special/test/test_logsumexp.py. If you have comments, I?d > appreciate any. > That seems like a good place. Cheers, Ralf > Best wishes, > -- > Takuya KOUMURA > koumura at cycentum.com > _______________________________________________ > 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 rlucas7 at vt.edu Fri Nov 15 20:54:33 2019 From: rlucas7 at vt.edu (rlucas7 at vt.edu) Date: Fri, 15 Nov 2019 20:54:33 -0500 Subject: [SciPy-Dev] SciPy-Dev Digest, Vol 193, Issue 12 In-Reply-To: References: Message-ID: <6311BBDE-11D3-491B-A5F3-0FA4383898FD@vt.edu> > On Fri, Nov 15, 2019 at 4:01 PM Andrew Reed wrote > >> I imagine that implementing a new method for rvs will probability break >> the repeatability of previous versions of SciPy, and I'm not sure if this >> is a distribution that warrants optimization. >> > > I don't think we've ever made such guarantees for the `rvs()` distribution > methods. In any case, moving from the inefficient default inversion to a > reasonably efficient sampling algorithm would win the argument over > stability. Not sure the implementation and probably would still want to ?check? some extreme parameter cases to make sure things don?t break down because of numerical over/underflow-at least not more than current. I think the rvs() method unit tests have an assumption of A single uniform draw for each sampled value in the unit tests. If you are using something like the difference of 2 exponential random variables with the same rate/scale you?ll need to turn off the tests IIRC. Last I checked there are some existing examples of that in the tests. Hope it helps. -Lucas Roberts > On Nov 15, 2019, at 8:17 PM, scipy-dev-request at python.org wrote: > > ?Send SciPy-Dev mailing list submissions to > scipy-dev at python.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://mail.python.org/mailman/listinfo/scipy-dev > or, via email, send a message with subject or body 'help' to > scipy-dev-request at python.org > > You can reach the person managing the list at > scipy-dev-owner at python.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of SciPy-Dev digest..." > > > Today's Topics: > > 1. Optimization to stats.dlaplace.rvs (Andrew Reed) > 2. Re: Optimization to stats.dlaplace.rvs (Evgeni Burovski) > 3. Re: Optimization to stats.dlaplace.rvs (Robert Kern) > 4. Re: Adding logsoftmax function to scipy.special (Ralf Gommers) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 15 Nov 2019 16:00:45 -0500 > From: Andrew Reed > To: scipy-dev at python.org > Subject: [SciPy-Dev] Optimization to stats.dlaplace.rvs > Message-ID: > > Content-Type: text/plain; charset="utf-8" > > All, > > Some of you may have seen a message I sent to the NumPy mailing list about > adding a two-sided geometric distribution and/or the comments to my PR on > Github: > https://mail.python.org/pipermail/numpy-discussion/2019-November/080223.html > https://github.com/numpy/numpy/pull/14890 > > Bottom line, rather than add it as a distribution to NumPy, it was > suggested that I look into adding it to stats.dlaplace.rvs (which currently > uses the inverted CDF) and I was provided with some code to get me started. > > I have been able to add the suggested code, with only minor tweaks, to > SciPy. A few tests with timeit seem to confirm that the new code provides > a speedup of about 250% on my machine. Furthermore, the default rvs > function would get killed when I tried to generate 100 million samples, > whereas this new code can generate at least 100 million samples (I get a > MemoryError on my VM when I try to go any higher). > > I think I'm at the point now where I need to start working through some > broadcasting errors, but before I do, I wanted to gauge the potential > interest in these improvements. > > I imagine that implementing a new method for rvs will probability break the > repeatability of previous versions of SciPy, and I'm not sure if this is a > distribution that warrants optimization. > > Thanks, > Andrew > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > ------------------------------ > > Message: 2 > Date: Sat, 16 Nov 2019 01:06:23 +0300 > From: Evgeni Burovski > To: SciPy Developers List > Subject: Re: [SciPy-Dev] Optimization to stats.dlaplace.rvs > Message-ID: > > Content-Type: text/plain; charset="utf-8" > > Yes, an efficient implementation of dlaplace._rvs would be in scope, I'd > think. > > ??, 16 ????. 2019 ?., 0:01 Andrew Reed : > >> All, >> >> Some of you may have seen a message I sent to the NumPy mailing list about >> adding a two-sided geometric distribution and/or the comments to my PR on >> Github: >> >> https://mail.python.org/pipermail/numpy-discussion/2019-November/080223.html >> https://github.com/numpy/numpy/pull/14890 >> >> Bottom line, rather than add it as a distribution to NumPy, it was >> suggested that I look into adding it to stats.dlaplace.rvs (which currently >> uses the inverted CDF) and I was provided with some code to get me started. >> >> I have been able to add the suggested code, with only minor tweaks, to >> SciPy. A few tests with timeit seem to confirm that the new code provides >> a speedup of about 250% on my machine. Furthermore, the default rvs >> function would get killed when I tried to generate 100 million samples, >> whereas this new code can generate at least 100 million samples (I get a >> MemoryError on my VM when I try to go any higher). >> >> I think I'm at the point now where I need to start working through some >> broadcasting errors, but before I do, I wanted to gauge the potential >> interest in these improvements. >> >> I imagine that implementing a new method for rvs will probability break >> the repeatability of previous versions of SciPy, and I'm not sure if this >> is a distribution that warrants optimization. >> >> Thanks, >> Andrew >> >> _______________________________________________ >> 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: > > ------------------------------ > > Message: 3 > Date: Fri, 15 Nov 2019 17:13:44 -0500 > From: Robert Kern > To: SciPy Developers List > Subject: Re: [SciPy-Dev] Optimization to stats.dlaplace.rvs > Message-ID: > > Content-Type: text/plain; charset="utf-8" > > On Fri, Nov 15, 2019 at 4:01 PM Andrew Reed wrote > >> I imagine that implementing a new method for rvs will probability break >> the repeatability of previous versions of SciPy, and I'm not sure if this >> is a distribution that warrants optimization. >> > > I don't think we've ever made such guarantees for the `rvs()` distribution > methods. In any case, moving from the inefficient default inversion to a > reasonably efficient sampling algorithm would win the argument over > stability. Tweaking an existing efficient algorithm, maybe you could argue > more in favor of stability, but as you point out, this is a GO/NO-GO kind > of improvement. > > -- > Robert Kern > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > ------------------------------ > > Message: 4 > Date: Fri, 15 Nov 2019 17:16:35 -0800 > From: Ralf Gommers > To: SciPy Developers List > Subject: Re: [SciPy-Dev] Adding logsoftmax function to scipy.special > Message-ID: > > Content-Type: text/plain; charset="utf-8" > > Hi Takuya, > > >> On Tue, Nov 12, 2019 at 9:05 PM Takuya Koumura wrote: >> >> Hello, >> >> I raised a GitHub issue (#11058) and was suggested to post it to scipy-dev. >> >> I?m considering to send a PR to add logsoftmax function in scipy.special. >> Before that, I would like to hear your opinion (partly because it?s my >> first time to send a PR to scipy). >> > > Welcome! Thanks for proposing that. logsoftmax is fairly popular at least > in deep learning, so it makes sense I think, and we already have a bunch of > other log* functions in scipy.special. > > I noticed that both PyTorch and Tensorflow name this function `log_softmax` > rather than `logsoftmax`. The latter would be a little more consistent with > other functions (although we also have `special.log_ndtr`), while the > former is consistent with other implementations of the same functionality. > I'd be okay with either, with a slight preference for `log_softmax`. > > >> I would like to implement logsoftmax(x) as x-logsumexp(x). Actually, >> special.softmax(x) = np.exp(x-logsumexp(x)), so it is trivial for those who >> read the source code of softmax, but I think including logsoftmax as a >> separate function will be useful for other users. Logsoftmax is more >> accurate with inputs that make softmax saturate, eg: When x=[1000, 0], >> np.log(softmax(x))=[0, -Inf] (maybe depending on the floating point >> precision), while logsoftmax(x)=[0, -1000]. >> >> I am planning to add the new function at the bottom of >> special/_logsumexp.py following the softmax function, and add some unit >> tests in special/test/test_logsumexp.py. If you have comments, I?d >> appreciate any. >> > > That seems like a good place. > > Cheers, > Ralf > > >> Best wishes, >> -- >> Takuya KOUMURA >> koumura at cycentum.com >> _______________________________________________ >> 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: > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at python.org > https://mail.python.org/mailman/listinfo/scipy-dev > > > ------------------------------ > > End of SciPy-Dev Digest, Vol 193, Issue 12 > ****************************************** From robert.kern at gmail.com Fri Nov 15 22:17:53 2019 From: robert.kern at gmail.com (Robert Kern) Date: Fri, 15 Nov 2019 22:17:53 -0500 Subject: [SciPy-Dev] SciPy-Dev Digest, Vol 193, Issue 12 In-Reply-To: <6311BBDE-11D3-491B-A5F3-0FA4383898FD@vt.edu> References: <6311BBDE-11D3-491B-A5F3-0FA4383898FD@vt.edu> Message-ID: On Fri, Nov 15, 2019 at 10:03 PM wrote: > > On Fri, Nov 15, 2019 at 4:01 PM Andrew Reed wrote > > > >> I imagine that implementing a new method for rvs will probability break > >> the repeatability of previous versions of SciPy, and I'm not sure if > this > >> is a distribution that warrants optimization. > >> > > > > I don't think we've ever made such guarantees for the `rvs()` > distribution > > methods. In any case, moving from the inefficient default inversion to a > > reasonably efficient sampling algorithm would win the argument over > > stability. > > Not sure the implementation and probably would still want to ?check? some > extreme parameter cases to make sure things don?t break down because of > numerical over/underflow-at least not more than current. > > I think the rvs() method unit tests have an assumption of A single uniform > draw for each sampled value in the unit tests. If you are using something > like the difference of 2 exponential random variables with the same > rate/scale you?ll need to turn off the tests IIRC. Last I checked there are > some existing examples of that in the tests. > I'm not sure what you are referring to. Can you show me an example of that? That's certainly not a restriction the rvs() methods obey, so a unit test expecting that is incorrect and should be fixed. -- Robert Kern -------------- next part -------------- An HTML attachment was scrubbed... URL: From warren.weckesser at gmail.com Fri Nov 15 22:54:41 2019 From: warren.weckesser at gmail.com (Warren Weckesser) Date: Fri, 15 Nov 2019 22:54:41 -0500 Subject: [SciPy-Dev] SciPy-Dev Digest, Vol 193, Issue 12 In-Reply-To: References: <6311BBDE-11D3-491B-A5F3-0FA4383898FD@vt.edu> Message-ID: On 11/15/19, Robert Kern wrote: > On Fri, Nov 15, 2019 at 10:03 PM wrote: > >> > On Fri, Nov 15, 2019 at 4:01 PM Andrew Reed wrote >> > >> >> I imagine that implementing a new method for rvs will probability >> >> break >> >> the repeatability of previous versions of SciPy, and I'm not sure if >> this >> >> is a distribution that warrants optimization. >> >> >> > >> > I don't think we've ever made such guarantees for the `rvs()` >> distribution >> > methods. In any case, moving from the inefficient default inversion to >> > a >> > reasonably efficient sampling algorithm would win the argument over >> > stability. >> >> Not sure the implementation and probably would still want to ?check? some >> extreme parameter cases to make sure things don?t break down because of >> numerical over/underflow-at least not more than current. >> >> I think the rvs() method unit tests have an assumption of A single >> uniform >> draw for each sampled value in the unit tests. If you are using something >> like the difference of 2 exponential random variables with the same >> rate/scale you?ll need to turn off the tests IIRC. Last I checked there >> are >> some existing examples of that in the tests. >> > > I'm not sure what you are referring to. Can you show me an example of that? > That's certainly not a restriction the rvs() methods obey, so a unit test > expecting that is incorrect and should be fixed. I think Lucas is referring to this test of broadcasting in the rvs() method: https://github.com/scipy/scipy/blob/master/scipy/stats/tests/test_continuous_basic.py#L253 This test was added when I worked on ensuring that all the rvs() methods correctly broadcast their arguments. For many distributions, this test was a simple way to verify that broadcasting was working correctly. The comment in the test explains the context. For distributions that use just one random value from the underlying numpy random generator per call to rvs(), the test checks that a call using broadcasting returns the same result as calling the result of vectorizing rvs() using numpy.vectorize. As explained in the comment, distributions for which that assumption is not true must be included in the list that defines the boolean variable 'shape_only' in the test. (For these, just the shape of the result is checked, not the actual values.) There is no *general* assumption that rvs() must use just one random variate from the numpy generator, and (as explained in the comment) there is no expectation that an rvs() method that uses one random variate now can't be changed to use more later. Just update the test if such a change is made. Warren > > -- > Robert Kern > From robert.kern at gmail.com Fri Nov 15 23:16:21 2019 From: robert.kern at gmail.com (Robert Kern) Date: Fri, 15 Nov 2019 23:16:21 -0500 Subject: [SciPy-Dev] SciPy-Dev Digest, Vol 193, Issue 12 In-Reply-To: References: <6311BBDE-11D3-491B-A5F3-0FA4383898FD@vt.edu> Message-ID: On Fri, Nov 15, 2019 at 10:55 PM Warren Weckesser < warren.weckesser at gmail.com> wrote: > On 11/15/19, Robert Kern wrote: > > On Fri, Nov 15, 2019 at 10:03 PM wrote: > > > >> > On Fri, Nov 15, 2019 at 4:01 PM Andrew Reed wrote > >> > > >> >> I imagine that implementing a new method for rvs will probability > >> >> break > >> >> the repeatability of previous versions of SciPy, and I'm not sure if > >> this > >> >> is a distribution that warrants optimization. > >> >> > >> > > >> > I don't think we've ever made such guarantees for the `rvs()` > >> distribution > >> > methods. In any case, moving from the inefficient default inversion to > >> > a > >> > reasonably efficient sampling algorithm would win the argument over > >> > stability. > >> > >> Not sure the implementation and probably would still want to ?check? > some > >> extreme parameter cases to make sure things don?t break down because of > >> numerical over/underflow-at least not more than current. > >> > >> I think the rvs() method unit tests have an assumption of A single > >> uniform > >> draw for each sampled value in the unit tests. If you are using > something > >> like the difference of 2 exponential random variables with the same > >> rate/scale you?ll need to turn off the tests IIRC. Last I checked there > >> are > >> some existing examples of that in the tests. > >> > > > > I'm not sure what you are referring to. Can you show me an example of > that? > > That's certainly not a restriction the rvs() methods obey, so a unit test > > expecting that is incorrect and should be fixed. > > > I think Lucas is referring to this test of broadcasting in the rvs() > method: > > > https://github.com/scipy/scipy/blob/master/scipy/stats/tests/test_continuous_basic.py#L253 > > This test was added when I worked on ensuring that all the rvs() > methods correctly broadcast their arguments. For many distributions, > this test was a simple way to verify that broadcasting was working > correctly. The comment in the test explains the context. For > distributions that use just one random value from the underlying numpy > random generator per call to rvs(), the test checks that a call using > broadcasting returns the same result as calling the result of > vectorizing rvs() using numpy.vectorize. As explained in the comment, > distributions for which that assumption is not true must be included > in the list that defines the boolean variable 'shape_only' in the > test. (For these, just the shape of the result is checked, not the > actual values.) There is no *general* assumption that rvs() must use > just one random variate from the numpy generator, and (as explained in > the comment) there is no expectation that an rvs() method that uses > one random variate now can't be changed to use more later. Just > update the test if such a change is made. > Ah, I see. I think the wording is a little confusing, since many of the RandomState distribution methods themselves draw more than one random value from the underlying PRNG to compute their result. This confusion may be limited to myself, though, since I wrote most of them and still think about them at that level. The restriction here seems more accurately (if less felicitously) phrased as "makes more than one RandomState method call". Because then their interleaving of PRNG draws won't match the interleaving that vectorize would do. I still don't really like that part of the test. I think that I would prefer that all distributions would be treated as "shape_only". Did it help us solve a bug once? -- Robert Kern -------------- next part -------------- An HTML attachment was scrubbed... URL: From warren.weckesser at gmail.com Sat Nov 16 00:06:57 2019 From: warren.weckesser at gmail.com (Warren Weckesser) Date: Sat, 16 Nov 2019 00:06:57 -0500 Subject: [SciPy-Dev] SciPy-Dev Digest, Vol 193, Issue 12 In-Reply-To: References: <6311BBDE-11D3-491B-A5F3-0FA4383898FD@vt.edu> Message-ID: On 11/15/19, Robert Kern wrote: > On Fri, Nov 15, 2019 at 10:55 PM Warren Weckesser < > warren.weckesser at gmail.com> wrote: > >> On 11/15/19, Robert Kern wrote: >> > On Fri, Nov 15, 2019 at 10:03 PM wrote: >> > >> >> > On Fri, Nov 15, 2019 at 4:01 PM Andrew Reed wrote >> >> > >> >> >> I imagine that implementing a new method for rvs will probability >> >> >> break >> >> >> the repeatability of previous versions of SciPy, and I'm not sure >> >> >> if >> >> this >> >> >> is a distribution that warrants optimization. >> >> >> >> >> > >> >> > I don't think we've ever made such guarantees for the `rvs()` >> >> distribution >> >> > methods. In any case, moving from the inefficient default inversion >> >> > to >> >> > a >> >> > reasonably efficient sampling algorithm would win the argument over >> >> > stability. >> >> >> >> Not sure the implementation and probably would still want to ?check? >> some >> >> extreme parameter cases to make sure things don?t break down because >> >> of >> >> numerical over/underflow-at least not more than current. >> >> >> >> I think the rvs() method unit tests have an assumption of A single >> >> uniform >> >> draw for each sampled value in the unit tests. If you are using >> something >> >> like the difference of 2 exponential random variables with the same >> >> rate/scale you?ll need to turn off the tests IIRC. Last I checked >> >> there >> >> are >> >> some existing examples of that in the tests. >> >> >> > >> > I'm not sure what you are referring to. Can you show me an example of >> that? >> > That's certainly not a restriction the rvs() methods obey, so a unit >> > test >> > expecting that is incorrect and should be fixed. >> >> >> I think Lucas is referring to this test of broadcasting in the rvs() >> method: >> >> >> https://github.com/scipy/scipy/blob/master/scipy/stats/tests/test_continuous_basic.py#L253 >> >> This test was added when I worked on ensuring that all the rvs() >> methods correctly broadcast their arguments. For many distributions, >> this test was a simple way to verify that broadcasting was working >> correctly. The comment in the test explains the context. For >> distributions that use just one random value from the underlying numpy >> random generator per call to rvs(), the test checks that a call using >> broadcasting returns the same result as calling the result of >> vectorizing rvs() using numpy.vectorize. As explained in the comment, >> distributions for which that assumption is not true must be included >> in the list that defines the boolean variable 'shape_only' in the >> test. (For these, just the shape of the result is checked, not the >> actual values.) There is no *general* assumption that rvs() must use >> just one random variate from the numpy generator, and (as explained in >> the comment) there is no expectation that an rvs() method that uses >> one random variate now can't be changed to use more later. Just >> update the test if such a change is made. >> > > Ah, I see. I think the wording is a little confusing, since many of the > RandomState distribution methods themselves draw more than one random value > from the underlying PRNG to compute their result. This confusion may be > limited to myself, though, since I wrote most of them and still think about > them at that level. The restriction here seems more accurately (if less > felicitously) phrased as "makes more than one RandomState method call". > Because then their interleaving of PRNG draws won't match the interleaving > that vectorize would do. Yes, that's a much better way to state the assumption. > > I still don't really like that part of the test. I think that I would > prefer that all distributions would be treated as "shape_only". Did it help > us solve a bug once? The original bug report (first reported in 2011): https://github.com/scipy/scipy/issues/2069 For some distributions, rvs() returned samples with the correct shape, but the random variates were not properly generated. Checking just the shape is a crude test; how does one verify that the parameter values were used correctly to generate the random variates? This test provided confidence that broadcasting was working correctly--at least for those distributions where the above assumption was true--without having to check the statistics of very large samples. Anyone interested in the history, including the discussion of this particular test, can browse the pull request: https://github.com/scipy/scipy/pull/5526. You'll see the comments where I first suggested that comparing the output of rvs() to the numpy.vectorize'd version would be a nice test, and shortly afterwards pointing out that it would not work for all the distributions. Warren > > -- > Robert Kern > From tyler.je.reddy at gmail.com Sat Nov 16 00:38:25 2019 From: tyler.je.reddy at gmail.com (Tyler Reddy) Date: Fri, 15 Nov 2019 22:38:25 -0700 Subject: [SciPy-Dev] Proposed SciPy 1.4.0 Release Schedule In-Reply-To: References: Message-ID: Please do take a look at the release notes in preparation for 1.4.0 branching: https://github.com/scipy/scipy/pull/11061 The number of pull requests is quite massive (347, I think), so it is a first draft, but I've transcribed the material from the wiki, made a no-doubt-controversial draft of release highlights, and tried to curate author names/mailmap based on the first round of contributor feedback (~144 authors vs. 97 for 1.3.0). On Wed, 13 Nov 2019 at 21:28, Ralf Gommers wrote: > > > On Wed, Nov 13, 2019 at 7:35 PM Tyler Reddy > wrote: > >> Alright, shall we aim for a two-day bump on the branching to Nov. 16th >> (Saturday)? I see we're at ~8 PRs with the milestone now, but I also still >> have to work on release notes, etc. >> > > Thanks, that sounds good! > > > >> I'm also expecting one or two surprises to pop up in the wheels repo >> given major release + 3.8. >> >> On Wed, 13 Nov 2019 at 20:21, Ralf Gommers >> wrote: >> >>> Hi Tyler, are you still planning to branch 1.4.x tomorrow? It looks like >>> there's no real blockers, but there's a bunch of stuff that people seem to >>> be scrambling to get in, so perhaps a 24-48 hour bump could be useful. >>> >>> Cheers, >>> Ralf >>> >>> >>> On Tue, Nov 12, 2019 at 8:31 AM Tyler Reddy >>> wrote: >>> >>>> Down to 12 open PRs with 1.4.0 milestone--getting closer! >>>> >>>> On Sat, 9 Nov 2019 at 21:40, Tyler Reddy >>>> wrote: >>>> >>>>> We currently sit at 31 open PRs and 20 open issues with 1.4.0 >>>>> milestone. >>>>> >>>>> That's a substantial drop in PRs but a rise in issues since the last >>>>> accounting. Things got >>>>> a little hectic with Python 3.8 for 1.3.2, but hopefully the wheels >>>>> stuff is in good shape >>>>> for 1.4.x series now. >>>>> >>>>> Branching in about 5 days is ambitious, but let's aim to stay >>>>> reasonably on track if possible. >>>>> >>>>> On Mon, 21 Oct 2019 at 13:39, Matt Haberland >>>>> wrote: >>>>> >>>>>> Re: 1.2.3 release, I did get a request in gh-10915 >>>>>> for gh-10498 >>>>>> to be backported to 1.2. >>>>>> >>>>>> On Mon, Oct 21, 2019 at 8:47 AM Ralf Gommers >>>>>> wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On Sat, Oct 19, 2019 at 12:24 AM Tyler Reddy < >>>>>>> tyler.je.reddy at gmail.com> wrote: >>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> SciPy 1.3.0 was released May 17 (5 months ago), and I think we'd >>>>>>>> like to keep a roughly biannual release cadence. >>>>>>>> >>>>>>>> I'd like to propose the following schedule for 1.4.0: >>>>>>>> - November 14: branch 1.4.x >>>>>>>> - November 17: rc1 >>>>>>>> - December 1: rc2 (if needed) >>>>>>>> - December 10: final release >>>>>>>> >>>>>>> >>>>>>> Sounds good to me. >>>>>>> >>>>>>>> >>>>>>>> The arrival of Python 3.8 and simultaneous responsibility to get at >>>>>>>> least one more 1.2.x LTS Python 2.7 release out the door means things will >>>>>>>> probably be busy on the release front until 2020. >>>>>>>> >>>>>>> >>>>>>> True. I think supporting 3.8 is fairly high-prio, there's a lot of >>>>>>> demand for it. Doing a 1.3.2 release that supports it would make sense I >>>>>>> guess. >>>>>>> >>>>>>> There don't seem to be any new commits on the 1.2.x branch nor >>>>>>> urgent Python 2.7 fixes that need to go out. So do we need a 1.2.3 release? >>>>>>> >>>>>>> Cheers, >>>>>>> Ralf >>>>>>> >>>>>>> >>>>>>> >>>>>>>> As always, it is a good idea to start tagging things that should be >>>>>>>> in 1.4.0 & please do help with reviewing PRs/issues that are >>>>>>>> tagged--current counts are: >>>>>>>> >>>>>>>> - PRs: 40 open with 1.4.0 milestone >>>>>>>> - issues: 17 open with 1.4.0 milestone >>>>>>>> >>>>>>>> While helping with that, also great if the release notes wiki is >>>>>>>> updated for appropriate changes: >>>>>>>> https://github.com/scipy/scipy/wiki/Release-note-entries-for-SciPy-1.4.0 >>>>>>>> >>>>>>>> Curating those final notes can be painful if the wiki isn't updated. >>>>>>>> >>>>>>>> Thoughts/objections for the schedule? >>>>>>>> >>>>>>>> Best wishes, >>>>>>>> Tyler >>>>>>>> _______________________________________________ >>>>>>>> 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 >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Matt Haberland >>>>>> Assistant Adjunct Professor in the Program in Computing >>>>>> Department of Mathematics >>>>>> 6617A Math Sciences Building, UCLA >>>>>> _______________________________________________ >>>>>> 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 >> > _______________________________________________ > 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 robert.kern at gmail.com Sat Nov 16 00:43:31 2019 From: robert.kern at gmail.com (Robert Kern) Date: Sat, 16 Nov 2019 00:43:31 -0500 Subject: [SciPy-Dev] SciPy-Dev Digest, Vol 193, Issue 12 In-Reply-To: References: <6311BBDE-11D3-491B-A5F3-0FA4383898FD@vt.edu> Message-ID: On Sat, Nov 16, 2019 at 12:07 AM Warren Weckesser < warren.weckesser at gmail.com> wrote: > On 11/15/19, Robert Kern wrote: > > > I still don't really like that part of the test. I think that I would > > prefer that all distributions would be treated as "shape_only". Did it > help > > us solve a bug once? > > The original bug report (first reported in 2011): > > https://github.com/scipy/scipy/issues/2069 > > For some distributions, rvs() returned samples with the correct shape, > but the random variates were not properly generated. > > Checking just the shape is a crude test; how does one verify that the > parameter values were used correctly to generate the random variates? > It looks like this particular bug manifested itself in a particular way that would be easy to recognize. It might be worth checking if we see that pattern instead (i.e. assume it's good unless it tests bad rather than assume it's bad unless if it precisely reproduces these numbers computed in a different way). I think that would cover the "shape_only" set, too. -- Robert Kern -------------- next part -------------- An HTML attachment was scrubbed... URL: From tyler.je.reddy at gmail.com Sun Nov 17 00:12:29 2019 From: tyler.je.reddy at gmail.com (Tyler Reddy) Date: Sat, 16 Nov 2019 22:12:29 -0700 Subject: [SciPy-Dev] Proposed SciPy 1.4.0 Release Schedule In-Reply-To: References: Message-ID: I branched maintenance/1.4.x at ~10 pm Mountain Time on Nov. 16/2019. The SciPy master branch is now open for development of version 1.5.0. Best wishes, Tyler On Fri, 15 Nov 2019 at 22:38, Tyler Reddy wrote: > Please do take a look at the release notes in preparation for 1.4.0 > branching: https://github.com/scipy/scipy/pull/11061 > > The number of pull requests is quite massive (347, I think), so it is a > first draft, but I've transcribed the material from the wiki, made a > no-doubt-controversial draft of release highlights, and tried to curate > author names/mailmap based on the first round of contributor feedback (~144 > authors vs. 97 for 1.3.0). > > On Wed, 13 Nov 2019 at 21:28, Ralf Gommers wrote: > >> >> >> On Wed, Nov 13, 2019 at 7:35 PM Tyler Reddy >> wrote: >> >>> Alright, shall we aim for a two-day bump on the branching to Nov. 16th >>> (Saturday)? I see we're at ~8 PRs with the milestone now, but I also still >>> have to work on release notes, etc. >>> >> >> Thanks, that sounds good! >> >> >> >>> I'm also expecting one or two surprises to pop up in the wheels repo >>> given major release + 3.8. >>> >>> On Wed, 13 Nov 2019 at 20:21, Ralf Gommers >>> wrote: >>> >>>> Hi Tyler, are you still planning to branch 1.4.x tomorrow? It looks >>>> like there's no real blockers, but there's a bunch of stuff that people >>>> seem to be scrambling to get in, so perhaps a 24-48 hour bump could be >>>> useful. >>>> >>>> Cheers, >>>> Ralf >>>> >>>> >>>> On Tue, Nov 12, 2019 at 8:31 AM Tyler Reddy >>>> wrote: >>>> >>>>> Down to 12 open PRs with 1.4.0 milestone--getting closer! >>>>> >>>>> On Sat, 9 Nov 2019 at 21:40, Tyler Reddy >>>>> wrote: >>>>> >>>>>> We currently sit at 31 open PRs and 20 open issues with 1.4.0 >>>>>> milestone. >>>>>> >>>>>> That's a substantial drop in PRs but a rise in issues since the last >>>>>> accounting. Things got >>>>>> a little hectic with Python 3.8 for 1.3.2, but hopefully the wheels >>>>>> stuff is in good shape >>>>>> for 1.4.x series now. >>>>>> >>>>>> Branching in about 5 days is ambitious, but let's aim to stay >>>>>> reasonably on track if possible. >>>>>> >>>>>> On Mon, 21 Oct 2019 at 13:39, Matt Haberland >>>>>> wrote: >>>>>> >>>>>>> Re: 1.2.3 release, I did get a request in gh-10915 >>>>>>> for gh-10498 >>>>>>> to be backported to 1.2. >>>>>>> >>>>>>> On Mon, Oct 21, 2019 at 8:47 AM Ralf Gommers >>>>>>> wrote: >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Sat, Oct 19, 2019 at 12:24 AM Tyler Reddy < >>>>>>>> tyler.je.reddy at gmail.com> wrote: >>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> SciPy 1.3.0 was released May 17 (5 months ago), and I think we'd >>>>>>>>> like to keep a roughly biannual release cadence. >>>>>>>>> >>>>>>>>> I'd like to propose the following schedule for 1.4.0: >>>>>>>>> - November 14: branch 1.4.x >>>>>>>>> - November 17: rc1 >>>>>>>>> - December 1: rc2 (if needed) >>>>>>>>> - December 10: final release >>>>>>>>> >>>>>>>> >>>>>>>> Sounds good to me. >>>>>>>> >>>>>>>>> >>>>>>>>> The arrival of Python 3.8 and simultaneous responsibility to get >>>>>>>>> at least one more 1.2.x LTS Python 2.7 release out the door means things >>>>>>>>> will probably be busy on the release front until 2020. >>>>>>>>> >>>>>>>> >>>>>>>> True. I think supporting 3.8 is fairly high-prio, there's a lot of >>>>>>>> demand for it. Doing a 1.3.2 release that supports it would make sense I >>>>>>>> guess. >>>>>>>> >>>>>>>> There don't seem to be any new commits on the 1.2.x branch nor >>>>>>>> urgent Python 2.7 fixes that need to go out. So do we need a 1.2.3 release? >>>>>>>> >>>>>>>> Cheers, >>>>>>>> Ralf >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> As always, it is a good idea to start tagging things that should >>>>>>>>> be in 1.4.0 & please do help with reviewing PRs/issues that are >>>>>>>>> tagged--current counts are: >>>>>>>>> >>>>>>>>> - PRs: 40 open with 1.4.0 milestone >>>>>>>>> - issues: 17 open with 1.4.0 milestone >>>>>>>>> >>>>>>>>> While helping with that, also great if the release notes wiki is >>>>>>>>> updated for appropriate changes: >>>>>>>>> https://github.com/scipy/scipy/wiki/Release-note-entries-for-SciPy-1.4.0 >>>>>>>>> >>>>>>>>> Curating those final notes can be painful if the wiki isn't >>>>>>>>> updated. >>>>>>>>> >>>>>>>>> Thoughts/objections for the schedule? >>>>>>>>> >>>>>>>>> Best wishes, >>>>>>>>> Tyler >>>>>>>>> _______________________________________________ >>>>>>>>> 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 >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Matt Haberland >>>>>>> Assistant Adjunct Professor in the Program in Computing >>>>>>> Department of Mathematics >>>>>>> 6617A Math Sciences Building, UCLA >>>>>>> _______________________________________________ >>>>>>> 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 >>> >> _______________________________________________ >> 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 Sun Nov 17 03:39:28 2019 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Sun, 17 Nov 2019 00:39:28 -0800 Subject: [SciPy-Dev] Proposed SciPy 1.4.0 Release Schedule In-Reply-To: References: Message-ID: On Sat, Nov 16, 2019 at 9:12 PM Tyler Reddy wrote: > I branched maintenance/1.4.x at ~10 pm Mountain Time on Nov. 16/2019. > Awesome, thanks Tyler! Ralf > The SciPy master branch is now open for development of version 1.5.0. > > Best wishes, > Tyler > > On Fri, 15 Nov 2019 at 22:38, Tyler Reddy > wrote: > >> Please do take a look at the release notes in preparation for 1.4.0 >> branching: https://github.com/scipy/scipy/pull/11061 >> >> The number of pull requests is quite massive (347, I think), so it is a >> first draft, but I've transcribed the material from the wiki, made a >> no-doubt-controversial draft of release highlights, and tried to curate >> author names/mailmap based on the first round of contributor feedback (~144 >> authors vs. 97 for 1.3.0). >> >> On Wed, 13 Nov 2019 at 21:28, Ralf Gommers >> wrote: >> >>> >>> >>> On Wed, Nov 13, 2019 at 7:35 PM Tyler Reddy >>> wrote: >>> >>>> Alright, shall we aim for a two-day bump on the branching to Nov. 16th >>>> (Saturday)? I see we're at ~8 PRs with the milestone now, but I also still >>>> have to work on release notes, etc. >>>> >>> >>> Thanks, that sounds good! >>> >>> >>> >>>> I'm also expecting one or two surprises to pop up in the wheels repo >>>> given major release + 3.8. >>>> >>>> On Wed, 13 Nov 2019 at 20:21, Ralf Gommers >>>> wrote: >>>> >>>>> Hi Tyler, are you still planning to branch 1.4.x tomorrow? It looks >>>>> like there's no real blockers, but there's a bunch of stuff that people >>>>> seem to be scrambling to get in, so perhaps a 24-48 hour bump could be >>>>> useful. >>>>> >>>>> Cheers, >>>>> Ralf >>>>> >>>>> >>>>> On Tue, Nov 12, 2019 at 8:31 AM Tyler Reddy >>>>> wrote: >>>>> >>>>>> Down to 12 open PRs with 1.4.0 milestone--getting closer! >>>>>> >>>>>> On Sat, 9 Nov 2019 at 21:40, Tyler Reddy >>>>>> wrote: >>>>>> >>>>>>> We currently sit at 31 open PRs and 20 open issues with 1.4.0 >>>>>>> milestone. >>>>>>> >>>>>>> That's a substantial drop in PRs but a rise in issues since the last >>>>>>> accounting. Things got >>>>>>> a little hectic with Python 3.8 for 1.3.2, but hopefully the wheels >>>>>>> stuff is in good shape >>>>>>> for 1.4.x series now. >>>>>>> >>>>>>> Branching in about 5 days is ambitious, but let's aim to stay >>>>>>> reasonably on track if possible. >>>>>>> >>>>>>> On Mon, 21 Oct 2019 at 13:39, Matt Haberland >>>>>>> wrote: >>>>>>> >>>>>>>> Re: 1.2.3 release, I did get a request in gh-10915 >>>>>>>> for gh-10498 >>>>>>>> to be backported to >>>>>>>> 1.2. >>>>>>>> >>>>>>>> On Mon, Oct 21, 2019 at 8:47 AM Ralf Gommers < >>>>>>>> ralf.gommers at gmail.com> wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Sat, Oct 19, 2019 at 12:24 AM Tyler Reddy < >>>>>>>>> tyler.je.reddy at gmail.com> wrote: >>>>>>>>> >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> SciPy 1.3.0 was released May 17 (5 months ago), and I think we'd >>>>>>>>>> like to keep a roughly biannual release cadence. >>>>>>>>>> >>>>>>>>>> I'd like to propose the following schedule for 1.4.0: >>>>>>>>>> - November 14: branch 1.4.x >>>>>>>>>> - November 17: rc1 >>>>>>>>>> - December 1: rc2 (if needed) >>>>>>>>>> - December 10: final release >>>>>>>>>> >>>>>>>>> >>>>>>>>> Sounds good to me. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> The arrival of Python 3.8 and simultaneous responsibility to get >>>>>>>>>> at least one more 1.2.x LTS Python 2.7 release out the door means things >>>>>>>>>> will probably be busy on the release front until 2020. >>>>>>>>>> >>>>>>>>> >>>>>>>>> True. I think supporting 3.8 is fairly high-prio, there's a lot of >>>>>>>>> demand for it. Doing a 1.3.2 release that supports it would make sense I >>>>>>>>> guess. >>>>>>>>> >>>>>>>>> There don't seem to be any new commits on the 1.2.x branch nor >>>>>>>>> urgent Python 2.7 fixes that need to go out. So do we need a 1.2.3 release? >>>>>>>>> >>>>>>>>> Cheers, >>>>>>>>> Ralf >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> As always, it is a good idea to start tagging things that should >>>>>>>>>> be in 1.4.0 & please do help with reviewing PRs/issues that are >>>>>>>>>> tagged--current counts are: >>>>>>>>>> >>>>>>>>>> - PRs: 40 open with 1.4.0 milestone >>>>>>>>>> - issues: 17 open with 1.4.0 milestone >>>>>>>>>> >>>>>>>>>> While helping with that, also great if the release notes wiki is >>>>>>>>>> updated for appropriate changes: >>>>>>>>>> https://github.com/scipy/scipy/wiki/Release-note-entries-for-SciPy-1.4.0 >>>>>>>>>> >>>>>>>>>> Curating those final notes can be painful if the wiki isn't >>>>>>>>>> updated. >>>>>>>>>> >>>>>>>>>> Thoughts/objections for the schedule? >>>>>>>>>> >>>>>>>>>> Best wishes, >>>>>>>>>> Tyler >>>>>>>>>> _______________________________________________ >>>>>>>>>> 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 >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Matt Haberland >>>>>>>> Assistant Adjunct Professor in the Program in Computing >>>>>>>> Department of Mathematics >>>>>>>> 6617A Math Sciences Building, UCLA >>>>>>>> _______________________________________________ >>>>>>>> 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 >>>> >>> _______________________________________________ >>> 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 josh.craig.wilson at gmail.com Sun Nov 17 13:51:35 2019 From: josh.craig.wilson at gmail.com (Joshua Wilson) Date: Sun, 17 Nov 2019 10:51:35 -0800 Subject: [SciPy-Dev] Adding logsoftmax function to scipy.special In-Reply-To: References: Message-ID: > I would like to implement logsoftmax(x) as x-logsumexp(x) The function seems reasonable to add, but I am not so sure about that implementation, as it appears that it could lead to cancellation. Note, for example, that because of the scaling `logsumexp` does to prevent overflow, with that implementation you will end up adding and subtracting the component `x_i` of the largest magnitude when computing the `i`th component of the results array, see e.g. https://github.com/scipy/scipy/blob/master/scipy/special/_logsumexp.py#L124 Off the top of my head, it is not obvious to me that situations similar to that will not lead to cancellation errors. Of course, I might be wrong, but my overall point is that in order to use a particular implementation we should have a reasonable understanding of its theoretical properties, so I would like to see some exploration of that before proceeding. - Josh On Fri, Nov 15, 2019 at 5:17 PM Ralf Gommers wrote: > > Hi Takuya, > > > On Tue, Nov 12, 2019 at 9:05 PM Takuya Koumura wrote: >> >> Hello, >> >> I raised a GitHub issue (#11058) and was suggested to post it to scipy-dev. >> >> I?m considering to send a PR to add logsoftmax function in scipy.special. Before that, I would like to hear your opinion (partly because it?s my first time to send a PR to scipy). > > > Welcome! Thanks for proposing that. logsoftmax is fairly popular at least in deep learning, so it makes sense I think, and we already have a bunch of other log* functions in scipy.special. > > I noticed that both PyTorch and Tensorflow name this function `log_softmax` rather than `logsoftmax`. The latter would be a little more consistent with other functions (although we also have `special.log_ndtr`), while the former is consistent with other implementations of the same functionality. I'd be okay with either, with a slight preference for `log_softmax`. > >> >> I would like to implement logsoftmax(x) as x-logsumexp(x). Actually, special.softmax(x) = np.exp(x-logsumexp(x)), so it is trivial for those who read the source code of softmax, but I think including logsoftmax as a separate function will be useful for other users. Logsoftmax is more accurate with inputs that make softmax saturate, eg: When x=[1000, 0], np.log(softmax(x))=[0, -Inf] (maybe depending on the floating point precision), while logsoftmax(x)=[0, -1000]. >> >> I am planning to add the new function at the bottom of special/_logsumexp.py following the softmax function, and add some unit tests in special/test/test_logsumexp.py. If you have comments, I?d appreciate any. > > > That seems like a good place. > > Cheers, > Ralf > >> >> Best wishes, >> -- >> Takuya KOUMURA >> koumura at cycentum.com >> _______________________________________________ >> 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 koumura at cycentum.com Mon Nov 18 03:38:20 2019 From: koumura at cycentum.com (Takuya Koumura) Date: Mon, 18 Nov 2019 17:38:20 +0900 Subject: [SciPy-Dev] Adding logsoftmax function to scipy.special In-Reply-To: References: Message-ID: Hi Ralf, Josh, and all, Thank you for your positive comments and raising potential issues. Having read Josh?s comment, I conducted several experiments and found there indeed is a case where cancellation occurs in my original implementation, in which log_softmax(x) = x - logsumexp(x) = x - (m + log(sum(exp(x - m)))) where m = max(x). Calculating s = x - m first and using it to calculate log_softmax(x) = s - logsumexp(s) should decrease the chance of cancellation because it does not involve subtraction other than x - m. Note that s is always <=0, so s - log(sum(exp(s))) is actually addition of negative values. Also, reusing s may be a bit more efficient in computational time. Best, Takuya 2019?11?18?(?) 3:51 Joshua Wilson : > > I would like to implement logsoftmax(x) as x-logsumexp(x) > > The function seems reasonable to add, but I am not so sure about that > implementation, as it appears that it could lead to cancellation. > Note, for example, that because of the scaling `logsumexp` does to > prevent overflow, with that implementation you will end up adding and > subtracting the component `x_i` of the largest magnitude when > computing the `i`th component of the results array, see e.g. > > https://github.com/scipy/scipy/blob/master/scipy/special/_logsumexp.py#L124 > > Off the top of my head, it is not obvious to me that situations > similar to that will not lead to cancellation errors. > > Of course, I might be wrong, but my overall point is that in order to > use a particular implementation we should have a reasonable > understanding of its theoretical properties, so I would like to see > some exploration of that before proceeding. > > - Josh > > On Fri, Nov 15, 2019 at 5:17 PM Ralf Gommers > wrote: > > > > Hi Takuya, > > > > > > On Tue, Nov 12, 2019 at 9:05 PM Takuya Koumura > wrote: > >> > >> Hello, > >> > >> I raised a GitHub issue (#11058) and was suggested to post it to > scipy-dev. > >> > >> I?m considering to send a PR to add logsoftmax function in > scipy.special. Before that, I would like to hear your opinion (partly > because it?s my first time to send a PR to scipy). > > > > > > Welcome! Thanks for proposing that. logsoftmax is fairly popular at > least in deep learning, so it makes sense I think, and we already have a > bunch of other log* functions in scipy.special. > > > > I noticed that both PyTorch and Tensorflow name this function > `log_softmax` rather than `logsoftmax`. The latter would be a little more > consistent with other functions (although we also have `special.log_ndtr`), > while the former is consistent with other implementations of the same > functionality. I'd be okay with either, with a slight preference for > `log_softmax`. > > > >> > >> I would like to implement logsoftmax(x) as x-logsumexp(x). Actually, > special.softmax(x) = np.exp(x-logsumexp(x)), so it is trivial for those who > read the source code of softmax, but I think including logsoftmax as a > separate function will be useful for other users. Logsoftmax is more > accurate with inputs that make softmax saturate, eg: When x=[1000, 0], > np.log(softmax(x))=[0, -Inf] (maybe depending on the floating point > precision), while logsoftmax(x)=[0, -1000]. > >> > >> I am planning to add the new function at the bottom of > special/_logsumexp.py following the softmax function, and add some unit > tests in special/test/test_logsumexp.py. If you have comments, I?d > appreciate any. > > > > > > That seems like a good place. > > > > Cheers, > > Ralf > > > >> > >> Best wishes, > >> -- > >> Takuya KOUMURA > >> koumura at cycentum.com > >> _______________________________________________ > >> 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 > -- -- Takuya KOUMURA koumura at cycentum.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From tyler.je.reddy at gmail.com Thu Nov 21 16:01:41 2019 From: tyler.je.reddy at gmail.com (Tyler Reddy) Date: Thu, 21 Nov 2019 14:01:41 -0700 Subject: [SciPy-Dev] Proposed SciPy 1.4.0 Release Schedule In-Reply-To: References: Message-ID: First attempt at 1.4.0rc1 wheel builds are now underway, with fingers crossed: https://travis-ci.org/MacPython/scipy-wheels/builds/615256054 https://ci.appveyor.com/project/scipy/scipy-wheels/builds/29034442 On Sun, 17 Nov 2019 at 01:40, Ralf Gommers wrote: > > > On Sat, Nov 16, 2019 at 9:12 PM Tyler Reddy > wrote: > >> I branched maintenance/1.4.x at ~10 pm Mountain Time on Nov. 16/2019. >> > > Awesome, thanks Tyler! > > Ralf > > >> The SciPy master branch is now open for development of version 1.5.0. >> >> Best wishes, >> Tyler >> >> On Fri, 15 Nov 2019 at 22:38, Tyler Reddy >> wrote: >> >>> Please do take a look at the release notes in preparation for 1.4.0 >>> branching: https://github.com/scipy/scipy/pull/11061 >>> >>> The number of pull requests is quite massive (347, I think), so it is a >>> first draft, but I've transcribed the material from the wiki, made a >>> no-doubt-controversial draft of release highlights, and tried to curate >>> author names/mailmap based on the first round of contributor feedback (~144 >>> authors vs. 97 for 1.3.0). >>> >>> On Wed, 13 Nov 2019 at 21:28, Ralf Gommers >>> wrote: >>> >>>> >>>> >>>> On Wed, Nov 13, 2019 at 7:35 PM Tyler Reddy >>>> wrote: >>>> >>>>> Alright, shall we aim for a two-day bump on the branching to Nov. 16th >>>>> (Saturday)? I see we're at ~8 PRs with the milestone now, but I also still >>>>> have to work on release notes, etc. >>>>> >>>> >>>> Thanks, that sounds good! >>>> >>>> >>>> >>>>> I'm also expecting one or two surprises to pop up in the wheels repo >>>>> given major release + 3.8. >>>>> >>>>> On Wed, 13 Nov 2019 at 20:21, Ralf Gommers >>>>> wrote: >>>>> >>>>>> Hi Tyler, are you still planning to branch 1.4.x tomorrow? It looks >>>>>> like there's no real blockers, but there's a bunch of stuff that people >>>>>> seem to be scrambling to get in, so perhaps a 24-48 hour bump could be >>>>>> useful. >>>>>> >>>>>> Cheers, >>>>>> Ralf >>>>>> >>>>>> >>>>>> On Tue, Nov 12, 2019 at 8:31 AM Tyler Reddy >>>>>> wrote: >>>>>> >>>>>>> Down to 12 open PRs with 1.4.0 milestone--getting closer! >>>>>>> >>>>>>> On Sat, 9 Nov 2019 at 21:40, Tyler Reddy >>>>>>> wrote: >>>>>>> >>>>>>>> We currently sit at 31 open PRs and 20 open issues with 1.4.0 >>>>>>>> milestone. >>>>>>>> >>>>>>>> That's a substantial drop in PRs but a rise in issues since the >>>>>>>> last accounting. Things got >>>>>>>> a little hectic with Python 3.8 for 1.3.2, but hopefully the wheels >>>>>>>> stuff is in good shape >>>>>>>> for 1.4.x series now. >>>>>>>> >>>>>>>> Branching in about 5 days is ambitious, but let's aim to stay >>>>>>>> reasonably on track if possible. >>>>>>>> >>>>>>>> On Mon, 21 Oct 2019 at 13:39, Matt Haberland >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Re: 1.2.3 release, I did get a request in gh-10915 >>>>>>>>> for gh-10498 >>>>>>>>> to be backported to >>>>>>>>> 1.2. >>>>>>>>> >>>>>>>>> On Mon, Oct 21, 2019 at 8:47 AM Ralf Gommers < >>>>>>>>> ralf.gommers at gmail.com> wrote: >>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Sat, Oct 19, 2019 at 12:24 AM Tyler Reddy < >>>>>>>>>> tyler.je.reddy at gmail.com> wrote: >>>>>>>>>> >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> SciPy 1.3.0 was released May 17 (5 months ago), and I think we'd >>>>>>>>>>> like to keep a roughly biannual release cadence. >>>>>>>>>>> >>>>>>>>>>> I'd like to propose the following schedule for 1.4.0: >>>>>>>>>>> - November 14: branch 1.4.x >>>>>>>>>>> - November 17: rc1 >>>>>>>>>>> - December 1: rc2 (if needed) >>>>>>>>>>> - December 10: final release >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Sounds good to me. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> The arrival of Python 3.8 and simultaneous responsibility to get >>>>>>>>>>> at least one more 1.2.x LTS Python 2.7 release out the door means things >>>>>>>>>>> will probably be busy on the release front until 2020. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> True. I think supporting 3.8 is fairly high-prio, there's a lot >>>>>>>>>> of demand for it. Doing a 1.3.2 release that supports it would make sense I >>>>>>>>>> guess. >>>>>>>>>> >>>>>>>>>> There don't seem to be any new commits on the 1.2.x branch nor >>>>>>>>>> urgent Python 2.7 fixes that need to go out. So do we need a 1.2.3 release? >>>>>>>>>> >>>>>>>>>> Cheers, >>>>>>>>>> Ralf >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> As always, it is a good idea to start tagging things that should >>>>>>>>>>> be in 1.4.0 & please do help with reviewing PRs/issues that are >>>>>>>>>>> tagged--current counts are: >>>>>>>>>>> >>>>>>>>>>> - PRs: 40 open with 1.4.0 milestone >>>>>>>>>>> - issues: 17 open with 1.4.0 milestone >>>>>>>>>>> >>>>>>>>>>> While helping with that, also great if the release notes wiki is >>>>>>>>>>> updated for appropriate changes: >>>>>>>>>>> https://github.com/scipy/scipy/wiki/Release-note-entries-for-SciPy-1.4.0 >>>>>>>>>>> >>>>>>>>>>> Curating those final notes can be painful if the wiki isn't >>>>>>>>>>> updated. >>>>>>>>>>> >>>>>>>>>>> Thoughts/objections for the schedule? >>>>>>>>>>> >>>>>>>>>>> Best wishes, >>>>>>>>>>> Tyler >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> 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 >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Matt Haberland >>>>>>>>> Assistant Adjunct Professor in the Program in Computing >>>>>>>>> Department of Mathematics >>>>>>>>> 6617A Math Sciences Building, UCLA >>>>>>>>> _______________________________________________ >>>>>>>>> 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 >>>>> >>>> _______________________________________________ >>>> 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 tyler.je.reddy at gmail.com Fri Nov 22 00:32:08 2019 From: tyler.je.reddy at gmail.com (Tyler Reddy) Date: Thu, 21 Nov 2019 22:32:08 -0700 Subject: [SciPy-Dev] ANN: SciPy 1.4.0rc1 -- please test Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi all, On behalf of the SciPy development team I'm pleased to announce the release candidate SciPy 1.4.0rc1. Please help us test this pre-release. Sources and binary wheels can be found at: https://pypi.org/project/scipy/ and at: https://github.com/scipy/scipy/releases/tag/v1.4.0rc1 One of a few ways to install the release candidate with pip: pip install scipy==1.4.0rc1 ========================== SciPy 1.4.0 Release Notes ========================== Note: Scipy 1.4.0 is not released yet! SciPy 1.4.0 is the culmination of 6 months of hard work. It contains many new features, numerous bug-fixes, improved test coverage and better documentation. There have been a number of deprecations and API changes in this release, which are documented below. All users are encouraged to upgrade to this release, as there are a large number of bug-fixes and optimizations. Before upgrading, we recommend that users check that their own code does not use deprecated SciPy functionality (to do so, run your code with ``python -Wd`` and check for ``DeprecationWarning`` s). Our development attention will now shift to bug-fix releases on the 1.4.x branch, and on adding new features on the master branch. This release requires Python 3.5+ and NumPy >=1.13.3 (for Python 3.5, 3.6), >=1.14.5 (for Python 3.7), >= 1.17.3 (for Python 3.8) For running on PyPy, PyPy3 6.0+ and NumPy 1.15.0 are required. Highlights of this release ---------------------------------- - a new submodule, `scipy.fft`, now supersedes `scipy.fftpack`; this means support for ``long double`` transforms, faster multi-dimensional transforms, improved algorithm time complexity, release of the global intepreter lock, and control over threading behavior - support for ``pydata/sparse`` arrays in `scipy.sparse.linalg` - substantial improvement to the documentation and functionality of several `scipy.special` functions, and some new additions - the generalized inverse Gaussian distribution has been added to `scipy.stats` - an implementation of the Edmonds-Karp algorithm in `scipy.sparse.csgraph.maximum_flow` - `scipy.spatial.SphericalVoronoi` now supports n-dimensional input, has linear memory complexity, improved performance, and supports single-hemisphere generators New features ============ Infrastructure ------------------- Documentation can now be built with ``runtests.py --doc`` A ``Dockerfile`` is now available in the ``scipy/scipy-dev`` repository to facilitate getting started with SciPy development. `scipy.constants` improvements -------------------------------------------- `scipy.constants` has been updated with the CODATA 2018 constants. `scipy.fft` added ----------------------- `scipy.fft` is a new submodule that supersedes the `scipy.fftpack` submodule. For the most part, this is a drop-in replacement for ``numpy.fft`` and `scipy.fftpack` alike. With some important differences, `scipy.fft`: - uses NumPy's conventions for real transforms (``rfft``). This means the return value is a complex array, half the size of the full ``fft`` output. This is different from the output of ``fftpack`` which returned a real array representing complex components packed together. - the inverse real to real transforms (``idct`` and ``idst``) are normalized for ``norm=None`` in thesame way as ``ifft``. This means the identity ``idct(dct(x)) == x`` is now ``True`` for all norm modes. - does not include the convolutions or pseudo-differential operators from ``fftpack``. This submodule is based on the ``pypocketfft`` library, developed by the author of ``pocketfft`` which was recently adopted by NumPy as well. ``pypocketfft`` offers a number of advantages over fortran ``FFTPACK``: - support for long double (``np.longfloat``) precision transforms. - faster multi-dimensional transforms using vectorisation - Bluestein?s algorithm removes the worst-case ``O(n^2)`` complexity of ``FFTPACK`` - the global interpreter lock (``GIL``) is released during transforms - optional multithreading of multi-dimensional transforms via the ``workers`` argument Note that `scipy.fftpack` has not been deprecated and will continue to be maintained but is now considered legacy. New code is recommended to use `scipy.fft` instead, where possible. `scipy.fftpack` improvements ---------------------------------------- `scipy.fftpack` now uses pypocketfft to perform its FFTs, offering the same speed and accuracy benefits listed for scipy.fft above but without the improved API. `scipy.integrate` improvements ------------------------------------------- The function `scipy.integrate.solve_ivp` now has an ``args`` argument. This allows the user-defined functions passed to the function to have additional parameters without having to create wrapper functions or lambda expressions for them. `scipy.integrate.solve_ivp` can now return a ``y_events`` attribute representing the solution of the ODE at event times New ``OdeSolver`` is implemented --- ``DOP853``. This is a high-order explicit Runge-Kutta method originally implemented in Fortran. Now we provide a pure Python implementation usable through ``solve_ivp`` with all its features. `scipy.integrate.quad` provides better user feedback when break points are specified with a weighted integrand. `scipy.integrate.quad_vec` is now available for general purpose integration of vector-valued functions `scipy.interpolate` improvements --------------------------------------------- `scipy.interpolate.pade` now handles complex input data gracefully `scipy.interpolate.Rbf` can now interpolate multi-dimensional functions `scipy.io` improvements --------------------------------- `scipy.io.wavfile.read` can now read data from a `WAV` file that has a malformed header, similar to other modern `WAV` file parsers `scipy.io.FortranFile` now has an expanded set of available ``Exception`` classes for handling poorly-formatted files `scipy.linalg` improvements -------------------------------------- The function ``scipy.linalg.subspace_angles(A, B)`` now gives correct results for complex-valued matrices. Before this, the function only returned correct values for real-valued matrices. New boolean keyword argument ``check_finite`` for `scipy.linalg.norm`; whether to check that the input matrix contains only finite numbers. Disabling may give a performance gain, but may result in problems (crashes, non-termination) if the inputs do contain infinities or NaNs. `scipy.linalg.solve_triangular` has improved performance for a C-ordered triangular matrix ``LAPACK`` wrappers have been added for ``?geequ``, ``?geequb``, ``?syequb``, and ``?heequb`` Some performance improvements may be observed due to an internal optimization in operations involving LAPACK routines via ``_compute_lwork``. This is particularly true for operations on small arrays. Block ``QR`` wrappers are now available in `scipy.linalg.lapack` `scipy.ndimage` improvements ------------------------------------------ `scipy.optimize` improvements ------------------------------------------ It is now possible to use linear and non-linear constraints with `scipy.optimize.differential_evolution`. `scipy.optimize.linear_sum_assignment` has been re-written in C++ to improve performance, and now allows input costs to be infinite. A ``ScalarFunction.fun_and_grad`` method was added for convenient simultaneous retrieval of a function and gradient evaluation `scipy.optimize.minimize` ``BFGS`` method has improved performance by avoiding duplicate evaluations in some cases Better user feedback is provided when an objective function returns an array instead of a scalar. `scipy.signal` improvements ---------------------------------------- Added a new function to calculate convolution using the overlap-add method, named `scipy.signal.oaconvolve`. Like `scipy.signal.fftconvolve`, this function supports specifying dimensions along which to do the convolution. `scipy.signal.cwt` now supports complex wavelets. The implementation of ``choose_conv_method`` has been updated to reflect the new FFT implementation. In addition, the performance has been significantly improved (with rather drastic improvements in edge cases). The function ``upfirdn`` now has a ``mode`` keyword argument that can be used to select the signal extension mode used at the signal boundaries. These modes are also available for use in ``resample_poly`` via a newly added ``padtype`` argument. `scipy.signal.sosfilt` now benefits from Cython code for improved performance `scipy.signal.resample` should be more efficient by leveraging ``rfft`` when possible `scipy.sparse` improvements ----------------------------------------- It is now possible to use the LOBPCG method in `scipy.sparse.linalg.svds`. `scipy.sparse.linalg.LinearOperator` now supports the operation ``rmatmat`` for adjoint matrix-matrix multiplication, in addition to ``rmatvec``. Multiple stability updates enable float32 support in the LOBPCG eigenvalue solver for symmetric and Hermitian eigenvalues problems in ``scipy.sparse.linalg.lobpcg``. A solver for the maximum flow problem has been added as `scipy.sparse.csgraph.maximum_flow`. `scipy.sparse.csgraph.maximum_bipartite_matching` now allows non-square inputs, no longer requires a perfect matching to exist, and has improved performance. `scipy.sparse.lil_matrix` conversions now perform better in some scenarios Basic support is available for ``pydata/sparse`` arrays in `scipy.sparse.linalg` `scipy.sparse.linalg.spsolve_triangular` now supports the ``unit_diagonal`` argument to improve call signature similarity with its dense counterpart, `scipy.linalg.solve_triangular` ``assertAlmostEqual`` may now be used with sparse matrices, which have added support for ``__round__`` `scipy.spatial` improvements ----------------------------------------- The bundled Qhull library was upgraded to version 2019.1, fixing several issues. Scipy-specific patches are no longer applied to it. `scipy.spatial.SphericalVoronoi` now has linear memory complexity, improved performance, and supports single-hemisphere generators. Support has also been added for handling generators that lie on a great circle arc (geodesic input) and for generators in n-dimensions. `scipy.spatial.transform.Rotation` now includes functions for calculation of a mean rotation, generation of the 3D rotation groups, and reduction of rotations with rotational symmetries. `scipy.spatial.transform.Slerp` is now callable with a scalar argument `scipy.spatial.voronoi_plot_2d` now supports furthest site Voronoi diagrams `scipy.spatial.Delaunay` and `scipy.spatial.Voronoi` now have attributes for tracking whether they are furthest site diagrams `scipy.special` improvements ----------------------------------------- The Voigt profile has been added as `scipy.special.voigt_profile`. A real dispatch has been added for the Wright Omega function (`scipy.special.wrightomega`). The analytic continuation of the Riemann zeta function has been added. (The Riemann zeta function is the one-argument variant of `scipy.special.zeta`.) The complete elliptic integral of the first kind (`scipy.special.ellipk`) is now available in `scipy.special.cython_special`. The accuracy of `scipy.special.hyp1f1` for real arguments has been improved. The documentation of many functions has been improved. `scipy.stats` improvements -------------------------------------- `scipy.stats.multiscale_graphcorr` added as an independence test that operates on high dimensional and nonlinear data sets. It has higher statistical power than other `scipy.stats` tests while being the only one that operates on multivariate data. The generalized inverse Gaussian distribution (`scipy.stats.geninvgauss`) has been added. It is now possible to efficiently reuse `scipy.stats.binned_statistic_dd` with new values by providing the result of a previous call to the function. `scipy.stats.hmean` now handles input with zeros more gracefully. The beta-binomial distribution is now available in `scipy.stats.betabinom`. `scipy.stats.zscore`, `scipy.stats.circmean`, `scipy.stats.circstd`, and `scipy.stats.circvar` now support the ``nan_policy`` argument for enhanced handling of ``NaN`` values `scipy.stats.entropy` now accepts an ``axis`` argument `scipy.stats.gaussian_kde.resample` now accepts a ``seed`` argument to empower reproducibility `scipy.stats.multiscale_graphcorr` has been added for calculation of the multiscale graph correlation (MGC) test statistic `scipy.stats.kendalltau` performance has improved, especially for large inputs, due to improved cache usage `scipy.stats.truncnorm` distribution has been rewritten to support much wider tails Deprecated features =================== `scipy` deprecations ----------------------------- Support for NumPy functions exposed via the root SciPy namespace is deprecated and will be removed in 2.0.0. For example, if you use ``scipy.rand`` or ``scipy.diag``, you should change your code to directly use ``numpy.random.default_rng`` or ``numpy.diag``, respectively. They remain available in the currently continuing Scipy 1.x release series. The exception to this rule is using ``scipy.fft`` as a function -- :mod:`scipy.fft` is now meant to be used only as a module, so the ability to call ``scipy.fft(...)`` will be removed in SciPy 1.5.0. In `scipy.spatial.Rotation` methods ``from_dcm``, ``as_dcm`` were renamed to ``from_matrix``, ``as_matrix`` respectively. The old names will be removed in SciPy 1.6.0. Backwards incompatible changes ============================== `scipy.special` changes ---------------------------------- The deprecated functions ``hyp2f0``, ``hyp1f2``, and ``hyp3f0`` have been removed. The deprecated function ``bessel_diff_formula`` has been removed. The function ``i0`` is no longer registered with ``numpy.dual``, so that ``numpy.dual.i0`` will unconditionally refer to the NumPy version regardless of whether `scipy.special` is imported. The function ``expn`` has been changed to return ``nan`` outside of its domain of definition (``x, n < 0``) instead of ``inf``. `scipy.sparse` changes --------------------------------- Sparse matrix reshape now raises an error if shape is not two-dimensional, rather than guessing what was meant. The behavior is now the same as before SciPy 1.1.0. `scipy.spatial` changes --------------------------------- The default behavior of the ``match_vectors`` method of `scipy.spatial.transform.Rotation` was changed for input vectors that are not normalized and not of equal lengths. Previously, such vectors would be normalized within the method. Now, the calculated rotation takes the vector length into account, longer vectors will have a larger weight. For more details, see https://github.com/scipy/scipy/issues/10968. `scipy.signal` changes -------------------------------- `scipy.signal.resample` behavior for length-1 signal inputs has been fixed to output a constant (DC) value rather than an impulse, consistent with the assumption of signal periodicity in the FFT method. `scipy.signal.cwt` now performs complex conjugation and time-reversal of wavelet data, which is a backwards-incompatible bugfix for time-asymmetric wavelets. `scipy.stats` changes ------------------------------ `scipy.stats.loguniform` added with better documentation as (an alias for ``scipy.stats.reciprocal``). ``loguniform`` generates random variables that are equally likely in the log space; e.g., ``1``, ``10`` and ``100`` are all equally likely if ``loguniform(10 ** 0, 10 ** 2).rvs()`` is used. Other changes ============= The ``LSODA`` method of `scipy.integrate.solve_ivp` now correctly detects stiff problems. `scipy.spatial.cKDTree` now accepts and correctly handles empty input data `scipy.stats.binned_statistic_dd` now calculates the standard deviation statistic in a numerically stable way. `scipy.stats.binned_statistic_dd` now throws an error if the input data contains either ``np.nan`` or ``np.inf``. Similarly, in `scipy.stats` now all continuous distributions' ``.fit()`` methods throw an error if the input data contain any instance of either ``np.nan`` or ``np.inf``. Authors ======= * @endolith * Abhinav + * Anne Archibald * ashwinpathak20nov1996 + * Danilo Augusto + * Nelson Auner + * aypiggott + * Christoph Baumgarten * Peter Bell * Sebastian Berg * Arman Bilge + * Benedikt Boecking + * Christoph Boeddeker + * Daniel Bunting * Evgeni Burovski * Angeline Burrell + * Angeline G. Burrell + * CJ Carey * Carlos Ramos Carre?o + * Mak Sze Chun + * Malayaja Chutani + * Christian Clauss + * Jonathan Conroy + * Stephen P Cook + * Dylan Cutler + * Anirudh Dagar + * Aidan Dang + * dankleeman + * Brandon David + * Tyler Dawson + * Dieter Werthm?ller * Joe Driscoll + * Jakub Dyczek + * D?vid Bodn?r * Fletcher Easton + * Stefan Endres * etienne + * Johann Faouzi * Yu Feng * Isuru Fernando + * Matthew H Flamm * Martin Gauch + * Gabriel Gerlero + * Ralf Gommers * Chris Gorgolewski + * Domen Gorjup + * Edouard Goudenhoofdt + * Jan Gwinner + * Maja Gwozdz + * Matt Haberland * hadshirt + * Pierre Haessig + * David Hagen * Charles Harris * Gina Helfrich + * Alex Henrie + * Francisco J. Hernandez Heras + * Andreas Hilboll * Lindsey Hiltner * Thomas Hisch * Min ho Kim + * Gert-Ludwig Ingold * jakobjakobson13 + * Todd Jennings * He Jia * Muhammad Firmansyah Kasim + * Andrew Knyazev + * Holger Kohr + * Mateusz Konieczny + * Krzysztof Pi?ro + * Philipp Lang + * Peter Mahler Larsen + * Eric Larson * Antony Lee * Gregory R. Lee * Chelsea Liu + * Jesse Livezey * Peter Lysakovski + * Jason Manley + * Michael Marien + * Nikolay Mayorov * G. D. McBain + * Sam McCormack + * Melissa Weber Mendon?a + * Kevin Michel + * mikeWShef + * Sturla Molden * Eric Moore * Peyton Murray + * Andrew Nelson * Clement Ng + * Juan Nunez-Iglesias * Renee Otten + * Kellie Ottoboni + * Ayappan P * Sambit Panda + * Tapasweni Pathak + * Oleksandr Pavlyk * Fabian Pedregosa * Petar Mlinari? * Matti Picus * Marcel Plch + * Christoph Pohl + * Ilhan Polat * Siddhesh Poyarekar + * Ioannis Prapas + * James Alan Preiss + * Yisheng Qiu + * Eric Quintero * Bharat Raghunathan + * Tyler Reddy * Joscha Reimer * Antonio Horta Ribeiro * Lucas Roberts * rtshort + * Josua Sassen * Kevin Sheppard * Scott Sievert * Leo Singer * Kai Striega * S?ren Fuglede J?rgensen * tborisow + * ?tienne Tremblay + * tuxcell + * Miguel de Val-Borro * Andrew Valentine + * Hugo van Kemenade * Paul van Mulbregt * Sebastiano Vigna * Pauli Virtanen * Dany Vohl + * Ben Walsh + * Huize Wang + * Warren Weckesser * Anreas Weh + * Joseph Weston + * Adrian Wijaya + * Timothy Willard + * Josh Wilson * Kentaro Yamamoto + * Dave Zbarsky + A total of 141 people contributed to this release. People with a "+" by their names contributed a patch for the first time. This list of names is automatically generated, and may not be fully complete. Issues closed for 1.4.0 --------------------------------- * `#1255 `__: maxiter broken for Scipy.sparse.linalg gmres, in addition to... * `#1301 `__: consolidate multipack.h from interpolate and integrate packages... * `#1739 `__: Single precision FFT insufficiently accurate. (Trac #1212) * `#1795 `__: stats test_distributions.py: replace old fuzz tests (Trac #1269) * `#2233 `__: fftpack segfault with big arrays (Trac #1714) * `#2434 `__: rmatmat and the sophistication of linear operator objects * `#2477 `__: stats.truncnorm.rvs() does not give symmetric results for negative... * `#2629 `__: FFTpack is unacceptably slow on non power of 2 * `#2883 `__: UnboundLocalError in scipy.interpolate.splrep * `#2956 `__: Feature Request: axis argument for stats.entropy function * `#3528 `__: Segfault on test_djbfft (possibly MKL-related?) * `#3793 `__: cwt should also return complex array * `#4464 `__: TST: residue/residuez/invres/invresz don't have any tests * `#4561 `__: BUG: tf filter trailing and leading zeros in residuez * `#4669 `__: Rewrite sosfilt to make a single loop over the input? * `#5040 `__: BUG: Empty data handling of (c)KDTrees * `#5112 `__: boxcox transform edge cases could use more care * `#5441 `__: scipy.stats.ncx2 fails for nc=0 * `#5502 `__: args keyword not handled in optimize.curve_fit * `#6484 `__: Qhull segmentation fault * `#6900 `__: linear_sum_assignment with infinite weights * `#6966 `__: Hypergeometric Functions documentation is lacking * `#6999 `__: possible false positive corruption check in compressed loadmat() * `#7018 `__: ydata that needs broadcasting renders curve_fit unable to compute... * `#7140 `__: trouble with documentation for windows * `#7327 `__: interpolate.ndgriddata.griddata causes Python to crash rather... * `#7396 `__: MatrixLinearOperator implements _adjoint(), but not _transpose() * `#7400 `__: BUG(?): special: factorial and factorial2 return a 0-dimensional... * `#7434 `__: Testing of scipy.stats continuous distributions misses 25 distributions * `#7491 `__: Several scipy.stats distributions (fisk, burr, burr12, f) return... * `#7759 `__: Overflow in stats.kruskal for large samples * `#7906 `__: Wrong result from scipy.interpolate.UnivariateSpline.integral... * `#8165 `__: ENH: match functionality of R for hmean * `#8417 `__: optimimze.minimize(method='L-BFGS-B', options={'disp': True})... * `#8535 `__: Strictly increasing requirement in UnivariateSpline * `#8815 `__: [BUG] GMRES: number of iteration is only increased if callback... * `#9207 `__: scipy.linalg.solve_triangular speed after scipy.linalg.lu_factor * `#9275 `__: new feature: adding LOBPCG solver in svds in addition to ARPACK * `#9403 `__: range of truncnorm.logpdf could be extended * `#9429 `__: gaussian_kde not working with numpy matrix * `#9515 `__: ndimage implementation relies on undefined behavior * `#9643 `__: arpack returns singular values in ascending order * `#9669 `__: DOC: matthew-brett/build-openblas has been retired * `#9852 `__: scipy.spatial.ConvexHull exit with code 134, free(): invalid... * `#9902 `__: scipy.stats.truncnorm second moment may be wrong * `#9943 `__: Custom sampling methods in shgo do not work * `#9947 `__: DOC: Incorrect documentation for \`nan_policy='propagate\` in... * `#9994 `__: BUG: sparse: reshape method allows a shape containing an arbitrary... * `#10036 `__: Official Nelder mead tutorial uses xtol instead of xatol, which... * `#10078 `__: possible to get a better error message when objective function... * `#10092 `__: overflow in truncnorm.rvs * `#10121 `__: A little spelling mistake * `#10126 `__: inaccurate std implementation in binned_statistic * `#10161 `__: Error in documentation scipy.special.modstruve * `#10195 `__: Derivative of spline with 'const' extrapolation is also extrapolted... * `#10206 `__: sparse matrices indexing with scipy 1.3 * `#10236 `__: Non-descriptive error on type mismatch for functions of scipy.optimize... * `#10258 `__: LOBPCG convergence failure if guess provided * `#10262 `__: distance matrix lacks dtype checks / warnings * `#10271 `__: BUG: optimize failure on wheels * `#10277 `__: scipy.special.zeta(0) = NAN * `#10292 `__: DOC/REL: Some sections of the release notes are not nested correctly. * `#10300 `__: scipy.stats.rv_continuous.fit throws empty RuntimeError when... * `#10319 `__: events in scipy.integrate.solve_ivp: How do I setup an events... * `#10323 `__: Adding more low-level LAPACK wrappers * `#10360 `__: firwin2 inadvertently modifies input and may result in undefined... * `#10388 `__: BLD: TestHerd::test_hetrd core dumps with Python-dbg * `#10395 `__: Remove warning about output shape of zoom * `#10403 `__: DOC: scipy.signal.resample ignores t parameter * `#10421 `__: Yeo-Johnson power transformation fails with integer input data * `#10422 `__: BUG: scipy.fft does not support multiprocessing * `#10427 `__: ENH: convolve numbers should be updated * `#10444 `__: BUG: scipy.spatial.transform.Rotation.match_vectors returns improper... * `#10488 `__: ENH: DCTs/DSTs for scipy.fft * `#10501 `__: BUG: scipy.spatial.HalfspaceIntersection works incorrectly * `#10514 `__: BUG: cKDTree GIL handling is incorrect * `#10535 `__: TST: master branch CI failures * `#10588 `__: scipy.fft and numpy.fft inconsistency when axes=None and shape... * `#10628 `__: Scipy python>3.6 Windows wheels don't ship msvcp\*.dll * `#10733 `__: DOC/BUG: min_only result does not match documentation * `#10775 `__: UnboundLocalError in Radau when given a NaN * `#10835 `__: io.wavfile.read unnecessarily raises an error for a bad wav header * `#10838 `__: Error in documentation for scipy.linalg.lu_factor * `#10875 `__: DOC: Graphical guides (using TikZ) * `#10880 `__: setting verbose > 2 in minimize with trust-constr method leads... * `#10887 `__: scipy.signal.signaltools._fftconv_faster has incorrect estimates * `#10948 `__: gammainc(0,x) = nan but should be 1, gammaincc(0,x) = nan but... * `#10952 `__: TestQRdelete_F.test_delete_last_p_col test failure * `#10968 `__: API: Change normalized=False to normalize=True in Rotation * `#10987 `__: Memory leak in shgo triangulation * `#10991 `__: Error running openBlas probably missing a step * `#11033 `__: deadlock on osx for python 3.8 * `#11041 `__: Test failure in wheel builds for TestTf2zpk.test_simple * `#11089 `__: Regression in scipy.stats where distribution will not accept loc and scale parameters Pull requests for 1.4.0 ------------------------------- * `#4591 `__: BUG, TST: Several issues with scipy.signal.residue * `#6629 `__: ENH: sparse: canonicalize on initialization * `#7076 `__: ENH: add complex wavelet support to scipy.signal.cwt. * `#8681 `__: ENH add generalized inverse Gaussian distribution to scipy.stats * `#9064 `__: BUG/ENH: Added default _transpose into LinearOperator. Fixes... * `#9215 `__: ENH: Rbf interpolation of large multi-dimensional data * `#9311 `__: ENH: Added voigt in scipy.special. * `#9642 `__: ENH: integrate: quad() for vector-valued functions * `#9679 `__: DOC: expand docstring of exponweib distribution * `#9684 `__: TST: add ppc64le ci testing * `#9800 `__: WIP : ENH: Refactored _hungarian.py for speed and added a minimize/maximize? * `#9847 `__: DOC: Change integrate tutorial to use solve_ivp instead of odeint * `#9876 `__: ENH: Use rfft when possible in resampling * `#9998 `__: BUG: Do not remove 1s when calling sparse: reshape method #9994 * `#10002 `__: ENH: adds constraints for differential evolution * `#10098 `__: ENH: integrate: add args argument to solve_ivp. * `#10099 `__: DOC: Add missing docs for linprog unknown_options * `#10104 `__: BUG: Rewrite of stats.truncnorm distribution. * `#10105 `__: MAINT improve efficiency of rvs_ratio_uniforms in scipy.stats * `#10107 `__: TST: dual_annealing set seed * `#10108 `__: ENH: stats: improve kendall_tau cache usage * `#10110 `__: MAINT: _lib: Fix a build warning. * `#10114 `__: FIX: only print bounds when supported by minimizer (shgo) * `#10115 `__: TST: Add a test with an almost singular design matrix for lsq_linear * `#10118 `__: MAINT: fix rdist methods in scipy.stats * `#10119 `__: MAINT: improve rvs of randint in scipy.stats * `#10127 `__: Fix typo in record array field name (spatial-ckdtree-sparse_distance? * `#10130 `__: MAINT: ndimage: Fix some compiler warnings. * `#10131 `__: DOC: Note the solve_ivp args enhancement in the 1.4.0 release... * `#10133 `__: MAINT: add rvs for semicircular in scipy.stats * `#10138 `__: BUG: special: Invalid arguments to ellip_harm can crash Python. * `#10139 `__: MAINT: spatial: Fix some compiler warnings in the file distance_wrap.c. * `#10140 `__: ENH: add handling of NaN in RuntimeWarning except clause * `#10142 `__: DOC: return value of scipy.special.comb * `#10143 `__: MAINT: Loosen linprog tol * `#10152 `__: BUG: Fix custom sampling input for shgo, add unittest * `#10154 `__: MAINT: add moments and improve doc of mielke in scipy.stats * `#10158 `__: Issue #6999: read zlib checksum before checking bytes read. * `#10166 `__: BUG: Correctly handle broadcasted ydata in curve_fit pcov computation. * `#10167 `__: DOC: special: Add missing factor of \`i\` to \`modstruve\` docstring * `#10168 `__: MAINT: stats: Fix an incorrect comment. * `#10169 `__: ENH: optimize: Clarify error when objective function returns... * `#10172 `__: DEV: Run tests in parallel when --parallel flag is passed to... * `#10173 `__: ENH: Implement DOP853 ODE integrator * `#10176 `__: Fixed typo * `#10182 `__: TST: fix test issue for stats.pearsonr * `#10184 `__: MAINT: stats: Simplify zmap and zscore (we can use keepdims now). * `#10191 `__: DOC: fix a formatting issue in the scipy.spatial module docstring. * `#10193 `__: DOC: Updated docstring for optimize.nnls * `#10198 `__: DOC, ENH: special: Make \`hyp2f1\` references more specific * `#10202 `__: DOC: Format DST and DCT definitions as latex equations * `#10207 `__: BUG: Compressed matrix indexing should return a scalar * `#10210 `__: DOC: Update docs for connection='weak' in connected_components * `#10225 `__: DOC: Clarify new interfaces for legacy functions in 'optimize' * `#10231 `__: DOC, MAINT: gpg2 updates to release docs / pavement * `#10235 `__: LICENSE: split license file in standard BSD 3-clause and bundled. * `#10238 `__: ENH: Add new scipy.fft module using pocketfft * `#10243 `__: BUG: fix ARFF reader regression with quoted values. * `#10248 `__: DOC: update README file * `#10255 `__: CI: bump OpenBLAS to match wheels * `#10264 `__: TST: add tests for stats.tvar with unflattened arrays * `#10280 `__: MAINT: stats: Use a constant value for sqrt(2/PI). * `#10286 `__: Development Documentation Overhaul * `#10290 `__: MAINT: Deprecate NumPy functions in SciPy root * `#10291 `__: FIX: Avoid importing xdist when checking for availability * `#10295 `__: Disable deprecated Numpy API in __odrpack.c * `#10296 `__: ENH: C++ extension for linear assignment problem * `#10298 `__: ENH: Made pade function work with complex inputs * `#10301 `__: DOC: Fix critical value significance levels in stats.anderson_ksamp * `#10307 `__: Minkowski Distance Type Fix (issue #10262) * `#10309 `__: BUG: Pass jac=None directly to lsoda * `#10310 `__: BUG: interpolate: UnivariateSpline.derivative.ext is 'zeros'... * `#10312 `__: FIX: Fixing a typo in a comment * `#10314 `__: scipy.spatial enhancement request * `#10315 `__: DOC: Update integration tutorial to solve_ivp * `#10318 `__: DOC: update the example for PPoly.solve * `#10333 `__: TST: add tests for stats.tvar with unflattened arrays * `#10334 `__: MAINT: special: Remove deprecated \`hyp2f0\`, \`hyp1f2\`, and... * `#10336 `__: BUG: linalg/interpolative: fix interp_decomp modifying input * `#10341 `__: BUG: sparse.linalg/gmres: deprecate effect of callback on semantics... * `#10344 `__: DOC: improve wording of mathematical formulation * `#10345 `__: ENH: Tiled QR wrappers for scipy.linalg.lapack * `#10350 `__: MAINT: linalg: Use the new fft subpackage in linalg.dft test... * `#10351 `__: BUG: Fix unstable standard deviation calculation in histogram * `#10353 `__: Bug: interpolate.NearestNDInterpolator (issue #10352) * `#10357 `__: DOC: linalg: Refer to scipy.fft.fft (not fftpack) in the dft... * `#10359 `__: DOC: Update roadmap now scipy.fft has been merged * `#10361 `__: ENH: Prefer scipy.fft to scipy.fftpack in scipy.signal * `#10371 `__: DOC: Tweaks to fft documentation * `#10372 `__: DOC: Fix typos * `#10377 `__: TST, MAINT: adjustments for pytest 5.0 * `#10378 `__: ENH: _lib: allow new np.random.Generator in check_random_state * `#10379 `__: BUG: sparse: set writeability to be forward-compatible with numpy>=1.17 * `#10381 `__: BUG: Fixes gh-7491, pdf at x=0 of fisk/burr/burr12/f distributions. * `#10387 `__: ENH: optimize/bfgs: don't evaluate twice at initial point for... * `#10392 `__: [DOC] Add an example for _binned_statistic_dd * `#10396 `__: Remove warning about output shape of zoom * `#10397 `__: ENH: Add check_finite to sp.linalg.norm * `#10399 `__: ENH: Add __round__ method to sparse matrix * `#10407 `__: MAINT: drop pybind11 from install_requires, it's only build-time... * `#10408 `__: TST: use pytest.raises, not numpy assert_raises * `#10409 `__: CI: uninstall nose on Travis * `#10410 `__: [ENH] ncx2 dispatch to chi2 when nc=0 * `#10411 `__: TST: optimize: test should use assert_allclose for fp comparisons * `#10414 `__: DOC: add pybind11 to the other part of quickstart guides * `#10417 `__: DOC: special: don't mark non-ufuncs with a \`[+]\` * `#10423 `__: FIX: Use pybind11::isinstace to check array dtypes * `#10424 `__: DOC: add doctest example for binary data for ttest_ind_from_stats * `#10425 `__: ENH: Add missing Hermitian transforms to scipy.fft * `#10426 `__: MAINT: Fix doc build bugs * `#10431 `__: Update numpy version for AIX * `#10433 `__: MAINT: Minor fixes for the stats * `#10434 `__: BUG: special: make \`ndtri\` return NaN outside domain of definition * `#10435 `__: BUG: Allow integer input data in scipy.stats.yeojohnson * `#10438 `__: [DOC] Add example for kurtosis * `#10440 `__: ENH: special: make \`ellipk\` a ufunc * `#10443 `__: MAINT: ndimage: malloc fail check * `#10447 `__: BLD: Divert output from test compiles into a temporary directory * `#10451 `__: MAINT: signal: malloc fail check * `#10455 `__: BUG: special: fix values of \`hyperu\` for negative \`x\` * `#10456 `__: DOC: Added comment clarifying the call for dcsrch.f in lbfgsb.f * `#10457 `__: BUG: Allow ckdtree to accept empty data input * `#10459 `__: BUG:TST: Compute lwork safely * `#10460 `__: [DOC] Add example to entropy * `#10461 `__: DOC: Quickstart Guide updates * `#10462 `__: TST: special: only show max atol/rtol for test points that failed * `#10465 `__: BUG: Correctly align fft inputs * `#10467 `__: ENH: lower-memory duplicate generator checking in spatial.SphericalVoronoi * `#10470 `__: ENH: Normalise the inverse DCT/DST in scipy.fft * `#10472 `__: BENCH: adjust timeout for slow setup_cache * `#10475 `__: CI: include python debug for Travis-ci * `#10476 `__: TST: special: use \`__tracebackhide__\` to get better error messages * `#10477 `__: ENH: faster region building in spatial.SphericalVoronoi * `#10479 `__: BUG: stats: Fix a few issues with the distributions' fit method. * `#10480 `__: Add RuntimeError in _distn_infrastructure.py in fit() method * `#10481 `__: BENCH, MAINT: wheel_cache_size has been renamed build_cache_size * `#10494 `__: ENH: faster circumcenter calculation in spatial.SphericalVoronoi * `#10500 `__: Splrep _curfit_cache global variable bugfix * `#10503 `__: BUG: spatial/qhull: get HalfspaceIntersection.dual_points from... * `#10506 `__: DOC: interp2d, note nearest neighbor extrapolation * `#10507 `__: MAINT: Remove fortran fftpack library in favour of pypocketfft * `#10508 `__: TST: fix a bug in the circular import test. * `#10509 `__: MAINT: Set up _build_utils as subpackage * `#10516 `__: BUG: Use nogil contexts in cKDTree * `#10517 `__: ENH: fftconvolve should not FFT broadcastable axes * `#10518 `__: ENH: Speedup fftconvolve * `#10520 `__: DOC: Proper .rst formatting for deprecated features and Backwards... * `#10523 `__: DOC: Improve scipy.signal.resample documentation * `#10524 `__: ENH: Add MGC to scipy.stats * `#10525 `__: [ENH] ncx2.ppf dispatch to chi2 when nc=0 * `#10526 `__: DOC: clarify laplacian normalization * `#10528 `__: API: Rename scipy.fft DCT/DST shape argument to s * `#10531 `__: BUG: fixed improper rotations in spatial.transform.rotation.match_vectors * `#10533 `__: [DOC] Add example for winsorize function * `#10539 `__: MAINT: special: don't register \`i0\` with \`numpy.dual\` * `#10540 `__: MAINT: Fix Travis and Circle * `#10542 `__: MAINT: interpolate: use cython_lapack * `#10547 `__: Feature request. Add furthest site Voronoi diagrams to scipy.spatial.plotutils. * `#10549 `__: [BUG] Fix bug in trimr when inclusive=False * `#10552 `__: add scipy.signal.upfirdn signal extension modes * `#10555 `__: MAINT: special: move \`c_misc\` into Cephes * `#10556 `__: [DOC] Add example for trima * `#10562 `__: [DOC] Fix triple string fo trimmed so that __doc__ can show... * `#10563 `__: improve least_squares error msg for mismatched shape * `#10564 `__: ENH: linalg: memoize get_lapack/blas_funcs to speed it up * `#10566 `__: ENH: add implementation of solver for the maximum flow problem * `#10567 `__: BUG: spatial: use c++11 construct for getting start of vector... * `#10568 `__: DOC: special: small tweaks to the \`zetac\` docstring * `#10571 `__: [ENH] Gaussian_kde can accept matrix dataset * `#10574 `__: ENH: linalg: speed up _compute_lwork by avoiding numpy constructs * `#10582 `__: Fix typos with typos in bundled libraries reverted * `#10583 `__: ENH: special: add the analytic continuation of Riemann zeta * `#10584 `__: MAINT: special: clean up \`special.__all__\` * `#10586 `__: BUG: multidimensional scipy.fft functions should accept 's' rather... * `#10587 `__: BUG: integrate/lsoda: never abort run, set error istate instead * `#10594 `__: API: Replicate numpy's fftn behaviour when s is given but not... * `#10599 `__: DOC: dev: update documentation vs. github pull request workflow... * `#10603 `__: MAINT: installer scripts removed * `#10604 `__: MAINT: Change c\*np.ones(...) to np.full(..., c, ...) in many... * `#10608 `__: Univariate splines should require x to be strictly increasing... * `#10613 `__: ENH: Add seed option for gaussian_kde.resample * `#10614 `__: ENH: Add parallel computation to scipy.fft * `#10615 `__: MAINT: interpolate: remove unused header file * `#10616 `__: MAINT: Clean up 32-bit platform xfail markers * `#10618 `__: BENCH: Added 'trust-constr' to minimize benchmarks * `#10621 `__: [MRG] multiple stability updates in lobpcg * `#10622 `__: MAINT: forward port 1.3.1 release notes * `#10624 `__: DOC: stats: Fix spelling of 'support'. * `#10627 `__: DOC: stats: Add references for the alpha distribution. * `#10629 `__: MAINT: special: avoid overflow longer in \`zeta\` for negative... * `#10630 `__: TST: GH10271, relax test assertion, fixes #10271 * `#10631 `__: DOC: nelder-mean uses xatol fixes #10036 * `#10633 `__: BUG: interpolate: integral(a, b) should be zero when both limits... * `#10635 `__: DOC: special: complete hypergeometric functions documentation * `#10636 `__: BUG: special: use series for \`hyp1f1\` when it converges rapidly * `#10641 `__: ENH: allow matching of general bipartite graphs * `#10643 `__: ENH: scipy.sparse.linalg.spsolve triangular unit diagonal * `#10650 `__: ENH: Cythonize sosfilt * `#10654 `__: DOC: Vertical alignment of table entries * `#10655 `__: ENH: Dockerfile for scipy development * `#10660 `__: TST: clean up tests for rvs in scipy.stats * `#10664 `__: Throw error on non-finite input for binned_statistic_dd() * `#10665 `__: DOC: special: improve the docstrings for \`gamma\` and \`gammasgn\` * `#10669 `__: TST: Update scipy.fft real transform tests * `#10670 `__: DOC: Clarify docs and error messages for scipy.signal.butter * `#10672 `__: ENH: return solution attribute when using events in solve_ivp * `#10675 `__: MAINT: special: add an explicit NaN check for \`iv\` arguments * `#10679 `__: DOC: special: Add documentation for \`beta\` function * `#10681 `__: TST: sparse.linalg: fix arnoldi test seed * `#10682 `__: DOC: special: Add documentation for \`betainc\` function * `#10684 `__: TST: special: require Mpmath 1.1.0 for \`test_hyperu_around_0\` * `#10686 `__: FIX: sphinx isattributedescriptor is not available in sphinx... * `#10687 `__: DOC: added Docker quickstart guide by @andyfaff * `#10689 `__: DOC: special: clarify format of parameters/returns sections for... * `#10690 `__: DOC: special: improve docstrings of incomplete gamma functions * `#10692 `__: ENH: higher-dimensional input in \`spatial.SphericalVoronoi\` * `#10694 `__: ENH: ScalarFunction.fun_and_grad * `#10698 `__: DOC: special: Add documentation for \`betaincinv\` * `#10699 `__: MAINT: remove time print lbfgsb fixes #8417 * `#10701 `__: TST, MAINT: bump OpenBLAS to 0.3.7 stable * `#10702 `__: DOC: clarify iterations consume multiple function calls * `#10703 `__: DOC: iprint doc lbfgsb closes #5482 * `#10708 `__: TST: test suggested in gh1758 * `#10710 `__: ENH: Added nan_policy to circ functions in \`stats\` * `#10712 `__: ENH: add axis parameter to stats.entropy * `#10714 `__: DOC: Formatting fix rv_continuous.expect docs * `#10715 `__: DOC: BLD: update doc Makefile for python version; add scipy version... * `#10717 `__: MAINT: modernize doc/Makefile * `#10719 `__: Enable setting minres initial vector * `#10720 `__: DOC: silence random warning in doc build for \`stats.binned_statistic_dd\` * `#10724 `__: DEV: Add doc option to runtests.py * `#10728 `__: MAINT: get rid of gramA, gramB text files that lobpcg tests leave... * `#10732 `__: DOC: add min_only to docstring for Dijkstra's algorithm * `#10734 `__: DOC: spell out difference between source and target in shortest... * `#10735 `__: Fix for Python 4 * `#10739 `__: BUG: optimize/slsqp: deal with singular BFGS update * `#10741 `__: ENH: LAPACK wrappers for ?geequ, ?geequb, ?syequb, ?heequb * `#10742 `__: DOC: special: add to the docstring of \`gammaln\` * `#10743 `__: ENH: special: add a real dispatch for \`wrightomega\` * `#10746 `__: MAINT: Fix typos in comments, docs and test name * `#10747 `__: Remove spurious quotes * `#10750 `__: MAINT: make cython code more precise * `#10751 `__: MAINT: Check that scipy.linalg.lapack functions are documented * `#10752 `__: MAINT: special: use \`sf_error\` in Cephes * `#10755 `__: DOC: cluster: Add 'See Also' and 'Examples' for kmeans2. * `#10763 `__: MAINT: list of minimize methods * `#10768 `__: BUG: Fix corner case for sos2zpk * `#10773 `__: Fix error type for complex input to scipy.fftpack.rfft and irfft * `#10776 `__: ENH: handle geodesic input in \`spatial.SphericalVoronoi\` * `#10777 `__: MAINT: minimizer-->custom should handle the kinds of bounds/constrain?... * `#10781 `__: ENH: solve_triangular C order improvement * `#10787 `__: Fix behavior of \`exp1\` on branch cut and add docstring * `#10789 `__: DOC: special: add parameters/returns doc sections for erfc/erfcx/erfi * `#10790 `__: Travis CI: sudo is deprecated and Xenial is default distro * `#10792 `__: DOC: special: add full docstring for \`expi\` * `#10799 `__: DOC: special: add a complete docstring for \`expn\` * `#10800 `__: Docs edits (GSoD) * `#10802 `__: BUG: fix UnboundLocalError in Radau (scipy#10775) * `#10804 `__: ENH: Speed up next_fast_len with LRU cache * `#10805 `__: DOC: Fix unbalanced quotes in signal.place_poles * `#10809 `__: ENH: Speed up next_fast_len * `#10810 `__: ENH: Raise catchable exceptions for bad Fortran files * `#10811 `__: MAINT: optimize: Remove extra variable from _remove_redundancy_dense * `#10813 `__: MAINT: special: Remove unused variables from _kolmogi and _smirnovi * `#10815 `__: DOC, API: scipy.stats.reciprocal is "log-uniform" * `#10816 `__: MAINT: special: remove deprecated \`bessel_diff_formula\` * `#10817 `__: DOC: special: complete the docstring for \`fresnel\` * `#10820 `__: Fixed compiler_helper.py to allow compilation with ICC on Linux * `#10823 `__: DOC: updated reference guide text for consistency in writing... * `#10825 `__: MAINT: special: change some features of the Voigt function * `#10828 `__: MAINT: integrate: Remove unused variable from init_callback * `#10830 `__: Adding LOBPCG solver in svds in addition to ARPACK * `#10837 `__: WIP: ENH: reduction function for \`spatial.tranform.Rotation\`... * `#10843 `__: ENH: Adding optional parameter to stats.zscores to allow for... * `#10845 `__: Rebase kruskal fix * `#10847 `__: remove redundant __getitem__ from scipy.sparse.lil * `#10848 `__: Better handling of empty (not missing) docstrings * `#10849 `__: ENH: implement rmatmat for LinearOperator * `#10850 `__: MAINT : Refactoring lil List of Lists * `#10851 `__: DOC: add a generative art example to the scipy.spatial tutorial. * `#10852 `__: DOC: linalg: fixed gh-10838 unused imports in example deleted * `#10854 `__: DOC: special: add a full docstring for \`pdtr\` * `#10861 `__: ENH: option to reuse binnumbers in stats.binned_statistic_dd * `#10863 `__: DOC: partial standardization and validation of scipy.stats reference... * `#10865 `__: BUG: special: fix incomplete gamma functions for infinite \`a\` * `#10866 `__: ENH: calculation of mean in spatial.transform.Rotation * `#10867 `__: MAINT: Also store latex directory * `#10869 `__: ENH: Implement overlap-add convolution * `#10870 `__: ENH: Do not raise EOF error if wavfile data read * `#10876 `__: ENH: Add beta-binomial distribution to scipy.stats * `#10878 `__: MAINT: Update R project URL * `#10883 `__: MAINT: (ndimage) More robust check for output being a numpy dtype * `#10884 `__: DOC: Added instructions on adding a new distribution to scipy.stats. * `#10885 `__: [BUG] fix lobpcg with maxiter=None results in Exception * `#10899 `__: ENH: Match R functionality for hmean * `#10900 `__: MAINT: stats: Use keepdims to simplify a few lines in power_divergence. * `#10901 `__: ENH: sparse/linalg: support pydata/sparse matrices * `#10907 `__: Check whether \`maxiter\` is integer * `#10912 `__: ENH: warn user that quad() ignores \`points=...\` when \`weight=...\`... * `#10918 `__: CI: fix Travis CI py3.8 build * `#10920 `__: MAINT: Update constants to codata 2018 values (second try) * `#10921 `__: ENH: scipy.sparse.lil: tocsr accelerated * `#10924 `__: BUG: Forbid passing 'args' as kwarg in scipy.optimize.curve_fit * `#10928 `__: DOC: Add examples to io.wavfile docstrings * `#10934 `__: typo fix * `#10935 `__: BUG: Avoid undefined behaviour on float to unsigned conversion * `#10936 `__: DOC: Added missing example to stats.mstats.variation * `#10939 `__: ENH: scipy.sparse.lil: tocsr accelerated depending on density * `#10946 `__: BUG: setting verbose > 2 in minimize with trust-constr method... * `#10947 `__: DOC: special: small improvements to the \`poch\` docstring * `#10949 `__: BUG: fix return type of erlang_gen._argcheck * `#10951 `__: DOC: fixed Ricker wavelet formula * `#10954 `__: BUG: special: fix \`factorial\` return type for 0-d inputs * `#10955 `__: MAINT: Relax the assert_unitary atol value * `#10956 `__: WIP: make pdtr(int, double) be pdtr(double, double) * `#10957 `__: BUG: Ensure full binary compatibility of long double test data * `#10964 `__: ENH: Make Slerp callable with a scalar argument * `#10972 `__: BUG: Handle complex gains in zpk2sos * `#10975 `__: TST: skip test_kendalltau ppc64le * `#10978 `__: BUG: boxcox data dimension and constancy check #5112 * `#10979 `__: API: Rename dcm to (rotation) matrix in Rotation class * `#10981 `__: MAINT: add support for a==0 and x>0 edge case to igam and igamc * `#10986 `__: MAINT: Remove direct imports from numpy in signaltools.py * `#10988 `__: BUG: signal: fixed issue #10360 * `#10989 `__: FIX binned_statistic_dd Mac wheel test fails * `#10990 `__: BUG: Fix memory leak in shgo triangulation * `#10992 `__: TST: Relax tolerance in upfirdn test_modes * `#10993 `__: TST: bump tolerance in optimize tests * `#10997 `__: MAINT: Rework residue and residuez * `#11001 `__: DOC: Updated Windows build tutorial * `#11004 `__: BUG: integrate/quad_vec: fix several bugs in quad_vec * `#11005 `__: TST: add Python 3.8 Win CI * `#11006 `__: DOC: special: add a reference for \`kl_div\` * `#11012 `__: MAINT: Rework invres and invresz * `#11015 `__: DOC: special: add references for \`rel_entr\` * `#11017 `__: DOC: numpydoc validation of morestats.py * `#11018 `__: MAINT: Filter unrelated warning * `#11031 `__: MAINT: update choose_conv_method for pocketfft implementation * `#11034 `__: MAINT: TST: Skip tests with multiprocessing that use "spawn"... * `#11036 `__: DOC: update doc/README with some more useful content. * `#11037 `__: DOC: special: add a complete docstring for \`rgamma\` * `#11038 `__: DOC: special: add a reference for the polygamma function * `#11042 `__: TST: fix tf2zpk test failure due to incorrect complex sorting. * `#11044 `__: MAINT: choose_conv_method can choose fftconvolution for longcomplex * `#11046 `__: TST: Reduce tolerance for ppc64le with reference lapack * `#11048 `__: DOC: special: add reference for orthogonal polynomial functions * `#11049 `__: MAINT: proper random number initialization and readability fix * `#11051 `__: MAINT: pep8 cleanup * `#11054 `__: TST: bump test precision for dual_annealing SLSQP test * `#11055 `__: DOC: special: add a reference for \`zeta\` * `#11056 `__: API: Deprecated normalized keyword in Rotation * `#11065 `__: DOC: Ubuntu Development Environment Quickstart should not modify... * `#11066 `__: BUG: skip deprecation for numpy top-level types * `#11067 `__: DOC: updated documentation for consistency in writing style * `#11070 `__: DOC: Amendment to Ubuntu Development Environment Quickstart should... * `#11073 `__: DOC: fix 1.4.0 release notes * `#11083 `__: DOC: more 1.4.0 release note fixes * `#11092 `__: BUG: stats: fix freezing of some distributions Checksums ========= MD5 ~~~ 283af03de950a39ecf31564328f88931 scipy-1.4.0rc1-cp35-cp35m-macosx_10_6_intel.whl d327980b440a6f11815f621c3734e0de scipy-1.4.0rc1-cp35-cp35m-manylinux1_i686.whl 10790c7c39eb98e63ad0eff9c17a63ba scipy-1.4.0rc1-cp35-cp35m-manylinux1_x86_64.whl c4d2fc262932c9068ac67ec498d0c2b3 scipy-1.4.0rc1-cp35-cp35m-win32.whl 31a163cf22320fd7dc7d491ac19e7e91 scipy-1.4.0rc1-cp35-cp35m-win_amd64.whl 0f84c55181dd5ce96d1daf0c7be392ec scipy-1.4.0rc1-cp36-cp36m-macosx_10_6_intel.whl 97d356eca6d39c9f130832ec79d0aa53 scipy-1.4.0rc1-cp36-cp36m-manylinux1_i686.whl d71670c4c2791fc3b335b27e94115519 scipy-1.4.0rc1-cp36-cp36m-manylinux1_x86_64.whl a6b733a86b455e1a99c58d5cc9c88807 scipy-1.4.0rc1-cp36-cp36m-win32.whl 9970702ab6ffd2fde68e9d19ba2f1a85 scipy-1.4.0rc1-cp36-cp36m-win_amd64.whl e48bdb4b341881b0d6a6e42b6d40290f scipy-1.4.0rc1-cp37-cp37m-macosx_10_6_intel.whl 508b3a49605840688d7996cc63e34c3d scipy-1.4.0rc1-cp37-cp37m-manylinux1_i686.whl 4ea165ef97d27cc35353d3628754bfa5 scipy-1.4.0rc1-cp37-cp37m-manylinux1_x86_64.whl 2cf7e244907748ea06f7bb61ae5ae391 scipy-1.4.0rc1-cp37-cp37m-win32.whl 36af22c75fd05e45d199fd960fd07def scipy-1.4.0rc1-cp37-cp37m-win_amd64.whl cb896d976a1c5ac930913e7275e8d4f4 scipy-1.4.0rc1-cp38-cp38-macosx_10_9_x86_64.whl 79c2a3d9a33f5d83b6a7cba97bbf5ecd scipy-1.4.0rc1-cp38-cp38-manylinux1_i686.whl 5e220977f0098cc8f440f1368f1ebc3e scipy-1.4.0rc1-cp38-cp38-manylinux1_x86_64.whl 548f18b97844bc068c2df64ee83af012 scipy-1.4.0rc1-cp38-cp38-win32.whl c9ed1c0d77e868f41d1c5dd1899b6fc0 scipy-1.4.0rc1-cp38-cp38-win_amd64.whl e8fef0f2c0305a02fc9acdb385df3f34 scipy-1.4.0rc1.tar.gz 892a34e4d0afbe09dc22cad360eab923 scipy-1.4.0rc1.tar.xz 63e055ef51e94428191824c8d42df715 scipy-1.4.0rc1.zip SHA256 ~~~~~~ 64f9e49dddf97b635ebb1e513b99103db33842035142dd141a83d1dd95f31850 scipy-1.4.0rc1-cp35-cp35m-macosx_10_6_intel.whl bddd8aa1fed04e2e00a5f14703b1955e4b8f0c71bea8ceb926fda0b024666aef scipy-1.4.0rc1-cp35-cp35m-manylinux1_i686.whl f3af484a178e6021d48c5a3d99e35b49db3cf478edf013cac63fdaeb156d81f2 scipy-1.4.0rc1-cp35-cp35m-manylinux1_x86_64.whl 6c4deb6dee25f19867812a51af0551364d9e7bbf76b10389536f9c0a0633308d scipy-1.4.0rc1-cp35-cp35m-win32.whl 7600ea58d37f3603c90d92f89244441021ed6aee0312c9ba9d2cfb73b7d5b72e scipy-1.4.0rc1-cp35-cp35m-win_amd64.whl 39ec6b1a6c1ee678a4bcfe66e37ca6fc432cb074f2f7b6f94e5ee45aa5f6cd21 scipy-1.4.0rc1-cp36-cp36m-macosx_10_6_intel.whl 2777bc70e9700619386161753f8642098cb274a1564d275cc4363bafc601af28 scipy-1.4.0rc1-cp36-cp36m-manylinux1_i686.whl 7654d6e6bd29f22585a9cea6d0b53d860eb344c6816b5f5a3b7954ebf44b40cd scipy-1.4.0rc1-cp36-cp36m-manylinux1_x86_64.whl b0e8a1e21c3c2e7dba71993544360f61998ac78bace70a98e0cc67e7a09bf197 scipy-1.4.0rc1-cp36-cp36m-win32.whl cf4117db3568017b1c8621a0218e91c16e41ae68ebf456f7e9c7780f4ae28aba scipy-1.4.0rc1-cp36-cp36m-win_amd64.whl 3f21e988bfaebeb850ae8d6488ba6cd18ff91b1e7339fcc0a28bafbe876af871 scipy-1.4.0rc1-cp37-cp37m-macosx_10_6_intel.whl e6ff464bc277d23dbd29abb6f2013c0849b3108624b7227af00663959385abd2 scipy-1.4.0rc1-cp37-cp37m-manylinux1_i686.whl ddb942bc84306e4cd4d40fffc31340bafa91f871a3018ef326ac6654f57c7300 scipy-1.4.0rc1-cp37-cp37m-manylinux1_x86_64.whl 0c2b4c99561cbc8e590a6cea9244d3af2e1c429db77cd58253f5e7fc95654faa scipy-1.4.0rc1-cp37-cp37m-win32.whl c574920b788de11b19da2afbfa9c72907dc9789f1f7fc2ce779c5b24f94beca3 scipy-1.4.0rc1-cp37-cp37m-win_amd64.whl d7e16527312df4175a151ea039d16913c28b108611080b34c7aea8fe4812c869 scipy-1.4.0rc1-cp38-cp38-macosx_10_9_x86_64.whl 0b4ffb335bf3de63c75502a1e574fa5a50f16dea22856ae79e6c24f42199244b scipy-1.4.0rc1-cp38-cp38-manylinux1_i686.whl d413d192d10629fbaec2dfbc7455b69e1f68ddf30e832e74461b0ed4e546e13a scipy-1.4.0rc1-cp38-cp38-manylinux1_x86_64.whl 0ab04d014258c81809e07f0379ecebd406bc9004006c7d342c5e40012037ddf9 scipy-1.4.0rc1-cp38-cp38-win32.whl 6e218da2c038ad347d8e07bdcc89878c4e70ee115839551c6ae3c7d569f29ddf scipy-1.4.0rc1-cp38-cp38-win_amd64.whl cbdb4c45bfd6fa474693328023a6da8e921a1919d078f046bda9de0fbc4d4e6f scipy-1.4.0rc1.tar.gz b9a44836fe47cf068d1a3ecc7845f82e9b88b8f37a38ea9a00d32b97d8fec69f scipy-1.4.0rc1.tar.xz 129c1d6c6614bf385c735da806e2f003d121581a40b066438c0823f623295c3a scipy-1.4.0rc1.zip -----BEGIN PGP SIGNATURE----- iQGzBAEBCAAdFiEEuinQzfUTSK0iykiguEZ+VI8xggYFAl3XYkMACgkQuEZ+VI8x ggaqGwv/Y/hZ6d48aEbqUhLjMOu2voz8irASbFvQqNW9jWcKQbN2Dvb5+a38fpur 5kBS1dPxT0J+RDVUhxD3l9dOsf7sY7hrzs7FsDuf3/KVSyIBSJugH5CLY0O2JqC0 /X3NM9re8cfqk7G6aEg0w9h7hfmVkejcWkFjV++jNUu5c0lDMSSSzv8vbr8M4Oji o/cRTl1KkuKTdkaLYqGdgjbnJGREPUPHI3L6ORRQ/QnyRQUdn/0krRRRp/5i2JeU Qr+CmnnD00YlNuP/uKZzxNPNN0oIi4BxdaYzj05W9Rj1i44PuTnGnaPsw1IhgsBs k/plOcMqm1n2pmmigXm5Yb5W7MCy60f70iKB7K7DgdNfLJDCgK2YSUqGj96ULz7g O+ytSemcQB5wTOjFICgsK7AsPSCI5wjimyaQQmZu4EmLO/oKW3DrKie9WFMx75hw bv/Ky+OHyuL+GbYqYpdsyz9X3xqoU9RvH7TlGqAkZk/fRgmdjlwKRN2Oqgs6FJlA XzBMUi2/ =gP0G -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From tyler.je.reddy at gmail.com Fri Nov 22 18:49:58 2019 From: tyler.je.reddy at gmail.com (Tyler Reddy) Date: Fri, 22 Nov 2019 16:49:58 -0700 Subject: [SciPy-Dev] Proposed SciPy 1.4.0 Release Schedule In-Reply-To: References: Message-ID: An attempt at building the wheels for the SciPy 1.3.3 release is underway: https://travis-ci.org/MacPython/scipy-wheels/builds/615811782 https://ci.appveyor.com/project/scipy/scipy-wheels/builds/29063776 If those are successful I will try to get it out soon to address some recent issues affecting DLL loading and multiprocessing tests. On Thu, 21 Nov 2019 at 14:01, Tyler Reddy wrote: > First attempt at 1.4.0rc1 wheel builds are now underway, with > fingers crossed: > > https://travis-ci.org/MacPython/scipy-wheels/builds/615256054 > https://ci.appveyor.com/project/scipy/scipy-wheels/builds/29034442 > > On Sun, 17 Nov 2019 at 01:40, Ralf Gommers wrote: > >> >> >> On Sat, Nov 16, 2019 at 9:12 PM Tyler Reddy >> wrote: >> >>> I branched maintenance/1.4.x at ~10 pm Mountain Time on Nov. 16/2019. >>> >> >> Awesome, thanks Tyler! >> >> Ralf >> >> >>> The SciPy master branch is now open for development of version 1.5.0. >>> >>> Best wishes, >>> Tyler >>> >>> On Fri, 15 Nov 2019 at 22:38, Tyler Reddy >>> wrote: >>> >>>> Please do take a look at the release notes in preparation for 1.4.0 >>>> branching: https://github.com/scipy/scipy/pull/11061 >>>> >>>> The number of pull requests is quite massive (347, I think), so it is a >>>> first draft, but I've transcribed the material from the wiki, made a >>>> no-doubt-controversial draft of release highlights, and tried to curate >>>> author names/mailmap based on the first round of contributor feedback (~144 >>>> authors vs. 97 for 1.3.0). >>>> >>>> On Wed, 13 Nov 2019 at 21:28, Ralf Gommers >>>> wrote: >>>> >>>>> >>>>> >>>>> On Wed, Nov 13, 2019 at 7:35 PM Tyler Reddy >>>>> wrote: >>>>> >>>>>> Alright, shall we aim for a two-day bump on the branching to Nov. >>>>>> 16th (Saturday)? I see we're at ~8 PRs with the milestone now, but I also >>>>>> still have to work on release notes, etc. >>>>>> >>>>> >>>>> Thanks, that sounds good! >>>>> >>>>> >>>>> >>>>>> I'm also expecting one or two surprises to pop up in the wheels repo >>>>>> given major release + 3.8. >>>>>> >>>>>> On Wed, 13 Nov 2019 at 20:21, Ralf Gommers >>>>>> wrote: >>>>>> >>>>>>> Hi Tyler, are you still planning to branch 1.4.x tomorrow? It looks >>>>>>> like there's no real blockers, but there's a bunch of stuff that people >>>>>>> seem to be scrambling to get in, so perhaps a 24-48 hour bump could be >>>>>>> useful. >>>>>>> >>>>>>> Cheers, >>>>>>> Ralf >>>>>>> >>>>>>> >>>>>>> On Tue, Nov 12, 2019 at 8:31 AM Tyler Reddy < >>>>>>> tyler.je.reddy at gmail.com> wrote: >>>>>>> >>>>>>>> Down to 12 open PRs with 1.4.0 milestone--getting closer! >>>>>>>> >>>>>>>> On Sat, 9 Nov 2019 at 21:40, Tyler Reddy >>>>>>>> wrote: >>>>>>>> >>>>>>>>> We currently sit at 31 open PRs and 20 open issues with 1.4.0 >>>>>>>>> milestone. >>>>>>>>> >>>>>>>>> That's a substantial drop in PRs but a rise in issues since the >>>>>>>>> last accounting. Things got >>>>>>>>> a little hectic with Python 3.8 for 1.3.2, but hopefully the >>>>>>>>> wheels stuff is in good shape >>>>>>>>> for 1.4.x series now. >>>>>>>>> >>>>>>>>> Branching in about 5 days is ambitious, but let's aim to stay >>>>>>>>> reasonably on track if possible. >>>>>>>>> >>>>>>>>> On Mon, 21 Oct 2019 at 13:39, Matt Haberland >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Re: 1.2.3 release, I did get a request in gh-10915 >>>>>>>>>> for gh-10498 >>>>>>>>>> to be backported to >>>>>>>>>> 1.2. >>>>>>>>>> >>>>>>>>>> On Mon, Oct 21, 2019 at 8:47 AM Ralf Gommers < >>>>>>>>>> ralf.gommers at gmail.com> wrote: >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Sat, Oct 19, 2019 at 12:24 AM Tyler Reddy < >>>>>>>>>>> tyler.je.reddy at gmail.com> wrote: >>>>>>>>>>> >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> SciPy 1.3.0 was released May 17 (5 months ago), and I think >>>>>>>>>>>> we'd like to keep a roughly biannual release cadence. >>>>>>>>>>>> >>>>>>>>>>>> I'd like to propose the following schedule for 1.4.0: >>>>>>>>>>>> - November 14: branch 1.4.x >>>>>>>>>>>> - November 17: rc1 >>>>>>>>>>>> - December 1: rc2 (if needed) >>>>>>>>>>>> - December 10: final release >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Sounds good to me. >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> The arrival of Python 3.8 and simultaneous responsibility to >>>>>>>>>>>> get at least one more 1.2.x LTS Python 2.7 release out the door means >>>>>>>>>>>> things will probably be busy on the release front until 2020. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> True. I think supporting 3.8 is fairly high-prio, there's a lot >>>>>>>>>>> of demand for it. Doing a 1.3.2 release that supports it would make sense I >>>>>>>>>>> guess. >>>>>>>>>>> >>>>>>>>>>> There don't seem to be any new commits on the 1.2.x branch nor >>>>>>>>>>> urgent Python 2.7 fixes that need to go out. So do we need a 1.2.3 release? >>>>>>>>>>> >>>>>>>>>>> Cheers, >>>>>>>>>>> Ralf >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> As always, it is a good idea to start tagging things that >>>>>>>>>>>> should be in 1.4.0 & please do help with reviewing PRs/issues that are >>>>>>>>>>>> tagged--current counts are: >>>>>>>>>>>> >>>>>>>>>>>> - PRs: 40 open with 1.4.0 milestone >>>>>>>>>>>> - issues: 17 open with 1.4.0 milestone >>>>>>>>>>>> >>>>>>>>>>>> While helping with that, also great if the release notes wiki >>>>>>>>>>>> is updated for appropriate changes: >>>>>>>>>>>> https://github.com/scipy/scipy/wiki/Release-note-entries-for-SciPy-1.4.0 >>>>>>>>>>>> >>>>>>>>>>>> Curating those final notes can be painful if the wiki isn't >>>>>>>>>>>> updated. >>>>>>>>>>>> >>>>>>>>>>>> Thoughts/objections for the schedule? >>>>>>>>>>>> >>>>>>>>>>>> Best wishes, >>>>>>>>>>>> Tyler >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> 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 >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Matt Haberland >>>>>>>>>> Assistant Adjunct Professor in the Program in Computing >>>>>>>>>> Department of Mathematics >>>>>>>>>> 6617A Math Sciences Building, UCLA >>>>>>>>>> _______________________________________________ >>>>>>>>>> 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 >>>>>> >>>>> _______________________________________________ >>>>> 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 tyler.je.reddy at gmail.com Sat Nov 23 16:59:51 2019 From: tyler.je.reddy at gmail.com (Tyler Reddy) Date: Sat, 23 Nov 2019 14:59:51 -0700 Subject: [SciPy-Dev] ANN: SciPy 1.3.3 Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi all, On behalf of the SciPy development team I'm pleased to announce the release of SciPy 1.3.3, a bug fix release that addresses a DLL loading issue for wheels and a multiprocessing test issue. Sources and binary wheels can be found at: https://pypi.org/project/scipy/ and at: https://github.com/scipy/scipy/releases/tag/v1.3.3 One of a few ways to install this release with pip: pip install scipy==1.3.3 ===================== SciPy 1.3.3 Release Notes ===================== SciPy 1.3.3 is a bug-fix release with no new features compared to 1.3.2. In particular, a test suite issue involving multiprocessing was fixed for Windows and Python 3.8 on macOS. Wheels were also updated to place msvcp140.dll at the appropriate location, which was previously causing issues. Authors ======= Ilhan Polat Tyler Reddy Ralf Gommers Issues closed for 1.3.3 -------------------------------- * `#11033 `__: deadlock on osx for python 3.8 Pull requests for 1.3.3 --------------------------------- * `#11034 `__: MAINT: TST: Skip tests with multiprocessing that use "spawn" start method Checksums ========= MD5 ~~~ 69dabfe955c7092f5389a4374db57186 scipy-1.3.3-cp35-cp35m-macosx_10_6_intel.whl 23f3f5f48dc7893b9ff2a9a63adcf8c7 scipy-1.3.3-cp35-cp35m-manylinux1_i686.whl e80281d504225da4b081245ac44081b5 scipy-1.3.3-cp35-cp35m-manylinux1_x86_64.whl 7af194e334c13a9b13f8814f4e1695ce scipy-1.3.3-cp35-cp35m-win32.whl a39a6cb0436572f6149c87036288bd53 scipy-1.3.3-cp35-cp35m-win_amd64.whl e0b74a4370050d48175c5ef91c50dbeb scipy-1.3.3-cp36-cp36m-macosx_10_6_intel.whl 0bd21eb01dc34028d85fd2a9d752caf2 scipy-1.3.3-cp36-cp36m-manylinux1_i686.whl 64d9fb9b4ce5f9869834810dde4bc06f scipy-1.3.3-cp36-cp36m-manylinux1_x86_64.whl ef5d60c5485f9ff7ff0fbc42b4c8d4e5 scipy-1.3.3-cp36-cp36m-win32.whl a3196497b85fc166cd50d7f465674753 scipy-1.3.3-cp36-cp36m-win_amd64.whl 0f6add185264881102ecac2fb5fb141c scipy-1.3.3-cp37-cp37m-macosx_10_6_intel.whl 8d058ca27f5f5b0841f6a7fabcf79aed scipy-1.3.3-cp37-cp37m-manylinux1_i686.whl eb609b74f3603cd4249cc31534a0d531 scipy-1.3.3-cp37-cp37m-manylinux1_x86_64.whl 46530dd85bf3dc2094ac7775b7279d81 scipy-1.3.3-cp37-cp37m-win32.whl b5d3f757675d45f9f69ca0729d012205 scipy-1.3.3-cp37-cp37m-win_amd64.whl 94455bf1e5a6f8bf459bc0971897e2f1 scipy-1.3.3-cp38-cp38-macosx_10_9_x86_64.whl 150c45e2a3c5b14aa089a7f7835212e2 scipy-1.3.3-cp38-cp38-manylinux1_i686.whl c6e464fdb7e928da58a7bd84f389cb74 scipy-1.3.3-cp38-cp38-manylinux1_x86_64.whl 08d3a330ef2469d139527163717fc318 scipy-1.3.3-cp38-cp38-win32.whl 286528ecaab3b56d6405d2775604d18d scipy-1.3.3-cp38-cp38-win_amd64.whl b265efea6ce2f2c1e580cc66bfb8b117 scipy-1.3.3.tar.gz 4c73d4a86f97f41ceface4fc1622e2f7 scipy-1.3.3.tar.xz 5e8182d8b29b04bfc2f19f6bf5ca1fac scipy-1.3.3.zip SHA256 ~~~~~~ a70308bb065562afb936c963780deab359966d71ab4f230368b154dde3136ea4 scipy-1.3.3-cp35-cp35m-macosx_10_6_intel.whl 7be424ee09bed7ced36c9457f99c826ce199fd0c0f5b272cf3d098ff7b29e3ae scipy-1.3.3-cp35-cp35m-manylinux1_i686.whl f5d47351aeb1cb6bda14a8908e56648926a6b2d714f89717c71f7ada41282141 scipy-1.3.3-cp35-cp35m-manylinux1_x86_64.whl 4ba2ce1a58fe117e993cf316a149cf9926c7c5000c0cdc4bc7c56ae8325612f6 scipy-1.3.3-cp35-cp35m-win32.whl c008f1b58f99f1d1cc546957b3effe448365e0a217df1f1894e358906e91edad scipy-1.3.3-cp35-cp35m-win_amd64.whl bb0899d3f8b9fe8ef95b79210cf0deb6709542889fadaa438eeb3a28001e09e7 scipy-1.3.3-cp36-cp36m-macosx_10_6_intel.whl 18ad034be955df046b5a27924cdb3db0e8e1d76aaa22c635403fe7aee17f1482 scipy-1.3.3-cp36-cp36m-manylinux1_i686.whl 2f690ba68ed7caa7c30b6dc48c1deed22c78f3840fa4736083ef4f2bd8baa19e scipy-1.3.3-cp36-cp36m-manylinux1_x86_64.whl b7b8cf45f9a48f23084f19deb9384a1cccb5e92fbc879b12f97dc4d56fb2eb92 scipy-1.3.3-cp36-cp36m-win32.whl 0b8c9dc042b9a47912b18b036b4844029384a5b8d89b64a4901ac3e06876e5f6 scipy-1.3.3-cp36-cp36m-win_amd64.whl 225d0b5e140bb66df23d438c7b535303ce8e533f94454f4e5bde5f8d109103ea scipy-1.3.3-cp37-cp37m-macosx_10_6_intel.whl 884e619821f47eccd42979488d10fa1e15dbe9f3b7660b1c8c928d203bd3c1a3 scipy-1.3.3-cp37-cp37m-manylinux1_i686.whl 583f2ccd6a112656c9feb2345761d2b19e9213a094cfced4e7d2c1cae4173272 scipy-1.3.3-cp37-cp37m-manylinux1_x86_64.whl dfcb0f0a2d8e958611e0b56536285bb435f03746b6feac0e29f045f7c6caf164 scipy-1.3.3-cp37-cp37m-win32.whl b01ea5e4cf95a93dc335089f8fbe97852f56fdb74afff238cbdf09793103b6b7 scipy-1.3.3-cp37-cp37m-win_amd64.whl cfee99d085d562a7e3c4afe51ac1fe9b434363489e565a130459307f30077973 scipy-1.3.3-cp38-cp38-macosx_10_9_x86_64.whl a42b0d02150ef4747e225c31c976a304de5dc8202ec35a27111b7bb8176e5f13 scipy-1.3.3-cp38-cp38-manylinux1_i686.whl 869465c7ff89fc0a1e2ea1642b0c65f1b3c05030f3a4c0d53d6a57b2dba7c242 scipy-1.3.3-cp38-cp38-manylinux1_x86_64.whl 4b8746f4a755bdb2eeb39d6e253a60481e165cfd74fdfb54d27394bd2c9ec8ac scipy-1.3.3-cp38-cp38-win32.whl 546f0dc020b155b8711159d53c87b36591d31f3327c47974a4fb6b50d91589c2 scipy-1.3.3-cp38-cp38-win_amd64.whl 64bf4e8ae0db2d42b58477817f648d81e77f0b381d0ea4427385bba3f959380a scipy-1.3.3.tar.gz 6de202d30b9e9e0704972f2b9272b1ff1090e2b089ddbdccfcf6271ce5ffb2d9 scipy-1.3.3.tar.xz 80ffa587aa910f4b2304cd23d5666dd755968b40036a358114a0b15228a56acc scipy-1.3.3.zip -----BEGIN PGP SIGNATURE----- iQGzBAEBCAAdFiEEuinQzfUTSK0iykiguEZ+VI8xggYFAl3ZoBMACgkQuEZ+VI8x ggbQXAwAwFxwfRudolGeEY15TGRBNSQdKtnL6tE8FQh+1yDAX9rKo+k5ZK34ouWV KDZMcC17SGXA/3hzuqw5Lz3UmcB0xl+st7ltZVUruDK0otU8LqEJLB87fvJgSB4h 7wF+/zvc5TYdVt/3Svd53jYIn95FKKRjuWV/FSO+qNx119DDYx6O4vL1uf4WZutW xEy1nGDn26j0Cc8fGBJE+eOCQFvySwRapqCP/gaRU/TkwYSXdIRWCFtU5WJA24zi 1kU6sk/jKsep07aEE3vc6xsjWCo+D8hca2XLqImnT7hN/djxzcSqk6xJMWyQhr+n kEl6F5SDxombrlLnAM+X6PxWTZZUeeP4R6rVcHIRJxf7Lehke5rKgrhsfX4eqehI 4mnAIu/sph1LDH/78Q/TlUIh7X6chPONOEYcGPtHYCg6mIgfd0DQeyBeYEsE9UkC No01gD11uAf/I9pYpdL918ADiVniRgG+IalbmAkPxvw0dBsfWGPVxWhEktKIloef JI8xhZ8G =e1l0 -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.robitaille at gmail.com Tue Nov 26 04:52:00 2019 From: thomas.robitaille at gmail.com (Thomas Robitaille) Date: Tue, 26 Nov 2019 09:52:00 +0000 Subject: [SciPy-Dev] Making it easier to pin numpy in pyproject.toml Message-ID: Hi all, As a developer of several packages that have numpy as a build-time dependency, I've been having to specify pinned versions of numpy in pyproject.toml files with environment markers, as is done by scipy: https://github.com/scipy/scipy/blob/master/pyproject.toml#L6 I've also noticed that different packages are sometimes inconsistent in what exact versions they use, and the scipy pinnings are also a little more advanced since they take into account the platform too (specifically the AIX case at the moment). I decided to experiment with an idea that might make the whole process easier and reduce burden on developers every time a new Python version is released. The basic idea is to create a meta-package that has a run-time dependency which is a pinned Numpy version, using the same pinnings. For now I've called this package 'oldest-supported-numpy': https://github.com/astrofrog/oldest-supported-numpy https://pypi.org/project/oldest-supported-numpy/ The idea is that with this, a pyproject.toml file can just use: [build-system] requires = ["wheel", "setuptools", "oldest-supported-numpy"] and there would then be one centralized place where we keep the pinnings, and can easily release a new version when a new Python version comes out. I wanted to check whether I might be missing some subtleties that mean that there will be issues with this approach? If not, then is this something that the SciPy community would be interested in using and maintaining? (since it seems a more natural home than just my user account). I'm also not particularly attached to the package name, so this could easily be changed to e.g. pep518-numpy or other options. Thanks! Tom From ralf.gommers at gmail.com Tue Nov 26 21:41:22 2019 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Tue, 26 Nov 2019 18:41:22 -0800 Subject: [SciPy-Dev] Making it easier to pin numpy in pyproject.toml In-Reply-To: References: Message-ID: On Tue, Nov 26, 2019 at 1:52 AM Thomas Robitaille < thomas.robitaille at gmail.com> wrote: > Hi all, > > As a developer of several packages that have numpy as a build-time > dependency, I've been having to specify pinned versions of numpy in > pyproject.toml files with environment markers, as is done by scipy: > > https://github.com/scipy/scipy/blob/master/pyproject.toml#L6 > > I've also noticed that different packages are sometimes inconsistent > in what exact versions they use, and the scipy pinnings are also a > little more advanced since they take into account the platform too > (specifically the AIX case at the moment). > > I decided to experiment with an idea that might make the whole process > easier and reduce burden on developers every time a new Python version > is released. The basic idea is to create a meta-package that has a > run-time dependency which is a pinned Numpy version, using the same > pinnings. For now I've called this package 'oldest-supported-numpy': > > https://github.com/astrofrog/oldest-supported-numpy > https://pypi.org/project/oldest-supported-numpy/ > > The idea is that with this, a pyproject.toml file can just use: > > [build-system] > requires = ["wheel", "setuptools", "oldest-supported-numpy"] > > and there would then be one centralized place where we keep the > pinnings, and can easily release a new version when a new Python > version comes out. > > I wanted to check whether I might be missing some subtleties that mean > that there will be issues with this approach? I think so. Looking at your setup.cfg, you're using install_requires. These are build-time dependencies though, so you should be using setup_requires instead (or as well). Also, your meta-package does itself not have a pyproject.toml. Pip does not understand anything about setup_requires, so I think any build-time dependency you handle via setup.cfg will necessarily invoke easy_install (I think, didn't test), which is something to be avoided. If not, then is this > something that the SciPy community would be interested in using and > maintaining? (since it seems a more natural home than just my user > account). I'm also not particularly attached to the package name, so > this could easily be changed to e.g. pep518-numpy or other options. > Maintaining, perhaps yes - if it works (see above). Getting these dependencies right is hard, so if we can make it easier for packages that want to stay in sync with how SciPy handles the NumPy dependency, that sounds like a sensible idea. On the other hand, for SciPy itself I'd rather just stay with pyproject.toml in its current form I think. A metapackage dependency comes with other costs I suspect. Cheers, Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.gommers at gmail.com Tue Nov 26 21:45:11 2019 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Tue, 26 Nov 2019 18:45:11 -0800 Subject: [SciPy-Dev] Making it easier to pin numpy in pyproject.toml In-Reply-To: References: Message-ID: On Tue, Nov 26, 2019 at 6:41 PM Ralf Gommers wrote: > > > On Tue, Nov 26, 2019 at 1:52 AM Thomas Robitaille < > thomas.robitaille at gmail.com> wrote: > >> Hi all, >> >> As a developer of several packages that have numpy as a build-time >> dependency, I've been having to specify pinned versions of numpy in >> pyproject.toml files with environment markers, as is done by scipy: >> >> https://github.com/scipy/scipy/blob/master/pyproject.toml#L6 >> >> I've also noticed that different packages are sometimes inconsistent >> in what exact versions they use, and the scipy pinnings are also a >> little more advanced since they take into account the platform too >> (specifically the AIX case at the moment). >> >> I decided to experiment with an idea that might make the whole process >> easier and reduce burden on developers every time a new Python version >> is released. The basic idea is to create a meta-package that has a >> run-time dependency which is a pinned Numpy version, using the same >> pinnings. For now I've called this package 'oldest-supported-numpy': >> >> https://github.com/astrofrog/oldest-supported-numpy >> https://pypi.org/project/oldest-supported-numpy/ >> >> The idea is that with this, a pyproject.toml file can just use: >> >> [build-system] >> requires = ["wheel", "setuptools", "oldest-supported-numpy"] >> >> and there would then be one centralized place where we keep the >> pinnings, and can easily release a new version when a new Python >> version comes out. >> >> I wanted to check whether I might be missing some subtleties that mean >> that there will be issues with this approach? > > > I think so. Looking at your setup.cfg, you're using install_requires. > These are build-time dependencies though, so you should be using > setup_requires instead (or as well). > Oh never mind, I think I got it. That does install that lowest NumPy version at build time in the isolated env. Still, I'm not sure if it's 100% equivalent, since it does invoke setuptools and therefore will interact differently with Pip. E.g. the new resolver will have info at a later stage, what happens when build isolation is turned off, etc. Cheers, Ralf > Also, your meta-package does itself not have a pyproject.toml. Pip does > not understand anything about setup_requires, so I think any build-time > dependency you handle via setup.cfg will necessarily invoke easy_install (I > think, didn't test), which is something to be avoided. > > If not, then is this >> something that the SciPy community would be interested in using and >> maintaining? (since it seems a more natural home than just my user >> account). I'm also not particularly attached to the package name, so >> this could easily be changed to e.g. pep518-numpy or other options. >> > > Maintaining, perhaps yes - if it works (see above). Getting these > dependencies right is hard, so if we can make it easier for packages that > want to stay in sync with how SciPy handles the NumPy dependency, that > sounds like a sensible idea. > > On the other hand, for SciPy itself I'd rather just stay with > pyproject.toml in its current form I think. A metapackage dependency comes > with other costs I suspect. > > Cheers, > Ralf > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.gommers at gmail.com Tue Nov 26 23:26:17 2019 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Tue, 26 Nov 2019 20:26:17 -0800 Subject: [SciPy-Dev] new repo: scipy-sphinx-theme-v2 Message-ID: Hi all, After 3 months of work by Shekhar, the new SciPy Sphinx theme is finally close to ready. We have just moved the repo from Shekhar's personal account to https://github.com/scipy/scipy-sphinx-theme-v2. There's a small demo deployment at http://pr-40-scipy-sphinx-theme-v2.surge.sh/, and a deployed version of the NumPy docs built with this theme at http://generated-numpy-docs-14648-2-sphinx2.surge.sh/. Shekhar is still making some further improvements and making it easier to customize the theme. Now is a great time to try this out and give feedback though. Cheers, Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From prabhu at aero.iitb.ac.in Wed Nov 27 00:18:43 2019 From: prabhu at aero.iitb.ac.in (Prabhu Ramachandran) Date: Wed, 27 Nov 2019 10:48:43 +0530 Subject: [SciPy-Dev] Making it easier to pin numpy in pyproject.toml In-Reply-To: References: Message-ID: <5bd0d03c-2653-4766-4571-67b6f642b218@aero.iitb.ac.in> Hi Thomas, Thanks for doing this, I think this would be very useful for multiple projects that use numpy as a build dependency.? I agree with Ralf that it would perhaps make more sense to have a pyproject.toml with the correct requirements in the oldest-supported-numpy project in addition to or in place of the setup.cfg you have. Regards, Prabhu On 11/26/19 3:22 PM, Thomas Robitaille wrote: > Hi all, > > As a developer of several packages that have numpy as a build-time > dependency, I've been having to specify pinned versions of numpy in > pyproject.toml files with environment markers, as is done by scipy: > > https://github.com/scipy/scipy/blob/master/pyproject.toml#L6 > > I've also noticed that different packages are sometimes inconsistent > in what exact versions they use, and the scipy pinnings are also a > little more advanced since they take into account the platform too > (specifically the AIX case at the moment). > [...] -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.robitaille at gmail.com Wed Nov 27 04:32:03 2019 From: thomas.robitaille at gmail.com (Thomas Robitaille) Date: Wed, 27 Nov 2019 09:32:03 +0000 Subject: [SciPy-Dev] Making it easier to pin numpy in pyproject.toml In-Reply-To: <5bd0d03c-2653-4766-4571-67b6f642b218@aero.iitb.ac.in> References: <5bd0d03c-2653-4766-4571-67b6f642b218@aero.iitb.ac.in> Message-ID: Hi Ralf and Prabhu, Thanks for your feedback! I should have clarified this originally, but pyproject.toml (in oldest-supported-numpy) is not the right place to define the Numpy pinnings since pyproject build requirements are only relevant for building wheels of oldest-supported-numpy (they would not be inherited by downstream packages using oldest-supported-numpy). Numpy needs to be a runtime dependency of oldest-supported-numpy because in this case 'runtime' means inside the downstream build environment. In fact, I deliberately have only published a universal wheel (no sdist) on PyPI for oldest-supported-numpy which means that pyproject.toml would never actually be used, and in addition this means that setuptools will not get invoked in the process either. The oldest-supported-numpy wheel only contains a bunch of metadata (no setup.cfg or setup.py) of which the main one that is relevant here is Requires-Dist which I think will be directly interpreted by pip. I will double check with the pip folks but I think that this means that this approach should be equivalent to pinning numpy manually. Cheers, Tom On Wed, 27 Nov 2019 at 05:18, Prabhu Ramachandran wrote: > > Hi Thomas, > > Thanks for doing this, I think this would be very useful for multiple projects that use numpy as a build dependency. I agree with Ralf that it would perhaps make more sense to have a pyproject.toml with the correct requirements in the oldest-supported-numpy project in addition to or in place of the setup.cfg you have. > > Regards, > Prabhu > > > On 11/26/19 3:22 PM, Thomas Robitaille wrote: > > Hi all, > > As a developer of several packages that have numpy as a build-time > dependency, I've been having to specify pinned versions of numpy in > pyproject.toml files with environment markers, as is done by scipy: > > https://github.com/scipy/scipy/blob/master/pyproject.toml#L6 > > I've also noticed that different packages are sometimes inconsistent > in what exact versions they use, and the scipy pinnings are also a > little more advanced since they take into account the platform too > (specifically the AIX case at the moment). > > [...] From stanczakdominik at gmail.com Wed Nov 27 06:54:35 2019 From: stanczakdominik at gmail.com (=?UTF-8?Q?Dominik_Sta=C5=84czak?=) Date: Wed, 27 Nov 2019 12:54:35 +0100 Subject: [SciPy-Dev] new repo: scipy-sphinx-theme-v2 In-Reply-To: References: Message-ID: Hey, Looks nice and clean! One quick feedback note: having the entire site get covered by a solid blue color fading to transparency on every link click is quite annoying. I'd suggest disabling that. Cheers, Dominik On Wed, 27 Nov 2019 at 05:26, Ralf Gommers wrote: > Hi all, > > After 3 months of work by Shekhar, the new SciPy Sphinx theme is finally > close to ready. We have just moved the repo from Shekhar's personal account > to https://github.com/scipy/scipy-sphinx-theme-v2. > > There's a small demo deployment at > http://pr-40-scipy-sphinx-theme-v2.surge.sh/, and a deployed version of > the NumPy docs built with this theme at > http://generated-numpy-docs-14648-2-sphinx2.surge.sh/. > > Shekhar is still making some further improvements and making it easier to > customize the theme. Now is a great time to try this out and give feedback > though. > > 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 scipy-dev at fuglede.dk Wed Nov 27 09:31:30 2019 From: scipy-dev at fuglede.dk (=?iso-8859-1?Q?S=F8ren_Fuglede_J=F8rgensen?=) Date: Wed, 27 Nov 2019 15:31:30 +0100 Subject: [SciPy-Dev] new repo: scipy-sphinx-theme-v2 In-Reply-To: References: Message-ID: <20191127143130.xthlk3hpikchndw3@sleipner.sleipner.fuglede.dk> Hi all, That issue (which I also agree becomes annoying almost immediately) is actually already mentioned in a GitHub issue as well and is not the expected behavior: https://github.com/scipy/scipy-sphinx-theme-v2/issues/47 Do we just add comments as GitHub issues? There could be enough to pollute the mailing list quite heavily. S?ren On Wed, Nov 27, 2019 at 12:54:35PM +0100, Dominik Sta?czak wrote: > Hey, > > Looks nice and clean! One quick feedback note: having the entire site get > covered by a solid blue color fading to transparency on every link click is > quite annoying. I'd suggest disabling that. > > Cheers, > Dominik > > On Wed, 27 Nov 2019 at 05:26, Ralf Gommers wrote: > > > Hi all, > > > > After 3 months of work by Shekhar, the new SciPy Sphinx theme is finally > > close to ready. We have just moved the repo from Shekhar's personal account > > to https://github.com/scipy/scipy-sphinx-theme-v2. > > > > There's a small demo deployment at > > http://pr-40-scipy-sphinx-theme-v2.surge.sh/, and a deployed version of > > the NumPy docs built with this theme at > > http://generated-numpy-docs-14648-2-sphinx2.surge.sh/. > > > > Shekhar is still making some further improvements and making it easier to > > customize the theme. Now is a great time to try this out and give feedback > > though. > > > > 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 From stefanv at berkeley.edu Wed Nov 27 18:34:42 2019 From: stefanv at berkeley.edu (Stefan van der Walt) Date: Wed, 27 Nov 2019 15:34:42 -0800 Subject: [SciPy-Dev] new repo: scipy-sphinx-theme-v2 In-Reply-To: References: Message-ID: <20191127233442.g4clwliwv3yjoebs@aurelius.localdomain> On Wed, 27 Nov 2019 12:54:35 +0100, Dominik Sta?czak wrote: > Looks nice and clean! One quick feedback note: having the entire site get > covered by a solid blue color fading to transparency on every link click is > quite annoying. I'd suggest disabling that. I filed an issue about that as well, but it turns out to be the surge deployment system, not the theme. Best regards, St?fan From ralf.gommers at gmail.com Fri Nov 29 20:40:48 2019 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Fri, 29 Nov 2019 17:40:48 -0800 Subject: [SciPy-Dev] Making it easier to pin numpy in pyproject.toml In-Reply-To: References: <5bd0d03c-2653-4766-4571-67b6f642b218@aero.iitb.ac.in> Message-ID: On Wed, Nov 27, 2019 at 1:32 AM Thomas Robitaille < thomas.robitaille at gmail.com> wrote: > Hi Ralf and Prabhu, > > Thanks for your feedback! I should have clarified this originally, but > pyproject.toml (in oldest-supported-numpy) is not the right place to > define the Numpy pinnings since pyproject build requirements are only > relevant for building wheels of oldest-supported-numpy (they would not > be inherited by downstream packages using oldest-supported-numpy). > Numpy needs to be a runtime dependency of oldest-supported-numpy > because in this case 'runtime' means inside the downstream build > environment. > > In fact, I deliberately have only published a universal wheel (no > sdist) on PyPI for oldest-supported-numpy which means that > pyproject.toml would never actually be used, and in addition this > means that setuptools will not get invoked in the process either. The > oldest-supported-numpy wheel only contains a bunch of metadata (no > setup.cfg or setup.py) of which the main one that is relevant here is > Requires-Dist which I think will be directly interpreted by pip. Ah yes, that sounds correct. So back to your original question: do we want to maintain this under the SciPy org. It sounds like a useful idea to me. What do others think? Also Tom, do you want to remain one of the maintainers of this package when we move it under https://github.com/scipy/? Cheers, Ralf I will double check with the pip folks but I think that this means that > this approach should be equivalent to pinning numpy manually. > > Cheers, > Tom > > On Wed, 27 Nov 2019 at 05:18, Prabhu Ramachandran > wrote: > > > > Hi Thomas, > > > > Thanks for doing this, I think this would be very useful for multiple > projects that use numpy as a build dependency. I agree with Ralf that it > would perhaps make more sense to have a pyproject.toml with the correct > requirements in the oldest-supported-numpy project in addition to or in > place of the setup.cfg you have. > > > > Regards, > > Prabhu > > > > > > On 11/26/19 3:22 PM, Thomas Robitaille wrote: > > > > Hi all, > > > > As a developer of several packages that have numpy as a build-time > > dependency, I've been having to specify pinned versions of numpy in > > pyproject.toml files with environment markers, as is done by scipy: > > > > https://github.com/scipy/scipy/blob/master/pyproject.toml#L6 > > > > I've also noticed that different packages are sometimes inconsistent > > in what exact versions they use, and the scipy pinnings are also a > > little more advanced since they take into account the platform too > > (specifically the AIX case at the moment). > > > > [...] > _______________________________________________ > 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 thomas.robitaille at gmail.com Sat Nov 30 10:30:50 2019 From: thomas.robitaille at gmail.com (Thomas Robitaille) Date: Sat, 30 Nov 2019 15:30:50 +0000 Subject: [SciPy-Dev] Making it easier to pin numpy in pyproject.toml In-Reply-To: References: <5bd0d03c-2653-4766-4571-67b6f642b218@aero.iitb.ac.in> Message-ID: Hi Ralf, On Sat, 30 Nov 2019 at 01:41, Ralf Gommers wrote: > > > > On Wed, Nov 27, 2019 at 1:32 AM Thomas Robitaille wrote: >> >> Hi Ralf and Prabhu, >> >> Thanks for your feedback! I should have clarified this originally, but >> pyproject.toml (in oldest-supported-numpy) is not the right place to >> define the Numpy pinnings since pyproject build requirements are only >> relevant for building wheels of oldest-supported-numpy (they would not >> be inherited by downstream packages using oldest-supported-numpy). >> Numpy needs to be a runtime dependency of oldest-supported-numpy >> because in this case 'runtime' means inside the downstream build >> environment. >> >> In fact, I deliberately have only published a universal wheel (no >> sdist) on PyPI for oldest-supported-numpy which means that >> pyproject.toml would never actually be used, and in addition this >> means that setuptools will not get invoked in the process either. The >> oldest-supported-numpy wheel only contains a bunch of metadata (no >> setup.cfg or setup.py) of which the main one that is relevant here is >> Requires-Dist which I think will be directly interpreted by pip. > > > Ah yes, that sounds correct. > > So back to your original question: do we want to maintain this under the SciPy org. It sounds like a useful idea to me. What do others think? > > Also Tom, do you want to remain one of the maintainers of this package when we move it under https://github.com/scipy/? I'd be happy to still be one of the maintainers - I would just be more comfortable with not being a single point of failure if this becomes a build-time dependency for a number of packages, hence why I thought it would make sense to live under a community organization like scipy. Thanks! Tom > Cheers, > Ralf > > >> I will double check with the pip folks but I think that this means that >> this approach should be equivalent to pinning numpy manually. >> >> Cheers, >> Tom >> >> On Wed, 27 Nov 2019 at 05:18, Prabhu Ramachandran >> wrote: >> > >> > Hi Thomas, >> > >> > Thanks for doing this, I think this would be very useful for multiple projects that use numpy as a build dependency. I agree with Ralf that it would perhaps make more sense to have a pyproject.toml with the correct requirements in the oldest-supported-numpy project in addition to or in place of the setup.cfg you have. >> > >> > Regards, >> > Prabhu >> > >> > >> > On 11/26/19 3:22 PM, Thomas Robitaille wrote: >> > >> > Hi all, >> > >> > As a developer of several packages that have numpy as a build-time >> > dependency, I've been having to specify pinned versions of numpy in >> > pyproject.toml files with environment markers, as is done by scipy: >> > >> > https://github.com/scipy/scipy/blob/master/pyproject.toml#L6 >> > >> > I've also noticed that different packages are sometimes inconsistent >> > in what exact versions they use, and the scipy pinnings are also a >> > little more advanced since they take into account the platform too >> > (specifically the AIX case at the moment). >> > >> > [...] >> _______________________________________________ >> 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