Symbolic computation and pynac

0 vue
Accéder directement au premier message non lu

Jean-Pierre Flori

non lue,
13 sept. 2010, 11:26:0713/09/2010
à 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
Répondre à tous
Répondre à l'auteur
Transférer
0 nouveau message