Re: [Numpy-discussion] Advanced indexing: fancy vs. orthogonal
On Sat, Apr 4, 2015 at 9:54 AM, Nathaniel Smith n...@pobox.com wrote: On Sat, Apr 4, 2015 at 12:17 AM, Ralf Gommers ralf.gomm...@gmail.com wrote: On Sat, Apr 4, 2015 at 1:54 AM, Nathaniel Smith n...@pobox.com wrote: So I'd be very happy to see worked out proposals for any or all of these approaches. It strikes me as really premature to be issuing proclamations about what changes might be considered. There is really no danger to *considering* a proposal; Sorry, I have to disagree. Numpy is already seen by some as having a poor track record on backwards compatibility. Having core developers say propose some backcompat break to how indexing works and we'll consider it makes our stance on that look even worse. Of course everyone is free to make any technical proposal they deem fit and we'll consider the merits of it. However I'd like us to be clear that we do care strongly about backwards compatibility and that the fundamentals of the core of Numpy (things like indexing, broadcasting, dtypes and ufuncs) will not be changed in backwards-incompatible ways. Ralf P.S. also not for a possible numpy 2.0 (or have we learned nothing from Python3?). I agree 100% that we should and do care strongly about backwards compatibility. But you're saying in one sentence that we should tell people that we won't consider backcompat breaks, and then in the next sentence that of course we actually will consider them (even if we almost always reject them). Basically, I think saying one thing and doing another is not a good way to build people's trust. There is a difference between politely considering what proposals people send us uninvited and inviting people to work on specific proposals. That is what Ralf was getting at. -- Robert Kern ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Advanced indexing: fancy vs. orthogonal
On Apr 4, 2015 10:54 AM, Nathaniel Smith n...@pobox.com wrote: On Sat, Apr 4, 2015 at 12:17 AM, Ralf Gommers ralf.gomm...@gmail.com wrote: On Sat, Apr 4, 2015 at 1:54 AM, Nathaniel Smith n...@pobox.com wrote: But, the real problem here is that we have two different array duck types that force everyone to write their code twice. This is a terrible state of affairs! (And exactly analogous to the problems caused by np.ndarray disagreeing with np.matrix scipy.sparse about the the proper definition of *, which PEP 465 may eventually alleviate.) IMO we should be solving this indexing problem directly, not applying bandaids to its symptoms, and the way to do that is to come up with some common duck type that everyone can agree on. Unfortunately, AFAICT this means our only options here are to have some kind of backcompat break in numpy, some kind of backcompat break in pandas, or to do nothing and continue indefinitely with the status quo where the same indexing operation might silently return different results depending on the types passed in. All of these options have real costs for users, and it isn't at all clear to me what the relative costs will be when we dig into the details of our various options. I doubt that there is a reasonable way to quantify those costs, especially those of breaking backwards compatibility. If someone has a good method, I'd be interested though. I'm a little nervous about how easily this argument might turn into either A or B is better but we can't be 100% *certain* which it is so instead of doing our best using the data available we should just choose B. Being a maintainer means accepting uncertainty and doing our best anyway. I think the burden of proof needs to be on the side proposing a change, and the more invasive the change the higher that burden needs to be. When faced with a situation like this, where the proposed change will cause fundamental alterations to the most basic, high-level operation of numpy, and where the is an alternative approach with no backwards-compatibility issues, I think the burden of proof would necessarily be nearly impossibly large. But that said I'm still totally on board with erring on the side of caution (in particular, you can never go back and *un*break backcompat). An obvious challenge to anyone trying to take this forward (in any direction!) would definitely be to gather the most useful data possible. And it's not obviously impossible -- maybe one could do something useful by scanning ASTs of lots of packages (I have a copy of pypi if anyone wants it, that I downloaded with the idea of making some similar arguments for why core python should slightly break backcompat to allow overloading of a b c syntax), or adding instrumentation to numpy, or running small-scale usability tests, or surveying people, or ... (I was pretty surprised by some of the data gathered during the PEP 465 process, e.g. on how common dot() calls are relative to existing built-in operators, and on its associativity in practice.) Surveys like this have the problem of small sample size and selection bias. Usability studies can't measure the effect of the compatibility break, not to mention the effect on numpy's reputation. This is considerably more difficult to scan existing projects for than .dot because it depends on the type being passed (which may not even be defined in the same project). And I am not sure I much like the idea of numpy phoning home by default, and an opt-in had the same issues as a survey. So to make a long story short, in this sort of situation I have a hard time imaging ways to get enough reliable, representative data to justify this level of backwards compatibility break. Core python broke backcompat on a regular basis throughout the python 2 series, and almost certainly will again -- the bar to doing so is *very* high, and they use elaborate mechanisms to ease the way (__future__, etc.), but they do it. A few months ago there was even some serious consideration given to changing py3 bytestring indexing to return bytestrings instead of integers. (Consensus was unsurprisingly that this was a bad idea, but there were core devs seriously exploring it, and no-one complained about the optics.) There was no break as large as this. In fact I would say this is even a larger change than any individual change we saw in the python 2 to 3 switch. The basic mechanics of indexing are just too fundamental and touch on too many things to make this sort of change feasible. It would be better to have a new language, or in this case anew project. It's true that numpy has something of a bad reputation in this area, and I think it's because until ~1.7 or so, we randomly broke stuff by accident on a pretty regular basis, even in bug fix releases. I think the way to rebuild that trust is to honestly say to our users that when we do break backcompat, we will never do it by
Re: [Numpy-discussion] Advanced indexing: fancy vs. orthogonal
On Sat, Apr 4, 2015 at 1:54 AM, Nathaniel Smith n...@pobox.com wrote: But, the real problem here is that we have two different array duck types that force everyone to write their code twice. This is a terrible state of affairs! (And exactly analogous to the problems caused by np.ndarray disagreeing with np.matrix scipy.sparse about the the proper definition of *, which PEP 465 may eventually alleviate.) IMO we should be solving this indexing problem directly, not applying bandaids to its symptoms, and the way to do that is to come up with some common duck type that everyone can agree on. Unfortunately, AFAICT this means our only options here are to have some kind of backcompat break in numpy, some kind of backcompat break in pandas, or to do nothing and continue indefinitely with the status quo where the same indexing operation might silently return different results depending on the types passed in. All of these options have real costs for users, and it isn't at all clear to me what the relative costs will be when we dig into the details of our various options. I doubt that there is a reasonable way to quantify those costs, especially those of breaking backwards compatibility. If someone has a good method, I'd be interested though. So I'd be very happy to see worked out proposals for any or all of these approaches. It strikes me as really premature to be issuing proclamations about what changes might be considered. There is really no danger to *considering* a proposal; Sorry, I have to disagree. Numpy is already seen by some as having a poor track record on backwards compatibility. Having core developers say propose some backcompat break to how indexing works and we'll consider it makes our stance on that look even worse. Of course everyone is free to make any technical proposal they deem fit and we'll consider the merits of it. However I'd like us to be clear that we do care strongly about backwards compatibility and that the fundamentals of the core of Numpy (things like indexing, broadcasting, dtypes and ufuncs) will not be changed in backwards-incompatible ways. Ralf P.S. also not for a possible numpy 2.0 (or have we learned nothing from Python3?). ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Advanced indexing: fancy vs. orthogonal
On Sat, Apr 4, 2015 at 12:17 AM, Ralf Gommers ralf.gomm...@gmail.com wrote: On Sat, Apr 4, 2015 at 1:54 AM, Nathaniel Smith n...@pobox.com wrote: But, the real problem here is that we have two different array duck types that force everyone to write their code twice. This is a terrible state of affairs! (And exactly analogous to the problems caused by np.ndarray disagreeing with np.matrix scipy.sparse about the the proper definition of *, which PEP 465 may eventually alleviate.) IMO we should be solving this indexing problem directly, not applying bandaids to its symptoms, and the way to do that is to come up with some common duck type that everyone can agree on. Unfortunately, AFAICT this means our only options here are to have some kind of backcompat break in numpy, some kind of backcompat break in pandas, or to do nothing and continue indefinitely with the status quo where the same indexing operation might silently return different results depending on the types passed in. All of these options have real costs for users, and it isn't at all clear to me what the relative costs will be when we dig into the details of our various options. I doubt that there is a reasonable way to quantify those costs, especially those of breaking backwards compatibility. If someone has a good method, I'd be interested though. I'm a little nervous about how easily this argument might turn into either A or B is better but we can't be 100% *certain* which it is so instead of doing our best using the data available we should just choose B. Being a maintainer means accepting uncertainty and doing our best anyway. But that said I'm still totally on board with erring on the side of caution (in particular, you can never go back and *un*break backcompat). An obvious challenge to anyone trying to take this forward (in any direction!) would definitely be to gather the most useful data possible. And it's not obviously impossible -- maybe one could do something useful by scanning ASTs of lots of packages (I have a copy of pypi if anyone wants it, that I downloaded with the idea of making some similar arguments for why core python should slightly break backcompat to allow overloading of a b c syntax), or adding instrumentation to numpy, or running small-scale usability tests, or surveying people, or ... (I was pretty surprised by some of the data gathered during the PEP 465 process, e.g. on how common dot() calls are relative to existing built-in operators, and on its associativity in practice.) So I'd be very happy to see worked out proposals for any or all of these approaches. It strikes me as really premature to be issuing proclamations about what changes might be considered. There is really no danger to *considering* a proposal; Sorry, I have to disagree. Numpy is already seen by some as having a poor track record on backwards compatibility. Having core developers say propose some backcompat break to how indexing works and we'll consider it makes our stance on that look even worse. Of course everyone is free to make any technical proposal they deem fit and we'll consider the merits of it. However I'd like us to be clear that we do care strongly about backwards compatibility and that the fundamentals of the core of Numpy (things like indexing, broadcasting, dtypes and ufuncs) will not be changed in backwards-incompatible ways. Ralf P.S. also not for a possible numpy 2.0 (or have we learned nothing from Python3?). I agree 100% that we should and do care strongly about backwards compatibility. But you're saying in one sentence that we should tell people that we won't consider backcompat breaks, and then in the next sentence that of course we actually will consider them (even if we almost always reject them). Basically, I think saying one thing and doing another is not a good way to build people's trust. Core python broke backcompat on a regular basis throughout the python 2 series, and almost certainly will again -- the bar to doing so is *very* high, and they use elaborate mechanisms to ease the way (__future__, etc.), but they do it. A few months ago there was even some serious consideration given to changing py3 bytestring indexing to return bytestrings instead of integers. (Consensus was unsurprisingly that this was a bad idea, but there were core devs seriously exploring it, and no-one complained about the optics.) It's true that numpy has something of a bad reputation in this area, and I think it's because until ~1.7 or so, we randomly broke stuff by accident on a pretty regular basis, even in bug fix releases. I think the way to rebuild that trust is to honestly say to our users that when we do break backcompat, we will never do it by accident, and we will do it only rarely, after careful consideration, with the smoothest transition possible, only in situations where we are convinced that it the net best possible solution for our users, and only after public discussion and
Re: [Numpy-discussion] Advanced indexing: fancy vs. orthogonal
On Sat, Apr 4, 2015 at 2:15 AM, Robert Kern robert.k...@gmail.com wrote: On Sat, Apr 4, 2015 at 9:54 AM, Nathaniel Smith n...@pobox.com wrote: On Sat, Apr 4, 2015 at 12:17 AM, Ralf Gommers ralf.gomm...@gmail.com wrote: On Sat, Apr 4, 2015 at 1:54 AM, Nathaniel Smith n...@pobox.com wrote: So I'd be very happy to see worked out proposals for any or all of these approaches. It strikes me as really premature to be issuing proclamations about what changes might be considered. There is really no danger to *considering* a proposal; Sorry, I have to disagree. Numpy is already seen by some as having a poor track record on backwards compatibility. Having core developers say propose some backcompat break to how indexing works and we'll consider it makes our stance on that look even worse. Of course everyone is free to make any technical proposal they deem fit and we'll consider the merits of it. However I'd like us to be clear that we do care strongly about backwards compatibility and that the fundamentals of the core of Numpy (things like indexing, broadcasting, dtypes and ufuncs) will not be changed in backwards-incompatible ways. Ralf P.S. also not for a possible numpy 2.0 (or have we learned nothing from Python3?). I agree 100% that we should and do care strongly about backwards compatibility. But you're saying in one sentence that we should tell people that we won't consider backcompat breaks, and then in the next sentence that of course we actually will consider them (even if we almost always reject them). Basically, I think saying one thing and doing another is not a good way to build people's trust. There is a difference between politely considering what proposals people send us uninvited and inviting people to work on specific proposals. That is what Ralf was getting at. I mean, I get that Ralf read my bit quoted above and got worried that people would read it as numpy core team announces they don't care about backcompat, which is fair enough. Sometimes people jump to all kinds of conclusions, esp. when confirmation bias meets skim-reading meets hastily-written emails. But it's just not true that I read people's proposals out of politeness; I read them because I'm interested, because they might surprise us by being more practical/awesome/whatever than we expect, and because we all learn things by giving them due consideration regardless of the final outcome. So yeah, I do honestly do want to see people work on specific proposals for important problems (and this indexing thing strikes me as important), even proposals that involve breaking backcompat. Pretending otherwise would still be a lie, at least on my part. So the distinction you're making here doesn't help me much. -n -- Nathaniel J. Smith -- http://vorpus.org ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Advanced indexing: fancy vs. orthogonal
On Sat, Apr 4, 2015 at 1:11 PM, Todd toddr...@gmail.com wrote: There was no break as large as this. In fact I would say this is even a larger change than any individual change we saw in the python 2 to 3 switch. Well, the impact of what Python3 did to everyone's string handling code caused so much work that it's close to impossible to top that within numpy I'd say:) Ralf The basic mechanics of indexing are just too fundamental and touch on too many things to make this sort of change feasible. It would be better to have a new language, or in this case anew project. ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Advanced indexing: fancy vs. orthogonal
On Sat, Apr 4, 2015 at 11:38 AM, Nathaniel Smith n...@pobox.com wrote: On Sat, Apr 4, 2015 at 2:15 AM, Robert Kern robert.k...@gmail.com wrote: On Sat, Apr 4, 2015 at 9:54 AM, Nathaniel Smith n...@pobox.com wrote: On Sat, Apr 4, 2015 at 12:17 AM, Ralf Gommers ralf.gomm...@gmail.com wrote: On Sat, Apr 4, 2015 at 1:54 AM, Nathaniel Smith n...@pobox.com wrote: So I'd be very happy to see worked out proposals for any or all of these approaches. It strikes me as really premature to be issuing proclamations about what changes might be considered. There is really no danger to *considering* a proposal; Sorry, I have to disagree. Numpy is already seen by some as having a poor track record on backwards compatibility. Having core developers say propose some backcompat break to how indexing works and we'll consider it makes our stance on that look even worse. Of course everyone is free to make any technical proposal they deem fit and we'll consider the merits of it. However I'd like us to be clear that we do care strongly about backwards compatibility and that the fundamentals of the core of Numpy (things like indexing, broadcasting, dtypes and ufuncs) will not be changed in backwards-incompatible ways. Ralf P.S. also not for a possible numpy 2.0 (or have we learned nothing from Python3?). I agree 100% that we should and do care strongly about backwards compatibility. But you're saying in one sentence that we should tell people that we won't consider backcompat breaks, and then in the next sentence that of course we actually will consider them (even if we almost always reject them). Basically, I think saying one thing and doing another is not a good way to build people's trust. There is a difference between politely considering what proposals people send us uninvited and inviting people to work on specific proposals. That is what Ralf was getting at. I mean, I get that Ralf read my bit quoted above and got worried that people would read it as numpy core team announces they don't care about backcompat, which is fair enough. Sometimes people jump to all kinds of conclusions, esp. when confirmation bias meets skim-reading meets hastily-written emails. But it's just not true that I read people's proposals out of politeness; I read them because I'm interested, because they might surprise us by being more practical/awesome/whatever than we expect, and because we all learn things by giving them due consideration regardless of the final outcome. Thanks for explaining, good perspective. So yeah, I do honestly do want to see people work on specific proposals for important problems (and this indexing thing strikes me as important), even proposals that involve breaking backcompat. Pretending otherwise would still be a lie, at least on my part. So the distinction you're making here doesn't help me much. A change in semantics would help already. If you'd phrased it for example as: I'd personally be interested in seeing a description of what changes, including backwards-incompatible ones, would need to be made to numpy indexing behavior to resolve this situation. We could learn a lot from such an exercise., that would have invited the same investigation from interested people without creating worries about Numpy stability. And without potentially leading new enthusiastic contributors to believe that this is an opportunity to make an important change to Numpy: 99.9% chance that they'd be disappointed after having their well thought out proposal rejected. Cheers, Ralf -n -- Nathaniel J. Smith -- http://vorpus.org ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Fix masked arrays to properly edit views
Hey Eric, That's a good point. I remember seeing this behavior before and thought it was a bit odd. Best, John On Mar 16, 2015, at 2:20 AM, numpy-discussion-requ...@scipy.org wrote: Send NumPy-Discussion mailing list submissions to numpy-discussion@scipy.org To subscribe or unsubscribe via the World Wide Web, visit http://mail.scipy.org/mailman/listinfo/numpy-discussion or, via email, send a message with subject or body 'help' to numpy-discussion-requ...@scipy.org You can reach the person managing the list at numpy-discussion-ow...@scipy.org When replying, please edit your Subject line so it is more specific than Re: Contents of NumPy-Discussion digest... Today's Topics: 1. Re: Fix masked arrays to properly edit views (Eric Firing) 2. Rewrite np.histogram in c? (Robert McGibbon) 3. numpy.stack -- which function, if any,deserves the name? (Stephan Hoyer) 4. Re: Rewrite np.histogram in c? (Jaime Fern?ndez del R?o) 5. Re: Rewrite np.histogram in c? (Robert McGibbon) 6. Re: Rewrite np.histogram in c? (Robert McGibbon) -- Message: 1 Date: Sat, 14 Mar 2015 14:01:04 -1000 From: Eric Firing efir...@hawaii.edu Subject: Re: [Numpy-discussion] Fix masked arrays to properly edit views To: numpy-discussion@scipy.org Message-ID: 5504cbc0.1080...@hawaii.edu Content-Type: text/plain; charset=windows-1252; format=flowed On 2015/03/14 1:02 PM, John Kirkham wrote: The sample case of the issue ( https://github.com/numpy/numpy/issues/5558 ) is shown below. A proposal to address this behavior can be found here ( https://github.com/numpy/numpy/pull/5580 ). Please give me your feedback. I tried to change the mask of `a` through a subindexed view, but was unable. Using this setup I can reproduce this in the 1.9.1 version of NumPy. import numpy as np a = np.arange(6).reshape(2,3) a = np.ma.masked_array(a, mask=np.ma.getmaskarray(a), shrink=False) b = a[1:2,1:2] c = np.zeros(b.shape, b.dtype) c = np.ma.masked_array(c, mask=np.ma.getmaskarray(c), shrink=False) c[:] = np.ma.masked This yields what one would expect for `a`, `b`, and `c` (seen below). masked_array(data = [[0 1 2] [3 4 5]], mask = [[False False False] [False False False]], fill_value = 99) masked_array(data = [[4]], mask = [[False]], fill_value = 99) masked_array(data = [[--]], mask = [[ True]], fill_value = 99) Now, it would seem reasonable that to copy data into `b` from `c` one can use `__setitem__` (seen below). b[:] = c This results in new data and mask for `b`. masked_array(data = [[--]], mask = [[ True]], fill_value = 99) This should, in turn, change `a`. However, the mask of `a` remains unchanged (seen below). masked_array(data = [[0 1 2] [3 0 5]], mask = [[False False False] [False False False]], fill_value = 99) I agree that this behavior is wrong. A related oddity is this: In [24]: a = np.arange(6).reshape(2,3) In [25]: a = np.ma.array(a, mask=np.ma.getmaskarray(a), shrink=False) In [27]: a.sharedmask True In [28]: a.unshare_mask() In [30]: b = a[1:2, 1:2] In [31]: b[:] = np.ma.masked In [32]: b.sharedmask False In [33]: a masked_array(data = [[0 1 2] [3 -- 5]], mask = [[False False False] [False True False]], fill_value = 99) It looks like the sharedmask property simply is not being set and interpreted correctly--a freshly initialized array has sharedmask True; and after setting it to False, changing the mask of a new view *does* change the mask in the original. Eric Best, John ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion -- Message: 2 Date: Sun, 15 Mar 2015 21:32:49 -0700 From: Robert McGibbon rmcgi...@gmail.com Subject: [Numpy-discussion] Rewrite np.histogram in c? To: Discussion of Numerical Python numpy-discussion@scipy.org Message-ID: can4+e8ff_ck-9gbrcbstq6qpiugxgkeix3+kkrxn4nm-lnn...@mail.gmail.com Content-Type: text/plain; charset=utf-8 Hi, Numpy.histogram is implemented in python, and is a little sluggish. This has been discussed previously on the mailing list, [1, 2]. It came up in a project that I maintain, where a new feature is bottlenecked by numpy.histogram, and one developer suggested a faster implementation in cython [3]. Would it make sense to reimplement this function in c? or cython? Is moving functions like this from
Re: [Numpy-discussion] Advanced indexing: fancy vs. orthogonal
On Apr 4, 2015 4:12 AM, Todd toddr...@gmail.com wrote: On Apr 4, 2015 10:54 AM, Nathaniel Smith n...@pobox.com wrote: Core python broke backcompat on a regular basis throughout the python 2 series, and almost certainly will again -- the bar to doing so is *very* high, and they use elaborate mechanisms to ease the way (__future__, etc.), but they do it. A few months ago there was even some serious consideration given to changing py3 bytestring indexing to return bytestrings instead of integers. (Consensus was unsurprisingly that this was a bad idea, but there were core devs seriously exploring it, and no-one complained about the optics.) There was no break as large as this. In fact I would say this is even a larger change than any individual change we saw in the python 2 to 3 switch. The basic mechanics of indexing are just too fundamental and touch on too many things to make this sort of change feasible. I'm afraid I'm not clever enough to know how large or feasible a change is without even seeing the proposed change. I may well agree with you when I do see it; I just prefer to base important decisions on as much data as possible. -n ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] GSoC students: please read
On Mon, Mar 23, 2015 at 10:42 PM, Ralf Gommers ralf.gomm...@gmail.com wrote: Hi Stephan, all, On Mon, Mar 23, 2015 at 10:29 PM, Stephan Hoyer sho...@gmail.com wrote: On Mon, Mar 23, 2015 at 2:21 PM, Ralf Gommers ralf.gomm...@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. This was actually a very good idea, for next year we should require proposals on Github and added to an overview page. For this year it was a bit late to require all students to make this change, but I've compiled an overview of all proposals that have been submitted including links to Melange and the public drafts that students posted to the mailing lists: https://github.com/scipy/scipy/wiki/GSoC-project-ideas#student-applications-for-2015-to-scipy-and-numpy I hope that this helps. Everyone who is signed up as a mentor can comment (privately or publicly) in Melange, and everyone who's interested can now more easily find back the mailing list threads on this and comment there. Cheers, Ralf 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. ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
