On Tue, 21 Jul 2009 15:54:11 -0700 William Stein <wst...@gmail.com> wrote:
> > On Tue, Jul 21, 2009 at 3:03 PM, Golam Mortuza > Hossain<gmhoss...@gmail.com> wrote: > > > > Hi, > > > > On Mon, Jul 20, 2009 at 8:31 PM, Robert > > Bradshaw<rober...@math.washington.edu> wrote: > >>> On Sun, Jul 19, 2009 at 3:11 PM, William Stein<wst...@gmail.com> > >>> wrote: > >>>>>> Or should we just restore old "diff" by simply sub-classing it > >>>>>> from SFunction like what is being done for "integration" > >>>>>> and others? > >>>> > >>>> At first glance doing this sounds like a really good idea. How > >>>> hard would it be for you to make a mock-up prototype of this to > >>>> more clearly demonstrate it? I'm definitely not opposed. > >>> > >>> OK, here is a prototype implementation. > >>> > >>> This is based on the principle that we stop applying chain rule > >>> when we hit a symbolic function and whose derivative isn't defined > >>> in sage/pynac. > >> > >> Excellent idea! > > > > Thanks Robert. > > > > Its now up to Sage policy maker to decide whether to continue > > with pynac fderivative. > > Well I'm a policy maker and I vote +1 to you continuing with this > line. As far as I can tell all the people involved with writing pyanc > (me, Mike Hansen, and Burcin), don't use formal derivatives at all for > any of our research/work. We just implemented something because other > people need it and to finish the switch over. Several people on > this list, including Golam, *do* need and use formal derivatives for > their research. So go for it! I still don't see the motivation for switching back to Maxima behavior. Somehow Maple and MMA both work the same way as GiNaC/pynac, and their users don't have difficulty using them. I'm sure if some users complained about how partial derivatives behaved in these commercial systems, the companies would be motivated to provide an alternative, but they don't. > > Inability to substitute the argument of D[] has ensured that > > I am forced out from using new sage symbolics for my own work. As I said above, you could have added a short term workaround for this, once you start using cython to call pynac internals. I believe the effort could be better spent fixing the bugs you listed above. Once you start playing with the internals of pynac, the problems you reported are not hard to fix. Of course, I cannot tell you how to spend your time, but I really don't see enough justification to change the default behavior of pynac/Sage to something other than the current one, which closely models how Maple and MMA does things. So, my vote is -1. 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 -~----------~----~----~----~------~----~------~--~---
