Mailman 3 January 2017 - 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

branching 0.19.x soon?
by Ralf Gommers 13 Feb '17

13 Feb '17

Hi all, We had planned the 0.19.0 release for the end of January. We won't make that anymore, but branching this month seems doable (nothing particularly large or blocking in https://github.com/scipy/scipy/milestone/30). @Evgeni, did you plan / want to be the release manager for this release again, or do you want someone else to take that role? Cheers, Ralf

3 7

GSoC'17 participation?
by Ralf Gommers 09 Feb '17

09 Feb '17

Hi all, It's that time of year again, we should think about GSoC participation. For SciPy participating in previous years has definitely been worth it. Here is the ideas page from last year: https://github.com/scipy/scipy/wiki/GSoC-2016-project-ideas (not a whole lot to reuse). New ideas very welcome (ideally with mentor attached ...). Who is interested and available to (co-)mentor this year? Cheers, Ralf

8 13

[Numpy]: making np.gradient support unevenly spaced data
by alebarde＠gmail.com 23 Jan '17

23 Jan '17

Hi all, current version of numpy gradient supports only data with uniform spacing. I have implemented a proposed enhancement for the np.gradient function that allows to compute the gradient on non uniform grids. (PR: https://github.com/numpy/numpy/pull/8446) Since it may be of interest also for the scipy user/developers and it may be useful also for scipy.diff <https://github.com/scipy/scipy/wiki/Proposal:-add-finite-difference-numeric…> I am posting here too. The proposed implementation has a behaviour/signature is similar to that of Matlab/Octave. As argument it can take: 1. A single scalar to specify a sample distance for all dimensions. 2. N scalars to specify a constant sample distance for each dimension. i.e. `dx`, `dy`, `dz`, ... 3. N arrays to specify the coordinates of the values along each dimension of F. The length of the array must match the size of the corresponding dimension 4. Any combination of N scalars/arrays with the meaning of 2. and 3. e.g., you can do the following: >>> f = np.array([[1, 2, 6], [3, 4, 5]], dtype=np.float) >>> dx = 2. >>> y = [1., 1.5, 3.5] >>> np.gradient(f, dx, y) [array([[ 1. , 1. , -0.5], [ 1. , 1. , -0.5]]), array([[ 2. , 2. , 2. ], [ 2. , 1.7, 0.5]])] It should not break any existing code since as of 1.12 only scalars or list of scalars are allowed. A possible alternative API could be pass arrays of sampling steps instead of the coordinates. On the one hand, this would have the advantage of having "differences" both in the scalar case and in the array case. On the other hand, if you are dealing with non uniformly-spaced data (e.g, data is mapped on a grid or it is a time-series), in most cases you already have the coordinates/timestamps. Therefore, in the case of difference as argument, you would almost always have a call np.diff before np.gradient. In the end, I would rather prefer the coordinates option since IMHO it is more handy, I don't think that would be too much "surprising" and it is what Matlab already does. Also, it could not easily lead to "silly" mistakes since the length have to match the size of the corresponding dimension. What do you think? Thanks Alessandro -- -------------------------------------------------------------------------- NOTICE: Dlgs 196/2003 this e-mail and any attachments thereto may contain confidential information and are intended for the sole use of the recipient(s) named above. If you are not the intended recipient of this message you are hereby notified that any dissemination or copying of this message is strictly prohibited. If you have received this e-mail in error, please notify the sender either by telephone or by e-mail and delete the material from any computer. Thank you. --------------------------------------------------------------------------

2 5

API to control iteration in differential evolution #6923
by Denis Laxalde 21 Jan '17

21 Jan '17

Hi, Recently there have been discussions about possible extensions of scipy.optimize.differential_evolution() : * https://github.com/scipy/scipy/issues/6878 is about having the callback function receive the function value * https://github.com/scipy/scipy/issues/6879 is about customizing of population initialization The differential_evolution function being already quite complex, we thought it would be better to expose a "lower level" API to control the iteration in the algorithm. This would be done by making the DifferentialEvolutionSolver class (in scipy/optimize/_differentialevolution.py) public and cleaning it a bit. I submitted a pull request for this : https://github.com/scipy/scipy/pull/6923 One noticeable thing is that it also makes the class a context manager to encapsulate the population initialization (in enter step) and final polishing (in exit step). Ultimately, usage of this class (renamed as DifferentialEvolution) would be: with DifferentialEvolution(func, bounds) as solver: # iterate until maxiter/maxfev is reached or the algorithm converged for step in solver: if mycallback(step.x, step.fun): break result = solver.result I might look a bit fancy, but I think it makes sense to regard a computation as a kind of context. Feedback welcome! Cheers, Denis.

4 7

ENH: added args and kwargs to Xdist
by alebarde＠gmail.com 19 Jan '17

19 Jan '17

Hi all, the current implementations of pdist and cdist takes as keyword arguments some extra parameters for a few specific metrics. At the same time, they do not allow for others args/kwargs that may be needed by a new user-defined metric. Plus, in 0.19 it is possible to call: pdist([[1,2,3]], metric='euclidean', V=[1,2,3], w=[1,2,3]) pdist([[1,2,3]], metric='seuclidean', VI=[1,2,3]) IMHO this is quite strange behaviour since I would have expected an error. In particular, in the second case, the error would also probably help debugging the code since it may be a copy-and-paste typo (seuclidean takes V as kwarg, while mahalanobis requires VI) I have opened a PR (https://github.com/scipy/scipy/pull/6974) that introduces support for *args and **kwargs that gets passed on to the selected metric. The new functions should not break any existing code with the exception of the previous example. However, if needed, I can try to catch those cases, and for now just raise a deprecate warning. what do you think? Alessandro -- -------------------------------------------------------------------------- NOTICE: Dlgs 196/2003 this e-mail and any attachments thereto may contain confidential information and are intended for the sole use of the recipient(s) named above. If you are not the intended recipient of this message you are hereby notified that any dissemination or copying of this message is strictly prohibited. If you have received this e-mail in error, please notify the sender either by telephone or by e-mail and delete the material from any computer. Thank you. --------------------------------------------------------------------------

1 0

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

Re: [SciPy-Dev] [Numpy-discussion] NumPy 1.12.0 release
by Matthew Brett 18 Jan '17

18 Jan '17

Hi, On Tue, Jan 17, 2017 at 5:56 AM, Neal Becker <ndbecker2(a)gmail.com> wrote: > Charles R Harris wrote: > >> Hi All, >> >> I'm pleased to announce the NumPy 1.12.0 release. This release supports >> Python 2.7 and 3.4-3.6. Wheels for all supported Python versions may be >> downloaded from PiPY >> <https://pypi.python.org/pypi?%3Aaction=pkg_edit&name=numpy>, the tarball >> and zip files may be downloaded from Github >> <https://github.com/numpy/numpy/releases/tag/v1.12.0>. The release notes >> and files hashes may also be found at Github >> <https://github.com/numpy/numpy/releases/tag/v1.12.0> . >> >> NumPy 1.12.0rc 2 is the result of 418 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) >> >> Enjoy, >> >> Chuck > > I've installed via pip3 on linux x86_64, which gives me a wheel. My > question is, am I loosing significant performance choosing this pre-built > binary vs. compiling myself? For example, my processor might have some more > features than the base version used to build wheels. I guess you are thinking about using this built wheel on some other machine? You'd have to be lucky for that to work; the wheel depends on the symbols it found at build time, which may not exist in the same places on your other machine. If it does work, the speed will primarily depend on your BLAS library. The pypi wheels should be pretty fast; they are built with OpenBLAS, which is at or near top of range for speed, across a range of platforms. Cheers, Matthew

3 4

GSOC 2017: NumFOCUS will be an umbrella organization
by Max Linke 16 Jan '17

16 Jan '17

Hi Organizations can start submitting applications for Google Summer of Code 2017 on January 19 (and the deadline is February 9) https://developers.google.com/open-source/gsoc/timeline?hl=en NumFOCUS will be applying again this year. If you want to work with us please let me know and if you apply as an organization yourself or under a different umbrella organization please tell me as well. If you participate with us it would be great if you start to add possible projects to the ideas page on github soon. We some general information for mentors on github. https://github.com/numfocus/gsoc/blob/master/CONTRIBUTING-mentors.md We also have a template for ideas that might help. It lists the things Google likes to see. https://github.com/numfocus/gsoc/blob/master/2017/ideas-list-skeleton.md In case you participated in earlier years with NumFOCUS there are some small changes this year. Raniere won't be the admin this year. Instead I'm going to be the admin. We are also planning to include two explicit rules when a student should be failed, they have to communicate regularly and commit code into your development branch at the end of the summer. best, Max

1 0