Mailman 3 December 2016 - SciPy-Dev

FFTLog
by Dieter Werthmüller 17 Apr '17

17 Apr '17

Dear SciPy-devs, I recently had the need for a logarithmic FFT routine, and did a quick f2py around Andrew Hamilton's FFTLog: http://casa.colorado.edu/~ajsh/FFTLog I put my f2py-setup and my pyf-file up on GitHub: https://github.com/prisae/fftlog I thought it might be a useful addition to the SciPy FFTPack. Specifically as three out of the five fortran-files, of which FFTLog consists, are already in scipy/fftpack. I have never contributed to SciPy and therefore do not know how much work it would involve to get it into SciPy. However, I thought I ask. If there is interest I expect that it would not take long for an experienced person, as it is a fairly small addition. Or someone could point me to the right direction on what to do to get it in. I append some comments on the involved files of FFTLog and some comments regarding their licenses. I believe it is compatible with SciPy. Thanks for all your good work! Dieter Files and Licenses/Permissions ------------------------------ Files of FFTLog [1] cdgamma.f [2] drfftb.f [3] drfftf.f [4] drffti.f [5] fftlog.f (plus a test routine, fftlogtest.f) -- [1] -- The original FFTLog states about this file: FFTLog uses [...] and a modified version of the complex Gamma function from the gamerf package at momonga.t.u-tokyo.ac.jp/~ooura/gamerf.html. The original gamerf copyright statement states: Copyright(C) 1996 Takuya OOURA (email: ooura(a)mmm.t.u-tokyo.ac.jp). You may use, copy, modify this code for any purpose and without fee. You may distribute this ORIGINAL package. Permission to distribute the modified gamma function code with the FFTLog package has been granted (email from Takuya Ooura to Andrew Hamilton dated 16 March 1999). Hence I think it is compatible with SciPy, or am I wrong? Alternatively it could be replaced with scipy.special.loggamma, I think, but I do not know if it is possible to mix Fortran and Python code with f2py. -- [2], [3], [4] -- They are from the NCAR suite of FFT routines (Swarztrauber 1979). As far as I can see they are already in SciPy, in scipy/fftpack/src/dfftpack/ (dfftb.f, dfftf.f, and dffti.f). So there is definitely not a licensing problem here. -- [5] -- This is the actual FFTLog routine from Hamilton. I asked Hamilton for permission before publishing his source code at github.com/prisae/fftlog. His email response was: -- start email from 28/09/2016 -- Dieter, You are welcome to use fftlog in any way you choose. Please note the credits commented in the code: c FFTLog uses the NCAR suite of FFT routines, c and a modified version of the complex Gamma function c from the gamerf package at c http://momonga.t.u-tokyo.ac.jp/~ooura/gamerf.html . c The original gamerf copyright statement states: c Copyright(C) 1996 Takuya OOURA (email: ooura(a)mmm.t.u-tokyo.ac.jp). c You may use, copy, modify this code for any purpose and c without fee. You may distribute this ORIGINAL package. c c Permission to distribute the modified gamma function code c with the FFTLog package has been granted c (email from Takuya Ooura to Andrew Hamilton dated 16 March 1999). Andrew -- end email from 28/09/2016 --

5 22

dense output option in integrate.ode
by Evgeni Burovski 20 Feb '17

20 Feb '17

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

3 5

SciPy governance model
by Ralf Gommers 18 Jan '17

18 Jan '17

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

10 33

Arff-handling?
by Moy Git 11 Jan '17

11 Jan '17

Hi folks. My team is writing code to slice and dice arff files: add/delete/update columns, save arffs, join two arffs on a key, append rows, etc. If there's interest in adding this functionality to SciPy's arff module please let me know and I'll send a PR. (Brief description: I'll extend arffread's MetaData class and add Arff and Data classes. Arff will have a convert_to_numpy method, and arffread's loadarff function will just create an Arff and call its convert_to_numpy. This will maintain backward-compatibility and also let us add new stuff to Arff.) Best, Moy

3 4

http://central.scipy.org/ unavailable ?
by Pascal LAUTRIDOU 29 Dec '16

29 Dec '16

I would like to upgrade a snippet that I published in Scipy Central, but for a few weeks, when I try to log on http://central.scipy.org/, I still get a 404 error. Is there a problem with this link, or is there today another way to reach the site? Regards.

2 1

From Python to Numpy
by Nicolas P. Rougier 22 Dec '16

22 Dec '16

Dear all, I've just put online a (kind of) book on Numpy and more specifically about vectorization methods. It's not yet finished, has not been reviewed and it's a bit rough around the edges. But I think there are some material that can be interesting. I'm specifically happy with the boids example that show a nice combination of numpy and matplotlib strengths. Book is online at: http://www.labri.fr/perso/nrougier/from-python-to-numpy/ Sources are available at: https://github.com/rougier/from-python-to-numpy Comments/questions/fixes/ideas are of course welcome. Nicolas

