On Mon, Feb 6, 2012 at 1:01 PM, Jason Grout <[email protected]> wrote: > On 2/6/12 1:33 PM, Oscar Lazo wrote: >> >> That is very nice! Unfortunately I need to evaluate many different >> expressions quickly, so the copy-paste aproach is not an option. >> That's why I wrote the fast_complex function. I'll be working in such >> a general implementation, do you think it's worth getting it into >> sage, or should fast_float be modified to accept complex expressions? > > > fast_callable is the answer to getting fast_float to accept complex > expressions. Seeing how fortran just stomps on fast_callable and even > copy-paste of Cython (i.e., it's *way* faster), I think it would be really > cool to get a fast_callable backend that uses fortran. A step towards that > would be your fortran-generating fast_complex. > > It could be called as fast_callable(expr, domain=CDF, compiler="fortran") or > something.
Note that fast_callable (and fast_float) before it use an interpreter because actually invoking the compiler can be literally millions of times slower than a sub-optimal evaluation (with domain=RDF or domain=CDF). That can mean that if you're actually evaluating the function less then a million (or thousand, or whatever depending on the ratio) times then you're not gaining anything even if the compiled code runs in no time at all. That being said, fast_callable construction could stand to be faster, and even more there's *lots* of low-hanging for fast_callable over the complex field here: sage: z_fast_callable=fast_callable(z,vars=[K1,K2],domain=CC) sage: z_fast_callable.python_calls() [exp, exp, exp, exp, exp, exp, exp, exp, exp, exp, exp, exp, exp, exp, exp, exp, exp, exp, exp, exp] sage: z_fast_callable=fast_callable(z,vars=[K1,K2],domain=CDF) sage: z_fast_callable.python_calls() [(^2), (^2), (^2), (^2), (^2), (^2), (^2), (^2), (^2), (^2), (^2), (^2), (^2), (^2), (^2), (^2), (^3), (^3), (^3), (^2), (^3), (^3), (^2), (^2), (^3), (^3), (^2), (^3), (^3), (^2), (^2), (^3), (^2), (^3), (^2), (^3), (^3), (^2), (^2), (^3), (^2), (^2), (^3), (^3), (^3), (^2), (^3), (^3), (^2), (^2), (^3), (^3), (^2), (^3), (^3), (^2), (^2), (^3), (^2), (^3), (^2), (^3), (^3), (^2), (^2), (^3), (^2), (^2), (^2), (^2), (^2), (^2), (^2), (^2), (^2), (^2), (^2), (^2), (^2), (^2), (^2), (^2), (^3), (^3), (^3), (^2), (^3), (^3), (^2), (^2), (^3), (^3), (^2), (^3), (^3), (^2), (^2), (^3), (^2), (^3), (^2), (^3), (^3), (^2), (^2), (^3), (^2), (^2), (^3), (^3), (^3), (^2), (^3), (^3), (^2), (^2), (^3), (^3), (^2), (^3), (^3), (^2), (^2), (^3), (^2), (^3), (^2), (^3), (^3), (^2), (^2), (^3), (^2), (^2)] Common sub-expression elimination (and constant folding) would be really handy here for this particular example as well, I wonder if that's the trick that the Fortran compiler is able to pull. I don't have time to play with it now, but it may also be worth trying "cdef extern from "complex.h": pass" to use c99 complex numbers in the Cython version. - Robert -- To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/sage-support URL: http://www.sagemath.org
