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}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 

1
(3) 
2
(6) 
3
(3) 
4
(2) 
5
(2) 
6
(6) 
7
(2) 
8

9
(1) 
10
(1) 
11
(2) 
12

13
(1) 
14
(2) 
15
(17) 
16
(5) 
17
(2) 
18
(4) 
19

20
(1) 
21

22
(22) 
23
(5) 
24

25

26
(1) 
27

28
(4) 
29
(1) 
30






From: SourceForge.net <noreply@so...>  20080606 18:23:41

Bugs item #1986726, was opened at 20080606 12:22 Message generated for change (Settings changed) made by npowell You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1986726&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: Nathan Powell (npowell) Assigned to: Nobody/Anonymous (nobody) >Summary: Integrating f(x) with limits after resetting throws an error Initial Comment: /*wxMaxima 0.7.5 http://wxmaxima.sourceforge.netMaxima 5.15.0 http://maxima.sourceforge.netUsing Lisp GNU Common Lisp (GCL) GCL 2.6.8 (aka 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(f(x),x,a,b); (%o1) integrate(f(x),x,a,b) (%i2) reset(); (%o1) [lispdisp,linenum,%,current,trunique,rhs,lhs,nobjects,+labs,algdelta,_,__,context] (%i2) integrate(f(x),x,a,b); Maxima encountered a Lisp error: Error in MACSYMATOPLEVEL [or a callee]: NIL is not of type INTEGER.Automatically continuing.To reenable the Lisp debugger set *debuggerhook* to nil. (%i3) This happens if both versions 5.15 and 5.14 The reason this is important to me is that I'm writing a program which needs to call reset() a lot between calculations (so that the calculations don't have the possibility of interferring with each other). Thanks!  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1986726&group_id=4933 
From: SourceForge.net <noreply@so...>  20080606 18:22:21

Bugs item #1986726, was opened at 20080606 12:22 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=1986726&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: Nathan Powell (npowell) Assigned to: Nobody/Anonymous (nobody) Summary: Integrating f(x) with limits after calling throws Lisp Error Initial Comment: /*wxMaxima 0.7.5 http://wxmaxima.sourceforge.netMaxima 5.15.0 http://maxima.sourceforge.netUsing Lisp GNU Common Lisp (GCL) GCL 2.6.8 (aka 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(f(x),x,a,b); (%o1) integrate(f(x),x,a,b) (%i2) reset(); (%o1) [lispdisp,linenum,%,current,trunique,rhs,lhs,nobjects,+labs,algdelta,_,__,context] (%i2) integrate(f(x),x,a,b); Maxima encountered a Lisp error: Error in MACSYMATOPLEVEL [or a callee]: NIL is not of type INTEGER.Automatically continuing.To reenable the Lisp debugger set *debuggerhook* to nil. (%i3) This happens if both versions 5.15 and 5.14 The reason this is important to me is that I'm writing a program which needs to call reset() a lot between calculations (so that the calculations don't have the possibility of interferring with each other). Thanks!  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1986726&group_id=4933 
From: SourceForge.net <noreply@so...>  20080605 19:35:22

Bugs item #1985748, was opened at 20080605 15:35 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=1985748&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: Viktor Toth (vttoth) Assigned to: Nobody/Anonymous (nobody) Summary: array and scalar declarations yield inconsistent results Initial Comment: The following example speaks for itself: (%i1) scalarp(x); (%o1) false (%i2) scalarp(x[1]); (%o2) false (%i3) declare(x,scalar); (%o3) done (%i4) scalarp(x); (%o4) true (%i5) scalarp(x[1]); (%o5) true (%i6) array(x,5); (%o6) x (%i7) scalarp(x); (%o7) false (%i8) scalarp(x[1]); (%o8) false (%i9) declare(x,scalar); (%o9) done (%i10) scalarp(x); (%o10) false (%i11) scalarp(x[1]); (%o11) false (%i12) nonscalarp(x); (%o12) true I do believe that this is an unwanted side effect of array() that should probably be fixed. The problem seems to be specific to scalar/scalarp, for instance it doesn't affect constant/constantp.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1985748&group_id=4933 
From: SourceForge.net <noreply@so...>  20080605 01:32:05

