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}
(62) 
_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 






1

2
(2) 
3
(1) 
4

5
(2) 
6
(2) 
7

8
(2) 
9

10

11

12
(1) 
13
(2) 
14
(2) 
15
(1) 
16

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

22
(4) 
23

24
(2) 
25
(7) 
26

27

28
(3) 
29
(8) 
30
(1) 
31
(4) 






From: SourceForge.net <noreply@so...>  20110718 20:40:55

Bugs item #3370649, was opened at 20110718 16:40 Message generated for change (Tracker Item Submitted) made by macrakis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3370649&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: 6 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: Integral with float exponent goes wrong Initial Comment: integrate(x^(1/2)*%e^x,x,0,inf) => sqrt(%pi)/2 OK integrate(x^.5*%e^x,x,0,inf) => 8545/9642 !!! This is rat(float(sqrt(%pi)/2))  why?! There is some argument that the second result should be a float (i.e. approximate number) to reflect that the input included an approximate number, but I see no reason that it should be a rat. Maxima 5.23.2 GCL 2.6.8 Windows 7  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3370649&group_id=4933 
From: SourceForge.net <noreply@so...>  20110718 19:50:33

Bugs item #635708, was opened at 20021108 22:17 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=635708&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: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: Bad display of unsimplified expr Initial Comment: f(n):=IF n = 0 THEN 1 ELSE 91919*gg(x^n+f(EV(n 1,SIMP))) simp:false; Now calculate and display f(6)*f(6) (with the display window fairly narrow, say 60 columns wide). displa generates lines that are wider than the window, which wrap around and make the display illegible (especially the exponents). I realize that unsimplified expressions are an unusual case.... I ran across this problem during a debugging session where I turned of SIMP to check something.  >Comment By: Dieter Kaiser (crategus) Date: 20110718 21:50 Message: Fixed in the function dimnary in the file displa.lisp with revision 18 Jul 2011. Closing this bug report as fixed. Dieter Kaiser  Comment By: Dieter Kaiser (crategus) Date: 20100203 01:15 Message: Sorry, but I have mixed up this problem with the problem of bug report ID: 1954693. Since Maxima 5.15 we have two problems with the 2ddisplay. I have recognised this today, because I had a look at all Maxima versions from 5.9 to 5.20 to find the differences in 2ddisplay. The problem of this bug report is present since Maxima 5.9, it is not a problem of a long denominator but of a long unsimplified expression. The problem is still present in Maxima 5.20post. Reverting the change of the title. Dieter Kaiser  Comment By: Dieter Kaiser (crategus) Date: 20100202 17:06 Message: I think this problem is not restricted to unsimplified expressions. It is a general problem of the 2ddisplay. This is the most simple example I have found to see the general problem. We take a long numerator and a long denominator. (%i1) num:a1+a2+a3+a4+a5+a6+a7+a8+a9; (%o1) a9 + a8 + a7 + a6 + a5 + a4 + a3 + a2 + a1 (%i2) denom:b1+b2+b3+b4+b5+b6+b7+b8+b9; (%o2) b9 + b8 + b7 + b6 + b5 + b4 + b3 + b2 + b1 We set linel to a small value 10. (%i4) linel:10; (%o4) 10 We display num/denom. This is a correct display. (%i5) num/denom; (%o5) (a9 + a8 + a7 + a6 + a5 + a4 + a3 + a2 + a1) /(b9 + b8 + b7 + b6 + b5 + b4 + b3 + b2 + b1) We get the error when we multiply the denominator with a further constant. The last line is no longer broken up correctly: (%i6) num/(x*denom); (%o6) (a9 + a8 + a7 + a6 + a5 + a4 + a3 + a2 + a1) /((b9 + b8 + b7 + b6 + b5 + b4 + b3 + b2 + b1) x) I had a look into the display routines. The additional constant x causes a nested expression which seems to confuse the highly recursive algorithm and the counting of space available for the expression. But I have not seen a way to correct this behaviour. Remark: The display of unsimplified matrices is easy to correct. The 2ddisplay routines have a check for unsimplified matrices. This can be removed without problems. Changing the title to reflect the issue. Dieter Kaiser  Comment By: Robert Dodier (robert_dodier) Date: 20060701 06:15 Message: Logged In: YES user_id=501686 Another bit of simp / display strangeness: simp : false; matrix ([a, b], [c, d]); Result is displayed as "matrix([a, b], [c, d])" (i.e. without the ascii art). I wonder why unsimplified matrices aren't displayed the same as simplified ones.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=635708&group_id=4933 
From: SourceForge.net <noreply@so...>  20110718 19:50:09

