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}
(12) 
_{Nov}

_{Dec}

S  M  T  W  T  F  S 




1
(2) 
2
(3) 
3
(1) 
4

5
(1) 
6
(4) 
7
(5) 
8
(3) 
9

10

11

12

13
(7) 
14
(5) 
15
(4) 
16

17
(1) 
18
(1) 
19
(5) 
20
(6) 
21
(5) 
22

23
(1) 
24

25
(1) 
26
(2) 
27
(1) 
28

29

30



From: SourceForge.net <noreply@so...>  20050613 20:10:04

Bugs item #1216231, was opened at 20050607 04:06 Message generated for change (Settings changed) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1216231&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: Pending Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Upper/lower case variables Initial Comment: Maxima is case sensitive for declaration of variables. But accidentally, I observed the following while defining the variables during programming: IS(aa=AA) FALSE (which is expected.) IS(dd=DD) TRUE (! Unexpected) IS(qq=QQ) TRUE (! Unexpected) for other variables the results are as expected. Vijayendra  Comment By: Raymond Toy (rtoy) Date: 20050607 08:18 Message: Logged In: YES user_id=28849 I believe these are all fixed in CVS. All three examples return false.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1216231&group_id=4933 
From: SourceForge.net <noreply@so...>  20050613 18:50:00

Bugs item #1215067, was opened at 20050605 02:52 Message generated for change (Comment added) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1215067&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: None Priority: 5 Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: hgfred([1,1],[1/2],x) Initial Comment: I think hgfred([1,1],[1/2],x) evaluates incorrectly. Consider: The rising factorial (%i1) rf(x,n) := product(x+i,i,0,n1)$ The sum of the first three terms of 2F1 (%i2) f21(a,b,c,x) := sum(rf(a,i) * rf(b,i) * x^i/(i ! * rf(c,i)),i,0,2)$ Let's taylor hgfred([1,1],[1/2],x) (%i3) taylor(hgfred([1,1],[1/2],x),x,0,2); (%o3) 1+(3*x)/4+(3*x^2)/4+... Compare with f21(1,1,1/2,x) (%i4) f21(1,1,1/2,x); (%o4) (8*x^2)/3+2*x+1 They disagree. Try different parameters  this time they agree (%i5) taylor(hgfred([1,2],[3],x),x,0,2); (%o5) 1+(2*x)/3+x^2/2+... (%i6) f21(1,2,3,x); (%o6) x^2/2+(2*x)/3+1 This might be a bug in taylor. But I doubt that  commercial macsyma's value for hgfred([1,1],[1/2]) differs from the one given by maxima (D5) asin(sqrt(x))*sqrt(x)/(1x)^(3/2)+1/(1x) (%i7) build_info(); Maxima version: 5.9.1 Maxima build date: 7:34 9/24/2004 host type: i686pcmingw32 lispimplementationtype: Kyoto Common Lisp lispimplementationversion: GCL 2.6.5 Barton  >Comment By: Barton Willis (willisbl) Date: 20050613 13:49 Message: Logged In: YES user_id=895922 Thanksit is fixed in CVS (using GCL). I'll close the bug. Barton  Comment By: Raymond Toy (rtoy) Date: 20050606 15:45 Message: Logged In: YES user_id=28849 This appears to be fixed in CVS. Can you try that? hgfred([1,1],[1/2],x) returns something essentially equivalent to what commerical Macsyma returns.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1215067&group_id=4933 
From: SourceForge.net <noreply@so...>  20050613 17:46:26

Bugs item #1219846, was opened at 20050613 12:46 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=1219846&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: 2 Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: properties Initial Comment: After translating a function, the properties of the function are messed up. Consider (%i1) f(x) := x; (%o1) f(x):=x This is OK: (%i2) properties(f); (%o2) [FUNCTION] (%i3) translate(f)$ Three questions: (1) Why is transfun listed five times? (2) Why doesn't f have the function property anymore? (3) Why the upper case? (%i4) properties(f); (%o4) [TRANSFUN,TRANSFUN,TRANSFUN,TRANSFUN,TRANSFUN] (%i5) build_info(); Maxima version: 5.9.1 Maxima build date: 7:34 9/24/2004 host type: i686pcmingw32 lispimplementationtype: Kyoto Common Lisp lispimplementationversion: GCL 2.6.5 Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1219846&group_id=4933 
From: SourceForge.net <noreply@so...>  20050613 11:31:00

