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}
(28) 
_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 

1
(2) 
2
(12) 
3
(1) 
4
(4) 
5

6
(3) 
7

8
(1) 
9
(8) 
10
(4) 
11
(6) 
12
(1) 
13
(5) 
14
(3) 
15
(5) 
16
(3) 
17
(3) 
18
(2) 
19
(5) 
20
(4) 
21
(6) 
22
(1) 
23
(1) 
24
(6) 
25
(9) 
26
(1) 
27
(1) 
28
(8) 
From: SourceForge.net <noreply@so...>  20090213 14:25:51

Bugs item #2582731, was opened at 20090209 16:18 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2582731&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: To be reviewed >Status: Pending >Resolution: Invalid Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: wrong sine computation Initial Comment: tried this on Linux and Windows: fpprec:70; bfloat(asin(sin(0.1))) should be 0.1, results in a number > 1  >Comment By: Raymond Toy (rtoy) Date: 20090213 09:25 Message: Marking as pending/invalid.  Comment By: Raymond Toy (rtoy) Date: 20090209 16:23 Message: Please show exactly what you got. I get the following: (%i133) bfloat(asin(sin(0.1))); (%o133) 1.000000000000000055511151231257827021181583404541015625b1 This is the expected answer because bfloat(0.1) is precisely %o133. (0.1 is a doublefloat which doesn't have an exact floatingpoint representation. The conversion to bfloat shows that.)  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2582731&group_id=4933 
From: SourceForge.net <noreply@so...>  20090213 14:24:46

Bugs item #2582078, was opened at 20090209 11:50 Message generated for change (Settings changed) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2582078&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: Closed >Resolution: Invalid Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Integration yields wrong result. Initial Comment: integrate(4*x / (2*(x^2 + 1/2)), x); yields: log(x^2 + 1/2) integrate(4*x / (2*x^2 + 1), x); yields log(2*x^2 + 1), but should yield log(x^2 + 1/2) as well. I am using Maxima 5.17.0, GCL 2.6.7 on Debian Linux, kernel 2.6.261686. EMail: gnihihihi@...  Comment By: Nobody/Anonymous (nobody) Date: 20090210 07:36 Message: Oh, sorry. My error.  Comment By: Nobody/Anonymous (nobody) Date: 20090209 17:07 Message: 2*x^2+1 is equal to x^2+1/2 so the answer is correct  Comment By: Raymond Toy (rtoy) Date: 20090209 16:28 Message: Why should they be the same? The two answers only differ by a constant. And the derivative of each answer is the integrand.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2582078&group_id=4933 
From: SourceForge.net <noreply@so...>  20090213 03:38:40

Bugs item #2592250, was opened at 20090212 02:42 Message generated for change (Comment added) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2592250&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: Ago77 (ago77) Assigned to: Nobody/Anonymous (nobody) Summary: lmin Initial Comment: I came across a list that seems to expose a bug in "lmin." The list is: Q: [0, (10*sqrt(3019)653)/(10*sqrt(3019)800), (1243*sqrt(3019)65630)/(1600*sqrt(3019)94190), (12270806*sqrt(3019)674213245)/(15070400*sqrt(3019)830019805), (1534218310305203*sqrt(3019)84298201004276722)/(2001396875083520*sqrt(3019)109967917387142242), (877822352489691153078985106965453*sqrt(3019)48232324401355597222123482321934010)/ (1100447231090345843897339350259200*sqrt(3019)60464543522069663495052507120510410)]$ lmin(Q); produces a "Division by 0" error message  on the other hand, lmin(float(Q)); or also lmin(Q), numer; both yield  0.089597918818624. lmax(Q) works properly, but lmax(Q) also yields a "Divide by 0" error, not too surprisingly.  >Comment By: Barton Willis (willisbl) Date: 20090212 21:38 Message: I believe the trouble is in computing the sign of: (%i62) (94648962737729943093436340438935374529647608621614*sqrt(3019)5200527717336367518913170807682526084100767540599370)/(60506859663968574059067272189736794088560937142400*sqrt(3019)3324575269180571635805235048597996242355104695758805); (%o62) (94648962737729943093436340438935374529647608621614*sqrt(3019)5200527717336367518913170807682526084100767540599370)/(60506859663968574059067272189736794088560937142400*sqrt(3019)3324575269180571635805235048597996242355104695758805) (%i63) sign(%); Division by 0 The number is actually not so complicated: (%i64) ratsimp(%o62), algebraic : true; (%o64) (2*sqrt(3019)70)/115 (%i65) sign(%); (%o65) neg  Comment By: Barton Willis (willisbl) Date: 20090212 21:34 Message: A workaround it to set algebraic : true.  Comment By: Barton Willis (willisbl) Date: 20090212 21:24 Message: A workaround it to set algebraic : true.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2592250&group_id=4933 
From: SourceForge.net <noreply@so...>  20090213 03:34:18

Bugs item #2592250, was opened at 20090212 02:42 Message generated for change (Comment added) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2592250&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: Ago77 (ago77) Assigned to: Nobody/Anonymous (nobody) Summary: lmin Initial Comment: I came across a list that seems to expose a bug in "lmin." The list is: Q: [0, (10*sqrt(3019)653)/(10*sqrt(3019)800), (1243*sqrt(3019)65630)/(1600*sqrt(3019)94190), (12270806*sqrt(3019)674213245)/(15070400*sqrt(3019)830019805), (1534218310305203*sqrt(3019)84298201004276722)/(2001396875083520*sqrt(3019)109967917387142242), (877822352489691153078985106965453*sqrt(3019)48232324401355597222123482321934010)/ (1100447231090345843897339350259200*sqrt(3019)60464543522069663495052507120510410)]$ lmin(Q); produces a "Division by 0" error message  on the other hand, lmin(float(Q)); or also lmin(Q), numer; both yield  0.089597918818624. lmax(Q) works properly, but lmax(Q) also yields a "Divide by 0" error, not too surprisingly.  >Comment By: Barton Willis (willisbl) Date: 20090212 21:34 Message: A workaround it to set algebraic : true.  Comment By: Barton Willis (willisbl) Date: 20090212 21:24 Message: A workaround it to set algebraic : true.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2592250&group_id=4933 
From: SourceForge.net <noreply@so...>  20090213 03:25:00

Bugs item #2592250, was opened at 20090212 02:42 Message generated for change (Comment added) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2592250&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: Ago77 (ago77) Assigned to: Nobody/Anonymous (nobody) Summary: lmin Initial Comment: I came across a list that seems to expose a bug in "lmin." The list is: Q: [0, (10*sqrt(3019)653)/(10*sqrt(3019)800), (1243*sqrt(3019)65630)/(1600*sqrt(3019)94190), (12270806*sqrt(3019)674213245)/(15070400*sqrt(3019)830019805), (1534218310305203*sqrt(3019)84298201004276722)/(2001396875083520*sqrt(3019)109967917387142242), (877822352489691153078985106965453*sqrt(3019)48232324401355597222123482321934010)/ (1100447231090345843897339350259200*sqrt(3019)60464543522069663495052507120510410)]$ lmin(Q); produces a "Division by 0" error message  on the other hand, lmin(float(Q)); or also lmin(Q), numer; both yield  0.089597918818624. lmax(Q) works properly, but lmax(Q) also yields a "Divide by 0" error, not too surprisingly.  >Comment By: Barton Willis (willisbl) Date: 20090212 21:24 Message: A workaround it to set algebraic : true.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2592250&group_id=4933 