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}
(27) 
_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 


1
(1) 
2
(4) 
3
(2) 
4
(1) 
5

6

7
(5) 
8
(9) 
9

10
(2) 
11
(6) 
12
(12) 
13
(5) 
14
(7) 
15
(4) 
16
(4) 
17

18

19
(2) 
20
(7) 
21
(9) 
22
(7) 
23
(6) 
24
(5) 
25
(12) 
26
(12) 
27
(10) 
28
(4) 
29
(4) 
30
(5) 
31




From: SourceForge.net <noreply@so...>  20100326 23:34:57

Bugs item #2977332, was opened at 20100326 23:34 Message generated for change (Tracker Item Submitted) made by You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2977332&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  Integration Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: https://me.yahoo.com/a/eusus3Ud () Assigned to: Nobody/Anonymous (nobody) Summary: x*cos(x/2) Initial Comment: integrate(x*(cos(x/2)),x) and f(n):=expand(integrate(x*(n+cos(x/2)),x)integrate(n*x,x)); are same function but... When n are even numbers, results are always 1/2 (%i2) f(1); (%o2) 2*x*sin(x/2)+4*cos(x/2) (%i3) f(2); (%o3) x*sin(x/2)+2*cos(x/2) (%i4) f(3);(%o4) 2*x*sin(x/2)+4*cos(x/2) (%i5) f(4); ***** if f(n) is defined as f(n):=expand(integrate(x*n+x*cos(x/2),x)integrate(n*x,x)) f(n) gives always correct answer. (%o5) x*sin(x/2)+2*cos(x/2)  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2977332&group_id=4933 
From: SourceForge.net <noreply@so...>  20100326 22:35:05

Bugs item #2977307, was opened at 20100326 22:35 Message generated for change (Tracker Item Submitted) made by You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2977307&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  Integration Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: https://me.yahoo.com/a/eusus3Ud () Assigned to: Nobody/Anonymous (nobody) Summary: x*cos(x/2) Initial Comment: integrate(x*(cos(x/2)),x) and f(n):=expand(integrate(x*(n+cos(x/2)),x)integrate(n*x,x)); are same function but... When n are even numbers, results are always 1/2 (%i2) f(1); (%o2) 2*x*sin(x/2)+4*cos(x/2) (%i3) f(2); (%o3) x*sin(x/2)+2*cos(x/2) (%i4) f(3);(%o4) 2*x*sin(x/2)+4*cos(x/2) (%i5) f(4); ***** if f(n) is defined as f(n):=expand(integrate(x*n+x*cos(x/2),x)integrate(n*x,x)) f(n) gives always correct answer. (%o5) x*sin(x/2)+2*cos(x/2)  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2977307&group_id=4933 
From: SourceForge.net <noreply@so...>  20100326 20:40:35

Bugs item #2977217, was opened at 20100326 20:58 Message generated for change (Comment added) made by alex108 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2977217&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: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: maxima can not integrate x*exp(1/2*(xm)^2) Initial Comment: Maxima can not integrate the function x*exp(1/2*(xm)^2) Maxima 5.20.1 http://maxima.sourceforge.net using Lisp GNU Common Lisp (GCL) GCL 2.6.8 (a.k.a. GCL) Distributed under the GNU Public License. See the file COPYING. Dedicated to the memory of William Schelter. The function bug_report() provides bug reporting information. (%i1) integrate(x*exp(1/2*(xm)^2),x); 2 (x  m) /   [ 2 (%o1) I x %e dx ] / The correct solution would be (%i2) diff(exp(1/2*x^2+m*x1/2*m^2)+1/2*m*sqrt(%pi)*sqrt(2)*erf(1/2*sqrt(2)*x1/2*m*sqrt(2)),x); 2 2 x m 2 x m  (  )   + m x   sqrt(2) sqrt(2) 2 2 (%o2) m %e  (m  x) %e  Comment By: Aleksas Domarkas (alex108) Date: 20100326 22:40 Message: (%i1) S:'integrate(x*exp(1/2*(xm)^2),x); (%o1) integrate(x*%e^((xm)^2/2),x) (%i2) changevar(S, y=xm, y, x); (%o2) integrate((y+m)*%e^(y^2/2),y) (%i3) ev(%, nouns); (%o3) (sqrt(%pi)*m*erf(y/sqrt(2)))/sqrt(2)%e^(y^2/2) Solution: (%i4) sol:subst(y=xm,%),rootscontract; (%o4) sqrt(%pi/2)*m*erf((xm)/sqrt(2))%e^((xm)^2/2) Test: (%i5) diff(sol,x)first(S)$ (%i6) expand(%); (%o6) 0  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2977217&group_id=4933 
From: SourceForge.net <noreply@so...>  20100326 18:58:55

