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
(2) 
2
(13) 
3
(4) 
4

5

6
(1) 
7

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

16

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

29
(4) 

From: SourceForge.net <noreply@so...>  20080225 15:52:13

Bugs item #1748173, was opened at 20070704 22:57 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1748173&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: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Problems with functions with uppercase arguments in solve Initial Comment: solve([FAe(A,B,C,D,Dy,Dz)=0,FBe(A,B,C,D,Dy,Dz)=0,...]); returns an 'unexpected error', while solve([FAe(a,b,c,d,dy,dz)=0,FBe(a,b,c,d,dy,dz)=0,...]); returns the right results For the definition of the functions see the attached file. The functions are defined both with uppercase arguments and lowercase arguments. Then the uppercase and lowercase functions are substracted to see, that they are equal. Then four systems of equations are solved: 1: Uppercase defined functions with uppercase arguments: fail 2: Lowercase defined functions with uppercase arguments: fail 3: Uppercase defined functions with lowercase arguments: succeed 4: Lowercase defined functions with lowercase arguments: succeed System information: Maxima version: 5.12.0 Maxima build date: 19:33 5/3/2007 host type: i686pcmingw32 lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.8  Comment By: Nobody/Anonymous (nobody) Date: 20080225 07:52 Message: Logged In: NO After trying various names (AAA, aaa, FOO1, X1, etc) I believe at this point that the problem is due to ordering of the variables. If Dy and Dz are replaced with something that comes after A, B, C, and D, for example, E and F, then solve is OK. Maybe solve (or allroots which is called by solve) is eliminating variables in order and there is a problem eliminating Dy and/or Dz before the others. If that's the case, it's not clear to me how to make progress here. Trying all possible elimination orderings is out of the question; or is it? Robert Dodier  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1748173&group_id=4933 
From: SourceForge.net <noreply@so...>  20080225 08:08:13

