Comment #79 on issue 1694 by nicolas.pourcelot: solve has many issues with
fractions
http://code.google.com/p/sympy/issues/detail?id=1694
Thanks Aaron.
What happens if I do some modification locally, and use git fetch after ?
@Vinzent (77)
For Adds, factor() might be a good idea.
+1
And
Comment #80 on issue 1694 by Vinzent.Steinberg: solve has many issues with
fractions
http://code.google.com/p/sympy/issues/detail?id=1694
+1 for solve() returning a set. You will use them internally for rational
functions anyway, there is no point in converting them back to a list.
Also,
Comment #81 on issue 1694 by nicolas.pourcelot: solve has many issues with
fractions
http://code.google.com/p/sympy/issues/detail?id=1694
There is at least one drawback with sets:
In [8]: 1 == S.One
Out[8]: True
In [9]: [1] == [S.One]
Out[9]: True
In [10]: set([1]) == set([S.One])
Comment #82 on issue 1694 by nicolas.pourcelot: solve has many issues with
fractions
http://code.google.com/p/sympy/issues/detail?id=1694
Work in progress... but issues remain.
There is at least one issue with factor() use:
solve(4*3**(5*x+2)-7,x) does not work anymore.
Comment #83 on issue 1694 by asmeurer: solve has many issues with fractions
http://code.google.com/p/sympy/issues/detail?id=1694
+1 on changing S.Integer.__hash__. I'll create a new issue for that (it
will probably be issue 1973).
What happens if I do some modification locally, and use
Comment #84 on issue 1694 by Vinzent.Steinberg: solve has many issues with
fractions
http://code.google.com/p/sympy/issues/detail?id=1694
The one disadvantage that I could see for sets over lists is that you
can't reference items in a set. So you may not want the solutions to be
sorted
Comment #16 on issue 1884 by Vinzent.Steinberg: remove old assumptions
http://code.google.com/p/sympy/issues/detail?id=1884
Rebased the new_assump branch on master.
--
You received this message because you are subscribed to the Google Groups
sympy-issues group.
To post to this group, send
Comment #17 on issue 1884 by Vinzent.Steinberg: remove old assumptions
http://code.google.com/p/sympy/issues/detail?id=1884
Current problems are some random failures for unknown reasons. Also I could
not yet debug why symbols() does not get to the correct scope (see the
go_back kwarg and
Status: Accepted
Owner: Vinzent.Steinberg
CC: fredrik.johansson
Labels: Type-Defect Priority-Medium
New issue 1975 by Vinzent.Steinberg: nsimplify() should be recursive
http://code.google.com/p/sympy/issues/detail?id=1975
In [2]: nsimplify(1./7 * x)
Out[2]: 0.142857142857143⋅x
This should be
Status: Accepted
Owner: asmeurer
Labels: Type-Defect Priority-Medium Assumptions
New issue 1976 by asmeurer: Add is_one attribute to Basic (or Expr)
http://code.google.com/p/sympy/issues/detail?id=1976
This would make it consistent with the Polys:
In [14]: Poly(1, x).is_one
Out[14]: True
In
Comment #2 on issue 1975 by Vinzent.Steinberg: nsimplify() should be
recursive
http://code.google.com/p/sympy/issues/detail?id=1975
nsimplify() and friends have been added to Expr.
--
You received this message because you are subscribed to the Google Groups
sympy-issues group.
To post to
Updates:
Labels: -Type-Defect -Priority-Medium Type-Enhancement Priority-Low
Comment #2 on issue 1976 by asmeurer: Add is_one attribute to Basic (or
Expr)
http://code.google.com/p/sympy/issues/detail?id=1976
Rather than Poly(1, x).is_one, I would expect to see Poly(1, x) == S(1),
12 matches
Mail list logo