Bugs item #2977217, was opened at 20100326 18:58 Message generated for change (Tracker Item Submitted) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2977217&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: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: maxima can not integrate x*exp(1/2*(xm)^2) Initial Comment: Maxima can not integrate the function x*exp(1/2*(xm)^2) Maxima 5.20.1 http://maxima.sourceforge.net using Lisp GNU Common Lisp (GCL) GCL 2.6.8 (a.k.a. GCL) Distributed under the GNU Public License. See the file COPYING. Dedicated to the memory of William Schelter. The function bug_report() provides bug reporting information. (%i1) integrate(x*exp(1/2*(xm)^2),x); 2 (x  m) /   [ 2 (%o1) I x %e dx ] / The correct solution would be (%i2) diff(exp(1/2*x^2+m*x1/2*m^2)+1/2*m*sqrt(%pi)*sqrt(2)*erf(1/2*sqrt(2)*x1/2*m*sqrt(2)),x); 2 2 x m 2 x m  (  )   + m x   sqrt(2) sqrt(2) 2 2 (%o2) m %e  (m  x) %e  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2977217&group_id=4933 
From: SourceForge.net <noreply@so...>  20100326 14:09:56

Bugs item #2914376, was opened at 20091214 20:20 Message generated for change (Settings changed) made by villate You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2914376&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  Plotting Group: None Status: Closed >Resolution: Fixed Priority: 7 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Jaime E. Villate (villate) Summary: implicit_plot error Initial Comment: On Ubuntu 9.10 (%i1) load(implicit_plot)$ (%i2) implicit_plot (x^2 = y^3  3*y + 1, [x, 4, 4], [y, 4, 4], [gnuplot_preamble, "set zeroaxis"])$ Maxima encountered a Lisp error: EVAL: too few arguments given to GNUPLOTPRINTHEADER: #1=(GNUPLOTPRINTHEADER FILE) Automatically continuing. To enable the Lisp debugger set *debuggerhook* to nil. (%i3) build_info()$ Maxima version: 5.20.1 Maxima build date: 10:1 12/14/2009 Host type: x86_64unknownlinuxgnu Lisp implementation type: CLISP Lisp implementation version: 2.44.1 (20080223) (built on loszerafin [127.0.1.1])  >Comment By: Jaime E. Villate (villate) Date: 20100326 14:09 Message: That bug was fixed shortly after version 5.20.1 was released. The current CVS version of implicit_plot does not give that error. Very soon (when the CVS server starts working again) I will also commit a new version of implicit_plot which is more consistent with plot2d. That means that in future versions you can simply write: implicit_plot (x^2 = y^3  3*y + 1, [x, 4, 4], [y, 4, 4]); and the plot will have x and y axes. If you want to remove those axes you will be able to use the option [axes,false]  Comment By: Jaime E. Villate (villate) Date: 20091215 01:12 Message: This was an error accidentally introduced by me in the latest changes made to plot.lisp. I have just fixed in in the CVS head branch, but this bug remains in versions 5.20.0 and 5.20.1. (If a new minor version 5.20.2 is released, it should have this bug fixed.)  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2914376&group_id=4933 
From: SourceForge.net <noreply@so...>  20100326 13:40:15

Bugs item #2976744, was opened at 20100325 22:44 Message generated for change (Settings changed) made by villate You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2976744&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  Plotting Group: None Status: Open >Resolution: Fixed Priority: 7 Private: No Submitted By: Jaime E. Villate (villate) Assigned to: Jaime E. Villate (villate) Summary: postscript terminal requires manual reset of default termina Initial Comment: Bug reported by Leo Butler in the Users list: When using the gnuplot_pipes plot format, the use of [gnuplot_preamble,"set terminal postscript ...] appears to require that subsequent calls manually reset the terminal to the default.  >Comment By: Jaime E. Villate (villate) Date: 20100326 13:40 Message: This bug has been fixed, but its solution has not been committed to the repository yet because the CVS sever is currently down. It will be committed when the server goes up again. The problem was introduced when the default gnuplot terminal command for Unix systems was changed from "x11" to empty. That was done to allow different installations to use their default terminal, which in most cases is better than "x11" (wxt is much nicer than x11). The change worked fine when the gnuplot format was used, because in that case a new gnuplot session is started for each plot command. However, when the gnuplot_pipes format is used, a plot command does not start a new gnuplot session but instead the plot is sent to an open gnuplot session. When the terminal was changed into postscript and then back to the default terminal, this last step did not change the terminal, leaving it as postscript. To avoid that problem while letting each site use its own default terminal, the default gnuplot terminal command will now be defined as "set term pop", which restores the initial terminal used when gnuplot was started; in fact, it is a good idea to use the same command at Windows sites, anticipating that different Windows versions of gnuplot might have a default terminal different from the "windows" terminal currently used.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2976744&group_id=4933 
From: SourceForge.net <noreply@so...>  20100326 13:04:05

