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}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 

1
(2) 
2
(6) 
3
(7) 
4
(2) 
5
(9) 
6
(14) 
7
(10) 
8
(6) 
9
(12) 
10
(1) 
11
(4) 
12
(9) 
13
(5) 
14
(18) 
15

16
(3) 
17
(3) 
18
(3) 
19
(1) 
20
(2) 
21
(5) 
22
(14) 
23
(2) 
24
(5) 
25
(1) 
26

27
(4) 
28
(8) 
29
(17) 
30
(8) 





From: SourceForge.net <noreply@so...>  20091105 23:33:36

Bugs item #840360, was opened at 20031112 00:28 Message generated for change (Settings changed) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=840360&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: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: qunit(4) internal errors Initial Comment: qunit of a square, e.g. qunit(4), gives the internal error "Floatingpoint exception." It should either give a friendly Maxima error, or possibly return 1  isn't the "quadratic" number field of sqrt(n^2) simply the rationals? qunit(2) goes into an infinite loop. It should give an error, since we're dealing with *real* quadratic number fields, but wouldn't it be nice if...  >Comment By: Dieter Kaiser (crategus) Date: 20091106 00:33 Message: Adding a check in combin.lisp revision 1.39: the argument must be a positive non quadratic integer. Closing this bug report as fixed. Dieter Kaiser  Comment By: Robert Dodier (robert_dodier) Date: 20060713 07:25 Message: Logged In: YES user_id=501686 Bugs still present: qunit(4) => division by zero for 5.9.3cvs / gcl 2.6.7, sbcl 0.9.9, clisp 2.38. qunit(2) => infinite loop (same combos).  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=840360&group_id=4933 
From: SourceForge.net <noreply@so...>  20091105 22:59:00

Bugs item #706455, was opened at 20030319 20:19 Message generated for change (Settings changed) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=706455&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: Martin Rubey (kratt5) Assigned to: Nobody/Anonymous (nobody) Summary: Should powerseries do Laurent expansions? Initial Comment: (C43) powerseries((1/x+x)^n,x,0); (D43) (x^2+1)^n/x^n It is not clear whether powerseries is supposed to return Taylor series expansions only or also Laurent type expansions. If it doesn't, the doc should say so. Martin  >Comment By: Dieter Kaiser (crategus) Date: 20091105 23:58 Message: The definition of the powerseries used for the expansion has been added to the documentation in Series.texi revision 1.21. It is not a Laurent series. Closing the bug report as fixed. Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=706455&group_id=4933 
From: SourceForge.net <noreply@so...>  20091105 22:33:18

Bugs item #2889126, was opened at 20091030 00:29 Message generated for change (Settings changed) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2889126&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: Dieter Kaiser (crategus) Assigned to: Nobody/Anonymous (nobody) Summary: Numerical evaluation of Bessel functions inconsistent Initial Comment: The numerical evaluation of the Bessel functions is not implemented consistently. These expressions evaluate numerically as expected: (%i28) bessel_j(1,0.5); (%o28) .2422684576748739 (%i29) bessel_j(1,0.5+%i); (%o29) .5124137767280906 %i + .3392601907198862 (%i30) bessel_j(0.5,%i); (%o30) .6630362720267232 %i + .6630362720267233 But these expressions should evaluate numerically too: (%i33) bessel_j(1/2,0.5); (%o33) bessel_j(1/2,0.5) (%i34) bessel_j(1,0.5+1/2*%i); (%o34) bessel_j(1,%i/2+0.5) (%i35) bessel_j(0.5,0.5+1/2*%i); (%o35) bessel_j(0.5,%i/2+0.5) The convention is, that the function evaluates numerically if all arguments are numbers (including Maxima rationals and bigfloats) and at least one of the numbers is a float or a bigfloat or the flag $numer is TRUE. The problem is that the function besselnumericalevalp does not count Maxima rationals as numbers. We have the function floatnumericalevalp and friends, which check more carefully if a function should be evaluated numerically. With the help of these functions we can implement the numerical evaluation of the Bessel functions more consistent. Dieter Kaiser  >Comment By: Dieter Kaiser (crategus) Date: 20091105 23:33 Message: Fixed in bessel.lisp revision 1.76. All given now example evaluate numerically. Closing this bug report as fixed. Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2889126&group_id=4933 
From: SourceForge.net <noreply@so...>  20091105 21:58:37

