Hi Ashwin, That looks like a good start. It's clear that in the first sections you've drawn quite a bit on Maniteja's draft from two years ago, but that's fine. There's some places where more detail and proper referencing is required though. I'll comment first on the structure of your approach and timeline, that will need some work. Would be good if you can get a reworked version together with a few days left before the submission deadline. Overall I'd say you need to focus on the two finite differences methods, those will take the bulk of your time. With the rest being taken up by building a test set of problems to verify accuracy of the implementation, and working out the API. Detailed comments on timeline: Week 1-4: this initially confused me, can you please rename those to something else so "week 1" is the first week of the coding period (that's how all proposals are numbered)? Week 2: some of this should be part of your proposal, the idea is that you have something concrete ("algorithm X as described in paper/book Y") to implement in your proposal. Week 3: automatic differentiation, no need to decide on that - that is out of scope for this project. API definition is the first part of your proposed schedule that does fit in the coding period; it should not be at the beginning though. You start with working on one method, API can be fine-tuned later. Week 4: not quite sure what that means. Overall for the community bonding period: I think you can remove some code/API things, but add a few community related items. For example: set up your blog and do a first blog post, then share that on the mailing list to get more feedback from the community. Week 5-6: Things like "Checking of appropriate conditions ..." don't need to be in your proposal, it's pretty meaningless as written. Instead of putting such tasks in your timeline, just put a short description somewhere on when/how you plan to write tests, documentation and benchmarks. Why do you propose an adaptation of scipy.misc.derivative? I'm not sure there's much of value to be rescued from that function (but I haven't checked for a while). What I am missing is a way to validate your implementation. Can you be more concrete about that? Will you use functions with known analytical derivatives only, is there a standard benchmark set that's commonly used in papers that you can use, etc.? Week 7: don't do that, always write tests and docstrings as you go. You can reserve some days to say write an extended tuturial, but not docs/tests. Week 8: some more detail on the complex step size algorithm is needed. And this needs referencing (applies to the adaptive step size algorithm too). Timing: you need to reserve more time for this algorithm, and include testing/integration. Week 10-11: adding a buffer period is fine, but midterm evaluation can't be in your schedule (it doesn't take time). Week 12-13: no autodiff please Week 14-15: I like the cross-testing with other implementations. I'd like to see some more detail here. You could also use packages from other languages to test against if that makes sense. Cheers, Ralf On Wed, Mar 29, 2017 at 5:10 AM, ashwin.pathak < ashwin.pathak@students.iiit.ac.in> wrote:

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.diff-(numerical-differentiation)

Please have a look at it and suggest me all the short-comings and changes to be included.

Thanks in advance _______________________________________________ SciPy-Dev mailing list SciPy-Dev@python.org https://mail.python.org/mailman/listinfo/scipy-dev