## reduce-algebra-developers — Discussion of development, administration and support for Reduce

You can subscribe to this list here.

 2009 2010 2011 2012 2013 2014 2015 2016 2017 Jan (2) Feb (5) Mar Apr May (2) Jun (8) Jul (4) Aug Sep Oct (2) Nov (6) Dec Jan (1) Feb (1) Mar (3) Apr (2) May (2) Jun (2) Jul (18) Aug (13) Sep (7) Oct Nov Dec (2) Jan Feb (11) Mar Apr (4) May Jun (1) Jul (18) Aug (16) Sep (12) Oct (12) Nov (19) Dec (42) Jan (16) Feb (3) Mar (8) Apr (14) May (30) Jun (5) Jul (7) Aug (3) Sep (10) Oct (4) Nov (10) Dec (1) Jan (14) Feb (8) Mar (5) Apr (3) May (9) Jun (19) Jul Aug (27) Sep (5) Oct (18) Nov (12) Dec (8) Jan (5) Feb (8) Mar (20) Apr (22) May (28) Jun (9) Jul (6) Aug (46) Sep (40) Oct (15) Nov (8) Dec (34) Jan (20) Feb (15) Mar (18) Apr (20) May (3) Jun (13) Jul (10) Aug (19) Sep (8) Oct (31) Nov (26) Dec (13) Jan (13) Feb (4) Mar (14) Apr (28) May (19) Jun (7) Jul (1) Aug Sep (19) Oct (5) Nov (4) Dec (9) Jan (4) Feb (30) Mar Apr May Jun Jul 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

Showing 2 results of 2

 Re: [Reduce-algebra-developers] An inconsistency in computing derivatives? From: Rainer Schöpf - 2011-09-08 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 ```
 Re: [Reduce-algebra-developers] An inconsistency in computing derivatives? From: Francis Wright - 2011-09-08 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: reduce-algebra-developers@... > 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 ```

Showing 2 results of 2