You can subscribe to this list here.
2002 
_{Jan}

_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}
(67) 
_{Jul}
(61) 
_{Aug}
(49) 
_{Sep}
(43) 
_{Oct}
(59) 
_{Nov}
(24) 
_{Dec}
(18) 

2003 
_{Jan}
(34) 
_{Feb}
(35) 
_{Mar}
(72) 
_{Apr}
(42) 
_{May}
(46) 
_{Jun}
(15) 
_{Jul}
(64) 
_{Aug}
(62) 
_{Sep}
(22) 
_{Oct}
(41) 
_{Nov}
(57) 
_{Dec}
(56) 
2004 
_{Jan}
(48) 
_{Feb}
(47) 
_{Mar}
(33) 
_{Apr}
(39) 
_{May}
(6) 
_{Jun}
(17) 
_{Jul}
(19) 
_{Aug}
(10) 
_{Sep}
(14) 
_{Oct}
(74) 
_{Nov}
(80) 
_{Dec}
(22) 
2005 
_{Jan}
(43) 
_{Feb}
(33) 
_{Mar}
(52) 
_{Apr}
(74) 
_{May}
(32) 
_{Jun}
(58) 
_{Jul}
(18) 
_{Aug}
(41) 
_{Sep}
(71) 
_{Oct}
(28) 
_{Nov}
(65) 
_{Dec}
(68) 
2006 
_{Jan}
(54) 
_{Feb}
(37) 
_{Mar}
(82) 
_{Apr}
(211) 
_{May}
(69) 
_{Jun}
(75) 
_{Jul}
(279) 
_{Aug}
(139) 
_{Sep}
(135) 
_{Oct}
(58) 
_{Nov}
(81) 
_{Dec}
(78) 
2007 
_{Jan}
(141) 
_{Feb}
(134) 
_{Mar}
(65) 
_{Apr}
(49) 
_{May}
(61) 
_{Jun}
(90) 
_{Jul}
(72) 
_{Aug}
(53) 
_{Sep}
(86) 
_{Oct}
(61) 
_{Nov}
(62) 
_{Dec}
(101) 
2008 
_{Jan}
(100) 
_{Feb}
(66) 
_{Mar}
(76) 
_{Apr}
(95) 
_{May}
(77) 
_{Jun}
(93) 
_{Jul}
(103) 
_{Aug}
(76) 
_{Sep}
(42) 
_{Oct}
(55) 
_{Nov}
(44) 
_{Dec}
(75) 
2009 
_{Jan}
(103) 
_{Feb}
(105) 
_{Mar}
(121) 
_{Apr}
(59) 
_{May}
(103) 
_{Jun}
(82) 
_{Jul}
(67) 
_{Aug}
(76) 
_{Sep}
(85) 
_{Oct}
(75) 
_{Nov}
(181) 
_{Dec}
(133) 
2010 
_{Jan}
(107) 
_{Feb}
(116) 
_{Mar}
(145) 
_{Apr}
(89) 
_{May}
(138) 
_{Jun}
(85) 
_{Jul}
(82) 
_{Aug}
(111) 
_{Sep}
(70) 
_{Oct}
(83) 
_{Nov}
(60) 
_{Dec}
(16) 
2011 
_{Jan}
(61) 
_{Feb}
(16) 
_{Mar}
(52) 
_{Apr}
(41) 
_{May}
(34) 
_{Jun}
(41) 
_{Jul}
(57) 
_{Aug}
(73) 
_{Sep}
(21) 
_{Oct}
(45) 
_{Nov}
(50) 
_{Dec}
(28) 
2012 
_{Jan}
(70) 
_{Feb}
(36) 
_{Mar}
(71) 
_{Apr}
(29) 
_{May}
(48) 
_{Jun}
(61) 
_{Jul}
(44) 
_{Aug}
(54) 
_{Sep}
(20) 
_{Oct}
(28) 
_{Nov}
(41) 
_{Dec}
(137) 
2013 
_{Jan}
(62) 
_{Feb}
(55) 
_{Mar}
(31) 
_{Apr}
(23) 
_{May}
(54) 
_{Jun}
(54) 
_{Jul}
(90) 
_{Aug}
(46) 
_{Sep}
(38) 
_{Oct}
(60) 
_{Nov}
(92) 
_{Dec}
(17) 
2014 
_{Jan}
(62) 
_{Feb}
(35) 
_{Mar}
(72) 
_{Apr}
(30) 
_{May}
(97) 
_{Jun}
(81) 
_{Jul}
(63) 
_{Aug}
(64) 
_{Sep}
(28) 
_{Oct}
(45) 
_{Nov}
(48) 
_{Dec}
(109) 
2015 
_{Jan}
(106) 
_{Feb}
(36) 
_{Mar}
(65) 
_{Apr}
(63) 
_{May}
(95) 
_{Jun}
(56) 
_{Jul}
(48) 
_{Aug}
(55) 
_{Sep}
(100) 
_{Oct}
(57) 
_{Nov}
(33) 
_{Dec}
(46) 
2016 
_{Jan}
(76) 
_{Feb}
(53) 
_{Mar}
(88) 
_{Apr}
(79) 
_{May}
(62) 
_{Jun}
(65) 
_{Jul}
(37) 
_{Aug}
(23) 
_{Sep}
(108) 
_{Oct}
(68) 
_{Nov}
(66) 
_{Dec}
(47) 
2017 
_{Jan}
(55) 
_{Feb}
(11) 
_{Mar}
(30) 
_{Apr}
(12) 
_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 






