Feedback on step-by-step thought

[RAJAT AGGARWAL]

Based on suggestions given by Matheww for step-by-step implementation, I tried implementing the step derivation first. Attached file is the output of some basic derivations which show steps. It needs to be arranged yet. Also, the printing may depend upon the certain requirements. Waiting for the feedback.

Thanks

Rajat

[Aaron Meurer]

What is an xcf file? I'm not sure how to read that. 

Aaron Meurer

--
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+un...@googlegroups.com.
To post to this group, send email to sy...@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
For more options, visit https://groups.google.com/groups/opt_out.

<step-derivation.xcf>

[Nitin Agarwal]

xcf file is a GIMP Image file. You can probably use GIMP to open this file.

Nitin Agarwal

[Christophe Bal]

Hello,

Gimp allows to convert this kind of file to a PDF one for example.

This format would be easier to read directly.

Best regards.

[RAJAT AGGARWAL]

Attached is the jpeg file. Sorry for the inconvience.

Rajat

[RAJAT AGGARWAL]

More examples attached. Have a look at it and please provide me the feedback. As i earlier stated that this still requires some more functionalities to be changed so to look better. This is just a prototype kind of thing..

On Sunday, February 16, 2014 3:04:19 AM UTC+5:30, RAJAT AGGARWAL wrote:

[Matthew Rocklin]

Hi Rajat,

How are you doing this?  Can you post the source code somewhere?  If you use github then that is best.

-Matthew

--

[RAJAT AGGARWAL]

Hi Matheww

You can look at the following link. I had just posted some methods of the classes so that you can have the idea of some modifications.

https://github.com/rajat974/StepDerivation

Rajat Aggarwal

On Sunday, February 16, 2014 3:04:19 AM UTC+5:30, RAJAT AGGARWAL wrote:

[Sergey Kirpichev]

It doesn't seems to be a good idea to modify almost every function in the SymPy.

It's Python, it has a great introspection and debugging capabilities!  Please take look to something like trace module from stdlib.

btw, if you are going to modify the SymPy sources - please fork and do your modification on the branch.

https://github.com/sympy/sympy/wiki/Development-workflow

[RAJAT AGGARWAL]

Hi Sergey

What I thought as of now, is to have some expression tree kind of thing which will expand one step and the printed, and this goes on. Using trace will tell us the workflow but will not tell the exact input and output and their position, if we use trace module then we have to manage for every different condition and that condition will change when code changes. So use of trace may become dependent. What are your suggestions?

Rajat 

[RAJAT AGGARWAL]

Proper implementation of step derivations is now there at https://github.com/sympy/sympy/pull/2933 . Please have a look at it and give your feedback.

Rajat Aggarwal

[RAJAT AGGARWAL]

See tests commited in PR https://github.com/sympy/sympy/pull/2933 to see how it works 

Rajat

[RAJAT AGGARWAL]

Hi

I was working on the other parts of the sympy code, to understand the much part of it so that i can have ideas for this project that how we can reduce new step_eval functions to implement step-by-step expressions. I have come up with new ideas and different kind of implementations.

1. In sympy we have different kind of implementations for different kind of functions. In integration we already have the list of the steps. For example: If I evaluate 

integrate(asin(x) *log(x), x), we get the integral_steps

PartsRule(u=log(x), dv=asin(x), v_step=PartsRule(u=asin(x), dv=1,

v_step=ConstantRule(constant=1, context=1, symbol=x), second_step=

URule(u_var=_u, u_func=-x**2 + 1,constant=1/2, substep=

ConstantTimesRule(constant=1/2, other=-1/sqrt(_u), substep

=ConstantTimesRule(constant=-1, other=1/sqrt(_u), substep=

PowerRule(base=_u, exp=-1/2, context=1/sqrt(_u), symbol=_u), 

context=-1/sqrt(_u), symbol=_u), context=-1/sqrt(_u), symbol=x), 

context=x/sqrt(-x**2 + 1), symbol=x), context=asin(x), symbol=x), 

second_step=RewriteRule(rewritten=asin(x) + sqrt(-x**2 + 1)/x, 

substep=AddRule(substeps=[PartsRule(u=asin(x), dv=1, v_step=

ConstantRule(constant=1, context=1, symbol=x), second_step=

URule(u_var=_u, u_func=-x**2 + 1, constant=1/2, substep=

ConstantTimesRule(constant=1/2, other=-1/sqrt(_u), substep

=ConstantTimesRule(constant=-1, other=1/sqrt(_u), substep=

PowerRule(base=_u, exp=-1/2, context=1/sqrt(_u), symbol=_u), 

context=-1/sqrt(_u), symbol=_u), context=-1/sqrt(_u), symbol=x), 

context=x/sqrt(-x**2 + 1), symbol=x), context=asin(x), symbol=x),

 DontKnowRule(context=sqrt(-x**2 + 1)/x, symbol=x)], 

context=asin(x) + sqrt(-x**2 + 1)/x, symbol=x), 

context=(x*asin(x) + sqrt(-x**2 + 1))/x, symbol=x), 

context=log(x)*asin(x), symbol=x)