Bugs item #1192935, was opened at 20050430 06:10 Message generated for change (Comment added) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1192935&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 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: termsubstitution in function sum is too late Initial Comment: (%i1) "Lower RiemannSum, Intervall [0,1], 10 parts"$ (%i2) /*Function*/ f(x):=x^2$ (%i3) /*area width*/ b: 1/10$ (%i4) /*area depending on k=0,...,9*/ Ak: b*f(k*b)$ (%i5) Ak; 2 k (%o5)  1000 (%i6) /* wrong */ sum(Ak,k,0,9); 2 k (%o6)  100 obviously, we first have the summation and then the symbolsubstitution (%i7) sum(''Ak,k,0,9); 57 (%o7)  200 finally, this is ok, but the usage of the doublequote is hard to explain to beginners. it gets even worse, if you use a function A(k):=k*f(k*b)$ for a sum with n partitions: (%i8) "Lower RiemannSum, Intervall [0,1], n parts"$ (%i9) /*area width*/ b:1/n$ (%i10) /*area depending on k=0,...,n1*/ A(k):=k*f(k*b)$ (%i11) A(k); 3 k (%o11)  2 n (%i12) sum(A(k),k,0,n1); n  1 ==== (%o12) > A(k) / ==== k = 0 in that case you need ''(A(k)), a bracket and the doublequote. is it possible to patch the sumfunction in that way, that we first have the term or symbolsubstitution and second the summation?  >Comment By: Barton Willis (willisbl) Date: 20050613 06:30 Message: Logged In: YES user_id=895922 If we decide to use Robert's $sum function, the translate property for sum will need to be changed. Consider: (1) Redefine $sum as Robert suggested. (2) Try this: (%i1) ak : k^2$ (%i2) g(a,n) := sum(a,k,1,n)$ (%i3) g(ak,5); (%o3) 55 < correct for Robert's $sum function (%i4) translate(g); (%o4) [g] (%i5) g(ak,5); (%o5) 5*k^2 < yeech There might be other things that need fixing: (%i8) properties(sum); (%o8) [Special Evaluation Form,OUTATIVE,NOUN,RULE] Barton  Comment By: Robert Dodier (robert_dodier) Date: 20050612 21:34 Message: Logged In: YES user_id=501686 OK, for the record, here is a definition of $sum which implements one of the ideas that has been proposed, namely this policy: evaluate the summand after binding the summation variable to itself. (defmspec $sum (l) (setq l (cdr l)) (if (= (length l) 4) (progv (list (cadr l)) (list (cadr l)) (dosum (meval (car l)) (cadr l) (meval (caddr l)) (meval (cadddr l)) t)) (wnaerr '$sum))) This version yields the results expected by the person who originated this bug report, and yields the results predicted by S Macrakis in the email referenced below (http://www.math.utexas.edu/pipermail/maxima/2003/004869.html), and run_testsuite() runs to completion with no errors. I'm in favor of making this change, but I'm just recording this code snippet here for future reference; no changes planned at the moment. For comparison here is the current version of $sum: (defmspec $sum (l) (setq l (cdr l)) (if (= (length l) 4) (dosum (car l) (cadr l) (meval (caddr l)) (meval (cadddr l)) t) (wnaerr '$sum)))  Comment By: Barton Willis (willisbl) Date: 20050501 07:09 Message: Logged In: YES user_id=895922 We've discussed this before; see http://www.math.utexas.edu/pipermail/maxima/2003/004869.html http://www.math.utexas.edu/pipermail/maxima/2003/004870.html Maybe a simple workaround such as mysum(f,v,lo,hi):=block([acc:0], if integerp(lo) and integerp(hi) then for i from lo thru hi do acc:acc+substitute(i,v,f) else acc:funmake('mysum,[f,v,lo,hi]), acc) or mysum(f,lo,hi):= block([acc:0], if integerp(lo) and integerp(hi) then for i : lo thru hi do acc : acc + apply(f,[i]) else acc : funmake('mysum,[f,lo,hi]), acc); might work for you, Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1192935&group_id=4933 
From: SourceForge.net <noreply@so...>  20050613 05:57:59

