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}
(19) 
_{May}
(14) 
_{Jun}
(21) 
_{Jul}
(30) 
_{Aug}
(48) 
_{Sep}
(36) 
_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 





1
(4) 
2
(5) 
3
(9) 
4
(11) 
5
(3) 
6
(1) 
7

8

9
(4) 
10
(5) 
11

12

13
(3) 
14
(8) 
15
(2) 
16

17
(2) 
18
(4) 
19
(1) 
20
(1) 
21
(1) 
22

23

24
(5) 
25
(1) 
26
(3) 
27
(2) 
28
(3) 
29
(1) 
30
(1) 
31
(2) 
From: SourceForge.net <noreply@so...>  20100710 15:54:22

Bugs item #1794673, was opened at 20070914 14:03 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1794673&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: Works For Me Priority: 2 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: bffac & pquotient by zero Initial Comment: Bug: (%i77) bffac(4,5); `pquotient' by zero OK: (%i78) bffac(4,6); (%o78) 2.4b1 Both bffac(4.0,5) and bffac(4.0b0,5) are OK.  >Comment By: Dieter Kaiser (crategus) Date: 20100710 17:54 Message: The problem is no longer present with the current CVS version 5.21post of Maxima: (%i1) bffac(4,5); (%o1) 2.4b1 Closing this bug report as "works for me". Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1794673&group_id=4933 
From: SourceForge.net <noreply@so...>  20100710 15:40:48