For such a big parts like integral, we can just parse this output and change this into a tree to get the whole hierarchy and then we can print the steps which are taken to do this integral.

In Integrations, different algorithms have been used, we can use these steps and it can be used to explain the algorithms to the users. Say if a user want to know about risch algorithm , we can use these steps to explain the algorithm by taking one example of any function.

2. For derivations, I had already implemented tree structures for having step by step expressions, as you can see in the commits.

For the optimizations and addition of less functions, we can ````traceback```` for some functions and get the inputs and outputs of the called function and put that in a tree like

def goto_child(self, infunc):

           if len(infunc.args) == 0:

              return infunc

          temp = infunc

          infunc =  list(infunc.args)

          for i in range(len(infunc)):

              if isinstance(infunc[i], Derivative):

                  infunc[i] = diff(infunc[i].expr, infunc[i].args[-1], evaluate=True, step=True)

              else:

                  infunc[i] = self.goto_child(infunc[i])

          at = tuple(infunc)

          return temp.func(*at)

def tracefunc(frame, event, arg, indent=[0]):

      if event == "call":

          if frame.f_code.co_name == "_eval_derivative":

                 # make a parent with 'arg' and the send the child to the next call

      elif event == "return":

                # store the resturn result and then go to next level of tree

      return tracefunc  

This implementation will be same for many functions which have the standard call for doit() or for _eval_derivative(). Same can be done for the basic classes.

According to me, if we use traceback, there is a need of step_derivation function at the end of for some parent classes, because sympy code is very vast and if in future some change happens, then we may have to change this parser for traceback functions . 

Conclusive thought which i have is, We can use traceback to form string of steps for every called functions (similar to shown in integration )  and then we make parser for the main function( like Integrate() ) and since for every function we can get the input argument and output argument, we can make a tree and then we output the results. 

Benefits: Very Less addition of new functions, parser will be able to parse for every function including  both simple and complex. Easy Implementation.

[RAJAT AGGARWAL]

I have submitted the proposal for this project. Please have a review and suggest me the changes to make it better.

Thanks

Rajat Aggarwal

[RAJAT AGGARWAL]

@aaron @mcrolin 

Please review the proposal submitted at melange.

Regards

Rajat Aggarwal

[Aaron Meurer]

This is already done in SymPy Gamma.

> In Integrations, different algorithms have been used, we can use these steps
> and it can be used to explain the algorithms to the users. Say if a user
> want to know about risch algorithm , we can use these steps to explain the
> algorithm by taking one example of any function.

Sure, though this will only be useful if you want to know how the
Risch algorithm works. It will not be useful for understanding the
integration, since the Risch algorithm uses methods that are far
different from the ones you learn in calculus.

No need to use strings and a parser. Just store it in a normal Python
data structure.

Aaron Meurer

>
> --
> 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+un...@googlegroups.com.
> To post to this group, send email to sy...@googlegroups.com.
> Visit this group at http://groups.google.com/group/sympy.

> To view this discussion on the web visit
> https://groups.google.com/d/msgid/sympy/6334e79b-0d97-4bed-92f9-61214bb88217%40googlegroups.com.

[RAJAT AGGARWAL]

Hi Aaron

Step-by-step implementation includes all the modules. It is just an example to proceed with different modules. What I meant was, for Integration parts we can just use this already implemented feature to show the steps.

 

Yeah, I agree that this is different from what we learn in calculus. In steps we can show that the question can be solved using "risch algorith" and then the algorithm .This way we can use this functionality to tell the workflow of the algorithm.

 

Yes, I tried showing the prototype of the "tree" to be used for the storage of the parent function and its child functions and then its inorder traversal in the proposal I submitted.