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}

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...>  20091208 16:32:06

Bugs item #2910796, was opened at 20091208 16:32 Message generated for change (Tracker Item Submitted) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2910796&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: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Could not run Maxima! Initial Comment: Does anybody knows why Maxima (the latest version, as the previous ones) does not run on my DELL studio 1555, with Avira and Kaspersky 2009 antivirus, having desabled all the possible defences from firewalls to Windows defence? Do you know any solution of that problem? I am starting to consider the fact that it could be my laptop that has some conflicts with Maxima, or maybe other softwares but actually I'm not using any particular one.... Thanks, Edoardo  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2910796&group_id=4933 
From: SourceForge.net <noreply@so...>  20091208 07:22:12

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: Wont Fix 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: 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...>  20091208 04:53:34

Bugs item #2910437, was opened at 20091207 22:28 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2910437&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: 7 Private: No Submitted By: Raymond Toy (rtoy) Assigned to: Nobody/Anonymous (nobody) Summary: nonrepeatable beta_incomplete(1b0,1,z) Initial Comment: This is totally unexpected and incorrect: (%i1) beta_incomplete(1b0,1,z); (%o1) 1.0b0 z (%i2) beta_incomplete(1b0,1,z); (%o2) 1.000000000000001b0 z I have no idea what the problem is.  >Comment By: Raymond Toy (rtoy) Date: 20091207 23:53 Message: The issue is caused by fpe. During the computation of beta_incomplete, the precision is 56 bits, but the last computation is 57 bits. This causes a new value of %e to be computed. The subsequent call to beta_incomplete, fpprec is 56 again. fpe rounds the 57 bit result to 56 bits, which causes the value of e to change off by one bit.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2910437&group_id=4933 
From: SourceForge.net <noreply@so...>  20091208 03:28:03

Bugs item #2910437, was opened at 20091207 22:28 Message generated for change (Tracker Item Submitted) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2910437&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: 7 Private: No Submitted By: Raymond Toy (rtoy) Assigned to: Nobody/Anonymous (nobody) Summary: nonrepeatable beta_incomplete(1b0,1,z) Initial Comment: This is totally unexpected and incorrect: (%i1) beta_incomplete(1b0,1,z); (%o1) 1.0b0 z (%i2) beta_incomplete(1b0,1,z); (%o2) 1.000000000000001b0 z I have no idea what the problem is.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2910437&group_id=4933 
From: SourceForge.net <noreply@so...>  20091208 02:45:55

Bugs item #2909980, was opened at 20091207 07:26 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2909980&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: Clarphimous (clarphimous) Assigned to: Nobody/Anonymous (nobody) Summary: optimization for log of bfloats Initial Comment: bfloats can store very large and very small numbers, and I found out that the log() function takes a long time for very large and very small bfloats. I do not know their binary representations, but it may be possible to decrease the time needed by logarithmic simplification. I have found that in general, when fpprec is 3/2 or greater than the absolute value of the exponent (in decimal), it is faster to use this simplification. That's a broad estimation, though. With negative exponents, the ratio is slightly higher. Also, it may turn out completely different when coded. I did not have the same improved results with regular floats, so this simplification may already be implemented with them. First, an extreme example: fpprec:50; fun1():=log(3b1000000); fun2():=1000000*log(10b0)+log(3b0); fun3():=log(3b1000000); fun4():=1000000*log(10b0)+log(3b0); timer(fun1,fun2,fun3,fun4); fun1(); fun2(); fun3(); fun4(); timer_info(fun1,fun2,fun3,fun4); http://www.disillusionary.com/files/log1.png Next, a more reasonable example: fpprec:150; fun5():=for i:0 step 1 thru 1000 do x:log(7b100); fun6():=for i:0 step 1 thru 1000 do y:100*log(10b0)+log(7b0); timer(fun5,fun6); fun5(); x; fun6(); y; timer_info(fun5,fun6); http://www.disillusionary.com/files/log2.png  >Comment By: Raymond Toy (rtoy) Date: 20091207 21:45 Message: I have implemented this change. Some examples, using cmucl on a mac mini: x:2b1000000; y:2b1000000; fpprec:50; (%i4) log(x); Evaluation took 21.6700 seconds (23.2400 elapsed) using 2360.417 MB. (%o4) 2.3025857861412262439632949548375584044564573860171b6 (%i6) log(y); Evaluation took 27.3200 seconds (33.3400 elapsed) using 3021.686 MB. (%o6)  2.3025843998468651240726820374522427494245334131286b6 With the new code: (%i7) log(x); Evaluation took 0.0100 seconds (0.0000 elapsed) using 137.609 KB. (%o7) 2.3025857861412262439632949548375584044564573860171b6 (%i8) log(y); Evaluation took 0.0000 seconds (0.0000 elapsed) using 34.883 KB. (%o8)  2.3025843998468651240726820374522427494245334131287b6 I will check in this change soon.  Comment By: Raymond Toy (rtoy) Date: 20091207 14:34 Message: You are correct. Maxima represents bfloats as, essentially, frac * 2^exp, where 1/2 < frac <= 1. The log routine does not take advantage of this fact. Instead, the algorithm removes powers of e until the result is small and computes the log of that. Instead we should just compute log(f) and use a cached value of log(2). I'll try to fix this. Using this fact should also help quite a bit in accuracy too.  Comment By: Clarphimous (clarphimous) Date: 20091207 07:39 Message: correction: "when the absolute value of the exponent (in decimal) is greater than 2/3rds of fpprec"  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2909980&group_id=4933 
From: SourceForge.net <noreply@so...>  20091208 02:20:28