Bugs item #627759, was opened at 20021023 23:17 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=627759&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: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: Ratdisrep of aggregates Initial Comment: ratdisrep(rat(x=y)) leaves x=y as a rat, and this is visible to the user: /R/ x=y Internally, it is actually rat(x)=rat(y), and ratdisrep does not look inside the "=" operator. Similarly, ratdisrep(rat([x])) and ratdisrep(rat(matrix([a]))) do not do any ratdisrep'ing within the toplevel operator. Though of course it is possible to Map or Scanmap Ratdisrep across the expressions, it is confusing for the user that Ratdisrep does not undo the effect of Rat. So Ratdisrep should have the same conventions as Rat. If Rat(x=y) "goes inside" the equality to convert x and y to rats, then similarly Ratdisrep should.  >Comment By: Dieter Kaiser (crategus) Date: 20091105 22:58 Message: As suggested ratdisrep is changed in rat3e.lisp revision 1.26. It distributes over lists, equations, and matrices. Closing this bug report as fixed. Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=627759&group_id=4933 
From: SourceForge.net <noreply@so...>  20091105 17:55:40

Bugs item #2880797, was opened at 20091016 18:27 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2880797&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: Robert Marik (robertmarik) Assigned to: Nobody/Anonymous (nobody) Summary: bad answer in integrate(sqrt(sin(t)^2+cos(t)^2),t,0,2*%pi) Initial Comment: integrate(sqrt(sin(t)^2+cos(t)^2),t,0,2*%pi) returns %pi but the result is 2*%pi The Maxima bug database is available at http://sourceforge.net/tracker/?atid=104933&group_id=4933&func=browse Submit bug reports by following the 'Add new artifact' link on that page. Please include the following build information with your bug report:  Maxima version: 5.19.1 Maxima build date: 1:42 10/16/2009 host type: i686pclinuxgnu lispimplementationtype: ECL lispimplementationversion: 9.8.4  The above information is also available from the Maxima function build_info(). this bug is not in 5.13 reported at http://groups.google.cz/group/sagedevel/t/f82e24efdfe23b07 Robert Marik  >Comment By: Raymond Toy (rtoy) Date: 20091105 12:55 Message: This looks like a good solution. But is it too broad? Are there cases in trigint where triginverses set to $all would be wrong? Maybe a more careful solution that only sets it when we use the tan(x/2) substitution would be better? I couldn't see any cases where it would produce incorrect results.  Comment By: Andrej Vodopivec (andrejv) Date: 20091017 17:45 Message: The problem comes from (%i1) integrate(sqrt(sin(x)^2+cos(x)^2), x); (%o1) atan(tan(x)) This integral is done with substitution (tan(x/2)) and we need to make sure that atan(tan(x))=x when we backsubstitute. Here is a simple patch which fixes the problem: Index: sin.lisp =================================================================== RCS file: /cvsroot/maxima/maxima/src/sin.lisp,v retrieving revision 1.51 diff u r1.51 sin.lisp  sin.lisp 18 Aug 2009 16:59:37 0000 1.51 +++ sin.lisp 17 Oct 2009 21:33:54 0000 @@ 1503,7 +1503,7 @@ getout (setq y (list '(mtimes) *yy* *yz*)) get2 (setq y (simplify y))  (return (substint repl 'x (integrator y 'x))))) + (return (let (($triginverses '$all)) (substint repl 'x (integrator y 'x)))))) (defmvar $integration_constant_counter 0) (defmvar $integration_constant '$%c)  Comment By: Dieter Kaiser (crategus) Date: 20091016 18:57 Message: Perhaps this bug is not a new problem. The answer of Maxima depends on the flag triginversers. (%i36) integrate(sqrt(sin(t)^2+cos(t)^2),t,0,2*%pi),triginverses:true; (%o36) %pi (%i37) integrate(sqrt(sin(t)^2+cos(t)^2),t,0,2*%pi),triginverses:all; (%o37) 2 %pi The default value of triginverses has changed with revision 1.33 of trigi.lisp from 'all to 'true. The bug was not visible in the past with the standard value 'all of triginverses. Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2880797&group_id=4933 
From: SourceForge.net <noreply@so...>  20091105 17:26:54

