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}
(39) 
_{Oct}
(30) 
_{Nov}
(42) 
_{Dec}

S  M  T  W  T  F  S 







1
(1) 
2

3

4

5

6

7
(3) 
8

9

10
(1) 
11
(1) 
12

13

14

15

16
(1) 
17

18
(1) 
19
(1) 
20

21
(4) 
22

23
(3) 
24
(4) 
25
(4) 
26
(3) 
27
(2) 
28
(3) 
29
(1) 
30
(6) 
31
(4) 





From: SourceForge.net <noreply@so...>  20050130 23:04:57

Bugs item #1073338, was opened at 20041125 13:21 Message generated for change (Comment added) made by macrakis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1073338&group_id=4933 Category: Lisp Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Robert Dodier (robert_dodier) Assigned to: Nobody/Anonymous (nobody) Summary: integrate yields incorrect result on rational function Initial Comment: "integrate" yields incorrect results on some rational functions. "Division by 0" is strange. The definite integral below is certainly greater than 0 as the integrand is positive over [0, 1]. "integrate (1/((x3)^4+1/2), x)" returns the noun form, so maybe (maybe) what happens is that the noun form is evaluated at the limits of integration and it's the same, hence 0 is the result. (Just guessing there.) Note that the difference between the two integrands is that one is 1/(something + 1), while the other is 1/(same something + 1/2).  (%i1) integrate (1/((x3)^4+1), x, 0, 1); Division by 0  an error. Quitting. To debug this try DEBUGMODE(TRUE); (%i2) integrate (1/((x3)^4+1/2), x, 0, 1); (%o2) 0 (%i3) build_info (); Maxima version: 5.9.1 Maxima build date: 21:24 9/23/2004 host type: i686pclinuxgnu lispimplementationtype: CMU Common Lisp lispimplementationversion: 19a  Same behavior observed in CVS build of 2004/11/24.  >Comment By: Stavros Macrakis (macrakis) Date: 20050130 18:04 Message: Logged In: YES user_id=588346 This is apparently another GCD problem. Fixed by setting the 'algebraic' flag: integrate (1/((x3)^4+1), x, 0, 1),algebraic:true For the indefinite integral, you can factor over the Gaussians then use partfrac: integrate ( partfrac ( gfactor( 1/((x3)^4+1) ), x ), x ) You can simplify the result using ratsimp(rectform(...)) s  Comment By: Nobody/Anonymous (nobody) Date: 20050118 16:17 Message: Logged In: NO Two remarks: The method that Maxima uses to solve such integrals is integration by residues. Trace (residue) shows that this function is called with the correct arguments but answers zeroes for integrate (1/((x3)^4+1/2), x, 0, 1); and runs into a division by zero for the other integral. The indefinite integrals can be solved with changevar: 'Integrate(1/((x3)^4+1/2), x); changevar (%, x  3  y ,y ,x); ev (%, Integrate);  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1073338&group_id=4933 
From: SourceForge.net <noreply@so...>  20050130 22:44:14

