On Sat, Mar 31, 2012 at 11:37 PM, Alexey U. Gudchenko <pr...@goodok.ru>wrote:

>
> On 31.03.2012 14:02, Ashwini Oruganti wrote:
> > Hi,
> >
> > My proposal can be found on the SymPy wiki at :
> >
> >
> https://github.com/sympy/sympy/wiki/GSoC-2012-Application-Ashwini-Oruganti:-Step-by-Step-Expression-Manipulation
> >
> > Can you please review the same and provide feedback?
> >
> >
> > Thanks and Regards,
> >
> > Ashwini Oruganti
> >
>
> 1. As I understand,  there are two main parts of your application:
>
>   a) informational: to inform what SymPy do by steps,
>   b) control: manage with those steps.

(exclusive of interface design)
>
> I think that those tasks must be clearly separated by the aims
> (nevertheless they are have the same base, an one of them use the other).
>

I realize that you and I are saying almost the same things, but under
different subheadings. I tried to divide my design into the UI part and the
main algorithm designing part to generate steps, as I think it's easier to
explain the design using this.



>
> 2. We must think how it can be embedded into SymPy, and easy maintain
> synchronization with changed code.
>

As I'm new to SymPy, I plan on doing this over along the way as I code. In
my proposed schedule, I've allotted some time for such design discussions.
I'm afraid my current knowledge about SymPy isn't enough to exactly answer
this question. I would be happy to include any inputs you might have
regarding the same.


>
> As I understand you are going to create the set of rules (Data
> Structure) as the central part.
>
> If the algorythm of the solve function (integrate|simplify|...) is
> updated we must to make adjustments to the rules too.
>
> The typical function:
>
>    solve(expr):
>        try to solve by method1
>             try simplify
>             try sub_method_1
>        if ok:
>           return
>        if failed:
>           try to solve by method2
>
> What is the DataSet for this example?
>

IMO the data-set will be different for different operations (e.g. For
differentiation, it will be product-rule, first degree derivative, quotient
rule, etc).



>
> I think, Most likely it will follow much of the code.
>
> May be to think how will the "rules" be created automatically? E.g. with
> the help of  statements embeded in the code like e.g.
> 'steps.push('info')" "cancel_transaction" functions?
>
> For the task (a) it can help to maintain the actuality of steps with
> respect to the present code. And even if the one of steps description
> will be missed the code (of step-by-step manipulation module) doesn't
> crash.
>

Yes, for this purpose I plan to include smart defaults in my algorithm.
Exactly "how", you might ask, but I'm working on it.  I might be a little
slow here, but I'm trying to figure ways out. That's the reason why my
timeline has a lot of time for designing and discussions with mentor.



> For the task(b) this way must be changed somehow, but the task (b) can
> use the information collected in task (a).
>


Indeed, that's what I've tried to put forth in my proposal. I guess I'll
add a flowchart of the design so as to make it more clear.


> --
> Alexey Gudchenko
>
> --
> You received this message because you are subscribed to the Google Groups
> "sympy" group.
> To post to this group, send email to sympy@googlegroups.com.
> To unsubscribe from this group, send email to
> sympy+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/sympy?hl=en.
>

-- 
You received this message because you are subscribed to the Google Groups 
"sympy" group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, send email to 
sympy+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/sympy?hl=en.

Reply via email to