Bugs item #1145990, was opened at 20050221 21:24 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1145990&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 Submitted By: Robert Dodier (robert_dodier) Assigned to: Nobody/Anonymous (nobody) Summary: affine package fails to load, and other strangeness Initial Comment: The affine package fails to load completely or correctly, and then what parts of it are loaded act strangely. load ("affine") appears to try to load everything, but stumbles with some error messages after getting through some of the files. load ("foo.lisp") for each Lisp file succeeds for most of the files but fails on some of them. Trying to execute fast_linsolve after staggering through the loading, I get an error that $POLY_VECTOR is undefined. But that's strange because it's defined in polya.lisp which apparently loaded successfully. Trying to execute grobner_basis I get an error that MUSTREPLACEP is undefined. But that's strange because it's defined in polysmp.lisp which apparently loaded successfully. No idea what's going on here, although my one suggestion is to cut out the autocompilation stuff if it's interfering with just getting the package loaded. Maxima version: 5.9.1 Maxima build date: 21:24 9/23/2004 host type: i686pclinuxgnu lispimplementationtype: CMU Common Lisp lispimplementationversion: 19a similar behavior seen with Maxima version: 5.9.1.1cvs Maxima build date: 21:51 2/10/2005 host type: i686redhatlinuxgnu lispimplementationtype: CLISP lispimplementationversion: 2.31 (released 20030901)  >Comment By: Robert Dodier (robert_dodier) Date: 20050612 23:57 Message: Logged In: YES user_id=501686 Executing load(affine); with Maxima 5.9.1cvs, clisp 2.33.2, now succeeds, although with lots of warning messages. After that, I can execute simple cases of fast_linsolve; didn't try anything more complicated. Executing load(affine) with Maxima 5.9.1cvs, gcl 2.6.6, barfs on compiling share/affine/sloop.lisp (first file). Didn't investigate.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1145990&group_id=4933 
From: SourceForge.net <noreply@so...>  20050613 05:54:04

Bugs item #740134, was opened at 20030519 16:13 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=740134&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 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: sum evals first argument inconsistently Initial Comment: Consider foo: i^2; sum('foo,i,0,2) => 3*foo (correct) sum(foo,i,0,2) => 3*i^2 WRONG sum(foo,i,0,n) => 'sum(i^2,i,0,n) (correct) In the case where upperlimitlowerlimit is a known integer, simpsum is checking whether foo is free of i *before* evaluating foo. I believe the correct way to handle this case is as follows: First evaluate foo with i bound to itself, and check if that result is free of i. If so, return the product. If not, *substitute* (don't evaluate) i=lowerlimit, i=lowerlimit+1, etc. This means that sum(print(i),i,1,2) would print "i", and not "1 2". That makes it consistent with Integrate: integrate('foo,i,0,2) => 2*foo (correct) integrate(foo,i,0,2) => 8/3 (correct) integrate(foo,i,0,n) => n^3/3 (correct) It also makes it consistent with Integrate in the presence of sideeffects: integrate(print(i),i,0,1) prints i sum(print(i),i,0,1) currently prints 0 1 but in this proposal would print i It is true that it would also create some funny situations. Currently, sum(integrate(x^i,x),i,0,2) evaluates correctly to x+x^2/2+x^3/3. Under this proposal, it would also evaluate *correctly*, but would first ask whether i+1 is zero or nonzero. Unless, that is, simpsum binds i to be an integer and to have a value >=lowerlimit and <=upperlimit (which is a sensible thing to do anyway). Now consider sum(integrate(1/(x^i+1),i),i,0,1) This currently correctly evaluates to x/2+log(x+1). Under the proposal, however, it would evaluate to a sum of noun forms, since the integral does not exist in closed form. I think we can live with that; an ev (...,integrate) takes care of it. But I still like the proposal. After all, if you set the result of the integration expression above to a temporary variable (which seems like a sensible thing to do), you will run into the original bad behavior.  >Comment By: Robert Dodier (robert_dodier) Date: 20050612 23:54 Message: Logged In: YES user_id=501686 The analysis presented in the original comments seems a little off the mark. In this example, foo: i^2; sum (foo, i, 0, 2); As shown by :lisp (trace meval), $sum is indeed evaluating the summand for each value of the index. Each of 3 evaluations (meval '$foo) yields ((MEXPT SIMP) $I 2), so the sum simplifies to 3 i^2. The problem here is that (meval '$foo) yields an expression with $i in it, and the expression isn't evaluated any farther. Replacing (meval exp) with (meval (meval exp)) in DOSUM yields the expected result, although I don't know if that's optimal. About the 'SUM(LAMBDA([x],x^i)(x),i,0,n) noted in the 2nd comment, this comes from $sum calling MEVALATOMS (eventually) to evaluate the summand. Calling MEVAL instead yields x^i as expected. $sum goes down the path to MEVALATOMS if the sum is something other than a finite sum; the lambda goes away if n is assigned a value e.g. 3 or something, since MEVAL is called instead of MEVALATOMS.  Comment By: Stavros Macrakis (macrakis) Date: 20030712 14:05 Message: Logged In: YES user_id=588346 More problems with the interaction between sumevaluation and hash arrays: (C1) f[i](x):=x^i$ (C2) g[i](x):=x^i$ (C3) h[i](x):=x^i$ (C4) f[i]; (D4) LAMBDA([x],x^i) (C5) g[i](t); (D5) t^i /* fine so far */ (C6) sum(f[i](x),i,0,n); (D6) 'SUM(LAMBDA([x],x^i)(x),i,0,n) /* oops, why are we seeing the lambda form here? This is some sort of partial evaluation.... */ (C7) sum(g[i](x),i,0,n); (D7) 'SUM(LAMBDA([x],x^i)(x),i,0,n) /* and here */ (C8) sum(h[i](x),i,0,n); (D8) 'SUM(h[i](x),i,0,n) /* but here we're not getting h[i] to evaluate at all, which is consistent with other cases, e.g.: */ (C9) sum(integrate(x^i,x),i,0,n); (D9) 'SUM(INTEGRATE(x^i,x),i,0,n);  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=740134&group_id=4933 
From: SourceForge.net <noreply@so...>  20050613 02:34:22

