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}
(46) 
2016 
_{Jan}
(76) 
_{Feb}
(53) 
_{Mar}
(88) 
_{Apr}
(79) 
_{May}
(62) 
_{Jun}
(65) 
_{Jul}
(37) 
_{Aug}
(23) 
_{Sep}
(108) 
_{Oct}
(68) 
_{Nov}
(66) 
_{Dec}
(47) 
2017 
_{Jan}
(55) 
_{Feb}
(11) 
_{Mar}
(30) 
_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 

1

2

3
(10) 
4
(1) 
5
(3) 
6
(1) 
7

8
(1) 
9

10

11
(1) 
12
(6) 
13
(4) 
14
(6) 
15

16
(1) 
17
(8) 
18
(4) 
19
(6) 
20
(3) 
21
(3) 
22
(1) 
23
(3) 
24

25
(1) 
26

27

28

29
(3) 
30

31
(6) 




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

Bugs item #902290, was opened at 20040222 16:11 Message generated for change (Comment added) made by macrakis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=902290&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: 8 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: Nonsimplifying nounforms: abs, realpart, carg, etc. Initial Comment: declare(q,complex)$ expr: rectform(q) => 'realpart(q) + %i * 'imagpart(q) subst(1,q,expr) => 'realpart(1) + %i * 'imagpart(1) (no simplification!)  Several Maxima mathematical functions do not simplify correctly as nounforms. As a general rule, simplifications should happen with all mathematicalfunction nounforms. For example, sin(0) == 'sin(0) == cos(%pi/2) == 'cos(%pi/2) == 0 But the following don't simplify: 'abs(1) 'realpart(1) 'imagpart(1) 'carg(1) Note also that cabs/carg are not treated symmetrically. cabs is an expressionmanipulating function (like factor) which can return the mathematical operator abs. But there is no mathematical operator corresponding to the expressionmanipuating function carg (cf also bug 620246).  >Comment By: Stavros Macrakis (macrakis) Date: 20070712 17:59 Message: Logged In: YES user_id=588346 Originator: YES You are mistaken about noun/verb; it is perfectly normal for nounforms to simplify. Integrate, diff, and limit all have simplifications. There is no clear line between noun simplifications and verb operations, but in general noun simplifications are "shallow" and efficient, while verb operations are "deep" and potentially very expensive. Also, I should think that noun simplifications must be correct for all substitions of values for variables, but diff and integrate are not consistent on this: 'diff(q,x) => 'diff(q,x) correct for arbitrary q's 'integrate(q,x) => q*x assumes q is freeof x I am not sure what you mean about subst vs. ev. Subst has clear and (I think) reasonable semantics, and I don't know what you'd want to change in your "specify" function.  Comment By: Harald Geyer (hgeyer) Date: 20070712 17:39 Message: Logged In: YES user_id=929336 Originator: NO I'm not sure I agree these are bugs and I can't think how to this could be fixed without questioning the whole noun/verb concept. For example consider the following session: (%i3) integrate(f(x), x); (%o3) 'integrate(f(x),x) (%i4) subst(sin, f, %); (%o4) 'integrate(sin(x),x) It has the same problem as rectform(), but how should maxima guess what the user wants? I think the real problem is, that we recommend subst() to users for things that it wasn't meant for, because ev() has it's own sets of problems. We might try to fix subst() but most likely we would end up with something as messy as ev(). IMO the this problem should be addressed by a) better explaining the noun/verb concept to users b) invent a new function  say specify()  which fills the gap between subst() and ev()  Comment By: Barton Willis (willisbl) Date: 20070112 13:55 Message: Logged In: YES user_id=895922 Originator: NO One observation about the simpabs code: if the special expandp is 1, signum1 will always return 1 for a sum. Since mminusp uses signum1, this means that the absolute value function will not apply the reflection simplification: (%i2) :lisp(setf expandp t); T (%i2) abs(ab)  abs(ba); (%o2) abs(ab)abs(ba) I don't think expandp ever gets set to true. So it's not a bug, I guess. If we want to make the simpabs reflection rule work the same as the trig reflection rules, we could: (setf (get '%mabs 'operators) 'simpabs) (setf (get 'mabs 'reflectionrule) #'evenfunctionreflect) (defmfun simpabs (x y z) (oneargcheck x) (setq y (simpcheck (cadr x) z)) (cond ((numberp y) (abs y)) ((or (ratnump y) ($bfloatp y)) (list (car y) (abs (cadr y)) (caddr y))) ((eq (setq z (csign y)) t) (cabs y)) ((memq z '($pos $pz)) y) ((memq z '($neg $nz)) (neg y)) ((eq z '$zero) 0) ((and (mexptp y) (integerp (caddr y))) (list (car y) (simpabs (list '(mabs) (cadr y)) nil t) (caddr y))) ((mtimesp y) (muln (mapcar #'(lambda (u) (simpabs (list '(mabs) u) nil t)) (cdr y)) t)) ((applyreflectionsimp (mop x) y t)) ;;((mminusp y) (list '(mabs simp) (neg y))) ((and (mbagp y) $listarith) ;; < I appended this!!! (cons (car y) (mapcar #'(lambda (u) (simpabs (list '(mabs) u) nil t)) (cdr y)))) (t (eqtest (list '(mabs) y) x))))  Comment By: Barton Willis (willisbl) Date: 20070112 06:25 Message: Logged In: YES user_id=895922 Originator: NO Isn't the 'abs(1) > abs(1) bug a noun / verb confusion (mabs vs %mabs)? Just doing (setf (get '%mabs 'operators) 'simpabs) allows 'abs(1) > 1. The test suite is OK with (setf (get '%mabs 'operators) 'simpabs).  Comment By: Robert Dodier (robert_dodier) Date: 20060723 14:41 Message: Logged In: YES user_id=501686 Observed in 5.9.3cvs. Also increasing the priority  this is a very weak point for Maxima.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=902290&group_id=4933 
From: SourceForge.net <noreply@so...>  20070712 21:39:26

