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
(8) 
2
(7) 
3
(12) 
4
(4) 
5
(4) 
6
(4) 
7
(12) 
8
(2) 
9
(3) 
10
(4) 
11
(7) 
12

13
(1) 
14
(3) 
15
(6) 
16
(1) 
17
(2) 
18
(11) 
19
(1) 
20
(3) 
21
(4) 
22
(2) 
23
(2) 
24
(2) 
25

26
(1) 
27
(4) 
28
(4) 
29
(1) 
30
(3) 
31
(3) 




From: SourceForge.net <noreply@so...>  20090315 21:24:09

Bugs item #2658058, was opened at 20090303 12:13 Message generated for change (Comment added) made by dgildea You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2658058&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: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Stack overflow when taking a limit Initial Comment: Test code assume(A_par>0); assume(B_par>0); assume(n>1); beta_par:A_par*(n^21)/((2*(n^21)+1)/sqrt(n^21)*log(n+sqrt(n^21))+B_par*n)/n/(6*%pi); limit(beta_par,n, infinity); on a Debian testing machine (amd64 architecture, maxima installed from standard repositories) this is the output (%i44) assume(A_par > 0) (%o44) [redundant] (%i45) assume(B_par > 0) (%o45) [redundant] (%i46) assume(n > 1) (%o46) [redundant] 2 A_par (n  1)  2 2 (1 + 2 (n  1)) log(sqrt(n  1) + n) B_par n +  2 sqrt(n  1)  n (%i47) beta_par :  6 %pi 2 A_par (n  1) (%o47)  2 2 (2 (n  1) + 1) log(sqrt(n  1) + n) 6 %pi n ( + B_par n) 2 sqrt(n  1) (%i48) limit(beta_par, n, infinity) Is (n  1) (n + 1) positive, negative, or zero? positive; 2 Is sqrt(n  1) + n positive or negative? positive; Is n  1 positive, negative, or zero? positive; Maxima encountered a Lisp error: Error in $LIMIT [or a callee]: Bind stack overflow. Automatically continuing. To reenable the Lisp debugger set *debuggerhook* to nil. (%o49) friction.max (%i50)  >Comment By: Dan Gildea (dgildea) Date: 20090315 17:23 Message: This was fixed in limit.lisp rev 1.62, on Feb 1, 2009.  Comment By: Robert Dodier (robert_dodier) Date: 20090306 23:42 Message: Stack overflow not observed with current CVS on Linux with GCL 2.6.8, Clisp 2.46, or ECL 8.12.0. (Instead it just prints a message "sign of infinity is undefined".) If we can get someone to verify the stack overflow behavior has also gone away on Windows, we can close this report.  Comment By: Raymond Toy (rtoy) Date: 20090303 12:23 Message: Perhaps you really meant to say limit(beta_par,n,inf) instead of limit(beta_par,n,infinity)? "inf" is the positive real infinity; "infinity" is the complex infinity. It's a bug that maxima gets an error here with a stack overflow. But that doesn't happen with the current CVS version. I just get an error that the sign of infinity is undefined.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2658058&group_id=4933 
From: SourceForge.net <noreply@so...>  20090315 21:22:37

Bugs item #1419046, was opened at 20060130 15:31 Message generated for change (Comment added) made by dgildea You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1419046&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  Assume Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Barton Willis (willisbl) >Assigned to: Dan Gildea (dgildea) Summary: sign bug Initial Comment: (%i14) 1sqrt(1x); (%o14) 1sqrt(1x) (%i15) x * diff(%,x)/%; (%o15) x/(2*(1sqrt(1x))*sqrt(1x)) (%i16) abs(%); Yeechs! numerator is x. (%o16) x/(2*abs(sqrt(1x)1)*sqrt(1x)) Let's check the sign at 0.1 (%i17) subst(x=0.1,%); (%o17) 0.97673129462279451 Try again using cabs; this looks OK: (%i18) 1sqrt(1x); (%o18) 1sqrt(1x) (%i19) x * diff(%,x)/%; (%o19) x/(2*(1sqrt(1x))*sqrt(1x)) (%i20) cabs(%); Is x  1 positive, negative, or zero? neg; (%o20) abs(x)/abs(2*x+2*sqrt(1x)2) Let's try again  this time I'll trace sign (%i23) x * diff(%,x)/%; (%o23) x/(2*(1sqrt(1x))*sqrt(1x)) (%i24) abs(%); 1 Enter sign [x/(2*(1sqrt(1x))*sqrt(1x))] 1 Exit sign pn 1 Enter sign [1/(1sqrt(1x))] 1 Exit sign pn 1 Enter sign [1sqrt(1x)] 1 Exit sign pn 1 Enter sign [1/sqrt(1x)] 1 Exit sign pos 1 Enter sign [x] 1 Exit sign pos < bogus (%i30) build_info(); Maxima version: 5.9.2.19cvs Maxima build date: 10:34 1/27/2006 host type: i686pcmingw32 lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.7 Barton  >Comment By: Dan Gildea (dgildea) Date: 20090315 17:21 Message: Fixed in compar.lisp rev 1.46. (%i1) 1sqrt(1x); (%o1) 1sqrt(1x) (%i2) x * diff(%,x)/%; (%o2) x/(2*(1sqrt(1x))*sqrt(1x)) (%i3) abs(%); (%o3) abs(x)/(2*abs(sqrt(1x)1)*sqrt(1x))  Comment By: Robert Dodier (robert_dodier) Date: 20060814 23:11 Message: Logged In: YES user_id=501686 Observed in 5.9.3.99rc1 / Clisp 2.38.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1419046&group_id=4933 
From: SourceForge.net <noreply@so...>  20090315 21:18:58