Bugs item #1984464, was opened at 20080604 07:59 Message generated for change (Settings changed) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1984464&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: Documentation Group: None Status: Open Resolution: None >Priority: 3 Private: No Submitted By: Nobody/Anonymous (nobody) >Assigned to: Barton Willis (willisbl) Summary: No documentation for topoly or topoly_solver Initial Comment: The packages topoly and topoly_solver have no documentation. In <http://www.math.utexas.edu/pipermail/maxima/2008/011921.html>;, Barton Willis suggested reporting this as a bug and volunteered to be the assignee. Thank you very much for that, Barton. I'll appear as anonymous, but I'm Dan Hatton <vi5u0maxima@...>.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1984464&group_id=4933 
From: SourceForge.net <noreply@so...>  20080604 12:59:44

Bugs item #1984464, was opened at 20080604 05:59 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=1984464&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: Documentation Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: No documentation for topoly or topoly_solver Initial Comment: The packages topoly and topoly_solver have no documentation. In <http://www.math.utexas.edu/pipermail/maxima/2008/011921.html>;, Barton Willis suggested reporting this as a bug and volunteered to be the assignee. Thank you very much for that, Barton. I'll appear as anonymous, but I'm Dan Hatton <vi5u0maxima@...>.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1984464&group_id=4933 
From: SourceForge.net <noreply@so...>  20080604 11:20:05

Bugs item #1981623, was opened at 20080601 22:39 Message generated for change (Comment added) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1981623&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: Satoshi Adachi (satoshi_adachi) Assigned to: Nobody/Anonymous (nobody) Summary: wrong sign of sqrt() Initial Comment: Dear Developers of Maxima, I found that sqrt() returns the incorrect expression that has the sign opposite to the ture expression when some certain argument is given to sqrt(). Namely, sqrt() interprets incorrectly the database that is prepared by assume(). Here is an demonstration program:  /* * wrong_sign_of_sqrt.maxima * * S.Adachi 2008/06/01 */ display2d:false; assume(x >= 0, x <= 1); correct_result_1:sqrt((x1)^2); correct_result_2:sqrt(1/(x1)^2); correct_result_3:sqrt(a*(x1)^2); incorrect_result_1:sqrt(a/(x1)^2); incorrect_result_2:sqrt(a^2/(x1)^2); incorrect_result_3:sqrt(x^2/(x1)^2); /* END */  The result of execution is as follows:  Maxima 5.14.0cvs http://maxima.sourceforge.net Using Lisp GNU Common Lisp (GCL) GCL 2.6.7 (aka 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) batch(wrong_sign_of_sqrt.maxima) batching #p/Volumes/HFS+2/home/adachi/work/299/wrong_sign_of_sqrt.maxima (%i2) display2d : false (%o2) false (%i3) assume(x >= 0,x <= 1) (%o3) [x >= 0,x <= 1] (%i4) correct_result_1:sqrt((x1)^2) (%o4) 1x (%i5) correct_result_2:sqrt(1/(x1)^2) (%o5) 1/(1x) (%i6) correct_result_3:sqrt(a*(x1)^2) (%o6) sqrt(a)*(1x) (%i7) incorrect_result_1:sqrt(a/(x1)^2) (%o7) sqrt(a)/(x1) (%i8) incorrect_result_2:sqrt(a^2/(x1)^2) (%o8) abs(a)/(x1) (%i9) incorrect_result_3:sqrt(x^2/(x1)^2) (%o9) x/(x1) (%o10) "wrong_sign_of_sqrt.maxima"  I wonder why sqrt() returns the wrong expression if sqrt((x1)^2) appears in the denominator of some fraction in the argument that is more complex than some threshold (e.g. the numerator is not a simple number or something like that). I think that this is a very severe bug of sqrt() and the database that is prepared by assume(). This bug puts many user programs to the state producing many wrong results. Please fix this severe bug. Sincerely yours, Satoshi Adachi  >Comment By: Barton Willis (willisbl) Date: 20080604 06:20 Message: Logged In: YES user_id=895922 Originator: NO As a workaround, you might try setting radexpand to false: (%i1) assume(0 < x, x <= 1)$ (%i2) sqrt(a/(x1)^2); (%o2) sqrt(a)/(x1) (%i3) sqrt(a/(x1)^2), radexpand : false; (%o3) sqrt(a/(x1)^2)  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1981623&group_id=4933 
From: SourceForge.net <noreply@so...>  20080603 04:14:16

