You can subscribe to this list here.
2009 
_{Jan}
(2) 
_{Feb}
(5) 
_{Mar}

_{Apr}

_{May}
(2) 
_{Jun}
(8) 
_{Jul}
(4) 
_{Aug}

_{Sep}

_{Oct}
(2) 
_{Nov}
(6) 
_{Dec}


2010 
_{Jan}
(1) 
_{Feb}
(1) 
_{Mar}
(3) 
_{Apr}
(2) 
_{May}
(2) 
_{Jun}
(2) 
_{Jul}
(18) 
_{Aug}
(13) 
_{Sep}
(7) 
_{Oct}

_{Nov}

_{Dec}
(2) 
2011 
_{Jan}

_{Feb}
(11) 
_{Mar}

_{Apr}
(4) 
_{May}

_{Jun}
(1) 
_{Jul}
(18) 
_{Aug}
(16) 
_{Sep}
(12) 
_{Oct}
(12) 
_{Nov}
(19) 
_{Dec}
(42) 
2012 
_{Jan}
(16) 
_{Feb}
(3) 
_{Mar}
(8) 
_{Apr}
(14) 
_{May}
(30) 
_{Jun}
(5) 
_{Jul}
(7) 
_{Aug}
(3) 
_{Sep}
(10) 
_{Oct}
(4) 
_{Nov}
(10) 
_{Dec}
(1) 
2013 
_{Jan}
(14) 
_{Feb}
(8) 
_{Mar}
(5) 
_{Apr}
(3) 
_{May}
(9) 
_{Jun}
(19) 
_{Jul}

_{Aug}
(27) 
_{Sep}
(5) 
_{Oct}
(18) 
_{Nov}
(12) 
_{Dec}
(8) 
2014 
_{Jan}
(5) 
_{Feb}
(8) 
_{Mar}
(20) 
_{Apr}
(22) 
_{May}
(28) 
_{Jun}
(9) 
_{Jul}
(6) 
_{Aug}
(46) 
_{Sep}
(40) 
_{Oct}
(15) 
_{Nov}
(8) 
_{Dec}
(34) 
2015 
_{Jan}
(20) 
_{Feb}
(15) 
_{Mar}
(18) 
_{Apr}
(20) 
_{May}
(3) 
_{Jun}
(13) 
_{Jul}
(10) 
_{Aug}
(19) 
_{Sep}
(8) 
_{Oct}
(31) 
_{Nov}
(26) 
_{Dec}
(13) 
2016 
_{Jan}
(13) 
_{Feb}
(4) 
_{Mar}
(14) 
_{Apr}
(28) 
_{May}
(19) 
_{Jun}
(7) 
_{Jul}
(1) 
_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 





1
(1) 
2
(1) 
3

4

5
(1) 
6
(2) 
7
(1) 
8
(2) 
9
(3) 
10

11

12
(1) 
13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30


From: Rainer Schöpf <rainer.schoepf@gm...>  20110912 17:07:35

While testing some new code for the main tree, I came upon an odesolve example that no longer works, (ex. 7 from zimmer.tst): In PSL, the whole system crashes with a SIGSEGV. Even after fixing the particular bug causing the crash, the example takes a very long time until memory is exhausted. The reason behind this behaviour is the attempt to try substitutions before running the integrator proper. A simple example of this problem is int(e^(1/x)*sqrt(x2),x); 1/x 5 1/x 3 1/x 2 (2*(105*e *sqrt(x  2)*x + 420*e *sqrt(x  2)*x + 280*e *sqrt(x  2)*x 1/x 1/x + 672*e *sqrt(x  2)*x + 160*e *sqrt(x  2) 1/x 1/x e 4 e 4  320*int(,x)*x  2464*int(,x)*x 6 5 sqrt(x  2)*x sqrt(x  2)*x 1/x e 4 4  3360*int(,x)*x ))/(315*x ) 4 sqrt(x  2)*x Or try this: on combinelogs; int(e^(1/x)*sqrt(x2),x); This result is silly; replacing the original integral by as um of more complicated ones. Running with "on trint;" shows that the substitution code tries all kind of substitutions to simplify the integral, but never comes back to the original integrand when the substitution doesn't give a better result. I'm well aware of the fact that "a better result" is a vague concept and unlikely to be accessible algorithmically. However, the current code can easily iterate until resources are exhausted; try this for a example: on combinelogs; int(e^(1/x)*sqrt(x2)/sqrt(x),x); or int(e^(1/x^3)*sqrt(x2)/sqrt(x),x); I propose to check that a substitution doesn't introduce a new transcendental kernel. Take the last two integrals: In both cases, the substitutions applied are 1. x = y^2+2 2. y = sqrt(2)*sinh(z) which lead to new kernels exp(1/(2*cosh(z)^2)) and exp(1/(8*cosh(z)^6)), respectively. The occurence of these should prevent the substituted integral to be tried. Comments are welcome. Rainer 
From: Klaus Rohe <klausrohe@t...>  20110909 20:10:17