Bugs item #1981623, was opened at 20080601 23:39 Message generated for change (Comment added) made by dgildea You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1981623&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: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Satoshi Adachi (satoshi_adachi) >Assigned to: Dan Gildea (dgildea) Summary: wrong sign of sqrt() Initial Comment: Dear Developers of Maxima, I found that sqrt() returns the incorrect expression that has the sign opposite to the ture expression when some certain argument is given to sqrt(). Namely, sqrt() interprets incorrectly the database that is prepared by assume(). Here is an demonstration program:  /* * wrong_sign_of_sqrt.maxima * * S.Adachi 2008/06/01 */ display2d:false; assume(x >= 0, x <= 1); correct_result_1:sqrt((x1)^2); correct_result_2:sqrt(1/(x1)^2); correct_result_3:sqrt(a*(x1)^2); incorrect_result_1:sqrt(a/(x1)^2); incorrect_result_2:sqrt(a^2/(x1)^2); incorrect_result_3:sqrt(x^2/(x1)^2); /* END */  The result of execution is as follows:  Maxima 5.14.0cvs http://maxima.sourceforge.net Using Lisp GNU Common Lisp (GCL) GCL 2.6.7 (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) batch(wrong_sign_of_sqrt.maxima) batching #p/Volumes/HFS+2/home/adachi/work/299/wrong_sign_of_sqrt.maxima (%i2) display2d : false (%o2) false (%i3) assume(x >= 0,x <= 1) (%o3) [x >= 0,x <= 1] (%i4) correct_result_1:sqrt((x1)^2) (%o4) 1x (%i5) correct_result_2:sqrt(1/(x1)^2) (%o5) 1/(1x) (%i6) correct_result_3:sqrt(a*(x1)^2) (%o6) sqrt(a)*(1x) (%i7) incorrect_result_1:sqrt(a/(x1)^2) (%o7) sqrt(a)/(x1) (%i8) incorrect_result_2:sqrt(a^2/(x1)^2) (%o8) abs(a)/(x1) (%i9) incorrect_result_3:sqrt(x^2/(x1)^2) (%o9) x/(x1) (%o10) "wrong_sign_of_sqrt.maxima"  I wonder why sqrt() returns the wrong expression if sqrt((x1)^2) appears in the denominator of some fraction in the argument that is more complex than some threshold (e.g. the numerator is not a simple number or something like that). I think that this is a very severe bug of sqrt() and the database that is prepared by assume(). This bug puts many user programs to the state producing many wrong results. Please fix this severe bug. Sincerely yours, Satoshi Adachi  >Comment By: Dan Gildea (dgildea) Date: 20090315 17:18 Message: Fixed in compar.lisp rev 1.46. (%i2) assume(x >= 0, x <= 1); (%o2) [x >= 0,x <= 1] (%i3) correct_result_1:sqrt((x1)^2); (%o3) 1x (%i4) correct_result_2:sqrt(1/(x1)^2); (%o4) 1/(1x) (%i5) correct_result_3:sqrt(a*(x1)^2); (%o5) sqrt(a)*(1x) (%i6) incorrect_result_1:sqrt(a/(x1)^2); (%o6) sqrt(a)/(1x) (%i7) incorrect_result_2:sqrt(a^2/(x1)^2); (%o7) abs(a)/(1x) (%i8) incorrect_result_3:sqrt(x^2/(x1)^2); (%o8) x/(1x)  Comment By: Dan Gildea (dgildea) Date: 20090215 16:06 Message: Tracing dcompare shows that the results of comparisons with x change in the middle of the computation. (%i4) sqrt(a/(x1)^2); 0: (DCOMPARE $X 1) 0: DCOMPARE returned $NZ 0: (DCOMPARE $X 1.0) 0: DCOMPARE returned $PNZ 0: (DCOMPARE $X 0) 0: DCOMPARE returned $PZ 0: (DCOMPARE $X 1) 0: DCOMPARE returned $POS Similar behavior observed with bug 1419046 "sign bug".  Comment By: Raymond Toy (rtoy) Date: 20080730 14:15 Message: Logged In: YES user_id=28849 Originator: NO FWIW, the code that handles this is simpexpt in simp.lisp. For the case of sqrt((x1)^2), the e1 tag is done, and the second cond case is executed. The result is correct in this case. However, for sqrt(1/(x1)^2), the e1 tag is also done, but the first cond case is executed because the (noneg (cadr gr)) returns nonnil. In the former case the noneg call returns NIL, which is correct because x1 is not negative. I don't know why the two different calls to noneg return different values for x1. NIL should be returned in each case because x <= 1. There is one difference, though. The z arg to simpexpt is NIL for the case that works and T for the case that is incorrect.  Comment By: Robert Dodier (robert_dodier) Date: 20080623 10:26 Message: Logged In: YES user_id=501686 Originator: NO Assign category = lisp core / simplification.  Comment By: Satoshi Adachi (satoshi_adachi) Date: 20080611 02:50 Message: Logged In: YES user_id=1953419 Originator: YES Thank you for your suggestion. But, your suggestion just forbids Maxima to simplify certain expressions in order not to produce wrong results. Is someone trying to fix this bug now? If not yet, I will read lisp source code in some future (maybe, several months later) to try to fix the problem...  Comment By: Barton Willis (willisbl) Date: 20080604 07:20 Message: Logged In: YES user_id=895922 Originator: NO As a workaround, you might try setting radexpand to false: (%i1) assume(0 < x, x <= 1)$ (%i2) sqrt(a/(x1)^2); (%o2) sqrt(a)/(x1) (%i3) sqrt(a/(x1)^2), radexpand : false; (%o3) sqrt(a/(x1)^2)  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1981623&group_id=4933 
From: SourceForge.net <noreply@so...>  20090315 21:06:49

