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}
(19) 
_{May}
(14) 
_{Jun}
(21) 
_{Jul}
(30) 
_{Aug}
(48) 
_{Sep}
(39) 
_{Oct}
(30) 
_{Nov}
(75) 
_{Dec}
(2) 
S  M  T  W  T  F  S 


1

2
(5) 
3

4
(5) 
5

6

7
(5) 
8
(2) 
9

10

11
(1) 
12
(6) 
13
(3) 
14
(2) 
15
(1) 
16
(1) 
17
(10) 
18

19
(4) 
20
(1) 
21

22
(1) 
23
(4) 
24
(3) 
25
(2) 
26

27
(2) 
28
(1) 
29

30

31
(2) 



From: SourceForge.net <noreply@so...>  20071031 22:58:33

Bugs item #1570828, was opened at 20061004 13:08 Message generated for change (Comment added) made by dgildea You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1570828&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  Solving equations Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: (lin)solve of inconsistent equations Initial Comment: Very simple example: > (%i1) solve([x=1,x=2],x); > Maxima 5.10.0 encountered a Lisp error: > > > CAR: 2 is not a list > > Automatically continuing. > To reenable the Lisp debugger set *debuggerhook* to > nil. Is it a bug? I expected empty list something like: > (%o1) [] or as maxima 5.9.2 says: > Inconsistent equations: (2) >  an error. Quitting. To debug this try > debugmode(true);  >Comment By: Dan Gildea (dgildea) Date: 20071031 18:58 Message: Logged In: YES user_id=1797506 Originator: NO seems to have been lisp implementation dependent  was still present in cmucl. fixed in solve.lisp rev 1.16.  Comment By: guno (guno) Date: 20070204 10:27 Message: Logged In: YES user_id=1709853 Originator: NO (%i13) build_info(); Maxima version: 5.11.0 Maxima build date: 22:25 12/26/2006 host type: i686pcmingw32 lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.8 (%o13) (%i14) solve([x=1,x=2],x); Inconsistent equations: (2)  an error. To debug this try debugmode(true); (%i15) seems to be fixed in 5.11  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1570828&group_id=4933 
From: SourceForge.net <noreply@so...>  20071031 22:53:55

Bugs item #1659946, was opened at 20070214 13:03 Message generated for change (Comment added) made by dgildea You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1659946&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  Solving equations Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Ruslan U. Zakirov (ruz) Assigned to: Nobody/Anonymous (nobody) Summary: [5.11] Lisp error on solve Initial Comment: The following commands generate the error: reset(); x(t) := a0+a1*t+a2*t^2+a3*t^3; solve( [x(0) = x0 ], [a0]); solve( [x(0) = x0, x(1) = x1 ], [a0]); Error: (%i3) solve([x(0) = x0, x(1) = x1], [a0]) Maxima encountered a Lisp error: CAR: 2 is not a list Automatically continuing. System information: Maxima version: 5.11.0 Maxima build date: 8:6 1/15/2007 host type: x86_64pclinuxgnu lispimplementationtype: CLISP lispimplementationversion: 2.41 (20061013) (built 3374317914) (memory 3377826422)  >Comment By: Dan Gildea (dgildea) Date: 20071031 18:53 Message: Logged In: YES user_id=1797506 Originator: NO Fixed in solve.lisp rev 1.16  Comment By: Barton Willis (willisbl) Date: 20070422 17:46 Message: Logged In: YES user_id=895922 Originator: NO Maxima compiled with GCL doesn't report a CL error: (%i28) solve([x(0) = x0, x(1) = x1], [a0]); Inconsistent equations: (2) (%i29) solve([x(0) = x0, x(1) = x1], [a0,a1]); (%o29) [[a0=x0,a1=x1x0a3a2]]  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1659946&group_id=4933 
From: SourceForge.net <noreply@so...>  20071028 23:36:29

Bugs item #1819568, was opened at 20071024 15:40 Message generated for change (Settings changed) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1819568&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: Pending >Resolution: Invalid Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: wrong matrix norms Initial Comment: (%i1) load(linearalgebra) ; 0 errors, 0 warnings (%o1) /usr/share/maxima/5.13.0/share/linearalgebra/linearalgebra.mac (%i2) a:matrix([1,2,3]); (%o2) [ 1 2 3 ] (%i3) mat_norm(a,1); (%o3) 3 (%i4) mat_norm(a,inf); (%o4) 6 norm 1 should be 6 and norm inf should be 3 Tested in versions 5.10 and 5.13.  Comment By: Barton Willis (willisbl) Date: 20071025 07:13 Message: Logged In: YES user_id=895922 Originator: NO The *matrix* onenorm is the largest column sum; the *matrix* infinitynorm is the largest row sum. So mat_norm(matrix([1,2,3]),1) > 3 and mat_norm(matrix([1,2,3]),'inf) > 6 are correct. You might be thinking that Maxima should convert matrix([1,2,3]) into the *vector* [1,2,3]. Indeed, the onenorm of the *vector* [1,2,3] is 6 and the infinity norm of the *vector* [1,2,3] is 3. But I think that such an automatic conversion is a bad idea. Maxima should have a vector type, but it doesn't. Unless somebody shows me that I'm mistaken, I'll mark this bug as invalid in a few days. Thanks for the report.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1819568&group_id=4933 
From: SourceForge.net <noreply@so...>  20071027 17:22:54