1
(2) 
2
(13) 
3
(4) 
4

5

6
(1) 
7

8
(1) 
9
(3) 
10
(1) 
11
(2) 
12
(2) 
13
(2) 
14
(1) 
15

16

17
(3) 
18
(1) 
19
(1) 
20
(3) 
21
(1) 
22
(3) 
23
(1) 
24
(7) 
25
(3) 
26
(5) 
27
(2) 
28

29
(4) 

From: SourceForge.net <noreply@so...>  20080202 23:54:55

Bugs item #1587235, was opened at 20061030 07:08 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1587235&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Limit Group: None Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: limit(floor(x),x,1) wrong Initial Comment: With Maxima version: 5.10.0, I get the following : (%i1) limit(floor(x),x,1); (%o1) 1 should be und (%i2) limit(floor(x),x,1,minus); (%o2) 1 should be 0 Eric Reyssat email : reyssat@...  >Comment By: Robert Dodier (robert_dodier) Date: 20080202 16:54 Message: Logged In: YES user_id=501686 Originator: NO I dunno. A noun form is useful if some additional information would make it possible to resolve it to some more definite result. But for 'limit(floor(x)+1,x,0) there isn't any such additional info, from what I can tell. So I think limit(floor(x),x,1) should yield und. Also it seems limit(floor(x),x,1,minus) should yield 0, not a noun expression. I guess the noun expressions are not incorrect, but they're not correct either. By the way, Dan, thanks a lot for all the bug fixes you have made. I appreciate it a lot.  Comment By: Dan Gildea (dgildea) Date: 20080202 09:47 Message: Logged In: YES user_id=1797506 Originator: NO Returns noun form as of limit.lisp 1.50: (%i4) limit(floor(x),x,1); (%o4) 'limit(floor(x)+1,x,0) (%i5) limit(floor(x),x,1,minus); (%o5) 'limit(floor(x)+1,x,0,minus)  Comment By: Robert Dodier (robert_dodier) Date: 20061030 08:09 Message: Logged In: YES user_id=501686 limit is mistakenly assuming that floor is continuous. I don't know how to make limit recognize that floor is discontinuous. Assigning this report to the "Lisp Core  Limit" category.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1587235&group_id=4933 
From: SourceForge.net <noreply@so...>  20080202 23:13:00

