Comment #57 on issue 1598 by mattpap: New polynomials manipulation module
http://code.google.com/p/sympy/issues/detail?id=1598
After a lot of work, finally, multiple algebraic extensions are ready, e.g.:
In [1]: factor(x**4+2, extension=[I])
Out[1]:
4
2 + x
In [2]: factor(x**4+2, extension=[sqrt(2)])
Out[2]:
4
2 + x
In [3]: factor(x**4+2, extension=[sqrt(2), I])
Out[3]:
⎛ ⎽⎽⎽ 2⎞ ⎛ ⎽⎽⎽ 2⎞
⎝ⅈ⋅╲╱ 2 + x ⎠⋅⎝- ⅈ⋅╲╱ 2 + x ⎠
In [4]: expand(_)
Out[4]:
4
2 + x
For the moment very slow and internally messy, but working.
So the last missing and very important element of polys puzzle are
splitting fields,
which split polynomials into linear factors (the benefit is that we don't
have to
know the field in advance, it will be constructed by the algorithm and all
roots will
be given as a side effect).
> Perhaps the solution to comment 46 is to have Poly instantiate from a
> basic
> expression with field=True automatically:
Is there a reason why you can't just write this:
>>> roots(3*x**3+5*x**2+7*x+11)
(which will apply field=True by default)? Am I not clear enough that Poly
is about
being explicit (domain, etc.). If you don't care about what problem you are
solving
and you want only roots then use Basic expressions, like above, and polys
will try to
figure out what you what to do (if you don't what to say this explicitly).
> That's because the field defaulted to ZZ. But if we had sent field=True
> we would
> have gotten a better result:
btw. "That's because the domain defaulted to ZZ (...)"
You are mixing ideas about different problems. One thing is what kind of
domain Poly
will select by default for a certain class of polynomials. Another is lack
of `auto`
keyword to roots() (I don't say it's necessary at all). And a completely
different
thing is that roots fails for ZZ polynomials, whereas it should at least
return an
empty solution space (or only integer solutions).
> So if the user is just trying to make a generic poly, is there a reason
> not to
> do field=True for them or should they just get more of an education about
> Polys
> before trying to do anything with them?
There is: the smaller the domain is, the faster computations are. Also, if
you enter
a polynomial with integer coefficients you expect integer only operations
to be done
and integer valued result (if of course possible).
Notice also that different ground domains have different coefficient
simplification
procedures, e.g. in a ring we remove content (take primitive part) and in a
field we
compute a monic polynomial. Being explicit about all this is important
because when
you implement some algorithm and it requires you to perform computations in
some
specific domain, then if you tell Poly to compute in this domain, you can
be sure (up
to bugs of course) that it will use only appropriate operations during all
your
computations. This way we guarantee correctness and robustness and pay a
little for
being explicit about what we expect and what we actually do.
> Issue 1759 has an upgrade possibility for the factor/gcd method (...)
No. Every one knows well what factor() is supposed to do and currently it
does this.
What? It factors polynomials and, eventually, rational functions, if you
tell it to
do that. If you want something extra that uses factorization, then create a
function
with explicit goal and name it explicitly, and add it to some more general
rewrite
function (like simplify() or whatever). This way you will cut on user
confusion. I
believe that at some point we will use context managers to save us typing.
Something like:
with AutoFactor():
do_some_computations()
will take all Adds and apply factor() to them and reevaluate whole
expression.
--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings
--
You received this message because you are subscribed to the Google Groups
"sympy-issues" group.
To post to this group, send email to sympy-iss...@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.