Bugs item #2907727, was opened at 20091202 15:19 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2907727&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: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Incorrect Integral with option integrate_use_rootsof :true Initial Comment: This integral previously crashed maxima, see bug 2906049. Now it gives the wrong answer. integrate_use_rootsof : true; integrate((d*QA^2+2*c*QA+3*b)/(g*QA^3*R+d*QA^2+c*QA+b),QA); yields: lsum(((%r1^2*d+2*%r1*c+3*b)*g*log(QA%r1)*R)/(3*%r1^2*g*R+2*%r1*d+c),%r1,rootsof(g*QA^3*R+d*QA^2+c*QA+b)) but the correct answer is lsum(((%r1^2*d+2*%r1*c+3*b)*log(QA%r1))/(3*%r1^2*g*R+2*%r1*d+c),%r1,rootsof(g*QA^3*R+d*QA^2+c*QA+b)) I'm using Maxima version: 5.20post Maxima build date: 9:7 12/2/2009 Host type: i686pclinuxgnu Lisp implementation type: CLISP Lisp implementation version: 2.44.1 (20080223) (built 3427367244) (memory 3468751644)  >Comment By: Raymond Toy (rtoy) Date: 20100326 09:04 Message: I think multiplying by the leading factor is wrong. I think the algorithm is basically a partial fraction expansion of N(x)/D(x) = sum(A(n)/(xr(n)), n=1,N) where r(n) is a root of D(x). The constant A(n) can be determined by computing limit(N(x)*D(x)/(xr), x, r), but that's basically N(r)*at(diff(D(x),x), [x=r]). The code basically does this, but multiplies by the leading factor.  Comment By: Dieter Kaiser (crategus) Date: 20091202 17:52 Message: I had a look at wolfram alpha and I have got as a reference the following result: integral (d x^2+2 c x+3 b)/(g r x^3+d x^2+c x+b) dx = RootSum[#1^3 g r+#1^2 d+#1 c+b&, (#1^2 d log(x#1)+3 b log(x#1)+2 #1 c log(x#1))/(3 #1^2 g r+2 #1 d+c)&]+constant This corresponds to your solution. Maxima has an extra factor g*r. So, the algorithm now is working, but it seems to be wrong. The extra factor is the leading coefficient of the denominator. This factor is extracted and multiplied into the result by the algorithm. Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2907727&group_id=4933 
From: SourceForge.net <noreply@so...>  20100326 11:44:25

Bugs item #2976378, was opened at 20100325 11:48 Message generated for change (Comment added) made by alex108 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2976378&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  Solving equations Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Joerg (genkides) Assigned to: Nobody/Anonymous (nobody) Summary: Solver doesn't finish Initial Comment: I had the following equation typed into wxMaxima 0.8.4: 2000=1000*1.072^x Then calling the solver: solve([%], [x]) returned two messages: rat: replaced 1.072 by 134/125 = 1.072 [134^x=2*125^x] instead of the solution: log(2)/log(1.072)  Comment By: Aleksas Domarkas (alex108) Date: 20100326 13:44 Message: better solution: (%i1) solve(2000=1000*1.072^x),simp=false; rat: replaced 1.072 by 134/125 = 1.072 (%o1) [x=log(2)/log(134/125)]  Comment By: Barton Willis (willisbl) Date: 20100326 13:28 Message: Setting simp to false is a workaround that will, in general, cause other problems; a better workaround: (%i6) solve(rationalize(2000=1000*1.072^x),x); (%o6) [x=log(2)/log(1206964700135293/1125899906842624)]  Comment By: Aleksas Domarkas (alex108) Date: 20100326 00:19 Message: > simp:false; (%o15) false > eq:2000=1000*1.072^x; (%o16) 2000=1000*1.072^x > solve(eq); rat: replaced 1.072 by 134/125 = 1.072 (%o17) [x=log(2)/log(134/125)]  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2976378&group_id=4933 
From: SourceForge.net <noreply@so...>  20100326 11:28:37