Bugs item #1885377, was opened at 20080202 14:20 Message generated for change (Comment added) made by dgildea You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1885377&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Limit Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: wrong limit evaluation in 5.14.0 Initial Comment: In 5.13.0, both limit((3/4)^(5*n+1), n, inf, minus) limit((3/4)^(5*n), n, inf, minus) give 0, which is good. In 5.14.0 limit((3/4)^(5*n), n, inf, minus) gives 0, which is OK, but limit((3/4)^(5*n+1), n, inf, minus) gives infinity, which is wrong. My guess is: Something is wrong with parsing parentheses.  >Comment By: Dan Gildea (dgildea) Date: 20080202 18:12 Message: Logged In: YES user_id=1797506 Originator: NO Fixed in limit.lisp rev 1.51.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1885377&group_id=4933 
From: SourceForge.net <noreply@so...>  20080202 19:20:51

Bugs item #1885377, was opened at 20080202 11:20 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1885377&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Limit Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: wrong limit evaluation in 5.14.0 Initial Comment: In 5.13.0, both limit((3/4)^(5*n+1), n, inf, minus) limit((3/4)^(5*n), n, inf, minus) give 0, which is good. In 5.14.0 limit((3/4)^(5*n), n, inf, minus) gives 0, which is OK, but limit((3/4)^(5*n+1), n, inf, minus) gives infinity, which is wrong. My guess is: Something is wrong with parsing parentheses.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1885377&group_id=4933 
From: SourceForge.net <noreply@so...>  20080202 16:52:58

Bugs item #1103515, was opened at 20050116 16:45 Message generated for change (Comment added) made by dgildea You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1103515&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Limit Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: limit(atan2(x,1),x,0) wrong Initial Comment: limit(atan2(x,1),x,0,plus) => %pi OK limit(atan2(x,1),x,0,minus) => %pi OK limit(atan2(x,1),x,0) => %pi !!! should be IND  >Comment By: Dan Gildea (dgildea) Date: 20080202 11:52 Message: Logged In: YES user_id=1797506 Originator: NO Fixed in limit.lisp rev 1.50. (%i13) limit(atan2(x,1),x,0,plus); (%o13) %pi (%i14) limit(atan2(x,1),x,0,minus); (%o14) %pi (%i15) limit(atan2(x,1),x,0); (%o15) und Ideally %o15 should be ind, but maxima always returns und for limits that are different from either side.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1103515&group_id=4933 
From: SourceForge.net <noreply@so...>  20080202 16:51:05

Bugs item #593357, was opened at 20020809 23:36 Message generated for change (Comment added) made by dgildea You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=593357&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Limit Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: Various problems with Limit and Atan2 Initial Comment: limit(atan2(sin(x),1/x),x,0) returns  FALSE Note that this only happens when the argument expression is negated (!).  limit(atan2(x,2*x),x,0) and limit(atan2(2*x^2,x^2),x,0) give the error Atan2(0,0) has been generated. But the first should give IND, and the second should give atan(2).  limit(atan2(x*abs(a),x),inf) correctly gives atan(abs(a)), but limit(atan2(x,abs(a)*x),x,inf) gives the noun form   >Comment By: Dan Gildea (dgildea) Date: 20080202 11:51 Message: Logged In: YES user_id=1797506 Originator: NO Fixed in limit.lisp rev 1.50. (%i8) limit(atan2(sin(x),1/x),x,0); (%o8) 'limit(atan2(sin(x),1/x),x,0) (%i9) limit(atan2(x*abs(a),x),x,inf); (%o9) atan(abs(a)) (%i10) limit(atan2(x,abs(a)*x),x,inf); (%o10) 'limit(atan2(x,abs(a)*x),x,inf) (%i11) limit(atan2(x,2*x),x,0); (%o11) und (%i12) limit(atan2(2*x^2,x^2),x,0); (%o12) atan(2) %o11 should ideally be ind, but maxima always returns und for limits that are different from either side.  Comment By: Raymond Toy (rtoy) Date: 20061108 22:05 Message: Logged In: YES user_id=28849 Current CVS (including the fix for bug 626697 does this: limit(atan2(sin(x),1/x),x,0) > nounform limit(atan2(x*abs(a),x),inf) > atan(a) limit(atan2(x,abs(a)*x),x,inf) > atan(1/a) limit(atan2(x,2*x),x,0) and limit(atan2(2*x^2,x^2),x,0) both return atan2(0,0) generated.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=593357&group_id=4933 
From: SourceForge.net <noreply@so...>  20080202 16:47:59

