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}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 

1
(1) 
2
(3) 
3
(1) 
4

5

6

7

8

9
(2) 
10

11

12
(2) 
13
(1) 
14

15

16
(1) 
17
(2) 
18

19

20
(1) 
21

22
(3) 
23
(8) 
24
(9) 
25
(7) 
26
(2) 
27
(4) 
28

29







From: SourceForge.net <noreply@so...>  20040223 23:35:24

Bugs item #903074, was opened at 20040223 18:25 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=903074&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: limit(1/inf1/minf) => 0+0 Initial Comment: limit(1/inf1/minf) returns the pseudosimplified form 0+0, internally ((mplus simp) 0 0).  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=903074&group_id=4933 
From: SourceForge.net <noreply@so...>  20040223 23:33:48

Bugs item #903072, was opened at 20040223 18:22 Message generated for change (Settings changed) made by macrakis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=903072&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) >Summary: is(x < inf) =>true Initial Comment: Compare apparently assumes that everything is smaller than inf: is(x < inf) => true ?? is(1/x < inf) => true ?? is(tan(x)^2 < inf) => true ?? is(und < inf) => error OK These are reasonable questions to ask, I think. Even if we consider that expressions' values range over standard, finite reals (and not inf/minf, which we reserve for return results), comparing to infinity has a reasonable mathematical interpretation, namely: is the expression bounded by a finite value. Clearly x is not. On the other hand, x <= inf should always be true, even for x:'UND (which currently causes an error). But perhaps we need a global theory of all this stuff.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=903072&group_id=4933 
From: SourceForge.net <noreply@so...>  20040223 23:33:24

Bugs item #903072, was opened at 20040223 18:22 Message generated for change (Settings changed) made by macrakis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=903072&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) >Summary: is(x < inf) = >true Initial Comment: Compare apparently assumes that everything is smaller than inf: is(x < inf) => true ?? is(1/x < inf) => true ?? is(tan(x)^2 < inf) => true ?? is(und < inf) => error OK These are reasonable questions to ask, I think. Even if we consider that expressions' values range over standard, finite reals (and not inf/minf, which we reserve for return results), comparing to infinity has a reasonable mathematical interpretation, namely: is the expression bounded by a finite value. Clearly x is not. On the other hand, x <= inf should always be true, even for x:'UND (which currently causes an error). But perhaps we need a global theory of all this stuff.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=903072&group_id=4933 
From: SourceForge.net <noreply@so...>  20040223 23:32:31

Bugs item #903072, was opened at 20040223 18: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=903072&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: is(x<inf) =>true Initial Comment: Compare apparently assumes that everything is smaller than inf: is(x < inf) => true ?? is(1/x < inf) => true ?? is(tan(x)^2 < inf) => true ?? is(und < inf) => error OK These are reasonable questions to ask, I think. Even if we consider that expressions' values range over standard, finite reals (and not inf/minf, which we reserve for return results), comparing to infinity has a reasonable mathematical interpretation, namely: is the expression bounded by a finite value. Clearly x is not. On the other hand, x <= inf should always be true, even for x:'UND (which currently causes an error). But perhaps we need a global theory of all this stuff.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=903072&group_id=4933 
From: SourceForge.net <noreply@so...>  20040223 22:28:00