Bugs item #2976378, was opened at 20100325 04:48 Message generated for change (Comment added) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2976378&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  Solving equations Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Joerg (genkides) Assigned to: Nobody/Anonymous (nobody) Summary: Solver doesn't finish Initial Comment: I had the following equation typed into wxMaxima 0.8.4: 2000=1000*1.072^x Then calling the solver: solve([%], [x]) returned two messages: rat: replaced 1.072 by 134/125 = 1.072 [134^x=2*125^x] instead of the solution: log(2)/log(1.072)  >Comment By: Barton Willis (willisbl) Date: 20100326 06:28 Message: Setting simp to false is a workaround that will, in general, cause other problems; a better workaround: (%i6) solve(rationalize(2000=1000*1.072^x),x); (%o6) [x=log(2)/log(1206964700135293/1125899906842624)]  Comment By: Aleksas Domarkas (alex108) Date: 20100325 17:19 Message: > simp:false; (%o15) false > eq:2000=1000*1.072^x; (%o16) 2000=1000*1.072^x > solve(eq); rat: replaced 1.072 by 134/125 = 1.072 (%o17) [x=log(2)/log(134/125)]  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2976378&group_id=4933 
From: SourceForge.net <noreply@so...>  20100326 01:05:24

Bugs item #2843954, was opened at 20090824 20:42 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2843954&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: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: limit of trig expression Initial Comment: (%i55) e : (2*sin(x)*z+cos(x)*sin(2*x)2*cos(x)^2*sin(x))/(z^2+(sin(2*x)^24*sin(x)^2cos(x)^21)*z+sin(2*x)^24*cos(x)*sin(x)*sin(2*x)+4*cos(x)^2*sin(x)^2); (%o55) (2*sin(x)*z+cos(x)*sin(2*x)2*cos(x)^2*sin(x))/(z^2+(sin(2*x)^24*sin(x)^2cos(x)^21)*z+sin(2*x)^24*cos(x)*sin(x)*sin(2*x)+4*cos(x)^2*sin(x)^2) (%i56) limit(e,z,0); (%o56) cos(x)/(sin(2*x)2*cos(x)*sin(x)) Bogus: (%i57) trigexpand(%); Division by 0  an error. To debug this try debugmode(true); OK: (%i58) limit(trigexpand(e),z,0); (%o58) (2*sin(x))/((4*cos(x)^2+4)*sin(x)^2+cos(x)^2+1)  >Comment By: Raymond Toy (rtoy) Date: 20100325 21:05 Message: I think limit basically evaluates the limit of the numerator and denominator. It thinks there are are no problems with either because the terms without z look fine, but, in fact, are exactly zero for all x. Not sure what can be done in this case. I do see that in limitsimp there is a hack to handle sin(x)^2+cos(x)^2. I suppose we could do trigexpand in addition to the hack, but that seems as if it could potentially complicate limit a lot.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2843954&group_id=4933 
From: SourceForge.net <noreply@so...>  20100325 22:44:35

Bugs item #2976744, was opened at 20100325 22:44 Message generated for change (Tracker Item Submitted) made by villate You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2976744&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  Plotting Group: None Status: Open Resolution: None Priority: 7 Private: No Submitted By: Jaime E. Villate (villate) Assigned to: Jaime E. Villate (villate) Summary: postscript terminal requires manual reset of default termina Initial Comment: Bug reported by Leo Butler in the Users list: When using the gnuplot_pipes plot format, the use of [gnuplot_preamble,"set terminal postscript ...] appears to require that subsequent calls manually reset the terminal to the default.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2976744&group_id=4933 
From: SourceForge.net <noreply@so...>  20100325 22:19:12

Bugs item #2976378, was opened at 20100325 11:48 Message generated for change (Comment added) made by alex108 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2976378&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  Solving equations Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Joerg (genkides) Assigned to: Nobody/Anonymous (nobody) Summary: Solver doesn't finish Initial Comment: I had the following equation typed into wxMaxima 0.8.4: 2000=1000*1.072^x Then calling the solver: solve([%], [x]) returned two messages: rat: replaced 1.072 by 134/125 = 1.072 [134^x=2*125^x] instead of the solution: log(2)/log(1.072)  Comment By: Aleksas Domarkas (alex108) Date: 20100326 00:19 Message: > simp:false; (%o15) false > eq:2000=1000*1.072^x; (%o16) 2000=1000*1.072^x > solve(eq); rat: replaced 1.072 by 134/125 = 1.072 (%o17) [x=log(2)/log(134/125)]  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2976378&group_id=4933 
From: SourceForge.net <noreply@so...>  20100325 19:42:12