Bugs item #1587235, was opened at 20061030 09:08 Message generated for change (Comment added) made by dgildea You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1587235&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Limit Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: limit(floor(x),x,1) wrong Initial Comment: With Maxima version: 5.10.0, I get the following : (%i1) limit(floor(x),x,1); (%o1) 1 should be und (%i2) limit(floor(x),x,1,minus); (%o2) 1 should be 0 Eric Reyssat email : reyssat@...  >Comment By: Dan Gildea (dgildea) Date: 20080202 11:47 Message: Logged In: YES user_id=1797506 Originator: NO Returns noun form as of limit.lisp 1.50: (%i4) limit(floor(x),x,1); (%o4) 'limit(floor(x)+1,x,0) (%i5) limit(floor(x),x,1,minus); (%o5) 'limit(floor(x)+1,x,0,minus)  Comment By: Robert Dodier (robert_dodier) Date: 20061030 10:09 Message: Logged In: YES user_id=501686 limit is mistakenly assuming that floor is continuous. I don't know how to make limit recognize that floor is discontinuous. Assigning this report to the "Lisp Core  Limit" category.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1587235&group_id=4933 
From: SourceForge.net <noreply@so...>  20080202 16:13:47

Bugs item #1047432, was opened at 20041014 19:01 Message generated for change (Comment added) made by dgildea You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1047432&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Simplification Group: None >Status: Closed >Resolution: Works For Me Priority: 5 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: erf(m) not simplified to erf(m) when m known to be negativ Initial Comment: assume(m<0)$ integrate((ym)*%e^y^2,y,m,inf); gives a result containing erf(m), which should have simplified to erf(m). Workaround is easy: just do expand(<<result>>,0,0) to force resimplification.  >Comment By: Dan Gildea (dgildea) Date: 20080202 11:13 Message: Logged In: YES user_id=1797506 Originator: NO Seems ok in current cvs: (%i3) assume(m<0)$ (%i4) erf(m); (%o4) erf(m) (%i5) integrate((ym)*%e^y^2,y,m,inf); (%o5) %e^m^2*(sqrt(%pi)*m*%e^m^2*erf(m)+1)/2sqrt(%pi)*m/2  Comment By: Robert Dodier (robert_dodier) Date: 20060731 00:23 Message: Logged In: YES user_id=501686 Observed in 5.9.3cvs. expand(%,0,0) does not cause simplification of erf(m) to erf(m). Aside from this problem with the integral: erf(m) => erf(m) (not simplified). Dunno if it's relevant, but: featurep(erf, oddfun) => false . HOWEVER with no assumptions about mm, note that erf(mm) =>  erf(mm) .  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1047432&group_id=4933 
From: SourceForge.net <noreply@so...>  20080202 15:47:43

