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.