Bugs item #690255, was opened at 20030220 15:16 Message generated for change (Comment added) made by dgildea You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=690255&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: Pending >Resolution: Works For Me Priority: 6 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: Some errors don't quit properly; :top fails Initial Comment: Maxima 5.9.0 Windows The "too many arguments" error does not quit back to the top level. ":top" doesn't, either. (C1) f(a):=1/a; 1 (D1) f(a) :=  a (C2) f(1); (D2) 1  So far, so good.  (C3) f(0); Division by 0 #0: f(a=0)  an error. Quitting. To debug this try DEBUGMODE (TRUE);) (C4) backtrace(); (D4) FALSE  This is fine, too. Maxima reports the Division by 0 error, then quits back to the top level.  (C5) f(5,6); Too many arguments supplied to f(a): [5, 6] #0: f(a=5)  an error. Quitting. To debug this try DEBUGMODE (TRUE);) (C6) backtrace(); #0: f(a=5) (D6) FALSE (C7) a; (D7) 5  Oops! Maxima didn't quit back to the top level, and left the binding of a=5 hanging around.  (C8) :top (C8) backtrace(); #0: f(a=5) (D8) FALSE  And :top didn't get us back to the top level, either.   >Comment By: Dan Gildea (dgildea) Date: 20071027 13:22 Message: Logged In: YES user_id=1797506 Originator: NO seems to work in 5.13.0. (%i2) f(a):=1/a; (%o2) f(a):=1/a (%i3) f(1); (%o3) 1 (%i4) f(0); Division by 0 #0: f(a=0)  an error. To debug this try debugmode(true); (%i5) backtrace(); (%o5) false (%i6) f(5,6); Too many arguments supplied to f(a): [5,6]  an error. To debug this try debugmode(true); (%i7) backtrace(); (%o7) false (%i8) a; (%o8) a  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=690255&group_id=4933 
From: SourceForge.net <noreply@so...>  20071027 15:15:48

Bugs item #1821240, was opened at 20071027 10:15 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1821240&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: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: set_partitions documentation Initial Comment: In the second example, (%o3) should follow (%i4): (%o3) 90 = 90 (%i4) cardinality(p) = stirling2 (6, 3); The 3rd and 4th examples have the same problem.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1821240&group_id=4933 
From: SourceForge.net <noreply@so...>  20071025 14:22:46

Bugs item #1820014, was opened at 20071025 10:22 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=1820014&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: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: slength does no error checking Initial Comment: slength is advertised to return the length of a string, which it does correctly: slength("foo") => 3 However, for nonstrings, it has strange behavior (testing in 5.13.0): slength(foo) => 4 (one too long) slength(200) => 1 (interpreting integer as a ASCII character) slength(200.0) => internal error slength(300) => internal error slength(a+b) => internal error It should either give a clean Maxima error in all these cases, or return a reasonable result. You might think the reasonable result would be slength(string(...)), but that would make slength("foo") => 5, which isn't right.... So I think it has to give an error when its argument is not a string.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1820014&group_id=4933 
From: SourceForge.net <noreply@so...>  20071025 12:13:12

Bugs item #1819568, was opened at 20071024 15:40 Message generated for change (Comment added) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1819568&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: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: wrong matrix norms Initial Comment: (%i1) load(linearalgebra) ; 0 errors, 0 warnings (%o1) /usr/share/maxima/5.13.0/share/linearalgebra/linearalgebra.mac (%i2) a:matrix([1,2,3]); (%o2) [ 1 2 3 ] (%i3) mat_norm(a,1); (%o3) 3 (%i4) mat_norm(a,inf); (%o4) 6 norm 1 should be 6 and norm inf should be 3 Tested in versions 5.10 and 5.13.  >Comment By: Barton Willis (willisbl) Date: 20071025 07:13 Message: Logged In: YES user_id=895922 Originator: NO The *matrix* onenorm is the largest column sum; the *matrix* infinitynorm is the largest row sum. So mat_norm(matrix([1,2,3]),1) > 3 and mat_norm(matrix([1,2,3]),'inf) > 6 are correct. You might be thinking that Maxima should convert matrix([1,2,3]) into the *vector* [1,2,3]. Indeed, the onenorm of the *vector* [1,2,3] is 6 and the infinity norm of the *vector* [1,2,3] is 3. But I think that such an automatic conversion is a bad idea. Maxima should have a vector type, but it doesn't. Unless somebody shows me that I'm mistaken, I'll mark this bug as invalid in a few days. Thanks for the report.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1819568&group_id=4933 
From: SourceForge.net <noreply@so...>  20071024 21:37:30