Bugs item #1947806, was opened at 20080421 07:02 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1947806&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: Documentation Group: Includes proposed fix >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Ed Beroset (beroset) Assigned to: Nobody/Anonymous (nobody) Summary: ilt documented variable order incorrect Initial Comment: In maxima/maxima/doc/info/Integration.texi, line 186 currently reads: @deffn {Function} ilt (@var{expr}, @var{t}, @var{s}) However, as the example below correctly shows, the variables t and s should be reversed, and the line should read: @deffn {Function} ilt (@var{expr}, @var{s}, @var{t})  >Comment By: Robert Dodier (robert_dodier) Date: 20080602 22:14 Message: Logged In: YES user_id=501686 Originator: NO Resolved by r1.38 doc/info/Integration.texi. Closing this report as fixed. Thanks for pointing out this error.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1947806&group_id=4933 
From: SourceForge.net <noreply@so...>  20080603 03:58:47

Bugs item #1963314, was opened at 20080513 13:35 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1963314&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: Wont Fix Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Fresnel integral  function romberg error. Initial Comment: Maxima 5.14.0 Linux and 5.15.0 Windows. Fresnel integral: http://en.wikipedia.org/wiki/Fresnel_integral http://upload.wikimedia.org/wikipedia/commons/thumb/8/8f/Fresnel_Integrals_%28Normalised%29.svg/250pxFresnel_Integrals_%28Normalised%29.svg.png Maxima command: for i:1 thru 10 do display(romberg(sin(%pi/2*(x^2)),x,0,i)); .... romberg(sin((%pi*x^2)/2),x,0,7)=0.49970480390049 romberg(sin((%pi*x^2)/2),x,0,8)=1.0449974219284286*10^14 romberg(sin((%pi*x^2)/2),x,0,9)=0.49986104588168 also romberg(cos((%pi*x^2)/2),x,0,7)=0.54546705790348 romberg(cos((%pi*x^2)/2),x,0,8)=8.0 romberg(cos((%pi*x^2)/2),x,0,9)=0.53536612585252 in point x=8 is error. Thx  >Comment By: Robert Dodier (robert_dodier) Date: 20080602 21:58 Message: Logged In: YES user_id=501686 Originator: NO Closing this report as "won't fix" per earlier comment.  Comment By: Robert Dodier (robert_dodier) Date: 20080513 18:32 Message: Logged In: YES user_id=501686 Originator: NO Changing status back to open so it appears in the default browsing mode.  Comment By: Robert Dodier (robert_dodier) Date: 20080513 18:30 Message: Logged In: YES user_id=501686 Originator: NO romberg is easily fooled by oscillatory integrands: it evaluates the integrand at a few points and sees that they are the same, so it thinks the integrand is constant. Much better to use the Quadpack functions, namely quad_qags, etc. ?? quad at the input prompt should find them. You can fiddle with some parameters to make romberg succeed on this problem (?? romberg finds them), but romberg is just not a very strong algorithm; use quad_qags or some other Quadpack function instead. Marking this report as "won't fix"; the romberg function is a correct implementation of Romberg's method. Instead of closing it, I'll leave it pending, so it stays open for a while in case the original poster comes back. Note: please log in so that annotations on bug reports are automatically sent to you.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1963314&group_id=4933 
From: SourceForge.net <noreply@so...>  20080603 03:56:46

