Hi Jean-Pierre, On Mon, 13 Sep 2010 04:58:00 -0700 (PDT) Jean-Pierre Flori <[email protected]> wrote:
> I've got some other questions: These should be on a separate thread, on sage-devel or pynac-devel. > - Sage and pynac do not realize that 2^(-b_0) and (2^b_0)^(-1) are > equal. > I guess there is no canonical way of expanding 2^(a*b) into something > else, but it could be a good idea doing it when a or b is an integer > and the other one a variable ? I don't understand your suggestion. Are you saying we should * expand 2^(-b) to (2^b)^(-1) or * simplify (2^b)^(-1) to 2^(-b)? Apart from a few simple modifications, e.g., exp(a)^b -> exp(a*b) when possible, pynac keeps the automatic evaluation rules from GiNaC. These operations effect the performance of the library quite a bit. We should be careful before adding more of them, and perhaps consult the GiNaC developers in the process. > - Should symbolic sums be implemented into pynac (at some point...) to > avoid calling Maxima ? They should be implemented in Sage. I don't think this requires any modification at the C++ level in the pynac library. Actually, I am working on this right now. > By the way calling symbolic_sum(1,x,0,b_0) gives me an error whereas > calling sum(1,x,0,b_0) does not. This is the difference between sage.misc.functional.symbolic_sum and sage.calculus.calculus.symbolic_sum. The latter tries to convert the output received from maxima to the parent of the given expression. In your example, this is ZZ. The conversion fails of course. The wrapper sage.misc.functional.symbolic_sum first converts the first argument to a symbolic expression, which prevents the error. When we move to new code in sage/symbolic/summation/* (which is not in the library yet), things will be much cleaner. Cheers, Burcin -- 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
