Jean-Pierre Flori
non lue,13 sept. 2010, 11:26:0713/09/2010Connectez-vous pour répondre à l'auteur
Connectez-vous pour transférer le message
Vous n'êtes pas autorisé à supprimer des messages dans ce groupe
Connectez-vous pour signaler le message
Afficher le message d'origine
Soit les adresses e-mail sont anonymes pour ce groupe, soit vous devez disposer de l'autorisation "Afficher les adresses e-mail des membres" pour afficher le message d'origine.
à sage-devel
Hi,
> These should be on a separate thread, on sage-devel or pynac-devel.
Done.
> 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.
Calling "simplify" on "2^(-x)*2^x" does the trick and returns "1".
However it does so through Maxima, so that it is quite slow.
Calling "subs" which only use pynac is much faster.
Of course, I am aware that it might not be a good idea doing it in
pynac and it is quite specific to what i am coding right now where
such product occurs very often.
Especially, there is nothing canonical to do with something like
"2^(x*y)".
Using the "coefficients" function, which seems to use Maxima, does
something like that (but the other way around...):
sage: ((2^y)^2*x).coeffs(x)
[[2^(2*y), 2]]
whereas using the "coeff" function which does not use Maxima does not
rewrite it:
sage: ((2^y)^2*x^2).coeff(x,2)
(2^y)^2
so it can be somehow misleading.
> 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.
Thanks, that is very good news.
> 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.
Thanks for the explanation, it was not clear from the documentation
which showed that the functions were different, but had exactly the
same "DocString".
Cheers,
JP