Bugs item #1981518, was opened at 20080601 16:10 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1981518&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: 6 Private: No Submitted By: Alexey Beshenov (beshenov) Assigned to: Nobody/Anonymous (nobody) Summary: Calling desolve inside a "for...do" makes it loop endlessly Initial Comment: In 5.14.0 (CLISP 2.41) calling desolve inside a "for...do" block makes it loop endlessly. (%i1) for i : 1 thru 3 do (print(i)); 1 2 3 (%o1) done (%i2) for i : 1 thru 3 do (desolve('diff(foo(x),x)=1,foo(x)), print(i)); 1 1 1 ... Seems to happen with CLISP and SBCL, but not with GCL and CMUCL. Actually, the problem is related to ilt which is called by desolve. http://www.math.utexas.edu/pipermail/maxima/2008/011592.html  >Comment By: Robert Dodier (robert_dodier) Date: 20080602 21:56 Message: Logged In: YES user_id=501686 Originator: NO Resolved by r1.65 src/mlisp.lisp which renames VAR in MDO and MDOIN to avoid name collision with special variable of same name. Closing this report as fixed.  Comment By: Robert Dodier (robert_dodier) Date: 20080601 23:25 Message: Logged In: YES user_id=501686 Originator: NO Looks like MDO in src/mlisp.lisp uses a variable (VAR) which is declared special and clobbered by some function called from ilt. Changing the name from VAR to MYVAR avoids the name collision. I'll commit a patch in a day or two.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1981518&group_id=4933 
From: SourceForge.net <noreply@so...>  20080602 05:25:32

Bugs item #1981518, was opened at 20080601 16:10 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1981518&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: 6 Private: No Submitted By: Alexey Beshenov (beshenov) Assigned to: Nobody/Anonymous (nobody) Summary: Calling desolve inside a "for...do" makes it loop endlessly Initial Comment: In 5.14.0 (CLISP 2.41) calling desolve inside a "for...do" block makes it loop endlessly. (%i1) for i : 1 thru 3 do (print(i)); 1 2 3 (%o1) done (%i2) for i : 1 thru 3 do (desolve('diff(foo(x),x)=1,foo(x)), print(i)); 1 1 1 ... Seems to happen with CLISP and SBCL, but not with GCL and CMUCL. Actually, the problem is related to ilt which is called by desolve. http://www.math.utexas.edu/pipermail/maxima/2008/011592.html  >Comment By: Robert Dodier (robert_dodier) Date: 20080601 23:25 Message: Logged In: YES user_id=501686 Originator: NO Looks like MDO in src/mlisp.lisp uses a variable (VAR) which is declared special and clobbered by some function called from ilt. Changing the name from VAR to MYVAR avoids the name collision. I'll commit a patch in a day or two.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1981518&group_id=4933 
From: SourceForge.net <noreply@so...>  20080602 04:46:58

