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

_{Nov}

_{Dec}

S  M  T  W  T  F  S 



1
(6) 
2
(14) 
3
(1) 
4
(1) 
5

6

7
(13) 
8
(6) 
9
(2) 
10
(8) 
11
(4) 
12

13
(15) 
14
(19) 
15
(3) 
16
(4) 
17
(2) 
18
(1) 
19
(1) 
20

21
(4) 
22
(7) 
23
(3) 
24

25
(2) 
26
(1) 
27
(1) 
28
(4) 
29
(7) 
30
(3) 
31
(1) 


From: SourceForge.net <noreply@so...>  20091210 22:13:00

Bugs item #2910001, was opened at 20091207 07:16 Message generated for change (Comment added) made by clarphimous You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2910001&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: Accepted Priority: 5 Private: No Submitted By: Clarphimous (clarphimous) Assigned to: Nobody/Anonymous (nobody) Summary: optimization of bfloat input Initial Comment: When using the input method that goes like 2.53b10, it tends to get very slow with large exponents. This applies for large negative exponents as well. I believe the reason is that it is converting all the digits up to the decimal point into binary, where it really only needs to convert them up to the number of bits of precision. For example: 1b1000000; takes quite a while to perform. Not far above this, Maxima crashes on my system (another bug I was originally investigating, which applies to rational numbers as well). On the other hand, if we do a calculation like x:1b1000; x^40000000; you can get a result in less than a second, although it does have some rounding errors at the end.  >Comment By: Clarphimous (clarphimous) Date: 20091210 16:12 Message: Alrighty. I think what would prevent roundoff errors is if you give it a few extra bits of precision while doing the calculations. In other words, guard digits/bits. If the input is shorter than the number of digits of precision, add some extra zeroes. The calculators I've used usually have 3 guard digits (although they were using binary coded decimal). For example: fpprec: 10; x:1.1223344556677889900112233b0 For this, cut it off 3 digits after the 10th digit. That would be 1.122334455668, with rounding. Then, convert that to binary with some extra bits of precision. Finally, round that answer off to the number of bits you usually have. Another example: a:1.23456789b0; For this I would assume that the actual input is 1.234567890000. Then convert that to binary, and cut off the excess bits when you're done. It might take some experimentation to figure out how how many extra digits and bits you need, but I'm pretty sure this will work. Here is a quick experiment I did where I manually rounded the numbers: fpprec: 10; x:1.1223344556677889900112233b0; x1.122334455b0; y:1.1223344557b0; y1.122334455b0; z:1.12233445567b0; z1.122334455b0; http://www.disillusionary.com/files/exp.png  Comment By: Raymond Toy (rtoy) Date: 20091210 11:40 Message: I've done some work on this, and bfloat input for large inputs is now much faster. 2.53b10 is converted by computing bfloat(253)*10b0^(102). Except the exponent is much larger. Small exponents use the current algorithm. The new algorithm has roundoff issues and about 5% of the time differs from the old algorithm. Perhaps this is acceptable for large exponents.  Comment By: Clarphimous (clarphimous) Date: 20091208 01:22 Message: Okay, I don't know exactly how you'd implement it, as I'm not very knowledgeable about base conversion algorithms (although I do know a little). However, I can tell you that the Sage CAS performs the exact same conversion without taking nearly as long for really large numbers. (On the other hand, the default Sage interface seems to only accept floatingpoint numbers up to around 323,000,000 digits before marking them as "infinity.") First, a 1000 digit bfloat in Maxima: set_display('ascii)$ fpprec:35; x:3.4000000000000000000000000000000001b1000; fpprec:1001; (x+1)1; result: http://www.disillusionary.com/files/maxima_big_a.png Next, the same calculation in Sage. x = 3.4000000000000000000000000000000001e1000 x parent(x) y = ZZ(x) parent(y) y result: http://www.disillusionary.com/files/sage_big_a.png Apparently with this calculation the same number of bits of precision are used. For the next one, though, I had to pad Sage's input with an extra zero to get the same result. In Maxima: fpprec:35; x:3.4000000000000000000000000000000001b5000000; fpprec:1001; x+1b4999000; result: http://www.disillusionary.com/files/maxima_big_b.png And now for Sage x = 3.40000000000000000000000000000000010e5000000 x parent(x) y = ZZ(x) parent(y) y result: http://www.disillusionary.com/files/sage_big_b.png Here is where the results in speed and memory usage come into play. Sage doesn't take any longer than it usually does to store the value of x. So... the point is that there is a way, but I do not know how to do it, myself. I was thinking maybe you could use the same process you use to output the decimal value of the bfloat each time it's displayed... but I don't know if it works both ways.  Comment By: Raymond Toy (rtoy) Date: 20091207 13:48 Message: The algorithm for reading bfloats converts the bfloat to an exact rational. Thus 2.53b10 is 253/100*10^10. This is then converted to a bfloat. So 1b1000000 is converted to the exact rational 10^1000000 and converted to a bfloat. This should incur exactly one rounding operation. I think doing it in any other way will incur additional roundoff errors, and we would very much like that the internal representation be as close as possible to the input number. This is also complicated by the fact that bfloats are internally represented using base 2 exponents, not base 10. Marking as pending/wontfix.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2910001&group_id=4933 
From: SourceForge.net <noreply@so...>  20091210 19:58:36

