sorry for the dupe, problem with my drafts
On 19 June 2013 19:14, Stefan Krastanov <krastanov.ste...@gmail.com> 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 <ondrej.cer...@gmail.com> wrote:
>> On Tue, Jun 18, 2013 at 11:23 PM, Thilina Rathnayake
>> <thilina.r...@gmail.com> 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
>>> <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.
>>>
>>>
>>
>> --
>> 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.
