On 03/26/2015 12:58 PM, Oğuzhan Ünlü wrote:

Hi,

Sorry for a bit late reply. I will express my thoughts for Ralf's suggestions, respectively.

Regarding your schedule: - I would remove the parts related to benchmarks. There's no nice benchmark infrastructure in numpy itself at the moment (that's a separate GSoC idea), so the two times 1 week that you have are likely not enough to get something off the ground there.

- I think we can do a sample/demo benchmark only based on a library' speed performance over some basic set of data sets. Couldn't we? Instead of speed, it could be any other performance parameter, we can decide together.

Creating benchmark and performance tracking tools should not be part of this project, but benchmarking is still important. You may have to research learn how to best benchmark this low level code, understand what influences their performance and we need a good set of benchmarks so we know in the end what we have gained by this project. I think the time allocation for this is good.

- The "implement a flexible interface" part will need some discussion, probably it makes sense to first draft a document (call it a NEP - Numpy Enhancement Proposal) that lays out the options and makes a proposal.

To be realistic, I don't think I have enough time to complete an enhancement proposal. Maybe we can talk about it in the first half of April?

I think he means writing the nep proposal should be part of the project, you don't need to have a fleshed out one ready now. Though if you already have some ideas on how the interface might look like this should go into your proposal.

- I wouldn't put "investigate accuracy differences" at the end. What if you find out there that you've been working on something for the whole summer that's not accurate enough?

However, we can't examine possible accuracy differences without having seen their real performance (in my case it is 'implementing an interface to libraries'). Isn't investigating possible libraries for numpy the fountain head of this project? Integrating chosen library can be possible by a small set of wrapping functions.

The accuracy of the libraries can be investigated prior to their integration into numpy, and it should be done early to rule out or de-prioritize bad options. Documenting the trade-offs between performance and accuracy is one of the most important tasks. This also involves researching what kind of inputs to functions may be numerically problematic which depending on your prior numerics knowledge may take some time and should be accounted for.

- The "researching possible options" I would do in the community bonding period - when the coding period starts you should have a fairly well-defined plan.

I agree with you at this point. After moving this to community bounding period, I can put a milestone like 'integrating chosen library to numpy' for 2 weeks. And we decide it would be better to remove benchmark part, then I would use that part for interface, probably.

- 3 weeks for implementing the interface looks optimistic.

It was an estimated time, I asked Julian's opinion about it and waiting his answer. You could be right, I am not familiar with codebase and exact set of functions to be improved. Since I prepared my schedule to serve as basis, I think it is understandable if something takes a bit longer or shorter as compared to what is written on schedule.

I am pretty bad as estimating times, but I think the implementation of interfaces can be done in three weeks if you are confident enough in your C coding abilities and are some experienced in maneuvering foreign code bases.