Bugs item #902290, was opened at 20040222 22:11 Message generated for change (Comment added) made by hgeyer You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=902290&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: 8 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: Nonsimplifying nounforms: abs, realpart, carg, etc. Initial Comment: declare(q,complex)$ expr: rectform(q) => 'realpart(q) + %i * 'imagpart(q) subst(1,q,expr) => 'realpart(1) + %i * 'imagpart(1) (no simplification!)  Several Maxima mathematical functions do not simplify correctly as nounforms. As a general rule, simplifications should happen with all mathematicalfunction nounforms. For example, sin(0) == 'sin(0) == cos(%pi/2) == 'cos(%pi/2) == 0 But the following don't simplify: 'abs(1) 'realpart(1) 'imagpart(1) 'carg(1) Note also that cabs/carg are not treated symmetrically. cabs is an expressionmanipulating function (like factor) which can return the mathematical operator abs. But there is no mathematical operator corresponding to the expressionmanipuating function carg (cf also bug 620246).  >Comment By: Harald Geyer (hgeyer) Date: 20070712 23:39 Message: Logged In: YES user_id=929336 Originator: NO I'm not sure I agree these are bugs and I can't think how to this could be fixed without questioning the whole noun/verb concept. For example consider the following session: (%i3) integrate(f(x), x); (%o3) 'integrate(f(x),x) (%i4) subst(sin, f, %); (%o4) 'integrate(sin(x),x) It has the same problem as rectform(), but how should maxima guess what the user wants? I think the real problem is, that we recommend subst() to users for things that it wasn't meant for, because ev() has it's own sets of problems. We might try to fix subst() but most likely we would end up with something as messy as ev(). IMO the this problem should be addressed by a) better explaining the noun/verb concept to users b) invent a new function  say specify()  which fills the gap between subst() and ev()  Comment By: Barton Willis (willisbl) Date: 20070112 19:55 Message: Logged In: YES user_id=895922 Originator: NO One observation about the simpabs code: if the special expandp is 1, signum1 will always return 1 for a sum. Since mminusp uses signum1, this means that the absolute value function will not apply the reflection simplification: (%i2) :lisp(setf expandp t); T (%i2) abs(ab)  abs(ba); (%o2) abs(ab)abs(ba) I don't think expandp ever gets set to true. So it's not a bug, I guess. If we want to make the simpabs reflection rule work the same as the trig reflection rules, we could: (setf (get '%mabs 'operators) 'simpabs) (setf (get 'mabs 'reflectionrule) #'evenfunctionreflect) (defmfun simpabs (x y z) (oneargcheck x) (setq y (simpcheck (cadr x) z)) (cond ((numberp y) (abs y)) ((or (ratnump y) ($bfloatp y)) (list (car y) (abs (cadr y)) (caddr y))) ((eq (setq z (csign y)) t) (cabs y)) ((memq z '($pos $pz)) y) ((memq z '($neg $nz)) (neg y)) ((eq z '$zero) 0) ((and (mexptp y) (integerp (caddr y))) (list (car y) (simpabs (list '(mabs) (cadr y)) nil t) (caddr y))) ((mtimesp y) (muln (mapcar #'(lambda (u) (simpabs (list '(mabs) u) nil t)) (cdr y)) t)) ((applyreflectionsimp (mop x) y t)) ;;((mminusp y) (list '(mabs simp) (neg y))) ((and (mbagp y) $listarith) ;; < I appended this!!! (cons (car y) (mapcar #'(lambda (u) (simpabs (list '(mabs) u) nil t)) (cdr y)))) (t (eqtest (list '(mabs) y) x))))  Comment By: Barton Willis (willisbl) Date: 20070112 12:25 Message: Logged In: YES user_id=895922 Originator: NO Isn't the 'abs(1) > abs(1) bug a noun / verb confusion (mabs vs %mabs)? Just doing (setf (get '%mabs 'operators) 'simpabs) allows 'abs(1) > 1. The test suite is OK with (setf (get '%mabs 'operators) 'simpabs).  Comment By: Robert Dodier (robert_dodier) Date: 20060723 20:41 Message: Logged In: YES user_id=501686 Observed in 5.9.3cvs. Also increasing the priority  this is a very weak point for Maxima.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=902290&group_id=4933 
From: SourceForge.net <noreply@so...>  20070712 21:07:14

