[sage-devel] Re: harmonizing derivatives of symbolic expressions and polynomials
On Sunday 24 February 2008, David Harvey wrote: > Okay > > So pretty much everyone seems to like the proposal, and from > discussion on IRC and sage-devel we're going to use derivative() > instead of diff(), which is fine with me. > > I'm going to start coding as soon as I discuss with martin about the > have_ring parameter issues The have_ring stuff should probably be removed all across the singular interface. It was a means to speed up stuff like diff() by not having to set the Singular ring over and over again. However, since we use libSingular (or should be using it) this ad-hoc-ish improvement is no longer needed and should be removed. So: Don't worry about it and I'll provide a patch to remove it everywhere else soon. Martin PS: +1 for the proposal -- name: Martin Albrecht _pgp: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x8EF0DC99 _www: http://www.informatik.uni-bremen.de/~malb _jab: [EMAIL PROTECTED] --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: harmonizing derivatives of symbolic expressions and polynomials
On 24-Feb-08, at 2:39 PM, David Harvey wrote: > > Okay > > So pretty much everyone seems to like the proposal, and from > discussion on IRC and sage-devel we're going to use derivative() > instead of diff(), which is fine with me. Woot! > I'm going to start coding as soon as I discuss with martin about the > have_ring parameter issues Hooray! I will gladly referee this most excellent undertaking. Nick --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: harmonizing derivatives of symbolic expressions and polynomials
Okay So pretty much everyone seems to like the proposal, and from discussion on IRC and sage-devel we're going to use derivative() instead of diff(), which is fine with me. I'm going to start coding as soon as I discuss with martin about the have_ring parameter issues david On Feb 24, 2008, at 2:42 PM, Alex Ghitza wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > I like the proposed plan. > > I also agree with Nick on derivative() vs diff(), but since the plan > says that both will be around, I can probably live with that. > > > Best, > Alex > --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: harmonizing derivatives of symbolic expressions and polynomials
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I like the proposed plan. I also agree with Nick on derivative() vs diff(), but since the plan says that both will be around, I can probably live with that. Best, Alex Nick Alexander wrote: | As the author of the one of the patches, possibly soon to be | obsolete, I like this proposal. | | The one thing I don't like is the name. I prefer nouns, as in | A.derivative(). A.diff() is short for A.differentiate(), which | sounds like an in place procedure to me. | | Standardizing on an abbreviation is madness! My preferred examples | are characteristic polynomials and coefficients of polynomials. If I | want a characteristic polynomial, I look for that, not 'charpoly'. | Also, in many places A.coefficients() or A.coefficient_list() is | abbreviated A.coeffs(). It makes it harder to search. | | If I know what I want (a derivative!) that's what I will look for. | Not a diff. | | Nick | | PS. IIRC, the patch in trac would optimize only the case derivative | (x, 3). | | On 24-Feb-08, at 6:37 AM, David Harvey wrote: | |> After hearing some ideas on IRC regarding the derivatives mess, in |> this email I propose a plan. It's rough around the edges. Comments |> welcome. |> |> |> CURRENT SITUATION |> |> There are currently at least 18 different functions for |> differentiation in Sage, attached to polynomials, power series, |> symbolics, and other things. (See my previous email for a complete |> list.) |> |> There are about 4 "diff", 12 "derivative", one "differentiate", and |> sometimes (but not always) these names are aliases to each other. |> |> I count six different call signatures (all "derivative"s replaced by |> "diff" in the following list): |> |> def diff(self): mainly for univariate polynomial and power series |> types. |> |> def diff(self, verbose=None): only in the sage.functions.elementary |> module. All doctests are switched off on this file. The documentation |> says that this function *integrates* things! The verbose flag seems |> to be something passed to maxima. |> |> def diff(self, *args): only in calculus.calculus.SymbolicExpression. |> This is the most powerful version, and is the closest to what I want |> to eventually support everywhere. |> |> def diff(f, *args, **kwds): only in calculus.functional. This is a |> global, and just dispatches to the diff method on f. |> |> def diff(self, variable, have_ring=False): in the libsingular |> multivariate polynomial code, and also mysteriously crops up in |> polynomial_modn_dense_ntl.pyx. The parameter "have_ring" seems to be |> ignored everywhere, and somewhere claims that it is needed for |> "compatibility reasons". But I can't figure out what this means. |> |> def diff(self, var='x', n=1): only in |> interfaces.maxima.MaximaElement. It means differentiate n times with |> respect to x. Note that the variable is supplied as a *string*. We |> might want to leave this one out of the discussion; I guess here the |> diff function is supposed to conform to maxima semantics (about which |> I know nothing) rather than fit into the sage object model. |> |> There are three open tickets on this issue: |> |> http://trac.sagemath.org/sage_trac/ticket/756 (patch is problematic) |> http://trac.sagemath.org/sage_trac/ticket/753 (not much interesting |> here) |> http://trac.sagemath.org/sage_trac/ticket/1578 (there's a patch here, |> might need to get superseded, sorry Nick) |> |> There are two separate issues here: function naming, and function |> signatures. The former is much simpler, so I'll discuss that first. |> |> |> FUNCTION NAMING |> |> I propose that we deprecate "differentiate". |> |> I propose that we use "diff" as the basic name, and have "derivative" |> as an alias for any object supporting "diff". |> |> I propose that there be a lower-level function "_diff" with a simpler |> signature, see below. |> |> |> FUNCTION SIGNATURES |> |> Here is an approximation to what I would like to see. |> |> Any object F supporting differentiation should have a function |> "_diff" (def or cpdef) taking at least one argument var=None. It can |> have additional arguments, but these must be optional. For example: |> def _diff(self, var=None) |> def _diff(self, var=None, have_ring=False) |> def _diff(self, var=None, verbose=False) |> |> If var is supplied, it should be a variable object (for example, a |> symbolic variable, or a generator of a polynomial ring). It need not |> lie in the parent of F. Examples: |> |> * If F is in S[x] for some ring S, and you call F._diff(x), you get |> what you expect. |> * If F is in S[x] for some ring S, and you call F._diff(y), then |> G._diff(y) gets called for each coefficient of F. |> * If F is in the symbolic ring, then var can be any symbolic variable. |> |> If var is None, the object makes a decision about the default |> variable and uses that. For example: |> |> * a univariate polynomial or power series will differentiate w.r.t. |> the generator. |> * a symbolic exp
[sage-devel] Re: harmonizing derivatives of symbolic expressions and polynomials
On Feb 24, 2008, at 1:49 PM, Fallen Seraph wrote: > The function I was interested in was: > > g(p,q) = 2*q(exp((q+p)^4)+1)+p(2*exp((q+p)^4)-1) It's not clear to me whether the first q is supposed to be multiplied by the following stuff, or whether q is supposed to be a *function* being evaluated at (exp((q+p)^4)+1). > h(p,q) = (2*q*exp((q+p)^4)+2*q)+p(2*exp((q+p)^4)-1) Here you are now multiplying q by exp(...). Do you also want to multiply p by 2*exp(...) in the second term, or is that a function evaluation? P.S. you should move this discussion to a different thread. I don't think it's that closely related to the "harmonizing derivatives..." thread. I am replying on this thread so that you can easily find this reply. david --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: harmonizing derivatives of symbolic expressions and polynomials
The IRC channel suggested I post my related bug report here. Basically, using the "diff" function is giving me different, and equally wrong, answers depending on the sytax I use. The function I was interested in was: g(p,q) = 2*q(exp((q+p)^4)+1)+p(2*exp((q+p)^4)-1) To find the derivative wrt q I tried: diff(g,q) which returned: (p, q) |--> 16*(q + p)^3*e^(q + p)^4 Which looked very wrong, so I rephrased the function as: h(p,q) = (2*q*exp((q+p)^4)+2*q)+p(2*exp((q+p)^4)-1) and diff(h,q) returned (p, q) |--> 8*q*(q + p)^3*e^(q + p)^4 + 8*(q + p)^3*e^(q + p)^4 + 2*e^(q + p)^4 + 2 Which is less wrong, but still too wrong. At this point I headed over to the IRC channel and was ended up here. I assume it is of relevence that I'm using version 2.10.1 32 bit on ubuntu from the appropriate package. I hope this is helpful. --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: harmonizing derivatives of symbolic expressions and polynomials
As the author of the one of the patches, possibly soon to be obsolete, I like this proposal. The one thing I don't like is the name. I prefer nouns, as in A.derivative(). A.diff() is short for A.differentiate(), which sounds like an in place procedure to me. Standardizing on an abbreviation is madness! My preferred examples are characteristic polynomials and coefficients of polynomials. If I want a characteristic polynomial, I look for that, not 'charpoly'. Also, in many places A.coefficients() or A.coefficient_list() is abbreviated A.coeffs(). It makes it harder to search. If I know what I want (a derivative!) that's what I will look for. Not a diff. Nick PS. IIRC, the patch in trac would optimize only the case derivative (x, 3). On 24-Feb-08, at 6:37 AM, David Harvey wrote: > > After hearing some ideas on IRC regarding the derivatives mess, in > this email I propose a plan. It's rough around the edges. Comments > welcome. > > > CURRENT SITUATION > > There are currently at least 18 different functions for > differentiation in Sage, attached to polynomials, power series, > symbolics, and other things. (See my previous email for a complete > list.) > > There are about 4 "diff", 12 "derivative", one "differentiate", and > sometimes (but not always) these names are aliases to each other. > > I count six different call signatures (all "derivative"s replaced by > "diff" in the following list): > > def diff(self): mainly for univariate polynomial and power series > types. > > def diff(self, verbose=None): only in the sage.functions.elementary > module. All doctests are switched off on this file. The documentation > says that this function *integrates* things! The verbose flag seems > to be something passed to maxima. > > def diff(self, *args): only in calculus.calculus.SymbolicExpression. > This is the most powerful version, and is the closest to what I want > to eventually support everywhere. > > def diff(f, *args, **kwds): only in calculus.functional. This is a > global, and just dispatches to the diff method on f. > > def diff(self, variable, have_ring=False): in the libsingular > multivariate polynomial code, and also mysteriously crops up in > polynomial_modn_dense_ntl.pyx. The parameter "have_ring" seems to be > ignored everywhere, and somewhere claims that it is needed for > "compatibility reasons". But I can't figure out what this means. > > def diff(self, var='x', n=1): only in > interfaces.maxima.MaximaElement. It means differentiate n times with > respect to x. Note that the variable is supplied as a *string*. We > might want to leave this one out of the discussion; I guess here the > diff function is supposed to conform to maxima semantics (about which > I know nothing) rather than fit into the sage object model. > > There are three open tickets on this issue: > > http://trac.sagemath.org/sage_trac/ticket/756 (patch is problematic) > http://trac.sagemath.org/sage_trac/ticket/753 (not much interesting > here) > http://trac.sagemath.org/sage_trac/ticket/1578 (there's a patch here, > might need to get superseded, sorry Nick) > > There are two separate issues here: function naming, and function > signatures. The former is much simpler, so I'll discuss that first. > > > FUNCTION NAMING > > I propose that we deprecate "differentiate". > > I propose that we use "diff" as the basic name, and have "derivative" > as an alias for any object supporting "diff". > > I propose that there be a lower-level function "_diff" with a simpler > signature, see below. > > > FUNCTION SIGNATURES > > Here is an approximation to what I would like to see. > > Any object F supporting differentiation should have a function > "_diff" (def or cpdef) taking at least one argument var=None. It can > have additional arguments, but these must be optional. For example: > def _diff(self, var=None) > def _diff(self, var=None, have_ring=False) > def _diff(self, var=None, verbose=False) > > If var is supplied, it should be a variable object (for example, a > symbolic variable, or a generator of a polynomial ring). It need not > lie in the parent of F. Examples: > > * If F is in S[x] for some ring S, and you call F._diff(x), you get > what you expect. > * If F is in S[x] for some ring S, and you call F._diff(y), then > G._diff(y) gets called for each coefficient of F. > * If F is in the symbolic ring, then var can be any symbolic variable. > > If var is None, the object makes a decision about the default > variable and uses that. For example: > > * a univariate polynomial or power series will differentiate w.r.t. > the generator. > * a symbolic expression containing precisely one variable will use > that variable. > * a multivariate polynomial will raise an exception. > * a symbolic expression containing more than one variable will raise > an exception. > > Now we come to the "diff" method. It must have an "*args"-style > argument, which must be interpreted according to the following list > of exa
[sage-devel] Re: harmonizing derivatives of symbolic expressions and polynomials
On Feb 24, 6:37 am, David Harvey <[EMAIL PROTECTED]> wrote: > After hearing some ideas on IRC regarding the derivatives mess, in > this email I propose a plan. It's rough around the edges. Comments > welcome. Your proposal looks excellent. Carl --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: harmonizing derivatives of symbolic expressions and polynomials
On Sun, Feb 24, 2008 at 3:37 PM, David Harvey <[EMAIL PROTECTED]> wrote: > > After hearing some ideas on IRC regarding the derivatives mess, in > this email I propose a plan. It's rough around the edges. Comments > welcome. > > > CURRENT SITUATION > > There are currently at least 18 different functions for > differentiation in Sage, attached to polynomials, power series, > symbolics, and other things. (See my previous email for a complete > list.) > > There are about 4 "diff", 12 "derivative", one "differentiate", and > sometimes (but not always) these names are aliases to each other. > > I count six different call signatures (all "derivative"s replaced by > "diff" in the following list): > > def diff(self): mainly for univariate polynomial and power series types. > > def diff(self, verbose=None): only in the sage.functions.elementary > module. All doctests are switched off on this file. The documentation > says that this function *integrates* things! The verbose flag seems > to be something passed to maxima. > > def diff(self, *args): only in calculus.calculus.SymbolicExpression. > This is the most powerful version, and is the closest to what I want > to eventually support everywhere. > > def diff(f, *args, **kwds): only in calculus.functional. This is a > global, and just dispatches to the diff method on f. > > def diff(self, variable, have_ring=False): in the libsingular > multivariate polynomial code, and also mysteriously crops up in > polynomial_modn_dense_ntl.pyx. The parameter "have_ring" seems to be > ignored everywhere, and somewhere claims that it is needed for > "compatibility reasons". But I can't figure out what this means. > > def diff(self, var='x', n=1): only in > interfaces.maxima.MaximaElement. It means differentiate n times with > respect to x. Note that the variable is supplied as a *string*. We > might want to leave this one out of the discussion; I guess here the > diff function is supposed to conform to maxima semantics (about which > I know nothing) rather than fit into the sage object model. > > There are three open tickets on this issue: > > http://trac.sagemath.org/sage_trac/ticket/756 (patch is problematic) > http://trac.sagemath.org/sage_trac/ticket/753 (not much interesting > here) > http://trac.sagemath.org/sage_trac/ticket/1578 (there's a patch here, > might need to get superseded, sorry Nick) > > There are two separate issues here: function naming, and function > signatures. The former is much simpler, so I'll discuss that first. > > > FUNCTION NAMING > > I propose that we deprecate "differentiate". > > I propose that we use "diff" as the basic name, and have "derivative" > as an alias for any object supporting "diff". > > I propose that there be a lower-level function "_diff" with a simpler > signature, see below. > > > FUNCTION SIGNATURES > > Here is an approximation to what I would like to see. > > Any object F supporting differentiation should have a function > "_diff" (def or cpdef) taking at least one argument var=None. It can > have additional arguments, but these must be optional. For example: > def _diff(self, var=None) > def _diff(self, var=None, have_ring=False) > def _diff(self, var=None, verbose=False) > > If var is supplied, it should be a variable object (for example, a > symbolic variable, or a generator of a polynomial ring). It need not > lie in the parent of F. Examples: > > * If F is in S[x] for some ring S, and you call F._diff(x), you get > what you expect. > * If F is in S[x] for some ring S, and you call F._diff(y), then > G._diff(y) gets called for each coefficient of F. > * If F is in the symbolic ring, then var can be any symbolic variable. > > If var is None, the object makes a decision about the default > variable and uses that. For example: > > * a univariate polynomial or power series will differentiate w.r.t. > the generator. > * a symbolic expression containing precisely one variable will use > that variable. > * a multivariate polynomial will raise an exception. > * a symbolic expression containing more than one variable will raise > an exception. > > Now we come to the "diff" method. It must have an "*args"-style > argument, which must be interpreted according to the following list > of examples (which is almost clear enough to serve as a > specification :-)): > > F.diff(): equivalent to F._diff(None) > F.diff(2): equivalent to F._diff(None)._diff(None) > F.diff(x): equivalent to F._diff(x) > F.diff(x, 3): equivalent to F._diff(x)._diff(x)._diff(x) > F.diff(x, y): equivalent to F._diff(x)._diff(y) > F.diff(x, 3, y, 2, z): equivalent to F._diff(x)._diff(x)._diff > (x)._diff(y)._diff(y)._diff(z) > F.diff(2, x): equivalent to F._diff(None)._diff(None)._diff(x) > [this one currently causes an infinite loop for symbolic objects!] > F.diff([x, y, z]): equivalent to F._diff(x)._diff(y)._diff(z) > F.diff((x, y, z)): equivale
[sage-devel] Re: harmonizing derivatives of symbolic expressions and polynomials
After hearing some ideas on IRC regarding the derivatives mess, in this email I propose a plan. It's rough around the edges. Comments welcome. CURRENT SITUATION There are currently at least 18 different functions for differentiation in Sage, attached to polynomials, power series, symbolics, and other things. (See my previous email for a complete list.) There are about 4 "diff", 12 "derivative", one "differentiate", and sometimes (but not always) these names are aliases to each other. I count six different call signatures (all "derivative"s replaced by "diff" in the following list): def diff(self): mainly for univariate polynomial and power series types. def diff(self, verbose=None): only in the sage.functions.elementary module. All doctests are switched off on this file. The documentation says that this function *integrates* things! The verbose flag seems to be something passed to maxima. def diff(self, *args): only in calculus.calculus.SymbolicExpression. This is the most powerful version, and is the closest to what I want to eventually support everywhere. def diff(f, *args, **kwds): only in calculus.functional. This is a global, and just dispatches to the diff method on f. def diff(self, variable, have_ring=False): in the libsingular multivariate polynomial code, and also mysteriously crops up in polynomial_modn_dense_ntl.pyx. The parameter "have_ring" seems to be ignored everywhere, and somewhere claims that it is needed for "compatibility reasons". But I can't figure out what this means. def diff(self, var='x', n=1): only in interfaces.maxima.MaximaElement. It means differentiate n times with respect to x. Note that the variable is supplied as a *string*. We might want to leave this one out of the discussion; I guess here the diff function is supposed to conform to maxima semantics (about which I know nothing) rather than fit into the sage object model. There are three open tickets on this issue: http://trac.sagemath.org/sage_trac/ticket/756 (patch is problematic) http://trac.sagemath.org/sage_trac/ticket/753 (not much interesting here) http://trac.sagemath.org/sage_trac/ticket/1578 (there's a patch here, might need to get superseded, sorry Nick) There are two separate issues here: function naming, and function signatures. The former is much simpler, so I'll discuss that first. FUNCTION NAMING I propose that we deprecate "differentiate". I propose that we use "diff" as the basic name, and have "derivative" as an alias for any object supporting "diff". I propose that there be a lower-level function "_diff" with a simpler signature, see below. FUNCTION SIGNATURES Here is an approximation to what I would like to see. Any object F supporting differentiation should have a function "_diff" (def or cpdef) taking at least one argument var=None. It can have additional arguments, but these must be optional. For example: def _diff(self, var=None) def _diff(self, var=None, have_ring=False) def _diff(self, var=None, verbose=False) If var is supplied, it should be a variable object (for example, a symbolic variable, or a generator of a polynomial ring). It need not lie in the parent of F. Examples: * If F is in S[x] for some ring S, and you call F._diff(x), you get what you expect. * If F is in S[x] for some ring S, and you call F._diff(y), then G._diff(y) gets called for each coefficient of F. * If F is in the symbolic ring, then var can be any symbolic variable. If var is None, the object makes a decision about the default variable and uses that. For example: * a univariate polynomial or power series will differentiate w.r.t. the generator. * a symbolic expression containing precisely one variable will use that variable. * a multivariate polynomial will raise an exception. * a symbolic expression containing more than one variable will raise an exception. Now we come to the "diff" method. It must have an "*args"-style argument, which must be interpreted according to the following list of examples (which is almost clear enough to serve as a specification :-)): F.diff(): equivalent to F._diff(None) F.diff(2): equivalent to F._diff(None)._diff(None) F.diff(x): equivalent to F._diff(x) F.diff(x, 3): equivalent to F._diff(x)._diff(x)._diff(x) F.diff(x, y): equivalent to F._diff(x)._diff(y) F.diff(x, 3, y, 2, z): equivalent to F._diff(x)._diff(x)._diff (x)._diff(y)._diff(y)._diff(z) F.diff(2, x): equivalent to F._diff(None)._diff(None)._diff(x) [this one currently causes an infinite loop for symbolic objects!] F.diff([x, y, z]): equivalent to F._diff(x)._diff(y)._diff(z) F.diff((x, y, z)): equivalent to F._diff(x)._diff(y)._diff(z) For the list and tuple versions, it must be the only parameter, and repetition counts are not allowed. When I say "equivalent" in the above descriptions, I don't mean it literally has to call _diff that way, I just mean the behav
[sage-devel] Re: harmonizing derivatives of symbolic expressions and polynomials
okay I made a list of all diff() and derivative() and differentiate() functions that we should probably be caring about for this issue. The list does not include aliases. functions/elementary.py class ElementaryFunction_class(CommutativeRingElement): def differentiate(self,verbose=None): interfaces/maxima.py class MaximaElement(ExpectElement): def diff(self, var='x', n=1): calculus/calculus.py class SymbolicExpression(RingElement): def derivative(self, *args): class Symbolic_object(SymbolicExpression): #def derivative(self, *args): calculus/functional.py def derivative(f, *args, **kwds): functions/piecewise.py class PiecewisePolynomial: def derivative(self): rings/polynomial/polynomial_modn_dense_ntl.pyx cdef class Polynomial_dense_mod_n(Polynomial): def diff(self, variable, have_ring=False): rings/polynomial/multi_polynomial_libsingular.pyx cdef class MPolynomial_libsingular (sage.rings.polynomial.multi_polynomial.MPolynomial): def diff(self, MPolynomial_libsingular variable, have_ring=True): rings/polynomial/polynomial_singular_interface.py class Polynomial_singular_repr: def diff(self, variable, have_ring=False): misc/functional.py def derivative(x): rings/laurent_series_ring_element.pyx cdef class LaurentSeries(AlgebraElement): def derivative(self): rings/polynomial/polynomial_element.pyx cdef class Polynomial(CommutativeAlgebraElement): def derivative(self): rings/polynomial/polynomial_element_generic.py class Polynomial_generic_sparse(Polynomial): def derivative(self): rings/polynomial/polynomial_modn_dense_ntl.pyx cdef class Polynomial_dense_mod_n(Polynomial): def derivative(self): cdef class Polynomial_dense_modn_ntl_zz(Polynomial_dense_mod_n): def derivative(self): rings/power_series_poly.pyx cdef class PowerSeries_poly(PowerSeries): def derivative(self): rings/power_series_ring_element.pyx cdef class PowerSeries(AlgebraElement): def derivative(self): rings/sparse_poly.pyx cdef class Polynomial: def derivative(self): There's also stuff in the following files which we probably shouldn't worry about: libs/ntl/ntl_GF2X.pyx libs/ntl/ntl_lzz_pX.pyx libs/ntl/ntl_ZZ_pEX.pyx libs/ntl/ntl_ZZ_pX.pyx libs/ntl/ntl_ZZX.pyx schemes/elliptic_curves/monsky_washnitzer.py lfunctions/dokchitser.py david --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: harmonizing derivatives of symbolic expressions and polynomials
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I was going to point to trac tickets and comments by David Harvey, but he beat me to the punch :) Since I agree with what he already said, I'll just address one point: Carl Witty wrote: | 1) Do we really need three names for this concept? Could we get rid | of one or two? If so, can we just remove it, or do we need some sort | of deprecation procedure? I vote in favor of keeping only one method name. I prefer derivative() over the other two, but I won't be too devastated if it's not the one picked. Best, Alex - -- Alexandru Ghitza Assistant Professor Department of Mathematics Colby College Waterville, ME 04901 http://bayes.colby.edu/~ghitza/ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHwGLgdZTaNFFPILgRAjPgAKCA2It/swAG6+D38z1sqEGNlDfyRwCgm0MD M/9BnqqJswvpKMiTWVCedP8= =Chq+ -END PGP SIGNATURE- --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: harmonizing derivatives of symbolic expressions and polynomials
On Feb 23, 2008, at 1:03 PM, Carl Witty wrote: > Currently, symbolic expressions have 3 identical "derivative" > methods: .derivative(), .diff(), and .differentiate() (that is, they > are aliases of each other). These have a powerful argument list; > foo.diff(x, 3, y, z, 2) differentiates three times with respect to x, > then once with respect to y, then twice with respect to z. (And if > foo contains only one variable, then foo.diff() differentiates with > respect to that variable.) > > Polynomials (both univariate and multivariate) have a .diff() method, > which takes a required variable argument; univariate polynomials also > have a .derivative() method, which does not take an argument. > > There are also global functions diff(), differentiate(), and > derivative(), which are basically wrappers for the .derivative() > method: diff(foo, ...) is equivalient to foo.derivative(...). > > 1) Do we really need three names for this concept? Could we get rid > of one or two? If so, can we just remove it, or do we need some sort > of deprecation procedure? > > 2) I plan to make the polynomial methods match the symbolic expression > methods. (This should be backward-compatible.) Any objections? Carl, I'm glad you've brought this up now, I was planning to take this on myself in the next few days. I strongly agree everything should be harmonised. Here are several related tickets: http://trac.sagemath.org/sage_trac/ticket/756 http://trac.sagemath.org/sage_trac/ticket/753 http://trac.sagemath.org/sage_trac/ticket/1578 david --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
