Comment #23 on issue 3560 by ronan.l...@gmail.com: solve() is a giant mess
http://code.google.com/p/sympy/issues/detail?id=3560
I now think that the solution object should rather be a Boolean. The
problem with a Set in the multivariate case is that it forces the variables
to be ordered, caus
Comment #22 on issue 3560 by asmeu...@gmail.com: solve() is a giant mess
http://code.google.com/p/sympy/issues/detail?id=3560
So here are my ideas
SolutionSet should just be a subclass of Set. I think we need to use a
custom subclass instead of just a Set because data like whether or not it
Comment #21 on issue 3560 by asmeu...@gmail.com: solve() is a giant mess
http://code.google.com/p/sympy/issues/detail?id=3560
I think that's a good idea. We often confuse properties of the individual
solutions and the properties of the whole set of solutions that we might
want to put on this
Comment #20 on issue 3560 by waks...@gwax.com: solve() is a giant mess
http://code.google.com/p/sympy/issues/detail?id=3560
Between this and issue 1234 I think that we might want both a Solution
object and a SolutionSet object (or some sort of unified object that
handles both cases).
I wou
Comment #19 on issue 3560 by asmeu...@gmail.com: solve() is a giant mess
http://code.google.com/p/sympy/issues/detail?id=3560
Another thing to think about: issue 3699.
--
You received this message because this project is configured to send all
issue notifications to this address.
You may adj
Issue 3560: solve() is a giant mess
http://code.google.com/p/sympy/issues/detail?id=3560
This issue is now blocking issue sympy:3699.
See http://code.google.com/p/sympy/issues/detail?id=3699
--
You received this message because you are listed in the owner
or CC fields of this issue, or because y
Comment #17 on issue 3560 by smi...@gmail.com: solve() is a giant mess
http://code.google.com/p/sympy/issues/detail?id=3560
To get consistent output (until everything is rewritten some day) the
`dict=True` option will give you a list of dictionaries (see issue 3667)
--
You received this mess
Updates:
Blockedon: sympy:3667
Comment #16 on issue 3560 by asmeu...@gmail.com: solve() is a giant mess
http://code.google.com/p/sympy/issues/detail?id=3560
(No comment was entered for this change.)
--
You received this message because this project is configured to send all
issue noti
Comment #15 on issue 3560 by asmeu...@gmail.com: solve() is a giant mess
http://code.google.com/p/sympy/issues/detail?id=3560
Here's the result in the latest git master:
0.7.2-git
[RootOf(x**5 - 5*x + 12, 0), RootOf(x**5 - 5*x + 12, 1), RootOf(x**5 - 5*x
+ 12, 2), RootOf(x**5 - 5*x + 12, 3),
Comment #14 on issue 3560 by alessand...@gmail.com: solve() is a giant mess
http://code.google.com/p/sympy/issues/detail?id=3560
Please observe that in my example just above, the MULTIPLICITY of the roots
is wrong too !
It seems they just fixed this now.
See the
Issue 3610: Solve fails t
Comment #13 on issue 3560 by alessand...@gmail.com: solve() is a giant mess
http://code.google.com/p/sympy/issues/detail?id=3560
Here some (redundant) code picking up (again) some of the mess. The code is
interpreted with Python 3.2.3 and Python 2.7.3. The version of sympy is
given below. Fi
Comment #12 on issue 3560 by nicolas@gmail.com: solve() is a giant mess
http://code.google.com/p/sympy/issues/detail?id=3560
"- In general you can't use attribute access to get at solutions."
Then, something similar to a set of ordered dict (which are much like named
tuples, except for ac
Comment #11 on issue 3560 by asmeu...@gmail.com: solve() is a giant mess
http://code.google.com/p/sympy/issues/detail?id=3560
Ok, we're thinking of different things here. I'm taking about user API and
you're talking about library API. I agree that the internals are a mess.
--
You received th
Comment #10 on issue 3560 by ronan.l...@gmail.com: solve() is a giant mess
http://code.google.com/p/sympy/issues/detail?id=3560
@asmeurer (I didn't see #c8 before):
- We *have* a Set class.
Yes, but we need more Set subclasses
- In general you can't use attribute access to get at solutions.
+1
Comment #9 on issue 3560 by ronan.l...@gmail.com: solve() is a giant mess
http://code.google.com/p/sympy/issues/detail?id=3560
@asmeurer: With a multivariate system of equations, there's no such thing
as "the solution for a specific variable". Also, in general, there is no
way to iterate ove
Comment #8 on issue 3560 by asmeu...@gmail.com: solve() is a giant mess
http://code.google.com/p/sympy/issues/detail?id=3560
Some comments:
- We *have* a Set class. And it already had things like Integers, Interval,
and TransformationSet (allows set builder notation).
- In general you can't
Comment #7 on issue 3560 by nicolas@gmail.com: solve() is a giant mess
http://code.google.com/p/sympy/issues/detail?id=3560
"So I think a Solution class could solve all these problems."
It would be nice to have solve(x+1<0,x) simply return Interval(-oo, -1) for
example.
IMO, there shoul
Comment #6 on issue 3560 by asmeu...@gmail.com: solve() is a giant mess
http://code.google.com/p/sympy/issues/detail?id=3560
So I think a Solution class could solve all these problems. We could allow
solution[x] syntax to get the solution for a specific variable, but still
allow "for sol in
Comment #5 on issue 3560 by nicolas@gmail.com: solve() is a giant mess
http://code.google.com/p/sympy/issues/detail?id=3560
"What's wrong with the dict output?"
Most arguments again dict output are detailed in the discussion linked
above.
Personally, I would sum up my own arguments as
Comment #4 on issue 3560 by asmeu...@gmail.com: solve() is a giant mess
http://code.google.com/p/sympy/issues/detail?id=3560
There have been many discussions about creating a Solve or Solution object,
which would be the output of solve. I think we could make it match both
current interfaces
Comment #3 on issue 3560 by nicolas@gmail.com: solve() is a giant mess
http://code.google.com/p/sympy/issues/detail?id=3560
"and a consistent return type"
Indeed.
I didn't work on sympy for a while, so some questions :
* is there some consensus now about output format ?
* is there a corres
Comment #2 on issue 3560 by asmeu...@gmail.com: solve() is a giant mess
http://code.google.com/p/sympy/issues/detail?id=3560
I'm not sure if that will simplify things much, though I still think we
should do it (or is it really just better eval_inverse support that we
need?). Mul._eval_solve
Comment #1 on issue 3560 by smi...@gmail.com: solve() is a giant mess
http://code.google.com/p/sympy/issues/detail?id=3560
One thing that might be done is to move solving to the object level, so
Add, Mul, etc... would have their own _eval_solve routines.
--
You received this message because
Status: Valid
Owner:
Labels: Type-Defect Priority-High Milestone-Release0.8.0 Solvers
New issue 3560 by ronan.l...@gmail.com: solve() is a giant mess
http://code.google.com/p/sympy/issues/detail?id=3560
Let's just kill it and start over!
The replacement needs to have a simple interface (no
24 matches
Mail list logo
