Hi Thilina,
On Wed, Nov 27, 2013 at 9:37 AM, Thilina Rathnayake
<[email protected]> wrote:
> Hi All,
>
> I want to change the basic organization of Diophantine equation module so
> that it can be extended and used more conveniently. Since I wish to develop
> the module for CSymPy also, I thought this would be a good time to talk
> about this.
Awesome, looking forward.
>
> Currently, the Diophantine module is invoked through the higher level API
> function `diophantine()`. For example,
>
>>>> from sympy.solvers.diophantine import diophantine
>>>> x, y, z = symbols("x, y, z", Integer=True)
>>>> diophantine(2*x + 3*y - 4*z - 7)
> set([(3⋅t - 4⋅z - 7, -2⋅t + 4⋅z + 7, z)])
>>>> diophantine(3*x**2 - 5*y**2 - 1)
> set([])
>
> I think that it will be better for us to go for an object oriented
> representation of
> Diophantine equations as SAGE does. Then we can simply supply member
> functions that will do required operations. It will also be more reusable
> and
> extensible than now.
>
> I propose a scheme like below.
>
>>>> x, y, z = symbols("x, y, z", Integer=True)
>>>> s = LinearDiophantineEqn(2*x + 3*y - 4*z - 7)
>>>> t = LinearDiophantineEqn([2, 3, -4, -7])
>>>> u = QuadraticDiophntineEqn(2*x**2 - 3*y**2 - 1)
>>>> u.solve()
Maybe you can still provide a thin diophantine() function, that just calls this
object oriented API internally. That way you get it both ways.
>
> We can supply different constructors for a given kind of equation and we can
> derive
> all the equation schemas from a base schema.
>
> Also, For the issue regarding the user specifying parameters, I vote against
> it
> since it can not be justified for the user requiring to know in advance the
> number of
> parameters we will be needing for a solution. We can keep the parameters in
> the
> equation object it self after calling the solve() method and provide other
> methods
> for the user to iterate over them. But one thing we can do is to let user
> specify one
> parameter and build other required parameters from it. i.e, if user input
> `t` to be used
> as a parameter, we use sub-scripted versions of t, ex. `t_{1}, t{2}, ...,
> t_{n}`. Here also
> we need to let user know of the `n`.
Maybe it can optionally accept a use defined generator function that
would return a symbol when you ask for it internally.
> This is just a vague expression on some of the ideas I have and nothing is
> finalized.
> I would like to know what you guys think.
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.
