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}
(12) 
_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 



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

15
(6) 
16
(3) 
17
(5) 
18
(7) 
19
(1) 
20
(1) 
21
(2) 
22
(1) 
23
(1) 
24

25
(2) 
26
(12) 
27
(2) 
28
(1) 
29
(2) 
30
(11) 
31



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

Bugs item #1990595, was opened at 20080611 12:32 Message generated for change (Comment added) made by beshenov You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1990595&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: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Bug in radcan Initial Comment: Maxima version: 5.15.0 Maxima build date: 17:36 4/20/2008 host type: i686pcmingw32 lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.8  The above information is also available from the Maxima function build_info(). (%o2) (%i3) sqrt(x^2+x^3); 3 2 (%o3) sqrt(x + x ) (%i4) factor(sqrt(x^2+x^3)); (%o4) sqrt(x + 1) abs(x) (%i5) radcan(sqrt(x^2+x^3)); (%o5) x sqrt(x + 1) (%i6) While factor got this right radcan yields a incorrect result.  >Comment By: Alexey Beshenov (beshenov) Date: 20080702 03:33 Message: Logged In: YES user_id=1498309 Originator: NO sqrt(x + 1) abs(x) is not a correct algebraic value, in contrast to x sqrt(x + 1). This radcan issue is being reported frequently, but it's not a bug. This tracker item should be closed.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1990595&group_id=4933 
From: SourceForge.net <noreply@so...>  20080701 14:02:31

Bugs item #1978090, was opened at 20080529 13:07 Message generated for change (Comment added) made by dgildea You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1978090&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  Limit Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: strange limit result 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) abs(sin(x))/sqrt(1cos(x)); (%o1) abs(sin(x))/sqrt(1cos(x)) (%i2) limit(%o1, x, 0, minus); (%o2) sqrt(2) (%i3) limit(%o1, x, 0, plus); (%o3) sqrt(2) (%i4) bug_report()$The Maxima bug database is available at http://sourceforge.net/tracker/?atid=104933&group_id=4933&func=browseSubmit bug reports by following the 'Submit New' link on that page.Please include the following build information with your bug report:Maxima version: 5.15.0Maxima build date: 17:36 4/20/2008 host type: i686pcmingw32 lispimplementationtype: GNU Common Lisp (GCL)lispimplementationversion: GCL 2.6.8The above information is also available from the Maxima function build_info().(%i5) amedeo.maddalena@...  >Comment By: Dan Gildea (dgildea) Date: 20080701 10:02 Message: Logged In: YES user_id=1797506 Originator: NO In current cvs: (%i2) limit(sin(x)/sqrt(1cos(x)), x, 0, plus); (%o2) sqrt(2) OK (%i3) limit(sin(x)/sqrt(1cos(x)), x, 0, minus); (%o3) sqrt(2) Should be sqrt(2). In both cases, limit is using taylor: (%i4) taylor(sin(x)/sqrt(1cos(x)), x, 0, 3); (%o4) sqrt(2)sqrt(2)*x^2/8 This fits one side of the discontinuity. What is the correct behavior for taylor in this situation?  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1978090&group_id=4933 
From: SourceForge.net <noreply@so...>  20080701 11:11:01

Bugs item #1990099, was opened at 20080610 14:26 Message generated for change (Comment added) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1990099&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: Oliver Kullmann (xgateruq9) Assigned to: Nobody/Anonymous (nobody) Summary: wrong integer_partitions(0) Initial Comment: (%i2) integer_partitions(0); (%o2) {} is wrong: it must be {[]}. The documentation of integer_partitions correctly states "A list [a_1, ..., a_m] is a partition of a nonnegative integer n when (1) each a_i is a nonzero integer, and (2) a_1 + ... + a_m = n." Unfortunately, then follows: "Thus 0 has no partitions." while obviously from the definition it follows that [] is the unique partition of 0. The partition function p(n), which counts the number of partitions of n, is accordingly defined as p(0) = 1. See any book on number theory, or e.g. http://en.wikipedia.org/wiki/Partition_(number_theory). Or see http://www.research.att.com/~njas/sequences/A000041. (For example, S_0 is the trivial group, the same as S_1, and thus p(0) = p(1) = 1.) Another bug: The documentation states that n is an integer. However: (%i4) integer_partitions(1); (%o4) int_partitions(1) The value is {} for negative n. The corrected integer_partition is corrected_integer_partitions(n) := if n < 0 then {} elseif n = 0 then {[]} else integer_partitions(n)$  >Comment By: Barton Willis (willisbl) Date: 20080701 06:10 Message: Logged In: YES user_id=895922 Originator: NO fixed typo: int_partitions > integer_partitions (CVS revision 1.26)  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1990099&group_id=4933 
From: SourceForge.net <noreply@so...>  20080701 02:21:39