Bugs item #2976657, was opened at 20100325 20:42 Message generated for change (Tracker Item Submitted) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2976657&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: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Dieter Kaiser (crategus) Assigned to: Nobody/Anonymous (nobody) Summary: Usage of gammagreek and %gammagreek Initial Comment: Maxima uses the different symbols %gammagreek and gammagreek for the same function. In hyp.lisp the symbol %gammagreek is used: (%i1) z^a/a*hgfred([a],[a+1],z); (%o1) %gammagreek(a,z) But in hypgeo.lisp the symbol gammagreek is used: (%i2) assume(s>0,a>0)$ The integrand with %gammagreek does not work: (%i3) specint(%gammagreek(a,t)*exp(s*t),t); (%o3) 'specint(%gammagreek(a,t)*%e^(s*t),t) Now we use the symbol gammagreek: (%i4) specint(gammagreek(a,t)*exp(s*t),t); (%o4) gamma(a+1)*s^(a1)/(a*(1/s+1)^a) I think we should use only the symbol gammagreek. It might be even better to introduce the symbol gamma_greek to be more consistent with the names of other functions related to the gamma function. Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2976657&group_id=4933 
From: SourceForge.net <noreply@so...>  20100325 19:07:48

Bugs item #2924831, was opened at 20100102 03:56 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2924831&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: Andrej Vodopivec (andrejv) Assigned to: Nobody/Anonymous (nobody) Summary: file_type is wrong for ccl on mac os x Initial Comment: clozure cl compiled files have the extension .dx64fls on mac os x. file_type thinks this are demo files since it only checks the first character of the extension. load therefore fails to load compiled files.  >Comment By: Raymond Toy (rtoy) Date: 20100325 15:07 Message: This is fine with me. I'll check it in shortly.  Comment By: Andrej Vodopivec (andrejv) Date: 20100311 03:48 Message: I think we can replace file_type in mload.lisp with (defun $file_type (fil &aux typ) (setq typ ($pathname_type fil)) (cond ((member typ (list "l" "lsp" "lisp") :test #'string=) '$lisp) ((member typ (list "mac" "mc" "demo" "dem" "dm1" "dm2" "dm3" "dmt") :test #'string=) '$maxima) (t '$object)))  Comment By: Raymond Toy (rtoy) Date: 20100204 08:05 Message: Perhaps file_type should be more explicit. So "max", "mac", "dem", and "demo" are maxima files; "l", "lsp", and "lisp" are lisp files, and everything else are object files. Maybe we can also let the user specify the association between the file extension and the file type?  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2924831&group_id=4933 
From: SourceForge.net <noreply@so...>  20100325 13:44:20

Bugs item #2974079, was opened at 20100321 08:45 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2974079&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  Integration Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Integration of sqrt(2*cos(t)+4*sin(t/2)^2+2) Initial Comment: Integration of function is not correct in (0,2*pi)  integrated function is 2^(5/2)*cos(t/2) in: integrate(sqrt(2*cos(t)+4*sin(t/2)^2+2),t); out: 2^(5/2)*cos(t/2) Maxima version: 5.20.1 Maxima build date: 21:25 12/14/2009 Host type: i686pcmingw32 Lisp implementation type: GNU Common Lisp (GCL) Lisp implementation version: GCL 2.6.8 Radim  >Comment By: Raymond Toy (rtoy) Date: 20100325 09:44 Message: This is caused by rischint. I don't know enough about it to say more than that.  Comment By: Aleksas Domarkas (alex108) Date: 20100321 16:27 Message: (%i1) S:'integrate(sqrt(44*cos(t)),t)$ correct: (%i2) factor(S); (%o2) 2*integrate(sqrt(1cos(t)),t) (%i3) ev(%, nouns); (%o3) 2*((sqrt(2)*cos(t)sqrt(2))*sin((t+%pi)/2)+sqrt(2)*sin(t)*cos((t+%pi)/2)) (%i4) trigreduce(%); (%o4) 2^(5/2)*cos(t/2) not correct: (%i5) ev(S, nouns); (%o5) 2^(5/2)*cos(t/2) ???  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2974079&group_id=4933 
From: SourceForge.net <noreply@so...>  20100325 13:32:55

