On Sep 19, 2007, at 6:26 PM, John Voight wrote:
> > Hi Robert! > > Thanks very much for your message. > >>> That's probably what is going on. My Cython routine creates and >>> returns a list of integers: it's begins as a cdef int[], and >>> apparently it doesn't like it when I just return that, so I just do >>> something silly like >>> return [ self.a[i] for i in range(self.n) ] >> >> Can declare the return type of cdef functions to be int* or whatever >> (though if you returned an int* that you allocated, things you would >> have to remember to free it later on (exactly once). Also, if you >> have a function that returns a list of ints, you could pass it in a >> list to fill rather than going via python lists. > > I need to def my functions so they can be accessed from Python calls. > The latter suggestion is a good one, and so I implemented it. I was > hoping it would save some time, but alas. I guess if I did everything > in Cython... :) Well, if it's just returning the result of a long computation, it shouldn't matter, but if it's getting called 100s of times a second then it could make a difference. >> Another thing I noticed is that you are using "range" a lot. A much >> faster syntax is "for i from 0 <= i < n" which is the same as "for i >> in range(n)" but literally 100+ times faster (make sure all your loop >> indices are cdef'd though). > > I made this change throughout and unfortunately it made no visible > difference to my final runtime. I made sure to cdef the indices. I > wonder if the effect is negligible over such small ranges? Hmm... it all depends on how much time is spent going around the loop vs. in a single iteration of the loop. For instance, it would make a huge difference in eval_seq_as_poly, but not as much in incr(). And if, for instance, all the time is being spent in calculating the discriminant rather than in incr() it would hardly make a difference at all. You would have to profile you code to see (I assume you've done this...) >> One thing I noticed when going through your code is that you >> try to free memory in the __del__ function, which is the wrong place >> (don't ask my whey they named it as such). This should be done in a >> __dealloc__ function instead (which is perhaps leading to one memory >> leak, but it looks like it only happens once. > > Thanks! I couldn't find a good reference for this--and so I made a > naive assumption about what __del__ was supposed to do! :) Yeah, it's not the best choice of names. Even worse is __new__ which means a totally different thing in Python and Pyrex. (I think it should probably be renamed to __alloc__). - Robert --~--~---------~--~----~------------~-------~--~----~ 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/ -~----------~----~----~----~------~----~------~--~---