Bugs item #2892737, was opened at 20091105 20:26 Message generated for change (Tracker Item Submitted) made by f0ma You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2892737&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: f0ma (f0ma) Assigned to: Nobody/Anonymous (nobody) Summary: Maxima crashes on solve, integrate and some other operation Initial Comment: eg: solve(x^2+5*x+2=0,x); integrate(x**(5/2)/sqrt(x+2), x, 1, 2); integrate((x+1)/(x^38),x); integrate((4*x)^(1/2),x); Bug reproduce on Maxima 5.17.1 from ubuntu 9.10 package and maxima 5.19.2 from source. Bug on the lanchpad: https://bugs.launchpad.net/ubuntu/+source/maxima/+bug/417433 arch: i386, Linux 2.6.3114generic, GCL 2.6.7  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2892737&group_id=4933 
From: SourceForge.net <noreply@so...>  20091105 16:26:47

Bugs item #2892710, was opened at 20091105 16:26 Message generated for change (Tracker Item Submitted) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2892710&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: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Allow easier library access Initial Comment: Currently, to use Maxima as a Lisp ibrary requires (setpathnames) in the file src/initcl.lisp to load packages, but this has an unbound variable *maximalangsubdir* which is only set in another method which is only run when Maxima is actually run. This ticket would add an error catch in setpathnames to check the case where *maximalangsubdir* is neither NIL nor an actual path, by invoking (setq *maximalangsubdir* nil) wherever appropriate.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2892710&group_id=4933 
From: SourceForge.net <noreply@so...>  20091105 01:31:26

Bugs item #2892329, was opened at 20091104 20:16 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2892329&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Plotting Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: William Holtz (wmholtz) Assigned to: Nobody/Anonymous (nobody) Summary: Plot2d sometimes incorrect when using logscale Initial Comment: Using 5.19.2 on winXP. plot2d([1/(x+1)], [x,1e3,1e3], [logx])$ plot2d([1/(x+1)], [x,1e3,1e3], [gnuplot_preamble, "set logscale x"])$ These should give identical plots, but I the second version gives me a "knee" in the plot that is incorrect. This only happens with certain x ranges. I have attached an image of the incorrect plot. Please let me know if there is additional information I can provide  great program overall!  >Comment By: Raymond Toy (rtoy) Date: 20091104 20:31 Message: The issue is how maxima does plots. Basically, plots are done by uniformly sampling the x range. (Roughly). But when you want to do a log plot, the x range should be sampled logarithmically. When you specify logx, maxima knows to do the sampling correctly. That's why you get a nice smooth curve. But with the preamble, maxima doesn't know you're producing a log plot, so it does the normal sampling. That's why you see the knee. The samples selected are at 0.001 and about 0.78. (The sampling is roughly uniform, because maxima has an adaptive algorithm that will sample more if the plot is not smooth enough.)  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2892329&group_id=4933 
From: SourceForge.net <noreply@so...>  20091105 01:16:29

Bugs item #2892329, was opened at 20091104 17:16 Message generated for change (Tracker Item Submitted) made by wmholtz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2892329&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Plotting Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: William Holtz (wmholtz) Assigned to: Nobody/Anonymous (nobody) Summary: Plot2d sometimes incorrect when using logscale Initial Comment: Using 5.19.2 on winXP. plot2d([1/(x+1)], [x,1e3,1e3], [logx])$ plot2d([1/(x+1)], [x,1e3,1e3], [gnuplot_preamble, "set logscale x"])$ These should give identical plots, but I the second version gives me a "knee" in the plot that is incorrect. This only happens with certain x ranges. I have attached an image of the incorrect plot. Please let me know if there is additional information I can provide  great program overall!  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2892329&group_id=4933 