Hi, On Mon, Mar 19, 2012 at 7:36 AM, Aaron Meurer <asmeu...@gmail.com> wrote:
> Hi. > > On Sun, Mar 18, 2012 at 9:23 AM, Ashwini Oruganti > <ashwini.oruga...@gmail.com> wrote: > > Hi, > > > > I am a sophomore undergraduate Computer Science and Engineering student. > > I've done a substantial amount of Mathematics in high school, and so far > in > > my university (Differential Calculus, Integral Calculus, Linear Algebra, > > Probability Theory) and am pretty comfortable learning new concepts. My > Open > > Source contribution so far has been a few patches in Evolution[1] [2] [3] > > and a few bugs (yakuake [4] , Sugarlabs [5]). > > > > I would like to work on SymPy this summer and take it up as my GSoC > project. > > I went through the ideas page and was thinking over the implementation of > > Step-by-step Expression Manipulation, and I felt it could be implemented > the > > way we do dry runs manually, e.g. for higher order derivatives, display > the > > result of fdiff() (i.e. 1st order derivative) at each step. This would > also > > help avoid code-duplication in cases where SymPy works in the way we > would > > too by hand. "show_steps" could be implemented as a separate function > where, > > when called by the user, it could be made it operation-specific. > > > > And as to what the output should look like, the readability part is easy, > > what's tricky is the usability part. We could store each step in an > object > > (auto-name each step as step1. step2, etc) that when called, can print > the > > operations occurring in that step and then the user could use it > as he/she > > finds fit. > > Ideally, the way we store this information and the way we print it > should be completely separate code (the way we print it could just be > implemented as part of the printing system). Yes, ideally that should be the case. We could use a method that takes in this information and prints it for us. > As you said, the more > important part is to have it in a usable form. Here are a few things > to think about: > > - We may want to do different degrees of steps. If I compute > diff(x*sin(x), x, x), I may want this as two first order derivatives > as you said, or I may want to break it up further and show the product > rule and rules for the derivative of x and sin(x) shown. > - Different steps may apply. For example, if you have something that > does integrals, you could compute Integral(sin(x)*exp(x), x) using > integration by parts in two different ways. Clearly the user should > be able to pick u and dv to be whatever he wants (even if it doesn't > work), but there should be smart defaults as well. > Well, for that, we could use a flag to store which function is being used to compute the answer ( in this case, e.g: two first order derivatives or a product rule) and use this flag to determine how show_steps() (I'm temporarily naming the function as show_steps() for the sake of discussion) proceeds to generate the step-wise solution. Also, note that if we don't be careful, many ambiguities might occur here, (e.g. taking ( f(x)/ g(x) ) as ( (f(x) . (1/g(x)) ) in case of differentiation, and hence whether to use product rule or quotient rule), when the final answer will be the same but the procedure might differ. To resolve this, we could ask the user which solution he would want to see. Or, we could just keep a smart default, as you mentioned below. > > - You should be able to apply steps to an expression. This was > discussed in another thread on this mailing list about this topic. > I'll look for the thread and see how I can implement this. > > - Printing is important. You need to have a good way to visualize > what is going on, or it will be useless. > Yes, I'm working on it. The problem is generalization. Same answer can be arrived at using different solutions, hence the different implementation of the print method. I think I could start with basic algebraic computations and then keep adding to it more operations, that way we could break up the issue into parts and tackle them one-by-one. Suggestions regarding which functions to implement first are welcome. > Aaron Meurer > > > > Please do let me know your take on this, and if its feasible to > implement. > > > > I also had a few ideas about the implementation of sparse matrix > > representation for Matrix, in the linear algebra module. I think we can > use > > a combination of both Dense & Sparse storage. We can create a list of > > indices that holds the zero elements and modify other Matrix operations > to > > first see if the element is in this list, if so, then treat it as a zero, > > else continue as before ( and refer to the Dense storage value); probably > > implement this as a test_sparse() function and add it to the existing > matrix > > operations. > > It's mentioned in the wiki that this project was partially worked upon > by a > > previous GSoC student. Given a reference, I could probably complete it > > further. > > The unmerged work from that project is here: > https://github.com/sympy/sympy/pulls/sherjilozair > > > > > I would love to get more inputs on the above ideas, and discuss the same. > > > > Regards, > > Ashwini Oruganti > > > > [1] https://bugzilla.gnome.org/show_bug.cgi?id=593449 > > [2] https://bugzilla.gnome.org/show_bug.cgi?id=593444 > > [3] https://bugzilla.gnome.org/show_bug.cgi?id=593450 > > [4] https://bugs.kde.org/show_bug.cgi?id=294051 > > [5] http://bugs.sugarlabs.org/ticket/3362 > > > > -- > > 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. > > Regards, Ashwini Oruganti -- 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.