Bugs item #1778796, was opened at 20070821 12:36 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1778796&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: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: integrate( (x^3+1)/(x^4 + 4*x + 1), 0, 1); Initial Comment: Maxima: 5.11.0 Lisp: SBCL 1.0.3 On the mailing list, I asked about a definite integral that seems to make Maxima hang. 8< (%i1) integrate( (x^3+1)/(x^4 + 4*x + 1), x); 4 log(x + 4 x + 1) (%o1)  4 (%i2) integrate( (x^3+1)/(x^4 + 4*x + 1), x, 0, 1); [... no output, sblc cpu usage at 87% ...]  Barton Willis replied and suggested to file a bug report. He said: > > To see in part what is going on, try this: > > (%i4) trace(?csign); > (%o4) [csign] > (%i5) integrate( (x^3+1)/(x^4 + 4*x + 1), x, 0, 1); > > > Yikes! all kinds of junk! > > Also try integrate((x^3+1)/(x^4 + 4*x + 1), x,a,b). > > I suppose that Maxima is struggling to show that the antiderivative > is continuous on [0,1]. But Maxima goes about it in just about the > worst of all possible ways. Maxima does know that x^4 + 4*x + 1 is > positive > for x in [0,1], so it should be able to determine that > log(x^4 + 4*x + 1) is continuous on [0,1]. > > (%i1) assume(x >= 0, x<=1); > (%o1) [x>=0,x<=1] > (%i2) sign(x^4 + 4*x + 1); > (%o2) pos  >Comment By: Raymond Toy (rtoy) Date: 20071024 17:37 Message: Logged In: YES user_id=28849 Originator: NO Fixed in defint.lisp, rev 1.52. We try the antiderivative first and if that fails, we try the keyhole contour.  Comment By: Raymond Toy (rtoy) Date: 20071019 10:23 Message: Logged In: YES user_id=28849 Originator: NO A summary of some emails. Maxima has converted the integral to a contour integral around a keyhole contour (circle with a slit on the positive real axis). The denominator is a quartic with 4 complex (and messy) roots. Maxima is using residues to evaluate the integral. If you wait long enough (and have enough memory), maxima does finally finish. (It took some hour or two). The result is too long to display, but if I bfloat the resullt, I get the expected numerical answer. (Which is a little surprising because there are some very large integers of 50+ digits or more in the result.) Since this is a rational function, I tried an experiment with ratfnt trying to do the antiderivative first before trying the contour integral. This works, and doesn't cause the test suite to fail. Two tests do fail, but that is because the form of the answer has changed, not the value.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1778796&group_id=4933 
From: SourceForge.net <noreply@so...>  20071024 20:53:18

Bugs item #1818753, was opened at 20071023 13:51 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1818753&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  Translator Group: None >Status: Closed >Resolution: Duplicate Priority: 5 Private: No Submitted By: Kai Yue (kaiyue) Assigned to: Nobody/Anonymous (nobody) Summary: Compiled maxima code containing $ARRAY gets a Lisp error. Initial Comment: The following shows the problem. The file below contains the function test_array_comp(). It runs fine with interpreter. But got the error "function $ARRAY is undefined". I could have used make_array. But its use has other problems for my application. Thanks. Kai file "testarray.max" : test_array_comp(x) :=block([abc, i], array(abc, 3), for i thru 3 do (abc[i]: i*i), abc[3] : x, print(abc, abc[3], abc[2]), x : x*2, x)$ maxima session: (%i222) load("testarray.max"); (%o222) testarray.max (%i223) test_array_comp(3); abc 3 4 (%o223) 6 (%i224) compile_file("testarray.max"); Translation begun on testarray.max. (%o224) [testarray.max, testarray.LISP, testarray.UNLISP, /hm/maxima/testarray.x86f] (%i225) loadfile("testarray"); (%o225) testarray (%i226) test_array_comp(3); Maxima encountered a Lisp error: Error in KERNEL:%COERCETOFUNCTION: the function $ARRAY is undefined. Automatically continuing. To reenable the Lisp debugger set *debuggerhook* to nil.  >Comment By: Raymond Toy (rtoy) Date: 20071024 16:53 Message: Logged In: YES user_id=28849 Originator: NO Duplicate of 1818645 https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1818645&group_id=4933  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1818753&group_id=4933 
From: SourceForge.net <noreply@so...>  20071024 20:40:18

Bugs item #1819568, was opened at 20071024 13:40 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=1819568&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: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: wrong matrix norms Initial Comment: (%i1) load(linearalgebra) ; 0 errors, 0 warnings (%o1) /usr/share/maxima/5.13.0/share/linearalgebra/linearalgebra.mac (%i2) a:matrix([1,2,3]); (%o2) [ 1 2 3 ] (%i3) mat_norm(a,1); (%o3) 3 (%i4) mat_norm(a,inf); (%o4) 6 norm 1 should be 6 and norm inf should be 3 Tested in versions 5.10 and 5.13.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1819568&group_id=4933 
From: SourceForge.net <noreply@so...>  20071023 20:57:53

