Ondrej: That's exactly what I am doing right now.
I am just implementing the low level functionalities which just solves
the equation and for the time being I am returning solutions as a set of
tuples.
I think the only assumption on the parameters would be that they
are Integers. Sometimes they may require to be positive or negative
but still I haven't come across that kind of a situation.
On the other hand, Stefan has a point in saying that we can't expect
user to be aware of the number of parameters to be used in the solution.
User may be unaware of how many parameters linear diophantine
equations or perhaps more unheard Pell's equation needs in the solution.
Can't we use the method or a slightly modified version of what Chris
proposed?
We use a set of fixed parameters internally, If we find them to be in the
equation
we add a '_' before that and use that as a parameter? Only problem here is
that
user can't know of the assumptions on the parameter. Besides being integers
I
didn't found any special assumption on them still.
Thilina.
On Wed, Jun 19, 2013 at 10:10 PM, Ondřej Čertík <ondrej.cer...@gmail.com>wrote:
> On Wed, Jun 19, 2013 at 9:39 AM, Stefan Krastanov
> <krastanov.ste...@gmail.com> wrote:
> > Inputting the parameter as a keyword to the solver seems like an
> > extremely fragile solutions. What if we need two parameters? What if
> > we do not need any?
>
> I think for linear equations it is clear from the equation how many
> parameters you need.
>
> > How we add appropriate assumptions to the
> > parameter (integer or whatever)?
>
> I am not sure what you mean here.
>
> >
> > 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 equations solver.
>
> We should follow the same API everywhere. Do you have some suggestions
> what the "correct" API should be?
>
> Thilina, so until this gets settled, just implement the low level API,
> and simply try to make all arguments explicit for each solver. Then it
> will be quite easy to hook this up with our high level solve()
> function.
>
> Ondrej
>
>
> >
> > 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.
> >
> >
>
> --
> 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.