Bugs item #2954472, was opened at 20100218 16:55 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2954472&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: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: rectform with large floats gives bad answer Initial Comment: rectform(1e160/(1e160+%i)) => 0.0 (should be 1.0  1.0e160) We should probably specialcase the float case to give better precision by avoiding underflow.  >Comment By: Raymond Toy (rtoy) Date: 20100325 09:32 Message: This definitely needed to be fixed. That it doesn't work with gcl and ecl is a bug in gcl and ecl. The code basically calls (/ (complex x y)). If this overflows, it's a bug in gcl and ecl. Of course, we can do it portably, and my original version did this. These errors should be reported to gcl and ecl.  Comment By: Dan Gildea (dgildea) Date: 20100325 08:42 Message: This fix does not work with gcl (where rectform(1e160/(1e160+%i)) still gives 0.0) or with ecl (where it gives a floating point overflow lisp error). Bugs like this are hard to fix in a portable way  are they even worth worrying about?  Comment By: Raymond Toy (rtoy) Date: 20100322 19:46 Message: A special case is added to risplitexpt to compute 1/(x+%i*y) carefully. With this change, we now get 1.0  9.99988867182683e161 %i. See rpart.lisp, rev 1.32. Closing bug.  Comment By: Raymond Toy (rtoy) Date: 20100322 16:20 Message: Is this gcl? With cmucl, I get a floatingpoint overflow error. Not good, but better than returning 0.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2954472&group_id=4933 
From: SourceForge.net <noreply@so...>  20100325 12:42:22

Bugs item #2954472, was opened at 20100218 16:55 Message generated for change (Comment added) made by dgildea You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2954472&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: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: rectform with large floats gives bad answer Initial Comment: rectform(1e160/(1e160+%i)) => 0.0 (should be 1.0  1.0e160) We should probably specialcase the float case to give better precision by avoiding underflow.  >Comment By: Dan Gildea (dgildea) Date: 20100325 08:42 Message: This fix does not work with gcl (where rectform(1e160/(1e160+%i)) still gives 0.0) or with ecl (where it gives a floating point overflow lisp error). Bugs like this are hard to fix in a portable way  are they even worth worrying about?  Comment By: Raymond Toy (rtoy) Date: 20100322 19:46 Message: A special case is added to risplitexpt to compute 1/(x+%i*y) carefully. With this change, we now get 1.0  9.99988867182683e161 %i. See rpart.lisp, rev 1.32. Closing bug.  Comment By: Raymond Toy (rtoy) Date: 20100322 16:20 Message: Is this gcl? With cmucl, I get a floatingpoint overflow error. Not good, but better than returning 0.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2954472&group_id=4933 
From: SourceForge.net <noreply@so...>  20100325 11:33:47

Bugs item #2953369, was opened at 20100217 03:56 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2953369&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  Integration Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Definite Integration of 1/(ab*cos(x)) wrong Initial Comment: Maxima 5.20.1 with wxMaxima. integrate(1/(ab*cos(x)),x,0,%pi); where a>0, 0<b<a yields 0.  >Comment By: Raymond Toy (rtoy) Date: 20100325 07:33 Message: dgildea's basic solution checked in. Closing bug.  Comment By: Raymond Toy (rtoy) Date: 20100324 22:05 Message: Yes, that works nicely. Need to make the second lambda also call asksign. And since the question is the same, it's nice to cache the answer from the first lambda.  Comment By: Dan Gildea (dgildea) Date: 20100324 05:32 Message: possible solution: (defun unitcir (grand var) (numden grand) (let ((result (princip (res nn* dn* #'(lambda (pt) (eq (let ((limitp nil)) ($asksign (m+ 1 (cabs pt)))) '$neg)) #'(lambda (pt) (alike1 1 (cabs pt))))))) (cond (result (m* '$%pi result)) (t nil))))  Comment By: Raymond Toy (rtoy) Date: 20100323 08:03 Message: The incorrect result comes from polelist failing to identify the locations of the poles. Since the integrand is even, we can integrate from %pi to %pi (or 0 to 2*%pi) and take half of the result. This integral is converted to the contour integral of 2/(b*yy^22*a*y+b) around the unit circle. This is evaluated by residues. We want to find the poles inside the unit circle and polelist is supposed to do that. The poles are correctly determined, but unfortunately for these poles, polelist cannot find the one pole that is in the circle. Therefore the function res thinks there are no poles in the unit circle and returns 0. When a and b are numbers, polelist does a better job and normally determines the pole that is within the unit circle. Perhaps the function that determines whether the pole is in the unit circle needs to be enhanced?  Comment By: Barton Willis (willisbl) Date: 20100226 01:45 Message: Notice how a float enters into the asksign: (%i4) integrate(1/(1a*cos(x)),x); Is a^21.0 positive or negative?neg; (%o4) (2*atan(((2*a+2)*sin(x))/(2*sqrt(1a^2)*(cos(x)+1))))/sqrt(1a^2)  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2953369&group_id=4933 
From: SourceForge.net <noreply@so...>  20100325 09:48:45

