I think that it is far more important to build a sane and extensible framework around solve than to focus on building new solvers. My guess is that this also requires a different skill set.
On Sat, Mar 15, 2014 at 11:54 AM, Aaron Meurer <[email protected]> wrote: > I think it looks good so far. I like how you cleanly organized your > pull requests. That helps a lot. > > My comments: > > - I'm putting this up front because I think it's the most important > point. I feel that you are only addressing half of the issue at > https://github.com/sympy/sympy/issues/6659, namely the output format > of solve. What about the input API? Here is the parameter list for > solve() (I had to construct this manually from the docstring since the > code uses **kwargs): > > 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) > > That's assuming there aren't any undocumented parameters. > > And don't get me started on the mess of linear equation solving > functions. We probably have a dozen functions that solve linear > equations or systems of linear equations (see some of the discussion > at https://github.com/sympy/sympy/pull/2580). > > I like that you're adding new stuff and cleaning up the output API, > but you should think about how to clean up the input API as well. > > - 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? > > - 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). > > - Your section on singularities doesn't really make it clear why we > need the solvers to be improved to do this, namely, that we need to > know exactly when we have all the solutions to not get wrong results. > > - 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? > > - I'm glad to see you are working on improving the simplicity of the > results of solve, such as radical denesting. A potential > simplification routine uses minpoly() on an algebraic expression and > then uses solve to find a simpler solution, but this relies on the > results of solve being simple. Do the radical denesting algorithms > work with symbolic entries as well? > > - 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. > > Aaron Meurer > > On Tue, Mar 11, 2014 at 8:40 AM, Harsh Gupta <[email protected]> > wrote: > > Hi, I have put my the first draft of the proposal on the sympy wiki. > > > > > https://github.com/sympy/sympy/wiki/GSoC-2014-Application-Harsh-Gupta:-Solvers > > > > Please have a look, your suggestions will be valuable. > > > > On 22 February 2014 01:27, Harsh Gupta <[email protected]> wrote: > >> I realize that there is less than a month left for the application > >> deadline and it has already been a month since I posted this thread. > >> So, I need to come up with design details fast. I have written some > >> details about using sets as output for solvers in this PR > >> https://github.com/sympy/sympy/pull/2948/files. PR because I feel it > >> is better platform to facilitate this discussion than the mailing > >> list. Please have a look. > >> > >> On 16 February 2014 07:15, Jigar Mistry <[email protected]> > wrote: > >>> i am also interested in solvers module. how can i contribute to simpy > using > >>> this solvers module.Plz help me.... > >>> > >>> > >>> On Tuesday, 21 January 2014 16:25:13 UTC+5:30, Harsh Gupta wrote: > >>>> > >>>> Hi, I'm Harsh Gupta I will be GSOC applicant this year. I want to > discuss > >>>> the solvers idea given on the Idea's > >>>> page.https://github.com/sympy/sympy/wiki/GSoC-2014-Ideas#solvers > >>>> > >>>> Some of the aspect of the idea are discussed at > >>>> > https://groups.google.com/forum/?fromgroups=#!starred/sympy/8TM8cnuzkG8. > >>>> > >>>> > >>>> Aaron Meurer said: > >>>> > >>>>> I think with TransformationSet we can do quite a bit. That handles > >>>>> sets like {f(x) | x in A}. I think what is missing is the basic set > >>>>> builder {x | P(x)}, where P(x) is a boolean predicate. > >>>> > >>>> > >>>> > >>>> Matthew Rocklin said: > >>>> > >>>>>> > Real issue here - how to represent some solutions (e.g. > sin(x)==0). > >>>>> > >>>>> In sets we would represent this with > >>>>> In [1]: imageset(k, pi*k, S.Integers) > >>>>> Out[1]: {π⋅k | k ∊ ℤ} > >>>> > >>>> > >>>> Implementing a general set builder will be very useful, we will need > to > >>>> define basic set operations like union > >>>> and intersection on them. We might use a syntax like `BuildSet(expr, > >>>> sym_in_inputset, cond)` > >>>> > >>>> In [1]: BuildSet(pi*k, (k, S.Integers), True).intersect(0, 10) > >>>> Out[1]: {pi, 2*pi, 3*pi} > >>>> > >>>> > >>>> Matthew Rocklin said: > >>>> > >>>>> It sounds like maybe solve should return a Set. > >>>> > >>>> > >>>> I think it will be necessary to return set if we want to represent the > >>>> solution of expressions like `floor(x) - 5`. > >>>> See https://code.google.com/p/sympy/issues/detail?id=3975. > >>>> One problem I see with returning sets is that it can break a lot of > >>>> existing code. > >>>> > >>>> > >>>> As mentioned in the idea page we need to have a method to check if > solve > >>>> returns all the solutions. For polynomials or expressions which are > >>>> solved by converting to polynomials we can compare the degree of the > >>>> polynomial to the number of solutions returned. > >>>> > >>>> Other method can be verifying the number of the solutions by using the > >>>> derivative of the function. Say we are given a *continuous* and > >>>> *differentiable* function f(x) and it's derivative w.r.t x is g(x), > >>>> then if g(x) has n solutions then f(x) cannot have more than n + 1 > >>>> solutions. So, if the solve returns n + 1 solutions for f(x) then we > are > >>>> guaranteed that we have found all the solutions. > >>>> For this we will need a discontinuity finder and we will also have to > make > >>>> sure that we have found all the solutions for g(x), i.e., the > derivative of > >>>> f(x), which can be done recursively or by using other methods. > >>>> > >>>> A third way can be using numerical solver. Say we use solve to find > the > >>>> solution of f(x) for some interval [a, b] then we can also run the > numerical > >>>> solver for f(x) on [a, b] > >>>> if the number of solutions by numerical solver and symbolic solve > matches > >>>> then we can be pretty sure that we have found out all the solutions > of f(x) > >>>> in [a, b]. > >>>> > >>>> -- > >>>> 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. > >>> For more options, visit https://groups.google.com/groups/opt_out. > >> > >> > >> > >> -- > >> Harsh > > > > > > > > -- > > 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/CADN8iuohUoie3-eQHG5C_%2BEtKsfs%2BJ%2Bk2P-_DdLMPSBbLtXXDA%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%3D6KJVcvAhtX0iXPN%3DRy9DVrt642KmXLkAxLSxMDpNy5jiA%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-F3Q6psXPJLk3-ZnWJtq9F0z42fo5Dp4epBoX%2BUg9Zt7Q%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