Bugs item #1884711, was opened at 20080201 12:37 Message generated for change (Settings changed) made by dgildea You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1884711&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Simplification Group: None >Status: Closed >Resolution: Fixed Priority: 7 Private: No Submitted By: Tom Brown (nworbmot) Assigned to: Nobody/Anonymous (nobody) Summary: bug when adding fractions involving square roots Initial Comment: Maxima fails to compute the correct answer to the following subtractions when square roots are in the fractions: sqrt(2)/62*sqrt(2)/6 sqrt(3)/12  5*sqrt(3)/12 Perhaps this is a problem with the simplification algorithm. Maxima version: 5.12.0 Maxima build date: 15:52 7/20/2007 host type: i686pclinuxgnu lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.7 This bug also seems to be in SAGE, which I guess uses Maxima routines?  >Comment By: Dan Gildea (dgildea) Date: 20080202 10:47 Message: Logged In: YES user_id=1797506 Originator: NO Incorrect result fixed in simp.lisp rev 1.47, but result is still not always simplified: (%i2) sqrt(2)/62*sqrt(2)/6; (%o2) 2^(1/2)/3 (%i3) sqrt(3)/12  5*sqrt(3)/12; (%o3) 4*3^(1/2)/4  Comment By: Barton Willis (willisbl) Date: 20080202 05:46 Message: Logged In: YES user_id=895922 Originator: NO Observation: (5.14.0) (%i22) 2*sqrt(2)/6; (%o22) (2*2^(1/2))/3 (%i23) expand(%,0,0); (%o23) 2/(3*sqrt(2)) Somebody is returning unsimplified expressions, I think. The bug is bigger than just this problem.  Comment By: Robert Dodier (robert_dodier) Date: 20080202 00:37 Message: Logged In: YES user_id=501686 Originator: NO Observed in current version from CVS. Here is what I see: sqrt(2)/62*sqrt(2)/6; => 5*2^(1/2)/(3*3) sqrt(3)/12  5*sqrt(3)/12; => 19*3^(1/2)/(4*4) Not observed in 5.9.0, so I guess something got broken. Someone who has several installed versions could check each one to see when the error was introduced.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1884711&group_id=4933 
From: SourceForge.net <noreply@so...>  20080202 12:52:51

Bugs item #1885188, was opened at 20080202 06:52 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1885188&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Complex Group: None Status: Open Resolution: None Priority: 2 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Barton Willis (willisbl) Summary: conjugate of taylor poly Initial Comment: The conjugate of a taylor poly isn't a taylor poly: (%i210) conjugate(taylor(cos(x),x,0,2)); (%o210) 1x^2/2 I think this is wrong.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1885188&group_id=4933 
From: SourceForge.net <noreply@so...>  20080202 12:13:27

Bugs item #1879521, was opened at 20080125 04:31 Message generated for change (Settings changed) made by dgildea You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1879521&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core Group: None >Status: Closed >Resolution: Duplicate Priority: 5 Private: No Submitted By: Tore Gaupseth (toregaupseth) Assigned to: Nobody/Anonymous (nobody) Summary: Incorrect simplification of quotient times exponent Initial Comment: Sum function fails, sum((9/8)*(2/3)**i, i, 0, inf), simpsum; gives answer 216 instead of 9/8=3.375 Maxima version: 5.14.0 Maxima build date: 21:46 12/27/2007 host type: i686pcmingw32 lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.8 (%i51) sum((5/4)*(2/3)**i, i, 0, inf), simpsum; 15 (%o51)  4 (%i52) sum((1.25)*(2/3)**i, i, 0, inf), simpsum; (%o52) 3.75 (%i53) sum((9/8)*(2/3)**i, i, 0, inf), simpsum; (%o53) 216 (%i54) sum((1.125)*(2/3)**i, i, 0, inf), simpsum; (%o54) 3.375  >Comment By: Dan Gildea (dgildea) Date: 20080202 07:13 Message: Logged In: YES user_id=1797506 Originator: NO This is a duplicate of bug 1845375, which was resolved in simp.lisp rev 1.46.  Comment By: Robert Dodier (robert_dodier) Date: 20080202 00:57 Message: Logged In: YES user_id=501686 Originator: NO Problem appears to stem from incorrect simplification of a quotient times something to an exponent. (Just entering the summand (9/8)*(2/3)**i, i.e. not in a summation, shows that it is simplified incorrectly.) Changing title of this report accordingly.  Comment By: Robert Dodier (robert_dodier) Date: 20080131 00:54 Message: Logged In: YES user_id=501686 Originator: NO With recent builds from CVS, I get sum((9/8)*(2/3)**i, i, 0, inf), simpsum; => 27/8 for Maxima + GCL, SBCL, and Clisp (all on Linux). BUT for 5.13.0 + Clisp + Linux, and 5.14.0 + Clisp + Linux, and 5.12.0 + GCL + Windows Vista, and 5.14.0 + GCL + Windows Vista, I get 216. Constants factors like 3m/n seem to cause trouble, e.g. 9/7, 9/11, 9/19, 15/19, 18/19. It appears the problem has been resolved in recent CVS revisions. But without searching the CVS revisions, I don't know what might have been changed which fixes the problem.  Comment By: Nobody/Anonymous (nobody) Date: 20080129 02:07 Message: Logged In: NO built maxima form cvs with cmucl sum((9/8)*(2/3)**i,i,0,inf); returns correct resulta : 27/8 thanks andrejv delandre  Comment By: delandre (delandre) Date: 20080129 01:06 Message: Logged In: YES user_id=1993771 Originator: NO the same result with maxima 5.13 in sage  Comment By: Andrej Vodopivec (andrejv) Date: 20080128 12:38 Message: Logged In: YES user_id=1179910 Originator: NO This works as expected on sbcl + cvs maxima: (%i1) sum((9/8)*(2/3)**i, i, 0, inf), simpsum; (%o1) 27/8 (%i2) build_info()$ Maxima version: 5.14.0cvs Maxima build date: 23:27 1/26/2008 host type: i386appledarwin8.11.1 lispimplementationtype: SBCL lispimplementationversion: 1.0.10 Andrej  Comment By: Tore Gaupseth (toregaupseth) Date: 20080125 05:17 Message: Logged In: YES user_id=1234122 Originator: YES The third line should read gives answer 216 instead of 27/8=3.375 and maybe the fault is that a math formula gives 3^3 * (2^(3)) and Maxima somehow calculates 3^3 * 2^3  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1879521&group_id=4933 
From: SourceForge.net <noreply@so...>  20080202 10:46:50