Bugs item #2909917, was opened at 20091207 04:42 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2909917&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: Clarphimous (clarphimous) Assigned to: Nobody/Anonymous (nobody) Summary: documentation typo  jornan Initial Comment: Just a little typo. http://maxima.sourceforge.net/docs/manual/en/maxima_46.html Function: jordan (mat) Returns the Jordan form of matrix mat, but codified in a Maxima list. To get the corresponding matrix, call function dispJordan using as argument the output of jornan.  Comment By: Raymond Toy (rtoy) Date: 20091210 14:07 Message: The reported bug is not present in the current cvs version of Maxima. Thank you for your report. If you see this bug in a later version of Maxima, please submit a new bug report.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2909917&group_id=4933 
From: SourceForge.net <noreply@so...>  20091210 17:40:51

Bugs item #2910001, was opened at 20091207 08:16 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2910001&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: Accepted Priority: 5 Private: No Submitted By: Clarphimous (clarphimous) Assigned to: Nobody/Anonymous (nobody) Summary: optimization of bfloat input Initial Comment: When using the input method that goes like 2.53b10, it tends to get very slow with large exponents. This applies for large negative exponents as well. I believe the reason is that it is converting all the digits up to the decimal point into binary, where it really only needs to convert them up to the number of bits of precision. For example: 1b1000000; takes quite a while to perform. Not far above this, Maxima crashes on my system (another bug I was originally investigating, which applies to rational numbers as well). On the other hand, if we do a calculation like x:1b1000; x^40000000; you can get a result in less than a second, although it does have some rounding errors at the end.  >Comment By: Raymond Toy (rtoy) Date: 20091210 12:40 Message: I've done some work on this, and bfloat input for large inputs is now much faster. 2.53b10 is converted by computing bfloat(253)*10b0^(102). Except the exponent is much larger. Small exponents use the current algorithm. The new algorithm has roundoff issues and about 5% of the time differs from the old algorithm. Perhaps this is acceptable for large exponents.  Comment By: Clarphimous (clarphimous) Date: 20091208 02:22 Message: Okay, I don't know exactly how you'd implement it, as I'm not very knowledgeable about base conversion algorithms (although I do know a little). However, I can tell you that the Sage CAS performs the exact same conversion without taking nearly as long for really large numbers. (On the other hand, the default Sage interface seems to only accept floatingpoint numbers up to around 323,000,000 digits before marking them as "infinity.") First, a 1000 digit bfloat in Maxima: set_display('ascii)$ fpprec:35; x:3.4000000000000000000000000000000001b1000; fpprec:1001; (x+1)1; result: http://www.disillusionary.com/files/maxima_big_a.png Next, the same calculation in Sage. x = 3.4000000000000000000000000000000001e1000 x parent(x) y = ZZ(x) parent(y) y result: http://www.disillusionary.com/files/sage_big_a.png Apparently with this calculation the same number of bits of precision are used. For the next one, though, I had to pad Sage's input with an extra zero to get the same result. In Maxima: fpprec:35; x:3.4000000000000000000000000000000001b5000000; fpprec:1001; x+1b4999000; result: http://www.disillusionary.com/files/maxima_big_b.png And now for Sage x = 3.40000000000000000000000000000000010e5000000 x parent(x) y = ZZ(x) parent(y) y result: http://www.disillusionary.com/files/sage_big_b.png Here is where the results in speed and memory usage come into play. Sage doesn't take any longer than it usually does to store the value of x. So... the point is that there is a way, but I do not know how to do it, myself. I was thinking maybe you could use the same process you use to output the decimal value of the bfloat each time it's displayed... but I don't know if it works both ways.  Comment By: Raymond Toy (rtoy) Date: 20091207 14:48 Message: The algorithm for reading bfloats converts the bfloat to an exact rational. Thus 2.53b10 is 253/100*10^10. This is then converted to a bfloat. So 1b1000000 is converted to the exact rational 10^1000000 and converted to a bfloat. This should incur exactly one rounding operation. I think doing it in any other way will incur additional roundoff errors, and we would very much like that the internal representation be as close as possible to the input number. This is also complicated by the fact that bfloats are internally represented using base 2 exponents, not base 10. Marking as pending/wontfix.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2910001&group_id=4933 
From: SourceForge.net <noreply@so...>  20091210 17:36:57

