Hi Burcin, On Wed, Jul 8, 2009 at 11:02 AM, Burcin Erocal<bur...@erocal.org> wrote: >> (2) New D derivative operator does not know how to act >> on symbolic integration ( #6465 ). So right now it is not >> possible to compute "S.diff(epsilon)" >> >> I have spent last two days in trying to fix this. I believe >> this is much more serious issue than the previous one >> and this requires changes in both pynac and sage. >> Pynac needs to check for special differentiation rules for >> function like "integrate( f(x,y), x)" before applying chain rules. >> Current "_derivative_" method of SFunction class is inadequate >> for this as it is called after chain rule has been applied. > > > <snip> >> So, I guess (1) and (2) need real work mostly in pynac. I was >> glancing through ginac code. Ginac seems to apply diff() method >> properly to its own integral() method. > > Do you think it's worth wrapping the integral class from pynac instead > of creating a new SFunction called integral?
Not really. See below for my comments. > Maybe we can arrange things so that I make the necessary changes in > pynac, and you work with a new package and write the Sage code on top > of that. > > I started putting alpha pynac packages here > > http://sage.math.washington.edu/home/burcin/pynac/ > > during SD16. E.g., pynac-0.1.9.a1.spkg was meant to be used for > merging the SFunction and PrimitiveFunction classes. > > If you share your code creating an SFunction called 'integral', I can > produce patches for Sage and pynac to special case that function when > computing derivatives. (Much like what is done for Order in the pynac > code right now.) I agree, we need something like Order in pynac. My suggestions are following: Let's have a new method for SFunction class say _diff_derivative_ Pynac should check first whether this method is defined. If not then it can go ahead with chain rule for its arguments. "_diff_derivative_" can be very similar to current "_derivative_" method. Instead of passing "diff_param" keyword it should pass "diff_var" keyword This would be backward compatible. This will solve not only the current issue but it will have wider applications. In future, it would allow Sage users to define their own custom differentiation rule for their symbolic functions. If you implement above in pynac then I can replicate the same in sage. Cheers, Golam --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
