Comment #32 on issue 1766 by smichr: expand(power_base=True) is too
aggressive
http://code.google.com/p/sympy/issues/detail?id=1766
I don't find "assert cls(0.9) is S.Zero" in my branch...could you clarify?
I did (after sending) see some of the other failures and have corrected
those, I
believe. All tests pass here.
<<<1785: The comment above 'def _maxfac' ...>>>
OK, it's been all encapsulated and documented as a module-hidden
function.
<<<more conservative together: typos: 'extract Add entire add', 'testsing
ode
solutions'.>>>
...will add to the todo
<<<Is _gcdn really only useful for internal stuff?>>>
not sure...I could remove the _ if you think it might be useful. Should
I include
it in the __init__ so it becomes part of the namespace? It could be useful
in
simplification if, e.g. you want to clear a 2 from eq=2+2*x. This is
starting to
duplicate things that will be in polys (.content(), as I recall) but IMO
that's ok
since one shouldn't (necessarily) have to convert expressions to polys to
get at a
useful polys feature. With _gcdn you can do the following which might be
helpful in
general:
eq=24+36*x
_gcdn(eq)
(12, 2 + 3*x)
But maybe it needs a different name? content_core or something? For
reference,
Poly(12+36*x,x).content
12
For now I haven't changed anything.
<<<set() == set([]) by the way.>>>
THANKS! I don't know where I got in my habits the latter. I changed it.
<<<Except-anything-blocks are evil, >>>
I know, but it's a one-liner. If it fails (for any reason) I just want
to skip it.
<<<Do you want to use except (PolynomialError, ZeroDivisionError)?>>>
yes, but I forget the problems that I was having and, again, II just
wanted the
one-liner to be skipped if it failed. I put it back and will deal with the
future
issues...in the future. :-)
<<<What is the motivation behind areq(), arne() and friends?>>>
The ode tests are my nemesis...the ode module is (too) dependent on
simplification behavior and whenever I make some changes to extraction
routines and
wot not, I end up having to twiddle with the form of the ode solutions.
Those
"friends" are my buddies to help me stop tweaking the format of the
solutions to the
equations. If == would compare canonical forms that would be a big help.
Without
that, the user is left to try make a more robust comparison routine...and
this was my
attempt.
<<<The non-commutative part looks nice, I'd only add more tests, for
example where it
should not work, like separatevars(n1*n2 + n2*n1) from the docstring.>>>
added.
<<<Some changed ODE tests should be broken on several lines>>>
Will do after I get a +/- on the "friends".
<<<This is a huge commit, but I assume it can be hardly split?>>>
I don't think so...this behavior touches a lot of different things.
This is my
GWOC commit (Google Winter of Code) :-)
[[[And I'm still of the opinion...]]]
It doesn't matter much to me where it goes...if we can settle on the
functionality
(esp. how the defaults should be handled) then I can do the final moves
before the
final commit.
An all-test-and-doctest passing version has been repushed.
--
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 [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sympy-issues?hl=en.
