Sorry I haven't had a chance to look into this yet, but I'm probably not going to have internet access for a while so I figured I'd send a quick reply now.
On Nov 14, 2007, at 2:03 AM, Jonathan Hanke wrote: > Hi Robert, > > I have been playing around with it, and there seems to be a problem > with the way I'm trying to call any C-level IntegerMod since I can > also generate errors and segfaults when I try to use the more > stable IntegerMod_gmp. Can you use hg_sage.diff() to see what changed? > > I think that the real issue is I don't know how to properly call > cython functions. > > 1) I can declare variables and do some basic operations with: > > R = 5 > cdef IntegerMod_gmp one > one = IntegerMod_gmp(IntegerModRing(R), 1) > print one + one > > However bad things happen when I try to multiply > > print one * one > > and this is where some of my problems are. > > > 2) I can create lists by repeated use of the .append() method, but > I don't know a cythonic way of creating lists (or if this is even > desirable). List comprehensions for now, or use native c arrays. > > 3) I read in the programming guide that we need to have cdef'ed > methods declared as public before we can use them, and > IntegerMod_gmp is not "public". Is this a problem? Why or why not? cef'd attributes need to be public to use them from python, nothing you do to cdef functions makes them accessable. (But cpdef can be.) The programming guide is so out of date in terms of using Pyrex/ Cython, and IIRC lots of it is misleading or just plain false. Everything but the C++ section needs a major rewrite. Use the stuff on http://wiki.cython.org/ And update it too, lots of people have similar questions. Also, I've been working on http://sage.math.washington.edu/home/ robertwb/cython/polynomial_element.pyx.html > 4) How do I know when to coerce a variable with <...>? If I do, > how does it do the coercion? Can I coerce an IntegerMod to an > IntegerMod_gmp? What about the other way? Never, ever, coerce variables with <...> That is C casting, and is used to tell Cython when you have an object that you know is a more specific type and you want to use it as such. This is probably where your segfaults are coming from. > 5) How would I find functions like PyList_New and PyInt_FromLong > from the following example when I need them (or even decide what > they do when I see them)? > > def f4(int n): > cdef int i > v = PyList_New(n) > for i from 0 <= i < n: > PyList_SET_ITEM(v, i, <object>PyInt_FromLong(i)) > #WARNING -- maybe I need to incref the ref to the long?! > return v The answer is, don't do stuff like this, do [i for i from 0 <= i < n] which will be just as fast, easier to read, and won't cause a segfault if you mess up. > 6) How do I know when I need to allocate/release memory? I don't > need to for a long, but I do for an mpz_t. > What about for an instance of Python/Cython class? How do I do this? Typically, you obey the c semantics of allocating/releasing memory for stuff like mpz_t, int*, etc. If you allocate, somewhere you have to figure out where to dealloc. But see below. As for Python/Cython classes, they are all taken care of by the python garbage collector, so you have no need to alloc or free them. Every cython (cdef) class has a __new__ (or __cinit__*) method which gets called exactly once at object creation. This is the best place to allocate class members (such as mpz_t's). When a class is about to be free'd (as determined by the Python garbage collector), the __dealloc__ method is called and this is the spot to free anything you allocated in __new__. This makes most memory handling very easy. * Greg recently changed the name of __new__ to __cinit__ to not conflict with Python's version of __new__. Both coexist for the moment and are aliases. Someday I'll do a s/__new__/__cinit__/g throughout all sage cython files. > That's about all I can think of. I looked at the cython section of > the Programming Guide, but it would be really helpful to have > several small worked "hacking projects" to see how design decisions > are made, and how everything fits together. I'd be happy to try to > contribute such information once I learn it. That would be great. > > Thanks a lot, > > -Jon > =) > > P.S. Feel free to post your response to the sage-devel list as > well if you think it's appropriate. If the past is any indication, I'm sure lots of other people have similar questions. --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~----------~----~----~----~------~----~------~--~---
