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}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 




1
(1) 
2

3
(1) 
4
(3) 
5
(6) 
6
(3) 
7
(2) 
8
(3) 
9
(18) 
10
(9) 
11

12
(3) 
13

14
(3) 
15
(1) 
16

17
(1) 
18
(4) 
19
(1) 
20
(1) 
21

22

23

24
(1) 
25
(1) 
26
(3) 
27
(3) 
28
(1) 
29
(8) 
30
(4) 


From: SourceForge.net <noreply@so...>  20061110 23:02:30

Bugs item #1528658, was opened at 20060725 23:52 Message generated for change (Comment added) made by tlecomte You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1528658&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  Plotting Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Timothée Lecomte (tlecomte) Assigned to: Nobody/Anonymous (nobody) Summary: maxima abuses of "gnuplot persist" Initial Comment: Deat maxima developpers, A few days ago andrei_dubovik reported on gnuplot's bug tracker that maxima was not working properly with gnuplot CVS, in particular with the new wxWidgets terminal (which provides antialiased output, arguably nicer that the X11 terminal). Here is the original report : http://sourceforge.net/tracker/index.php?func=detail&aid=1527701&group_id=2055&atid=102055 And the conclusion is that maxima is abusing "gnuplot persist". The "persist" option was designed to be be used when you pipe a script to gnuplot, like that : gnuplot persist script maxima seem to rely on the fact that the implementation of "persist" with the x11 terminal makes gnuplot exits immediately after the end of the input, while the windows stay opened because they are managed by a separate process. However, gnuplot does not behave the same on Windows, neither with the new wxWidgets terminal both on Windows and Unix, because in these case gnuplot is a single process and can't exit until all windows are closed. Maxima should rather use gnuplot in one of the following two ways :  use persist but don't care about gnuplot after it is launched, ie don't wait for it.  talk to gnuplot through a pipe that is opened and kept opened for the whole maxima session. I think octave does that. As a temporary workaround, andrei_dubovik did the following : "I've created ~/.gnuplot that includes set term wxt persist Also I've created an executable shell script named gnuplot that includes /usr/local/bin/gnuplot $2& and placed this script into a directory that is earlier in $PATH then /usr/local/bin, so maxima calls my wrapper rather then gnuplot itself (there should be an option in maxima for gnuplot command name, but I don't know it). So, the bash takes the task of spawning processes in this case and it works now." Best regards, Timothée  >Comment By: Timothée Lecomte (tlecomte) Date: 20061111 00:02 Message: Logged In: YES user_id=1333817 I have fixed the new wxWidgets terminal in gnuplot so that it will use fork() and satisfy Maxima. This bug doesn't exist anymore. (The suggestion to use a pipe is still valid, but not critical)  Comment By: Robert Dodier (robert_dodier) Date: 20060727 20:45 Message: Logged In: YES user_id=501686 Assign category = Lisp Core  Plotting.  Comment By: Timothée Lecomte (tlecomte) Date: 20060726 00:26 Message: Logged In: YES user_id=1333817 I must add that if you choose the second alternative (hint hint), ie drive gnuplot through a pipe that you keep open, you will get the whole range of mousing capabilities that gnuplot offers. With "persist" and the x11 terminal, you only get the mouse coordinates. By keeping gnuplot opened, you get zooming, 3d rotation, a ruler, copy to clipboard, etc.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1528658&group_id=4933 
From: SourceForge.net <noreply@so...>  20061110 21:51:51