Klaus Rohe AdolfKolpingStr. 10a, 85625 Glonn, Germany Tel.: +49 (0) 08093 5402 Email: <mailto:klausrohe@...> klausrohe@... 
From: Rainer Schöpf <rainer.schoepf@gm...>  20110909 18:48:55

On Fri, 9 Sep 2011 at 17:21 +0100, Francis Wright wrote: > > Some more border cases in differentiation: > > > > 1. This one has nothing to do with expanddf and the recent changes: > > > > depend cos(y),x; > > > > df(cos(y),x) => 0 > > > > because df(cos(y),x) simplifies to > > > > sin(y) * df(y,x) > > > > and y doesn't depend on x. > > > > This looks wrong to me. > > Yes. But the only way that cos(y) can depend on x is if y depends on x, so I > think REDUCE should either regard "depend cos(y),x; " as an error or interpret > it to mean "depend y,x; ". But you can't do this for all functions, because an > arbitrary function f(y) could reasonably have some implicit dependence on other > variables. Off hand, the only way I can see to distinguish the cases would be to > flag known operators in some way. Two ideas: 1. regard "depend cos(y),x;" as an error because there is a diffentiation rule for cos 2. do not apply the diff. rule for cos(y) if there is an implicit (declared) dependency on x. > > 2. With expand set to on: > > > > depend r,x; > > df(f(r,cos(x)),x); > > > > gives > > > > df(f(r,cos(x)),r)*df(r,x) + df(f(r,cos(x)),cos(x))*df(cos(x),x) > > > > > > I believe it is correct, but possibly not what one expects. > > Yes. I would suggest leaving this and waiting for users to complain if it's not > what they expect. (I presume that df(cos(x),x) actually simplifies.) Yes, will do that. I guess there will still be a few pathological cases where the result is not what one would expect. I've put some tests into regression test files: packages/regressions/sep052011expanddf.tst packages/regressions/sep052011expanddf.rlg > > BTW, I think there is an error in the procedure diffp, both in the original > one and > > the one in odesolve/odepatch.red: The else clause > > > > else if eqcar(cadr u, 'int) then > > > > is not an alternative to the then clause > > > > if cadr u eq v then > > > > (as the indentation suggests), but part of that then clause, ie there is a > > > > << > > ... > > >> > > > > missing. > > As far as odesolve/odepatch.red is concerned, I clearly missed this problem, > partly because I try not to reformat existing code that I'm modifying. So can > you change odesolve/odepatch.red as well, please, if you change the main code? Will do. However, with there being three redefinitions of diffp (in changevr, odesolve and crack) it might be better to merge all these into the main code, with some global variables or switches to activate the necessary bits. What do you think? Rainer 
From: Francis Wright <f.wright@qm...>  20110909 16:21:12

> From: Rainer Schöpf [mailto:rainer.schoepf@...] > Sent: Thursday, September 08, 2011 9:21 PM > To: Francis Wright > Cc: reducealgebradevelopers@... > Subject: RE: [Reducealgebradevelopers] An inconsistency in computing > derivatives? > > Some more border cases in differentiation: > > 1. This one has nothing to do with expanddf and the recent changes: > > depend cos(y),x; > > df(cos(y),x) => 0 > > because df(cos(y),x) simplifies to > > sin(y) * df(y,x) > > and y doesn't depend on x. > > This looks wrong to me. Yes. But the only way that cos(y) can depend on x is if y depends on x, so I think REDUCE should either regard "depend cos(y),x; " as an error or interpret it to mean "depend y,x; ". But you can't do this for all functions, because an arbitrary function f(y) could reasonably have some implicit dependence on other variables. Off hand, the only way I can see to distinguish the cases would be to flag known operators in some way. > 2. With expand set to on: > > depend r,x; > df(f(r,cos(x)),x); > > gives > > df(f(r,cos(x)),r)*df(r,x) + df(f(r,cos(x)),cos(x))*df(cos(x),x) > > > I believe it is correct, but possibly not what one expects. Yes. I would suggest leaving this and waiting for users to complain if it's not what they expect. (I presume that df(cos(x),x) actually simplifies.) > BTW, I think there is an error in the procedure diffp, both in the original one and > the one in odesolve/odepatch.red: The else clause > > else if eqcar(cadr u, 'int) then > > is not an alternative to the then clause > > if cadr u eq v then > > (as the indentation suggests), but part of that then clause, ie there is a > > << > ... > >> > > missing. As far as odesolve/odepatch.red is concerned, I clearly missed this problem, partly because I try not to reformat existing code that I'm modifying. So can you change odesolve/odepatch.red as well, please, if you change the main code? Thanks, Francis 
From: Rainer Schöpf <rainer.schoepf@gm...>  20110908 20:20:58

