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 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 1 results of 1

 Re: [Reduce-algebra-developers] An inconsistency in computing derivatives? From: Rainer Schöpf - 2011-09-07 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: reduce-algebra-developers@... > > 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:rainer.schoepf@...] > > Sent: 01 > > September 2011 6:21 pm > > To: reduce-algebra- > > developers@... > > > > 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 > > > > > > > > > > > > ---------------------------------------------------------------------------- ```

Showing 1 results of 1