Bugs item #2976378, was opened at 20100325 10:48 Message generated for change (Tracker Item Submitted) made by genkides You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2976378&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  Solving equations Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Joerg (genkides) Assigned to: Nobody/Anonymous (nobody) Summary: Solver doesn't finish Initial Comment: I had the following equation typed into wxMaxima 0.8.4: 2000=1000*1.072^x Then calling the solver: solve([%], [x]) returned two messages: rat: replaced 1.072 by 134/125 = 1.072 [134^x=2*125^x] instead of the solution: log(2)/log(1.072)  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2976378&group_id=4933 
From: SourceForge.net <noreply@so...>  20100325 08:22:03

Bugs item #2976346, was opened at 20100325 08:22 Message generated for change (Tracker Item Submitted) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2976346&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  Taylor Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: taylor expansion bug when mixing floats and rationals Initial Comment: When taylor encounters terms of the same order, one with float coefficient and the other one with rational coefficient, with nonminimal degree, it fails. Example: keepfloat:true; taylor(cos(x) + 1.0*x^2, x, 0, 2); Maxima encountered a Lisp error: Error in MACSYMATOPLEVEL [or a callee]: 1.0 is not of type INTEGER. while taylor(cos(x) + 1.0*x, x, 0, 2) works correctly, since there is no term of order 1 in cos(x), and taylor(cos(x) + 1.0, x, 0, 2) also works correctly.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2976346&group_id=4933 
From: SourceForge.net <noreply@so...>  20100325 02:20:59

Bugs item #2968173, was opened at 20100310 19:25 Message generated for change (Comment added) made by sfrobot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2968173&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: Share Libraries Group: None >Status: Closed Resolution: Invalid Priority: 5 Private: No Submitted By: Richard Hennessy (richardhennessy) Assigned to: Nobody/Anonymous (nobody) Summary: quad_qagi bug Initial Comment: Try (%i1) (gamma_incomplete(6/7,9*x^7)*xgamma_incomplete(1,9*x^7)/9^(1/7))/(7*9^(6/7))$ (%i2) quad_qagi(%,x,0,inf); (%i2) (gamma_incomplete(6/7,9*x^7)*xgamma_incomplete(1,9*x^7)/9^(1/7))/(7*9^(6/7)) ; 7 gamma_incomplete(1, 9 x ) 6 7   gamma_incomplete(, 9 x ) x 1/7 7 9 (out2)  6/7 7 9 (%i3) quad_qagi(%,x,0,inf); gamma_incomplete: continued fractions failed for gamma_incomplete(1.0, 4.3682654441477153E+19). 7 gamma_incomplete(1, 9 x ) 6 7   gamma_incomplete(, 9 x ) x 1/7 7 9 (out3) quad_qagi(, x, 0, inf, epsrel = 1.0E8, epsabs = 0.0, limit = 200) 6/7 7 9 (%i4) bug_report(); The Maxima bug database is available at http://sourceforge.net/tracker/?atid=104933&group_id=4933&func=browse Submit bug reports by following the 'Add new' link on that page. Please include the following information with your bug report:  Maxima version: 5.20.1 Maxima build date: 21:25 12/14/2009 Host type: i686pcmingw32 Lisp implementation type: GNU Common Lisp (GCL) Lisp implementation version: GCL 2.6.8 Rich Hennessy  >Comment By: SourceForge Robot (sfrobot) Date: 20100325 02:20 Message: This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker).  Comment By: Raymond Toy (rtoy) Date: 20100311 00:34 Message: I don't think this is a bug in quad_qagi. Look at the error message that says gamma_incomplete failed to compute the value of gamma_incomplete(1.0, 4.368e19). Marking as pending/invalid. I'll write up another bug report about gamma_incomplete.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2968173&group_id=4933 
From: SourceForge.net <noreply@so...>  20100325 02:05:38

