Comment #4 on issue 2315 by matt...@gmail.com: integrate(1/(x**2 + n**2, x)
failure, where n is an integer
http://code.google.com/p/sympy/issues/detail?id=2315
This patch is wrong because it shouldn't happen that for a certain case
div() changes the domain of computation (ZZ -> QQ). A sane solution is to
use 'auto' flag, e.g.:
In [1]: Poly(x).div(Poly(2, x))
Out[1]: (Poly(0, x, domain='ZZ'), Poly(x, x, domain='ZZ'))
In [2]: Poly(x).div(Poly(2, x), auto=True)
Out[2]: (Poly(1/2*x, x, domain='QQ'), Poly(0, x, domain='QQ'))
@Aaron: Domains in polys can be viewed as static types with type inference
(more or less). Bugs like this one simply show that modules that use polys
were often coded without sufficient care taken about the domains of
computation and fulfillment of algorithmic criteria, and ratint() is a good
example of this. If only ratint() took care of setting up proper domains,
all those problems would have been non-existent.
Changing div() to use QQ by default won't help here. For example if an
algorithm requires computations in an algebraic closure of some domain, we
always tell polys what the final domain should be (because it's very
expensive to do computations in such domains and not always possible to
infer correct domain automatically).
I will speed up work on a specific version context managers for polys (no
with statement required). This should help tracking domains in algorithms
and will make it much more pleasant than it is currently. Still we will
have to put a lot of attention to those details.
--
You received this message because you are subscribed to the Google Groups
"sympy-issues" group.
To post to this group, send email to sympy-issues@googlegroups.com.
To unsubscribe from this group, send email to
sympy-issues+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sympy-issues?hl=en.
