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}
(15) 
_{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...>  20110722 18:27:38

Bugs item #3369856, was opened at 20110718 01:16 Message generated for change (Comment added) made by dgildea 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: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Robert Dodier (robert_dodier) >Assigned to: Dan Gildea (dgildea) 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   >Comment By: Dan Gildea (dgildea) Date: 20110722 14:27 Message: Fixed in defint.lisp. Look for discontinuities in antiderivative.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3369856&group_id=4933 
From: SourceForge.net <noreply@so...>  20110722 18:26:56

Bugs item #3292033, was opened at 20110423 11:24 Message generated for change (Comment added) made by dgildea You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3292033&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: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: https://www.google.com/accounts () >Assigned to: Dan Gildea (dgildea) Summary: error in integrating exp(x)*sinh(sqrt(x)) Initial Comment: Maxima 5.24.0 http://maxima.sourceforge.net using Lisp SBCL 1.0.24 (%i3) integrate(exp(x)*sinh(sqrt(x)),x,0,inf); (%o3) 0 (%i4) quad_qagi(exp(x)*sinh(sqrt(x)),x,0,inf); (%o4) [1.137937897234377, 5.171862937913829e11, 345, 0]  >Comment By: Dan Gildea (dgildea) Date: 20110722 14:26 Message: Fixed in defint.lisp. Look for discontinuities in antiderivative.  Comment By: Dan Gildea (dgildea) Date: 20110524 12:22 Message: A simpler test case: (%i16) integrate(exp(sqrt(x)x), x, 0, inf); (%o16) %e^(1/4)*gamma_incomplete(1,1/4)%e^(1/4)*gamma_incomplete(1/2,1/4)/2 +2*%e^(1/4)*sqrt(%pi) (%i17) float(%); (%o17) 5.006110228172447 (%i18) quad_qagi(exp(sqrt(x)x), x, 0, inf); (%o18) [2.730234433703704,9.207745677031198e11,345,0] The problem seems to be caused by the fact that the indefinite integral: (%i15) integrate(exp(sqrt(x)x), x); (%o15) %e^(1/4)*%i *(%i*gamma_incomplete(1,(12*sqrt(x))^2/4)*(12*sqrt(x))^2 /(2*sqrt(x)1)^2 %i*gamma_incomplete(1/2,(12*sqrt(x))^2/4)*(12*sqrt(x)) /(2*abs(2*sqrt(x)1))) has a discontinuity at x=1/4. This integral is computed by case m2exptype5 in integrateexpspecial. Mathematica gives the indefinite integral as: exp(sqrt(x)x)+exp(1/4)*sqrt(%pi)*erf((1+2*sqrt(x))/2)/2; which results in the correct value for the definite integral in this case.  Comment By: Aleksas (aleksasd) Date: 20110518 14:20 Message: solving with Maxima 5.24.0: Dwight Tables of integrals 862.04 (%i1) declare(integrate,linear)$ assume(y>0)$ (%i3) S:'integrate(exp(x)*sinh(sqrt(x)),x,0,inf)$ (%i4) exponentialize(%); (%o4) integrate((%e^sqrt(x)%e^(sqrt(x)))*%e^(x),x,0,inf)/2 (%i5) expand(%); (%o5) integrate(%e^(sqrt(x)x),x,0,inf)/2integrate(%e^(xsqrt(x)),x,0,inf)/2 (%i6) S1:changevar(%, y=sqrt(x), y, x); (%o6) integrate(y*%e^(yy^2),y,0,inf)integrate(y*%e^(y^2y),y,0,inf) (%i10) changevar(part(S1,1),2*y1=z,z,y)+ changevar(part(S1,2),2*y+1=z,z,y); (%o10) integrate((z+1)*%e^((z^21)/4),z,1,inf)/4integrate((z1)*%e^((z^21)/4),z,1,inf)/4 (%i8) ev(%, nouns),ratsimp; (%o8) (%e^(1/4)*sqrt(%pi))/2 (%i9) float(%), numer; (%o9) 1.137937897234373 Where is the error? wrong: (%i1) R:integrate(y*%e^(yy^2),y,0,inf); (%o1) (%e^(1/4)*gamma_incomplete(1,1/4))/2(%e^(1/4)*gamma_incomplete(1/2,1/4))/4 (%i2) float(R), numer; (%o2) 0.22717931961748 (%i3) quad_qagi(y*%e^(yy^2), y, 0, inf); (%o3) [1.365117216851849,7.6857545173630158*10^10,165,0] correct: (%i4) R1:integrate(y*%e^(yy^2),y,0,inf); (%o4) (%e^(1/4)*gamma_incomplete(1,1/4))/2(%e^(1/4)*gamma_incomplete(1/2,1/4))/4 (%i5) float(R1), numer; (%o5) 0.22717931961748 (%i6) quad_qagi(y*%e^(yy^2), y, 0, inf); (%o6) [0.22717931961748,1.4118104693665376*10^9,135,0] Aleksas D  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3292033&group_id=4933 
From: SourceForge.net <noreply@so...>  20110722 18:25:58

Bugs item #3311145, was opened at 20110603 11:58 Message generated for change (Comment added) made by dgildea You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3311145&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: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Barton Willis (willisbl) >Assigned to: Dan Gildea (dgildea) Summary: integrate(x^m * exp(x^2),x,minf,inf) > 0 Initial Comment: Bogus: (%i1) integrate(x^m * exp(x^2),x,minf,inf); "Is "m+1" positive, negative, or zero?"pos; "Is "m" an "integer"?"yes; (%o1) 0  >Comment By: Dan Gildea (dgildea) Date: 20110722 14:25 Message: Fixed in defint.lisp. Look for discontinuities in antiderivative.  Comment By: Aleksas (aleksasd) Date: 20110614 08:58 Message: All correct: (%i1) kill(all)$ (%i1) declare(m,even); assume(m+1>0); (%o1) done (%o2) [m>1] (%i3) integrate(x^m * exp(x^2),x,minf,inf); (%o3) gamma((m+1)/2) (%i4) kill(all)$ (%i1) declare(m,odd); assume(m+1>0); (%o1) done (%o2) [m>1] (%i3) integrate(x^m * exp(x^2),x,minf,inf); (%o3) 0 (%i4) kill(all)$ (%i1) integrate(x^(1) * exp(x^2),x,minf,inf); Principal Value (%o1) 0 (%i2) integrate(x^(1) * exp(x^2),x,0,inf); defint: integral is divergent.  an error. To debug this try: debugmode(true); (%i3) integrate(x^(1) * exp(x^2),x,minf,0); defint: integral is divergent.  an error. To debug this try: debugmode(true); (%i4) kill(all)$ (%i1) assume(m+1<0); (%o1) [m<1] (%i2) /* Principal Value */ integrate(x^m * exp(x^2),x,minf,inf); (%o2) 0 (%i3) integrate(x^m * exp(x^2),x,0,inf); defint: integral is divergent.  an error. To debug this try: debugmode(true); (%i4) integrate(x^m * exp(x^2),x,minf,0); defint: integral is divergent.  an error. To debug this try: debugmode(true);  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3311145&group_id=4933 
From: SourceForge.net <noreply@so...>  20110722 06:01:56

Bugs item #3374715, was opened at 20110722 06:01 Message generated for change (Tracker Item Submitted) made by You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3374715&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: yuihji () Assigned to: Nobody/Anonymous (nobody) Summary: a wrong display of the line number in the manual Initial Comment: i found it in the pdf manual , and the same in the online manual . in this page http://maxima.sourceforge.net/docs/manual/en/maxima_4.html#SEC10 , the 4th example of section " Operator: '' " : (%i3) dispfun (foo_1a, foo_1b); (%t3) foo_1a(x) := x log(x)  x (%t4) foo_1b(x) := integrate(log(x), x) (%o4) [%t3, %t4] (%i4) integrate (log (x), x); (%o4) x log(x)  x (%i5) foo_2a (x) := ''%; (%o5) foo_2a(x) := x log(x)  x after the 1st (%o4) , there should be a (%i5) not a (%i4) . and there are some similar mistakes.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3374715&group_id=4933 
From: SourceForge.net <noreply@so...>  20110720 16:23:38

Bugs item #3365831, was opened at 20110713 10:40 Message generated for change (Comment added) made by peti You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3365831&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: Peter Simons (peti) Assigned to: Nobody/Anonymous (nobody) Summary: "make check" does not abort if test errors occurred Initial Comment: Automated build system used by distributors such as Gentoo, ArchLinux, or NixOS assume that "make check" returns with a nonzero error code if tests failed. Maxima doesn't seem to do that, however. I just got a test failure (reported a minute ago), but the build process just went on without signalling the problem. This is bad, because it means that test failures will go unnoticed. I just noticed this one more or less by coincidence.  >Comment By: Peter Simons (peti) Date: 20110720 18:23 Message: Well, it would certainly be nice if there were a way to detect whether "make check" generated errors or not in some automated fashion. Watching all output, trying to spot failures doesn't work so well in practice.  Comment By: Raymond Toy (rtoy) Date: 20110714 14:44 Message: I think this is basically an issue with how Lisp exits with a return code. Most lisps (I think) do not provide a way to exit with a user provided exit code, so there's not much that can be done short of saving the output of the testsuite and checking that no tests failed. In addition this is problematic in that some tests are know to fail with some lisps. These are bug in the lisp implementation, not maxima.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3365831&group_id=4933 
From: SourceForge.net <noreply@so...>  20110719 13:43:25

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: Closed >Resolution: Fixed 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: 20110719 08:43 Message: ...the commit appears in the commit mailing list, so I think this is finally fixed.  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 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 
From: SourceForge.net <noreply@so...>  20110717 18:16:06

Bugs item #3369477, was opened at 20110717 20:16 Message generated for change (Tracker Item Submitted) made by haawda 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: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Stefan Husmann (haawda) Assigned to: Nobody/Anonymous (nobody) Summary: bernstein.texi missing in git Initial Comment: There is no file bernstein.texi in git, so the build of the info documentation fails.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3369477&group_id=4933 
From: SourceForge.net <noreply@so...>  20110717 12:51:30

Bugs item #3369300, was opened at 20110717 08:44 Message generated for change (Comment added) made by vttoth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3369300&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: Share Libraries Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Viktor Toth (vttoth) Assigned to: Viktor Toth (vttoth) Summary: Odd itensor wedge product behavior Initial Comment: The wedge product should not be affected when a term is multiplied by a scalar, but it is when said scalar is a Maxima list element with a numerical index: (%i2) ishow((a([i],[])*X)~a([j],[]))$ (%t2) 0 (%i3) ishow( (a([i],[])*X[1])~a([j],[]))$ (%t3) X a a 1 i j (%i4) ishow((a([i],[])*X[k])~a([j],[]))$ (%t4) 0  >Comment By: Viktor Toth (vttoth) Date: 20110717 08:51 Message: Another (related?) problem is that this shouldn't happen: (%i7) ishow((o([i],[])*s([j],[]))~o([k],[]))$ (%t7) 0 (%i8) ishow((o([j],[])*s([i],[]))~o([k],[]))$ o (o s  s o ) j i k i k (%t8)   2  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3369300&group_id=4933 
From: SourceForge.net <noreply@so...>  20110717 12:44:47

Bugs item #3369300, was opened at 20110717 08:44 Message generated for change (Tracker Item Submitted) made by vttoth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3369300&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: Share Libraries Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Viktor Toth (vttoth) Assigned to: Viktor Toth (vttoth) Summary: Odd itensor wedge product behavior Initial Comment: The wedge product should not be affected when a term is multiplied by a scalar, but it is when said scalar is a Maxima list element with a numerical index: (%i2) ishow((a([i],[])*X)~a([j],[]))$ (%t2) 0 (%i3) ishow( (a([i],[])*X[1])~a([j],[]))$ (%t3) X a a 1 i j (%i4) ishow((a([i],[])*X[k])~a([j],[]))$ (%t4) 0  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3369300&group_id=4933 
From: SourceForge.net <noreply@so...>  20110717 12:41:20

Bugs item #3368052, was opened at 20110715 11:36 Message generated for change (Settings changed) made by vttoth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3368052&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: Share Libraries Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Barton Willis (willisbl) >Assigned to: Viktor Toth (vttoth) Summary: itensor redefines sdiff / problem with binomial Initial Comment: OK: (%i1) diff(binomial(k,n),k); (%o1) binomial(k,n)*(psi[0](n+k+1)psi[0](k+1)) (%i2) load(itensor)$ Not OK (%i3) diff(binomial(k,n),k); (%o3) 'diff(binomial(k,n),k,1)  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3368052&group_id=4933 
From: SourceForge.net <noreply@so...>  20110715 15:36:38

Bugs item #3368052, was opened at 20110715 10:36 Message generated for change (Tracker Item Submitted) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3368052&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: Share Libraries Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: itensor redefines sdiff / problem with binomial Initial Comment: OK: (%i1) diff(binomial(k,n),k); (%o1) binomial(k,n)*(psi[0](n+k+1)psi[0](k+1)) (%i2) load(itensor)$ Not OK (%i3) diff(binomial(k,n),k); (%o3) 'diff(binomial(k,n),k,1)  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3368052&group_id=4933 
From: SourceForge.net <noreply@so...>  20110714 12:44:57

Bugs item #3365831, was opened at 20110713 04:40 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3365831&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: Peter Simons (peti) Assigned to: Nobody/Anonymous (nobody) Summary: "make check" does not abort if test errors occurred Initial Comment: Automated build system used by distributors such as Gentoo, ArchLinux, or NixOS assume that "make check" returns with a nonzero error code if tests failed. Maxima doesn't seem to do that, however. I just got a test failure (reported a minute ago), but the build process just went on without signalling the problem. This is bad, because it means that test failures will go unnoticed. I just noticed this one more or less by coincidence.  >Comment By: Raymond Toy (rtoy) Date: 20110714 08:44 Message: I think this is basically an issue with how Lisp exits with a return code. Most lisps (I think) do not provide a way to exit with a user provided exit code, so there's not much that can be done short of saving the output of the testsuite and checking that no tests failed. In addition this is problematic in that some tests are know to fail with some lisps. These are bug in the lisp implementation, not maxima.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3365831&group_id=4933 
From: SourceForge.net <noreply@so...>  20110714 12:42:32

Bugs item #3365824, was opened at 20110713 04:37 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3365824&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: Tests Group: None >Status: Pending >Resolution: Wont Fix Priority: 5 Private: No Submitted By: Peter Simons (peti) Assigned to: Nobody/Anonymous (nobody) Summary: rtest16 failed in problem 386 Initial Comment: maxima5.24.0 fails its selftest on Linux/x86_64 when built with sbcl1.0.49. The test output is attached below.  >Comment By: Raymond Toy (rtoy) Date: 20110714 08:42 Message: For the record, test 306 is ********************** Problem 386 *************** Input: closeto(zeta(%i + 3)  (1.10721440843141  .1482908671781754 %i), 1.e15) Result: 3.3157171357748244e9 This is a known issue related to how sbcl computes x^y when x and y have different precisions. I (rtoy) have discussed the issue with the sbcl developers who said they will fix this issue so that x^y will coerce x and y to the highest precision before computing it. Ccl also had this problem but was fixed. Marking this as pending/wontfix.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3365824&group_id=4933 
From: SourceForge.net <noreply@so...>  20110713 08:40:49

Bugs item #3365831, was opened at 20110713 10:40 Message generated for change (Tracker Item Submitted) made by peti You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3365831&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: Peter Simons (peti) Assigned to: Nobody/Anonymous (nobody) Summary: "make check" does not abort if test errors occurred Initial Comment: Automated build system used by distributors such as Gentoo, ArchLinux, or NixOS assume that "make check" returns with a nonzero error code if tests failed. Maxima doesn't seem to do that, however. I just got a test failure (reported a minute ago), but the build process just went on without signalling the problem. This is bad, because it means that test failures will go unnoticed. I just noticed this one more or less by coincidence.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3365831&group_id=4933 
From: SourceForge.net <noreply@so...>  20110713 08:37:35

Bugs item #3365824, was opened at 20110713 10:37 Message generated for change (Tracker Item Submitted) made by peti You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3365824&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: Tests Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Peter Simons (peti) Assigned to: Nobody/Anonymous (nobody) Summary: rtest16 failed in problem 386 Initial Comment: maxima5.24.0 fails its selftest on Linux/x86_64 when built with sbcl1.0.49. The test output is attached below.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3365824&group_id=4933 
From: SourceForge.net <noreply@so...>  20110712 20:31:54

Bugs item #3365132, was opened at 20110712 22:31 Message generated for change (Tracker Item Submitted) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3365132&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: Parity of the Bessel functions bessel_j and bessel_i Initial Comment: The parity of the Bessel functions bessel_j and bessel_i is not fully implemented. Maxima knows the rules: bessel_j(n, z) > (1)^n * bessel_j(n, z) bessel_i(n, z) > (1)^n * bessel_i(n, z) for n an integer, but not the rules bessel_j(n, z) > (1)^n * bessel_j(n, z) bessel_i(n, z) > (1)^n * bessel_i(n, z) for n an integer. Maxima version: 5.24post Maxima build date: 21:18 7/11/2011 Host type: i686pclinuxgnu Lisp implementation type: SBCL Lisp implementation version: 1.0.45 Simplification for a negative order: (%i1) bessel_j(1, z); (%o1) bessel_j(1,z) (%i2) bessel_j(2, z); (%o2) bessel_j(2,z) But no simplification for a negative argument: (%i3) bessel_j(1, z); (%o3) bessel_j(1,z) (%i4) bessel_j(2, z); (%o4) bessel_j(2,z) Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3365132&group_id=4933 
From: SourceForge.net <noreply@so...>  20110708 18:58:05

Bugs item #3358816, was opened at 20110708 20:58 Message generated for change (Tracker Item Submitted) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3358816&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: 2 Private: No Submitted By: Dieter Kaiser (crategus) Assigned to: Nobody/Anonymous (nobody) Summary: Package dimen breaks Maxima code Initial Comment: The package dimen breaks Maxima code. It overwrites the Maxima function listify. (%i1) set(a,b,c); (%o1) {a, b, c} (%i2) listify(%); (%o2) [a, b, c] (%i3) load(dimen); define: warning: redefining the builtin function listify (%o3) /usr/local/share/maxima/5.24post/share/physics/dimen.mac (%i4) set(a,b,c); (%o4) {a, b, c} (%i5) listify(%); (%o5) [{a, b, c}] Furthermore, the documentation in the chapter equations is misplaced. Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3358816&group_id=4933 
From: SourceForge.net <noreply@so...>  20110708 11:53:40

Bugs item #3358420, was opened at 20110708 06:53 Message generated for change (Tracker Item Submitted) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3358420&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: Share Libraries Group: None Status: Open Resolution: None Priority: 4 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Barton Willis (willisbl) Summary: nfloat bug Initial Comment: Wrong: (%i6) nfloat(%i,[],20); Unable to evaluate to requested number of digits  an error. To debug this try: debugmode(true); Correct: (%i9) nfloat(1.0*%i,[],20); (%o9) 1.0b0*%i  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3358420&group_id=4933 