Mailman 3 March 2018 - SciPy-Dev

New pull request, fixing ellipj
by Adam March 12, 2018

March 12, 2018

Hello everybody, I've submitted a pull request (8548) to fix issue 8480. The problem here was that whenever m was near 1.0 and u>K, ellipj was producing wildly inaccurate values. (Note that K=ellipk(m), the quarter-period). This was caused by the underlying formula used by the implementation (16.15.4 from Abramowitz and Stegun) that was only valid when phi<pi/2 or u<K. As the original poster (vasilevgmaslov) noted, this method can still be easily applied if we use the periodic properties of the elliptic functions to 'unwind' the phi and only apply 16.15.4 to the principal part or remainder part of phi that is between 0 and pi/2. It was relatively easy for me implement this method and the results agree well with what mpmath returns. I am pinging the dev list just to see if anyone thinks there is any major problem with this fix and to request that this fix gets merged into the main repo. Thank you! Adam

1 0

Numba as a dependency for SciPy?
by Ralf Gommers March 11, 2018

March 11, 2018

Hi all, Goal of this email: start a discussion to decide whether we'd be okay with relying on Numba as a dependency, now or in 1-2 years' time. Context: in https://github.com/pydata/sparse/issues/126 a discussion is ongoing about whether to adopt Cython or Numba, with Numba being preferred by the majority. That `sparse` package is meant to provide sparse *arrays* that down the line should either be replacing our current sparse *matrices* or at least be integrated in scipy.sparse in addition to them. See https://github.com/scipy/scipy/issues/8162 and https://github.com/hameerabbasi/sparse-ndarray-protocols for more details on that. Also related is the question from Serge Guelton some weeks ago about whether we'd want to rely on Pythran: https://mail.python.org/pipermail/scipy-dev/2018-January/022325.html On that Pythran thread I commented that we'd want to take these aspects into account: - portability - performance - maturity - maintenance status (active devs, how quick do bugs get fixed after a release with an issue) - ease of use (@jit vs. Pythran comments vs. translate to .pyx syntax) - size of generated binaries - templating support for multiple dtypes - debugging and optimization experience/tool Debugging is one of the ones where I'd say Numba is still worse than Cython, however that's being resolved as we speak: https://github.com/numba/numba/issues/2788 One thing I missed in the above list is dependencies: while our use of Cython only adds a build-time dependency, Numba would add a run-time dependency. Given that binary wheels and conda packages for all major platforms are available that's not a showstopper, but it matters. Overall I'd say that: - Numba is better than Cython at: performance, ease of use, size of generated binaries, and templating support for multiple dtypes. Possibly also maintenance status right now. - Numba and Cython are about equally good at portability (I think, not much data about exotic platforms for Numba). - Cython is better than Numba at: maturity, debugging (but not for long anymore probably), dependencies. I'm usually pretty conservative in these things, but considering the above I'm leaning towards saying use of Numba should be allowed in the future. The added run-time dependency is the one major downside that's going to stay, however compared to our Fortran headaches that's a relatively small issue. Thoughts? Cheers, Ralf

17 33

discussion of options for vectorized scipy.optimize.zeros.newton
by Mark Mikofski March 10, 2018

March 10, 2018

PR #8357 proposes vectorizing `scipy.optimize.zeros.newton`. Several options have been discussed in the PR, and I would like to get more feedback from the mailing list. (1) The vectorized version causes a speed reduction for the scalar case. Benchmarks using tests from `test_zeros.py` show from 3X to 9X slowdown. For example `test_newton` with a scalar runs in 46[us] but as a numpy 1-item array takes 408[us]. A suggested option was to move the vectorized approach to a private function, to check the inputs in the `newton()`, and call the private vectorized version if the input is not scalar. In this case should we just check the initial guess or all of the extra args? IMO we can't know that all of the args are actually used for calculating the objective, although they probably are, so the only value we know will be used is the initial guess. So if implementing this option, I propose only checking the initial guess. (2) Halting conditions are also a concern. The current implementation in PR #8357 will raise a RuntimeWarning and return the current guess, if any derivative becomes zero, even though the other items in the array may not have converged. A suggested option is to continue to iterate until either all of the derivatives are zero, or the max newton step of the items with a non-zero derivative is less than the specified tolerance. A RuntimeWarning would still be raised if any of the items had a zero derivative, and the message would provide the indices of those items. An additional option I considered was to add a flag to allow the user to specify either early or delayed termination in the situation where zero-derivatives exist. Early termination corresponds to the current implementation in PR #8357 (as of 2f2b3df) and delayed corresponds to the option suggested above. (3) There may be other issues and options I haven't considered. Thanks for your feedback “As I breath in, I calm my body, as I breath out, I smile” - Thich_Nhat_Hanh

1 0

GSOC 2018 [Starting advice, not proposal]
by Aditya Bharti March 10, 2018

March 10, 2018

