Mailman 3 March 2017 - SciPy-Dev

Are you using Bento to build scipy?
by CJ Carey July 16, 2018

July 16, 2018

With the 1.0 release coming up, I figured this is a good time to take the pulse of the community regarding Bento. The project seems to have been abandoned before reaching stability, and it seems that the core problems it was trying to address have been at least partially fixed by the more official build systems. If you use Bento and would like to keep using it post 1.0, or if my previous sentence is wrong, please let me know!

10 15

FFTLog
by Dieter Werthmüller April 17, 2017

April 17, 2017

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

GSoC applications - next steps
by Ralf Gommers April 3, 2017

April 3, 2017

Hi prospective GSoC participants, The GSoC application deadline is just over a week away, so I thought it'd be useful to give a short overview of what will happen over the next few weeks. Until April 3 we'll do our best to help you write your proposals. Some of you have already shared a draft proposal; I strongly encourage the rest of you to do the same. If you have questions, please make them as concrete as possible (showing that you've done your own reading/research on the topics helps for getting answers). The week after proposal submission we'll interview you (over Skype or Google Hangouts) to help us pick the best applicants. If you are unavailable that week, please let me know now and we'll try to schedule an interview earlier (later is difficult, because we need to indicate how many slots we want to the PSF around the 11th). You'll find out on May 4th if your application was successful. If so, the "community bonding" period starts the next day - this is the time to get more familiar with the project and community: read the developer guide, start interacting on the mailing list, and ensure you're fully set up to hit the ground running on May 30th. April 3: student application deadline April 4-11: SciPy mentors interview students May 4: accepted students announced May 5-30: community bonding period If you have any questions about this, please do ask! Cheers, Ralf

1 1

(no subject)
by Qianhui Wan April 3, 2017

April 3, 2017

Hi all, I'm a senior undergraduate in US. My direction is in applied math and numerical analysis so I want to contribute to our suborg this year :) This is my first time to apply for GSoC. As I mentioned above, I've already had some background in related math and I have some experience in solving PDEs numerically with classical schemes. In the ideas list, I'm more interested in "implement scipy.diff (numerical differentiation)" and "improve the parabolic cylinder functions". For programming languages, I'm a intermediate learner in Python, MATLAB and R, also having some skills in C/C++. If anyone can give me some tips in the requirements of these two projects and proposal writing I'll be very appreciate, and if you have suggestions in choosing projects or developing ideas please let me know. Thanks! Best, Qianhui Qianhui Wan, senior Fall 2016 - Spring 2017, visiting, Math Department, University of Wisconsin, Madison, US Spring 2016, visiting, Math Department, University of California, Berkeley, US Fall 2013 - Spring 2017, Math School, Sun Yat-sen University, Guangzhou, China

3 3

GSoC 2017 : Implementation of scipy.diff
by ashwin.pathak April 1, 2017

April 1, 2017

Hello developers, I have made suggested changes in my proposal. Here is the link of the second iteration of my proposal. Please suggested further changes to the proposal. https://docs.google.com/document/d/1WQwpD4VU3cewBH99a_2-3CcTmhtbclgS6JR1lVX… Thanks in advance

1 0

GSoC Proposal: Circular statistics
by Vladislav Iakovlev March 31, 2017

March 31, 2017

Thanks to Josef and other colleagues for productive discussion! It clarified a lot for me! This is a first iteration of my GSoC proposal. The goal of the project is to implement circular statistics functionality in scipy.stats. Motivation: There exist several Python packages related to this theme, but most of them has some shortcomings. Also, it will be very conveniently to have this functionality in SciPy. It will simplify users work because they will not have to search and install other packages. What will be done: Base class rv_circular that will provide infrastructure for distributions characteristics. List of supposed characteristics: pdf, cdf, moments, mean, dispersion, standard deviation, percentiles, median, entropy, kurtosis, skewness. Derived classes for distributions. Methods for calculating values of characteristics can be redefined in this classes. List of supposed distributions: Uniform distribution, Triangular distribution, Cardioid distribution, Wrapped distributions: Cauchy, Normal, Von Mises. Functions for statistical tests: Tests of uniformity and Goodness-of-Fit. Tests related to Von Mises distribution: tests for mean and concentration parameters, multi-sample tests. Some non-parametric tests. I have developed a little “demo-version” of circular stats toolbox: https://github.com/yakovlevvs/Circular-Statistics It is very raw and will be rewritten; I created this just to demonstrate my vision of how it will be arranged. Approximate timeline: April: Reading books, understanding related mathematics; May – June, 20: Implementing rv_circular class, documentation and tests for it; June, 20 – July, 10: Implementing distribution classes; July, 10 – August, 20: Implementing statistical tests and point estimations; Related literature: Kanti V. Mardia, Peter E. Jupp: Directional statistics, 2000. Jammalamadaka, S. Rao. Topics in circular statistics / S. Rao Jammalamadaka, A. SenGupta.

3 4

'scipy.signal' : Issues/Comments (for GSoC 2017)
by Aman Pratik March 30, 2017

March 30, 2017

Hello developers, I am working on Improving support and features in BSpline in 'scipy.interpolate'. I want to know any issues or difficulties you face when working with bsplines in 'scipy.signal'. If you want to see any changes of modifications that you want related to b-splines, specifically in 'scipy.signal', then please comment on this thread. Thank you

2 1

Github account got deleted
by ashwin.pathak March 29, 2017

March 29, 2017

I don't know how but my github account got deleted without my consent. I have reported this issue to Github and I am waiting for their response. Since, GSoC deadline is also fast approaching , can anyone help me suggesting alternatives to submit proposal or how to get the account back and running as soon as possible ?

3 2

Fwd: Re: GSoC 2017: BSpline support
by Nikolay Mayorov March 29, 2017

March 29, 2017

Resent my answer to the new address. ============ Forwarded message ============ >From : Nikolay Mayorov <nikolay.mayorov(a)zoho.com> To : "SciPy Developers List"<scipy-dev(a)scipy.org> Date : Fri, 24 Mar 2017 01:07:10 +0500 Subject : Re: [SciPy-Dev] GSoC 2017: BSpline support ============ Forwarded message ============ De Boor, "Practical guide to splines", Chapter IX should be the place for your. Likely you will need to thoroughly study several chapters in it, it's not an easy book to quickly pick up a recipe from it. Nikolay. ---- On Thu, 23 Mar 2017 19:31:32 +0500 Aman Pratik <amanpratik10(a)gmail.com> wrote ---- Hello, I need some help with "Convert a CubicSpline/PPoly object to a BSpline". I am unable to find suitable literature for it, or maybe I am overlooking something. I would be really grateful if you could guide me to some reading material or code samples. Thank You On 20 March 2017 at 03:38, Nikolay Mayorov <nikolay.mayorov(a)zoho.com> wrote: _______________________________________________ SciPy-Dev mailing list SciPy-Dev(a)scipy.org https://mail.scipy.org/mailman/listinfo/scipy-dev For future I suggest to put your proposal in markdown format somewhere on github (scipy wiki is a good place). I don't know what is the correct and productive way to review such proposal, so these are some thoughts on some of your points. > Rework the tutorial for scipy.interpolate: The 1D interpolation section prominently recommends interp1d. We likely want to tone it down and recommend instead CubicSpline, Akima1DInterpolator, BSpline etc. This can be done after reading some basics about these algorithms and making the changes as required. Honestly I don't think it is that easy, you definitely need to have a certain taste and interest to rewrite this tutorial. My guess is that you will be able to do it better after you finished the main algorithmic and coding work. > Come up with better names for make_interp_spline/make_lsq_spline routines. This too can be handled after some discussion. I don't think it is necessary to put things like that in the proposal, you'll figure it out (with Evgeni) as the work progresses. > Add string aliases to the bc_type keyword of make_interp_spline to match what CubicSpline allows. I.e. bc_type="natural" should be equivalent to bc_type=((2, 0), (2, 0)) This requires mainly imitating whats there in CubicSpline so wont be very difficult. This can be indeed your first small objective. The documentation for bc_type in make_interp_spline reads "Each of these must be an iterable of pairs (order, value) which gives the values of derivatives of specified orders at the given edge of the interpolation interval." So BSpline is quite general and allows specifying conditions for several derivatives at one end (as opposed to CubicSpline). Maybe it will need some special considerations, just something I noticed. > Convert a CubicSpline object to a BSpline This could be done by assigning the __class__ attribute to the instance. However, since this is not preferred, we may construct a new method which will create a new BSpline object using a CubicSpline object by assigning the corresponding attribute values. (I need your suggestion, which approach to follow?) I believe ideally there should be a factory method like `BSpline.from_ppoly(...)`, as a compromise something like `BSpline.from_cubic_spline`, but I'm not sure whether it will be that valuable in that form. The problem might be not that simple, do some research on now to make conversion between polynomial and B-spline basis. > Knot insertion: BSpline class should grow a method insert_knot (or insert_knots). This can either wrap fitpack.insert directly, or reuse parts of it (e.g. retain the buffer swapping plumbing from _fitpack and reimplement the Fortran routine fitpack/fpinst.f in C or Cython). Since fitpack.insert is already implemented for BSplines, wrapping around it would be the simplest solution as I perceive. As I see there is already a public function insert (implemented in fitpack.py). So just moving it in as a method pretty much does the job. However is the final aim is to move away from FITPACK, then reimplementing insertion algorithm in Cython is useful. Additionally it can be an entry into more serious problems to follow and doing things in Cython. (Btw, I'm not sure what Evgeni meant by "e.g. retain the buffer swapping plumbing".) > Root-finding: At a minimum, sproot should be wrapped into a method of BSpline class. Better still, it should be generalized to allow non-cubic splines. The interface should mirror PPoly.solve and PPoly.roots. This too can be done by imitating PPoly.roots and PPoly.solve. Writing a new implementation for arbitrary spline orders looks like an interesting and challenging problem. Consider doing it instead of just minimal wrapper. All in all the two previous problems, if done in full capacity, don't seem easy and can occupy you for the good part of the GSoC. BSpline Variations:- > Cardinal BSplines (BSplines with equidistant knots). We need representation, evaluation and construction. scipy.signal has some. The task here is to have an interface which is both compatible with regular b-splines and piecewise polynomials and is useful for the signal processing folks. For implementing this feature I will have to read some material to get a good understanding of Cardinal BSplines and its implementation These are two of the places (for now) I would start my study from. The implementation in scipy.signal can be of help. https://en.wikipedia.org/wiki/B-spline#Cardinal_B-spline http://dx.doi.org/10.1016/j.aml.2010.06.029 This task could take a long time, maybe 3 weeks or more. > Spline fitting to data. ATM there's only FITPACK, and we want a more controllable alternative. A first exploratory shot could be to implement de Boors's newknot routine and see how it behaves in real life. This too requires reading of some literature to understand the math and also looking at the FITPACK code for guidance. The following literature can be helpful. https://www.cs.mtu.edu/~shene/COURSES/cs3621/NOTES/spline/B-spline/de-Boor.… https://en.wikipedia.org/wiki/De_Boor%27s_algorithm Both these tasks would take over a month for complete implementation. Generally I suggest to pick (at least for now) one subject most interesting to you and think it through in more details. Now it's unclear what exactly you want to program (which classes, functions, etc.) and time estimates don't look reliable. For "Spline fitting to data" I'm somewhat confused, because make_lsq_spline and make_interp_spline seem to already solve fitting problems without relying on FITPACK. Evgeni, what is the situation here? For now that's all from me. To sum up: focus on fewer things with more details, you don't necessary need to go into the most advanced things. If I'm not mistaken, the whole project can be organized as "get rid of some things from fitpack" and it can be good. I think Evgeni will clarify/comment on things. Nikolay. After looking at the issue tracker #6730 I have made my first proposal for the GSoC project "Improve support for B-splines". This is in continuation with my first mail regarding the same matter. This is a long list of what I think could be done as part of the project. I don't have much knowledge of Splines or B-Splines hence the work plan is not very detailed. Please have a look. Minor changes:- ::: Documentation: > Rework the tutorial for scipy.interpolate: The 1D interpolation section prominently recommends interp1d. We likely want to tone it down and recommend instead CubicSpline, Akima1DInterpolator, BSpline etc. This can be done after reading some basics about these algorithms and making the changes as required. > Come up with better names for make_interp_spline/make_lsq_spline routines. This too can be handled after some discussion. Both these documentation changes can be done within a few days time, 3 to 4 days should be enough. ::: Enhancements: > Add string aliases to the bc_type keyword of make_interp_spline to match what CubicSpline allows. I.e. bc_type="natural" should be equivalent to bc_type=((2, 0), (2, 0)) This requires mainly imitating whats there in CubicSpline so wont be very difficult. > Convert a CubicSpline object to a BSpline This could be done by assigning the __class__ attribute to the instance. However, since this is not preferred, we may construct a new method which will create a new BSpline object using a CubicSpline object by assigning the corresponding attribute values. (I need your suggestion, which approach to follow?) Both these tasks should not take more than 6 to 7 days, including all the documentation and unit tests. Major Enhancements:- > Knot insertion: BSpline class should grow a method insert_knot (or insert_knots). This can either wrap fitpack.insert directly, or reuse parts of it (e.g. retain the buffer swapping plumbing from _fitpack and reimplement the Fortran routine fitpack/fpinst.f in C or Cython). Since fitpack.insert is already implemented for BSplines, wrapping around it would be the simplest solution as I perceive. > Root-finding: At a minimum, sproot should be wrapped into a method of BSpline class. Better still, it should be generalized to allow non-cubic splines. The interface should mirror PPoly.solve and PPoly.roots. This too can be done by imitating PPoly.roots and PPoly.solve. Both these tasks can be completed within 10 days time including all the documentation and tests. BSpline Variations:- > Cardinal BSplines (BSplines with equidistant knots). We need representation, evaluation and construction. scipy.signal has some. The task here is to have an interface which is both compatible with regular b-splines and piecewise polynomials and is useful for the signal processing folks. For implementing this feature I will have to read some material to get a good understanding of Cardinal BSplines and its implementation These are two of the places (for now) I would start my study from. The implementation in scipy.signal can be of help. https://en.wikipedia.org/wiki/B-spline#Cardinal_B-spline http://dx.doi.org/10.1016/j.aml.2010.06.029 This task could take a long time, maybe 3 weeks or more. > Spline fitting to data. ATM there's only FITPACK, and we want a more controllable alternative. A first exploratory shot could be to implement de Boors's newknot routine and see how it behaves in real life. This too requires reading of some literature to understand the math and also looking at the FITPACK code for guidance. The following literature can be helpful. https://www.cs.mtu.edu/~shene/COURSES/cs3621/NOTES/spline/B-spline/de-Boor.… https://en.wikipedia.org/wiki/De_Boor%27s_algorithm Both these tasks would take over a month for complete implementation. optional: I am not sure about the scope of these additions. Also, if we decide to implement these, I am not quite sure they can be completed within the span of GSoC. Probably, we can just take up one of these tasks. > PSpline: The term P-spline stands for "penalized B-spline". It refers to using the B-spline representation where the coefficients are determined partly by the data to be fitted, and partly by an additional penalty function that aims to impose smoothness to avoid overfitting. Adequate literature can be found here, https://projecteuclid.org/download/pdf_1/euclid.ss/1038425655 SAS have already implemented it, https://support.sas.com/documentation/cdl/en/statug/63033/HTML/default/view… This feature could take up a lot of time, including documentation,tests,examples etc. > Non-Uniform Rational B-splines (NURBS): Unlike simple B-splines, the control points each have a weight. The following literature can be helpful, https://en.wikipedia.org/wiki/Non-uniform_rational_B-spline https://www.rhino3d.com/nurbs The following articles can help with the implementation. https://www.codeproject.com/Articles/996281/NURBS-curve-made-easy http://www.nar-associates.com/nurbs/c_code.html#chapter4 This feature too can take up lots of time for full completion. > Constructing periodic splines. Fitpack does it. With full matrices it's straightforward, a naive implementation with banded matrices has issues with numerical stability. We can definitely look into the banded matrix issue if time permits. I am not sure what we may find so cant say anything about the time required. Final Assessment:- After these tasks have been completed. All the new features,methods would undergo rigorous tests and doctests. Benchmark tests could also be added wherever necessary. Features having scope for work could be reported on GitHub. I plan on reading as much as I can related to Cardinal BSplines,De Boor's newknot routine,Penalized BSplines,NURBS etc. before the start of GSoC. This will help me in saving time finding literature related to all these new additions. Looking forward to feedback and corrections. On 16 March 2017 at 20:03, Evgeni Burovski <evgeny.burovskiy(a)gmail.com> wrote: _______________________________________________ SciPy-Dev mailing list SciPy-Dev(a)scipy.org https://mail.scipy.org/mailman/listinfo/scipy-dev On Thu, Mar 16, 2017 at 11:06 AM, Aman Pratik <amanpratik10(a)gmail.com> wrote: Hello Developers, This is Aman Pratik. I am currently pursuing my B.Tech from Indian Institute of Technology, Varanasi. I am a keen software developer and not very new to the open source community. I am interested in your project "Improve support for B-splines" for GSoC 2017. I have been working in Python for the past 2 years and have good idea about Mathematical Methods and Techniques. I am quite familiar with scipy mainly as a user and also as a developer. I also have some experience with Cython. These are the PRs I have worked/working on for the past month. ENH: Add evaluation of periodic splines #6730 DOC: Bad documentation of k in sparse.linalg.eigs See #6990 (Merged) ENH: scipy.linalg.eigsh cannot get all eigenvalues #7004 My GitHub Profile: https://www.github.com/amanp10 I am interested in Mathematical models and functions and therefore willing to work on splines. Also, I am familiar with Benchmark tests, Unit tests and other technical knowledge I would require for this project. I have started my study for the subject and am looking forward to guidance from the potential mentors or other developers. Thank You Hi Aman, and welcome! I see that you already started with https://github.com/scipy/scipy/pull/7185, great! We'll also need a proposal. Since writing a good proposal typically takes several iterations, I encourage you to start working on it, too. When you have a draft, please send it to the list. All the best, Evgeni _______________________________________________ SciPy-Dev mailing list SciPy-Dev(a)scipy.org https://mail.scipy.org/mailman/listinfo/scipy-dev _______________________________________________ SciPy-Dev mailing list SciPy-Dev(a)scipy.org https://mail.scipy.org/mailman/listinfo/scipy-dev

6 13

GSoC 2017 : Implementation of scipy.diff
by ashwin.pathak March 29, 2017

March 29, 2017

Hello Developers, I am applying for GSoC 2017 under the project : Implementation of scipy.diff. Here is my first iteration of my proposal : https://github.com/ashwinpathak20/scipy/wiki/GSoc-2017:-Implement-scipy.dif… Please have a look at it and suggest me all the short-comings and changes to be included. Thanks in advance

3 3