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) or >>>diop_solve(3*x*y + 5*y -7, param="t") On Wed, Jun 19, 2013 at 10:35 AM, Thilina Rathnayake <thilina.r...@gmail.com > 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 <ondrej.cer...@gmail.com>wrote: > >> Hi Thilina, >> >> On Tue, Jun 18, 2013 at 12:39 PM, Thilina Rathnayake >> <thilina.r...@gmail.com> 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 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. >> 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 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. For more options, visit https://groups.google.com/groups/opt_out.