Bugs item #1913067, was opened at 20080312 22:06 Message generated for change (Comment added) made by robertmarik You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1913067&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: Ximin Luo (infinity0x) Assigned to: Nobody/Anonymous (nobody) Summary: Cannot integrate 1/(1+x^n) Initial Comment: Maxima cannot integrate functions of the form 1/(1+x^n) for n >= 7. Mathematica is capable of this. Maxima attempts the integration via an algorithm which seems to involve taking partial fractions. For example, if you try to integrate 1/(1+x^7) for example, Maxima gives: log(1+x)/7  integral(x^52*x^4+3*x^34*x^2+5*x6)/(x^6x^5+x^4x^3+x^2x+1) / 7 I'm guessing a different algorithm (such as that employed by Mathematica) is required to give a fully symbolic answer. For the record, the integral(1/(1+x^7)) is: Log[1 + x]/7  (Cos[Pi/7]*Log[1 + x^2  2*x*Cos[Pi/7]])/7  (Cos[(3*Pi)/7]*Log[1 + x^2  2*x*Cos[(3*Pi)/7]])/7  (Cos[(5*Pi)/7]*Log[1 + x^2  2*x*Cos[(5*Pi)/7]])/7 + (2*ArcTan[(x  Cos[Pi/7])*Csc[Pi/7]]* Sin[Pi/7])/7 + (2*ArcTan[(x  Cos[(3*Pi)/7])* Csc[(3*Pi)/7]]*Sin[(3*Pi)/7])/7 + (2*ArcTan[(x  Cos[(5*Pi)/7])* Csc[(5*Pi)/7]]*Sin[(5*Pi)/7])/7  Additionally, this also means that we can calculate the integral(that nasty rational function), by calculating 7 * ( log(1+x)/7  integral(1/(1+x^7)) ) As a side note, Mathematica also cannot give integral(that nasty rational function) fully symbolically. Instead, it gives: RootSum[1  #1 + #1^2  #1^3 + #1^4  #1^5 + #1^6 & , (6*Log[x  #1] + 5*Log[x  #1]*#1  4*Log[x  #1]*#1^2 + 3*Log[x  #1]* #1^3  2*Log[x  #1]*#1^4 + Log[x  #1]*#1^5)/(1 + 2*#1  3*#1^2 + 4*#1^3  5*#1^4 + 6*#1^5) & ] where RootSum[ f, form ] represents the sum of form[x] for all x that satisfy the polynomial equation f[x] == 0.  Comment By: Robert Marik (robertmarik) Date: 20080602 06:46 Message: Logged In: YES user_id=2033662 Originator: NO This could be a similar problem (copied from Maxima discussion list) Hello all, Maxima fails to evaluate integral of 1/(x^4+3*x^2+1). Answers to this problem on Maxima list include:  BTW Maxima is able to factor x4+3*x2+1. To factor a polynomial over the Gaussian integers, use "gfactor" instead of "factor": gfactor(x4+3*x2+1) => (x2%i*x+1)*(x2+%i*x+1) itegrate doesn't handle 1/(x4+3*x2+1), but it does handle 1/gfactor(x4+3*x2+1).  Probably the integration code should be replaced. The commercial Macsyma does the integral, which is kind of a mess, but if you ev(%,numer) you get 0.72361 * atan(1.61804 * x)  0.27639 * atan(0.61803 * x)  The Horowitz method (1969) gives the rational part of the antiderivative of a rational function. The method for the logarithmic part is due to Trager (1976), I think. The residue method (at least for definite integration of rational functions) that Maxima might be using seems to be due to Wang (circa 1974). Maybe Maxima isn't using the best methods for rational function integration?  Comment By: Raymond Toy (rtoy) Date: 20080317 16:19 Message: Logged In: YES user_id=28849 Originator: NO By handcomputed, I mean someone wrote out the expansion of x^6+1 as (x^2+1)*(x^2+sqrt(3)*x+1)*(x^2sqrt(3)*x+1). I'm not sure maxima can figure that out itself. For the general case x^n+c, we would need to write that as a product of quadratics (and maybe a linear term). Easy to do since we know the roots are, more or less, the n roots of unity. I think the results will be pretty ugly for n >= 7.  Comment By: Raymond Toy (rtoy) Date: 20080317 16:19 Message: Logged In: YES user_id=28849 Originator: NO By handcomputed, I mean someone wrote out the expansion of x^6+1 as (x^2+1)*(x^2+sqrt(3)*x+1)*(x^2sqrt(3)*x+1). I'm not sure maxima can figure that out itself. For the general case x^n+c, we would need to write that as a product of quadratics (and maybe a linear term). Easy to do since we know the roots are, more or less, the n roots of unity. I think the results will be pretty ugly for n >= 7.  Comment By: Ximin Luo (infinity0x) Date: 20080317 15:27 Message: Logged In: YES user_id=2003896 Originator: YES i don't know how to integrate these without knowing the roots of the equation; i thought mathematica was, because it could integrate 1/(1+x^n) without being able to integrate (that nasty rational function). (and i thought algorithms do to this would be available somewhere else.) also, i assumed maxima was already factorising the equation for arbitrarily large values of n. but your approach seems feasible. what do you mean by handcomputed though? as in, numerically instead of algebraically? wouldn't that give imprecise answers?  Comment By: Raymond Toy (rtoy) Date: 20080317 14:37 Message: Logged In: YES user_id=28849 Originator: NO If you can, please describe how to integrate these without knowing the roots of the equation. FWIW, maxima has a special function to integrate functions of the form f(x)/(a*x^n+b). (See enprog and eprog in sinint.lisp.) It only handles the cases of n = 4, 5, 6. And it does this by essentially doing a partial fraction expansion with handcomputed quadratic factors. It seems feasible to extend this to any n.  Comment By: Raymond Toy (rtoy) Date: 20080317 14:37 Message: Logged In: YES user_id=28849 Originator: NO If you can, please describe how to integrate these without knowing the roots of the equation. FWIW, maxima has a special function to integrate functions of the form f(x)/(a*x^n+b). (See enprog and eprog in sinint.lisp.) It only handles the cases of n = 4, 5, 6. And it does this by essentially doing a partial fraction expansion with handcomputed quadratic factors. It seems feasible to extend this to any n.  Comment By: Raymond Toy (rtoy) Date: 20080317 14:37 Message: Logged In: YES user_id=28849 Originator: NO If you can, please describe how to integrate these without knowing the roots of the equation. FWIW, maxima has a special function to integrate functions of the form f(x)/(a*x^n+b). (See enprog and eprog in sinint.lisp.) It only handles the cases of n = 4, 5, 6. And it does this by essentially doing a partial fraction expansion with handcomputed quadratic factors. It seems feasible to extend this to any n.  Comment By: Raymond Toy (rtoy) Date: 20080313 01:30 Message: Logged In: YES user_id=28849 Originator: NO Actually, the roots are obviously the seven roots of 1, which maxima does know, and it could have done the partial fraction expansion to find the value of the integral. Not sure how or where to teach maxima about this, though. Some thought needed.  Comment By: Ximin Luo (infinity0x) Date: 20080312 23:32 Message: Logged In: YES user_id=2003896 Originator: YES The point is that Maxima does not NEED to know the roots of that equation. Sorry for making this unclear. By doing the integral using a different algorithm which doesn't involve taking partial fractions, you can avoid the above, and get a purely symbolic integral, like Mathematic does.  Comment By: Raymond Toy (rtoy) Date: 20080312 23:16 Message: Logged In: YES user_id=28849 Originator: NO Maxima can't give an answer because it doesn't know the roots of (x^7+1)/(x+1). If you set integrate_use_rootsof:true, then maxima can return an answer, but unless you can compute the roots of the above equation, it's probably not very helpful.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1913067&group_id=4933 
From: SourceForge.net <noreply@so...>  20080602 03:45:42