Bugs item #744679, was opened at 20030527 22:30 Message generated for change (Comment added) made by dgildea You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=744679&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: Works For Me Priority: 5 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: limit overflows memory? Initial Comment: expr: (x^(1/n)+1)^n/2^n; limit(expr,n,inf); Is x positive or negative? pos;Is x  1 positive or negative? pos; Error: Contiguous blocks exhausted. Currently, 129 pages are allocated. Use ALLOCATECONTIGUOUSPAGES to expand the space. Fast links are on: do (si::usefastlinks nil) for debugging Error signalled by MACSYMATOPLEVEL. Broken at HAIPART. Type :H for Help.  a) Of course it shouldn't cause this sort of error at all. b) What is allocatecontiguouspages??? There is apparently no such function in gcl. By the way, tlimit gets the correct result, sqrt(x). Maxima 5.9.0 GCL 2.5.0 mingw32 Windows 2000 Athlon  >Comment By: Dan Gildea (dgildea) Date: 20071023 16:57 Message: Logged In: YES user_id=1797506 Originator: NO works in current cvs. (%i5) assume(x>1); (%o5) [x > 1] (%i6) expr: (x^(1/n)+1)^n/2^n; (%o6) (x^(1/n)+1)^n/2^n (%i7) limit(expr,n,inf); (%o7) sqrt(x)  Comment By: Robert Dodier (robert_dodier) Date: 20060707 01:18 Message: Logged In: YES user_id=501686 Still present in 5.9.3cvs / sbcl 0.9.9. In this case the error is "The value 536870912 is not of type FIXNUM".  Comment By: Raymond Toy (rtoy) Date: 20030528 12:33 Message: Logged In: YES user_id=28849 With CMUCL, we also get an error. It seems we're trying to compute 2^16384, and CMUCL stops if the exponent is too large. Presumably gcl is trying to compute the same thing and has run out of memory for this number.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=744679&group_id=4933 
From: SourceForge.net <noreply@so...>  20071023 17:51:04

Bugs item #1818753, was opened at 20071023 10: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=1818753&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  Translator Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Kai Yue (kaiyue) Assigned to: Nobody/Anonymous (nobody) Summary: Compiled maxima code containing $ARRAY gets a Lisp error. Initial Comment: The following shows the problem. The file below contains the function test_array_comp(). It runs fine with interpreter. But got the error "function $ARRAY is undefined". I could have used make_array. But its use has other problems for my application. Thanks. Kai file "testarray.max" : test_array_comp(x) :=block([abc, i], array(abc, 3), for i thru 3 do (abc[i]: i*i), abc[3] : x, print(abc, abc[3], abc[2]), x : x*2, x)$ maxima session: (%i222) load("testarray.max"); (%o222) testarray.max (%i223) test_array_comp(3); abc 3 4 (%o223) 6 (%i224) compile_file("testarray.max"); Translation begun on testarray.max. (%o224) [testarray.max, testarray.LISP, testarray.UNLISP, /hm/maxima/testarray.x86f] (%i225) loadfile("testarray"); (%o225) testarray (%i226) test_array_comp(3); Maxima encountered a Lisp error: Error in KERNEL:%COERCETOFUNCTION: the function $ARRAY is undefined. Automatically continuing. To reenable the Lisp debugger set *debuggerhook* to nil.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1818753&group_id=4933 
From: SourceForge.net <noreply@so...>  20071023 15:49:43

Bugs item #1818645, was opened at 20071023 08:49 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=1818645&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  Translator Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Kai Yue (kaiyue) Assigned to: Nobody/Anonymous (nobody) Summary: Compiled maxima code containing $ARRAY gets a Lisp error. Initial Comment: The following shows the problem. The file below contains the function test_array_comp(). It runs fine with interpreter. But got the error "function $ARRAY is undefined". I could have used make_array. But its use has other problems for my application. Thanks. Kai file "testarray.max" : test_array_comp(x) :=block([abc, i], array(abc, 3), for i thru 3 do (abc[i]: i*i), abc[3] : x, print(abc, abc[3], abc[2]), x : x*2, x)$ maxima session: (%i222) load("testarray.max"); (%o222) testarray.max (%i223) test_array_comp(3); abc 3 4 (%o223) 6 (%i224) compile_file("testarray.max"); Translation begun on testarray.max. (%o224) [testarray.max, testarray.LISP, testarray.UNLISP, /hm/maxima/testarray.x86f] (%i225) loadfile("testarray"); (%o225) testarray (%i226) test_array_comp(3); Maxima encountered a Lisp error: Error in KERNEL:%COERCETOFUNCTION: the function $ARRAY is undefined. Automatically continuing. To reenable the Lisp debugger set *debuggerhook* to nil.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1818645&group_id=4933 
From: SourceForge.net <noreply@so...>  20071023 10:38:43