Bugs item #1046653, was opened at 20041014 00:36 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1046653&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: Fixed Priority: 5 Private: No Submitted By: Abdulhaq Lynch (abdulhaq) Assigned to: Nobody/Anonymous (nobody) Summary: input prompt appearing when it should not Initial Comment: on entering e.g. integrate(,x); the input prompt appears 3 times instead of once. This is a problem for external interfaces. Thanks.  >Comment By: Dieter Kaiser (crategus) Date: 20100710 17:40 Message: Fixed in nparese.lisp revision 1.59. As suggested we do the test (eql *parsestream* *standardinput*). Closing this bug report as fixed. Dieter Kaiser  Comment By: Dieter Kaiser (crategus) Date: 20100523 17:53 Message: In mreadsynerr in the file nparse.lisp we have the following check (outputstreamp *standardinput*) If T Maxima prints the *parsewindow*, marks the place where the input error had occurred and flushes the rest of the input line. I think this test is not correct at this place, because it only checks the Lisp specific implementation of the stream *standardinput*. For GCL we get always T and for SBCL we get always NIL for this test. Because of this mreadsynerr does not print the *parsewindow* and does not flush the input line. We get the following: (%i1) integrate(,x); incorrect syntax: , is not a prefix operator (%i1) incorrect syntax: Too many )'s (%i1) incorrect syntax: Premature termination of input at ;. (%i1) sin a+b); incorrect syntax: A is not an infix operator (%i1) incorrect syntax: Too many )'s (%i1) incorrect syntax: Premature termination of input at ;. (%i1) sin(a+b; incorrect syntax: Missing ) I think we have to ask if we are reading from the *standardinput*. For this case we print out the *parsewindow* on the *standardoutput*. This could be the test (eql *parsestream* *standardinput*) With this change we get for SBCL the expected behavior too: (%i2) integrate(,x); incorrect syntax: , is not a prefix operator integrate(, ^ (%i2) sin a+b); incorrect syntax: A is not an infix operator sin a+ ^ (%i2) sin(a+b; incorrect syntax: Missing ) sin(a+b; ^ Dieter Kaiser  Comment By: Robert Dodier (robert_dodier) Date: 20060909 07:21 Message: Logged In: YES user_id=501686 (1) I've succeeded in reproducing the bug. It appears in SBCL and CMUCL but not GCL or Clisp (all Linux) so far as I can tell. Apparently parsing and/or error handling works differently depending on the Lisp implementation. Rats. (2) I'm entirely in agreement with the comments about the need for a programmatic interface. If the original poster has further comments on this topic, I would be interested to hear about it. Maxima sessions: Maxima 5.9.3cvs / SBCL 0.9.9: (%i1) integrate(,x); Incorrect syntax: , is not a prefix operator (%i1) Incorrect syntax: Too many )'s (%i1) Incorrect syntax: Premature termination of input at ;. (%i1) Maxima 5.9.1 / CMUCL 19a: (%i1) integrate(,x); Incorrect syntax: , is not a prefix operator integrate(, ^ (%i1) Incorrect syntax: Too many )'s x) ^ (%i1) Incorrect syntax: Premature termination of input at ;. ; ^ (%i1) Maxima 5.9.3cvs / Clisp 2.38 (exact same result for Maxima 5.9.3cvs / GCL 2.6.7): (%i1) integrate(,x); Incorrect syntax: , is not a prefix operator integrate(, ^ (%i1)  Comment By: aalynch (aalynch) Date: 20060731 12:02 Message: Logged In: YES user_id=1289744 it seems that it has been fixed. I'm working on a front endfor maxima (Kayali) and the underlying problem is that the interface is not suitable for machinemachine communication (it was after all designed for humanmachine interation). We (xmaxima, wxMaxima, whatever) really need an interface tailored for being used programmatically e.g.(in pythonesque pcode) result, errorcode, extrainfo = submit(equation) without needing to parse input/output prompts etc.  Comment By: Robert Dodier (robert_dodier) Date: 20060731 06:18 Message: Logged In: YES user_id=501686 Not sure what the problem is here. It would help to report the build_info() output and also to show a session log (just cutnpaste whatever Maxima prints out).  Comment By: Abdulhaq Lynch (abdulhaq) Date: 20041015 18:03 Message: Logged In: YES user_id=182792 unfortunately no as the problem is: when do I stop listening to Maxima i.e. when do I stop waiting for more output? To verify that the prompts are the same you have to wait to see if the second or third prompt does actually come  i.e. the problem is knowing when to wait. If we set the timeout large then it's annoying for the user and if it's too small then the communication gets messed up entirely.  Comment By: Stavros Macrakis (macrakis) Date: 20041014 16:05 Message: Logged In: YES user_id=588346 Note that the inputline number (e.g. %i34) is the same each time. Does that help in parsing Maxima's output? Of course, it would be better if there were a clean socket API where all these things were made explicit.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1046653&group_id=4933 
From: SourceForge.net <noreply@so...>  20100710 15:29:10

Bugs item #2834169, was opened at 20090808 15:58 Message generated for change (Settings changed) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2834169&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: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: JeanYves (jyoberle) Assigned to: Nobody/Anonymous (nobody) Summary: Wrong solution with sqrt/asin equation solving Initial Comment: I noticed that when using latest version of Maxima: solve(1(asin(x^21))^2,x) gives [x=sqrt(1sin(1)),x=sqrt(1sin(1)),x=sqrt(sin(1)+1),x=sqrt(sin(1)+1)] which is correct. But: solve(sqrt(1(asin(x^21))^2),x) gives [] whereas I would have expected same solutions as above. Below are details about the Maxima version:  Maxima version: 5.18.1 Maxima build date: 20:57 4/19/2009 host type: i686pcmingw32 lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.8  Best regards, JeanYves  >Comment By: Dieter Kaiser (crategus) Date: 20100710 17:29 Message: This problem is no longer present. We get for both examples: (%i2) solve((1(asin(x^21))^2),x); (%o2) [x = sqrt(1sin(1)),x = sqrt(1sin(1)),x = sqrt(sin(1)+1), x = sqrt(sin(1)+1)] (%i3) solve(sqrt(1(asin(x^21))^2),x); (%o3) [x = sqrt(1sin(1)),x = sqrt(1sin(1)),x = sqrt(sin(1)+1), x = sqrt(sin(1)+1)] I think this is because of revision 1.26 of solve.lisp. The algorithm has been improved to compare simplified expressions. Closing this bug report as fixed. Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2834169&group_id=4933 
From: SourceForge.net <noreply@so...>  20100710 14:31:42