Bugs item #1710774, was opened at 20070501 21:36 Message generated for change (Comment added) made by hgeyer You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1710774&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: Installation Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Troy Henderson (tlhiv) Assigned to: Vadim V. Zhytnikov (vvzhy) Summary: Windows + space in install directory Initial Comment: The default installation directory for Maxima in Windows is C:\Program Files\Maxima... which contains a space " " in the filename. Maxima will not run from the command line or from wxMaxima. Installing in, say, C:\maxima seems to work just fine.  >Comment By: Harald Geyer (hgeyer) Date: 20070712 23:07 Message: Logged In: YES user_id=929336 Originator: NO Further information about this problem can be found in the IRC logs of a discussion between tlhiv (the submitter) and myself in #maxima: http://rerun.lefant.net/~harald/maximalogs/20070501.txt http://rerun.lefant.net/~harald/maximalogs/20070618.txt I guess this bug report can be closed unless vvzhy has some additional ideas how to track this down.  Comment By: Robert Dodier (robert_dodier) Date: 20070703 02:43 Message: Logged In: YES user_id=501686 Originator: NO This doesn't look like a bug to me. Maybe someone can convince me it is a bug. I have run Maxima from a Windows command prompt many times. It is necessary to enclose the path in quote marks e.g "c:\program files\maxima\..." but this is nothing peculiar to Maxima. To the original poster: maybe something else is preventing Maxima from running. Feel free to post additional details here.  Comment By: Vadim V. Zhytnikov (vvzhy) Date: 20070506 21:03 Message: Logged In: YES user_id=366498 Originator: NO Strange, nobody reported problems with spaces in installation path for very long time. On the other hand I do know situation in which the problem could arise but newer observed it in practice before. Please post your Windows version and contents of maxima.bat file in the case when maxima instelled in C:\Program Files\Maxima.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1710774&group_id=4933 
From: SourceForge.net <noreply@so...>  20070712 09:51:37

Bugs item #1752518, was opened at 20070712 02:51 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=1752518&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: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: $ does not suppress output completely Initial Comment: typing in (%i1) 1$2$3$4$ leads to : (%i2) (%i3) (%i4) (%i5) I am using $ to supress output and be able to view more formula on screen, xmaxima still prints one line per command (command line maxima does not do this)  Maxima version: 5.12.0 Maxima build date: 15:58 6/6/2007 host type: i686redhatlinuxgnu lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.7   You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1752518&group_id=4933 
From: SourceForge.net <noreply@so...>  20070712 02:27:13

