reduce-algebra-developers

[Reduce-algebra-developers] An inconsistency in computing derivatives?

[Rainer S. <rai...@gm...>]

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

Re: [Reduce-algebra-developers] An inconsistency in computing derivatives?

[Francis W. <f.j...@qm...>]

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:rai...@gm...]
> Sent: 01 September 2011 6:21 pm
> To: red...@li...
> Subject: [Reduce-algebra-developers] 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 world-class log management solution at an even better
price-free! And
> you'll get a free "Love Thy Logs" t-shirt when you download Logger. Secure
your
> free ArcSight Logger TODAY!
> http://p.sf.net/sfu/arcsisghtdev2dev
> _______________________________________________
> Reduce-algebra-developers mailing list
> Red...@li...
> https://lists.sourceforge.net/lists/listinfo/reduce-algebra-developers

Re: [Reduce-algebra-developers] An inconsistency in computing derivatives?

[Rainer S. <rai...@gm...>]

Well, there is a least one problem:

--------------------------------
Reduce (Free PSL version),  5-Sep-2011 ...

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:rai...@gm...]
 > > Sent: 01 September 2011 6:21 pm
 > > To: red...@li...
 > > Subject: [Reduce-algebra-developers] 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 world-class log management solution at an even better
 > price-free! And
 > > you'll get a free "Love Thy Logs" t-shirt when you download Logger. Secure
 > your
 > > free ArcSight Logger TODAY!
 > > http://p.sf.net/sfu/arcsisghtdev2dev
 > > _______________________________________________
 > > Reduce-algebra-developers mailing list
 > > Red...@li...
 > > https://lists.sourceforge.net/lists/listinfo/reduce-algebra-developers
 > 

Re: [Reduce-algebra-developers] An inconsistency in computing derivatives?

[Francis W. <f.j...@qm...>]

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:rai...@gm...]
> Sent: Monday, September 05, 2011 7:27 PM
> To: Francis Wright
> Cc: red...@li...
> Subject: RE: [Reduce-algebra-developers] An inconsistency in computing
> derivatives?
> 
> Well, there is a least one problem:
> 
> --------------------------------
> Reduce (Free PSL version),  5-Sep-2011 ...
> 
> 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:rai...@gm...]  > > Sent: 01
> September 2011 6:21 pm  > > To: reduce-algebra-
> dev...@li...
>  > > Subject: [Reduce-algebra-developers] 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 world-class log management solution at an even better  >
price-
> free! And  > > you'll get a free "Love Thy Logs" t-shirt when you download
Logger.
> Secure  > your  > > free ArcSight Logger TODAY!
>  > > http://p.sf.net/sfu/arcsisghtdev2dev
>  > > _______________________________________________
>  > > Reduce-algebra-developers mailing list  > > Reduce-algebra-
> dev...@li...
>  > > https://lists.sourceforge.net/lists/listinfo/reduce-algebra-developers
>  >

Re: [Reduce-algebra-developers] An inconsistency in computing derivatives?

[Rainer S. <rai...@gm...>]

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:rai...@gm...]
 > > Sent: Monday, September 05, 2011 7:27 PM
 > > To: Francis Wright
 > > Cc: red...@li...
 > > Subject: RE: [Reduce-algebra-developers] An inconsistency in computing
 > > derivatives?
 > > 
 > > Well, there is a least one problem:
 > > 
 > > --------------------------------
 > > Reduce (Free PSL version),  5-Sep-2011 ...
 > > 
 > > 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:rai...@gm...]  > > Sent: 01
 > > September 2011 6:21 pm  > > To: reduce-algebra-
 > > dev...@li...
 > >  > > Subject: [Reduce-algebra-developers] 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
 > >  > >
 > >  > >
 > >  >
 > ----------------------------------------------------------------------------

Re: [Reduce-algebra-developers] An inconsistency in computing derivatives?

[Francis W. <f.j...@qm...>]

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:rai...@gm...]
> Sent: Wednesday, September 07, 2011 4:34 PM
> To: Francis Wright
> Cc: red...@li...
> Subject: RE: [Reduce-algebra-developers] 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

Re: [Reduce-algebra-developers] An inconsistency in computing derivatives?

[Rainer S. <rai...@gm...>]

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

Re: [Reduce-algebra-developers] An inconsistency in computing derivatives?

[Francis W. <f.j...@qm...>]

> From: Rainer Schöpf [mailto:rai...@gm...]
> Sent: Thursday, September 08, 2011 9:21 PM
> To: Francis Wright
> Cc: red...@li...
> Subject: RE: [Reduce-algebra-developers] 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

Re: [Reduce-algebra-developers] An inconsistency in computing derivatives?

[Rainer S. <rai...@gm...>]

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/sep-05-2011-expanddf.tst
  packages/regressions/sep-05-2011-expanddf.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