Bugs item #965926, was opened at 20040603 13:21 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=965926&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  Trigonometry Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: trigsimp exponentially slow on lists Initial Comment: trigsimp of a [] list can sometimes take time exponential in the length of the list. For example: trigsimp(makelist(sin(i)^2+cos(i)^2,i,1,N)) for N=4,5,... takes 0.12, 0.52, 1.50, 4.45, 13.97 secs. Also for sin(i)^2. Of course, it should take linear time. This doesn't happen  >Comment By: Raymond Toy (rtoy) Date: 20061110 16:51 Message: Logged In: YES user_id=28849 Fixed. trigsimp3 modified to handle each element of the list one at a time instead of trying to do the entire list all at once.  Comment By: Raymond Toy (rtoy) Date: 20061109 12:50 Message: Logged In: YES user_id=28849 This is probably due to the way trigsimp1 and improve work (share/trigonometry/trgsmp.mac). It looks like caused by trigsimp1 and improve, which cause quadratic behavior, I think. I think if trigsimp3 is modified to map(trigsimp1, num(expn))/map(trigsimp1,denom(expn), things will work much faster. Some care must be taken in case expn is not a list, but that's not too difficult.  Comment By: Stavros Macrakis (macrakis) Date: 20040603 13:22 Message: Logged In: YES user_id=588346 Oops, "this doesn't happen" should continue... in other cases, like sin(1)^2, sin(x)^2+cos(x)^2, etc.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=965926&group_id=4933 
From: SourceForge.net <noreply@so...>  20061110 19:46:18

Bugs item #1594330, was opened at 20061110 13:08 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1594330&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: Raymond Toy (rtoy) Assigned to: Nobody/Anonymous (nobody) Summary: limit(x*(atan(x)%pi/2),x,inf) Initial Comment: Maxima returns the nounform. The limit is 1.  >Comment By: Raymond Toy (rtoy) Date: 20061110 14:46 Message: Logged In: YES user_id=28849 Fixed.  Comment By: Raymond Toy (rtoy) Date: 20061110 13:12 Message: Logged In: YES user_id=28849 Maxima uses L'Hospital's rule on the form x/(1/(atan(x)%pi2)). Differentiating the parts just makes things even more complicated. If maxima had used the form (atan(x)%pi/2)/(1/x), one differentiation would have sufficed to produce 1. LHOPNUMDEN needs to handle this case better.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1594330&group_id=4933 
From: SourceForge.net <noreply@so...>  20061110 19:45:54

Bugs item #1469411, was opened at 20060412 13:29 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1469411&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: Includes proposed fix >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Raymond Toy (rtoy) Assigned to: Nobody/Anonymous (nobody) Summary: limit(t^2*exp(4*t/38*exp(t)),t,inf) is wrong Initial Comment: Maxima returns the noun form for the limit. But the limit should be 0 because 8*exp(t) decreases so fast that the exp term is basically exp(4*t/3) and maxima knows that limit(t^2*exp(4*t/3),t,inf) is 0.  >Comment By: Raymond Toy (rtoy) Date: 20061110 14:45 Message: Logged In: YES user_id=28849 Fixed.  Comment By: Raymond Toy (rtoy) Date: 20061109 23:54 Message: Logged In: YES user_id=28849 Maxima uses L'Hospital's rule to evaluate this limit. LHOPNUMDEN is a heuristic that decides what should be the numerator and denominator. For this problem, it changes the expression to the equivalent exp(4*t/3+8*exp(t))/(t^(2)) However, as we differentiate this, the numerator and denominator become more complex. If we left it in the form t^2/exp(4*t/3+8*exp(t)), the derivative of the numerator becomes simpler. If we modify LHOPNUMDEN so that this form is kept, maxima can determine the limit to be 0. This can be done by moving the clause (or (polyinx num var ()) ...) from near the end to just before test for the numerator containing %e. This allows this to work and the test suite passes. I'm sure there are expressions where this change in the heuristic will break other limits.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1469411&group_id=4933 
From: SourceForge.net <noreply@so...>  20061110 18:12:26