Bugs item #1981628, was opened at 20080602 12:45 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=1981628&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: Satoshi Adachi (satoshi_adachi) Assigned to: Nobody/Anonymous (nobody) Summary: a bug of radcan() and radexpand Initial Comment: Dear Developers of Maxima, radcan() does not behave in the correct way. In the online desription of radcan() with the correction of a misprint, which is informed in a separate report by me, it is written that  Function: radcan (<expr>) ... ... When `radexpand' is `false', certain transformations are inhibited. `radcan (sqrt (1x))' remains `sqrt (1x)' and is not simplified to `%i sqrt (x1)'. `radcan (sqrt (x^2  2*x + 1))' remains `sqrt (x^2  2*x + 1)' and is not simplified to `x  1'. ... ... The control by the variable `radexpand' does not work in the present Maxima. A demonstration program is as follows:  /* * a_bug_of_radcan.maxima: * * S.Adachi 2008/06/01 */ display2d:false; radexpand; /* Inspect the value of `radexpand' */ radcan(sqrt(x^22*x+1)); /* expected to reduce to x1 */ radexpand:false; radcan(sqrt(x^22*x+1)); /* expected to remain sqrt(x^22*x+1) */ /* END */  The result of execution is as follows:  Maxima 5.14.0cvs http://maxima.sourceforge.net Using Lisp GNU Common Lisp (GCL) GCL 2.6.7 (aka 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) batch(a_bug_of_radcan.maxima) batching #p/Volumes/HFS+2/home/adachi/work/301/a_bug_of_radcan.maxima (%i2) display2d : false (%o2) false (%i3) radexpand (%o3) true (%i4) radcan(sqrt(12*x+x^2)) (%o4) x1 (%i5) radexpand:false (%o5) false (%i6) radcan(sqrt(12*x+x^2)) (%o6) x1 (%o7) "a_bug_of_radcan.maxima"  If `radexpand' is `false', `radcan(sqrt(x^22*x+1))' is expected to remain `sqrt(x^22*x+1)'. However, Maxima returns `x1' in reality. This is a bug. I think that this is a very serious bug of radcan(). Please fix it. Sincerely yours, Satoshi Adachi  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1981628&group_id=4933 
From: SourceForge.net <noreply@so...>  20080602 03:44:08