Bugs item #1192935, was opened at 20050430 05:10 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1192935&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 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: termsubstitution in function sum is too late Initial Comment: (%i1) "Lower RiemannSum, Intervall [0,1], 10 parts"$ (%i2) /*Function*/ f(x):=x^2$ (%i3) /*area width*/ b: 1/10$ (%i4) /*area depending on k=0,...,9*/ Ak: b*f(k*b)$ (%i5) Ak; 2 k (%o5)  1000 (%i6) /* wrong */ sum(Ak,k,0,9); 2 k (%o6)  100 obviously, we first have the summation and then the symbolsubstitution (%i7) sum(''Ak,k,0,9); 57 (%o7)  200 finally, this is ok, but the usage of the doublequote is hard to explain to beginners. it gets even worse, if you use a function A(k):=k*f(k*b)$ for a sum with n partitions: (%i8) "Lower RiemannSum, Intervall [0,1], n parts"$ (%i9) /*area width*/ b:1/n$ (%i10) /*area depending on k=0,...,n1*/ A(k):=k*f(k*b)$ (%i11) A(k); 3 k (%o11)  2 n (%i12) sum(A(k),k,0,n1); n  1 ==== (%o12) > A(k) / ==== k = 0 in that case you need ''(A(k)), a bracket and the doublequote. is it possible to patch the sumfunction in that way, that we first have the term or symbolsubstitution and second the summation?  >Comment By: Robert Dodier (robert_dodier) Date: 20050612 20:34 Message: Logged In: YES user_id=501686 OK, for the record, here is a definition of $sum which implements one of the ideas that has been proposed, namely this policy: evaluate the summand after binding the summation variable to itself. (defmspec $sum (l) (setq l (cdr l)) (if (= (length l) 4) (progv (list (cadr l)) (list (cadr l)) (dosum (meval (car l)) (cadr l) (meval (caddr l)) (meval (cadddr l)) t)) (wnaerr '$sum))) This version yields the results expected by the person who originated this bug report, and yields the results predicted by S Macrakis in the email referenced below (http://www.math.utexas.edu/pipermail/maxima/2003/004869.html), and run_testsuite() runs to completion with no errors. I'm in favor of making this change, but I'm just recording this code snippet here for future reference; no changes planned at the moment. For comparison here is the current version of $sum: (defmspec $sum (l) (setq l (cdr l)) (if (= (length l) 4) (dosum (car l) (cadr l) (meval (caddr l)) (meval (cadddr l)) t) (wnaerr '$sum)))  Comment By: Barton Willis (willisbl) Date: 20050501 06:09 Message: Logged In: YES user_id=895922 We've discussed this before; see http://www.math.utexas.edu/pipermail/maxima/2003/004869.html http://www.math.utexas.edu/pipermail/maxima/2003/004870.html Maybe a simple workaround such as mysum(f,v,lo,hi):=block([acc:0], if integerp(lo) and integerp(hi) then for i from lo thru hi do acc:acc+substitute(i,v,f) else acc:funmake('mysum,[f,v,lo,hi]), acc) or mysum(f,lo,hi):= block([acc:0], if integerp(lo) and integerp(hi) then for i : lo thru hi do acc : acc + apply(f,[i]) else acc : funmake('mysum,[f,lo,hi]), acc); might work for you, Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1192935&group_id=4933 