Mailman 3 March 2015 - SciPy-Dev

Split signal.lti class into subclasses
by Felix Berkenkamp 12 Apr '15

12 Apr '15

Hi everyone, I started looking into improving the signal.lti class following the issue discussed at https://github.com/scipy/scipy/issues/2912 The pull request can be found here: https://github.com/scipy/scipy/pull/4576 The main idea is to split the lti class into ss, tf, and zpk subclasses. Calling the lti class itself returns instances of these three subclasses. Advantages * No redundant information (lti class currently holds the information of all 3 classes) * Reduce overhead (creating 3 system representations) * Switching between the different subclasses is more explicit: obj.ss(), obj.tf(), obj.zpk() * Avoids one huge class for everything * Is fully backwards compatible (as far as I can tell) * Similar to what Octave / Matlab does (easier to convert code from there to scipy) Disadvantages: * Accessing properties that are not part of the subclass is more expensive (e.g.: sys = ss(1,1,1,1); sys.num --> this now returns sys.tf().num). Any suggestions / comments / things I've broken? Best, Felix

3 3

Adding routines for updating QR decompositions
by Eric Moore 06 Apr '15

06 Apr '15

Hi, I've just submitted PR #4249 adding qr_update, qr_insert and qr_delete for performing rank-k updates, adding rows or columns and removing rows or colums. https://github.com/scipy/scipy/pull/4249 Comments welcome. Eric.

5 6

Re: [SciPy-Dev] [Numpy-discussion] GSoC students: please read
by Ralf Gommers 04 Apr '15

04 Apr '15

On Mon, Mar 23, 2015 at 10:29 PM, Stephan Hoyer <shoyer(a)gmail.com> wrote: > On Mon, Mar 23, 2015 at 2:21 PM, Ralf Gommers <ralf.gommers(a)gmail.com> > wrote: > >> It's great to see that this year there are a lot of students interested >> in doing a GSoC project with Numpy or Scipy. So far five proposals have >> been submitted, and it looks like several more are being prepared now. >> > > Hi Ralf, > > Is there a centralized place for non-mentors to view proposals and give > feedback? > Hi Stephan, there isn't really. All students post their drafts to the mailing list, where they can get feedback. They're free to keep that draft wherever they want - blogs, Github, StackEdit, ftp sites and more are all being used. The central overview is in Melange (the official GSoC tool), but that's not publicly accessible. Note that an overview of project ideas can be found at https://github.com/scipy/scipy/wiki/GSoC-project-ideas. If you're particularly interested in one or more of those, it should be easy to find back in the mailing list archive what students sent draft proposals for feedback. Your comments on individual proposals will be much appreciated. Cheers, Ralf

1 1

Pull request #4648
by Andreea Georgescu 04 Apr '15

04 Apr '15

Hi, I was wondering if there's anything else I could improve on for the pull request #4688 <https://github.com/scipy/scipy/pull/4648> (Fixes #4408: Vector-valued constraints in minimize() et al). It's still marked as "needs-work", although I followed all the things that Pauli Virtanen suggested. I'm a new contributor to SciPy so I'm not sure what the process is at this stage :). Should I just wait for it to be reviewed and merged, or is there anything else I should do? Thanks! Andreea

2 2

`histogram2` and `signaltonoise` deprecation from `scipy.stats`
by Abraham Escalante 04 Apr '15

04 Apr '15

Hello all, As part of the StatistisCleanup milestone (which I aim to complete by late August) `scipy.stats.histogram2` and `scipy.stats.signaltonoise` are to be deprecated but of course, we would like to get opinions from the community. In short: - `histogram2` is not well tested and is unnecessary since `np.histogram2d` can be used instead. - `signaltonoise` doesn't really belong in `scipy.stats` and it is rarely used. For more details, please refer to issues #602 and #609. If you have an objection or any opinion regarding this please let me know to take it into account. Regards, Abraham Escalante.

2 2

GSoC'15 Idea: Approximation with Parametric Splines
by Anastasiia Tsyplia 04 Apr '15

04 Apr '15

