Hello Thilina,
If by object oriented, you mean that the user needs to classify their
equation and then construct an appropriate solver object, my initial
reaction is that this would be less easy to use than the current
interface.
By analogy, a user calls integrate and (usually) doesn't care what magic
ensues, as long as a useful answer comes back. People usually only dig
deeper if the high-level routine fails in some way.
At least currently, classify_diop() looks to be algorithmically
straightforward, and a little bit complicated -- exactly the kind of
task a user would like to delegate to the machine. Do you envision
extending the Diophantine module so that there will be multiple solvers
that might apply to a given equation? In that case, there is more
reason to let the user choose, but even there I would prefer that a good
heuristic be available.
Return of solutions is an interesting and tricky issue, because there is
so much variety. (And admittedly, this is where the more specific
routines have an advantage - having called a specific routine, the
calling code has notice of what to expect back.)
The return interface needs to have the following, I think:
* A way of mapping between the variables of the original equation and
the specific solutions. The solve() function can return a dict or a
pair of lists. The current diop_solve interface returns a tuple or
set of tuples, but after calling diop_solve(2*x + 3*y - 5), I don't
see an easy way to figure out which element of the tuple corresponds
to x and which to y.
* Some way of getting at the parameters in parameterized solutions. As
you point out, the user doesn't necessarily know in advance how many
parameters there will be, so having the user provide the parameters as
arguments to the diop_solve() function call won't work all that well.
The user can drop down to calling atoms() on the resulting expression,
but that seems way too low-level.
I think it would also be very helpful for the solution interface to
provide a convenience function that would provide a way to iterate
through the solutions as regular integers (i.e., with substitutions for
the parameters), in such a way that the small (in absolute value)
solutions are provided first. This would also work well if the
Diophantine module ever presents results as recurrence relations
(following the alpertron approach). If the results are presented as a
recurrence relation, the first thing I would want to do would be to look
at the first few values.
On Wednesday, November 27, 2013 8:37:28 AM UTC-8, Thilina Rathnayake 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.
>
> 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()
>
> 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`.
>
> 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.
>
> Regards,
> Thilina.
>
>
>
>
--
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.
