Re: [Numpy-discussion] Raveling, reshape order keyword unnecessarily confuses index and memory ordering
Hi, On Mon, Apr 1, 2013 at 4:51 PM, Chris Barker - NOAA Federal wrote: > HI folks, > > I've been teaching Python lately, have taught numpy a couple times > (formally), and am preparing a leacture about it over the next couple > weeks -- so I'm taking an interest here. > > I've been a regular numpy user for a long time, though as it happens, > rarely use ravel() (sode note, what's always confused me the most is > that it seems to me that ravel() _unravels_ the array - but that's a > side note...) > > So I ignored the first post, then fired up iPython, read the > docstring, and played with ravel a bit -- it behaved EXACTLY like I > expected. -- at least for 2-d > > Mathew, I expect your group may have gotten tied up by the fact that > you know too much! kind of like how I have a hard time getting my > iphone to work, and my computer-illiterate wife has no problem at all. Thank you for the compliment, it's more enjoyable than other potential explanations of my confusion (sigh). But, I don't think that is the explanation. First, there were three of us with different levels of experience getting confused on this. Second, I think we all agree that: > So: yes, I do think it's bit confusing and unfortunate that the > "order" parameter has two somewhat different meanings, - so there is a good reason that we could get confused. Last, as soon as we came to the distinction between index order and memory layout, it was clear. We all agreed that this was an important distinction that would improve numpy if we made it. Before I sent the email I did wonder aloud whether people would read the email, understand the distinction, and then fail to see the problem. It is hard to imagine yourself before you understood something. > but they are in > fat, used fairly similarly. And while the idea of "fortran" or "C" > ordering of arrays may be a foreign concept to folks that have not > used fortran or C (or most critically, tried to interace the two...) > it's a common enough concept that it's a reasonable shorthand. > > As for "should we teach memory order at all to newbies?' > > I usually do teach memory order early on, partly that's because I > really like to emphasize that numpy arrays are both a really nice > Python data structure and set of functions, but also a wrapper around > a block of data -- for the later, you need to talk about order. Also, > even with pure-python, knowing a bit about whether arrays are > contiguous or not is important (and views, and...). You can do a lot > with numpy without thinking about memory order at all, but to really > make it dance, you need to know about it. > > In short -- I don't think the situation is too bad, and not bad enough > to change any names or flags, but if someone wants to add a bit to the > ravel docstring to clarify it, I'm all for it. I think you agree that there is potential for confusion, and there doesn't seem any reason to continue with that confusion if we can come up with a clearer name. So here is a compromise proposal. How about: * Preferring the names 'c-style' and 'f-style' for the indexing order case (ravel, reshape, flatiter) * Leaving 'C" and 'F' as functional shortcuts, so there is no possible backwards-compatibility problem. Would you object to that? Cheers, Matthew ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Raveling, reshape order keyword unnecessarily confuses index and memory ordering
HI folks, I've been teaching Python lately, have taught numpy a couple times (formally), and am preparing a leacture about it over the next couple weeks -- so I'm taking an interest here. I've been a regular numpy user for a long time, though as it happens, rarely use ravel() (sode note, what's always confused me the most is that it seems to me that ravel() _unravels_ the array - but that's a side note...) So I ignored the first post, then fired up iPython, read the docstring, and played with ravel a bit -- it behaved EXACTLY like I expected. -- at least for 2-d Mathew, I expect your group may have gotten tied up by the fact that you know too much! kind of like how I have a hard time getting my iphone to work, and my computer-illiterate wife has no problem at all. So: yes, I do think it's bit confusing and unfortunate that the "order" parameter has two somewhat different meanings, but they are in fat, used fairly similarly. And while the idea of "fortran" or "C" ordering of arrays may be a foreign concept to folks that have not used fortran or C (or most critically, tried to interace the two...) it's a common enough concept that it's a reasonable shorthand. As for "should we teach memory order at all to newbies?' I usually do teach memory order early on, partly that's because I really like to emphasize that numpy arrays are both a really nice Python data structure and set of functions, but also a wrapper around a block of data -- for the later, you need to talk about order. Also, even with pure-python, knowing a bit about whether arrays are contiguous or not is important (and views, and...). You can do a lot with numpy without thinking about memory order at all, but to really make it dance, you need to know about it. In short -- I don't think the situation is too bad, and not bad enough to change any names or flags, but if someone wants to add a bit to the ravel docstring to clarify it, I'm all for it. -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Raveling, reshape order keyword unnecessarily confuses index and memory ordering
Hi, On Mon, Apr 1, 2013 at 1:34 PM, wrote: > On Mon, Apr 1, 2013 at 3:10 PM, Matthew Brett wrote: >> Hi, >> >> On Mon, Apr 1, 2013 at 10:23 AM, Sebastian Berg >> wrote: >>> On Sun, 2013-03-31 at 14:04 -0700, Matthew Brett wrote: Hi, On Sun, Mar 31, 2013 at 1:43 PM, wrote: > On Sun, Mar 31, 2013 at 3:54 PM, Matthew Brett > wrote: >> Hi, >> >> On Sat, Mar 30, 2013 at 10:38 PM, wrote: >>> On Sun, Mar 31, 2013 at 12:50 AM, Matthew Brett >>> wrote: Hi, On Sat, Mar 30, 2013 at 9:37 PM, wrote: > On Sun, Mar 31, 2013 at 12:04 AM, Matthew Brett > wrote: >> Hi, >> >> On Sat, Mar 30, 2013 at 7:02 PM, wrote: >>> On Sat, Mar 30, 2013 at 8:29 PM, Matthew Brett >>> wrote: Hi, On Sat, Mar 30, 2013 at 7:50 PM, wrote: > On Sat, Mar 30, 2013 at 7:31 PM, Bradley M. Froehle > wrote: >> On Sat, Mar 30, 2013 at 3:21 PM, Matthew Brett >> >> wrote: >>> >>> On Sat, Mar 30, 2013 at 2:20 PM, wrote: >>> > On Sat, Mar 30, 2013 at 4:57 PM, >>> > wrote: >>> >> On Sat, Mar 30, 2013 at 3:51 PM, Matthew Brett >>> >> wrote: >>> >>> On Sat, Mar 30, 2013 at 4:14 AM, >>> >>> wrote: >>> On Fri, Mar 29, 2013 at 10:08 PM, Matthew Brett >>> wrote: >>> > >>> > Ravel and reshape use the tems 'C' and 'F" in the sense >>> > of index >>> > ordering. >>> > >>> > This is very confusing. We think the index ordering and >>> > memory >>> > ordering ideas need to be separated, and specifically, >>> > we should >>> > avoid >>> > using "C" and "F" to refer to index ordering. >>> > >>> > Proposal >>> > - >>> > >>> > * Deprecate the use of "C" and "F" meaning backwards and >>> > forwards >>> > index ordering for ravel, reshape >>> > * Prefer "Z" and "N", being graphical representations of >>> > unraveling >>> > in >>> > 2 dimensions, axis1 first and axis0 first respectively >>> > (excellent >>> > naming idea by Paul Ivanov) >>> > >>> > What do y'all think? >>> >>> I always thought "F" and "C" are easy to understand, I >>> always thought >>> about >>> the content and never about the memory when using it. >>> >> >>> >> changing the names doesn't make it easier to understand. >>> >> I think the confusion is because the new A and K refer to >>> >> existing >>> >> memory >>> >> >>> >>> I disagree, I think it's confusing, but I have evidence, and >>> that is >>> that four out of four of us tested ourselves and got it wrong. >>> >>> Perhaps we are particularly dumb or poorly informed, but I >>> think it's >>> rash to assert there is no problem here. > > I think you are overcomplicating things or phrased it as a > "trick question" I don't know what you mean by trick question - was there something over-complicated in the example? I deliberately didn't include various much more confusing examples in "reshape". >>> >>> I meant making the "candidates" think about memory instead of just >>> column versus row stacking. >> >> To be specific, we were teaching about reshaping a (I, J, K, N) 4D >> array, it was an image, with time as the 4th dimension (N time >> points). Raveling and reshaping 3D and 4D arrays is a common thing >> to do in neuroimaging, as you can imagine. >> >> A student asked what he would get back from raveling this array, a >> concatenated time series, or something spatial? >> >> We showed (I'd worked it out by this time) that the first N values >> were the time series given by [0, 0, 0, :]. >> >> He said - "Oh - I see - so the data is stored as a whole lot of time >> series one by one, I thought it would be stored as a series of >> images'. >> >> Ironically, this was a Fortran-ordered array in memory, and he was >> wrong. >> >
Re: [Numpy-discussion] Raveling, reshape order keyword unnecessarily confuses index and memory ordering
On Mon, Apr 1, 2013 at 3:10 PM, Matthew Brett wrote: > Hi, > > On Mon, Apr 1, 2013 at 10:23 AM, Sebastian Berg > wrote: >> On Sun, 2013-03-31 at 14:04 -0700, Matthew Brett wrote: >>> Hi, >>> >>> On Sun, Mar 31, 2013 at 1:43 PM, wrote: >>> > On Sun, Mar 31, 2013 at 3:54 PM, Matthew Brett >>> > wrote: >>> >> Hi, >>> >> >>> >> On Sat, Mar 30, 2013 at 10:38 PM, wrote: >>> >>> On Sun, Mar 31, 2013 at 12:50 AM, Matthew Brett >>> >>> wrote: >>> Hi, >>> >>> On Sat, Mar 30, 2013 at 9:37 PM, wrote: >>> > On Sun, Mar 31, 2013 at 12:04 AM, Matthew Brett >>> > wrote: >>> >> Hi, >>> >> >>> >> On Sat, Mar 30, 2013 at 7:02 PM, wrote: >>> >>> On Sat, Mar 30, 2013 at 8:29 PM, Matthew Brett >>> >>> wrote: >>> Hi, >>> >>> On Sat, Mar 30, 2013 at 7:50 PM, wrote: >>> > On Sat, Mar 30, 2013 at 7:31 PM, Bradley M. Froehle >>> > wrote: >>> >> On Sat, Mar 30, 2013 at 3:21 PM, Matthew Brett >>> >> >>> >> wrote: >>> >>> >>> >>> On Sat, Mar 30, 2013 at 2:20 PM, wrote: >>> >>> > On Sat, Mar 30, 2013 at 4:57 PM, >>> >>> > wrote: >>> >>> >> On Sat, Mar 30, 2013 at 3:51 PM, Matthew Brett >>> >>> >> wrote: >>> >>> >>> On Sat, Mar 30, 2013 at 4:14 AM, >>> >>> >>> wrote: >>> >>> On Fri, Mar 29, 2013 at 10:08 PM, Matthew Brett >>> >>> wrote: >>> >>> > >>> >>> > Ravel and reshape use the tems 'C' and 'F" in the sense >>> >>> > of index >>> >>> > ordering. >>> >>> > >>> >>> > This is very confusing. We think the index ordering and >>> >>> > memory >>> >>> > ordering ideas need to be separated, and specifically, we >>> >>> > should >>> >>> > avoid >>> >>> > using "C" and "F" to refer to index ordering. >>> >>> > >>> >>> > Proposal >>> >>> > - >>> >>> > >>> >>> > * Deprecate the use of "C" and "F" meaning backwards and >>> >>> > forwards >>> >>> > index ordering for ravel, reshape >>> >>> > * Prefer "Z" and "N", being graphical representations of >>> >>> > unraveling >>> >>> > in >>> >>> > 2 dimensions, axis1 first and axis0 first respectively >>> >>> > (excellent >>> >>> > naming idea by Paul Ivanov) >>> >>> > >>> >>> > What do y'all think? >>> >>> >>> >>> I always thought "F" and "C" are easy to understand, I >>> >>> always thought >>> >>> about >>> >>> the content and never about the memory when using it. >>> >>> >> >>> >>> >> changing the names doesn't make it easier to understand. >>> >>> >> I think the confusion is because the new A and K refer to >>> >>> >> existing >>> >>> >> memory >>> >>> >> >>> >>> >>> >>> I disagree, I think it's confusing, but I have evidence, and >>> >>> that is >>> >>> that four out of four of us tested ourselves and got it wrong. >>> >>> >>> >>> Perhaps we are particularly dumb or poorly informed, but I >>> >>> think it's >>> >>> rash to assert there is no problem here. >>> > >>> > I think you are overcomplicating things or phrased it as a "trick >>> > question" >>> >>> I don't know what you mean by trick question - was there something >>> over-complicated in the example? I deliberately didn't include >>> various much more confusing examples in "reshape". >>> >>> >>> >>> I meant making the "candidates" think about memory instead of just >>> >>> column versus row stacking. >>> >> >>> >> To be specific, we were teaching about reshaping a (I, J, K, N) 4D >>> >> array, it was an image, with time as the 4th dimension (N time >>> >> points). Raveling and reshaping 3D and 4D arrays is a common thing >>> >> to do in neuroimaging, as you can imagine. >>> >> >>> >> A student asked what he would get back from raveling this array, a >>> >> concatenated time series, or something spatial? >>> >> >>> >> We showed (I'd worked it out by this time) that the first N values >>> >> were the time series given by [0, 0, 0, :]. >>> >> >>> >> He said - "Oh - I see - so the data is stored as a whole lot of time >>> >> series one by one, I thought it would be stored as a series of >>> >> images'. >>> >> >>> >> Ironically, this was a Fortran-ordered array in memory, and he was >>> >> wrong. >>> >> >>> >> So, I think the idea of memory ordering and index ordering is very >>> >> easy to confuse, and comes up naturally. >>> >> >>> >> I would like,
Re: [Numpy-discussion] Raveling, reshape order keyword unnecessarily confuses index and memory ordering
Hi, On Mon, Apr 1, 2013 at 10:23 AM, Sebastian Berg wrote: > On Sun, 2013-03-31 at 14:04 -0700, Matthew Brett wrote: >> Hi, >> >> On Sun, Mar 31, 2013 at 1:43 PM, wrote: >> > On Sun, Mar 31, 2013 at 3:54 PM, Matthew Brett >> > wrote: >> >> Hi, >> >> >> >> On Sat, Mar 30, 2013 at 10:38 PM, wrote: >> >>> On Sun, Mar 31, 2013 at 12:50 AM, Matthew Brett >> >>> wrote: >> Hi, >> >> On Sat, Mar 30, 2013 at 9:37 PM, wrote: >> > On Sun, Mar 31, 2013 at 12:04 AM, Matthew Brett >> > wrote: >> >> Hi, >> >> >> >> On Sat, Mar 30, 2013 at 7:02 PM, wrote: >> >>> On Sat, Mar 30, 2013 at 8:29 PM, Matthew Brett >> >>> wrote: >> Hi, >> >> On Sat, Mar 30, 2013 at 7:50 PM, wrote: >> > On Sat, Mar 30, 2013 at 7:31 PM, Bradley M. Froehle >> > wrote: >> >> On Sat, Mar 30, 2013 at 3:21 PM, Matthew Brett >> >> >> >> wrote: >> >>> >> >>> On Sat, Mar 30, 2013 at 2:20 PM, wrote: >> >>> > On Sat, Mar 30, 2013 at 4:57 PM, wrote: >> >>> >> On Sat, Mar 30, 2013 at 3:51 PM, Matthew Brett >> >>> >> wrote: >> >>> >>> On Sat, Mar 30, 2013 at 4:14 AM, >> >>> >>> wrote: >> >>> On Fri, Mar 29, 2013 at 10:08 PM, Matthew Brett >> >>> wrote: >> >>> > >> >>> > Ravel and reshape use the tems 'C' and 'F" in the sense of >> >>> > index >> >>> > ordering. >> >>> > >> >>> > This is very confusing. We think the index ordering and >> >>> > memory >> >>> > ordering ideas need to be separated, and specifically, we >> >>> > should >> >>> > avoid >> >>> > using "C" and "F" to refer to index ordering. >> >>> > >> >>> > Proposal >> >>> > - >> >>> > >> >>> > * Deprecate the use of "C" and "F" meaning backwards and >> >>> > forwards >> >>> > index ordering for ravel, reshape >> >>> > * Prefer "Z" and "N", being graphical representations of >> >>> > unraveling >> >>> > in >> >>> > 2 dimensions, axis1 first and axis0 first respectively >> >>> > (excellent >> >>> > naming idea by Paul Ivanov) >> >>> > >> >>> > What do y'all think? >> >>> >> >>> I always thought "F" and "C" are easy to understand, I >> >>> always thought >> >>> about >> >>> the content and never about the memory when using it. >> >>> >> >> >>> >> changing the names doesn't make it easier to understand. >> >>> >> I think the confusion is because the new A and K refer to >> >>> >> existing >> >>> >> memory >> >>> >> >> >>> >> >>> I disagree, I think it's confusing, but I have evidence, and >> >>> that is >> >>> that four out of four of us tested ourselves and got it wrong. >> >>> >> >>> Perhaps we are particularly dumb or poorly informed, but I think >> >>> it's >> >>> rash to assert there is no problem here. >> > >> > I think you are overcomplicating things or phrased it as a "trick >> > question" >> >> I don't know what you mean by trick question - was there something >> over-complicated in the example? I deliberately didn't include >> various much more confusing examples in "reshape". >> >>> >> >>> I meant making the "candidates" think about memory instead of just >> >>> column versus row stacking. >> >> >> >> To be specific, we were teaching about reshaping a (I, J, K, N) 4D >> >> array, it was an image, with time as the 4th dimension (N time >> >> points). Raveling and reshaping 3D and 4D arrays is a common thing >> >> to do in neuroimaging, as you can imagine. >> >> >> >> A student asked what he would get back from raveling this array, a >> >> concatenated time series, or something spatial? >> >> >> >> We showed (I'd worked it out by this time) that the first N values >> >> were the time series given by [0, 0, 0, :]. >> >> >> >> He said - "Oh - I see - so the data is stored as a whole lot of time >> >> series one by one, I thought it would be stored as a series of >> >> images'. >> >> >> >> Ironically, this was a Fortran-ordered array in memory, and he was >> >> wrong. >> >> >> >> So, I think the idea of memory ordering and index ordering is very >> >> easy to confuse, and comes up naturally. >> >> >> >> I would like, as a teacher, to be able to say something like: >> >> >> >> This is what C memory layout is (it's the memory layout that gives >> >> arr.flags.C_CONTIGUOUS=True) >> >> This is wha
Re: [Numpy-discussion] Raveling, reshape order keyword unnecessarily confuses index and memory ordering
On Sun, 2013-03-31 at 14:04 -0700, Matthew Brett wrote: > Hi, > > On Sun, Mar 31, 2013 at 1:43 PM, wrote: > > On Sun, Mar 31, 2013 at 3:54 PM, Matthew Brett > > wrote: > >> Hi, > >> > >> On Sat, Mar 30, 2013 at 10:38 PM, wrote: > >>> On Sun, Mar 31, 2013 at 12:50 AM, Matthew Brett > >>> wrote: > Hi, > > On Sat, Mar 30, 2013 at 9:37 PM, wrote: > > On Sun, Mar 31, 2013 at 12:04 AM, Matthew Brett > > wrote: > >> Hi, > >> > >> On Sat, Mar 30, 2013 at 7:02 PM, wrote: > >>> On Sat, Mar 30, 2013 at 8:29 PM, Matthew Brett > >>> wrote: > Hi, > > On Sat, Mar 30, 2013 at 7:50 PM, wrote: > > On Sat, Mar 30, 2013 at 7:31 PM, Bradley M. Froehle > > wrote: > >> On Sat, Mar 30, 2013 at 3:21 PM, Matthew Brett > >> > >> wrote: > >>> > >>> On Sat, Mar 30, 2013 at 2:20 PM, wrote: > >>> > On Sat, Mar 30, 2013 at 4:57 PM, wrote: > >>> >> On Sat, Mar 30, 2013 at 3:51 PM, Matthew Brett > >>> >> wrote: > >>> >>> On Sat, Mar 30, 2013 at 4:14 AM, > >>> >>> wrote: > >>> On Fri, Mar 29, 2013 at 10:08 PM, Matthew Brett > >>> wrote: > >>> > > >>> > Ravel and reshape use the tems 'C' and 'F" in the sense of > >>> > index > >>> > ordering. > >>> > > >>> > This is very confusing. We think the index ordering and > >>> > memory > >>> > ordering ideas need to be separated, and specifically, we > >>> > should > >>> > avoid > >>> > using "C" and "F" to refer to index ordering. > >>> > > >>> > Proposal > >>> > - > >>> > > >>> > * Deprecate the use of "C" and "F" meaning backwards and > >>> > forwards > >>> > index ordering for ravel, reshape > >>> > * Prefer "Z" and "N", being graphical representations of > >>> > unraveling > >>> > in > >>> > 2 dimensions, axis1 first and axis0 first respectively > >>> > (excellent > >>> > naming idea by Paul Ivanov) > >>> > > >>> > What do y'all think? > >>> > >>> I always thought "F" and "C" are easy to understand, I > >>> always thought > >>> about > >>> the content and never about the memory when using it. > >>> >> > >>> >> changing the names doesn't make it easier to understand. > >>> >> I think the confusion is because the new A and K refer to > >>> >> existing > >>> >> memory > >>> >> > >>> > >>> I disagree, I think it's confusing, but I have evidence, and that > >>> is > >>> that four out of four of us tested ourselves and got it wrong. > >>> > >>> Perhaps we are particularly dumb or poorly informed, but I think > >>> it's > >>> rash to assert there is no problem here. > > > > I think you are overcomplicating things or phrased it as a "trick > > question" > > I don't know what you mean by trick question - was there something > over-complicated in the example? I deliberately didn't include > various much more confusing examples in "reshape". > >>> > >>> I meant making the "candidates" think about memory instead of just > >>> column versus row stacking. > >> > >> To be specific, we were teaching about reshaping a (I, J, K, N) 4D > >> array, it was an image, with time as the 4th dimension (N time > >> points). Raveling and reshaping 3D and 4D arrays is a common thing > >> to do in neuroimaging, as you can imagine. > >> > >> A student asked what he would get back from raveling this array, a > >> concatenated time series, or something spatial? > >> > >> We showed (I'd worked it out by this time) that the first N values > >> were the time series given by [0, 0, 0, :]. > >> > >> He said - "Oh - I see - so the data is stored as a whole lot of time > >> series one by one, I thought it would be stored as a series of > >> images'. > >> > >> Ironically, this was a Fortran-ordered array in memory, and he was > >> wrong. > >> > >> So, I think the idea of memory ordering and index ordering is very > >> easy to confuse, and comes up naturally. > >> > >> I would like, as a teacher, to be able to say something like: > >> > >> This is what C memory layout is (it's the memory layout that gives > >> arr.flags.C_CONTIGUOUS=True) > >> This is what F memory layout is (it's the memory layout that gives > >> arr.flags.F_CONTIGUOUS=True) > >> It's rather easy to get something that is neither C or F memory layout >
Re: [Numpy-discussion] [SciPy-Dev] NumPy/SciPy participation in GSoC 2013
On Mon, Apr 1, 2013 at 1:58 PM, Ralf Gommers wrote: > > > > On Tue, Mar 26, 2013 at 12:27 AM, Ralf Gommers wrote: > >> >> >> >> On Thu, Mar 21, 2013 at 10:20 PM, 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. >>> >>> 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-...@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 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] NumPy/SciPy participation in GSoC 2013
On Tue, Mar 26, 2013 at 12:27 AM, Ralf Gommers wrote: > > > > On Thu, Mar 21, 2013 at 10:20 PM, 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. >> >> 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 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
