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

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 





1
(6) 
2
(10) 
3

4
(3) 
5
(5) 
6

7
(5) 
8
(3) 
9
(3) 
10
(3) 
11

12
(1) 
13
(1) 
14
(8) 
15
(8) 
16
(3) 
17
(5) 
18

19

20

21

22
(1) 
23

24
(2) 
25
(2) 
26
(2) 
27

28
(1) 
29
(2) 
30

31
(3) 
From: SourceForge.net <noreply@so...>  20080501 15:36:27

Bugs item #1955272, was opened at 20080501 02:14 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1955272&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  Floating point Group: None >Status: Closed >Resolution: Invalid Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: fpprec does not reflect actual output prec Initial Comment: The following batch file which calculates pi (using a very inefficient algorithm), does not show the correct fp precision on output. I'm comparing the output (iteration number 39) with the same algorithm using Mathematica. Increasing fpprec solves the problem, but the actual precision of the calculation is not fpprec. Maxima batch file: ==================================================== fpprec: 30$ L_0: 2$ k: 2$ el(x) := sqrt(22*sqrt(1x^2/4))$ L_old: L_0$ for i: 2 thru 39 do (k:k*2, L_new: el(L_old), cr:k*L_new/2, print("(",i,") ",bfloat(cr)), L_old:L_new)$ ==================================================== Maxima output: (39) 3.14159265480758935938754019422 Mathematica output: (39) 3.14159265358979323846262628475 If I increase fpprec in Maxima (to 50 in this case), it gives the correct answer: (39) 3.14159265358979323846262628475 I assume the preferred behavior is to have Maxima output at fpprec. Eric ehmajzo@...  >Comment By: Raymond Toy (rtoy) Date: 20080501 11:36 Message: Logged In: YES user_id=28849 Originator: NO I'm not familiar with Mathematica, but I don't think there's any way to do that in maxima. Closing this report.  Comment By: Nobody/Anonymous (nobody) Date: 20080501 11:15 Message: Logged In: NO Yes, you are correct regarding the roundoff errors in the algorithm. My misunderstanding was thinking that fpprec would yield output that was significant to that many decimal places. Is there an equivalent way to do in Maxima what is done in Mathematica with N[expr,n]?  Comment By: Raymond Toy (rtoy) Date: 20080501 09:06 Message: Logged In: YES user_id=28849 Originator: NO What does "output at fpprec" mean? fpprec in Maxima means that all bfloat operations will use fpprec digits in the calculations. Note that el(x) has significant roundoff issues as x becomes small. sqrt(1x^2/4) is not very accurate for small x. For small x sqrt(1x^2/4) is approximately 1, and then we essentially subtract that from 1, incurring even more roundoff. But, L_old starts as an exact integer, so, in fact, all intermediate calculations are done exactly. Then we compute bfloat(cr), which may not necessarily be the best way to compute the result. The symbolic expression does not take into consideration roundoff issues. I don't think this is a problem with maxima or the computations.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1955272&group_id=4933 
From: SourceForge.net <noreply@so...>  20080501 15:15:03

Bugs item #1955272, was opened at 20080430 23:14 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1955272&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  Floating point Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: fpprec does not reflect actual output prec Initial Comment: The following batch file which calculates pi (using a very inefficient algorithm), does not show the correct fp precision on output. I'm comparing the output (iteration number 39) with the same algorithm using Mathematica. Increasing fpprec solves the problem, but the actual precision of the calculation is not fpprec. Maxima batch file: ==================================================== fpprec: 30$ L_0: 2$ k: 2$ el(x) := sqrt(22*sqrt(1x^2/4))$ L_old: L_0$ for i: 2 thru 39 do (k:k*2, L_new: el(L_old), cr:k*L_new/2, print("(",i,") ",bfloat(cr)), L_old:L_new)$ ==================================================== Maxima output: (39) 3.14159265480758935938754019422 Mathematica output: (39) 3.14159265358979323846262628475 If I increase fpprec in Maxima (to 50 in this case), it gives the correct answer: (39) 3.14159265358979323846262628475 I assume the preferred behavior is to have Maxima output at fpprec. Eric ehmajzo@...  Comment By: Nobody/Anonymous (nobody) Date: 20080501 08:15 Message: Logged In: NO Yes, you are correct regarding the roundoff errors in the algorithm. My misunderstanding was thinking that fpprec would yield output that was significant to that many decimal places. Is there an equivalent way to do in Maxima what is done in Mathematica with N[expr,n]?  Comment By: Raymond Toy (rtoy) Date: 20080501 06:06 Message: Logged In: YES user_id=28849 Originator: NO What does "output at fpprec" mean? fpprec in Maxima means that all bfloat operations will use fpprec digits in the calculations. Note that el(x) has significant roundoff issues as x becomes small. sqrt(1x^2/4) is not very accurate for small x. For small x sqrt(1x^2/4) is approximately 1, and then we essentially subtract that from 1, incurring even more roundoff. But, L_old starts as an exact integer, so, in fact, all intermediate calculations are done exactly. Then we compute bfloat(cr), which may not necessarily be the best way to compute the result. The symbolic expression does not take into consideration roundoff issues. I don't think this is a problem with maxima or the computations.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1955272&group_id=4933 
From: SourceForge.net <noreply@so...>  20080501 13:51:42

