[MUG] bug in funding the reduced form of functions?

[MUG] Re: bug in funding the reduced form of functions
Author: Maple User Group    Posted: Fri, 15 Nov 2002 10:46:17 -0500
>> From: Maple User Group "maple_gr" |>> From: "Antony Davies, Ph.D." "antony" | When I issue the command: | > sum ( ( 1 / exp ( r ) ) ^ ( n * i ) , i = 0 .. infinity ); | Maple simply returns this same function in its original summation notation. | However, when I issue the command: | > sum ( ( exp ( r ) ) ^ ( -n * i ) , i = 0 .. infinity ); | (which is an equivalent function) I get the correct reduced form: | | ( exp ( r ) ^ n ) / ( exp ( r ) ^ n - 1 ) -=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=- Date: Mon, 11 Nov 2002 16:10:05 -0800 (PST) From: Robert Israel "israel" To: "maple-list" Subject: bug in funding the reduced form of functions? One could say you shouldn't get it for either one unless you make assumptions sufficient to ensure that the sum converges. Yes, I know, Maple is supposed to use "summability methods", which in this case simply means it doesn't check for convergence. Convergence is not relevant to the distinction between the two results here. What seems to be happening here is that using normal and expand, `sum/hgpossib2` fails to simplify exp(-r)^(n*(i+1))/exp(-r)^(n*i) to exp(-r)^n, but it does simplify exp(r)^(-n*(i+1))/exp(r)^(-n*i) to 1/(exp(r)^n). Ultimately, it seems to me the source is a weakness in expand: > expand(a^(b+c)); b c a a but > expand((1/a)^(b+c)); (b + c) (1/a) Robert Israel "israel" Department of Mathematics http://www.math.ubc.ca/~israel University of British Columbia Vancouver, BC, Canada V6T 1Z2 -=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=- Date: Tue, 12 Nov 2002 08:10:50 -0400 From: Vladimir Bondarenko "vvb" To: "maple-list" Subject: bug in funding the reduced form of functions? Please take my congratulation. You has just identified a bug in Maple. > kernelopts(version); `Maple 8.00, IBM INTEL NT, Apr 22 2002 Build ID 110847` > sum ( ( 1 / exp ( r ) ) ^ ( n * i ) , i = 0 .. infinity ); sum ( ( 1 / exp ( r ) ) ^ ( n * i ) , i = 0 .. infinity ); # This is non-informative but correct as the behavior of the # sum depends drastically on the choice of r and n > sum ( ( exp ( r ) ) ^ ( -n * i ) , i = 0 .. infinity ); exp(r)^n/(exp(r)^n-1) > subs(r=1, n=-1, s); 1/exp(1)/(1/exp(1)-1) > evalf(%); -.5819767069 # This is wrong because actually the sum diverges to plus infinity > r:=1: n:=-1: > sum ( ( exp ( r ) ) ^ ( -n * i ) , i = 0 .. infinity ); infinity By the way, if you are interested in bugs in Maple, you may wish to visit my upcoming sites http://maple.bug-list.org/ Maple Bugs Encyclopaedia http://www.CAS-testing.org/ GEMM project Please note that, at the moment, the GEMM if off. There is many interesting discussions on the point at the Maple 8 Group at http://groups.yahoo.com/group/maple8/ . Best wishes, Vladimir Bondarenko Mathematical and Production Director Symbolic Testing Group Email: "vvb" Web : http://www.CAS-testing.org/ (under development, 95% ready) http://maple.bug-list.org/ (under development, 20% ready) Voice: (380)-652-447325 Mon-Fri 6 a.m. - 3 p.m. GMT ICQ : 173050619 Mail : 76 Zalesskaya Str, Simferopol, Crimea, Ukraine

Previous by date: [MUG] Lebesgue-Integral,  Classen, Manfred
Next by date: [MUG] Maple crashing with odeplot, John Robert Kitchin
Previous thread: [MUG] Limit Superior & Limit Inferior,  Classen, Manfred
Next thread: [MUG] Maple crashing with odeplot, John Robert Kitchin