Bugs item #1709575, was opened at 20070429 08:27 Message generated for change (Settings changed) made by dgildea You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1709575&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: Pending >Resolution: Works For Me Priority: 5 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: reflection rule code Initial Comment: Consider: (%i1) tellsimp(sin(x),0); (%o1) [sinrule1,simp%sin] (%i3) sin(x); (%o3) sin(x) Oops! %o3 should be 0. To fully simplify, we need an expand (or ratsimp) (%i4) expand(%); (%o4) 0 I think there are cases where this reflection rule bug causes problems *without* a tellsimp rule. Also, I think the test suite uses ratsimp to test for equality. This makes these kind of bugs difficult to detect in the test suite.  Comment By: Stavros Macrakis (macrakis) Date: 20070506 21:35 Message: Logged In: YES user_id=588346 Originator: NO > I think (without looking) that ALIKE1 calls ratsimp so > that's how it comes into play in the testsuite. No, alike1 is the Maxima equivalent of equal; it tests for strictly syntactic equality, ignoring all flags (like simp) except arr. The test suite cannot use ratsimp to test for correctness because that would ignore changes of *form* which don't change meaning, e.g. factor, factorsum, expand, partfrac, etc. s  Comment By: Robert Dodier (robert_dodier) Date: 20070506 14:51 Message: Logged In: YES user_id=501686 Originator: NO Seems to have been fixed in cvs head. tellsimp (sin(x), 0); sin(x); => 0 Also (in a fresh session) tellsimpafter (sin(x), 0); sin(x); => 0 About ratsimp, I think (without looking) that ALIKE1 calls ratsimp so that's how it comes into play in the testsuite.  Comment By: Stavros Macrakis (macrakis) Date: 20070429 15:27 Message: Logged In: YES user_id=588346 Originator: NO This is because (take '(%sin) ...) goes directly to simpsin rather than to simplifya. I am currently testing new code for take which calls simplifya (and will replace opcons and the like).  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1709575&group_id=4933 
From: SourceForge.net <noreply@so...>  20071022 03:36:51

Bugs item #1760232, was opened at 20070725 07:34 Message generated for change (Comment added) made by dgildea You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1760232&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: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: limit(1/n * n!^(1/n), n, inf); Initial Comment: >From wester_problems/test_limits.mac: (%i1) limit(1/n * n!^(1/n), n, inf); Is n! positive or negative?pos; Maxima encountered a Lisp error: Error in PROGN [or a callee]: Bind stack overflow. (%i3) build_info(); Maxima version: 5.12.0 Maxima build date: 19:33 5/3/2007 host type: i686pcmingw32 lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.8  >Comment By: Dan Gildea (dgildea) Date: 20071021 23:36 Message: Logged In: YES user_id=1797506 Originator: NO fixed in limit.lisp rev 1.44 (%i4) limit(1/n * n!^(1/n), n, inf); (%o4) %e^1  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1760232&group_id=4933 
From: SourceForge.net <noreply@so...>  20071020 00:39:30

Bugs item #1816801, was opened at 20071019 17:58 Message generated for change (Comment added) made by vttoth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1816801&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Simplification Group: None >Status: Closed >Resolution: Out of Date Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Equations scaled incorrectly Initial Comment: Now, this could be me, but I think that Maxima is not meant to actually change your expression when you ask it to factor it. I think this session best describes the problem: (%i48) (10*y11*%i+2)*(10*z+11*%i+2); (%o48) (10*y11*%i+2)*(10*z+11*%i+2) (%i49) factor(%); (%o49) (10*y11*%i+2)*(10*z+11*%i+2) (%i50) expand(%); (%o50) 100*y*z110*%i*z+20*z+110*%i*y+20*y+125 (%i51) factor(%); (%o51) 5*(10*y11*%i+2)*(10*z+11*%i+2) (%i52) expand(%); (%o52) 500*y*z550*%i*z+100*z+550*%i*y+100*y+625 (%i53) factor(%); (%o53) 25*(10*y11*%i+2)*(10*z+11*%i+2) (%i54) expand(%); (%o54) 2500*y*z2750*%i*z+500*z+2750*%i*y+500*y+3125 (%i55) factor(%); (%o55) 125*(10*y11*%i+2)*(10*z+11*%i+2) (%i56) expand(%); (%o56) 12500*y*z13750*%i*z+2500*z+13750*%i*y+2500*y+15625 (%i57) factor(%); (%o57) 625*(10*y11*%i+2)*(10*z+11*%i+2) (%i58) expand(%); (%o58) 62500*y*z68750*%i*z+12500*z+68750*%i*y+12500*y+78125 Maxima version: 5.10.0 Maxima build date: 14:57 10/18/2006 host type: i686pclinuxgnu lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.7  >Comment By: Viktor Toth (vttoth) Date: 20071019 20:39 Message: Logged In: YES user_id=1023504 Originator: NO This problem is not reproducible in the current production version. I recommend that you download and use version 5.13.0: Maxima 5.13.0 http://maxima.sourceforge.net Using Lisp CLISP 2.35 (20050829) Distributed under the GNU Public License. See the file COPYING. Dedicated to the memory of William Schelter. This is a development version of Maxima. The function bug_report() provides bug reporting information. (%i1) (10*y11*%i+2)*(10*z+11*%i+2); (%o1) (10 y  11 %i + 2) (10 z + 11 %i + 2) (%i2) factor(%); (%o2) (10 y  11 %i + 2) (10 z + 11 %i + 2) (%i3) expand(%); (%o3) 100 y z  110 %i z + 20 z + 110 %i y + 20 y + 125 (%i4) factor(%); (%o4) 5 (20 y z  22 %i z + 4 z + 22 %i y + 4 y + 25) (%i5) expand(%); (%o5) 100 y z  110 %i z + 20 z + 110 %i y + 20 y + 125 (%i6) Viktor  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1816801&group_id=4933 
From: SourceForge.net <noreply@so...>  20071019 21:58:54