Bugs item #1901199, was opened at 20080225 17:08 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=1901199&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 polynomial that puts factor() into an infinite loop. Initial Comment: Dear Developers of Maxima, I met a polynomial that puts factor() into an infinite loop if subres is used as the gcd algorithm. Please look and see the following log:  [wisdom3:~/work/283:1] adachi% cat infinite_loop.maxima /* * A polynomial that puts factor() into an infinite loop * if subres is used as the gcd algorithm. * If spmod is used as the gcd algorithm, * this polynomial is factorized normally by factor(). */ display2d:false; gcd:subres; X:( 64*l^3  240*l^2  284*l  105 )*n^4 + (128*l^4 + 672*l^3 + 1288*l^2 + 1062*l + 315 )*n^3 + ( 96*l^5  696*l^4  1948*l^3  2631*l^2  1714*l  430 )*n^2 + (64*l^6 + 528*l^5 + 1792*l^4 + 3192*l^3 + 3137*l^2 + 1608*l + 335 )*n  32*l^7  264*l^6  944*l^5  1894*l^4  2294*l^3  1669*l^2  672*l  115; X:expand(X); Y:factor(X); difference:expand(XY); [wisdom3:~/work/283:2] adachi% maxima b infinite_loop.maxima 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(infinite_loop.maxima) batching #p/Volumes/HFS+2/home/adachi/work/283/infinite_loop.maxima (%i2) display2d : false (%o2) false (%i3) gcd:subres (%o3) subres (%i4) X:115672*l1669*l^22294*l^31894*l^4944*l^5264*l^632*l^7 +(335+1608*l+3137*l^2+3192*l^3+1792*l^4+528*l^5+64*l^6)*n +(4301714*l2631*l^21948*l^3696*l^496*l^5)*n^2 +(315+1062*l+1288*l^2+672*l^3+128*l^4)*n^3 +(105284*l240*l^264*l^3)*n^4 (%o4) (64*l^3240*l^2284*l105)*n^4+(128*l^4+672*l^3+1288*l^2+1062*l+315) *n^3 +(96*l^5696*l^41948*l^32631*l^2 1714*l430) *n^2 +(64*l^6+528*l^5+1792*l^4+3192*l^3 +3137*l^2+1608*l+335) *n32*l^7264*l^6944*l^51894*l^4 2294*l^31669*l^2672*l115 (%i5) X:expand(X) (%o5) 64*l^3*n^4240*l^2*n^4284*l*n^4105*n^4+128*l^4*n^3+672*l^3*n^3 +1288*l^2*n^3+1062*l*n^3+315*n^396*l^5*n^2696*l^4*n^2 1948*l^3*n^22631*l^2*n^21714*l*n^2430*n^2+64*l^6*n +528*l^5*n+1792*l^4*n+3192*l^3*n+3137*l^2*n+1608*l*n+335*n 32*l^7264*l^6944*l^51894*l^42294*l^31669*l^2672*l115 (%i6) Y:factor(X) ^CMaxima encountered a Lisp error: Console interrupt.  Here, I have to terminate the program by a console interrupt. (I extracted the above polynomial from an experence that my own library which implements Zeilberger's algorithm did not return. I had waited for one day before judging my program fell into an infinite loop.) If spmod is used as the gcd algorithm (this is the default now), the above polynomial causes no problem as follows:  [wisdom3:~/work/283:3] adachi% cat OK.maxima /* * A polynomial that puts factor() into an infinite loop * if subres is used as the gcd algorithm. * If spmod is used as the gcd algorithm, * this polynomial is factorized normally by factor(). */ display2d:false; gcd:spmod; X:( 64*l^3  240*l^2  284*l  105 )*n^4 + (128*l^4 + 672*l^3 + 1288*l^2 + 1062*l + 315 )*n^3 + ( 96*l^5  696*l^4  1948*l^3  2631*l^2  1714*l  430 )*n^2 + (64*l^6 + 528*l^5 + 1792*l^4 + 3192*l^3 + 3137*l^2 + 1608*l + 335 )*n  32*l^7  264*l^6  944*l^5  1894*l^4  2294*l^3  1669*l^2  672*l  115; X:expand(X); Y:factor(X); difference:expand(XY); [wisdom3:~/work/283:4] adachi% maxima b OK.maxima 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(OK.maxima) batching #p/Volumes/HFS+2/home/adachi/work/283/OK.maxima (%i2) display2d : false (%o2) false (%i3) gcd:spmod (%o3) spmod (%i4) X:115672*l1669*l^22294*l^31894*l^4944*l^5264*l^632*l^7 +(335+1608*l+3137*l^2+3192*l^3+1792*l^4+528*l^5+64*l^6)*n +(4301714*l2631*l^21948*l^3696*l^496*l^5)*n^2 +(315+1062*l+1288*l^2+672*l^3+128*l^4)*n^3 +(105284*l240*l^264*l^3)*n^4 (%o4) (64*l^3240*l^2284*l105)*n^4+(128*l^4+672*l^3+1288*l^2+1062*l+315) *n^3 +(96*l^5696*l^41948*l^32631*l^2 1714*l430) *n^2 +(64*l^6+528*l^5+1792*l^4+3192*l^3 +3137*l^2+1608*l+335) *n32*l^7264*l^6944*l^51894*l^4 2294*l^31669*l^2672*l115 (%i5) X:expand(X) (%o5) 64*l^3*n^4240*l^2*n^4284*l*n^4105*n^4+128*l^4*n^3+672*l^3*n^3 +1288*l^2*n^3+1062*l*n^3+315*n^396*l^5*n^2696*l^4*n^2 1948*l^3*n^22631*l^2*n^21714*l*n^2430*n^2+64*l^6*n +528*l^5*n+1792*l^4*n+3192*l^3*n+3137*l^2*n+1608*l*n+335*n 32*l^7264*l^6944*l^51894*l^42294*l^31669*l^2672*l115 (%i6) Y:factor(X) (%o6) (4*l+5)*(nl1)^2 *(16*l^2*n^2+40*l*n^2+21*n^216*l^2*n40*l*n21*n+8*l^4+40*l^3 +78*l^2+70*l+23) (%i7) difference:expand(XY) (%o7) 0  This computation reuires just several seconds on my iBook. Acoordingly, the problem which I am reporting in this email seems to be related with the algorithm subres. I know that subres is not anymore the default gcd algorithm but spmod is now the the default gcd algorithm. However, if spmod is used as the gcd algorithm, several my programs written in maxima behave incorrectly (I have alrealy reported it). So, I am still using subres to run my programs. In the past, the developer of maxima suggested that the default gcd algorithm would be switched back to subres again in future. If it is so, please fix the bug of subres which is reported here. Thank you very much for developing maxima. Sincerely yours, Satoshi Adachi  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1901199&group_id=4933 
From: SourceForge.net <noreply@so...>  20080225 05:16:07

