sorry for the dupe, problem with my drafts On 19 June 2013 19:14, Stefan Krastanov <[email protected]> wrote: > Inputting the parameter as a keyword to the solver seems like a > fragile solutions. What if we need two parameters? What if we do not > need any? How we add appropriate assumptions to the parameter (integer > or whatever)? > > Moreover, this would create two divergent styles for the different > solvers: why should the additional symbols needed to represent > solutions to differential equations (the integration constants) follow > a different api from the Diophantine > > On 19 June 2013 17:13, Ondřej Čertík <[email protected]> wrote: >> On Tue, Jun 18, 2013 at 11:23 PM, Thilina Rathnayake >> <[email protected]> wrote: >>> >>> >>> When we ask the user to specify the parameter to be used, what should >>> be the input? should it be a symbol or a string which contain the symbol >>> to be used. What I am asking is whether we should use, >>> >>>>>>var("t") >>>>>>diop_solve(3*x*y + 5*y -7, param=t) >> >> Yes, it should be a symbol. >> >> Ondrej >> >>> >>> or >>> >>>>>>diop_solve(3*x*y + 5*y -7, param="t") >>> >>> >>> On Wed, Jun 19, 2013 at 10:35 AM, Thilina Rathnayake >>> <[email protected]> wrote: >>>> >>>> Thank you Ondrej for the reply. >>>> >>>> I think that's the way we should go at it. I can implement the >>>> moduels to find the solution and return those naturally as a list. >>>> Later we consider about the high level API's. >>>> >>>> >>>> On Wed, Jun 19, 2013 at 1:28 AM, Ondřej Čertík <[email protected]> >>>> wrote: >>>>> >>>>> Hi Thilina, >>>>> >>>>> On Tue, Jun 18, 2013 at 12:39 PM, Thilina Rathnayake >>>>> <[email protected]> wrote: >>>>> > Hi everyone, >>>>> > >>>>> > Before continuing further with the Diophantine module development (PR >>>>> > #2168) >>>>> > I thought it would be better for me to get other people's views on the >>>>> > representation >>>>> > of solutions returned by diop_solve(). >>>>> >>>>> Thanks for discussing it. >>>>> >>>>> > >>>>> > The main routine of the module is diop_solve(), which takes a >>>>> > Diophantine >>>>> > equation >>>>> > as an argument and returns the solution of the equation. Currently the >>>>> > solution is >>>>> > returned as a dictionary. Ex: >>>>> > >>>>> >> >>>diop_solve(4*x + 6*y - 4) >>>>> >> {x: 6*t - 2, y: -4*t + 2} >>>>> >> >>>diop_solve(3*x - 5*y + 7*z -5) >>>>> >> {x: -25*t - 14*z + 10, y: -15*t - 7*z + 5, z: z} >>>>> > >>>>> > >>>>> > Everything works fine here because the solutions are parametric. >>>>> >>>>> Right. For these equations I think a dictionary is the best solution, >>>>> as it is simple and clear. You should allow the user to specify the >>>>> "t" symbol, e.g. something like: >>>>> >>>>> var("x y z t") >>>>> diop_solve(3*x - 5*y + 7*z -5, param=t) >>>>> >>>>> so that the user can specify other variables names besides "t" as well. >>>>> >>>>> > >>>>> > But when I was trying to solve quadratic Diophantine equation ( this >>>>> > has the >>>>> > form >>>>> > Ax**2 + Bxy + Cy**2 + Dx + Ey + F), they involve solutions which are >>>>> > not >>>>> > parametric. >>>>> > For example, the equation 2*x*y + 5*x + 56*y + 7 = 0 (which is a >>>>> > special >>>>> > case of the >>>>> > quadratic equation) has 8 solution pairs (x, y). (-27, 64), (-29, -69), >>>>> > (-21, 7) and five more. >>>>> > >>>>> > To represent these in a dictionary which has the above form, we have to >>>>> > split the solution >>>>> > pair and put it in to two lists which are keyed under x and y in the >>>>> > dict. >>>>> > if the user want >>>>> > to retrieve a solution pair he would have to find the x value and the y >>>>> > value of the solution >>>>> > separately. Returned value would look like, >>>>> > >>>>> >> {x: [-27, -29, -21, ...], y: [64, -69, 7, ...]} >>>>> > >>>>> > >>>>> > Is this a good way to cope with this situation? I personally feel that >>>>> > it is >>>>> > not natural to >>>>> > split a solution pair and enable the access of it's elements >>>>> > separately. >>>>> > >>>>> > I would like to know what the others have to say on this. >>>>> >>>>> >>>>> So for this I agree with Aaron: >>>>> >>>>> > You may want to look at >>>>> > https://code.google.com/p/sympy/issues/detail?id=3560 and some of the >>>>> > ideas for a unified solve object. >>>>> >>>>> We definitely need a consistent interface to the solve() command. >>>>> >>>>> > Already you have the issue that you >>>>> > are returning a parameter, but there is no easy way to access that >>>>> > parameter (and what happens if t is one of the variables?). >>>>> >>>>> The user can specify his own symbols as "params", as I suggested above. >>>>> >>>>> I would also look how Mathematica does it: >>>>> >>>>> http://reference.wolfram.com/mathematica/guide/DiophantineEquations.html >>>>> >>>>> e.g.: >>>>> >>>>> http://reference.wolfram.com/mathematica/ref/Reduce.html >>>>> >>>>> >>>>> >>>>> In general, I would suggest you simply write the low level modules for >>>>> actually solving the equation. >>>>> Those can return pretty much any representation that you think is the >>>>> best for that particular type of the equation. >>>>> >>>>> Then we need a consistent high level API, and that will take some time >>>>> to get right. But no matter what API we settle on in the end, it >>>>> should be quite simple to call the low level solver and convert the >>>>> result if needed. What do you think Aaron? >>>>> >>>>> Ondrej >>>>> >>>>> -- >>>>> 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. >>>>> >>>>> >>>> >>> >>> -- >>> 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. >>> >>> >> >> -- >> 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. >> >>
-- 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.