Some more border cases in differentiation: 1. This one has nothing to do with expanddf and the recent changes: depend cos(y),x; df(cos(y),x) => 0 because df(cos(y),x) simplifies to sin(y) * df(y,x) and y doesn't depend on x. This looks wrong to me. 2. With expand set to on: depend r,x; df(f(r,cos(x)),x); gives df(f(r,cos(x)),r)*df(r,x) + df(f(r,cos(x)),cos(x))*df(cos(x),x) I believe it is correct, but possibly not what one expects. BTW, I think there is an error in the procedure diffp, both in the original one and the one in odesolve/odepatch.red: The else clause else if eqcar(cadr u, 'int) then is not an alternative to the then clause if cadr u eq v then (as the indentation suggests), but part of that then clause, ie there is a << ... >> missing. Rainer 
From: Francis Wright <f.wright@qm...>  20110908 08:56:54

In the short term I would suggest not applying the chain rule if there are inconsistent dependences. In the longer term I think the depend command should be revised to treat an inconsistent dependence as an error. Francis > Original Message > From: Rainer Schöpf [mailto:rainer.schoepf@...] > Sent: Wednesday, September 07, 2011 4:34 PM > To: Francis Wright > Cc: reducealgebradevelopers@... > Subject: RE: [Reducealgebradevelopers] An inconsistency in computing > derivatives? > > I believe I've now managed to treat this and other cases correctly. > > However, I'm not entirely sure how to treat inconsistent input. For example, > assume the following depend statements > > depend f(u),a,b,c; > > depend u,a,b; > > depend {a,b,c},v; > > Obviously, these dependencies are inconsistent. > > With the switch expanddf set to on, how should df(f(u),v) be simplified? > > Using the chain rule with the first and the third dependencies, the result is > > (*) df(f(u),a)*df(a,v) + df(f(u),b)*df(b,v) + df(f(u),c)*df(c,v) > > but using the second and third dependencies, we get > > (**) df(f(u),u)*(df(a,v)*df(u,a) + df(b,v)*df(u,b)) > > One could argue that (*) is the better result since there is a direct dependency of > f(u) on a,b,c. > > So, what should happen in this case? An error, or a warning message? If no error, > then what should be returned? > (1) Result (*) > (2) Result (**) > (3) do not apply chain rule, return df(f(u),v) instead > > Rainer 
From: Rainer Schöpf <rainer.schoepf@gm...>  20110907 15:34:09