Bugs item #1594330, was opened at 20061110 13:08 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1594330&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: Open Resolution: None Priority: 5 Private: No Submitted By: Raymond Toy (rtoy) Assigned to: Nobody/Anonymous (nobody) Summary: limit(x*(atan(x)%pi/2),x,inf) Initial Comment: Maxima returns the nounform. The limit is 1.  >Comment By: Raymond Toy (rtoy) Date: 20061110 13:12 Message: Logged In: YES user_id=28849 Maxima uses L'Hospital's rule on the form x/(1/(atan(x)%pi2)). Differentiating the parts just makes things even more complicated. If maxima had used the form (atan(x)%pi/2)/(1/x), one differentiation would have sufficed to produce 1. LHOPNUMDEN needs to handle this case better.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1594330&group_id=4933 
From: SourceForge.net <noreply@so...>  20061110 18:08:35

Bugs item #1594330, was opened at 20061110 13:08 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=1594330&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: Open Resolution: None Priority: 5 Private: No Submitted By: Raymond Toy (rtoy) Assigned to: Nobody/Anonymous (nobody) Summary: limit(x*(atan(x)%pi/2),x,inf) Initial Comment: Maxima returns the nounform. The limit is 1.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1594330&group_id=4933 
From: SourceForge.net <noreply@so...>  20061110 16:28:59

Bugs item #1590528, was opened at 20061104 11:27 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1590528&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: Deleted Resolution: None Priority: 1 Private: No Submitted By: Raymond Toy (rtoy) Assigned to: Nobody/Anonymous (nobody) Summary: Does debugmode(true) actually do anything? Initial Comment: debugmode(true)$ integrate((4*x^2+8*x+4)/(17*x^4+64*x^3+96*x^2+64*x+16),x,0,inf); This should give a division by zero error, and we enter debug mode: (dbm:1) :bt (dbm:1) I tried this with gcl, clisp, and cmucl. Nothing really seems to happen. Does debugmode work for anything? At least with CMUCL, it doesn't seem to matter too much, because I can press Cc to get to CMUCL's debugger which can then produce backtraces and such.  >Comment By: Raymond Toy (rtoy) Date: 20061110 11:28 Message: Logged In: YES user_id=28849 I've removed just the "Quitting" part, and cleaned up some of the prompts. Closing this bug.  Comment By: Raymond Toy (rtoy) Date: 20061106 09:37 Message: Logged In: YES user_id=28849 After reading your comments and the examples in the user manual, I see that debugmode is useful. I also agree that we should change the "Quitting" part. However, I propose to leave the debugmode(true) part in. Even though it can't debug Lisp functions and such, it's quite useful because execution stops at the error and I can press Cc (in CMUCL) and use CMUCL's debugger to figure out where the problem is. I suppose I could use (setf *breakonsignals* t), but this is still useful.  Comment By: Robert Dodier (robert_dodier) Date: 20061105 11:11 Message: Logged In: YES user_id=501686 Maxima debugmode can print a backtrace of functions defined in Maxima by := . So far as I can tell, debugmode doesn't know anything about functions defined by defun or defmfun or defmspec. Given that most functions in Maxima are defined by defun, defmfun, and defmspec, it is not very informative to use debugmode. Since debugmode is useful in a certain context (namely debugging userdefined functions) I think we should keep it, but let's change "  an error. Quitting. To debug this try debugmode(true);" to just "  an error." (i.e. cut out the recommendation to use debugmode, which is usually not helpful, and also the "Quitting." because, in fact, Maxima is not executing (quit) nor quit()).  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1590528&group_id=4933 
From: SourceForge.net <noreply@so...>  20061110 15:34:38