Bugs item #1981626, was opened at 20080602 12:44 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=1981626&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: Satoshi Adachi (satoshi_adachi) Assigned to: Nobody/Anonymous (nobody) Summary: a misprint about radcan() in the manual Initial Comment: Dear Developers of Maxima, I found a misprint in the description of radcan() in Maxima manual (both of pdf and online versions). This part of the description of radcan() in Maxima 5.14.0cvs is as follows:  [Macintosh:/tmp:1] adachi% maxima batchstring='? radcan' Maxima 5.14.0cvs http://maxima.sourceforge.net Using Lisp GNU Common Lisp (GCL) GCL 2.6.7 (aka 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) describe(radcan, exact)  Function: radcan (<expr>) ... ... When `radexpand' is `false', certain transformations are inhibited. `radcan (sqrt (1x))' remains `sqrt (1x)' and is not simplified to `%i sqrt (x1)'. `radcan (sqrt (x^2  2*x + 11))' remains `sqrt (x^2  2*x + 1)' and is not simplified to `x  1'. ... ...  The misprint is as follows: WRONG: `radcan (sqrt (x^2  2*x + 11))' remains `sqrt (x^2  2*x + 1)' ... CORRECT: `radcan (sqrt (x^2  2*x + 1))' remains `sqrt (x^2  2*x + 1)' ... I inspected the corresponding description in an old manual "Macsyma Mathematics and System Refercen Manual" (16th Edition) published by Macsyma, Inc. in 1996. On p.37 in this Macsyma manual, it is written as radexpand default: true When set to false, this option variable inhibits certain transformations: ... ; and radcan(sqrt(x^22+1)) remains sqrt(x^2+2x+1) and is not transformed to x1. ... Clearly, the above description in Maxima manual comes from this part in the old Macsyma manual. So, I think that the misprint is confirmed. Please correct the misprint. Sincerely yours, Satoshi Adachi P.S. Furthermore, radcan() does not work as is described in the corrected manual. This is a bug of radcan(). I will report this bug in a separate report.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1981626&group_id=4933 
From: SourceForge.net <noreply@so...>  20080602 03:40:00

Bugs item #1981623, was opened at 20080602 12:39 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=1981623&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: Satoshi Adachi (satoshi_adachi) Assigned to: Nobody/Anonymous (nobody) Summary: wrong sign of sqrt() Initial Comment: Dear Developers of Maxima, I found that sqrt() returns the incorrect expression that has the sign opposite to the ture expression when some certain argument is given to sqrt(). Namely, sqrt() interprets incorrectly the database that is prepared by assume(). Here is an demonstration program:  /* * wrong_sign_of_sqrt.maxima * * S.Adachi 2008/06/01 */ display2d:false; assume(x >= 0, x <= 1); correct_result_1:sqrt((x1)^2); correct_result_2:sqrt(1/(x1)^2); correct_result_3:sqrt(a*(x1)^2); incorrect_result_1:sqrt(a/(x1)^2); incorrect_result_2:sqrt(a^2/(x1)^2); incorrect_result_3:sqrt(x^2/(x1)^2); /* END */  The result of execution is as follows:  Maxima 5.14.0cvs http://maxima.sourceforge.net Using Lisp GNU Common Lisp (GCL) GCL 2.6.7 (aka 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) batch(wrong_sign_of_sqrt.maxima) batching #p/Volumes/HFS+2/home/adachi/work/299/wrong_sign_of_sqrt.maxima (%i2) display2d : false (%o2) false (%i3) assume(x >= 0,x <= 1) (%o3) [x >= 0,x <= 1] (%i4) correct_result_1:sqrt((x1)^2) (%o4) 1x (%i5) correct_result_2:sqrt(1/(x1)^2) (%o5) 1/(1x) (%i6) correct_result_3:sqrt(a*(x1)^2) (%o6) sqrt(a)*(1x) (%i7) incorrect_result_1:sqrt(a/(x1)^2) (%o7) sqrt(a)/(x1) (%i8) incorrect_result_2:sqrt(a^2/(x1)^2) (%o8) abs(a)/(x1) (%i9) incorrect_result_3:sqrt(x^2/(x1)^2) (%o9) x/(x1) (%o10) "wrong_sign_of_sqrt.maxima"  I wonder why sqrt() returns the wrong expression if sqrt((x1)^2) appears in the denominator of some fraction in the argument that is more complex than some threshold (e.g. the numerator is not a simple number or something like that). I think that this is a very severe bug of sqrt() and the database that is prepared by assume(). This bug puts many user programs to the state producing many wrong results. Please fix this severe bug. Sincerely yours, Satoshi Adachi  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1981623&group_id=4933 
From: SourceForge.net <noreply@so...>  20080602 02:28:14