Bugs item #1699445, was opened at 20070412 12:11 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1699445&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: Closed >Resolution: Wont Fix Priority: 5 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Jaime E. Villate (villate) Summary: plot2d in very narrow range Initial Comment: I was looking at the behavior of floatingpoint sin near %pi/2, so I did: plot2d(sin(x),[x,1.57079628,1.570796326794897], [nticks,1000]); There are several problems with the result. First of all, the x and y axes are labelled with only 5 digits of precision, so x goes from 1.5708 to 1.5708, and y goes from 1 to 1. Not very useful. Similarly, the coordinates shown in the bottom left have only 6 digits. Secondly, about 5/6 of the way across the plot, there is a short line *outside* the plotting box. I don't know if this represents a value larger than the other values or some sort of plotting glitch. Maxima 5.11.0 GCL Windows Gnuplot 4.0  >Comment By: Robert Dodier (robert_dodier) Date: 20080630 20:21 Message: Logged In: YES user_id=501686 Originator: NO Line outside the box not observed in 5.15.0cvs + Clisp + Gnuplot 4.0.0 + Linux. Line outside the box is observed in 5.15.0 + GCL + Gnuplot 4.2.3 + Windows XP. In fact, when the same Gnuplot script is rendered on Windows (i.e. the maxout.gnuplot file created when plot_format is gnuplot) the extraneous line is shown on Windows, and not shown on Linux. I conclude this is a Windowsspecific bug in Gnuplot. The problem with labels mentioned here is a bug in Gnuplot; it should be smarter about constructing the label text. I don't think we should try to work around it. Closing this report as "won't fix" since the problems are in Gnuplot. I have submitted bug reports to the Gnuplot project for these.  Comment By: Robert Dodier (robert_dodier) Date: 20070629 17:30 Message: Logged In: YES user_id=501686 Originator: NO It appears that the display generated by Maxima 5.12.0 is even less informative ... in 5.12.0 the vertical range of the display is 0.99 to 1.01 which is many orders of magnitude greater than the range of sin over [1.57079628, 1.570796326794897]. At least with 5.11.0 you get stair steps as expected. The range [0.99, 1.01] might be imposed by Gnuplot (5.12.0 ships with Gnuplot 4.1, 5.11.0 ships with 4.0), or it might be imposed by Maxima, dunno which.  Comment By: Stavros Macrakis (macrakis) Date: 20070412 12:13 Message: Logged In: YES user_id=588346 Originator: YES nticks not necessary to evoke this bug  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1699445&group_id=4933 
From: SourceForge.net <noreply@so...>  20080701 01:40:51

Bugs item #1063875, was opened at 20041110 08:14 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1063875&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: Fixed Priority: 5 Private: No Submitted By: Robert Dodier (robert_dodier) Assigned to: Nobody/Anonymous (nobody) Summary: Symmetries.texi needs translation from French to English Initial Comment: Symmetries.texi needs translation from French to English. Looks like it would be straightforward.  >Comment By: Robert Dodier (robert_dodier) Date: 20080630 19:40 Message: Logged In: YES user_id=501686 Originator: YES Translation by Kostas Oikonomou committed as r1.10 doc/info/Symmetries.texi. Closing this report as fixed.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1063875&group_id=4933 