Bugs item #1285104, was opened at 20050908 12:53 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1285104&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  Trigonometry Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: trigsimp and trigreduce & square roots Initial Comment: Sometimes trigsimp and trigreduce seem to make assumptions of the sign of variables. Consider: (%i1) sqrt(r^2 * cos(x)^2 + r^2 * sin(x)^2); (%o1) sqrt(r^2*sin(x)^2+r^2*cos(x)^2) (%i2) trigsimp(%o1); (%o2) r < should be r (%i3) trigreduce(%o1); (%o3) r < should be r (%i4) trigreduce(sqrt(r^2)); (%o4) abs(r) < OK here (%i5) trigsimp(sqrt(r^2)); (%o5) abs(r) < OK here too And oh my! Using z instead of r makes the problem go away. (%i9) sqrt(z^2 * cos(x)^2 + z^2 * sin(x)^2); (%o9) sqrt(sin(x)^2*z^2+cos(x)^2*z^2) (%i10) trigsimp(%); (%o10) abs(z) < OK here as well! (%i6) build_info(); Maxima version: 5.9.1.1cvs Maxima build date: 14:5 8/30/2005 host type: i686pcmingw32 lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.7 Barton  >Comment By: Raymond Toy (rtoy) Date: 20061110 10:34 Message: Logged In: YES user_id=28849 What radcan returns seems to depend on the order of the variables. radcan(sqrt(c^2*cos(b)^2+c^2*sin(b)^2)) > sqrt(sin(b)^2+cos(b)^2)*abs(c) radcan(sqrt(a^2*cos(b)^2+a^2*sin(b)^2)) > a*sqrt(sin(b)^2+cos(b)^2) This seems to be true for any variables ordered in this way. FR1 returns different things in these two cases. For the first, FR1 factors c^2*cos(b)^2+c^2*sin(b)^2 to (sin(b)^2+cos(b)^2)*c^2. In the second, it's not factored out. Don't know why.  Comment By: Robert Dodier (robert_dodier) Date: 20060812 21:07 Message: Logged In: YES user_id=501686 Observed in 5.9.3cvs.  Comment By: Raymond Toy (rtoy) Date: 20051005 09:41 Message: Logged In: YES user_id=28849 Neat. It appears to be a bug in radcan. radcan(sqrt(r^2*cos(x)^2+r^2*sin(x)^2)) returns just r*stuff, but with r replaced with z, it returns abs(z)*stuff. Tracing radcan and friends, I see that fr1 returns something different for the r version. I don't know why.  Comment By: Barton Willis (willisbl) Date: 20050910 05:35 Message: Logged In: YES user_id=895922 A possible fix: (defun sp1expt (b e) (cond ((mexptp b) (power b e)) ;;(sp1expt (cadr b) (m* e (caddr b)))) < (sp1expt x^2 1/2) > x The old code calls sp1expt after it does (a^b)^c > a^(bc). I'm not sure if that second call to sp1expt ever makes a difference. Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1285104&group_id=4933 
From: SourceForge.net <noreply@so...>  20061110 04:54:08

Bugs item #1469411, was opened at 20060412 13:29 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1469411&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: Includes proposed fix Status: Open Resolution: None Priority: 5 Private: No Submitted By: Raymond Toy (rtoy) Assigned to: Nobody/Anonymous (nobody) Summary: limit(t^2*exp(4*t/38*exp(t)),t,inf) is wrong Initial Comment: Maxima returns the noun form for the limit. But the limit should be 0 because 8*exp(t) decreases so fast that the exp term is basically exp(4*t/3) and maxima knows that limit(t^2*exp(4*t/3),t,inf) is 0.  >Comment By: Raymond Toy (rtoy) Date: 20061109 23:54 Message: Logged In: YES user_id=28849 Maxima uses L'Hospital's rule to evaluate this limit. LHOPNUMDEN is a heuristic that decides what should be the numerator and denominator. For this problem, it changes the expression to the equivalent exp(4*t/3+8*exp(t))/(t^(2)) However, as we differentiate this, the numerator and denominator become more complex. If we left it in the form t^2/exp(4*t/3+8*exp(t)), the derivative of the numerator becomes simpler. If we modify LHOPNUMDEN so that this form is kept, maxima can determine the limit to be 0. This can be done by moving the clause (or (polyinx num var ()) ...) from near the end to just before test for the numerator containing %e. This allows this to work and the test suite passes. I'm sure there are expressions where this change in the heuristic will break other limits.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1469411&group_id=4933 