On Sun, Mar 16, 2014 at 3:20 PM, Harsh Gupta <[email protected]> wrote: > 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)]
How is this implemented? > > > '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. The issue here is with the way the polys handles floating point numbers. Basically, some things do not work if you use floating point numbers but they do if you use rationals. Once the base issue is fixed, the need for this flag will be obviated. > > '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. This is part of the messy linear system API that I alluded to. I'm not clear what to do this this without seeing the full picture of all the linear solvers. > > '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) This one also relates to the linear stuff. It's only valid for particular=True. > > > '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>) I'm not sure if the input_set API is as friendly as it could be. Most users are going to want to just toss in relations with the rest of the equations, especially if they can be expressed using the assumptions or using inequalities, like solve([sin(x) - 1, x > 0]) or solve([x**2 + y**2 - z**2, Q.integer(x), Q.integer(y), Q.integer(z)]) Maybe we should just make the API like this. If you want to represent a complicated set, you can input some kind of Contains object (does this exist yet?). That would also make it clearer what variables correspond to what axes in higher dimensional sets. Aaron Meurer > > > 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. -- 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%3D6J5fvPJJQis49_LYBp0nmaU4Y3dWyLqzr3ofou-h-cymw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