I believe I've now managed to treat this and other cases correctly. However, I'm not entirely sure how to treat inconsistent input. For example, assume the following depend statements depend f(u),a,b,c; depend u,a,b; depend {a,b,c},v; Obviously, these dependencies are inconsistent. With the switch expanddf set to on, how should df(f(u),v) be simplified? Using the chain rule with the first and the third dependencies, the result is (*) df(f(u),a)*df(a,v) + df(f(u),b)*df(b,v) + df(f(u),c)*df(c,v) but using the second and third dependencies, we get (**) df(f(u),u)*(df(a,v)*df(u,a) + df(b,v)*df(u,b)) One could argue that (*) is the better result since there is a direct dependency of f(u) on a,b,c. So, what should happen in this case? An error, or a warning message? If no error, then what should be returned? (1) Result (*) (2) Result (**) (3) do not apply chain rule, return df(f(u),v) instead Rainer Original Message On Tue, 6 Sep 2011, Francis Wright wrote: > Yes. Not applying the chain rule is certainly better than an error, and it's > probably the right thing mathematically as well. > > Francis > > > Original Message > > From: Rainer Schöpf [mailto:rainer.schoepf@...] > > Sent: Monday, September 05, 2011 7:27 PM > > To: Francis Wright > > Cc: reducealgebradevelopers@... > > Subject: RE: [Reducealgebradevelopers] An inconsistency in computing > > derivatives? > > > > Well, there is a least one problem: > > > >  > > Reduce (Free PSL version), 5Sep2011 ... > > > > 1: let x^3=u; > > > > 2: df(x,u); > > > > df(x,u) > > > > 3: on expanddf; > > > > 4: df(x,u); > > ***** Segmentation Violation in diffp > >  > > > > This is from trying to take a cdr of nil, in the line reading > > > > if !*expanddf and not(v memq (x:=cdr atsoc(u, depl!*))) then << > > > > It happens when u (in this case the symbol x) can be found in powlis!* but not > in > > depl!*. > > > > I think that the chain rule shouldn't be applied here, ie. the code should > read > > something like (at the same time protecting against cdr nil): > > > > if !*expanddf > > and (not (x:= atsoc(u,powlis!*)) or not depends(cadddr x,v)) > > and not (x := atsoc(u, depl!*) and (v memq (x := cdr x))) then << > > > > Rainer > > > > > > ______________________________________________________________ > > ____________ > > On Fri, 2 Sep 2011 at 18:22 +0100, Francis Wright wrote: > > > > > I think this is code that I had a hand in a while ago and I think I didn?t > > > > consider the case of mixed explicit and implicit dependence. I agree that > > this > > case should be included. I think I regarded this code as experimental, > > which is > > probably why it didn?t get put into the manual. Given that the code > is > still there > > it can't have caused undue problems, so it's probably time it > was included > in > > the manual! > > > > > > Francis > > > > > > > Original Message > > > > From: Rainer Schöpf [mailto:rainer.schoepf@...] > > Sent: 01 > > September 2011 6:21 pm > > To: reducealgebra > > developers@... > > > > Subject: [Reducealgebradevelopers] An inconsistency in computing > > > > derivatives? > > > > > > > > Compare the following examples > > > > > > > > A) > > > >  > > > > 1: depend f,r; > > > > > > > > 2: depend r,x; > > > > > > > > 3: df(f,x); > > > > > > > > df(f,x) > > > > > > > > 4: on expanddf; > > > > > > > > 5: df(f,x); > > > > > > > > df(f,r)*df(r,x) > > > >  > > > > > > > > B) > > > >  > > > > 1: operator f; > > > > > > > > 2: depend r,x; > > > > > > > > 3: df(f(r),x); > > > > > > > > df(f(r),x) > > > > > > > > 4: on expanddf; > > > > > > > > 5: df(f(r),x); > > > > > > > > df(f(r),x) > > > >  > > > > > > > > With on expanddf, the chain rule is applied to the first example, but not > > to > > the > > second one. Shouldn't this be done as well? > > > > > > > > The second one is needed for the changevr package; this package redefines > > > diffp > > to achieve it. > > > > > > > > (As an aside: the new switches like expanddf are not described in the > > > manual; > > was this deliberate? If not, I'll update the documentation.) > > > > > > Rainer > > > > > > > > > > > >  
From: Aditya Narayan <aditya.pda@gm...>  20110906 22:38:53

Hello, I'm a new Reduce user and please excuse me if these questions have been asked before: 1. The CSL version as I understood can be used from within a Cbased programming environment. Is there a hello world for that? 2. Related to above  can the kernel of Reduce (without GUI etc.) be built as a shared library? 3. Any instructions for building Reduce from source on a Mac OS X Lion? I am trying but there are many errors ( related to FreeType, FOX) and I'm slowly making progress but if there's something on it that I can use  I'll appreciate it. Thank you, Jim 
From: Francis Wright <f.wright@qm...>  20110906 08:43:52