Bugs item #1884711, was opened at 20080201 11:37 Message generated for change (Comment added) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1884711&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Simplification Group: None Status: Open Resolution: None >Priority: 7 Private: No Submitted By: Tom Brown (nworbmot) Assigned to: Nobody/Anonymous (nobody) Summary: bug when adding fractions involving square roots Initial Comment: Maxima fails to compute the correct answer to the following subtractions when square roots are in the fractions: sqrt(2)/62*sqrt(2)/6 sqrt(3)/12  5*sqrt(3)/12 Perhaps this is a problem with the simplification algorithm. Maxima version: 5.12.0 Maxima build date: 15:52 7/20/2007 host type: i686pclinuxgnu lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.7 This bug also seems to be in SAGE, which I guess uses Maxima routines?  >Comment By: Barton Willis (willisbl) Date: 20080202 04:46 Message: Logged In: YES user_id=895922 Originator: NO Observation: (5.14.0) (%i22) 2*sqrt(2)/6; (%o22) (2*2^(1/2))/3 (%i23) expand(%,0,0); (%o23) 2/(3*sqrt(2)) Somebody is returning unsimplified expressions, I think. The bug is bigger than just this problem.  Comment By: Robert Dodier (robert_dodier) Date: 20080201 23:37 Message: Logged In: YES user_id=501686 Originator: NO Observed in current version from CVS. Here is what I see: sqrt(2)/62*sqrt(2)/6; => 5*2^(1/2)/(3*3) sqrt(3)/12  5*sqrt(3)/12; => 19*3^(1/2)/(4*4) Not observed in 5.9.0, so I guess something got broken. Someone who has several installed versions could check each one to see when the error was introduced.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1884711&group_id=4933 
From: SourceForge.net <noreply@so...>  20080202 05:57:18