Hi all, Goal of this email: To ask for general advice on starting contributions to scipy for GSOC 2018 To summarise: I am interested in a project which aligns well with my research and open source experience, but I'm having a little trouble finding issues to start working on. I am an undergraduate researcher in Computer Vision, interested in contributing to scipy. I was specifically looking forward to the second project on the github project ideas page <https://github.com/scipy/scipy/wiki/GSoC-2018-project-ideas#rotation-formal…>: Rotation Formalism in 3 dimensions. I think I would be a good fit for the project because I have experience with contributing to open source in general, and specifically to C++ and python codebases [1] <https://mzl.la/2oV3PtL>. Due to my academic background, I am already comfortable with 3D rotations being represented as matrices, Euler angles and vectors as these are used extensively in Computer Vision. Being a researcher, I will have no problem understanding academic literature on the subject to extend that knowledge. The initial setup completed, in order to get started with contributions to scipy, I have asked around on multiple issues on the main scipy repo with the 'good first issue' tags, however, after discussion it was realised that those bugs either require a very deep understanding of the codebase [2 <https://github.com/scipy/scipy/issues/8385#issuecomment-366196873>] <https://github.com/scipy/scipy/issues/8385#issuecomment-366196873> , or need to be fixed by the external library author and require no work on scipy's side [3] <https://github.com/scipy/scipy/issues/4819#issuecomment-366814744>. I would greatly appreciate it if you could give me advice getting started with scipy or just generally making a strong application to scipy. Thank you, Aditya Bharti (Undergraduate Researcher, International Institute of Information Technology Hyderabad, India) [1]: https://mzl.la/2oV3PtL [2]: https://github.com/scipy/scipy/issues/8385#issuecomment-366196873 [3]: https://github.com/scipy/scipy/issues/4819#issuecomment-36681474 <https://github.com/scipy/scipy/issues/4819#issuecomment-366814744> github: https://github.com/adbugger bugzilla: https://mzl.la/2FyzaMp P.S. I apologise in advance if the mailing list is not the correct place to ask for such advice. I'd be happy to ask on more appropriate channels.

2 1

Re: [SciPy-Dev] scipep repo
by Ralf Gommers March 9, 2018

March 9, 2018

<now reply-all> On Thu, Mar 8, 2018 at 11:02 PM, Ralf Gommers <ralf.gommers(a)gmail.com> wrote: > > > On Fri, Feb 16, 2018 at 9:12 AM, Scott Sievert <sievert.scott(a)gmail.com> > wrote: > >> What should it be called? "seps" is a bit ambiguous, maybe just go for a >> long name "scipy-enhancement-proposals"? >> >> I’ve been calling it “scipeps” for “Scientific Python Enhancement >> Proposals” because I think it plays well with the acronym “SciPy”. >> > > Sounds good to me, more concise than mine. Unless there's last minute > objections, let's go with the `scipeps` repo name and SciPEP acronym' > > But the NumPy and Matplotlib have NEPs and MEPs for {NumPy, Matplotlib} >> Enhancement Proposals respectively. On GitHub, they’re folders (not repos) >> of names “neps”[1] >> > Things are in flux right now: https://github.com/numpy/neps. I'd like to > just copy that setup, but it looks like it will take some days to > stabilize. @Stefan/Jarrod/Nathaniel: are we now keeping neps sources in [1] > and only have autogenerated commits in https://github.com/numpy/neps ? > > Ralf > > and “MEP”[2]. >> Scott >> >> [1]: https://github.com/numpy/numpy/tree/master/doc/neps >> [2]: https://github.com/matplotlib/matplotlib/tree/master/doc/devel/MEP >> >> On February 16, 2018 at 9:00:22 AM, Ralf Gommers (ralf.gommers(a)gmail.com) >> wrote: >> >> >> >> On Fri, Feb 16, 2018 at 2:18 AM, Andrew Nelson <andyfaff(a)gmail.com> >> wrote: >> >>> Scott Sievert and I are writing an enhancement proposal, think of it as >>> a scipep, to make an Optimizer class. Is it worth keeping such proposals in >>> it's own repo, e.g. scipy/scipep? >>> >> >> That seems like a good idea. It follows Python, NumPy, etc. - no need to >> reinvent this wheel. >> >> >>> I'm not sure I can create that myself. >>> >> >> No, only owners can create new repos. What should it be called? "seps" is >> a bit ambiguous, maybe just go for a long name >> "scipy-enhancement-proposals"? >> >> Ralf >> >> >>> >>> _______________________________________________ >>> SciPy-Dev mailing list >>> SciPy-Dev(a)python.org >>> https://mail.python.org/mailman/listinfo/scipy-dev >>> >>> >> _______________________________________________ >> SciPy-Dev mailing list >> SciPy-Dev(a)python.org >> https://mail.python.org/mailman/listinfo/scipy-dev >> >> >

3 2

Strange problem with Kanes Method and Lagrange Method
by Roberto Bucher March 8, 2018