Bugs item #2953369, was opened at 20100217 03:56 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2953369&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  Integration Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Definite Integration of 1/(ab*cos(x)) wrong Initial Comment: Maxima 5.20.1 with wxMaxima. integrate(1/(ab*cos(x)),x,0,%pi); where a>0, 0<b<a yields 0.  >Comment By: Raymond Toy (rtoy) Date: 20100324 22:05 Message: Yes, that works nicely. Need to make the second lambda also call asksign. And since the question is the same, it's nice to cache the answer from the first lambda.  Comment By: Dan Gildea (dgildea) Date: 20100324 05:32 Message: possible solution: (defun unitcir (grand var) (numden grand) (let ((result (princip (res nn* dn* #'(lambda (pt) (eq (let ((limitp nil)) ($asksign (m+ 1 (cabs pt)))) '$neg)) #'(lambda (pt) (alike1 1 (cabs pt))))))) (cond (result (m* '$%pi result)) (t nil))))  Comment By: Raymond Toy (rtoy) Date: 20100323 08:03 Message: The incorrect result comes from polelist failing to identify the locations of the poles. Since the integrand is even, we can integrate from %pi to %pi (or 0 to 2*%pi) and take half of the result. This integral is converted to the contour integral of 2/(b*yy^22*a*y+b) around the unit circle. This is evaluated by residues. We want to find the poles inside the unit circle and polelist is supposed to do that. The poles are correctly determined, but unfortunately for these poles, polelist cannot find the one pole that is in the circle. Therefore the function res thinks there are no poles in the unit circle and returns 0. When a and b are numbers, polelist does a better job and normally determines the pole that is within the unit circle. Perhaps the function that determines whether the pole is in the unit circle needs to be enhanced?  Comment By: Barton Willis (willisbl) Date: 20100226 01:45 Message: Notice how a float enters into the asksign: (%i4) integrate(1/(1a*cos(x)),x); Is a^21.0 positive or negative?neg; (%o4) (2*atan(((2*a+2)*sin(x))/(2*sqrt(1a^2)*(cos(x)+1))))/sqrt(1a^2)  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2953369&group_id=4933 
From: SourceForge.net <noreply@so...>  20100324 20:26:28

Bugs item #2973983, was opened at 20100321 05:28 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2973983&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: Pending >Resolution: Invalid Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: limit givers complex infinity Initial Comment: Try (%i2) limit(a*x^3,x,inf); (%o2) infinity This is a bug. Rich  >Comment By: Dieter Kaiser (crategus) Date: 20100324 21:26 Message: For a positive a we get the limit inf and for a negative a the limit minf: (%i9) assume(a>0)$ (%i10) limit(a*x^2,x,inf); (%o10) inf (%i11) limit(a*x^2,x,inf); (%o11) minf Because the sign of a is not known in the example of this bug report, the result infinity seems to be a consistent answer. Setting the status to pending and the resolution to invalid. Dieter Kaiser  Comment By: Raymond Toy (rtoy) Date: 20100322 16:21 Message: Why is this a bug? a is unknown, so (complex) infinity seems like a reasonable answer.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2973983&group_id=4933 
From: SourceForge.net <noreply@so...>  20100324 20:22:32

Bugs item #2975992, was opened at 20100324 17:14 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2975992&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: Pending >Resolution: Invalid Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: partfrac problem Initial Comment: Maxima cannot solve integrate(1/x(x+4),x), but it's not an integration problem. Maxima can integrate the expression 1/(x^2+4*x) that is the exact same, but before factorisation. To be clear, try those two commands: display(integrate(1/x(x+4),x)); and display(integrate(factor(1/(x^2+4*x)),x));  >Comment By: Dieter Kaiser (crategus) Date: 20100324 21:22 Message: Maxima can solve both integrals and they the results are equal: (%i4) integrate(1/(x*(x+4)),x); (%o4) log(x)/4log(x+4)/4 (%i5) integrate(1/(x^2+4*x),x); (%o5) log(x)/4log(x+4)/4 I think the multiplication operator is missing in the given example. It is 1/(x*(x+4)) and not 1/x(x+4). Setting the status to pending and the resolution to invalid. Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2975992&group_id=4933 
From: SourceForge.net <noreply@so...>  20100324 16:14:02

Bugs item #2975992, was opened at 20100324 16:14 Message generated for change (Tracker Item Submitted) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2975992&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: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: partfrac problem Initial Comment: Maxima cannot solve integrate(1/x(x+4),x), but it's not an integration problem. Maxima can integrate the expression 1/(x^2+4*x) that is the exact same, but before factorisation. To be clear, try those two commands: display(integrate(1/x(x+4),x)); and display(integrate(factor(1/(x^2+4*x)),x));  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2975992&group_id=4933 