Bugs item #697476, was opened at 20030304 15:06 Message generated for change (Comment added) made by macrakis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=697476&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Barton Willis (willisb) Assigned to: Nobody/Anonymous (nobody) Summary: formating doubles / really minor Initial Comment: fpprec has an undocumented feature; its value determines the number of decimal digits that are displayed for a double. (C1) fpprec : 8; (D1) 8 (C2) sin(0.1d0); (D2) 0.099833 (C3) fpprec : 30; (D3) 30 (C4) sin(0.1d0); (D4) 0.09983341664682816 (C5) fpprec : 16; (D5) 16 (C6) sin(0.1d0); (D6) 0.09983341664683 (C7) I was surprised by this; the setting of fpprec changes the formatting of doubles, but nothing else about them. For bfloat numbers, the setting of fpprec changes the formating and the number of bits in the fractional part. The documentation for fpprec is unclear and misleading  Variable: FPPREC default: [16]  Floating Point PRECision. Can be set to an intger representing the desired precision. Maybe Maxima has too many globals already, but I might suggest that the formating of doubles be controlled by something other than fpprec. (An option for scientific notation, etc might be nice.) Maxima version: 5.9.0.rc4 Maxima build date: 12:4 1/30/2003 host type: i686pcmingw32 lispimplementationtype: Kyoto Common Lisp lispimplementationversion: GCL25.0 Barton  >Comment By: Stavros Macrakis (macrakis) Date: 20040223 17:17 Message: Logged In: YES user_id=588346 for fpprec:1 thru 6 do print(fpprec," ", 1.0e3/3," ", 1.0e2/3," ", 1.0e1/3," ", 1.0e+0/3," ", 1.0e+1/3," ", 1.0e+2/3," ", 1.0e+6/3," ", 1.0e+10/3); 1 3.E4 .0 .0 .0 3. 30. 300000. 3.E+9 2 3.3E4 0.0 0.0 0.3 3.3 33. 330000. 3.3E+9 3 3.33E4 0.0 0.03 0.3 3.33 33.3 333000. 3.33E+9 4 3.333E4 0.003 0.03 0.33 3.333 33.33 333300. 3.333E+9 5 3.3333E4 0.003 0.033 0.333 3.3333 33.333 333330. 3.3333E+9 6 3.33333E4 0.0033 0.0333 0.3333 3.33333 33.3333 333333. 3.33333E+9 There are several problems here. First of all, in all but the .003, 0.03, and 0.3 cases, fpprec refers to the number of significant digits, not the number of printed digits. Those cases should read: 1 0.003 0.03 0.3 2 0.0033 0.033 0.33 3 0.00333 0.0333 0.333 4 0.003333 0.03333 0.3333 5 0.0033333 0.033333 0.33333 6 0.00333333 0.0333333 0.333333 Secondly, 3. and 30. in Maxima read in as integers, not floats, so should presumably be output in a consistent way. Finally, it is confusing (though arguably consistent) that 333333.0 prints as 300000. with fpprec=1. Nonsignificant zeroes can be avoided by using scientific form, as C does with %g format.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=697476&group_id=4933 
From: SourceForge.net <noreply@so...>  20040223 16:36:19

Bugs item #902792, was opened at 20040223 11:26 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=902792&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: describe interaction parser not robust Initial Comment: When describe() finds more than one match, it offers the interactive choice: Enter n, all, none, or multiple choices eg 1 3 : If you enter anything but a spaceseparated list of numbers and all/none then semicolon, it tends to error out in stupid, ugly, unfriendly ways. Try, for example, describe(ratp), which prompts: 0: RATP :(maxima.info)Definitions for Polynomials. 1: RATPRINT :Definitions for Polynomials. Enter n, all, none, or multiple choices eg 1 3 : ratp; The following produce internal errors: 0,1; '0; The following print nothing, and give no error: 1 $ 01; ratprint; 4; The following give incomplete results: 0 <newline> 1; (shows only ratp) The following give syntax errors: 0 <newline> ; (note that the prompt doesn't say you need to terminate with semicolon  I suspect that originally, the <newline> terminated the input, and the semicolon wasn't necessary) xmaxima 5.9.0  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=902792&group_id=4933 
From: SourceForge.net <noreply@so...>  20040223 16:02:43

Bugs item #902757, was opened at 20040223 10:52 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=902757&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: taylor(x,[x],inf,...) garbage Initial Comment: taylor(x,[x],inf,1) => (inf^2+1)/inf1/(x*inf^2)+... ??? taylor(x,[x],[inf],1) => same thing but variants all work: taylor(x,x,inf,1) => x+... OK taylor(x,[x,inf,1]) => x+... OK taylor(x,[x],0,1) => x+... OK taylor(x,[x],[0],1) => x+... OK taylor(x,x,q,1) => q+(xq)+... OK taylor(x,[x],q,1) => q+(xq)+... OK taylor(x,[x],[q],1) => q+(xq)+... OK The original failure was of course in a more realistic case, with more than one variable: taylor(atan(x^2+y^2),[x,y],inf,4) => error should be %pi/21/(y^2+x^2)+... but taylor(atan(x^2+y^2),[x,y],0,2) => %pi/2y^2*x^2/(x^2+y^2)+...  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=902757&group_id=4933 
From: SourceForge.net <noreply@so...>  20040223 14:08:33

Bugs item #902694, was opened at 20040223 08:58 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=902694&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: equal(ind,ind) should be false; also und, NaN Initial Comment: is(ind=ind) => true OK, is/= is syntactic is(equal(ind,ind)) => true NO! is/equal should be semantic Unlike IEEE floating point, Maxima carefully distinguishes syntactic and semantic equality tests. Clearly everything, including ind / und / IEEE_NaN, is syntactically equal to itself. However, not everything is semantically equal to itself. In particular, equal(und,und), equal(ind,ind), and equal(IEEE_NaN, IEEE_NaN) (when we support it) should be false.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=902694&group_id=4933 