March 8, 2018

I have two scripts which implement method to model a wheeled inverted pendulum, the first one implementing a Kanes method, the second one with Lagrange. Using Kane, I obtain the right result into the "fr+frstar" variable, but after linearization the matrices A and B are completely wrong. The same behavior seems to append with the Lagrange script, where after the Lagrange Method the "form_lagranges_equations()" output is correct but the generated matrices A and B not... In my opinion the right matrices should be: A= np.matrix([ [0, 0, 1, 0], [0, 0, 0, 1], [((L_w*M_w+L_p*M_p)*g)/(L_w^2*M_w-J_w+J_p), 0, 0, 0], [-((L_w*M_w+L_p*M_p)*g)/(L_w^2*M_w-J_w+J_p), 0, 0, 0]] ) B = np.matrix( [0], [0], [-K_t/(L_w^2*M_w-J_w+J_p)], [(K_t*L_w^2*M_w+J_p*K_t)/(J_w*L_w^2*M_w-J_w^2+J_p*J_w)] ) Both scripts are attached Thanks in advance Best regards Roberto

1 0

Re: [SciPy-Dev] Exposing additional window functions in scipy.signal
by Jordan Heemskerk March 7, 2018

March 7, 2018

Greetings, I’m hoping to make a small contribution in the scipy.signal.windows module which exposes an existing private function _cos_win as general_cosine and implements a new general_hamming window. Lately I’ve been coming across these windows in my line of work and having an idiomatic way to produce them through SciPy would be beneficial to me. Although they are not the most common windows, they are used (see PR) and hopefully other members of the community would be interested in having a standard Python implementation. I’ve drafted the potential changes in PR #8534 (https://github.com/scipy/scipy/pull/8534) and am hoping to recruit some reviewers. Thanks, Jordan Heemskerk Urthecast Inc.

1 0

GSoC 2018: Cythonizing
by Lars G. March 7, 2018

March 7, 2018

Dear SciPy devs, I'm currently thinking about an application for this year's GSoC as well. As there already seems to be a large interest in the rotation formalism I'm trying to find another area that matches my interest and skill. I've dug up this proposal in scikit-image from GSoC 2015 https://github.com/scikit-image/scikit-image/wiki/GSoC-2015#rewriting-scipy… and judging by the state of scipy/ndimage/src/ nobody has worked on this proposal yet (feel free to correct me). Alternatively I could imagine something similar for other sub-packages, e.g. scipy/signal which features many source files in C as well. So basically if there is an interest I could try to port C / Python code to Cython. What I would like to know: - Is there an interest? ;) - Is the original proposal in scikit-image still unfinished and are the potential mentors still interested in mentoring? - If there is a general interest to cythonize C or Python code during a GSoC project, which parts / sub-packages of SciPy would you priorize? As for my current involvement with SciPy: - I've already added a small function written in Cython https://github.com/scipy/scipy/pull/8350 - as part of a larger PR extending the signal module https://github.com/scipy/scipy/pull/8264 which will possibly merged this week. - I already cythonized slow parts of the above PR and plan to add these with new PRs after #8264 is merged. If this receives positive feedback I'd be happy to draft a more complete proposal / application based on the discussion around this. Best regards, Lars

7 12

SciPy Central Rescue
by Stefan van der Walt March 7, 2018

March 7, 2018

Hi, everyone Jiayue Li, a student working with me here at BIDS, recently converted the database of the now-defunc SciPy Central into Sphinx-rendered pages: https://machine-shop.github.io/scipy-central-rescue/ The source materials are at: https://github.com/machine-shop/scipy-central-rescue We are happy to move this over to the SciPy repo, and to integrate these materials wherever is most applicable. Let us know! Thanks also to Surya Kasturi who helped us get access to the original database. Best regards, Stéfan

2 1

ANN: SfePy 2018.1
by Robert Cimrman March 6, 2018

March 6, 2018

I am pleased to announce release 2018.1 of SfePy. Description ----------- SfePy (simple finite elements in Python) is a software for solving systems of coupled partial differential equations by the finite element method or by the isogeometric analysis (limited support). It is distributed under the new BSD license. Home page: http://sfepy.org Mailing list: https://mail.python.org/mm3/mailman3/lists/sfepy.python.org/ Git (source) repository, issue tracker: https://github.com/sfepy/sfepy Highlights of this release -------------------------- - major update of time-stepping solvers and solver handling - Newmark and Bathe elastodynamics solvers - interface to MUMPS linear solver - new examples: - iron plate impact problem (elastodynamics) - incompressible Mooney-Rivlin material model (hyperelasticity) as a script For full release notes see http://docs.sfepy.org/doc/release_notes.html#id1 (rather long and technical). Cheers, Robert Cimrman --- Contributors to this release in alphabetical order: Robert Cimrman Jan Heczko Jan Kopacka Vladimir Lukes

1 0