FYI, http://trac.sagemath.org/sage_trac/ticket/12513
On Mon, Feb 6, 2012 at 1:53 PM, Robert Bradshaw <rober...@math.washington.edu> wrote: > On Mon, Feb 6, 2012 at 1:01 PM, Jason Grout <jason-s...@creativetrax.com> > 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 sage-support@googlegroups.com To unsubscribe from this group, send email to sage-support+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-support URL: http://www.sagemath.org