Bugs item #2911760, was opened at 20091209 22:22 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2911760&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: Problem not in Maxima Group: None >Status: Pending >Resolution: Invalid Priority: 5 Private: No Submitted By: AKG (agehr) Assigned to: Nobody/Anonymous (nobody) Summary: xmaxima breaks on Ubuntu 9.10 Initial Comment: (%i1) Maxima version: 5.17.1 Maxima build date: 14:9 7/13/2009 host type: i686pclinuxgnu lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.7 Clicking on the first example in the tutorial results in: %i2) Universal error handler called recursively (:ERROR NIL CONDITIONS::CLCSUNIVERSALERRORHANDLER "" "Couldn't protect") Universal error handler called recursively (:ERROR NIL CONDITIONS::CLCSUNIVERSALERRORHANDLER "" "Couldn't protect") Maxima encountered a Lisp error: Error in CONDITIONS::CLCSUNIVERSALERRORHANDLER [or a callee]: Caught fatal error [memory may be damaged] Automatically continuing. To reenable the Lisp debugger set *debuggerhook* to nil. (%i3) Other simple tasks deliver similar error messages. Wxmaxima also gives similar results. This appears to be a problem introduced with Ubuntu 9.10. I didn't have a problem with 9.04. I removed and reinstalled maxima and got the same results.  >Comment By: Raymond Toy (rtoy) Date: 20091210 12:36 Message: This is a problem with the Ubuntu package and not with Maxima itself. Get Ubuntu to provide a working version.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2911760&group_id=4933 
From: SourceForge.net <noreply@so...>  20091210 17:29:47

Bugs item #2912067, was opened at 20091210 10:44 Message generated for change (Settings changed) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2912067&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: Problem not in Maxima Group: None >Status: Pending >Resolution: Invalid Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: CLCSUNIVERSALERRORHANDLER Initial Comment: A crash occurred entering "factor (x^6  1)" which is an example given in the Introduction to the Maxima Manual. A screen shot is attached. Maxima version: 5.17.1 Maxima build date: 14:31 7/13/2009 host type: x86_64unknownlinuxgnu (Ubuntu 9.10) lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.7  >Comment By: Raymond Toy (rtoy) Date: 20091210 12:29 Message: There have been quite bugs related to Ubuntu's distribution of gcl and/or maxima. This is not a bug in maxima per se. Try using a different lisp or building your own or getting Ubuntu to provide a working version.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2912067&group_id=4933 
From: SourceForge.net <noreply@so...>  20091210 15:44:13

Bugs item #2912067, was opened at 20091210 15:44 Message generated for change (Tracker Item Submitted) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2912067&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: CLCSUNIVERSALERRORHANDLER Initial Comment: A crash occurred entering "factor (x^6  1)" which is an example given in the Introduction to the Maxima Manual. A screen shot is attached. Maxima version: 5.17.1 Maxima build date: 14:31 7/13/2009 host type: x86_64unknownlinuxgnu (Ubuntu 9.10) lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.7  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2912067&group_id=4933 
From: SourceForge.net <noreply@so...>  20091210 09:28:40

Bugs item #2911891, was opened at 20091210 09:28 Message generated for change (Tracker Item Submitted) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2911891&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: gcfac gives Lisp error Initial Comment: a : diff(diff(diff(integrate(integrate(integrate(sin(sqrt(x)),x),x),x),x),x),x); load (scifac)$ gcfac(a); Maxima encountered a Lisp error: Error in AND [or a callee]: The function $MIN is undefined. Automatically continuing. To reenable the Lisp debugger set *debuggerhook* to nil.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2911891&group_id=4933 
From: SourceForge.net <noreply@so...>  20091210 03:22:03

Bugs item #2911760, was opened at 20091209 21:22 Message generated for change (Tracker Item Submitted) made by agehr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2911760&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: AKG (agehr) Assigned to: Nobody/Anonymous (nobody) Summary: xmaxima breaks on Ubuntu 9.10 Initial Comment: (%i1) Maxima version: 5.17.1 Maxima build date: 14:9 7/13/2009 host type: i686pclinuxgnu lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.7 Clicking on the first example in the tutorial results in: %i2) Universal error handler called recursively (:ERROR NIL CONDITIONS::CLCSUNIVERSALERRORHANDLER "" "Couldn't protect") Universal error handler called recursively (:ERROR NIL CONDITIONS::CLCSUNIVERSALERRORHANDLER "" "Couldn't protect") Maxima encountered a Lisp error: Error in CONDITIONS::CLCSUNIVERSALERRORHANDLER [or a callee]: Caught fatal error [memory may be damaged] Automatically continuing. To reenable the Lisp debugger set *debuggerhook* to nil. (%i3) Other simple tasks deliver similar error messages. Wxmaxima also gives similar results. This appears to be a problem introduced with Ubuntu 9.10. I didn't have a problem with 9.04. I removed and reinstalled maxima and got the same results.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2911760&group_id=4933 