Bugs item #1954693, was opened at 20080430 07:26 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1954693&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: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Satoshi Adachi (satoshi_adachi) Assigned to: Nobody/Anonymous (nobody) Summary: 2D display of long denominator of nested fractional Initial Comment: Dear Developers of Maxima, I think that I met a bug of Maxima to display nested fractionals in the 2D style. If the denominator of a nested fractional is long, it is not displayed correctly. The display width controll based on the variable LINEL seems to be not effective in the denominator. Compared to this, the numerator of a nested fractional causes no such problem to be displayed even when the numerator is long. Here, I have prepared a program for demonstration:  /* * denominator_of_nested_fractional_is_not_displayed_correctly.maxima: * * The line length, which is usually controlled by the variable LINEL, * is not recognized in the denominator of a nested fractional, if the * nested fractional has a long denominator. * * S.Adachi 2008/04/29 */ /* Do not use ``display2d:false;'', since this is a problem in displaying a mathematical expression in the 2D style. */ X:product(f(i+1/2),i,0,20); Y:product(g(i+1/2),i,0,20); Z:X/Y; /* A nested fractional; its denominator is not displayed correctly. */ /* END */  This is a problem in displaying mathematical expressions in the 2D style. Accordingly, I cannot attach here the log list that is obtained by running the above program. (If I include in a bug report the mathematical expressions that are displayed in the 2D style by Maxima, the posted bug report becomes a disordered gabage in appearance.) So, please execute the above program by the command maxima b denominator_of_nested_fractional_is_not_displayed_correctly.maxima to see the phenomenon that I am reporting in this letter. I am using a console terminal with line width 80 to run the above program. It is essential for Maxima to display any mathematical expression in a correct mannar. If it is not, we cannot read the output from Maxima. So, please fix this bug. Sincerely yours, Satoshi Adachi  >Comment By: Dieter Kaiser (crategus) Date: 20110718 21:50 Message: Fixed in the function dimnary in the file displa.lisp with revision 18 Jul 2011. Closing this bug report as fixed. Dieter Kaiser  Comment By: Dieter Kaiser (crategus) Date: 20100802 23:11 Message: Again I had a look at the problem. I have found the reason in a change of the function dimnary in revision 1.37. When I revert the changes of this function I get the expected breakup of long lines. This is the routine (defun dimnary (form result lop op rop w) ; (declare (ignore op)) (if (and (consp form) ; (member (safeget (caar form) 'dimension) '(dimensioninfix dimensionnary)) (eq (caar form) op) ) (dimensionparen form result) (dimension form result lop rop w right))) We get the following for the example of the last posting: (%i1) num:a1+a2+a3+a4+a5+a6+a7+a8+a9$ (%i2) denom:b1+b2+b3+b4+b5+b6+b7+b8+b9$ (%i3) linel:10$ (%i4) num/(x*denom); (%o4) (a9 + a8 + a7 + a6 + a5 + a4 + a3 + a2 + a1) /((b9 + b8 + b7 + b6 + b5 + b4 + b3 + b2 + b1) x) The change has been introduced to get a more correct display for expressions like a * b . c > a (b . c) I have not analyzed the problem further and I have no solution to get a correct breakup of long lines. Dieter Kaiser  Comment By: Dieter Kaiser (crategus) Date: 20100203 01:04 Message: I had again a look at this problem. The example I have given in the bug report ID:635708 is a more simple example for the reported problem in this bug report. But there are two problems and this bug report is not related to the first one. The problem of this bug report is present until Maxima 5.15. In Maxima 5.14 the display of this example is correct. The example I have given in the report ID:635708 is correct in Maxima 5.14 too, but not since Maxima 5.15. This is again the more simple example: We take a long numerator and a long denominator. (%i1) num:a1+a2+a3+a4+a5+a6+a7+a8+a9; (%o1) a9 + a8 + a7 + a6 + a5 + a4 + a3 + a2 + a1 (%i2) denom:b1+b2+b3+b4+b5+b6+b7+b8+b9; (%o2) b9 + b8 + b7 + b6 + b5 + b4 + b3 + b2 + b1 We set linel to a small value 10. (%i4) linel:10; (%o4) 10 We display num/denom. This is a correct display. (%i5) num/denom; (%o5) (a9 + a8 + a7 + a6 + a5 + a4 + a3 + a2 + a1) /(b9 + b8 + b7 + b6 + b5 + b4 + b3 + b2 + b1) We get the error when we multiply the denominator with a further constant. The last line is no longer broken up correctly: (%i6) num/(x*denom); (%o6) (a9 + a8 + a7 + a6 + a5 + a4 + a3 + a2 + a1) /((b9 + b8 + b7 + b6 + b5 + b4 + b3 + b2 + b1) x) Dieter Kaiser  Comment By: Dieter Kaiser (crategus) Date: 20100202 17:40 Message: I think this bug report is related to the following bug report: ID 635708  Bad 2ddisplay of a long denominator. A 2ddisplay with a small value of linel shows that the long denominator is not broken up correctly. This seems to be a general problem. Dieter Kaiser  Comment By: Robert Dodier (robert_dodier) Date: 20080622 23:55 Message: Logged In: YES user_id=501686 Originator: NO Assign category = lisp core.  Comment By: Robert Dodier (robert_dodier) Date: 20080504 07:55 Message: Logged In: YES user_id=501686 Originator: NO Observed in Maxima 5.15.0cvs. NOT observed in 5.9.0  so I guess the display code was modified incorrectly at some point. I can try some different versions, but it will be a while. The line width doesn't appear to be important  I get incorrect output when linel:65, or linel:70, or linel:80.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1954693&group_id=4933 
From: SourceForge.net <noreply@so...>  20110718 19:42:42