Bugs item #2996542, was opened at 20100504 14:38 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2996542&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: akalinin (aleckalinin) Assigned to: Nobody/Anonymous (nobody) Summary: log(x) integration is incorrect Initial Comment: Correct behaviour in previous verison: wxMaxima 0.8.4, Maxima 5.20.1: integrate(log(x), x, 0, a) > a log(a) a Incorrect behaviour in current version: wxMaxima 0.8.5, Maxima 5.21.0: integrate(log(x), x, 0, a) > gamma_incomplete(2,log(a))  >Comment By: Dieter Kaiser (crategus) Date: 20100710 16:31 Message: Fixed in defint.lisp revision 1.78. As suggested the option variable $gamma_expand has been bound to TRUE when calling logx1 in the routine dintlog. Closing this bug report as fixed. Dieter Kaiser  Comment By: Dieter Kaiser (crategus) Date: 20100523 22:15 Message: Some more examples of integrals which have changed. In general the following type of integral: integrate(log(x)^n, x, 0, a); where n is a positive integer has changed. Some examples: (%i1) assume(a>0)$ (%i2) integrate(log(x)^2,x,0,a); (%o2) gamma_incomplete(3,log(a)) (%i3) integrate(log(x)^2,x,0,a),gamma_expand:true; (%o3) a*log(a)^22*a*log(a)+2*a (%i4) integrate(log(x)^3,x,0,a); (%o4) gamma_incomplete(4,log(a)) (%i5) integrate(log(x)^3,x,0,a),gamma_expand:true; (%o5) a*log(a)^33*a*log(a)^2+6*a*log(a)6*a (%i6) integrate(log(x)^4,x,0,a); (%o6) gamma_incomplete(5,log(a)) (%i7) integrate(log(x)^4,x,0,a),gamma_expand:true; (%o7) a*log(a)^44*a*log(a)^3+12*a*log(a)^224*a*log(a)+24*a But we have also new integrals which do not work in Maxima 5.20. These are of the type integrate(log(x)^(n/2), x, 0, a); where n is an integer. Some examples are: (%i8) integrate(log(x)^(1/2),x,0,a); (%o8) %i*gamma_incomplete(3/2,log(a)) (%i9) integrate(log(x)^(1/2),x,0,a),gamma_expand:true; (%o9) (sqrt(%pi)*%i*erfc(sqrt(log(a)))+2*%i*a*sqrt(log(a)))/2 (%i10) integrate(log(x)^(3/2),x,0,a); (%o10) %i*(3*sqrt(%pi)*erf(sqrt(log(a)))/4 a*sqrt(log(a))*log(a)+3*a*sqrt(log(a))/2+3*sqrt(%pi)/4) (%i11) integrate(log(x)^(5/2),x,0,a); (%o11) %i*gamma_incomplete(7/2,log(a)) (%i12) integrate(log(x)^(5/2),x,0,a),gamma_expand:true; (%o12) (15*sqrt(%pi)*%i*erfc(sqrt(log(a))) +sqrt(log(a))*(8*%i*a*log(a)^220*%i*a*log(a)+30*%i*a)) /8 So the best seems to be as suggested to bind the flag $gamma_expand to T. We get the change for gamma(k1+1) because the Gamma function uses the flag $gamma_expand too. Perhaps, we should introduce a second flag $gamma_incomplete_expand to have the possibility to get a more specific expansion of the Incomplete Gamma function. Dieter Kaiser  Comment By: Raymond Toy (rtoy) Date: 20100520 01:35 Message: One possible solution. In dintlog, bind $gamma_expand to T when calling logx1. Then maxima returns a*log(a)a. However, this change causes 90 in rtestint to fail. The result is k1*gamma(k1) instead of gamma(1+k1).  Comment By: Raymond Toy (rtoy) Date: 20100518 05:31 Message: You are correct. Looks like the issue comes from dintlog. In 5.19.2, the antideriv was tried first, then logx1. In 5.21, logx1 is tried first, then antideriv. I do not know which is better. The commit message says the change helps remove the limit from some integrals. But it makes this particular integral not as nice.  Comment By: Dieter Kaiser (crategus) Date: 20100518 00:20 Message: We have the new algorithm of defintlogexp since Maxima 5.19. But the behavior for the log function has changed between 5.20 and 5.21. Therefore, I think it is not the algorithm of defintlogexp which has changed the integral of the log function, but some code which has been introduced later. Dieter Kaiser  Comment By: Raymond Toy (rtoy) Date: 20100517 22:01 Message: The new result comes from the new routine defintlogexp, which is called relatively early in defint. Perhaps it should be called later? I have not investigated this aspect yet.  Comment By: Dieter Kaiser (crategus) Date: 20100504 15:08 Message: Yes, the result has changed between Maxima 5.21 and 5.20. I do not know the reason at this time, but the new result is not really wrong. It simplifies to the old result with the flag gamma_expand: (%i1) assume(a>0)$ (%i2) integrate(log(x),x,0,a),gamma_expand:true; (%o2) a*log(a)a Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2996542&group_id=4933 
From: SourceForge.net <noreply@so...>  20100710 14:08:52

