Screenshot instructions:
Windows
Mac
Red Hat Linux
Ubuntu
Click URL instructions:
Rightclick on ad, choose "Copy Link", then paste here →
(This may not be possible with some types of ads)
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: 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 
From: Francis Wright <f.j.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...>  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.j.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...>  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: Francis Wright <f.j.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...>  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.j.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...>  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 
Sign up for the SourceForge newsletter:
No, thanks