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.