Bugs item #1816801, was opened at 20071019 14:58 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=1816801&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: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Equations scaled incorrectly Initial Comment: Now, this could be me, but I think that Maxima is not meant to actually change your expression when you ask it to factor it. I think this session best describes the problem: (%i48) (10*y11*%i+2)*(10*z+11*%i+2); (%o48) (10*y11*%i+2)*(10*z+11*%i+2) (%i49) factor(%); (%o49) (10*y11*%i+2)*(10*z+11*%i+2) (%i50) expand(%); (%o50) 100*y*z110*%i*z+20*z+110*%i*y+20*y+125 (%i51) factor(%); (%o51) 5*(10*y11*%i+2)*(10*z+11*%i+2) (%i52) expand(%); (%o52) 500*y*z550*%i*z+100*z+550*%i*y+100*y+625 (%i53) factor(%); (%o53) 25*(10*y11*%i+2)*(10*z+11*%i+2) (%i54) expand(%); (%o54) 2500*y*z2750*%i*z+500*z+2750*%i*y+500*y+3125 (%i55) factor(%); (%o55) 125*(10*y11*%i+2)*(10*z+11*%i+2) (%i56) expand(%); (%o56) 12500*y*z13750*%i*z+2500*z+13750*%i*y+2500*y+15625 (%i57) factor(%); (%o57) 625*(10*y11*%i+2)*(10*z+11*%i+2) (%i58) expand(%); (%o58) 62500*y*z68750*%i*z+12500*z+68750*%i*y+12500*y+78125 Maxima version: 5.10.0 Maxima build date: 14:57 10/18/2006 host type: i686pclinuxgnu lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.7  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1816801&group_id=4933 
From: SourceForge.net <noreply@so...>  20071019 14:23:35

Bugs item #1778796, was opened at 20070821 12:36 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1778796&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: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: integrate( (x^3+1)/(x^4 + 4*x + 1), 0, 1); Initial Comment: Maxima: 5.11.0 Lisp: SBCL 1.0.3 On the mailing list, I asked about a definite integral that seems to make Maxima hang. 8< (%i1) integrate( (x^3+1)/(x^4 + 4*x + 1), x); 4 log(x + 4 x + 1) (%o1)  4 (%i2) integrate( (x^3+1)/(x^4 + 4*x + 1), x, 0, 1); [... no output, sblc cpu usage at 87% ...]  Barton Willis replied and suggested to file a bug report. He said: > > To see in part what is going on, try this: > > (%i4) trace(?csign); > (%o4) [csign] > (%i5) integrate( (x^3+1)/(x^4 + 4*x + 1), x, 0, 1); > > > Yikes! all kinds of junk! > > Also try integrate((x^3+1)/(x^4 + 4*x + 1), x,a,b). > > I suppose that Maxima is struggling to show that the antiderivative > is continuous on [0,1]. But Maxima goes about it in just about the > worst of all possible ways. Maxima does know that x^4 + 4*x + 1 is > positive > for x in [0,1], so it should be able to determine that > log(x^4 + 4*x + 1) is continuous on [0,1]. > > (%i1) assume(x >= 0, x<=1); > (%o1) [x>=0,x<=1] > (%i2) sign(x^4 + 4*x + 1); > (%o2) pos  >Comment By: Raymond Toy (rtoy) Date: 20071019 10:23 Message: Logged In: YES user_id=28849 Originator: NO A summary of some emails. Maxima has converted the integral to a contour integral around a keyhole contour (circle with a slit on the positive real axis). The denominator is a quartic with 4 complex (and messy) roots. Maxima is using residues to evaluate the integral. If you wait long enough (and have enough memory), maxima does finally finish. (It took some hour or two). The result is too long to display, but if I bfloat the resullt, I get the expected numerical answer. (Which is a little surprising because there are some very large integers of 50+ digits or more in the result.) Since this is a rational function, I tried an experiment with ratfnt trying to do the antiderivative first before trying the contour integral. This works, and doesn't cause the test suite to fail. Two tests do fail, but that is because the form of the answer has changed, not the value.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1778796&group_id=4933 
From: SourceForge.net <noreply@so...>  20071019 10:08:13

