Updates:
Status: Fixed
Comment #15 on issue 1731 by smi...@gmail.com: fraction can be more flexible
http://code.google.com/p/sympy/issues/detail?id=1731
(No comment was entered for this change.)
--
You received this message because you are subscribed to the Google Groups
sympy-issues
Comment #14 on issue 1731 by smichr: fraction can be more flexible
http://code.google.com/p/sympy/issues/detail?id=1731
Although I originally changed what was returned from fractions (and someone
mentioned that they were wary of t2 because of this) that change has been
reverted. This commit
Comment #13 on issue 1731 by smichr: fraction can be more flexible
http://code.google.com/p/sympy/issues/detail?id=1731
The big difference between fraction and as_numer_denom is that fraction
just gives the naive numer/denom fraction(x/(1+1/b)) - (x, 1 + 1/b)
whereas as_numer_denom gives
Updates:
Labels: smichr
Comment #12 on issue 1731 by asmeurer: fraction can be more flexible
http://code.google.com/p/sympy/issues/detail?id=1731
(No comment was entered for this change.)
--
You received this message because you are subscribed to the Google Groups
sympy-issues group.
Comment #11 on issue 1731 by smichr: fraction can be more flexible
http://code.google.com/p/sympy/issues/detail?id=1731
it's now in branch t at github/smichr with the same commit number, 1731.
--
You received this message because you are subscribed to the Google Groups
sympy-issues group.
To
Updates:
Labels: -NeedsBetterPatch NeedsReview
Comment #10 on issue 1731 by smichr: fraction can be more flexible
http://code.google.com/p/sympy/issues/detail?id=1731
commit 1731 in branch 1766 at smichr's github has a reworked as_numer_denom
and fractions
--
You received this
Comment #8 on issue 1731 by Vinzent.Steinberg: fraction can be more flexible
http://code.google.com/p/sympy/issues/detail?id=1731
What's the advantage of fraction over .as_numer_denom()?
--
You received this message because you are listed in the owner
or CC fields of this issue, or because you
Comment #9 on issue 1731 by asmeurer: fraction can be more flexible
http://code.google.com/p/sympy/issues/detail?id=1731
As I noted above, fraction can deal with assumptions on the exponents.
Also, fraction seems to be a full algorithm whereas
as_numer_denom is implemented method wise on the
Updates:
Labels: -NeedsReview NeedsBetterPatch
Comment #7 on issue 1731 by Vinzent.Steinberg: fraction can be more flexible
http://code.google.com/p/sympy/issues/detail?id=1731
(No comment was entered for this change.)
--
You received this message because you are listed in the owner
or
Comment #1 on issue 1731 by Vinzent.Steinberg: fraction can be more flexible
http://code.google.com/p/sympy/issues/detail?id=1731
Are you sure that numer, denom, fraction_expand, numer_expand and
denom_expand have to
be exported to the global namespace? Shouldn't they be methods or
Comment #2 on issue 1731 by ronan.l...@gmail.com: fraction can be more
flexible
http://code.google.com/p/sympy/issues/detail?id=1731
I think that the real question is: what is the relationship between
fraction and
.as_numer_denom? It looks like it's the same thing with two separate
Comment #5 on issue 1731 by asmeurer: fraction can be more flexible
http://code.google.com/p/sympy/issues/detail?id=1731
Fraction handles assumptions:
In [2]: n = Symbol('n', negative=True)
In [3]: (x**n).as_numer_denom()
Out[3]:
⎛ n ⎞
⎝x , 1⎠
In [4]: fraction(x**n)
Out[4]:
⎛-n⎞
⎝1, x
12 matches
Mail list logo