Bugs item #1814656, was opened at 20071016 13:09 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1814656&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: Fixed Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: imaginary integrand in romberg Initial Comment: This is the error discription: (%i3) romberg(sqrt(1sqrt(x)/3*x), x, 0, 3);Maxima encountered a Lisp error: Error in TRAMP1$M [or a callee]: ((MPLUS SIMP) 5.2388640049375714E17 ((MTIMES SIMP) 0.85559967716735219 $%I)) is not of type (OR RATIONAL LISP:FLOAT).Automatically continuing.To reenable the Lisp debugger set *debuggerhook* to nil.  >Comment By: Robert Dodier (robert_dodier) Date: 20080224 22:16 Message: Logged In: YES user_id=501686 Originator: NO Forgot to actually close this report. Hope I got it right this time.  Comment By: Robert Dodier (robert_dodier) Date: 20080202 19:13 Message: Logged In: YES user_id=501686 Originator: NO r1.8 share/numeric/romberg.lisp binds *PLOTREALPART* to NIL so that the constructed integrand function returns a complex result (instead of silently returning only the real part). Now romberg(sqrt(1sqrt(x)/3*x), x, 0, 3); => romberg expression, since the integrand returns a nonnumeric value within the limits of integration. Closing this report as fixed.  Comment By: Robert Dodier (robert_dodier) Date: 20080120 23:09 Message: Logged In: YES user_id=501686 Originator: NO The error cited in the original report ("Error in TRAMP1$M") doesn't happen anymore because romberg is now an ordinary DEFUN. (The TRAMPFOO stuff was an idiosyncratic evaluation scheme.) As noted by Ray, now romberg(sqrt(1sqrt(x)/3*x), x, 0, 3); => 1.53754250... even though the integrand is imaginary for x > 3^(2/3). romberg calls COERCEFLOATFUN to construct the integrand function and the constructed function calls MAYBEREALPART which observes the special variable *PLOTREALPART*; when *PLOTREALPART* is T, MAYBEREALPART returns 0, otherwise NIL. So the constructed integrand treats this integrand as 0 in the range (3^(2/3), 3). If I set *PLOTREALPART* to NIL I get an unevaluated romberg expression (romberg doesn't attempt to compute a numeric result if the constructed integrand function returns a nonnumber). Probably romberg should bind *PLOTREALPART* to NIL before calling the integrand function. Probably *PLOTREALPART* should also be renamed since it is significant outside of the plotting code (for which it was originally devised).  Comment By: Raymond Toy (rtoy) Date: 20071217 10:54 Message: Logged In: YES user_id=28849 Originator: NO This error doesn't seem to occur anymore with 5.13.99rc1. It returns the result 1.537542508725151, which is approximately the value of integrate(sqrt(1sqrt(x)/3*x),x,0,3^(2/3)) > 2*3^(2/3)*beta(2/3,3/2)/3 > 1.537544212176236. Since the integrand is complex over some parts of the integration range, romberg should say something about that.  Comment By: Raymond Toy (rtoy) Date: 20071017 06:52 Message: Logged In: YES user_id=28849 Originator: NO Evaluate the integrand at x = 3. I get sqrt(1sqrt(3)), which is definitely not real. Maxima shouldn't give an error for this, but I'm not sure what exactly it should do.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1814656&group_id=4933 