Yes. Not applying the chain rule is certainly better than an error, and it's probably the right thing mathematically as well. Francis > Original Message > From: Rainer Schöpf [mailto:rainer.schoepf@...] > Sent: Monday, September 05, 2011 7:27 PM > To: Francis Wright > Cc: reducealgebradevelopers@... > Subject: RE: [Reducealgebradevelopers] An inconsistency in computing > derivatives? > > Well, there is a least one problem: > >  > Reduce (Free PSL version), 5Sep2011 ... > > 1: let x^3=u; > > 2: df(x,u); > > df(x,u) > > 3: on expanddf; > > 4: df(x,u); > ***** Segmentation Violation in diffp >  > > This is from trying to take a cdr of nil, in the line reading > > if !*expanddf and not(v memq (x:=cdr atsoc(u, depl!*))) then << > > It happens when u (in this case the symbol x) can be found in powlis!* but not in > depl!*. > > I think that the chain rule shouldn't be applied here, ie. the code should read > something like (at the same time protecting against cdr nil): > > if !*expanddf > and (not (x:= atsoc(u,powlis!*)) or not depends(cadddr x,v)) > and not (x := atsoc(u, depl!*) and (v memq (x := cdr x))) then << > > Rainer > > > ______________________________________________________________ > ____________ > On Fri, 2 Sep 2011 at 18:22 +0100, Francis Wright wrote: > > > I think this is code that I had a hand in a while ago and I think I didn?t > > consider the case of mixed explicit and implicit dependence. I agree that > this > case should be included. I think I regarded this code as experimental, > which is > probably why it didn?t get put into the manual. Given that the code > is still there > it can't have caused undue problems, so it's probably time it > was included in > the manual! > > > > Francis > > > > > Original Message > > > From: Rainer Schöpf [mailto:rainer.schoepf@...] > > Sent: 01 > September 2011 6:21 pm > > To: reducealgebra > developers@... > > > Subject: [Reducealgebradevelopers] An inconsistency in computing > > > derivatives? > > > > > > Compare the following examples > > > > > > A) > > >  > > > 1: depend f,r; > > > > > > 2: depend r,x; > > > > > > 3: df(f,x); > > > > > > df(f,x) > > > > > > 4: on expanddf; > > > > > > 5: df(f,x); > > > > > > df(f,r)*df(r,x) > > >  > > > > > > B) > > >  > > > 1: operator f; > > > > > > 2: depend r,x; > > > > > > 3: df(f(r),x); > > > > > > df(f(r),x) > > > > > > 4: on expanddf; > > > > > > 5: df(f(r),x); > > > > > > df(f(r),x) > > >  > > > > > > With on expanddf, the chain rule is applied to the first example, but not > to > the > > second one. Shouldn't this be done as well? > > > > > > The second one is needed for the changevr package; this package redefines > > diffp > > to achieve it. > > > > > > (As an aside: the new switches like expanddf are not described in the > > manual; > > was this deliberate? If not, I'll update the documentation.) > > > > > Rainer > > > > > > > >  > >  > > > Special Offer  Download ArcSight Logger for FREE! > > > Finally, a worldclass log management solution at an even better > price > free! And > > you'll get a free "Love Thy Logs" tshirt when you download Logger. > Secure > your > > free ArcSight Logger TODAY! > > > http://p.sf.net/sfu/arcsisghtdev2dev > > > _______________________________________________ > > > Reducealgebradevelopers mailing list > > Reducealgebra > developers@... > > > https://lists.sourceforge.net/lists/listinfo/reducealgebradevelopers > > 
From: Rainer Schöpf <rainer.schoepf@gm...>  20110905 18:26:37