1 0

NumPy 1.12.0rc1
by Charles R Harris 20 Dec '16

20 Dec '16

Hi All, I am pleased to announce the release of NumPy 1.12.0rc1. This release supports Python 2.7 and 3.4 - 3.6 and is the result of 406 pull requests submitted by 139 contributors and comprises a large number of fixes and improvements. Among the many improvements it is difficult to pick out just a few as standing above the others, but the following may be of particular interest or indicate areas likely to have future consequences. * Order of operations in ``np.einsum`` can now be optimized for large speed improvements. * New ``signature`` argument to ``np.vectorize`` for vectorizing with core dimensions. * The ``keepdims`` argument was added to many functions. * New context manager for testing warnings * Support for BLIS in numpy.distutils * Much improved support for PyPy (not yet finished) The release notes are quite sizable and rather than put them inline I've attached them as a file. They may also be viewed at Github <https://github.com/numpy/numpy/releases/tag/v1.12.0rc1>. Zip files and tarballs may also be found the Github link. Wheels and a zip archive are available from PyPI, which is the recommended method of installation. Cheers, Charles Harris

1 0

NumPy 1.11.3 release.
by Charles R Harris 19 Dec '16

19 Dec '16

Hi All, I'm please to annouce the release of NumPy 1.11.3. This is a one bug fix release to take care of a bug that could corrupt large files opened in append mode and then used as an argument to ndarray.tofile. Thanks to Pavel Potocek for the fix. Cheers, Chuck -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ========================== NumPy 1.11.3 Release Notes ========================== Numpy 1.11.3 fixes a bug that leads to file corruption when very large files opened in append mode are used in ``ndarray.tofile``. It supports Python versions 2.6 - 2.7 and 3.2 - 3.5. Wheels for Linux, Windows, and OS X can be found on PyPI. Contributors to maintenance/1.11.3 ================================== A total of 2 people contributed to this release. People with a "+" by their names contributed a patch for the first time. - - Charles Harris - - Pavel Potocek + Pull Requests Merged ==================== - - `#8341 <https://github.com/numpy/numpy/pull/8341>`__: BUG: Fix ndarray.tofile large file corruption in append mode. - - `#8346 <https://github.com/numpy/numpy/pull/8346>`__: TST: Fix tests in PR #8341 for NumPy 1.11.x Checksums ========= MD5 ~~~ f36503c6665701e1ca0fd2953b6419dd numpy-1.11.3-cp27-cp27m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl ada01f12b747c0669be00be843fde6dd numpy-1.11.3-cp27-cp27m-manylinux1_i686.whl e3f454dc204b90015e4d8991b12069fb numpy-1.11.3-cp27-cp27m-manylinux1_x86_64.whl cccfb3f765fa2eb4759590467a5f3fb1 numpy-1.11.3-cp27-cp27mu-manylinux1_i686.whl 479c0c8b50ab0ed4acca0a66887fe74c numpy-1.11.3-cp27-cp27mu-manylinux1_x86_64.whl 110b93cc26ca556b075316bee81f8652 numpy-1.11.3-cp27-none-win32.whl 33bfb4c5f5608d3966a6600fa3d7623c numpy-1.11.3-cp27-none-win_amd64.whl 81df8e91c06595572583cd67fcb7d68f numpy-1.11.3-cp34-cp34m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl 194d8903cb3fd3b17af4093089b1a154 numpy-1.11.3-cp34-cp34m-manylinux1_i686.whl 837d9d7c911d4589172d19d0d8fb4eaf numpy-1.11.3-cp34-cp34m-manylinux1_x86_64.whl f6b24305ab3edba245106b49b97fd9d7 numpy-1.11.3-cp34-none-win32.whl 2f3fdd08d9ad43304d67c16182ff92de numpy-1.11.3-cp34-none-win_amd64.whl f90839ad86e3ccda9a409ce93ca1cccc numpy-1.11.3-cp35-cp35m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl 3b2268154e405f895402cbd4cbcaad7a numpy-1.11.3-cp35-cp35m-manylinux1_i686.whl 3d6754274af48c1c19154dd370ddb569 numpy-1.11.3-cp35-cp35m-manylinux1_x86_64.whl f8b64f46cc0e9a3fc877f24efd5e3b7c numpy-1.11.3-cp35-none-win32.whl b1a53851dde805a233e6c4eafe116e82 numpy-1.11.3-cp35-none-win_amd64.whl b8a9dec6901c046edaea706bad1448b1 numpy-1.11.3.tar.gz aa70cd5bba81b78382694d654ed10036 numpy-1.11.3.zip SHA256 ~~~~~~ 5941d3dbd0afed1ecd3746c0371b2a8b79977d084004cc320c2a4cf9d88589d8 numpy-1.11.3-cp27-cp27m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl ca37b5bebcc4ebde39dfbff0bda69fdc28785a8ff21155fd7adacf473c7b40dd numpy-1.11.3-cp27-cp27m-manylinux1_i686.whl 276cbb35b69eb2f0d5f264b7c71bdc1f4e91ecd3125d32cd1839873268239892 numpy-1.11.3-cp27-cp27m-manylinux1_x86_64.whl 1226e259d796207e8ef36762dce139e7da1cc0bb78f5d54e739252acd07834e5 numpy-1.11.3-cp27-cp27mu-manylinux1_i686.whl 674d0c1318890357f27ce3a8939e643eaf55140cfb8e84730aeee1dd769b0c21 numpy-1.11.3-cp27-cp27mu-manylinux1_x86_64.whl f8b30c76e0f805da7ea641f52c3f6bade55d50a0767f9c89c50e4c42b2a1b34c numpy-1.11.3-cp27-none-win32.whl 8cd184b0341e1db3a5619c85f875ce511ef0eb7ec01ec320116959a3de77f1b8 numpy-1.11.3-cp27-none-win_amd64.whl f0824beb03aff58d4062508b1dd4f737f08f5d2369f25a73c2350fe081beab2c numpy-1.11.3-cp34-cp34m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl 9e4228ac322743dea101a90305ee6d54b4bf82f15d6499e55d1d9cef17bccdbb numpy-1.11.3-cp34-cp34m-manylinux1_i686.whl 195604fc19a9333f3342fcad93094b6a21bc6e6b28d7bfec14d120cb4391a032 numpy-1.11.3-cp34-cp34m-manylinux1_x86_64.whl 71a6aa8b8c9f666b541208d38b30c84df1666e4cc02fb33b59086aaea10affad numpy-1.11.3-cp34-none-win32.whl 135586ce1966dbecd9494ba30cb9beca93fad323ef9264c21efc2a0b59e449d2 numpy-1.11.3-cp34-none-win_amd64.whl cca8af884cbf220656ca2f8f9120a634e5cfb5fdcb0a21fd83ec279cc4f46654 numpy-1.11.3-cp35-cp35m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl ab810c942ead3f5988a7bef95dc6e85b586b6e814b83d571dfbca879e245bd45 numpy-1.11.3-cp35-cp35m-manylinux1_i686.whl 7c6eb737dc3d53977c558d57625dfbecd9900a5807ff17edd6842a102cb95c3b numpy-1.11.3-cp35-cp35m-manylinux1_x86_64.whl ab2af03dabecb97de27badfa944c56d799774a1fa975d52083197bb81858b742 numpy-1.11.3-cp35-none-win32.whl dd1800ec19192fd853bc255917eb3ecb34de268551b9c561f36d089023883807 numpy-1.11.3-cp35-none-win_amd64.whl 6e89f41217028452977cddb2a6c614e2210214bf3efb8494e7a9137b26985d41 numpy-1.11.3.tar.gz 2e0fc5248246a64628656fe14fcab0a959741a2820e003bd15538226501b82f7 numpy-1.11.3.zip -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJYVz6CAAoJEGefIoN3xSR7PUsH/iK2boFNPG2x6RQ2bIvYW/eC iDw5Aewhv5VJRch8QUDAJAVX228Zw4rKY4mxgyXMBvd2ZGL0+E6lMSlooK9r4Sz+ y+lnHyWFc1UjxgQla46TUV77l8PBMjXUKgPQl+Whp8YYwqKd5Q1ZYmDcbNwuNZNc lw7aRcVMF2/hv02B+SYaxp2eo7VQVYf6OJQ3a2Ya8bdLUr2M5kUbVeUk4fpUhQXT FX3E0jFlxELm3y6YkC3mxgyp9kAOOn0d2M7y9IjufOaj7F+oCg+uHMfPTK6EqnoU 7T08Hy8TSdyoUY4ueRsoj3Ns/iwaM88iR133A4UR7vbNkaIDkVhCE/isrdvwbwk= =SJME -----END PGP SIGNATURE-----

1 0

PyPI source files.
by Charles R Harris 19 Dec '16

19 Dec '16

Hi All, It seems that PyPI will only accept one source file at this time, e.g., numpy-1.11.3.zip and numpy-1.11.3.tar.gz are considered duplicates. Does anyone know if this is intentional or a bug on the PyPI end? It makes sense in a screwy sort of way. Chuck

2 1

ENH: Adding simulated annealing method
by Gubian, Sylvain 16 Dec '16

16 Dec '16

Dear SciPy maintainers, I am about to submit a paper about extensive benchmarks in Python of global optimization methods. It includes SciPy ones and some others (like PSO). I know that you guys are very busy with the big chunk of PRs. I have addressed all of the PR comments/suggestions. Do you think you would foresee a merge for this PR. https://github.com/scipy/scipy/pull/6569 Thanks a lot for you time. Best regards, Sylvain.

3 2