Bugs item #3370589, was opened at 20110718 15:42 Message generated for change (Tracker Item Submitted) made by macrakis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3370589&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: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: abs(x)^(2*int) doesn't simplify Initial Comment: declare(n,integer)$ abs(x)^(2*n) doesn't simplify to x^(2*n). Similarly for abs(x)^(2*floor(q)). Maxima 5.23.2 on GCL 2.6.8 on Windows 7  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3370589&group_id=4933 
From: SourceForge.net <noreply@so...>  20110718 13:24:07

Bugs item #3369477, was opened at 20110717 13:16 Message generated for change (Comment added) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3369477&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: Open Resolution: None Priority: 5 Private: No Submitted By: Stefan Husmann (haawda) Assigned to: Barton Willis (willisbl) Summary: bernstein.texi missing in git Initial Comment: There is no file bernstein.texi in git, so the build of the info documentation fails.  >Comment By: Barton Willis (willisbl) Date: 20110718 08:24 Message: Sorry about thatI think this should be fixed now.  Comment By: Robert Dodier (robert_dodier) Date: 20110718 00:42 Message: Barton, I think you need to commit bernstein.texi.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3369477&group_id=4933 
From: SourceForge.net <noreply@so...>  20110718 05:43:00

Bugs item #3369477, was opened at 20110717 12:16 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3369477&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: Open Resolution: None Priority: 5 Private: No Submitted By: Stefan Husmann (haawda) >Assigned to: Barton Willis (willisbl) Summary: bernstein.texi missing in git Initial Comment: There is no file bernstein.texi in git, so the build of the info documentation fails.  >Comment By: Robert Dodier (robert_dodier) Date: 20110717 23:42 Message: Barton, I think you need to commit bernstein.texi.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3369477&group_id=4933 
From: SourceForge.net <noreply@so...>  20110718 05:16:13

Bugs item #3369856, was opened at 20110717 23:16 Message generated for change (Tracker Item Submitted) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3369856&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: Robert Dodier (robert_dodier) Assigned to: Nobody/Anonymous (nobody) Summary: special case assumed to be general in integration Initial Comment: Problem reported by Frazer Williams to the Maxima mailing list 20110715. I have reproduced his email in extenso below.  begin quoted text  Maxima 5.23.2 http://maxima.sourceforge.net using Lisp SBCL 1.0.401.fc14 (%i1) f(x):=x^(2*n)*exp((x/x0)^2); 2 n x 2 (%o1) f(x) := x exp( () ) x0 (%i2) integrate(f(x),x,inf,inf); Is 2 n + 1 positive, negative, or zero? p; Is 2 n an integer? y; (%o2) 0 The result should be zero only if 2*n is odd. If we declare n to be an integer, the correct result is produced. (%i3) declare(n,integer); (%o3) done (%i4) integrate(f(x),x,inf,inf); Is 2 n + 1 positive, negative, or zero? p; Is x0 positive or negative? p; 2 n + 1 2 n + 1 (%o4) gamma() x0 2  end quoted text   You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3369856&group_id=4933 