S.Integers._contains(self, other) just calls ask(Q.integer(other)) 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 On Sun, Mar 16, 2014 at 11:14 AM, Aaron Meurer <asmeu...@gmail.com> wrote: > On Sun, Mar 16, 2014 at 3:06 AM, Harsh Gupta <gupta.hars...@gmail.com> > 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 sympy+unsubscr...@googlegroups.com. > > To post to this group, send email to sympy@googlegroups.com. > > 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 sympy+unsubscr...@googlegroups.com. > To post to this group, send email to sympy@googlegroups.com. > 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 sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. 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.
