NumPy/SciPy participation in GSoC 2013
Hi all, It is the time of the year for Google Summer of Code applications. If we want to participate with Numpy and/or Scipy, we need two things: enough mentors and ideas for projects. If we get those, we'll apply under the PSF umbrella. They've outlined the timeline they're working by and guidelines at http://pyfound.blogspot.nl/2013/03/get-ready-for-google-summer-of-code.html. We should be able to come up with some interesting project ideas I'd think, let's put those at http://projects.scipy.org/scipy/wiki/SummerofCodeIdeas. Preferably with enough detail to be understandable for people new to the projects and a proposed mentor. We need at least 3 people willing to mentor a student. Ideally we'd have enough mentors this week, so we can apply to the PSF on time. If you're willing to be a mentor, please send me the following: name, email address, phone nr, and what you're interested in mentoring. If you have time constaints and have doubts about being able to be a primary mentor, being a backup mentor would also be helpful. Cheers, Ralf P.S. as you can probably tell from the above, I'm happy to coordinate the GSoC applications for Numpy and Scipy
On Thu, 2013-03-21 at 22:20 +0100, Ralf Gommers wrote:
Hi all,
It is the time of the year for Google Summer of Code applications. If we want to participate with Numpy and/or Scipy, we need two things: enough mentors and ideas for projects. If we get those, we'll apply under the PSF umbrella. They've outlined the timeline they're working by and guidelines at http://pyfound.blogspot.nl/2013/03/get-ready-for-google-summer-of-code.html.
We should be able to come up with some interesting project ideas I'd think, let's put those at http://projects.scipy.org/scipy/wiki/SummerofCodeIdeas. Preferably with enough detail to be understandable for people new to the projects and a proposed mentor.
Just some more ideas for numpy. I did not think about it much if they fit the GSoC format well, but maybe a possible mentor likes one: 1. Speed improvement for scalars/small arrays. This would start with ideas along the lines currently done by two current pull requests for numpy, that try to improve array + python scalar speed by circumventing costly scalar -> array conversions, etc. And continue to improving the speed for finding the correct ufunc (which I believe Nathaniel timed to be a pretty big factor). But it would touch a lot of numpy internals probably, so the learning curve may be pretty steep. 2. Implement stable summation. Basically it would be about creating generalized ufuncs (if that is possible) implementing different kinds of stable summation algorithms for the inexact types and then adding it as an option to np.sum. 3. This has been suggested before in some way or another, but improving of the subclassing of arrays. Though I am unsure if user code might dislike changes, even if it is improvement... It would start of with checking which python side functions should explicitly call __array_wrap__ (possible writing more helpers to do it) and calling it more consistently plus adding the context information where it is currently not added (only simple ufunc calls add it, not even reductions I think). I am sure you can dig a lot deeper into it all, but it would require some serious thinking and is not straight forward. 4. Partial sorting. This would be about implementing partial sorting and O(N) median calculation into numpy. Plus maybe new functions that can make use of it (though I don't know what exactly that would be, but these functions could also have a home in scipy not numpy).
We need at least 3 people willing to mentor a student. Ideally we'd have enough mentors this week, so we can apply to the PSF on time. If you're willing to be a mentor, please send me the following: name, email address, phone nr, and what you're interested in mentoring. If you have time constaints and have doubts about being able to be a primary mentor, being a backup mentor would also be helpful.
Cheers, Ralf
P.S. as you can probably tell from the above, I'm happy to coordinate the GSoC applications for Numpy and Scipy
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
On Thu, Mar 21, 2013 at 10:20 PM, Ralf Gommers <ralf.gommers@gmail.com>wrote:
Hi all,
It is the time of the year for Google Summer of Code applications. If we want to participate with Numpy and/or Scipy, we need two things: enough mentors and ideas for projects. If we get those, we'll apply under the PSF umbrella. They've outlined the timeline they're working by and guidelines at http://pyfound.blogspot.nl/2013/03/get-ready-for-google-summer-of-code.html.
We should be able to come up with some interesting project ideas I'd think, let's put those at http://projects.scipy.org/scipy/wiki/SummerofCodeIdeas. Preferably with enough detail to be understandable for people new to the projects and a proposed mentor.
We need at least 3 people willing to mentor a student. Ideally we'd have enough mentors this week, so we can apply to the PSF on time. If you're willing to be a mentor, please send me the following: name, email address, phone nr, and what you're interested in mentoring. If you have time constaints and have doubts about being able to be a primary mentor, being a backup mentor would also be helpful.
So far we've only got one primary mentor (thanks Chuck!), most core devs do not seem to have the bandwidth this year. If there are other people interested in mentoring please let me know. If not, then it looks like we're not participating this year. Ralf
On Tue, Mar 26, 2013 at 12:27 AM, Ralf Gommers <ralf.gommers@gmail.com>wrote:
On Thu, Mar 21, 2013 at 10:20 PM, Ralf Gommers <ralf.gommers@gmail.com>wrote:
Hi all,
It is the time of the year for Google Summer of Code applications. If we want to participate with Numpy and/or Scipy, we need two things: enough mentors and ideas for projects. If we get those, we'll apply under the PSF umbrella. They've outlined the timeline they're working by and guidelines at http://pyfound.blogspot.nl/2013/03/get-ready-for-google-summer-of-code.html.
We should be able to come up with some interesting project ideas I'd think, let's put those at http://projects.scipy.org/scipy/wiki/SummerofCodeIdeas. Preferably with enough detail to be understandable for people new to the projects and a proposed mentor.
We need at least 3 people willing to mentor a student. Ideally we'd have enough mentors this week, so we can apply to the PSF on time. If you're willing to be a mentor, please send me the following: name, email address, phone nr, and what you're interested in mentoring. If you have time constaints and have doubts about being able to be a primary mentor, being a backup mentor would also be helpful.
So far we've only got one primary mentor (thanks Chuck!), most core devs do not seem to have the bandwidth this year. If there are other people interested in mentoring please let me know. If not, then it looks like we're not participating this year.
Hi all, an update on GSoC'13. We do have enough mentoring power after all; NumPy/SciPy is now registered as a participating project on the PSF page: http://wiki.python.org/moin/SummerOfCode/2013 Prospective students: please have a look at http://wiki.python.org/moin/SummerOfCode/Expectations and at http://projects.scipy.org/scipy/wiki/SummerofCodeIdeas. In particular note that we require you to make one pull request to NumPy/SciPy which has to be merged *before* the application deadline (May 3). So please start thinking about that, and start a discussion on your project idea on this list. Cheers, Ralf
On Mon, Apr 1, 2013 at 1:58 PM, Ralf Gommers <ralf.gommers@gmail.com> wrote:
On Tue, Mar 26, 2013 at 12:27 AM, Ralf Gommers <ralf.gommers@gmail.com>wrote:
On Thu, Mar 21, 2013 at 10:20 PM, Ralf Gommers <ralf.gommers@gmail.com>wrote:
Hi all,
It is the time of the year for Google Summer of Code applications. If we want to participate with Numpy and/or Scipy, we need two things: enough mentors and ideas for projects. If we get those, we'll apply under the PSF umbrella. They've outlined the timeline they're working by and guidelines at http://pyfound.blogspot.nl/2013/03/get-ready-for-google-summer-of-code.html.
We should be able to come up with some interesting project ideas I'd think, let's put those at http://projects.scipy.org/scipy/wiki/SummerofCodeIdeas. Preferably with enough detail to be understandable for people new to the projects and a proposed mentor.
We need at least 3 people willing to mentor a student. Ideally we'd have enough mentors this week, so we can apply to the PSF on time. If you're willing to be a mentor, please send me the following: name, email address, phone nr, and what you're interested in mentoring. If you have time constaints and have doubts about being able to be a primary mentor, being a backup mentor would also be helpful.
So far we've only got one primary mentor (thanks Chuck!), most core devs do not seem to have the bandwidth this year. If there are other people interested in mentoring please let me know. If not, then it looks like we're not participating this year.
Hi all, an update on GSoC'13. We do have enough mentoring power after all; NumPy/SciPy is now registered as a participating project on the PSF page: http://wiki.python.org/moin/SummerOfCode/2013
Prospective students: please have a look at http://wiki.python.org/moin/SummerOfCode/Expectations and at http://projects.scipy.org/scipy/wiki/SummerofCodeIdeas. In particular note that we require you to make one pull request to NumPy/SciPy which has to be merged *before* the application deadline (May 3). So please start thinking about that, and start a discussion on your project idea on this list.
Cheers, Ralf
_______________________________________________ SciPy-Dev mailing list SciPy-Dev@scipy.org http://mail.scipy.org/mailman/listinfo/scipy-dev
There were a number of other ideas in this thread: http://mail.scipy.org/pipermail/numpy-discussion/2013-March/065699.html
On Mon, Apr 1, 2013 at 2:27 PM, Todd <toddrjen@gmail.com> wrote:
On Mon, Apr 1, 2013 at 1:58 PM, Ralf Gommers <ralf.gommers@gmail.com>wrote:
On Tue, Mar 26, 2013 at 12:27 AM, Ralf Gommers <ralf.gommers@gmail.com>wrote:
On Thu, Mar 21, 2013 at 10:20 PM, Ralf Gommers <ralf.gommers@gmail.com>wrote:
Hi all,
It is the time of the year for Google Summer of Code applications. If we want to participate with Numpy and/or Scipy, we need two things: enough mentors and ideas for projects. If we get those, we'll apply under the PSF umbrella. They've outlined the timeline they're working by and guidelines at http://pyfound.blogspot.nl/2013/03/get-ready-for-google-summer-of-code.html.
We should be able to come up with some interesting project ideas I'd think, let's put those at http://projects.scipy.org/scipy/wiki/SummerofCodeIdeas. Preferably with enough detail to be understandable for people new to the projects and a proposed mentor.
We need at least 3 people willing to mentor a student. Ideally we'd have enough mentors this week, so we can apply to the PSF on time. If you're willing to be a mentor, please send me the following: name, email address, phone nr, and what you're interested in mentoring. If you have time constaints and have doubts about being able to be a primary mentor, being a backup mentor would also be helpful.
So far we've only got one primary mentor (thanks Chuck!), most core devs do not seem to have the bandwidth this year. If there are other people interested in mentoring please let me know. If not, then it looks like we're not participating this year.
Hi all, an update on GSoC'13. We do have enough mentoring power after all; NumPy/SciPy is now registered as a participating project on the PSF page: http://wiki.python.org/moin/SummerOfCode/2013
Prospective students: please have a look at http://wiki.python.org/moin/SummerOfCode/Expectations and at http://projects.scipy.org/scipy/wiki/SummerofCodeIdeas. In particular note that we require you to make one pull request to NumPy/SciPy which has to be merged *before* the application deadline (May 3). So please start thinking about that, and start a discussion on your project idea on this list.
Cheers, Ralf
_______________________________________________ SciPy-Dev mailing list SciPy-Dev@scipy.org http://mail.scipy.org/mailman/listinfo/scipy-dev
There were a number of other ideas in this thread:
http://mail.scipy.org/pipermail/numpy-discussion/2013-March/065699.html
Thanks Todd. Your idea 5 is pretty much what Nathaniel just detailed out, it's on the ideas page now. That should enable idea 1 as well. The other idea that got some positive feedback was 3: http://mail.scipy.org/pipermail/numpy-discussion/2013-March/065710.html. If you or someone else could make that a little more concrete, we can put that up. Ralf
On Tue, Apr 2, 2013 at 8:12 PM, Ralf Gommers <ralf.gommers@gmail.com> wrote:
On Mon, Apr 1, 2013 at 2:27 PM, Todd <toddrjen@gmail.com> wrote:
There were a number of other ideas in this thread:
http://mail.scipy.org/pipermail/numpy-discussion/2013-March/065699.html
Thanks Todd. Your idea 5 is pretty much what Nathaniel just detailed out, it's on the ideas page now. That should enable idea 1 as well. The other idea that got some positive feedback was 3: http://mail.scipy.org/pipermail/numpy-discussion/2013-March/065710.html. If you or someone else could make that a little more concrete, we can put that up.
For 3: With structured arrays, you can access them by name (key) in a manner identical to dictionaries: y = x['f'] It also has a method for accessing the list of names (keys): x.dtype.names This should be maintained for backwards-compatibility, but these methods should also be added: x.keys -- returns a list of field names x.values -- returns a list of views into the array, one for each structure x.items -- returns a list of tuple containing name/structure pairs (the structures being a views) x.iterkeys/itervalues/iteritems -- returns an iterable over the corresponding objects (should not be available in python 3) x.viewkeys/viewvalues/viewitems -- the same as the corresponding item, since they always return views (should not be available in python 3) x.has_key -- tests if a field name is present (should not be available in python 3, should use "key in x.keys()") x.get -- get a field by name, returning a default array (an empty array by default) if not present x.update -- copy values into the matching key from another structured array, a dict, or list of key/value tuples. Unlike dicts this will only work for keys that are already present. Documentation should probably be updated to have these as the default ways of interacting with structured arrays, with the old methods deprecated. "Names" should also probably be renamed "keys" for compatibility with dicts.
On Tue, Apr 2, 2013 at 8:10 PM, Todd <toddrjen@gmail.com> wrote:
On Tue, Apr 2, 2013 at 8:12 PM, Ralf Gommers <ralf.gommers@gmail.com> wrote:
On Mon, Apr 1, 2013 at 2:27 PM, Todd <toddrjen@gmail.com> wrote:
There were a number of other ideas in this thread:
http://mail.scipy.org/pipermail/numpy-discussion/2013-March/065699.html
Thanks Todd. Your idea 5 is pretty much what Nathaniel just detailed out, it's on the ideas page now. That should enable idea 1 as well. The other idea that got some positive feedback was 3: http://mail.scipy.org/pipermail/numpy-discussion/2013-March/065710.html. If you or someone else could make that a little more concrete, we can put that up.
For 3:
With structured arrays, you can access them by name (key) in a manner identical to dictionaries:
y = x['f']
It also has a method for accessing the list of names (keys):
x.dtype.names
This should be maintained for backwards-compatibility, but these methods should also be added:
x.keys -- returns a list of field names x.values -- returns a list of views into the array, one for each structure x.items -- returns a list of tuple containing name/structure pairs (the structures being a views) x.iterkeys/itervalues/iteritems -- returns an iterable over the corresponding objects (should not be available in python 3) x.viewkeys/viewvalues/viewitems -- the same as the corresponding item, since they always return views (should not be available in python 3) x.has_key -- tests if a field name is present (should not be available in python 3, should use "key in x.keys()") x.get -- get a field by name, returning a default array (an empty array by default) if not present x.update -- copy values into the matching key from another structured array, a dict, or list of key/value tuples. Unlike dicts this will only work for keys that are already present.
Documentation should probably be updated to have these as the default ways of interacting with structured arrays, with the old methods deprecated. "Names" should also probably be renamed "keys" for compatibility with dicts.
I'm concerned that this will be 1 week of coding + 2 months of arguing over whether it's actually a good idea to add all these methods to every ndarray, whether it makes sense to have "views" for ndarrays, what should be done with "in", can/should we really rename "names", etc. Maybe I'm just pessimistic, but it isn't as much a slam-dunk obviously-the-right-thing improvement as some things. (Also I have no idea what the other comment about compact dicts that Ralf referred to above meant.) Handling such debates is a super-important part of OSS coding, but probably the worst thing to put on the critical path of a GSoC project. (Actually I guess I may be guilty of this myself, if anyone is worried about that dtype proposal speak up now... I think it can be done without serious compatibility breaks.) -n
participants (4)
-
Nathaniel Smith -
Ralf Gommers -
Sebastian Berg -
Todd