On Tue, Dec 17, 2013 at 2:16 AM, Rathmann <[email protected]> wrote:
> 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.
>
I Agree. That would be hard on a user who is not sound in Diophantine
equations.
I was going to provide specialized solver objects + A generic equation
object say,
`DiophantineEqn`. If user knows exactly what is the equation he deals with,
he can
use a specialized object, otherwise he can use the general object.
Specialized object
will provide functionalities specific to that equation. This is specific
details matter
because the solving process of Diophantine equations vary largely according
to the
type.
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?
>
No such plan in my mind.
> 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.)
>
I agree, that is one of the main reasons which made me want to specialize.
> 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.
>
Of course, this is the major issue need to be addressed in the DE module.
FYI, elements in a return tuple is ordered in the same order as the sorted
variables(lexicographically). I used the tuple representation as a
low-level
one on which we should write a convenient interface to the solutions.
> * 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 Agree.
> 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.
>
That's a great idea. But sometimes it will be hard to provide the solutions
which
have the least absolute values first. (In certain cases they may occur
arbitrarily
in the solution sequence). But iterating in the ascending or descending
order of
the parameters is both possible and useful. But the multi-parameter case is
a bit complex.
>
> 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.
>
--
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.