Bugs item #3006875, was opened at 20100525 15:55 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3006875&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: akalinin (aleckalinin) Assigned to: Nobody/Anonymous (nobody) Summary: ldefint() integration seems to be not correct Initial Comment: The ldefint() integration seems to be not correct. I compared Maxima results with Maple results. I tried to integrate "Lambda^4 / (Lambda^2 + a1 * epsilon * Lambda + epsilon^2)^(5/2);" function and I got three strange results in Maxima: 1. Too many terms in sum after integration. 2. Some terms have strange "false" factor in numerator. 3. Several terms have the singularity 1/epsilon, epsilon > 0. The Maple integration produces less terms and no 1/epsilon singularity. Please, see attachments for details. I put the Maxima "false" strange term and singular term in double bar.  >Comment By: Dieter Kaiser (crategus) Date: 20100710 16:08 Message: It is easier to see the problem of this bug report, when we reduce the problem to the following integrand: x^4 * (a*x^2 + b*x + c)^(5/2) When we assume a>0, b>0, c>0 and b^24*a*c>0 and try to get the integral integrate(x^4*(a*x^2+b*x+x)^(5/2), x) we get a wrong answer which includes a term 9*false. We can further simplify the example and set a=1. Then we have the integrand x^4 * (x^2 + b*x +c)^(5/2) When we assume again b>0, c>0, and b^24*c>0 then we get a wrong answer too (%i1) assume(b>0,c>0,b^24*c>0)$ (%i2) integrate(x^4*(x^2+b*x+c)^(5/2),x); (%o2) 7*false+log(2*sqrt(x^2+b*x+c)+2*x+b) +x*(32*b*c*x/(3*(4*cb^2)^2*sqrt(x^2+b*x+c)) +2*b*(4*c+b^2)*x/(3*(4*cb^2)^2*sqrt(x^2+b*x+c)) 16*b^2*c/(3*(4*cb^2)^2*sqrt(x^2+b*x+c)) +b^2*(4*c+b^2)/(3*(4*cb^2)^2*sqrt(x^2+b*x+c)) x^2/(x^2+b*x+c)^(3/2)2*b*c*x/((4*cb^2)*(x^2+b*x+c)^(3/2)) +b^3*x/(3*(4*cb^2)*(x^2+b*x+c)^(3/2)) b^2*c/(3*(4*cb^2)*(x^2+b*x+c)^(3/2)) 2*c/(3*(x^2+b*x+c)^(3/2))) 4*c*x/(3*(4*cb^2)*sqrt(x^2+b*x+c)) +2*b^2*x/((4*cb^2)*sqrt(x^2+b*x+c)) +10*b*c/(3*(4*cb^2)*sqrt(x^2+b*x+c)) For this case we get an answer with a term 7*false. The problem occurs in the routine INTIRA in the file irinte.lisp. This routine detects correctly a integration problem of the type (1) d*p(x)*x^m*(a*x^2+b*x+x)^n I have not analyzed the integration process in detail, but the algorithm produces a list of subproblems which are passed again to the routine INTIRA. For our example from above, the algorithm founds 7 subproblems. Furthermore, the algorithm assumes that all subproblems are again of the type (1) and have a solution. But the routine INTIRA does not return a solution, the answer for this subproblems is false. These false terms are added up. I think the problem is, that the expression which are passed again to the routine INTIRA are of the type (1), but the routine INTIRA does not recognize it. The following expression is one of the seven subproblems INTIRA has to solve: b^3*x/(12*c*(x^2+b*x+c)^(3/2)3*b^2*(x^2+b*x+c)^(3/2)) It is difficult to see in linear display, but this expression is of the type INTIRA can solve, but INTIRA does not match it, because the root (x^2+b*x+c)^(3/2) is distributed over two terms. To see that INTIRA in principle can solve the problem we can rewrite the expression from above the following way b^3*(12*c3*b^2)^1 * x * (x^2+b*x+c)^(3/2) The problem is that the root is distributed over the constant term (12*c3*b^2)^1 It might be difficult to solve this problem in general, but at least, the algorithm should recognize that a subproblem was not solved. A correct answer would be a noun form for the integral for this case. Dieter Kaiser  Comment By: akalinin (aleckalinin) Date: 20100526 12:42 Message: Some additional information. I tried to use integrate(...) instead of ldefint(...) and got the incorrect results. The coefficient a1 change the behavior of the integral:  Maxima script  logexpand : all; logarc : true; assume(epsilon > 0); assume(a1 > 0); assume(a1  2.0 > 0); kern1 : Lambda^4 / (Lambda^2 + epsilon * Lambda + epsilon^2 )^(5/2); kern2 : Lambda^4 / (Lambda^2 + a1 * epsilon * Lambda + epsilon^2)^(5/2); phi1 : integrate(kern1, Lambda); phi2 : integrate(kern2, Lambda); phi2 : subst(a1 = 1, phi2); res : phi2  phi1;  The res is not zero!  Comment By: akalinin (aleckalinin) Date: 20100526 10:22 Message: Thanks for comments. Version of maxima: Maxima version: 5.21.0 Maxima build date: 8:38 4/12/2010 Host type: i686pcmingw32 Lisp implementation type: GNU Common Lisp (GCL) Lisp implementation version: GCL 2.6.8 About the divergence. It should be log(epsilon) but not 1/epsilon. And after integration I manually separate this log(epsilon) term. Without a1 coefficient Maxima works correct, see maximaresults2.pdf and maximascript2.mac in attachment. In this case both Maxima and Maple produces the same results. But when the a1 term is present, Maxima produces 1/epsilon divergence. I think this is not right, because a1 term cannot change the behavior of the integral.  Comment By: l_butler () Date: 20100525 22:34 Message: Hi, Thanks for the report. A few comments: 1. Rather than using expand, try ratsimp. This produces a relatively compact expression. 2. I can confirm there is a bug in Maxima's integral with v5.21.1: false appears as a term. When a1=0, this term disappears. 3. If you look at your integrand, when epsilon=0 (a1 is irrelevant), you are computing the integral of 1/x from 0 to QL, which diverges. From that, one expects that the integral will have a singularity at epsilon=0. If Maple doesn't produce such a result, this is a bug in Maple. Please report your version of Maxima when filing a bug report. Just copy the output of the 'build_info' command into your report.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3006875&group_id=4933 