Thank you for your comments on my patch It is a legitimate concern, I agree (and could affect many number-theoretical or similar functions); and the principle of solution that you are proposing could be a good one. (I like the idea of writing some code in cython that calls pari directly, I don't know much on cython internals to help on this)
I could not read your modification to my patch since you've uploaded that as an hg bundle. I think that for trac the best would be to upload patches in plain text. That way, trac knows how to format it so that it can be easy read on the web (it would be nice to have something like trac but based on mercurial, rather than in subversion, but I doubt that such a program exists) Pablo On 9/10/07, Joel B. Mohler <[EMAIL PROTECTED]> wrote: > > Hi, > > David Harvey raised a speed question on > http://sagetrac.org/sage_trac/ticket/628 > It's a legitimate concern, but as far as I can tell, it's a completely > orthogonal issue to that specific patch thanks to Pablo's clever coding (all > of the exceptional code only occurs if we aren't on the fast path anyhow). > The issue is basically that we want the binomial function to be as fast as > possible for 2 integer arguments. I've observed similar potential issues > with the moebius function. > > There are an awful lot of python name lookups before we actually get to the > arithmetic work (in pari). I guess the only real way to fix that is to write > some cython and call pari directly. I think this would be worthwhile. I'm > wondering though if there isn't a way to make this moderately easy in these > cases. > > I suggest having a cython'ed function which takes parameters to coerce and a > function pointer (?). It coerces the parameters (quickly) to Integers (or > some agreed upon format, mpz, etc) and passes them down to the function > pointer which is then guaranteed an appropriate data format and can just do > the arithmetic. If the coercion fails, an exception is thrown. The value of > this intermediary is that the "isinstance(int,long,Integer)" is only coded > once and can thus be maintained and made as quick as possible. This idea is > very sketchy in my mind so I think it might need some refinement. > > The binomial function then gets a prefix something like: > > try: > call_fast_integer_function( x, m, _binomial_raw ) > except CoercionError: > # compute binomial slowly .... > > The principle refinement needed is: How can call_fast_integer_function > bewritten generically? What is _binomial_raw -- a c-function, a cython > function? > > -- > Joel > --~--~---------~--~----~------------~-------~--~----~ 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/ -~----------~----~----~----~------~----~------~--~---