Bugs item #1812167, was opened at 20071012 12:53 Message generated for change (Comment added) made by hgeyer You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1812167&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: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Harald Geyer (hgeyer) Assigned to: Nobody/Anonymous (nobody) Summary: current cvs still installs as 5.12.99rc1 Initial Comment: Hi, it seems nobody has updated the version string in cvs since the last release. Thus current cvs installs with an lower version string than 5.13. Sorry, I can't fix it myself right now, because I don't have my cvs ssh key ready. best, Harald  >Comment By: Harald Geyer (hgeyer) Date: 20071019 12:08 Message: Logged In: YES user_id=929336 Originator: YES Fixed by configure.in revision 1.94, Thu Oct 18 13:39:45 2007 UTC  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1812167&group_id=4933 
From: SourceForge.net <noreply@so...>  20071019 02:20:14

Bugs item #1605716, was opened at 20061129 15:53 Message generated for change (Comment added) made by sfrobot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1605716&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  Taylor Group: None >Status: Closed Resolution: Works For Me Priority: 3 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: taylor at infinity for non algebraic Initial Comment: Consider: (%i1) log(x) + exp(x^2)$ (%i2) e : diff(%,x)/%; (%o2) (2*x*%e^x^2+1/x)/(log(x)+%e^x^2) Towards infinity, a good approximation to e is 2 x. But (%i3) taylor(e,x,inf,2); (%o3) 4/x+... And (%i4) taylor(e,x,inf,5); (%o4) 240/x^5+... And (%i5) taylor(ratsimp(e),x,inf,5); 1/(x*log(x)+x*%e^x^2) Assumed to be zero in `taylor' (%o5) 0+... It would be better if taylor just gave up. All the results are not right. Barton  >Comment By: SourceForge Robot (sfrobot) Date: 20071018 19:20 Message: Logged In: YES user_id=1312539 Originator: NO This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker).  Comment By: Dan Gildea (dgildea) Date: 20071004 03:46 Message: Logged In: YES user_id=1797506 Originator: NO These seem ok in current cvs. (%i7) log(x) + exp(x^2)$ (%i8) e : diff(%,x)/%; (%o8) (2*x*%e^x^2+1/x)/(log(x)+%e^x^2) (%i9) taylor(e,x,inf,2); (%o9) +2*x+((+(2*log(x)))*x+1/x)*%e^x^2 +((+2*log(x)^2)*x+(+(log(x)))/x)*(%e^x^2)^2 (%i10) taylor(e,x,inf,5); (%o10) +2*x+((+(2*log(x)))*x+1/x)*%e^x^2 +((+2*log(x)^2)*x+(+(log(x)))/x)*(%e^x^2)^2 +((+(2*log(x)^3))*x+(+log(x)^2)/x)*(%e^x^2)^3 +((+2*log(x)^4)*x+(+(log(x)^3))/x)*(%e^x^2)^4 +((+(2*log(x)^5))*x+(+log(x)^4)/x)*(%e^x^2)^5 (%i11) taylor(ratsimp(e),x,inf,5); (%o11) +2*x+((+(2*log(x)))*x+1/x)*%e^x^2 +((+2*log(x)^2)*x+(+(log(x)))/x)*(%e^x^2)^2 +((+(2*log(x)^3))*x+(+log(x)^2)/x)*(%e^x^2)^3 +((+2*log(x)^4)*x+(+(log(x)^3))/x)*(%e^x^2)^4 +((+(2*log(x)^5))*x+(+log(x)^4)/x)*(%e^x^2)^5 (%i12) log(log(x)) + exp(x)$ (%i13) diff(%,x)/%; (%o13) (1/(x*log(x))%e^x)/(log(log(x))+%e^x) (%i14) taylor(%,x,inf,2); (%o14) +(+(+1/log(log(x)))/log(x))/x+(+(1/log(log(x))) +(+(+(1/log(log(x))^2))/log(x))/x) *%e^x+(+1/log(log(x))^2)*(%e^x)^2 (%i15) log(log(x)) + x$ (%i16) diff(%,x)/%; (%o16) (1/(x*log(x))+1)/(log(log(x))+x) (%i17) taylor(%,x,inf,2); (%o17) 1/x+(+(log(log(x)))+1/log(x))/x^2  Comment By: Barton Willis (willisbl) Date: 20061201 02:54 Message: Logged In: YES user_id=895922 Originator: YES Two related problems: (%i1) log(log(x)) + exp(x)$ (%i2) diff(%,x)/%$ (%i3) taylor(%,x,inf,2); Invalid call to varexpand (%i4) log(log(x)) + x$ (%i5) diff(%,x)/%$ (%i6) taylor(%,x,inf,2); (%o6) 1/x+(1/log(x)+(log(log(x))+zeroa+...)+...)/x^2+... Isn't this unsimplified? I don't know what taylor is trying to do with expressions similar to %o5. Again, maybe it would be better if taylor gave up.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1605716&group_id=4933 
From: SourceForge.net <noreply@so...>  20071017 22:40:04