Bugs item #1951964, was opened at 20080425 18:39 Message generated for change (Comment added) made by macrakis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1951964&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: Describe (? xxx) depends on ibase Initial Comment: ibase:2$ ? diff => internal error Maxima 5.14.0 GCL Windows  >Comment By: Stavros Macrakis (macrakis) Date: 20080501 09:51 Message: Logged In: YES user_id=588346 Originator: YES > should generic autoload rebind *readbase* when loading up Lisp files? Excellent idea; I wonder if there aren't other globals which should be bound during file loading?  Comment By: Raymond Toy (rtoy) Date: 20080501 09:13 Message: Logged In: YES user_id=28849 Originator: NO First solution implemented in clinfo.lisp.  Comment By: Raymond Toy (rtoy) Date: 20080430 13:44 Message: Logged In: YES user_id=28849 Originator: NO Problem is caused by loading maximaindex.lisp with a *readbase* of 2. All of the numbers in maximaindex.lisp show up as symbols since most are not base2 numbers. One solution: rebind *readbase* to 10 when maximaindex.lisp is loaded. Second solution: Make build_index.pl put trailing dots after each number. Perhaps both should be done. Also, should generic autoload rebind *readbase* when loading up Lisp files?  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1951964&group_id=4933 
From: SourceForge.net <noreply@so...>  20080501 13:13:11

Bugs item #1951964, was opened at 20080425 18:39 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1951964&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: Describe (? xxx) depends on ibase Initial Comment: ibase:2$ ? diff => internal error Maxima 5.14.0 GCL Windows  >Comment By: Raymond Toy (rtoy) Date: 20080501 09:13 Message: Logged In: YES user_id=28849 Originator: NO First solution implemented in clinfo.lisp.  Comment By: Raymond Toy (rtoy) Date: 20080430 13:44 Message: Logged In: YES user_id=28849 Originator: NO Problem is caused by loading maximaindex.lisp with a *readbase* of 2. All of the numbers in maximaindex.lisp show up as symbols since most are not base2 numbers. One solution: rebind *readbase* to 10 when maximaindex.lisp is loaded. Second solution: Make build_index.pl put trailing dots after each number. Perhaps both should be done. Also, should generic autoload rebind *readbase* when loading up Lisp files?  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1951964&group_id=4933 
From: SourceForge.net <noreply@so...>  20080501 13:06:22

Bugs item #1955272, was opened at 20080501 02:14 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1955272&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  Floating point Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: fpprec does not reflect actual output prec Initial Comment: The following batch file which calculates pi (using a very inefficient algorithm), does not show the correct fp precision on output. I'm comparing the output (iteration number 39) with the same algorithm using Mathematica. Increasing fpprec solves the problem, but the actual precision of the calculation is not fpprec. Maxima batch file: ==================================================== fpprec: 30$ L_0: 2$ k: 2$ el(x) := sqrt(22*sqrt(1x^2/4))$ L_old: L_0$ for i: 2 thru 39 do (k:k*2, L_new: el(L_old), cr:k*L_new/2, print("(",i,") ",bfloat(cr)), L_old:L_new)$ ==================================================== Maxima output: (39) 3.14159265480758935938754019422 Mathematica output: (39) 3.14159265358979323846262628475 If I increase fpprec in Maxima (to 50 in this case), it gives the correct answer: (39) 3.14159265358979323846262628475 I assume the preferred behavior is to have Maxima output at fpprec. Eric ehmajzo@...  >Comment By: Raymond Toy (rtoy) Date: 20080501 09:06 Message: Logged In: YES user_id=28849 Originator: NO What does "output at fpprec" mean? fpprec in Maxima means that all bfloat operations will use fpprec digits in the calculations. Note that el(x) has significant roundoff issues as x becomes small. sqrt(1x^2/4) is not very accurate for small x. For small x sqrt(1x^2/4) is approximately 1, and then we essentially subtract that from 1, incurring even more roundoff. But, L_old starts as an exact integer, so, in fact, all intermediate calculations are done exactly. Then we compute bfloat(cr), which may not necessarily be the best way to compute the result. The symbolic expression does not take into consideration roundoff issues. I don't think this is a problem with maxima or the computations.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1955272&group_id=4933 
From: SourceForge.net <noreply@so...>  20080501 06:14:05

Bugs item #1955272, was opened at 20080430 23:14 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=1955272&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  Floating point Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: fpprec does not reflect actual output prec Initial Comment: The following batch file which calculates pi (using a very inefficient algorithm), does not show the correct fp precision on output. I'm comparing the output (iteration number 39) with the same algorithm using Mathematica. Increasing fpprec solves the problem, but the actual precision of the calculation is not fpprec. Maxima batch file: ==================================================== fpprec: 30$ L_0: 2$ k: 2$ el(x) := sqrt(22*sqrt(1x^2/4))$ L_old: L_0$ for i: 2 thru 39 do (k:k*2, L_new: el(L_old), cr:k*L_new/2, print("(",i,") ",bfloat(cr)), L_old:L_new)$ ==================================================== Maxima output: (39) 3.14159265480758935938754019422 Mathematica output: (39) 3.14159265358979323846262628475 If I increase fpprec in Maxima (to 50 in this case), it gives the correct answer: (39) 3.14159265358979323846262628475 I assume the preferred behavior is to have Maxima output at fpprec. Eric ehmajzo@...  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1955272&group_id=4933 