Bugs item #1556627, was opened at 20060911 20:07 Message generated for change (Settings changed) made by sfrobot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1556627&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  Solving equations Group: None >Status: Closed Resolution: Works For Me Priority: 5 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: solve & sign called on imaginary Initial Comment: This example is ridiculous, but this error shouldn't happen: x^1616*x^15+120*x^14560*x^13+1800*x^124128*x^11+6688*x^107040*x^9+2304*x^8+9728*x^729120*x^6+48768*x^558560*x^4+56576* x^343008*x^2+20992*x4544=0 (%i165) solve(%,x); `sign' called on an imaginary argument: sqrt(125*sqrt(6)) Barton  >Comment By: SourceForge Robot (sfrobot) Date: 20091208 02:20 Message: This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker).  Comment By: Dieter Kaiser (crategus) Date: 20091123 23:40 Message: I think the error is no longer present in Maxima 5.19post. We had a lot of improvements of the code for complex expressions since the version 5.10. This might be the reason that we no longer get the error. The result is: (%i34) eq; (%o34) x^1616*x^15+120*x^14560*x^13+1800*x^124128*x^11+6688*x^107040*x^9 +2304*x^8+9728*x^729120*x^6+48768*x^558560*x^4+56576*x^3 43008*x^2+20992*x4544 = 0 (%i35) solve(eq,x),algebraic:true; (%o35) [x = 1sqrt(sqrt(6^(3/2)4*sqrt(125*sqrt(6))+5)), x = sqrt(sqrt(6^(3/2)4*sqrt(125*sqrt(6))+5))+1, x = 1(6^(3/2)4*sqrt(125*sqrt(6))+5)^(1/4), x = (6^(3/2)4*sqrt(125*sqrt(6))+5)^(1/4)+1, x = 1sqrt(sqrt(6^(3/2)+4*sqrt(125*sqrt(6))+5)), x = sqrt(sqrt(6^(3/2)+4*sqrt(125*sqrt(6))+5))+1, x = 1(6^(3/2)+4*sqrt(125*sqrt(6))+5)^(1/4), x = (6^(3/2)+4*sqrt(125*sqrt(6))+5)^(1/4)+1, x = 1(6^(3/2)4*sqrt(5*sqrt(6)+12)+5)^(1/4)*%i, x = (6^(3/2)4*sqrt(5*sqrt(6)+12)+5)^(1/4)*%i+1, x = 1(6^(3/2)4*sqrt(5*sqrt(6)+12)+5)^(1/4), x = (6^(3/2)4*sqrt(5*sqrt(6)+12)+5)^(1/4)+1, x = 1(6^(3/2)+4*sqrt(5*sqrt(6)+12)+5)^(1/4)*%i, x = (6^(3/2)+4*sqrt(5*sqrt(6)+12)+5)^(1/4)*%i+1, x = 1(6^(3/2)+4*sqrt(5*sqrt(6)+12)+5)^(1/4), x = (6^(3/2)+4*sqrt(5*sqrt(6)+12)+5)^(1/4)+1] That is equivalent to the result with algebraic:false: (%i36) solve(eq,x),algebraic:false; (%o36) [x = 1sqrt(sqrt(6^(3/2)4*sqrt(125*sqrt(6))+5)), x = sqrt(sqrt(6^(3/2)4*sqrt(125*sqrt(6))+5))+1, x = 1(6^(3/2)4*sqrt(125*sqrt(6))+5)^(1/4), x = (6^(3/2)4*sqrt(125*sqrt(6))+5)^(1/4)+1, x = 1sqrt(sqrt(6^(3/2)+4*sqrt(125*sqrt(6))+5)), x = sqrt(sqrt(6^(3/2)+4*sqrt(125*sqrt(6))+5))+1, x = 1(6^(3/2)+4*sqrt(125*sqrt(6))+5)^(1/4), x = (6^(3/2)+4*sqrt(125*sqrt(6))+5)^(1/4)+1, x = 1(6^(3/2)4*sqrt(5*sqrt(6)+12)+5)^(1/4)*%i, x = (6^(3/2)4*sqrt(5*sqrt(6)+12)+5)^(1/4)*%i+1, x = 1(6^(3/2)4*sqrt(5*sqrt(6)+12)+5)^(1/4), x = (6^(3/2)4*sqrt(5*sqrt(6)+12)+5)^(1/4)+1, x = 1(6^(3/2)+4*sqrt(5*sqrt(6)+12)+5)^(1/4)*%i, x = (6^(3/2)+4*sqrt(5*sqrt(6)+12)+5)^(1/4)*%i+1, x = 1(6^(3/2)+4*sqrt(5*sqrt(6)+12)+5)^(1/4), x = (6^(3/2)+4*sqrt(5*sqrt(6)+12)+5)^(1/4)+1] Setting the status to pending and the resolution to "works for me". Dieter Kaiser  Comment By: Barton Willis (willisbl) Date: 20061210 12:19 Message: Logged In: YES user_id=895922 Originator: YES I'm guessing that I had algebraic : true. Then: (%i1) x^1616*x^15+120*x^14560*x^13+1800*x^124128*x^11+6688*x^107040*x^9+2304*x^8+9728*x^7 29120*x^6+48768*x^558560*x^4+56576* x^343008*x^2+20992*x4544=0$ (%i2) solve(%i1,x), algebraic : true; `sign' called on an imaginary argument: sqrt(125*sqrt(6))  an error. Quitting. To debug this try debugmode(true); (%i3) solve(%i1,x), algebraic : false; (%o3) [x=1sqrt(sqrt(4*6^(1/4)*sqrt(52*sqrt(6))*%i6*sqrt(6)+5)), < deleted> Maxima version: 5.10.0 Maxima build date: 17:18 10/24/2006 host type: i686pcmingw32 lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.8  Comment By: Robert Dodier (robert_dodier) Date: 20061210 06:09 Message: Logged In: YES user_id=501686 Originator: NO I don't see this error. I get the following from solve(%, x). [x = 1sqrt(sqrt(4*6^(1/4)*sqrt(52*sqrt(6))*%i6*sqrt(6)+5)), x = sqrt(sqrt(4*6^(1/4)*sqrt(52*sqrt(6))*%i6*sqrt(6)+5))+1, x = 1(4*6^(1/4)*sqrt(52*sqrt(6))*%i6*sqrt(6)+5)^(1/4), x = (4*6^(1/4)*sqrt(52*sqrt(6))*%i6*sqrt(6)+5)^(1/4)+1, x = 1sqrt(sqrt(4*6^(1/4)*sqrt(52*sqrt(6))*%i6*sqrt(6)+5)), x = sqrt(sqrt(4*6^(1/4)*sqrt(52*sqrt(6))*%i6*sqrt(6)+5))+1, x = 1(4*6^(1/4)*sqrt(52*sqrt(6))*%i6*sqrt(6)+5)^(1/4), x = (4*6^(1/4)*sqrt(52*sqrt(6))*%i6*sqrt(6)+5)^(1/4)+1, x = 1(4*6^(1/4)*sqrt(2*sqrt(6)+5)+6*sqrt(6)+5)^(1/4)*%i, x = (4*6^(1/4)*sqrt(2*sqrt(6)+5)+6*sqrt(6)+5)^(1/4)*%i+1, x = 1(4*6^(1/4)*sqrt(2*sqrt(6)+5)+6*sqrt(6)+5)^(1/4), x = (4*6^(1/4)*sqrt(2*sqrt(6)+5)+6*sqrt(6)+5)^(1/4)+1, x = 1(4*6^(1/4)*sqrt(2*sqrt(6)+5)+6*sqrt(6)+5)^(1/4)*%i, x = (4*6^(1/4)*sqrt(2*sqrt(6)+5)+6*sqrt(6)+5)^(1/4)*%i+1, x = 1(4*6^(1/4)*sqrt(2*sqrt(6)+5)+6*sqrt(6)+5)^(1/4), x = (4*6^(1/4)*sqrt(2*sqrt(6)+5)+6*sqrt(6)+5)^(1/4)+1]$ Above result is from Clisp: Maxima version: 5.10.0cvs Maxima build date: 23:10 11/30/2006 host type: i686pclinuxgnu lispimplementationtype: CLISP lispimplementationversion: 2.38 (20060124) (built 3355931855) (memory 3373942297) I believe I get the same thing from SBCL (looks similar). Maxima version: 5.10.0cvs Maxima build date: 23:9 12/5/2006 host type: i686pclinuxgnu lispimplementationtype: SBCL lispimplementationversion: 1.0  Comment By: Nobody/Anonymous (nobody) Date: 20061118 16:09 Message: Logged In: NO On my copy of wxMaxima, it didn't show any error!  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1556627&group_id=4933 