Bugs item #1111390, was opened at 20050128 07:03 Message generated for change (Comment added) made by macrakis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1111390&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: nroots(sqrt(3),minf,inf) & .... Initial Comment: nroots claims that 1 isn't a univariate polynomial, and that sqrt(3) is. This is chaotic. Further, nroots(%pi,minf,inf) > 1, nroots(sqrt(3),minf,inf) > 1. These are both wrong. It's not clear from the documentation, but it seems that nroots does not allow algebraic coefficients; if that's the case, the documentation should say so. Finally, nroots counts multiplicities, but the user documentation doesn't say that it does. (%i1) nroots(1,minf,inf); Argument must be a univariate polynomial  an error. Quitting. To debug this try DEBUGMODE (TRUE); (%i2) nroots(sqrt(3),minf,inf); (%o2) 1 (%i3) nroots(%pi,minf,inf); (%o3) 1 (%i4) nroots(sqrt(3)*x+sqrt(7)); Argument must be a univariate polynomial  an error. Quitting. To debug this try DEBUGMODE (TRUE); (%i14) nroots(x^2,minf,inf); (%o14) 2 One more comment about the documentationit doesn't mention what happends when low > high. (%i18) nroots(x^2,1,1); (%o18)  2 Maxima version: 5.9.1 Maxima build date: 7:34 9/24/2004 host type: i686pcmingw32 lispimplementationtype: Kyoto Common Lisp lispimplementationversion: GCL 2.6.5 Barton  >Comment By: Stavros Macrakis (macrakis) Date: 20050130 17:44 Message: Logged In: YES user_id=588346 Agreed that the univariate polynomial stuff is random. As for excluding algebraic coefficients.... I agree that this should be documented. The method (Sturm sequences) is exact for exact evaluation of polynomials. Exact evaluation is easy for rational coefficients. The result is approximate for approximate coefficients (floats), which is also fine. However, though algebraic numbers are exact, calculating with them exactly is a problem. If this matters to you, I suppose you can use increasingly precise intervals until the signs are unambiguous (though checking for 0 is harder...), but Maxima doesn't currently support interval arithmetic. Anyway, what I would suggest is not changing the documentation, but instead converting algebraic numbers to rationals (at what precision?) and giving the warning: Warning: nroots will not always give exact results with nonrational coefficients Unfortunately, nroots does not currently support bfloats....  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1111390&group_id=4933 
From: SourceForge.net <noreply@so...>  20050130 22:27:00

Bugs item #1045514, was opened at 20041012 11:38 Message generated for change (Comment added) made by macrakis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1045514&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: conjugate(complex) wrong Initial Comment: declare(z,complex) conjugate(z) > z  should be nounform (conjugate loaded from EIGEN)  Comment By: Stavros Macrakis (macrakis) Date: 20050130 17:26 Message: Logged In: YES user_id=588346 I am not sure why you mention lists and matrices  all Maxima functions are supposed to handle those cases (though admittedly they don't all do it). For all *analytic* functions and real variables, the current definition is correct, and often gives far smaller expressions than using rectform would. However, it is incorrect for nonanalytic functions (like carg) and nonreal variables. For that matter, rectform also assumes that functions it doesn't know always have purereal values. Try, for example, realpart(f(%i)) or rp(%i!). It is straightforward enough to write a proper $conjugate function that takes that into account  most of the work would in fact go into establishing the list of analytic functions!: though there is in principle a Maxima feature 'analytic', it is not used at all currently. It is not clear what the right thing to do about unknown functions is. In general, Maxima assumes that functions and variables are realvalued  even if the function arguments are nonreal. We probably don't want rectform(f(x)) for unknown f and x to return 'realpart(f(x)) + 'imagpart(f(x))*%i.... But returning that only if x is known nonreal seems arbitrary, too. Consider realpart(f(x)) => f(x) ... where f turns out to be sqrt.  Comment By: Nobody/Anonymous (nobody) Date: 20050130 17:25 Message: Logged In: NO I am not sure why you mention lists and matrices  all Maxima functions are supposed to handle those cases (though admittedly they don't all do it). For all *analytic* functions and real variables, the current definition is correct, and often gives far smaller expressions than using rectform would. However, it is incorrect for nonanalytic functions (like carg) and nonreal variables. For that matter, rectform also assumes that functions it doesn't know always have purereal values. Try, for example, realpart(f(%i)) or rp(%i!). It is straightforward enough to write a proper $conjugate function that takes that into account  most of the work would in fact go into establishing the list of analytic functions!: though there is in principle a Maxima feature 'analytic', it is not used at all currently. It is not clear what the right thing to do about unknown functions is. In general, Maxima assumes that functions and variables are realvalued  even if the function arguments are nonreal. We probably don't want rectform(f(x)) for unknown f and x to return 'realpart(f(x)) + 'imagpart(f(x))*%i.... But returning that only if x is known nonreal seems arbitrary, too. Consider realpart(f(x)) => f(x) ... where f turns out to be sqrt.  Comment By: Robert Dodier (robert_dodier) Date: 20050129 13:15 Message: Logged In: YES user_id=501686 The defn of conjugate is conjugate(x) := sublis('([%i =  %i]), x)$ which is useful since it can be applied to lists and matrices (among other objects) but it seems too simpleminded. The defn above can yield a wrong answer if its argument is a real function of a complex variable. E.g., conjugate('carg(a+b %i)) yields 'carg (ab %i)  oops. Maybe the right answer is to kill off the existing defn and replace it with conjugate(x) := realpart(x)  %i*imagpart(x)$ ?? realpart and imagpart know about lists and matrices, maybe other objects, so the convenience of the existing defn doesn't seem compelling. Also realpart and imagpart know about carg (as they should).  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1045514&group_id=4933 
From: SourceForge.net <noreply@so...>  20050130 22:25:44

