Re: [Numpy-discussion] Numpy/Cython Google Summer of Code project idea
On Fri, Mar 7, 2008 at 11:41 AM, william ratcliff [EMAIL PROTECTED] wrote: Will Cython be compatible with OpenMP? I tried with weave some time back and failed miserably. Has anyone tried with ctypes? As far as I know cython has no explicit OpenMP support, but it *may* be possible to get it to generate the proper directives, using similar tricks to those that C++ wrapping uses: http://wiki.cython.org/WrappingCPlusPlus Note that this is just an idea, I haven't actually tried to do it. cheers f ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Numpy/Cython Google Summer of Code project idea
Hi Joris, On Fri, Mar 7, 2008 at 8:10 AM, Joris De Ridder [EMAIL PROTECTED] wrote: Thanks. I've a few questions concerning the objections against ctypes. It's part of the Python standard library, brand new from v2.5, and it allows creating extensions. Disregarding it, requires therefore good arguments, I think. I trust you that there are, but I would like to understand them better. For ctypes your extensions needs to be compiled as a shared library, but as numpy is moving towards Scons which seem to facilitate this quite a lot, is this still a difficulty/ objection? Secondly, looking at the examples given by Travis in his Numpy Book, neither pyrex nor ctypes seem to be particularly user- friendly concerning Numpy ndarrays (although ctypes does seem slightly easier). From your email, I understand it's possibly to mediate this for Cython. From a technical point of view, would it also be possible to make ctypes work better with Numpy, and if yes, do you have any idea whether it would be more or less work than for Cython? As Chris B. said, I also think that ctypes and cython are simply different, complementary tools. Cython allows you to create complete functions that can potentially run at C speed entirely, by letting you bypass some of the more dynamic (but expensive) features of python, while retaining a python-like sytnax and having to learn a lot less of the Python C API. Ctypes is pure python, so while you can access arbitrary shared libraries, it won't help you one bit if you need to write new looping code and the execution speed in pure python isn't enough. At that point if ctypes is your only tool, you'd need to write a pure C library (to the pure Python C API, with manual memory management included) and access it via ctypes. The point we're trying to reach is one where most of the extension code for numpy is Cython, to improve its long-term maintainability, to make it easier for non-experts in the C API to contribute 'low level' tools, and to open up future possibilities for fast code generation. I don't want to steal Travis' thunder, but I've heard him make some very interesting comments about his long term ideas for novel tools to express high-level routines in python/cython into highly efficient low-level representations, in a way that code written explicitly to the python C API may well make very difficult. I hope this (Travis' ideas teaser and all :) provides some better perspective on the recent enthusiasm regarding cython, as a tool complementary to ctypes that could greatly benefit numpy and scipy. If it doesn't it just means I did a poor job of communicating, so keep on asking. We all really want to make sure that this is something where we reach technical consensus; the fact that Sage has been so successful with this approach is a very strong argument in favor (and they've done LOTS of non-trivial work on cython to further their goal), but we still need to ensure that the numpy/scipy community is equally on board with the decision. Cheers, f ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Numpy/Cython Google Summer of Code project idea
Hi Robin, On Fri, Mar 7, 2008 at 8:36 AM, Robin [EMAIL PROTECTED] wrote: I hadn't seen the link Ondrej provided, although the 40 hour week seems to be a Python/PSF requirement. Prior to posting I had checked the Google information, where they say the time commitment depends on both the scope of your project and the requirements of your mentoring organisation. They also say they have had successful applicants in previous years from full-time students at non-US universities (who don't get a summer break), so I thought it might be possible for me to be considered. I also asked in #gsoc where I was advised 20 hours per week would be a good baseline, again depending on the project. Of course, I hope to contribute to Numpy/Scipy anyway - but this scheme would be a great way to kick-start that. I look forward to seeing Numpy/Scipy accepted as a mentor organisation this year anyway, even if I am unable to take part. I don't want to mislead anyone because I'm not directly involved with the actual mentoring, so forgive any confusion I may have caused. My current understanding is that we just don't have the time and resources right now for numpy/scipy to be a separate mentor organization, and thus we'd go in under the PSF umbrella. In that case, we'd probably be bound to the PSF guidelines, I imagine. I offered to get the ball rolling on the cython idea because time is tight and at the Sage/Scipy meeting there was lot of interest on this topic from everyone present. But the actual mentoring will need to come from others who are much more directly involved with cython and numpy at the C API level than myself, so I'll try not to answer anything too specifically on that front to avoid spreading misinformation. Cheers, f ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Numpy/Cython Google Summer of Code project idea
On Thu, Mar 6, 2008 at 3:13 PM, Joris De Ridder [EMAIL PROTECTED] wrote: On 06 Mar 2008, at 19:15, Fernando Perez wrote: http://www.cython.org/ is an evolved version of Pyrex (which is used by numpy and scipy) with lots of improvements. We'd like to position Cython as the preferred way of writing most, if not all, new extension code written for numpy and scipy, as it is easier to write, get right, debug (when you still get it wrong) and maintain than writing to the raw Python-C API. Could you explain a bit more why you think this is the best path to follow? Pyrex is kind of a dialect, so your extension modules would be nor python nor C, but a third language. Is this indeed easier to maintain? When you would like to use legacy C code for an extension, would you rewrite it in Cython? What are Cython's advantages compared to ctypes? Chris B gave what I think is a good reply to this, but feel free to ask if you have further questions. I think it's important that we reach some consensus on why this a good idea on technical grounds without anyone feeling like the decision is made opaquely in some back room, so please raise any doubts or concerns you may still have, and we'll do our best to address them. Cheers f ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Numpy/Cython Google Summer of Code project idea
Hi Robin, On Thu, Mar 6, 2008 at 12:48 PM, Robin [EMAIL PROTECTED] wrote: On Thu, Mar 6, 2008 at 6:15 PM, Fernando Perez [EMAIL PROTECTED] wrote: Any student interested in this should quickly respond on the list; such a project would likely be co-mentored by people on the Numpy and Cython teams, since it is likely to require expertise from both ends. Hello, I would like to register my keen interest in applying for Numpy/Scipy GSoC project. I am a first year PhD student in Computational Neuroscience and my undergraduate degree was in Mathematics. I have been using Numpy and Scipy for my PhD work for a few months now and have been building up to trying to contribute something to the project - I am keen to get more substantial real world programming experience... The projects described involving Cython definitely interest me, although I don't yet have a sufficient understanding of the Python C-API and Pyrex/Cython to gauge how demanding they might be. As a PhD student in the UK I don't have any official summer vacation, so I wouldn't be able to work full time on the project (I also have a continuation report due just before the GSoC final deadline which is a bit annoying). However I currently work 20 hours per week part time anyway, so I'm confident that I could replace that with GSoC and still keep up with my studies. I would be keen to chat with someone (perhaps on the IRC channel) about whether my existing programming experience and availability would allow me to have a proper crack at this. I understand that first organisations apply (deadline 12th March) with some suggested projects, and then towards the end of the month students can apply to accepted organisations, either for the suggested project or their own ideas. I'd love to see Numpy/Scipy apply as an organisation with these projects (and perhaps some others) so that interested students like myself can apply. As Ondrej pointed out, the expectation is a full-time commitment to the project. Other than that it sounds like you might be able to participate, and it's worth noting that this being open source, if you just have some free time and would like to get involved with an interesting project, by all means pitch in. Even if someone picks up an 'official' project, there's plenty to be done on the cython/numpy front for more than one person. Perhaps it's not out of place to mention that many people have made solid contributions for years to open source projects without monetary compensation, and still see value in the activity. If you can spend the time on it, you may still find many rewards out of the work. Cheers, f ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Numpy/Cython Google Summer of Code project idea
On 07.03.2008, at 09:59, Fernando Perez wrote: I doubt it's much better, and that's part of the point of the project: to identify the problems and fix them once and for all. Getting anything fixed in pyrex was hard due to a very opaque development process, but Cython is part of the Sage umbrella and thus enjoys a very open and active development community. Furthermore, they are explicitly interested in improving the Cython numpy support, and are willing to help along if this project goes forward. This is very good news in my opinion. Pyrex and Cython are already very useful tools for scientific computing. They lower the barrier to writing extension modules significantly (compared to writing directly in C), and they permit a continuous transition from a working Python prototype to an efficient extension module. I have been writing all my recent extension modules using Pyrex, and I definitely won't go back to C. If Cython gets explicit array support, it would become an even more useful tool for the NumPy community. Konrad. ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Numpy/Cython Google Summer of Code project idea
On Fri, Mar 7, 2008 at 1:17 AM, Konrad Hinsen [EMAIL PROTECTED] wrote: On 07.03.2008, at 09:59, Fernando Perez wrote: I doubt it's much better, and that's part of the point of the project: to identify the problems and fix them once and for all. Getting anything fixed in pyrex was hard due to a very opaque development process, but Cython is part of the Sage umbrella and thus enjoys a very open and active development community. Furthermore, they are explicitly interested in improving the Cython numpy support, and are willing to help along if this project goes forward. This is very good news in my opinion. Pyrex and Cython are already very useful tools for scientific computing. They lower the barrier to writing extension modules significantly (compared to writing directly in C), and they permit a continuous transition from a working Python prototype to an efficient extension module. I have been writing all my recent extension modules using Pyrex, and I definitely won't go back to C. If Cython gets explicit array support, it would become an even more useful tool for the NumPy community. Thanks for your feedback and support of the idea, Konrad. I just realized that I forgot to include this message that W. Stein (sage lead) sent me, which I think presents many of these points very nicely and may be useful in this discussion. cheers f -- Forwarded message -- From: Dag Sverre Seljebotn [EMAIL PROTECTED] Date: Tue, Mar 4, 2008 at 2:54 PM Subject: [Cython] Thoughts on numerical computing/NumPy support To: [EMAIL PROTECTED] Since Robert mentioned NumPy in relation with adding operator support I thought about sharing my more thoughts about NumPy - I'm very new to Cython so I guess take it for what it is worth - however what I've seen so far looks so promising for me that I might want to spend some time in a few months working on implementing some of this, which perhaps may make my thoughts more intereseting :-) Currently, Cython is mostly geared towards wrapping C code, but it is also an excellent foundation for being a numerical tool - but the rough edges are still prohibitive. A few relatively small steps (in terms of man-hours needed) would improve the situation a lot I think - not perfect, but perhaps in a few years we can have something that will finally kill FORTRAN :-) Three suggestions comes briefly here, if anyone's interested and it is not already discussed and decided I might flesh them out in PEP-style in the coming month? Note that a) is what is important for me, b) and c) is just something I throw along... a) numpy.ndarray syntax candy. Really, what one should implement is syntax support for PEP-3118: http://www.python.org/dev/peps/pep-3118/ Because this protocol will be shared between NumPy, PIL etc. in Python 3 it could make sense to simply have native/hard-coded support for this aspect without necesarrily making it a generic operator feature, and one can then use the same approach as will be needed for buffers in Python 3 for NumPy in Python 2? Example (where array is considered a new, Cython-native type that will have automatic conversion from any NumPy arrays and Python 3 buffers): def myfunc(array2, unsigned char arr): arr[4, 5] = 10 might be translated to the equivalent of the currently legal: def myfunc(numpy.ndarray arr): if arr.nd != 2 or arr.dtype != numpy.dtype(numpy.uint8): raise ValueError(Must pass 2-dimensional uint8 array.) cdef unsigned char* arr_buf = unsigned char*arr.data arr.data[4 * arr.strides[0] + 5 * arr.strides[1]] = 10 (Probably caching the strides in local variables etc.). That should do as a first implementation -- it is always possible to be more sophisticated, but this little will allow NumPyers to simply dive in. Specifically, the number of dimensions must be declared first and only direct access in that many dimensions are allowed. Slices etc. should be less important (they can be done on the Python object instead). Moving on from here, one should probably instead define bufferinfo from PEP-3118 and make it say def myfunc(bufferinfo arr): if arr.ndim != 2 or arr.format != B) or arr.readonly: raise ValueError(Must pass writeable 2-dimensional buffer with format 'B'.) ... with automatic conversion from NumPy arrays to bufferinfo. b) Allow numpy types? Basically, make it possible to say cdef uint8 myvar, at least for in-function-variables that is not interfacing with C code, so that for numerical use one doesn't need to learn C. This can be in addition, so it should not break existing code, though I can understand resentment against the idea as well. c) Probably controversial: More Pythonic syntax. A syntax for decoration of function arguments is decided upon (at least in Python 3), so to align with that one could allow for stuff like @Compile def myfunc(a: uint8, b: array(2, uint8), c: int = 10): d: ptr(int) =
Re: [Numpy-discussion] Numpy/Cython Google Summer of Code project idea
On 07 Mar 2008, at 10:02, Fernando Perez wrote: Chris B gave what I think is a good reply to this, but feel free to ask if you have further questions. I think it's important that we reach some consensus on why this a good idea on technical grounds without anyone feeling like the decision is made opaquely in some back room, so please raise any doubts or concerns you may still have, and we'll do our best to address them. Thanks. I've a few questions concerning the objections against ctypes. It's part of the Python standard library, brand new from v2.5, and it allows creating extensions. Disregarding it, requires therefore good arguments, I think. I trust you that there are, but I would like to understand them better. For ctypes your extensions needs to be compiled as a shared library, but as numpy is moving towards Scons which seem to facilitate this quite a lot, is this still a difficulty/ objection? Secondly, looking at the examples given by Travis in his Numpy Book, neither pyrex nor ctypes seem to be particularly user- friendly concerning Numpy ndarrays (although ctypes does seem slightly easier). From your email, I understand it's possibly to mediate this for Cython. From a technical point of view, would it also be possible to make ctypes work better with Numpy, and if yes, do you have any idea whether it would be more or less work than for Cython? Cheers, Joris P.S. I had some problems with bounces, sorry if this message appears more than once. Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Numpy/Cython Google Summer of Code project idea
On Fri, Mar 7, 2008 at 9:06 AM, Fernando Perez [EMAIL PROTECTED] wrote: Hi Robin, As Ondrej pointed out, the expectation is a full-time commitment to the project. Other than that it sounds like you might be able to participate, and it's worth noting that this being open source, if you just have some free time and would like to get involved with an interesting project, by all means pitch in. Even if someone picks up an 'official' project, there's plenty to be done on the cython/numpy front for more than one person. Perhaps it's not out of place to mention that many people have made solid contributions for years to open source projects without monetary compensation, and still see value in the activity. If you can spend the time on it, you may still find many rewards out of the work. Thanks, I hadn't seen the link Ondrej provided, although the 40 hour week seems to be a Python/PSF requirement. Prior to posting I had checked the Google information, where they say the time commitment depends on both the scope of your project and the requirements of your mentoring organisation. They also say they have had successful applicants in previous years from full-time students at non-US universities (who don't get a summer break), so I thought it might be possible for me to be considered. I also asked in #gsoc where I was advised 20 hours per week would be a good baseline, again depending on the project. Of course, I hope to contribute to Numpy/Scipy anyway - but this scheme would be a great way to kick-start that. I look forward to seeing Numpy/Scipy accepted as a mentor organisation this year anyway, even if I am unable to take part. Cheers, Robin ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Numpy/Cython Google Summer of Code project idea
Joris De Ridder wrote: Thanks. I've a few questions concerning the objections against ctypes. It's not so much an abjection (I think), but the fact that pyrex/Cython really are different beasts, with different goals. For ctypes your extensions needs to be compiled as a shared library, The compiling isn't the key issue -- you're right, that's not too big a deal, and Scons helps. If your goal is primarily to wrap existing C code, then ctypes is a good option. But if you are trying to write new code as extension modules, then Cython helps with that a lot. You do need to get C, but you don't actually have to write functional stand-alone C code. neither pyrex nor ctypes seem to be particularly user- friendly concerning Numpy ndarrays True, though it looks like one of the goals of Cython is to make it more user-friendly to numpy arrays -- I'm really looking forward to that. I suppose an example might be in order here - does anyone have a small, but not trivial, example of an extension that could be done with both Ctypes and Cython that we could examine? By the way, I know Greg Ewing was asked about better support for numpy arrays in Pyrex, and he said I'm *definitely* not going to re-implement C++ templates! -- is there talk of creating a way to write extensions that could operate on numpy arrays of arbitrary type with Cython? -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/ORR(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception [EMAIL PROTECTED] ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Numpy/Cython Google Summer of Code project idea
Will Cython be compatible with OpenMP? I tried with weave some time back and failed miserably. Has anyone tried with ctypes? Cheers, William On Fri, Mar 7, 2008 at 12:50 PM, Christopher Barker [EMAIL PROTECTED] wrote: Joris De Ridder wrote: Thanks. I've a few questions concerning the objections against ctypes. It's not so much an abjection (I think), but the fact that pyrex/Cython really are different beasts, with different goals. For ctypes your extensions needs to be compiled as a shared library, The compiling isn't the key issue -- you're right, that's not too big a deal, and Scons helps. If your goal is primarily to wrap existing C code, then ctypes is a good option. But if you are trying to write new code as extension modules, then Cython helps with that a lot. You do need to get C, but you don't actually have to write functional stand-alone C code. neither pyrex nor ctypes seem to be particularly user- friendly concerning Numpy ndarrays True, though it looks like one of the goals of Cython is to make it more user-friendly to numpy arrays -- I'm really looking forward to that. I suppose an example might be in order here - does anyone have a small, but not trivial, example of an extension that could be done with both Ctypes and Cython that we could examine? By the way, I know Greg Ewing was asked about better support for numpy arrays in Pyrex, and he said I'm *definitely* not going to re-implement C++ templates! -- is there talk of creating a way to write extensions that could operate on numpy arrays of arbitrary type with Cython? -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/ORR(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception [EMAIL PROTECTED] ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Numpy/Cython Google Summer of Code project idea
Christopher Barker wrote: By the way, I know Greg Ewing was asked about better support for numpy arrays in Pyrex, and he said I'm *definitely* not going to re-implement C++ templates! -- is there talk of creating a way to write extensions that could operate on numpy arrays of arbitrary type with Cython? Don't forget that one of the advantages of having data type information is that you can choose an algorithm accordingly. For example, large arrays of the smaller integer types can be efficiently sorted using histograms. The idea separating the algorithm from the datatype means that (ultra-fast-optimised) things like blas, fftw etc become quite hard to program. This is straying far from the discussion of a summer of code project, which seemed like a great idea. Jon ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Numpy/Cython Google Summer of Code project idea
Hi all, after the Scipy/Sage Days 8 meeting, we were all very impressed by the progress made by Cython. For those not familiar with it, Cython: http://www.cython.org/ is an evolved version of Pyrex (which is used by numpy and scipy) with lots of improvements. We'd like to position Cython as the preferred way of writing most, if not all, new extension code written for numpy and scipy, as it is easier to write, get right, debug (when you still get it wrong) and maintain than writing to the raw Python-C API. A specific project along these lines, that would be very beneficial for numpy could be: - Creating new matrix types in cython that match the cvxopt matrices. The creation of new numpy array types with efficient code would be very useful. - Rewriting the existing ndarray subclasses that ship with numpy, such as record arrays, in cython. In doing this, benchmarks of the relative performance of the new code should be obtained. Another possible project would be the addition to Cython of syntactic support for array expressions, multidimensional indexing, and other features of numpy. This is probably more difficult than the above, as it would require fairly detailed knowledge of both the numpy C API and the Cython internals, but would ultimately be extremely useful. Any student interested in this should quickly respond on the list; such a project would likely be co-mentored by people on the Numpy and Cython teams, since it is likely to require expertise from both ends. Cheers, f ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Numpy/Cython Google Summer of Code project idea
Fernando Perez wrote: after the Scipy/Sage Days 8 meeting, we were all very impressed by the progress made by Cython. cool stuff! A specific project along these lines, that would be very beneficial for numpy could be: Is there any way to set this up as a possible Google Summer of Code project? I don't suppose numpy.scipy is an officially listed project, is it? -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/ORR(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception [EMAIL PROTECTED] ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Numpy/Cython Google Summer of Code project idea
On Thursday 06 March 2008 13:15:27 Fernando Perez wrote: - Rewriting the existing ndarray subclasses that ship with numpy, such as record arrays, in cython. In doing this, benchmarks of the relative performance of the new code should be obtained. Fernando, I remember having huge difficulties trying to implement ndarray subclasses in vanilla Pyrex, to the extent that I gave up that approach. Does it work better in Cython (I haven't tried it yet) ? ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Numpy/Cython Google Summer of Code project idea
On Thu, Mar 6, 2008 at 6:15 PM, Fernando Perez [EMAIL PROTECTED] wrote: Any student interested in this should quickly respond on the list; such a project would likely be co-mentored by people on the Numpy and Cython teams, since it is likely to require expertise from both ends. Hello, I would like to register my keen interest in applying for Numpy/Scipy GSoC project. I am a first year PhD student in Computational Neuroscience and my undergraduate degree was in Mathematics. I have been using Numpy and Scipy for my PhD work for a few months now and have been building up to trying to contribute something to the project - I am keen to get more substantial real world programming experience... The projects described involving Cython definitely interest me, although I don't yet have a sufficient understanding of the Python C-API and Pyrex/Cython to gauge how demanding they might be. As a PhD student in the UK I don't have any official summer vacation, so I wouldn't be able to work full time on the project (I also have a continuation report due just before the GSoC final deadline which is a bit annoying). However I currently work 20 hours per week part time anyway, so I'm confident that I could replace that with GSoC and still keep up with my studies. I would be keen to chat with someone (perhaps on the IRC channel) about whether my existing programming experience and availability would allow me to have a proper crack at this. I understand that first organisations apply (deadline 12th March) with some suggested projects, and then towards the end of the month students can apply to accepted organisations, either for the suggested project or their own ideas. I'd love to see Numpy/Scipy apply as an organisation with these projects (and perhaps some others) so that interested students like myself can apply. Thanks, Robin PS My nick on IRC is 'thrope' and I try to hang out in there most of the time I am online. I am also on Google Talk at this email address. ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Numpy/Cython Google Summer of Code project idea
On Thu, Mar 6, 2008 at 9:48 PM, Robin [EMAIL PROTECTED] wrote: On Thu, Mar 6, 2008 at 6:15 PM, Fernando Perez [EMAIL PROTECTED] wrote: Any student interested in this should quickly respond on the list; such a project would likely be co-mentored by people on the Numpy and Cython teams, since it is likely to require expertise from both ends. Hello, I would like to register my keen interest in applying for Numpy/Scipy GSoC project. I am a first year PhD student in Computational Neuroscience and my undergraduate degree was in Mathematics. I have been using Numpy and Scipy for my PhD work for a few months now and have been building up to trying to contribute something to the project - I am keen to get more substantial real world programming experience... The projects described involving Cython definitely interest me, although I don't yet have a sufficient understanding of the Python C-API and Pyrex/Cython to gauge how demanding they might be. As a PhD student in the UK I don't have any official summer vacation, so I wouldn't be able to work full time on the project (I also have a continuation report due just before the GSoC final deadline which is a bit annoying). However I currently work 20 hours per week part time anyway, so I'm confident that I could replace that with GSoC and still keep up with my studies. Just a note, that the usual commitment is 40 hours/week, i.e. a full time job. See e.g.: http://wiki.python.org/moin/SummerOfCode/Expectations Ondrej ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Numpy/Cython Google Summer of Code project idea
On 06 Mar 2008, at 19:15, Fernando Perez wrote: http://www.cython.org/ is an evolved version of Pyrex (which is used by numpy and scipy) with lots of improvements. We'd like to position Cython as the preferred way of writing most, if not all, new extension code written for numpy and scipy, as it is easier to write, get right, debug (when you still get it wrong) and maintain than writing to the raw Python-C API. Could you explain a bit more why you think this is the best path to follow? Pyrex is kind of a dialect, so your extension modules would be nor python nor C, but a third language. Is this indeed easier to maintain? When you would like to use legacy C code for an extension, would you rewrite it in Cython? What are Cython's advantages compared to ctypes? Cheers, Joris Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Numpy/Cython Google Summer of Code project idea
I'm not a pyrex/Cython expert, but Joris De Ridder wrote: Pyrex is kind of a dialect, so your extension modules would be nor python nor C, but a third language. correct. Is this indeed easier to maintain? yes, because while you can write C extensions in C, you need to use the quite complex Python/C api, and get all sorts of things like reference counting, etc right too -- that is hard. Also, with Cython, you can quite easily mix Python and C in one place, so you truly only need to put the performance intensive bits in Cython specific code. When you would like to use legacy C code for an extension, would you rewrite it in Cython? no -- you can call regular old C from Cython, so you can use it to write wrappers, too. What are Cython's advantages compared to ctypes? for ctypes, you also avoid the wrapping code, but your C code needs to be compiled as a library, and can't use python types directly, which is more limiting. I think Cython is easier for someone not very experienced in C, and no harder for someone who is. -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/ORR(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception [EMAIL PROTECTED] ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
