On Wed, 8 Jul 2009 00:18:38 -0300 Golam Mortuza Hossain <gmhoss...@gmail.com> wrote:
> > Hi, > > On Tue, Jul 7, 2009 at 10:29 PM, William Stein<wst...@gmail.com> > wrote: > >> In new symbolics, if I do the same I get > >> -------- > >> sage: g > >> D[0](f)(x) > >> sage: g.subs_expr(f(x)==f(x)+df(x)) > >> D[0](f)(x) > >> --------- > >> > >> Is there a way to do this in new symbolics? It seems > >> to be a road block in implementing calculus of variations > >> in new symbolics. > > > > I don't see any way to do this yet, which is frustrating. This was > > as close as I got, which is really awful: > > > > sage: g.operator().change_function(f(x)+df(x))(x) > > D[0](f)(x) + D[0](df)(x) > > I got another workaround > ----- > for n in range(max): > S = S.subs_expr(f(x).diff(x,n)==(f(x)+df(x)).diff(x,n)) > ----- > It gets my work done as I know 'max' for my problems. > However, I think we need a proper solution not a workaround. > > > I really hope once we get these issues sorted out and you implement > > calculus of variations, that you include it in Sage. > > Definitely! Right now, I see four issues that need to be sorted > out before calculus of variations can be implemented in Sage. > > (1) Improved .subs_expr() method so that one can vary a > functional of the form > S0 = L( q(t), q(t).diff(t) ).integral(t, -oo, oo) > to > S = L( q(t) + dq(t), (q(t)+dq(t)).diff(t) ).integral(t, -oo, oo) > > where dq(t) = epsilon*f(t), f(t) a test function. This requires messing around with the pattern matching functionality of ginac, which I am not really familiar with right now. I'm afraid it will have to wait till I have more time available if no one else takes this up. > (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? 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.) Thanks. Burcin --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