Bugs item #1879521, was opened at 20080125 02:31 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1879521&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Tore Gaupseth (toregaupseth) Assigned to: Nobody/Anonymous (nobody) >Summary: Incorrect simplification of quotient times exponent Initial Comment: Sum function fails, sum((9/8)*(2/3)**i, i, 0, inf), simpsum; gives answer 216 instead of 9/8=3.375 Maxima version: 5.14.0 Maxima build date: 21:46 12/27/2007 host type: i686pcmingw32 lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.8 (%i51) sum((5/4)*(2/3)**i, i, 0, inf), simpsum; 15 (%o51)  4 (%i52) sum((1.25)*(2/3)**i, i, 0, inf), simpsum; (%o52) 3.75 (%i53) sum((9/8)*(2/3)**i, i, 0, inf), simpsum; (%o53) 216 (%i54) sum((1.125)*(2/3)**i, i, 0, inf), simpsum; (%o54) 3.375  >Comment By: Robert Dodier (robert_dodier) Date: 20080201 22:57 Message: Logged In: YES user_id=501686 Originator: NO Problem appears to stem from incorrect simplification of a quotient times something to an exponent. (Just entering the summand (9/8)*(2/3)**i, i.e. not in a summation, shows that it is simplified incorrectly.) Changing title of this report accordingly.  Comment By: Robert Dodier (robert_dodier) Date: 20080130 22:54 Message: Logged In: YES user_id=501686 Originator: NO With recent builds from CVS, I get sum((9/8)*(2/3)**i, i, 0, inf), simpsum; => 27/8 for Maxima + GCL, SBCL, and Clisp (all on Linux). BUT for 5.13.0 + Clisp + Linux, and 5.14.0 + Clisp + Linux, and 5.12.0 + GCL + Windows Vista, and 5.14.0 + GCL + Windows Vista, I get 216. Constants factors like 3m/n seem to cause trouble, e.g. 9/7, 9/11, 9/19, 15/19, 18/19. It appears the problem has been resolved in recent CVS revisions. But without searching the CVS revisions, I don't know what might have been changed which fixes the problem.  Comment By: Nobody/Anonymous (nobody) Date: 20080129 00:07 Message: Logged In: NO built maxima form cvs with cmucl sum((9/8)*(2/3)**i,i,0,inf); returns correct resulta : 27/8 thanks andrejv delandre  Comment By: delandre (delandre) Date: 20080128 23:06 Message: Logged In: YES user_id=1993771 Originator: NO the same result with maxima 5.13 in sage  Comment By: Andrej Vodopivec (andrejv) Date: 20080128 10:38 Message: Logged In: YES user_id=1179910 Originator: NO This works as expected on sbcl + cvs maxima: (%i1) sum((9/8)*(2/3)**i, i, 0, inf), simpsum; (%o1) 27/8 (%i2) build_info()$ Maxima version: 5.14.0cvs Maxima build date: 23:27 1/26/2008 host type: i386appledarwin8.11.1 lispimplementationtype: SBCL lispimplementationversion: 1.0.10 Andrej  Comment By: Tore Gaupseth (toregaupseth) Date: 20080125 03:17 Message: Logged In: YES user_id=1234122 Originator: YES The third line should read gives answer 216 instead of 27/8=3.375 and maybe the fault is that a math formula gives 3^3 * (2^(3)) and Maxima somehow calculates 3^3 * 2^3  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1879521&group_id=4933 
From: SourceForge.net <noreply@so...>  20080202 05:37:18

Bugs item #1884711, was opened at 20080201 10:37 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1884711&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Simplification Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Tom Brown (nworbmot) Assigned to: Nobody/Anonymous (nobody) Summary: bug when adding fractions involving square roots Initial Comment: Maxima fails to compute the correct answer to the following subtractions when square roots are in the fractions: sqrt(2)/62*sqrt(2)/6 sqrt(3)/12  5*sqrt(3)/12 Perhaps this is a problem with the simplification algorithm. Maxima version: 5.12.0 Maxima build date: 15:52 7/20/2007 host type: i686pclinuxgnu lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.7 This bug also seems to be in SAGE, which I guess uses Maxima routines?  >Comment By: Robert Dodier (robert_dodier) Date: 20080201 22:37 Message: Logged In: YES user_id=501686 Originator: NO Observed in current version from CVS. Here is what I see: sqrt(2)/62*sqrt(2)/6; => 5*2^(1/2)/(3*3) sqrt(3)/12  5*sqrt(3)/12; => 19*3^(1/2)/(4*4) Not observed in 5.9.0, so I guess something got broken. Someone who has several installed versions could check each one to see when the error was introduced.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1884711&group_id=4933 