Bugs item #1571099, was opened at 20061004 23:51 Message generated for change (Comment added) made by jul059 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1571099&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: Julien B. O. (jul059) Assigned to: Nobody/Anonymous (nobody) Summary: handling of large factorials Initial Comment: evaluation of large factorials, such as 143311! leads to a value stack overflow when evaluated in wxMaxima 0.7.0a, but not in the command line version of maxima: Maxima encountered a Lisp error: Error in FORMAT [or a callee]: Value stack overflow.Automatically continuing.To reenable the Lisp debugger set *debuggerhook* to nil. The error is explicit enough to understand it is an overflow... but when trying to evaluate even larger factorials, such as 1433115!, windows simply reports a standard program failure with no message from maxima regardless of the interface you use. version used: Maxima version: 5.10.0 Maxima build date: 19:9 9/21/2006 host type: i686pcmingw32 lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.7 also using Windows XP profesionnal with SP2.  >Comment By: Julien B. O. (jul059) Date: 20070711 22:27 Message: Logged In: YES user_id=1610192 Originator: YES I have done some new testing and maxima can indeed compute 143311!$ with the config described above (regardless of the interface). It can also display if it is computed first with a:143311!$ and then displayed with a;. this does works in the console and xMaxima, but not in wxMaxima. The latter gives a stack overflow. But please note than the display is MUCH longer than the actual calculation (about 30x40x). Also, a2 can compute with 1433115!$ (about 14s) but maxima crashes on display (the standard windows failure thing). The behaviour is slightly different from what robert_dodier reported in (2).  Comment By: Robert Dodier (robert_dodier) Date: 20061021 14:38 Message: Logged In: YES user_id=501686 Interesting problem. If I had to guess I would say that GCL is not verifying whether some memory allocation has succeeded. Some additional data. (1) With Maxima 5.10.0cvs + GCL 2.6.7 + Linux, computations of a:143311!$ succeeds (3 s) and a2:1433115$ succeeds (76 s). Note that display of a and a2 is suppressed by $. (2) (Again with GCL 2.6.7) Display of a and a2 fails, however. a; yields (after a short delay) some garbage (spaces and backslashes observed on some occasions and random characters on another) and a2; causes a segfault. (3) Maxima 5.10.0 + clisp 2.38 + Linux: 143311!; yields "overflow during multiplication of large numbers". (4) Maxima 5.10.0cvs + sbcl 0.9.16: a:143311!$ takes about 100 s, and a2:1433115!$ didn't terminate within an hour. Display a; seems to take longer than I'm willing to wait.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1571099&group_id=4933 
From: SourceForge.net <noreply@so...>  20070712 01:53:59

Bugs item #1741705, was opened at 20070622 11:59 Message generated for change (Comment added) made by jul059 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1741705&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  Integration Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Raymond Toy (rtoy) Assigned to: Nobody/Anonymous (nobody) Summary: integrate(1/(sin(x)^2+1),x,0,8) wrong Initial Comment: integrate(1/(sin(x)^2+1),x,0,8) returns sqrt(2)/2*atan(sqrt(2)*tan(8)) + %pi/sqrt(2) This is not right. But integrate(1/(sin(x)^2+1),x,0,5*%pi/2) returns 5*sqrt(2)*%pi/4, which is probably correct according to quad_qags. This latter integral works because intsc1 notices that the interval length is a rational multiple of %pi and breaks up the integral. However, for the former integral, intsc1 gives up because the interval length is not a multiple of %pi. Since we now have a floor function that works well, we should try to extend intsc1 to accept all numeric limits. This issue affects all integrals of trig functions that are handled by intsc1. See also the related bug 1552789.  Comment By: Julien B. O. (jul059) Date: 20070711 21:53 Message: Logged In: YES user_id=1610192 Originator: NO Just wanted to say that this bug is not present in maxima 5.10.0. In fact, it returns (sqrt(2)*atan(sqrt(2)*tan(8)))/2, which is correct.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1741705&group_id=4933 