Bugs item #2687962, was opened at 20090315 22:06 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=2687962&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: Dieter Kaiser (crategus) Assigned to: Nobody/Anonymous (nobody) Summary: hgfred([3/2,1],[1/2],t) division by zero Initial Comment: Working on the Laplace transfom for the Exponential Integral E, I get a problem with half integral values for the order of the Exponential Integral E. This is one of the hypergeometric functions needed by the algorithm: %i17) hgfred([3/2,1],[1/2],t); Division by 0  an error. To debug this try debugmode(true); It works for positive half integral values and a=1/2 but not for a=3/2, a=5/2, a=7/2, ... This would be a solution for a=3/2,b=1,c=1/2 (see wolfram.function.com): hgfred([3/2,1],[1/2],t) = 1+3*t3*t^(3/2)*atan(sqrt(t)) Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2687962&group_id=4933 
From: SourceForge.net <noreply@so...>  20090315 19:52:01

Bugs item #2672976, was opened at 20090308 14:03 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2672976&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: Xmaxima or other UI Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: David Ström (dmaj26) >Assigned to: Andrej Vodopivec (andrejv) Summary: wxMaxima 0.8.1: set logscale x gives error Initial Comment: Maxima version: 5.17.1 Maxima build date: 19:10 12/18/2008 host type: i686pcmingw32 lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.8 Button: Plot 2D... i.e: sin(x) option: set logscale x; set grid; gives input line: (%i) wxplot2d([sin(x)], [x,0,100], [gnuplot_preamble, "set logscale x; set grid;"])$ and (%t) Error It could have changed [x,5,5] to [x,1,100] instead, like 'set logscale y' automatically changes yvalues to 'From: 0.001 To: 1' in the case of sin(x). If I change the variable: x from: 0 to e.g. 0.01, 0.1 or 1 this is not really a bug, but why does Maxima change the xvalues automtically at all, if the suggested values are not allowed?  >Comment By: Robert Dodier (robert_dodier) Date: 20090315 13:51 Message: I've added code to src/plot.lisp (r1.139) to ensure that x and y bounds are positive when the logx and logy options are in effect. Closing this report as fixed accordingly. However please bear in mind that wxMaxima uses its own plotting function (wxplot2d) which probably needs to be fixed separately. Since wxMaxima is a separate project, I'm going to close this report and assign it to Andrej V and let him take it from here.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2672976&group_id=4933 
From: SourceForge.net <noreply@so...>  20090315 10:15:58

Bugs item #2687528, was opened at 20090315 10:15 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=2687528&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: Wrong solution to ode2 Initial Comment: I tried to solve this very simple ODE. When a=0 the solution is wrong; furthermore I get a division by "a" in the output. ode2('diff(y,t,2)a*'diff(y,t)=t,y,t); Is a zero or nonzero?zero; y=(%k2*t+%k1)*%e^((a*t)/2)(4*a*t+16)/a^3 The correct answer should be y=t^3/6+%k2*t+%k1 Thanks. Franco Buratti bufranz@...  Maxima version: 5.17.0 Maxima build date: 19:8 12/4/2008 host type: i686pcmingw32 lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.8   You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2687528&group_id=4933 