Here's what I think we should we with the parameters. The list is generated
from the docstring.
'dict'=True (default is False)
return list (perhaps empty) of solution mappings
'set'=True (default is False)
return list of symbols and set of tuple(s) of solution(s)
Not needed, sets as output will take care of it.
'implicit=True (default is False)'
allows solve to return a solution for a pattern in terms of
other functions that contain that pattern; this is only
needed if the pattern is inside of some invertible function
like cos, exp, ....
We won't be able to support such output with our new output API
assert solve(x - exp(x), x, implicit=True) == [exp(x)]
'force=True (default is False)'
make positive all symbols without assumptions regarding sign.
The user can define this in the input_set parameter.
'rational=True (default)'
recast Floats as Rational; if this option is not used, the
system containing floats may fail to solve because of issues
with polys. If rational=None, Floats will be recast as
rationals but the answer will be recast as Floats. If the
flag is False then nothing will be done to the Floats.
I don't know if people use it. If such flag is not popular we will use
it. Anyway sympy solvers are mainly for "exact" symbolic coefficient so
floating point
coefficients doesn't really fit in.
'exclude=[] (default)'
don't try to solve for any of the free symbols in exclude;
if expressions are given, the free symbols in them will
be extracted automatically.
The new API makes is mandatory to enter the variable as an argument so all
symbols
not given in the variables list is excluded.
'particular=True (default is False)'
instructs solve to try to find a particular solution to a linear
system with as many zeros as possible; this is very expensive
I'm not sure about this one.
'check=True (default)'
If False, don't do any testing of solutions. This can be
useful if one wants to include solutions that make any
denominator zero.
'numerical=True (default)'
do a fast numerical check if ``f`` has only one symbol.
'minimal=True (default is False)'
a very fast, minimal testing.
'quick=True (default is False)'
when using particular=True, use a fast heuristic instead to find a
solution with many zeros (instead of using the very slow method
guaranteed to find the largest number of zeros possible)
'warning=True (default is False)'
show a warning if checksol() could not conclude.
'simplify=True (default)'
simplify all but cubic and quartic solutions before
returning them and (if check is not False) use the
general simplify function on the solutions and the
expression obtained when they are substituted into the
function which should be zero
'manual=True (default is False)'
do not use the polys/matrix method to solve a system of
equations, solve them one at a time as you might "manually".
All these parameters trade the speed of the solvers with the accuracy. I
know there have been issue regarding speed, see
https://github.com/sympy/sympy/issues/6611. But I still think we should not
be using these flags for the reason of maintaining simplicity. If a lot of
people report that our solvers are too slow then we might reintroduce a few
of them.
It turns out that we might go about not using any of the current parameters
and have a clean simple input api as
solve(<expression>, <variables>, input_set=<domain of variables>)
On 17 March 2014 01:02, Aaron Meurer <[email protected]> wrote:
> On Sun, Mar 16, 2014 at 2:27 PM, Matthew Rocklin <[email protected]>
> wrote:
> > S.Integers._contains(self, other) just calls ask(Q.integer(other))
>
> It should raise an exception when ask() returns None.
>
> >
> > S.Reals is actually just Interval(-oo, oo). Interval._contains depends
> on
> > the < and > operators. It returns true because the following return true
> > In [9]: x < oo
> > Out[9]: True
> >
> > In [10]: x > -oo
> > Out[10]: True
>
> It would be better to use ask and Q.real. The inequalities let you put
> complex variables in them, because otherwise it would be annoying to
> have to always use x = Symbol('x', real=True). But it leads to
> incorrect results in this case.
>
> By the way, I didn't know that the sets use exclusively the new
> assumptions (assuming that is indeed what you are saying here). Given
> what I've seen in the new assumptions, I'm not so sure this is such a
> hot idea (namely, the handlers have a ton of mathematical
> inaccuracies), but it's nice that they actually are used anywhere
> nonetheless.
>
> Aaron Meurer
>
> >
> >
> >
> > On Sun, Mar 16, 2014 at 11:14 AM, Aaron Meurer <[email protected]>
> wrote:
> >>
> >> On Sun, Mar 16, 2014 at 3:06 AM, Harsh Gupta <[email protected]>
> >> wrote:
> >> >> - Your example
> >> >>
> >> >> In[]: soln = solve(sin(x)*sin(y), (x, y), input_set = Interval(0,
> >> >> 4)*Interval(0, 4))
> >> >>
> >> >> is a bit confusing to me. The input_set argument gives a
> 2-dimensional
> >> >> set, but how are you to know which axis is x and which is y?
> >> >
> >> > The axis is determined by the order of variables in which they appear
> in
> >> > the
> >> > argument of solve. Defining the input set in this way will give us
> >> > special
> >> > advantage of being able to take values from the sets which are
> >> > traditionally
> >> > hard to define. For example if we want the variable to come from a
> >> > circle we
> >> > can do it like.
> >> >
> >> > In[]: solve(f(x, y), (x, y), input_set = imageset((x, y), x**2 + y**2
> <
> >> > 1,
> >> > S.Reals*S.Reals))
> >> >
> >> > For a L shape domain we can do
> >> >
> >> > In[]: solve(f(x, y), (x, y), input_set = Intersection(Interval(0,
> >> > 2)*Interval(0, 3), Interval(1, 2)*Interval(1, 3))
> >> >
> >> > I cannot be sure that sets will be able to seamlessly handle such
> sets,
> >> > but
> >> > I really think this API will scale.
> >> >
> >> >> What about the input API?
> >> >>
> >> >> solve(f, *symbols, dict=False, set=False, exclude=(), check=True,
> >> >> numerical=True, minimal=False, warning=False, simplify=True,
> >> >> force=False, rational=True, manual=False, implicit=False,
> >> >> minimal=False, quick=False)
> >> >
> >> > I think most of the flags are not needed. The flags like `dict` and
> >> > `set`,
> >> > won't be need as we
> >> > are unifying the output to set. Do we have any estimate of how many of
> >> > these
> >> > flags are actually used by users?
> >>
> >> Quite a few people use dict=True, as that's the recommended format to
> >> get a consistent result. As with any public API, we'd have to
> >> deprecate it before removing it.
> >>
> >> What about the other flags? And what about the dozen linear solvers? I
> >> don't expect you to have the right answers now these things this (I'm
> >> not even sure myself what should be done about them), but you should
> >> be thinking about them.
> >>
> >> >
> >> >> - You talk a lot about using sets, which I think is a good idea. But
> >> >> you should think about how you can also use the assumptions. Maybe
> >> >> there is a clean way that we can go back and forth between
> assumptions
> >> >> and sets that requires minimal code duplication, and also allows each
> >> >> to take advantage of the algorithms implemented in the other (by the
> >> >> way, when I say assumptions, you should probably only worry about the
> >> >> new assumptions, i.e., the stuff in the Q object).
> >> >
> >> > As mentioned in the comment by Matthew
> >> > https://github.com/sympy/sympy/pull/2948#issuecomment-36592347
> >> > Assumptions can answer questions like if k is in N, is k*(k+1)/2 in N?
> >> > This
> >> > will
> >> > clearly help in resolving some of the set operations. btw I think
> >> > assumptions
> >> > is wrong in this result.
> >> >
> >> > In [20]: with assuming(Q.integer(k/2)):
> >> > ...: print(k in S.Integers)
> >> > ...:
> >> > False
> >>
> >> The problem is that we always return an answer with __contains__. This
> >> has nothing to do with the assumptions, but rather the sets module.
> >> __contains__ should raise an exception if it can't determine (note
> >> that Python forces "in" to always return a boolean, so we can't return
> >> anything symbolic).
> >>
> >> But beyond that, I don't think the sets use the new assumptions at all
> >> (correct me if I am wrong).
> >>
> >> I also noticed this:
> >>
> >> In [32]: S.Reals.contains(x)
> >> Out[32]: True
> >>
> >> (x is just Symbol('x')).
> >>
> >> >
> >> >> - How will we handle that situation (finding all solutions)? What if
> >> >> we can't say anything? Can we still represent objects in such a way
> >> >> that it is not wrong (basically by somehow saying, "here are 'some'
> of
> >> >> the solutions, but maybe not all of them", and ditto for anything
> that
> >> >> uses solve, like singularities)? Maybe Piecewise is sufficient
> >> >> somehow?
> >> >
> >> > We will return a set as a solution if and only if we have found all
> the
> >> > solutions in the given domain. For every other case we will be using
> the
> >> > unevaluated Solve object. We will have a attribute in the unevaluated
> >> > solve
> >> > named "know_solutions" to say "here are some solutions". Yes Picewise
> >> > might
> >> > be
> >> > helpful, but for now I can't think of a clear way to say "assuming
> this
> >> > parameter 'a' is positive
> >> > the solutions are ..."
> >>
> >> I guess one idea would be to union the set with some "additional
> >> solutions" set, for which not much is known about. So the result, in
> >> the case where we don't know if we have all the solutions, would be
> >>
> >> SolutionSet U NotFoundSolutions
> >>
> >> Then things that use the solutions like discontinuities would
> >> propagate the union (discontinuities should return a Set object too
> >> btw).
> >>
> >> The unknown solutions set may have properties known, even if its exact
> >> cardinality isn't. For instance, the zero set of a continuous function
> >> is always closed.
> >>
> >> >
> >> >
> >> >> Do the radical denesting algorithms
> >> >> work with symbolic entries as well?
> >> >
> >> > I don't think so.
> >>
> >> So in that case, one should try to improve the solvers themselves to
> >> return simpler answers in the first place, if possible.
> >>
> >> >
> >> >
> >> >> - Did you plan to add any new solvers? I think there are still quite
> a
> >> >> few cases that we can't solve. Some higher degree irreducible
> >> >> polynomials for instance (not all higher degree polynomials are
> >> >> solvable by radicals but some are). There will also be a lot to
> >> >> implement once we are able to even represent the solutions to
> >> >> sin(x)=0.
> >> >
> >> > There was one algorithm
> >> > I discussed on the discussion
> >> > https://github.com/sympy/sympy/pull/2948#issuecomment-36970134.
> >> > By that algo we will be able to solve some special cases like
> >> > `sin(x) == x`. I will implement that and we might come up with new
> >> > algorithm
> >> > in the
> >> > process of rewriting current solvers. If time permits I'll surely try
> to
> >> > implement new solvers.
> >>
> >> As I noted before, algorithms that just extend what is already there
> >> should go at the end of the timeline. But algorithms that will provide
> >> motivating examples for the solve API should be implemented sooner, at
> >> least in part.
> >>
> >> (p.s. don't forget to be updating your proposal with ideas from this
> >> discussion)
> >>
> >> Aaron Meurer
> >>
> >> >
> >> >
> >> > --
> >> > You received this message because you are subscribed to the Google
> >> > Groups
> >> > "sympy" group.
> >> > To unsubscribe from this group and stop receiving emails from it, send
> >> > an
> >> > email to [email protected].
> >> > To post to this group, send email to [email protected].
> >> > Visit this group at http://groups.google.com/group/sympy.
> >> > To view this discussion on the web visit
> >> >
> >> >
> https://groups.google.com/d/msgid/sympy/CADN8iuq9aVesJzFFE0wpG9_eJd6C7RW-7Lb%2BRZ3OHA4AXP1yXA%40mail.gmail.com
> .
> >> >
> >> > For more options, visit https://groups.google.com/d/optout.
> >>
> >> --
> >> You received this message because you are subscribed to the Google
> Groups
> >> "sympy" group.
> >> To unsubscribe from this group and stop receiving emails from it, send
> an
> >> email to [email protected].
> >> To post to this group, send email to [email protected].
> >> Visit this group at http://groups.google.com/group/sympy.
> >> To view this discussion on the web visit
> >>
> https://groups.google.com/d/msgid/sympy/CAKgW%3D6JtpThrtt7TVqJ162gNO0qepP_hf%3DKcARRaGdCEST%3Dkww%40mail.gmail.com
> .
> >>
> >> For more options, visit https://groups.google.com/d/optout.
> >
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "sympy" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to [email protected].
> > To post to this group, send email to [email protected].
> > Visit this group at http://groups.google.com/group/sympy.
> > To view this discussion on the web visit
> >
> https://groups.google.com/d/msgid/sympy/CAJ8oX-E9B1uFoqw2_FTRxkJcm7jNk%3DM8NdKkco8bzsx3tYae5A%40mail.gmail.com
> .
> >
> > For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google Groups
> "sympy" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To post to this group, send email to [email protected].
> Visit this group at http://groups.google.com/group/sympy.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/sympy/CAKgW%3D6Kw671B%2B4XKcyV%2BeMLY3gffy%3DGqiAKrqVwjOEswXnRS6A%40mail.gmail.com
> .
> For more options, visit https://groups.google.com/d/optout.
>
--
Harsh
--
You received this message because you are subscribed to the Google Groups
"sympy" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sympy.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sympy/CADN8iurGQmeb5NGD_ZqvB_Y27KQA5h032GmFZRfTGFVEH6n_%3DA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
