Comment #3 on issue 1883 by mattpap: Recode dmp_zero_p to be non-recursive
http://code.google.com/p/sympy/issues/detail?id=1883
Does this mean that the API for this file is unstable
It is unstable and incoherent between different types of polynomials. When
I started
working on this there were just a few functions and everything was simple
and clear.
But later on the API has grown enormously and it needs refactoring.
That is one (not very good at all) reason why there are no doctests in
dense*.py
files, as all those files will require very deep changes. My primary goal
for last
months was to implement all important polynomial manipulation algorithms
and assure
their correctness. There were other goals, like efficiency, but they were
considered
minor. Now this will change because most algorithms are implemented and we
need to
improve speed and consistency in the module.
or will that be going in some separate sparcebasic.py file?
I plan to have two polynomial representations, i.e. recursive dense
(possibly in
iterative version where ever possible) and sparse distributed. Arithmetics
and basic
stuff will be separately implemented (note some functions from
densetools.py will be
moved to basic). Everything that can be shared across different
representations will
be put in separate files and refactored to make it independent of the
underlying
polynomial representation. Some tools are already outside densetools.py,
like
factorization algorithms and root isolation. But all of those will need to
be refactored.
Otherwise, I would like to write doctests for the functions in
densebasic.py, as
it would have made things a little easier for me in doing this to have
them :).
You obviously can, but remember that quite a few things will change. At the
moment I
can't give any estimates how much time it will take to introduce the new
polynomial
representation and refactor all lowlevel functions, because I ought to be
writing my
masters thesis right now.
I noticed that many of the functions take K as an argument but don't use
it. Is
there a reason for this? I didn't want to go through and change the API
without
being sure that there isn't some magic or something going on here. An
example of
such a function is dmp_nest()
The original idea was that all dup_* and dmp_* functions will have the
ground domain
(K) as the last argument. It happened that for many functions this was an
overkill so
I decided to skip this argument. Some functions used K at some point but
later it
happened that this argument is not needed anymore, but I didn't want to
change the
API. Basically there are functions like *_degree() which obviously do not
require
domain specification. Those non-obvious usually have, but this might be
inconsistent.
--
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.