Well, there is a least one problem:  Reduce (Free PSL version), 5Sep2011 ... 1: let x^3=u; 2: df(x,u); df(x,u) 3: on expanddf; 4: df(x,u); ***** Segmentation Violation in diffp  This is from trying to take a cdr of nil, in the line reading if !*expanddf and not(v memq (x:=cdr atsoc(u, depl!*))) then << It happens when u (in this case the symbol x) can be found in powlis!* but not in depl!*. I think that the chain rule shouldn't be applied here, ie. the code should read something like (at the same time protecting against cdr nil): if !*expanddf and (not (x:= atsoc(u,powlis!*)) or not depends(cadddr x,v)) and not (x := atsoc(u, depl!*) and (v memq (x := cdr x))) then << Rainer __________________________________________________________________________ On Fri, 2 Sep 2011 at 18:22 +0100, Francis Wright wrote: > I think this is code that I had a hand in a while ago and I think I didn?t > consider the case of mixed explicit and implicit dependence. I agree that > this case should be included. I think I regarded this code as experimental, > which is probably why it didn?t get put into the manual. Given that the code > is still there it can't have caused undue problems, so it's probably time it > was included in the manual! > > Francis > > > Original Message > > From: Rainer Schöpf [mailto:rainer.schoepf@...] > > Sent: 01 September 2011 6:21 pm > > To: reducealgebradevelopers@... > > Subject: [Reducealgebradevelopers] An inconsistency in computing > > derivatives? > > > > Compare the following examples > > > > A) > >  > > 1: depend f,r; > > > > 2: depend r,x; > > > > 3: df(f,x); > > > > df(f,x) > > > > 4: on expanddf; > > > > 5: df(f,x); > > > > df(f,r)*df(r,x) > >  > > > > B) > >  > > 1: operator f; > > > > 2: depend r,x; > > > > 3: df(f(r),x); > > > > df(f(r),x) > > > > 4: on expanddf; > > > > 5: df(f(r),x); > > > > df(f(r),x) > >  > > > > With on expanddf, the chain rule is applied to the first example, but not > to the > > second one. Shouldn't this be done as well? > > > > The second one is needed for the changevr package; this package redefines > diffp > > to achieve it. > > > > (As an aside: the new switches like expanddf are not described in the > manual; > > was this deliberate? If not, I'll update the documentation.) > > > > Rainer > > > > >  >  > > Special Offer  Download ArcSight Logger for FREE! > > Finally, a worldclass log management solution at an even better > pricefree! And > > you'll get a free "Love Thy Logs" tshirt when you download Logger. Secure > your > > free ArcSight Logger TODAY! > > http://p.sf.net/sfu/arcsisghtdev2dev > > _______________________________________________ > > Reducealgebradevelopers mailing list > > Reducealgebradevelopers@... > > https://lists.sourceforge.net/lists/listinfo/reducealgebradevelopers > 
From: Francis Wright <f.wright@qm...>  20110902 17:22:58

I think this is code that I had a hand in a while ago and I think I didnt consider the case of mixed explicit and implicit dependence. I agree that this case should be included. I think I regarded this code as experimental, which is probably why it didnt get put into the manual. Given that the code is still there it can't have caused undue problems, so it's probably time it was included in the manual! Francis > Original Message > From: Rainer Schöpf [mailto:rainer.schoepf@...] > Sent: 01 September 2011 6:21 pm > To: reducealgebradevelopers@... > Subject: [Reducealgebradevelopers] An inconsistency in computing > derivatives? > > Compare the following examples > > A) >  > 1: depend f,r; > > 2: depend r,x; > > 3: df(f,x); > > df(f,x) > > 4: on expanddf; > > 5: df(f,x); > > df(f,r)*df(r,x) >  > > B) >  > 1: operator f; > > 2: depend r,x; > > 3: df(f(r),x); > > df(f(r),x) > > 4: on expanddf; > > 5: df(f(r),x); > > df(f(r),x) >  > > With on expanddf, the chain rule is applied to the first example, but not to the > second one. Shouldn't this be done as well? > > The second one is needed for the changevr package; this package redefines diffp > to achieve it. > > (As an aside: the new switches like expanddf are not described in the manual; > was this deliberate? If not, I'll update the documentation.) > > Rainer > >   > Special Offer  Download ArcSight Logger for FREE! > Finally, a worldclass log management solution at an even better pricefree! And > you'll get a free "Love Thy Logs" tshirt when you download Logger. Secure your > free ArcSight Logger TODAY! > http://p.sf.net/sfu/arcsisghtdev2dev > _______________________________________________ > Reducealgebradevelopers mailing list > Reducealgebradevelopers@... > https://lists.sourceforge.net/lists/listinfo/reducealgebradevelopers 
From: Rainer Schöpf <rainer.schoepf@gm...>  20110901 17:21:25

Compare the following examples A)  1: depend f,r; 2: depend r,x; 3: df(f,x); df(f,x) 4: on expanddf; 5: df(f,x); df(f,r)*df(r,x)  B)  1: operator f; 2: depend r,x; 3: df(f(r),x); df(f(r),x) 4: on expanddf; 5: df(f(r),x); df(f(r),x)  With on expanddf, the chain rule is applied to the first example, but not to the second one. Shouldn't this be done as well? The second one is needed for the changevr package; this package redefines diffp to achieve it. (As an aside: the new switches like expanddf are not described in the manual; was this deliberate? If not, I'll update the documentation.) Rainer 