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.