Bugs item #1801287, was opened at 20070924 12:03 Message generated for change (Comment added) made by dgildea You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1801287&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: Pending Resolution: None Priority: 5 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: 1arg limit infinite loop Initial Comment: limit( (inf*(inf+1))/((inf+2)/(inf+3)) ) runs for a very long (infinite?) time. It should be able to return UND quickly, the way smaller examples do.  >Comment By: Dan Gildea (dgildea) Date: 20071017 18:39 Message: Logged In: YES user_id=1797506 Originator: NO closing unless this shows up in 5.13  Comment By: Stavros Macrakis (macrakis) Date: 20071015 11:31 Message: Logged In: YES user_id=588346 Originator: YES Sorry for forgetting to include the version number. This must have been on my home machine, 5.12/Windows. It works on my work install, 5.13.  Comment By: Dan Gildea (dgildea) Date: 20071014 09:15 Message: Logged In: YES user_id=1797506 Originator: NO (%i1) limit( (inf*(inf+1))/((inf+2)/(inf+3)) ); (%o1) und (%i2) build_info(); Maxima version: 5.13.0 Maxima build date: 12:41 9/14/2007 host type: i686pclinuxgnu lispimplementationtype: CMU Common Lisp lispimplementationversion: 19d (19D) what version are you using?  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1801287&group_id=4933 
From: SourceForge.net <noreply@so...>  20071017 20:05:20

Bugs item #1815331, was opened at 20071017 16:05 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=1815331&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: 3 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: lambda[...] doesn't give error Initial Comment: lambda[[x],x^2] is accepted by the parser, and the evaluator is willing to apply it: lambda[[x],x^2](4) => 16 but other parts of Maxima don't treat it as a lambda expression: lambda([x],x),x=3 => lambda([x],x) lambda[[x],x],x=3 => lambda[[3],3] lambda[...] should give an error.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1815331&group_id=4933 
From: SourceForge.net <noreply@so...>  20071017 20:02:13

Bugs item #1812669, was opened at 20071012 23:20 Message generated for change (Comment added) made by macrakis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1812669&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: Invalid Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: integration variable is global, should be local Initial Comment: jjby@... Maxima version: 5.13.0Maxima build date: 20:4 9/10/2007host type: i686pcmingw32lispimplementationtype: GNU Common Lisp (GCL)lispimplementationversion: GCL t:0; integrate(t,t); Attempt to integrate wrt a number: 0  an error. To debug this try debugmode(true);  >Comment By: Stavros Macrakis (macrakis) Date: 20071017 16:02 Message: Logged In: YES user_id=588346 Originator: NO This is not a bug. The arguments to integrate, as to most functions, are evaluated. Thus: var: x$ expr: x^2$ integrate(expr,var) => x^3/3 You can quote them if you don't want them evaluated, e.g. integrate('expr,'var) => expr*var rtoy: I think he wants integrate('t,'t), actually...  Comment By: Raymond Toy (rtoy) Date: 20071017 08:50 Message: Logged In: YES user_id=28849 Originator: NO I'm not really familiar with all of maxima's evaluation rules, but this makes sense to me. Perhaps you really want to use integrate(t,'t)?  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1812669&group_id=4933 
From: SourceForge.net <noreply@so...>  20071017 13:36:38

Bugs item #1815032, was opened at 20071017 05:25 Message generated for change (Comment added) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1815032&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: Invalid Priority: 5 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: 1arg limit stack overflow Initial Comment: This 1arg limit gives (GCL) gives a bind stack overflow: limit((minfinf)) (%i29) build_info(); Maxima version: 5.13.0 Maxima build date: 20:4 9/10/2007 host type: i686pcmingw32 lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.8  >Comment By: Barton Willis (willisbl) Date: 20071017 08:36 Message: Logged In: YES user_id=895922 Originator: YES My mistakethis morning I was testing some experimental (and buggy) code (simpmax, for one). I forgot that this code was loaded. It seems that limit((minfinf)) works fine. Sorry about that.  Comment By: Dan Gildea (dgildea) Date: 20071017 06:03 Message: Logged In: YES user_id=1797506 Originator: NO (%i1) limit((minfinf)); (%o1) inf (%i2) build_info(); Maxima version: 5.13.0 Maxima build date: 12:41 9/14/2007 host type: i686pclinuxgnu lispimplementationtype: CMU Common Lisp lispimplementationversion: 19d (19D)  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1815032&group_id=4933 
From: SourceForge.net <noreply@so...>  20071017 12:52:42

Bugs item #1814656, was opened at 20071016 15:09 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1814656&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: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Romberg Initial Comment: This is the error discription: (%i3) romberg(sqrt(1sqrt(x)/3*x), x, 0, 3);Maxima encountered a Lisp error: Error in TRAMP1$M [or a callee]: ((MPLUS SIMP) 5.2388640049375714E17 ((MTIMES SIMP) 0.85559967716735219 $%I)) is not of type (OR RATIONAL LISP:FLOAT).Automatically continuing.To reenable the Lisp debugger set *debuggerhook* to nil.  >Comment By: Raymond Toy (rtoy) Date: 20071017 08:52 Message: Logged In: YES user_id=28849 Originator: NO Evaluate the integrand at x = 3. I get sqrt(1sqrt(3)), which is definitely not real. Maxima shouldn't give an error for this, but I'm not sure what exactly it should do.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1814656&group_id=4933 