Hello, My name is Anastasiia Tsyplia. I am a 5th-yaer student of National Mining University of Ukraine. I am keen on interpolation/approximation with splines and it was a nice surprise to find out that there is a demand in interpolation improvements amongst the Scipy's ideas for GSoC'15. However, I've spend some time on working out the idea <https://drive.google.com/file/d/0BzveGSDwNVtBanU1THpFTXNKZHc/view?usp=shari…> of my own. Recently I've made a post <http://tsplb.blogspot.com/> dedicated to description of the parametric spline curves construction process and approaches to approximate engineering data by spline functions and parametric spline curves with SciPy. It seems that using parametric spline curves in approximation can be extremely useful and time-saving approach. That's why I would like to share my project idea and hope to hear some feedback as I am about to make a proposal for the Google Summer of Code. I have a 2-year experience in programming with Python, PyOpengl, PyQt, Matplotlib, Numpy & SciPy. Some time I spent to dive into ctypes and scratched the surface of C. Now my priority is Cython. I've read the book on the spline methods recommended on SciPy's idea page, so I feel myself competent in spline methods. I feel free with recursions: the last challenge I faced was implementation of binary space partitioning algorithm in python as I was writing my own ray-tracer. I would like to contribute to SciPy by any means, so I'm ready to receive instructions on my next move. And, certainly I'm looking forward to start dealing with B-Splines in Cython as it is also a part of my project idea. Thanks in advance, Looking forward to receive the feedback, Anastasiia Tsyplia

5 11

Github code for Differential Evolution reevaluations
by James Phillips 03 Apr '15

03 Apr '15

I have just reviewed the Differential Evolution code in github. It is is particularly well coded and most algorithmically thorough, my professional compliments. I noticed in the older DE code I use there is a possible performance improvement, and this seems to be the case in the github code as well. Not every population vector changes within a generation, yet my older code reevaluates the unchanged vectors. Of course this does not change the final results, but is a point of potential savings in total computation time. Respectfully, James Phillips

2 3

Robert Kern's accursed excellent DE implementation
by James Phillips 30 Mar '15

30 Mar '15

I have been using Robert Kern's implementation of the Differential Evolution (DE) genetic algorithm for a decade, for the purpose of guessimating initial parameter estimates for curve fitting and surface fitting in my oprn source pyeq2 fitting library. I can't find anything that works better, which gives rise to my current problem. In trying to improve performance of my fitting library, I tried to use GPU calculations for each generation of the genetic algorithm, I found the following: 1) Robert's 2005 implementation of DE is not parallelizeable, as each crossover withing a generation can affect the population from which new items will be created. That is, within a given generation the population *changes* as the algorithm runs the generation itself, and it must run serially in it's present form. 2) I can rework the algorithm to be parallelizeable by separating out "crossover", "breeding" and "evolving" into three separate steps, but months of testing show that population size and number of generations must beconsiderably increased to match the results from Robert's version. That is, making the algorithm parallelizable means slowing it down so I can speed it up! I would like to increase performance, but cannot find any way to equal Robert's results without reducing performance prior to parallelization. Any suggestions? James

2 6

About Application for GSoC
by Fukumu Tsutsumi 27 Mar '15

27 Mar '15

Hello, my name is Fukumu Tsutsumi. I'm a student at the University of Tokyo, Japan. I'm planning to apply for GSoC with one of SciPy projects, but I deeply regret that I did not notice the deadline is so close (only about a day). I wonder if I can meet the deadline. I'm very eager to participate in GSoC, so wouldn't like to give up this opportunity. I would appreciate if anyone reply for me. Sincerely, Fukumu Tsutsumi

2 4

GSoC students: please read
by Ralf Gommers 27 Mar '15

27 Mar '15

Hi all, It's great to see that this year there are a lot of students interested in doing a GSoC project with Numpy or Scipy. So far five proposals have been submitted, and it looks like several more are being prepared now. I'd like to give you a bit of advice as well as an idea of what's going to happen in the few weeks. The deadline for submitting applications is 27 March. Don't wait until the last day to submit your proposal! It has happened before that Melange was overloaded and unavailable - the Google program admins will not accept that as an excuse and allow you to submit later. So as soon as your proposal is in good shape, put it in. You can still continue revising it. >From 28 March until 13 April we will continue to interact with you, as we request slots from the PSF and rank the proposals. We don't know how many slots we will get this year, but to give you an impression: for the last two years we got 2 slots. Hopefully we can get more this year, but that's far from certain. Our ranking will be based on a combination of factors: the interaction you've had with potential mentors and the community until now (and continue to have), the quality of your submitted PRs, quality and projected impact of your proposal, your enthusiasm, match with potential mentors, etc. We will also organize a video call (Skype / Google Hangout / ...) with each of you during the first half of April to be able to exchange ideas with a higher communication bandwidth medium than email. Finally a note on mentoring: we will be able to mentor all proposals submitted or suggested until now. Due to the large interest and technical nature of a few topics it has in some cases taken a bit long to provide feedback on draft proposals, however there are no showstoppers in this regard. Please continue improving your proposals and working with your potential mentors. Cheers, Ralf

1 1