Bugs item #1045514, was opened at 20041012 08:38 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1045514&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: conjugate(complex) wrong Initial Comment: declare(z,complex) conjugate(z) > z  should be nounform (conjugate loaded from EIGEN)  Comment By: Nobody/Anonymous (nobody) Date: 20050130 14:25 Message: Logged In: NO I am not sure why you mention lists and matrices  all Maxima functions are supposed to handle those cases (though admittedly they don't all do it). For all *analytic* functions and real variables, the current definition is correct, and often gives far smaller expressions than using rectform would. However, it is incorrect for nonanalytic functions (like carg) and nonreal variables. For that matter, rectform also assumes that functions it doesn't know always have purereal values. Try, for example, realpart(f(%i)) or rp(%i!). It is straightforward enough to write a proper $conjugate function that takes that into account  most of the work would in fact go into establishing the list of analytic functions!: though there is in principle a Maxima feature 'analytic', it is not used at all currently. It is not clear what the right thing to do about unknown functions is. In general, Maxima assumes that functions and variables are realvalued  even if the function arguments are nonreal. We probably don't want rectform(f(x)) for unknown f and x to return 'realpart(f(x)) + 'imagpart(f(x))*%i.... But returning that only if x is known nonreal seems arbitrary, too. Consider realpart(f(x)) => f(x) ... where f turns out to be sqrt.  Comment By: Robert Dodier (robert_dodier) Date: 20050129 10:15 Message: Logged In: YES user_id=501686 The defn of conjugate is conjugate(x) := sublis('([%i =  %i]), x)$ which is useful since it can be applied to lists and matrices (among other objects) but it seems too simpleminded. The defn above can yield a wrong answer if its argument is a real function of a complex variable. E.g., conjugate('carg(a+b %i)) yields 'carg (ab %i)  oops. Maybe the right answer is to kill off the existing defn and replace it with conjugate(x) := realpart(x)  %i*imagpart(x)$ ?? realpart and imagpart know about lists and matrices, maybe other objects, so the convenience of the existing defn doesn't seem compelling. Also realpart and imagpart know about carg (as they should).  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1045514&group_id=4933 
From: SourceForge.net <noreply@so...>  20050130 12:40:54

Bugs item #1112532, was opened at 20050130 06:40 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=1112532&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: zeta declared posfun Initial Comment: The zeta function is declared to be a positive function (%i70) featurep(zeta,'posfun); (%o70) TRUE This isn't truefor example, zeta(1) = 1/12. The bogus declaration is in the file compar.lisp. Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1112532&group_id=4933 
From: SourceForge.net <noreply@so...>  20050130 11:33:15

Bugs item #1112510, was opened at 20050130 05:33 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=1112510&group_id=4933 Category: Documentation Group: None Status: Open Resolution: None Priority: 2 Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: no user documentation for 'maybe' Initial Comment: There is no user documentation for 'maybe.' At least, 'describe' can't find any. Maxima version: 5.9.1 Maxima build date: 7:34 9/24/2004 host type: i686pcmingw32 lispimplementationtype: Kyoto Common Lisp lispimplementationversion: GCL 2.6.5 Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1112510&group_id=4933 