Bugs item #1980715, was opened at 20080531 11:39 Message generated for change (Comment added) made by dgildea You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1980715&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: 5 Private: No Submitted By: Nobody/Anonymous (nobody) >Assigned to: Dan Gildea (dgildea) Summary: wrong radcansimplification Initial Comment: Maxima version: 5.13.0 Maxima build date: 9:20 12/12/2007 host type: i686pclinuxgnu lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.8 radcan(3^(1/6)*9^(1/3)); sqrt(3) and that ist wrong! helfried.kravanja@...  >Comment By: Dan Gildea (dgildea) Date: 20080601 22:28 Message: Logged In: YES user_id=1797506 Originator: NO fixed in src/nrat4.lisp revision 1.17: o spc5: was losing denominator in building gcdlist (%i2) radcan(3^(1/6)*9^(1/3)); (%o2) 3^(5/6) (%i3) radcan(81^(1/5)*9^(1/3)); (%o3) 3*3^(7/15)  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1980715&group_id=4933 
From: SourceForge.net <noreply@so...>  20080601 22:10:31

Bugs item #1981518, was opened at 20080602 02:10 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=1981518&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  Differential eqns Group: None Status: Open Resolution: None Priority: 6 Private: No Submitted By: Alexey Beshenov (beshenov) Assigned to: Nobody/Anonymous (nobody) Summary: Calling desolve inside a "for...do" makes it loop endlessly Initial Comment: In 5.14.0 (CLISP 2.41) calling desolve inside a "for...do" block makes it loop endlessly. (%i1) for i : 1 thru 3 do (print(i)); 1 2 3 (%o1) done (%i2) for i : 1 thru 3 do (desolve('diff(foo(x),x)=1,foo(x)), print(i)); 1 1 1 ... Seems to happen with CLISP and SBCL, but not with GCL and CMUCL. Actually, the problem is related to ilt which is called by desolve. http://www.math.utexas.edu/pipermail/maxima/2008/011592.html  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1981518&group_id=4933 
From: SourceForge.net <noreply@so...>  20080601 22:00:43

Bugs item #1961009, was opened at 20080509 16:57 Message generated for change (Settings changed) made by beshenov You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1961009&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: Documentation Group: None >Status: Deleted Resolution: None Priority: 4 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: Maxima web page Initial Comment: "...arbitrary precision integers, and arbitrarily precision floating point numbers." Change this to something like "...arbitrary precision integers, and variable precision floating point numbers."  Comment By: Alexey Beshenov (beshenov) Date: 20080602 01:57 Message: Logged In: YES user_id=1498309 Originator: NO Thanks. Fixed.  Comment By: Alexey Beshenov (beshenov) Date: 20080602 01:57 Message: Logged In: YES user_id=1498309 Originator: NO The reported bug is not present in the current cvs version of Maxima. Thank you for your report. If you see this bug in a later version of Maxima, please submit a new bug report.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1961009&group_id=4933 
From: SourceForge.net <noreply@so...>  20080601 21:57:19

Bugs item #1961009, was opened at 20080509 16:57 Message generated for change (Comment added) made by beshenov You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1961009&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: Documentation Group: None >Status: Closed Resolution: None Priority: 4 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: Maxima web page Initial Comment: "...arbitrary precision integers, and arbitrarily precision floating point numbers." Change this to something like "...arbitrary precision integers, and variable precision floating point numbers."  >Comment By: Alexey Beshenov (beshenov) Date: 20080602 01:57 Message: Logged In: YES user_id=1498309 Originator: NO Thanks. Fixed.  Comment By: Alexey Beshenov (beshenov) Date: 20080602 01:57 Message: Logged In: YES user_id=1498309 Originator: NO The reported bug is not present in the current cvs version of Maxima. Thank you for your report. If you see this bug in a later version of Maxima, please submit a new bug report.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1961009&group_id=4933 