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

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{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...>  20050627 00:30:38

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: 20050626 18:30 Message: Logged In: YES user_id=501686 attempting to remove old version of rtestsum.mac and upload new version in the same update... let's see if it works.  Comment By: Robert Dodier (robert_dodier) Date: 20050621 00:18 Message: Logged In: YES user_id=501686 New DOSUM, etc, in tmpsum8.lisp. A few new sum tests have been added to rtestsum.mac, and all sum tests copied and turned into product tests. This revision passes all tests in current rtestsum.mac except for test 38: (assume(i < 0, j < 0, n > 0), product(product(abs(j) + abs(i), i, 1, j), j, 1, n)); => Lower bound to product is > upper bound. This emanates from SIMPROD1 (src/combin.lisp) which is called after the assumptions about i and j (actually, assumptions about the gensym standins for i and j) have been forgotten. This looks like a bug in combin.lisp  there is no assume/forget about the indices.  Comment By: Robert Dodier (robert_dodier) Date: 20050621 00:06 Message: Logged In: YES user_id=501686 New rtestsum.mac. A couple of new tests for sum, and also copied all sum tests and substituted product for sum (and adjusted expected outputs to suit).  Comment By: Robert Dodier (robert_dodier) Date: 20050621 00:03 Message: Logged In: YES user_id=501686 Delete rtestsum.mac, going to upload a new one momentarily.  Comment By: Robert Dodier (robert_dodier) Date: 20050619 23:27 Message: Logged In: YES user_id=501686 About sum(rat(k),k,1,3), calling $FREEOF instead of FREEOF makes it happy again. Oh well. I think I'll just hang onto the current rev for a day or two to see what other changes accumulate, before posting a new version of tmpsum*.lisp. A related bit  sum(rat(k), k, 1, n) returns 'sum (k, k, 1, n), which isn't exactly wrong, but it does make me wonder what happened to the rat... it turns out this is what happened: subst (foo, k, rat(k)) => foo Not rat(foo) as I would have expected. Dunno what this is about.  Comment By: Barton Willis (willisbl) Date: 20050619 21:36 Message: Logged In: YES user_id=895922 Does tmpsum6.lisp need a ratdisrep somewhere? (%i1) load("c:/maxima/tmpsum6.lisp")$ (%i2) sum(k,k,1,3); (%o2) 6 (%i3) sum(rat(k),k,1,3); Maxima encountered a Lisp error: Error in COND [or a callee]: Caught fatal error [memory may be damaged] Automatically continuing. To reenable the Lisp debugger set *debuggerhook* to nil. (%i4) Barton  Comment By: Robert Dodier (robert_dodier) Date: 20050619 20:28 Message: Logged In: YES user_id=501686 Yet another revision (attached file tmpsum6.lisp) of DOSUM and friends. This version passes run_testsuite() and batch ("rtestsum.mac", test) using the currently attached version of rtestsum.mac. This version avoids substituting for the index in expressions which are free of the index. This version also has an alternate definition of the function FREE. The simplification code (and other code) calls FREE instead of FREEOF. FREEOF looks for dummy variables, but FREE does not, so with the original defn of FREE, sum (lambda([i], i^2), i, 1, n) does not simplify to n lambda ([i], i^2), i, 1, n). I'm not very happy about changing FREE since it is called from all over the place, but I'm also not very happy about the presence of FREE, either; why not call FREEOF ? I don't think changing FREE at this point is such a good idea; it seems to me the two choices are (1) inspect the sum/product simplification code and change FREE to FREEOF where possible. That would be a lot of work. (2) Leave FREE as it is, and just accept that expressions with dummy variables can't be factored out of summations. At this point I think I'd rather leave FREE alone, and file a separate bug report about the inability to factor out expressions with dummy variables, and just leave it for another day.  Comment By: Robert Dodier (robert_dodier) Date: 20050619 20:04 Message: Logged In: YES user_id=501686 New version of rtestsum.mac. Two new test cases, sum (lambda ([i], i^2, 1, 3) and sum (lambda ([i], i^2), i, 1, n).  Comment By: Robert Dodier (robert_dodier) Date: 20050619 19:59 Message: Logged In: YES user_id=501686 Removing rtestsum.mac, will upload a new version momentarily.  Comment By: Robert Dodier (robert_dodier) Date: 20050619 10:52 Message: Logged In: YES user_id=501686 I'm attaching my latest and greatest revision (tmpsum5.lisp) of DOSUM, DO%SUM, and MEVALSUMARGS. I find that load ("tmpsum5.lisp"); batch ("rtestsum.mac", test); where rtestsum.mac is the currently attached version, yields all tests passed for Maxima 5.9.1cvs built with clisp 2.33.2 and with gcl 2.6.6. This revision uses a gensym index for cases handled by MEVALSUMARGS (i.e., cases for which (upper limit) minus (lower limit) is not an integer); the gensym index is the argument for assume/forget. When upper minus lower is an integer, the index is bound to lower, lower+1, lower+2, etc., the summand is evaluated, and then lower, lower+1, lower+2, etc. is substituted for any remaining instances of index.  Comment By: Robert Dodier (robert_dodier) Date: 20050619 10:33 Message: Logged In: YES user_id=501686 Attaching a longer list of test cases. batch ("rtestsum.mac", test); executes the test. As always the "correct" results (2nd line in each pair) are subject to review.  Comment By: Robert Dodier (robert_dodier) Date: 20050619 10:28 Message: Logged In: YES user_id=501686 I'm removing rtestsum.mac, in anticipation of attaching a new version in a minute.  Comment By: van_Nek (van_nek) Date: 20050618 11:42 Message: Logged In: YES user_id=1269745 Dear Maximadevelopers, thank you for your support. I tried the last fix from Robert Dodier and it works. Volker van Nek original (anonymous) poster  Comment By: Robert Dodier (robert_dodier) Date: 20050615 08:37 Message: Logged In: YES user_id=501686 I'm attaching a list of test cases for sum, which can be executed by batch ("rtestsum.mac", test) . Doubtless there will be some discussion as to what the expected output of each test should be. All tests pass after making these 2 changes: ;; ORIGINAL: MEVAL ONCE ;; (mbinding (lind l*i) (meval exp)) ;; TRIED THIS: MEVAL TWICE ;; (mbinding (lind l*i) (meval (meval exp))) ;; THIRD TIME IS A CHARM ?? ($substitute *i ind (mbinding (lind l*i) (meval exp))) ;; ORIGINAL: MEVALATOMS ;; (resimplify (mevalatoms (if (and (not (atom exp)) (resimplify (meval (if (and (not (atom exp))  Comment By: Robert Dodier (robert_dodier) Date: 20050614 08:42 Message: Logged In: YES user_id=501686 OK, here is another attempt. I think I now understand this comment by Stavros in bug report # 740134  "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." ;; ORIGINAL: MEVAL ONCE ;; (mbinding (lind l*i) (meval exp)) ;; TRIED THIS: MEVAL TWICE ;; (mbinding (lind l*i) (meval (meval exp))) ;; THIRD TIME IS A CHARM ?? ($substitute *i ind (mbinding (lind l*i) (meval exp))) This version now yields this result  ex 9: f(x) := sum (x, i, 1, 3); f(x) => 3 x as expected, as well as the same results for ex 1 through ex 8.  Comment By: Robert Dodier (robert_dodier) Date: 20050613 23:00 Message: Logged In: YES user_id=501686 Actually, after looking at the code some more (specifically DOSUM in src/asum.lisp) it looks to me like the intent is indeed to evaluate the summand after binding the summation index to itself. In addition, there is code to assume the index is between its lower and upper limits (although assume/forget is handled incorrectly, see 851765). I believe that the observed behavior is a bug, in the narrow sense that the observed behavior is different from what the code author intended. See also my comments on SF bug # 740134. Here is a different patch. I like this one better than the previous one. In DOSUM: ;; ORIGINAL: MEVAL ONCE ;; (mbinding (lind l*i) (meval exp)) (mbinding (lind l*i) (meval (meval exp))) In MEVALSUMARG: ;; ORIGINAL: MEVALATOMS ;; (resimplify (mevalatoms (if (and (not (atom exp)) (resimplify (meval (if (and (not (atom exp)) With these changes, the results are as expected for the examples cited by the original poster, and also the example about the translated function produces the correct result, and some examples adapted from another bug report (740134) yield correct results. ex 1: f(x):=x^2$ b: 1/10$ Ak: b*f(k*b)$ sum(Ak,k,0,9); => 57/200 ex 2: A(k):=k*f(k*b)$ b:1/n$ A(k) => k^3/n^2 sum(A(k),k,0,n1) => ('sum(k^3,k,0,n1))/n^2 sum(A(k),k,0,n1), simpsum => ((n1)^4 + 2*(n1)^3 + (n1)^2) / (4*n^2) ex 3: ak : k^2$ g(a,n) := sum(a,k,1,n)$ g(ak,5) => 55 translate (g)$ g(ak,5) => 55 some other examples, adapted from bug # 740134: ex 4: sum (print (i), i, 1, 3) => prints 1, 2, 3 then returns 6 ex 5: sum (integrate (x^i ,x), i, 0, 2) => x^3/3 + x^2/2 + x ex 6: sum (integrate (1/(x^i + 1), x), i, 0, 1) => log(x+1) + x/2 ex 7: f[i](x):=x^i$ g[i](x):=x^i$ h[i](x):=x^i$ /* reference f[i] and g[i]  see 740134 for the effect this has on previous defn of sum */ f[i]$ g[i](t)$ sum (f[i](x), i, 0, n) => 'sum (x^i, i, 0, n) sum (g[i](x), i, 0, n) => 'sum (x^i, i, 0, n) sum (h[i](x), i, 0, n) => 'sum (x^i, i, 0, n) ex 8: sum (integrate (x^i, x), i, 0, n) => 'sum (x^(i+1) / (i+1), i, 0, n)  Comment By: Barton Willis (willisbl) Date: 20050613 05: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 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 
From: SourceForge.net <noreply@so...>  20050626 23:24:22

Bugs item #1227953, was opened at 20050626 17:24 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=1227953&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 Submitted By: Robert Dodier (robert_dodier) Assigned to: Nobody/Anonymous (nobody) Summary: uncaught exception on floating point overflow (GCL) Initial Comment: Using GCL 2.6.6/Maxima 5.9.1cvs. Usually if there is a floating point overflow, Maxima catches the GCL error and returns to the Maxima command prompt after printing an error message. E.g. in a fresh session: (%i1) 1e300*1e300; Maxima encountered a Lisp error: Error in PROGN [or a callee]: Can't print a nonnumber. Automatically continuing. To reenable the Lisp debugger set *debuggerhook* to nil. (%i2) However, sometimes the error is not caught, and instead of getting the Maxima prompt, the user gets the GCL debugger prompt. I've been able to cause this to happen a few times, but the only reproduceable example I have is the following. The example is contained in the attached file musa.mac.  begin transcript  (%i1) T: matrix ([3, 45, 6, 7, 8]); (%o1) [ 3 45 6 7 8 ] (%i2) t: matrix ([0, 3, 48, 54, 61, 69]); (%o2) [ 0 3 48 54 61 69 ] (%i3) F1(N,F):= 5/N  sum (F*exp(F*t[1,i])*T[1,i], i, 1, 5); 5 (%o3) F1(N, F) :=   sum(F exp(( F) t ) T , i, 1, 5) N 1, i 1, i (%i4) F2(N,F):= 5/F  sum(N*exp(F*t[1,i]),i,1,5) + sum(F*N*t[1,i]*exp(F*t[1,i])*T[1, i],i,1,5)  sum (t[1,i],i,1,5); 5 (%o4) F2(N, F) :=   sum(N exp(( F) t ), i, 1, 5) F 1, i + sum(F N t exp(( F) t ) T , i, 1, 5) 1, i 1, i 1, i  sum(t , i, 1, 5) 1, i (%i5) load (mnewton); (%o5) /home/robert/tmp/maximaclean/maxima/share/contrib/mnewton.mac (%i6) mnewton ([F1(N,F), F2(N,F)], [N, F], [1, 1]); Maxima encountered a Lisp error: Error in MACSYMATOPLEVEL [or a callee]: Error in PCL::PRINTSTDINSTANCE [or a callee]: Can't print a nonnumber. Fast links are on: do (usefastlinks nil) for debugging Broken at PRINTOBJECT. Type :H for Help. 1 (Continue) Macsyma toplevel 2 (Abort) Return to top level. dbl:MAXIMA>>  end transcript  The error appears to be generated by the line numdet:float(sublis(Solutions,det)), in mnewton.mac. See also bug report 781726.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1227953&group_id=4933 
From: SourceForge.net <noreply@so...>  20050626 23:11:34

Bugs item #781726, was opened at 20030801 14:45 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=781726&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 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: Problems with IEEEfloat NaN and INF Initial Comment: flinf: 2.0^1024$ flinf => Error: Can't print a nonnumber (lisp break) Should print something special, e.g. INFe0 flnan: flinfflinf$ flnan => Bind stack overflow (lisp break) Should print something special, e.g. NaNe0 is(flnan=flnan) => TRUE NO! NaN is not equal to itself; cf ?=(flnan,flnan). is(flnan>0) => TRUE NO! is(flnan<0) => TRUE NO! flnan*0 => 0 NO! flinf*0 => 0 NO! GCL also can't print flnan/flinf. Maxima 5.9.0 gcl 2.5.0 mingw Windows 2000 Athlon  >Comment By: Robert Dodier (robert_dodier) Date: 20050626 17:11 Message: Logged In: YES user_id=501686 In reference to the examples given in the original writeup, it is worth pointing out that GCL does indeed compute inf and nan; it just can't display them. Clisp refuses to compute the inf or nan, and there doesn't appear to be a way to compel it to do so. CMUCL is happy with inf and nan after :lisp (extensions::setfloatingpointmodes :traps nil) is executed.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=781726&group_id=4933 
From: SourceForge.net <noreply@so...>  20050625 20:04:39

Bugs item #1224960, was opened at 20050621 11:36 Message generated for change (Comment added) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1224960&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: Fix for 5.9.2 Status: Open Resolution: None Priority: 5 Submitted By: van_Nek (van_nek) Assigned to: Nobody/Anonymous (nobody) Summary: sideeffect with copylist Initial Comment: (%i1) list:[1,[2,2],3]$ (%i2) copy:copylist(list)$ (%i3) copy[2][2]:42$ (%i4) list; (%o4) [1, [2, 42], 3]  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  I expected copylist to be fully functional. That is not the case. I had a look into comm2.lisp where copylist is defined. copylist uses copytoplevel from maxmac.lisp, which I do not understand, but I have doubts, that copylist does really cons recursively in sublists. The effect is, that for a sublist the full pointer is copied. Volker van Nek  >Comment By: Barton Willis (willisbl) Date: 20050625 15:04 Message: Logged In: YES user_id=895922 One fix is to replace copytoplevel with copytree. (defmfun $copylist (x) (if (not ($listp x)) (merror "argument not a list  copylist:~%~m" x)) (cons (car x) (copytree (cdr x)))) I don't know why copylist doesn't just do copytree on all of x. A second fix (change the error message too): (defun $copylist (x) (if ($listp x) (copytree x) (merror "The argument to 'copylist' must be a list; instead the argument was ~:M" x))) Finally, I don't understand the need for copylist and copymatrix. What's wrong with simply copy (maybe this copy doesn't work with maxima arrays? Anything else?) (defun $copy (x) (copytree x)) Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1224960&group_id=4933 
From: SourceForge.net <noreply@so...>  20050623 11:57:43

Bugs item #1226208, was opened at 20050623 04:57 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=1226208&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 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: solving E/exponent equation hangs Initial Comment: I cancelled both of these after waiting several minutes: (%i26) solve(2*%e^(200*t)=8*%e^(8000*t),t); Maxima encountered a Lisp error: Console interrupt. Automatically continuing. To reenable the Lisp debugger set *debuggerhook* to nil. (%i27) solve(0=2*%e^(200*t)+8*%e^(8000*t),t); Maxima encountered a Lisp error: Console interrupt. Automatically continuing. To reenable the Lisp debugger set *debuggerhook* to nil. David Logan djlogan2@...  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1226208&group_id=4933 
From: SourceForge.net <noreply@so...>  20050621 18:35:55

Bugs item #1222927, was opened at 20050617 23:54 Message generated for change (Comment added) made by van_nek You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1222927&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: Fix for 5.9.2 Status: Open Resolution: None Priority: 5 Submitted By: van_Nek (van_nek) Assigned to: Nobody/Anonymous (nobody) Summary: scope for a variable in buildq? Initial Comment: (%i1) printlist(list)::=buildq([temp:ev(list)],print(splice(temp)))$ (%i2) list:[1,2,3]$ (%i3) printlist(list); SPLICE(TEMP) returned LIST But SPLICE must return a list #0: printlist(list=LIST)  an error. Quitting. To debug this try DEBUGMODE(TRUE); (%i4) ref:list$ (%i5) printlist(ref); 1 2 3 (%o5) 3 this is confusing! (%i12) f(x):=x**2$ (%i13) x:3$ (%i14) f(x); (%o14) 9 that works! Am I not allowed to use any name for a variable in buildq? van_Nek van.Nek@...  >Comment By: van_Nek (van_nek) Date: 20050621 18:10 Message: Logged In: YES user_id=1269745 Dear Robert Dodier, thanks for your answer. I am not really happy with the work of SPLICE in BUILDQ, but you showed, that with the use of APPLY there is a much easier way. Volker van Nek  Comment By: Robert Dodier (robert_dodier) Date: 20050619 04:24 Message: Logged In: YES user_id=501686 The problem is that before expanding printlist, the formal argument list is bound to the actual argument, also named list. Given that, ev (list) => list (not the actual [1, 2, 3]) and then splice complains. Same complaint if the formal and actual arguments have the same name (something other than "list"), e.g., FOO. This is strange, although I'm not sure if it can be considered a bug, as it is a straightforward consequence of the general rules for binding and evaluation. In any event, maybe apply (print, list) has the effect you want? How about: printlist (list) := apply (print, list); list: [1,2,3]; printlist (list); 1 2 3 3  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1222927&group_id=4933 
From: SourceForge.net <noreply@so...>  20050621 16:36:23

Bugs item #1224960, was opened at 20050621 18:36 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=1224960&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: Fix for 5.9.2 Status: Open Resolution: None Priority: 5 Submitted By: van_Nek (van_nek) Assigned to: Nobody/Anonymous (nobody) Summary: sideeffect with copylist Initial Comment: (%i1) list:[1,[2,2],3]$ (%i2) copy:copylist(list)$ (%i3) copy[2][2]:42$ (%i4) list; (%o4) [1, [2, 42], 3]  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  I expected copylist to be fully functional. That is not the case. I had a look into comm2.lisp where copylist is defined. copylist uses copytoplevel from maxmac.lisp, which I do not understand, but I have doubts, that copylist does really cons recursively in sublists. The effect is, that for a sublist the full pointer is copied. Volker van Nek  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1224960&group_id=4933 
From: SourceForge.net <noreply@so...>  20050621 06:18:50

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: 20050621 00:18 Message: Logged In: YES user_id=501686 New DOSUM, etc, in tmpsum8.lisp. A few new sum tests have been added to rtestsum.mac, and all sum tests copied and turned into product tests. This revision passes all tests in current rtestsum.mac except for test 38: (assume(i < 0, j < 0, n > 0), product(product(abs(j) + abs(i), i, 1, j), j, 1, n)); => Lower bound to product is > upper bound. This emanates from SIMPROD1 (src/combin.lisp) which is called after the assumptions about i and j (actually, assumptions about the gensym standins for i and j) have been forgotten. This looks like a bug in combin.lisp  there is no assume/forget about the indices.  Comment By: Robert Dodier (robert_dodier) Date: 20050621 00:06 Message: Logged In: YES user_id=501686 New rtestsum.mac. A couple of new tests for sum, and also copied all sum tests and substituted product for sum (and adjusted expected outputs to suit).  Comment By: Robert Dodier (robert_dodier) Date: 20050621 00:03 Message: Logged In: YES user_id=501686 Delete rtestsum.mac, going to upload a new one momentarily.  Comment By: Robert Dodier (robert_dodier) Date: 20050619 23:27 Message: Logged In: YES user_id=501686 About sum(rat(k),k,1,3), calling $FREEOF instead of FREEOF makes it happy again. Oh well. I think I'll just hang onto the current rev for a day or two to see what other changes accumulate, before posting a new version of tmpsum*.lisp. A related bit  sum(rat(k), k, 1, n) returns 'sum (k, k, 1, n), which isn't exactly wrong, but it does make me wonder what happened to the rat... it turns out this is what happened: subst (foo, k, rat(k)) => foo Not rat(foo) as I would have expected. Dunno what this is about.  Comment By: Barton Willis (willisbl) Date: 20050619 21:36 Message: Logged In: YES user_id=895922 Does tmpsum6.lisp need a ratdisrep somewhere? (%i1) load("c:/maxima/tmpsum6.lisp")$ (%i2) sum(k,k,1,3); (%o2) 6 (%i3) sum(rat(k),k,1,3); Maxima encountered a Lisp error: Error in COND [or a callee]: Caught fatal error [memory may be damaged] Automatically continuing. To reenable the Lisp debugger set *debuggerhook* to nil. (%i4) Barton  Comment By: Robert Dodier (robert_dodier) Date: 20050619 20:28 Message: Logged In: YES user_id=501686 Yet another revision (attached file tmpsum6.lisp) of DOSUM and friends. This version passes run_testsuite() and batch ("rtestsum.mac", test) using the currently attached version of rtestsum.mac. This version avoids substituting for the index in expressions which are free of the index. This version also has an alternate definition of the function FREE. The simplification code (and other code) calls FREE instead of FREEOF. FREEOF looks for dummy variables, but FREE does not, so with the original defn of FREE, sum (lambda([i], i^2), i, 1, n) does not simplify to n lambda ([i], i^2), i, 1, n). I'm not very happy about changing FREE since it is called from all over the place, but I'm also not very happy about the presence of FREE, either; why not call FREEOF ? I don't think changing FREE at this point is such a good idea; it seems to me the two choices are (1) inspect the sum/product simplification code and change FREE to FREEOF where possible. That would be a lot of work. (2) Leave FREE as it is, and just accept that expressions with dummy variables can't be factored out of summations. At this point I think I'd rather leave FREE alone, and file a separate bug report about the inability to factor out expressions with dummy variables, and just leave it for another day.  Comment By: Robert Dodier (robert_dodier) Date: 20050619 20:04 Message: Logged In: YES user_id=501686 New version of rtestsum.mac. Two new test cases, sum (lambda ([i], i^2, 1, 3) and sum (lambda ([i], i^2), i, 1, n).  Comment By: Robert Dodier (robert_dodier) Date: 20050619 19:59 Message: Logged In: YES user_id=501686 Removing rtestsum.mac, will upload a new version momentarily.  Comment By: Robert Dodier (robert_dodier) Date: 20050619 10:52 Message: Logged In: YES user_id=501686 I'm attaching my latest and greatest revision (tmpsum5.lisp) of DOSUM, DO%SUM, and MEVALSUMARGS. I find that load ("tmpsum5.lisp"); batch ("rtestsum.mac", test); where rtestsum.mac is the currently attached version, yields all tests passed for Maxima 5.9.1cvs built with clisp 2.33.2 and with gcl 2.6.6. This revision uses a gensym index for cases handled by MEVALSUMARGS (i.e., cases for which (upper limit) minus (lower limit) is not an integer); the gensym index is the argument for assume/forget. When upper minus lower is an integer, the index is bound to lower, lower+1, lower+2, etc., the summand is evaluated, and then lower, lower+1, lower+2, etc. is substituted for any remaining instances of index.  Comment By: Robert Dodier (robert_dodier) Date: 20050619 10:33 Message: Logged In: YES user_id=501686 Attaching a longer list of test cases. batch ("rtestsum.mac", test); executes the test. As always the "correct" results (2nd line in each pair) are subject to review.  Comment By: Robert Dodier (robert_dodier) Date: 20050619 10:28 Message: Logged In: YES user_id=501686 I'm removing rtestsum.mac, in anticipation of attaching a new version in a minute.  Comment By: van_Nek (van_nek) Date: 20050618 11:42 Message: Logged In: YES user_id=1269745 Dear Maximadevelopers, thank you for your support. I tried the last fix from Robert Dodier and it works. Volker van Nek original (anonymous) poster  Comment By: Robert Dodier (robert_dodier) Date: 20050615 08:37 Message: Logged In: YES user_id=501686 I'm attaching a list of test cases for sum, which can be executed by batch ("rtestsum.mac", test) . Doubtless there will be some discussion as to what the expected output of each test should be. All tests pass after making these 2 changes: ;; ORIGINAL: MEVAL ONCE ;; (mbinding (lind l*i) (meval exp)) ;; TRIED THIS: MEVAL TWICE ;; (mbinding (lind l*i) (meval (meval exp))) ;; THIRD TIME IS A CHARM ?? ($substitute *i ind (mbinding (lind l*i) (meval exp))) ;; ORIGINAL: MEVALATOMS ;; (resimplify (mevalatoms (if (and (not (atom exp)) (resimplify (meval (if (and (not (atom exp))  Comment By: Robert Dodier (robert_dodier) Date: 20050614 08:42 Message: Logged In: YES user_id=501686 OK, here is another attempt. I think I now understand this comment by Stavros in bug report # 740134  "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." ;; ORIGINAL: MEVAL ONCE ;; (mbinding (lind l*i) (meval exp)) ;; TRIED THIS: MEVAL TWICE ;; (mbinding (lind l*i) (meval (meval exp))) ;; THIRD TIME IS A CHARM ?? ($substitute *i ind (mbinding (lind l*i) (meval exp))) This version now yields this result  ex 9: f(x) := sum (x, i, 1, 3); f(x) => 3 x as expected, as well as the same results for ex 1 through ex 8.  Comment By: Robert Dodier (robert_dodier) Date: 20050613 23:00 Message: Logged In: YES user_id=501686 Actually, after looking at the code some more (specifically DOSUM in src/asum.lisp) it looks to me like the intent is indeed to evaluate the summand after binding the summation index to itself. In addition, there is code to assume the index is between its lower and upper limits (although assume/forget is handled incorrectly, see 851765). I believe that the observed behavior is a bug, in the narrow sense that the observed behavior is different from what the code author intended. See also my comments on SF bug # 740134. Here is a different patch. I like this one better than the previous one. In DOSUM: ;; ORIGINAL: MEVAL ONCE ;; (mbinding (lind l*i) (meval exp)) (mbinding (lind l*i) (meval (meval exp))) In MEVALSUMARG: ;; ORIGINAL: MEVALATOMS ;; (resimplify (mevalatoms (if (and (not (atom exp)) (resimplify (meval (if (and (not (atom exp)) With these changes, the results are as expected for the examples cited by the original poster, and also the example about the translated function produces the correct result, and some examples adapted from another bug report (740134) yield correct results. ex 1: f(x):=x^2$ b: 1/10$ Ak: b*f(k*b)$ sum(Ak,k,0,9); => 57/200 ex 2: A(k):=k*f(k*b)$ b:1/n$ A(k) => k^3/n^2 sum(A(k),k,0,n1) => ('sum(k^3,k,0,n1))/n^2 sum(A(k),k,0,n1), simpsum => ((n1)^4 + 2*(n1)^3 + (n1)^2) / (4*n^2) ex 3: ak : k^2$ g(a,n) := sum(a,k,1,n)$ g(ak,5) => 55 translate (g)$ g(ak,5) => 55 some other examples, adapted from bug # 740134: ex 4: sum (print (i), i, 1, 3) => prints 1, 2, 3 then returns 6 ex 5: sum (integrate (x^i ,x), i, 0, 2) => x^3/3 + x^2/2 + x ex 6: sum (integrate (1/(x^i + 1), x), i, 0, 1) => log(x+1) + x/2 ex 7: f[i](x):=x^i$ g[i](x):=x^i$ h[i](x):=x^i$ /* reference f[i] and g[i]  see 740134 for the effect this has on previous defn of sum */ f[i]$ g[i](t)$ sum (f[i](x), i, 0, n) => 'sum (x^i, i, 0, n) sum (g[i](x), i, 0, n) => 'sum (x^i, i, 0, n) sum (h[i](x), i, 0, n) => 'sum (x^i, i, 0, n) ex 8: sum (integrate (x^i, x), i, 0, n) => 'sum (x^(i+1) / (i+1), i, 0, n)  Comment By: Barton Willis (willisbl) Date: 20050613 05: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 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 
From: SourceForge.net <noreply@so...>  20050621 06:06:50

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: 20050621 00:06 Message: Logged In: YES user_id=501686 New rtestsum.mac. A couple of new tests for sum, and also copied all sum tests and substituted product for sum (and adjusted expected outputs to suit).  Comment By: Robert Dodier (robert_dodier) Date: 20050621 00:03 Message: Logged In: YES user_id=501686 Delete rtestsum.mac, going to upload a new one momentarily.  Comment By: Robert Dodier (robert_dodier) Date: 20050619 23:27 Message: Logged In: YES user_id=501686 About sum(rat(k),k,1,3), calling $FREEOF instead of FREEOF makes it happy again. Oh well. I think I'll just hang onto the current rev for a day or two to see what other changes accumulate, before posting a new version of tmpsum*.lisp. A related bit  sum(rat(k), k, 1, n) returns 'sum (k, k, 1, n), which isn't exactly wrong, but it does make me wonder what happened to the rat... it turns out this is what happened: subst (foo, k, rat(k)) => foo Not rat(foo) as I would have expected. Dunno what this is about.  Comment By: Barton Willis (willisbl) Date: 20050619 21:36 Message: Logged In: YES user_id=895922 Does tmpsum6.lisp need a ratdisrep somewhere? (%i1) load("c:/maxima/tmpsum6.lisp")$ (%i2) sum(k,k,1,3); (%o2) 6 (%i3) sum(rat(k),k,1,3); Maxima encountered a Lisp error: Error in COND [or a callee]: Caught fatal error [memory may be damaged] Automatically continuing. To reenable the Lisp debugger set *debuggerhook* to nil. (%i4) Barton  Comment By: Robert Dodier (robert_dodier) Date: 20050619 20:28 Message: Logged In: YES user_id=501686 Yet another revision (attached file tmpsum6.lisp) of DOSUM and friends. This version passes run_testsuite() and batch ("rtestsum.mac", test) using the currently attached version of rtestsum.mac. This version avoids substituting for the index in expressions which are free of the index. This version also has an alternate definition of the function FREE. The simplification code (and other code) calls FREE instead of FREEOF. FREEOF looks for dummy variables, but FREE does not, so with the original defn of FREE, sum (lambda([i], i^2), i, 1, n) does not simplify to n lambda ([i], i^2), i, 1, n). I'm not very happy about changing FREE since it is called from all over the place, but I'm also not very happy about the presence of FREE, either; why not call FREEOF ? I don't think changing FREE at this point is such a good idea; it seems to me the two choices are (1) inspect the sum/product simplification code and change FREE to FREEOF where possible. That would be a lot of work. (2) Leave FREE as it is, and just accept that expressions with dummy variables can't be factored out of summations. At this point I think I'd rather leave FREE alone, and file a separate bug report about the inability to factor out expressions with dummy variables, and just leave it for another day.  Comment By: Robert Dodier (robert_dodier) Date: 20050619 20:04 Message: Logged In: YES user_id=501686 New version of rtestsum.mac. Two new test cases, sum (lambda ([i], i^2, 1, 3) and sum (lambda ([i], i^2), i, 1, n).  Comment By: Robert Dodier (robert_dodier) Date: 20050619 19:59 Message: Logged In: YES user_id=501686 Removing rtestsum.mac, will upload a new version momentarily.  Comment By: Robert Dodier (robert_dodier) Date: 20050619 10:52 Message: Logged In: YES user_id=501686 I'm attaching my latest and greatest revision (tmpsum5.lisp) of DOSUM, DO%SUM, and MEVALSUMARGS. I find that load ("tmpsum5.lisp"); batch ("rtestsum.mac", test); where rtestsum.mac is the currently attached version, yields all tests passed for Maxima 5.9.1cvs built with clisp 2.33.2 and with gcl 2.6.6. This revision uses a gensym index for cases handled by MEVALSUMARGS (i.e., cases for which (upper limit) minus (lower limit) is not an integer); the gensym index is the argument for assume/forget. When upper minus lower is an integer, the index is bound to lower, lower+1, lower+2, etc., the summand is evaluated, and then lower, lower+1, lower+2, etc. is substituted for any remaining instances of index.  Comment By: Robert Dodier (robert_dodier) Date: 20050619 10:33 Message: Logged In: YES user_id=501686 Attaching a longer list of test cases. batch ("rtestsum.mac", test); executes the test. As always the "correct" results (2nd line in each pair) are subject to review.  Comment By: Robert Dodier (robert_dodier) Date: 20050619 10:28 Message: Logged In: YES user_id=501686 I'm removing rtestsum.mac, in anticipation of attaching a new version in a minute.  Comment By: van_Nek (van_nek) Date: 20050618 11:42 Message: Logged In: YES user_id=1269745 Dear Maximadevelopers, thank you for your support. I tried the last fix from Robert Dodier and it works. Volker van Nek original (anonymous) poster  Comment By: Robert Dodier (robert_dodier) Date: 20050615 08:37 Message: Logged In: YES user_id=501686 I'm attaching a list of test cases for sum, which can be executed by batch ("rtestsum.mac", test) . Doubtless there will be some discussion as to what the expected output of each test should be. All tests pass after making these 2 changes: ;; ORIGINAL: MEVAL ONCE ;; (mbinding (lind l*i) (meval exp)) ;; TRIED THIS: MEVAL TWICE ;; (mbinding (lind l*i) (meval (meval exp))) ;; THIRD TIME IS A CHARM ?? ($substitute *i ind (mbinding (lind l*i) (meval exp))) ;; ORIGINAL: MEVALATOMS ;; (resimplify (mevalatoms (if (and (not (atom exp)) (resimplify (meval (if (and (not (atom exp))  Comment By: Robert Dodier (robert_dodier) Date: 20050614 08:42 Message: Logged In: YES user_id=501686 OK, here is another attempt. I think I now understand this comment by Stavros in bug report # 740134  "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." ;; ORIGINAL: MEVAL ONCE ;; (mbinding (lind l*i) (meval exp)) ;; TRIED THIS: MEVAL TWICE ;; (mbinding (lind l*i) (meval (meval exp))) ;; THIRD TIME IS A CHARM ?? ($substitute *i ind (mbinding (lind l*i) (meval exp))) This version now yields this result  ex 9: f(x) := sum (x, i, 1, 3); f(x) => 3 x as expected, as well as the same results for ex 1 through ex 8.  Comment By: Robert Dodier (robert_dodier) Date: 20050613 23:00 Message: Logged In: YES user_id=501686 Actually, after looking at the code some more (specifically DOSUM in src/asum.lisp) it looks to me like the intent is indeed to evaluate the summand after binding the summation index to itself. In addition, there is code to assume the index is between its lower and upper limits (although assume/forget is handled incorrectly, see 851765). I believe that the observed behavior is a bug, in the narrow sense that the observed behavior is different from what the code author intended. See also my comments on SF bug # 740134. Here is a different patch. I like this one better than the previous one. In DOSUM: ;; ORIGINAL: MEVAL ONCE ;; (mbinding (lind l*i) (meval exp)) (mbinding (lind l*i) (meval (meval exp))) In MEVALSUMARG: ;; ORIGINAL: MEVALATOMS ;; (resimplify (mevalatoms (if (and (not (atom exp)) (resimplify (meval (if (and (not (atom exp)) With these changes, the results are as expected for the examples cited by the original poster, and also the example about the translated function produces the correct result, and some examples adapted from another bug report (740134) yield correct results. ex 1: f(x):=x^2$ b: 1/10$ Ak: b*f(k*b)$ sum(Ak,k,0,9); => 57/200 ex 2: A(k):=k*f(k*b)$ b:1/n$ A(k) => k^3/n^2 sum(A(k),k,0,n1) => ('sum(k^3,k,0,n1))/n^2 sum(A(k),k,0,n1), simpsum => ((n1)^4 + 2*(n1)^3 + (n1)^2) / (4*n^2) ex 3: ak : k^2$ g(a,n) := sum(a,k,1,n)$ g(ak,5) => 55 translate (g)$ g(ak,5) => 55 some other examples, adapted from bug # 740134: ex 4: sum (print (i), i, 1, 3) => prints 1, 2, 3 then returns 6 ex 5: sum (integrate (x^i ,x), i, 0, 2) => x^3/3 + x^2/2 + x ex 6: sum (integrate (1/(x^i + 1), x), i, 0, 1) => log(x+1) + x/2 ex 7: f[i](x):=x^i$ g[i](x):=x^i$ h[i](x):=x^i$ /* reference f[i] and g[i]  see 740134 for the effect this has on previous defn of sum */ f[i]$ g[i](t)$ sum (f[i](x), i, 0, n) => 'sum (x^i, i, 0, n) sum (g[i](x), i, 0, n) => 'sum (x^i, i, 0, n) sum (h[i](x), i, 0, n) => 'sum (x^i, i, 0, n) ex 8: sum (integrate (x^i, x), i, 0, n) => 'sum (x^(i+1) / (i+1), i, 0, n)  Comment By: Barton Willis (willisbl) Date: 20050613 05: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 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 
From: SourceForge.net <noreply@so...>  20050621 06:03:20

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: 20050621 00:03 Message: Logged In: YES user_id=501686 Delete rtestsum.mac, going to upload a new one momentarily.  Comment By: Robert Dodier (robert_dodier) Date: 20050619 23:27 Message: Logged In: YES user_id=501686 About sum(rat(k),k,1,3), calling $FREEOF instead of FREEOF makes it happy again. Oh well. I think I'll just hang onto the current rev for a day or two to see what other changes accumulate, before posting a new version of tmpsum*.lisp. A related bit  sum(rat(k), k, 1, n) returns 'sum (k, k, 1, n), which isn't exactly wrong, but it does make me wonder what happened to the rat... it turns out this is what happened: subst (foo, k, rat(k)) => foo Not rat(foo) as I would have expected. Dunno what this is about.  Comment By: Barton Willis (willisbl) Date: 20050619 21:36 Message: Logged In: YES user_id=895922 Does tmpsum6.lisp need a ratdisrep somewhere? (%i1) load("c:/maxima/tmpsum6.lisp")$ (%i2) sum(k,k,1,3); (%o2) 6 (%i3) sum(rat(k),k,1,3); Maxima encountered a Lisp error: Error in COND [or a callee]: Caught fatal error [memory may be damaged] Automatically continuing. To reenable the Lisp debugger set *debuggerhook* to nil. (%i4) Barton  Comment By: Robert Dodier (robert_dodier) Date: 20050619 20:28 Message: Logged In: YES user_id=501686 Yet another revision (attached file tmpsum6.lisp) of DOSUM and friends. This version passes run_testsuite() and batch ("rtestsum.mac", test) using the currently attached version of rtestsum.mac. This version avoids substituting for the index in expressions which are free of the index. This version also has an alternate definition of the function FREE. The simplification code (and other code) calls FREE instead of FREEOF. FREEOF looks for dummy variables, but FREE does not, so with the original defn of FREE, sum (lambda([i], i^2), i, 1, n) does not simplify to n lambda ([i], i^2), i, 1, n). I'm not very happy about changing FREE since it is called from all over the place, but I'm also not very happy about the presence of FREE, either; why not call FREEOF ? I don't think changing FREE at this point is such a good idea; it seems to me the two choices are (1) inspect the sum/product simplification code and change FREE to FREEOF where possible. That would be a lot of work. (2) Leave FREE as it is, and just accept that expressions with dummy variables can't be factored out of summations. At this point I think I'd rather leave FREE alone, and file a separate bug report about the inability to factor out expressions with dummy variables, and just leave it for another day.  Comment By: Robert Dodier (robert_dodier) Date: 20050619 20:04 Message: Logged In: YES user_id=501686 New version of rtestsum.mac. Two new test cases, sum (lambda ([i], i^2, 1, 3) and sum (lambda ([i], i^2), i, 1, n).  Comment By: Robert Dodier (robert_dodier) Date: 20050619 19:59 Message: Logged In: YES user_id=501686 Removing rtestsum.mac, will upload a new version momentarily.  Comment By: Robert Dodier (robert_dodier) Date: 20050619 10:52 Message: Logged In: YES user_id=501686 I'm attaching my latest and greatest revision (tmpsum5.lisp) of DOSUM, DO%SUM, and MEVALSUMARGS. I find that load ("tmpsum5.lisp"); batch ("rtestsum.mac", test); where rtestsum.mac is the currently attached version, yields all tests passed for Maxima 5.9.1cvs built with clisp 2.33.2 and with gcl 2.6.6. This revision uses a gensym index for cases handled by MEVALSUMARGS (i.e., cases for which (upper limit) minus (lower limit) is not an integer); the gensym index is the argument for assume/forget. When upper minus lower is an integer, the index is bound to lower, lower+1, lower+2, etc., the summand is evaluated, and then lower, lower+1, lower+2, etc. is substituted for any remaining instances of index.  Comment By: Robert Dodier (robert_dodier) Date: 20050619 10:33 Message: Logged In: YES user_id=501686 Attaching a longer list of test cases. batch ("rtestsum.mac", test); executes the test. As always the "correct" results (2nd line in each pair) are subject to review.  Comment By: Robert Dodier (robert_dodier) Date: 20050619 10:28 Message: Logged In: YES user_id=501686 I'm removing rtestsum.mac, in anticipation of attaching a new version in a minute.  Comment By: van_Nek (van_nek) Date: 20050618 11:42 Message: Logged In: YES user_id=1269745 Dear Maximadevelopers, thank you for your support. I tried the last fix from Robert Dodier and it works. Volker van Nek original (anonymous) poster  Comment By: Robert Dodier (robert_dodier) Date: 20050615 08:37 Message: Logged In: YES user_id=501686 I'm attaching a list of test cases for sum, which can be executed by batch ("rtestsum.mac", test) . Doubtless there will be some discussion as to what the expected output of each test should be. All tests pass after making these 2 changes: ;; ORIGINAL: MEVAL ONCE ;; (mbinding (lind l*i) (meval exp)) ;; TRIED THIS: MEVAL TWICE ;; (mbinding (lind l*i) (meval (meval exp))) ;; THIRD TIME IS A CHARM ?? ($substitute *i ind (mbinding (lind l*i) (meval exp))) ;; ORIGINAL: MEVALATOMS ;; (resimplify (mevalatoms (if (and (not (atom exp)) (resimplify (meval (if (and (not (atom exp))  Comment By: Robert Dodier (robert_dodier) Date: 20050614 08:42 Message: Logged In: YES user_id=501686 OK, here is another attempt. I think I now understand this comment by Stavros in bug report # 740134  "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." ;; ORIGINAL: MEVAL ONCE ;; (mbinding (lind l*i) (meval exp)) ;; TRIED THIS: MEVAL TWICE ;; (mbinding (lind l*i) (meval (meval exp))) ;; THIRD TIME IS A CHARM ?? ($substitute *i ind (mbinding (lind l*i) (meval exp))) This version now yields this result  ex 9: f(x) := sum (x, i, 1, 3); f(x) => 3 x as expected, as well as the same results for ex 1 through ex 8.  Comment By: Robert Dodier (robert_dodier) Date: 20050613 23:00 Message: Logged In: YES user_id=501686 Actually, after looking at the code some more (specifically DOSUM in src/asum.lisp) it looks to me like the intent is indeed to evaluate the summand after binding the summation index to itself. In addition, there is code to assume the index is between its lower and upper limits (although assume/forget is handled incorrectly, see 851765). I believe that the observed behavior is a bug, in the narrow sense that the observed behavior is different from what the code author intended. See also my comments on SF bug # 740134. Here is a different patch. I like this one better than the previous one. In DOSUM: ;; ORIGINAL: MEVAL ONCE ;; (mbinding (lind l*i) (meval exp)) (mbinding (lind l*i) (meval (meval exp))) In MEVALSUMARG: ;; ORIGINAL: MEVALATOMS ;; (resimplify (mevalatoms (if (and (not (atom exp)) (resimplify (meval (if (and (not (atom exp)) With these changes, the results are as expected for the examples cited by the original poster, and also the example about the translated function produces the correct result, and some examples adapted from another bug report (740134) yield correct results. ex 1: f(x):=x^2$ b: 1/10$ Ak: b*f(k*b)$ sum(Ak,k,0,9); => 57/200 ex 2: A(k):=k*f(k*b)$ b:1/n$ A(k) => k^3/n^2 sum(A(k),k,0,n1) => ('sum(k^3,k,0,n1))/n^2 sum(A(k),k,0,n1), simpsum => ((n1)^4 + 2*(n1)^3 + (n1)^2) / (4*n^2) ex 3: ak : k^2$ g(a,n) := sum(a,k,1,n)$ g(ak,5) => 55 translate (g)$ g(ak,5) => 55 some other examples, adapted from bug # 740134: ex 4: sum (print (i), i, 1, 3) => prints 1, 2, 3 then returns 6 ex 5: sum (integrate (x^i ,x), i, 0, 2) => x^3/3 + x^2/2 + x ex 6: sum (integrate (1/(x^i + 1), x), i, 0, 1) => log(x+1) + x/2 ex 7: f[i](x):=x^i$ g[i](x):=x^i$ h[i](x):=x^i$ /* reference f[i] and g[i]  see 740134 for the effect this has on previous defn of sum */ f[i]$ g[i](t)$ sum (f[i](x), i, 0, n) => 'sum (x^i, i, 0, n) sum (g[i](x), i, 0, n) => 'sum (x^i, i, 0, n) sum (h[i](x), i, 0, n) => 'sum (x^i, i, 0, n) ex 8: sum (integrate (x^i, x), i, 0, n) => 'sum (x^(i+1) / (i+1), i, 0, n)  Comment By: Barton Willis (willisbl) Date: 20050613 05: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 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 
From: SourceForge.net <noreply@so...>  20050620 05:27:42

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: 20050619 23:27 Message: Logged In: YES user_id=501686 About sum(rat(k),k,1,3), calling $FREEOF instead of FREEOF makes it happy again. Oh well. I think I'll just hang onto the current rev for a day or two to see what other changes accumulate, before posting a new version of tmpsum*.lisp. A related bit  sum(rat(k), k, 1, n) returns 'sum (k, k, 1, n), which isn't exactly wrong, but it does make me wonder what happened to the rat... it turns out this is what happened: subst (foo, k, rat(k)) => foo Not rat(foo) as I would have expected. Dunno what this is about.  Comment By: Barton Willis (willisbl) Date: 20050619 21:36 Message: Logged In: YES user_id=895922 Does tmpsum6.lisp need a ratdisrep somewhere? (%i1) load("c:/maxima/tmpsum6.lisp")$ (%i2) sum(k,k,1,3); (%o2) 6 (%i3) sum(rat(k),k,1,3); Maxima encountered a Lisp error: Error in COND [or a callee]: Caught fatal error [memory may be damaged] Automatically continuing. To reenable the Lisp debugger set *debuggerhook* to nil. (%i4) Barton  Comment By: Robert Dodier (robert_dodier) Date: 20050619 20:28 Message: Logged In: YES user_id=501686 Yet another revision (attached file tmpsum6.lisp) of DOSUM and friends. This version passes run_testsuite() and batch ("rtestsum.mac", test) using the currently attached version of rtestsum.mac. This version avoids substituting for the index in expressions which are free of the index. This version also has an alternate definition of the function FREE. The simplification code (and other code) calls FREE instead of FREEOF. FREEOF looks for dummy variables, but FREE does not, so with the original defn of FREE, sum (lambda([i], i^2), i, 1, n) does not simplify to n lambda ([i], i^2), i, 1, n). I'm not very happy about changing FREE since it is called from all over the place, but I'm also not very happy about the presence of FREE, either; why not call FREEOF ? I don't think changing FREE at this point is such a good idea; it seems to me the two choices are (1) inspect the sum/product simplification code and change FREE to FREEOF where possible. That would be a lot of work. (2) Leave FREE as it is, and just accept that expressions with dummy variables can't be factored out of summations. At this point I think I'd rather leave FREE alone, and file a separate bug report about the inability to factor out expressions with dummy variables, and just leave it for another day.  Comment By: Robert Dodier (robert_dodier) Date: 20050619 20:04 Message: Logged In: YES user_id=501686 New version of rtestsum.mac. Two new test cases, sum (lambda ([i], i^2, 1, 3) and sum (lambda ([i], i^2), i, 1, n).  Comment By: Robert Dodier (robert_dodier) Date: 20050619 19:59 Message: Logged In: YES user_id=501686 Removing rtestsum.mac, will upload a new version momentarily.  Comment By: Robert Dodier (robert_dodier) Date: 20050619 10:52 Message: Logged In: YES user_id=501686 I'm attaching my latest and greatest revision (tmpsum5.lisp) of DOSUM, DO%SUM, and MEVALSUMARGS. I find that load ("tmpsum5.lisp"); batch ("rtestsum.mac", test); where rtestsum.mac is the currently attached version, yields all tests passed for Maxima 5.9.1cvs built with clisp 2.33.2 and with gcl 2.6.6. This revision uses a gensym index for cases handled by MEVALSUMARGS (i.e., cases for which (upper limit) minus (lower limit) is not an integer); the gensym index is the argument for assume/forget. When upper minus lower is an integer, the index is bound to lower, lower+1, lower+2, etc., the summand is evaluated, and then lower, lower+1, lower+2, etc. is substituted for any remaining instances of index.  Comment By: Robert Dodier (robert_dodier) Date: 20050619 10:33 Message: Logged In: YES user_id=501686 Attaching a longer list of test cases. batch ("rtestsum.mac", test); executes the test. As always the "correct" results (2nd line in each pair) are subject to review.  Comment By: Robert Dodier (robert_dodier) Date: 20050619 10:28 Message: Logged In: YES user_id=501686 I'm removing rtestsum.mac, in anticipation of attaching a new version in a minute.  Comment By: van_Nek (van_nek) Date: 20050618 11:42 Message: Logged In: YES user_id=1269745 Dear Maximadevelopers, thank you for your support. I tried the last fix from Robert Dodier and it works. Volker van Nek original (anonymous) poster  Comment By: Robert Dodier (robert_dodier) Date: 20050615 08:37 Message: Logged In: YES user_id=501686 I'm attaching a list of test cases for sum, which can be executed by batch ("rtestsum.mac", test) . Doubtless there will be some discussion as to what the expected output of each test should be. All tests pass after making these 2 changes: ;; ORIGINAL: MEVAL ONCE ;; (mbinding (lind l*i) (meval exp)) ;; TRIED THIS: MEVAL TWICE ;; (mbinding (lind l*i) (meval (meval exp))) ;; THIRD TIME IS A CHARM ?? ($substitute *i ind (mbinding (lind l*i) (meval exp))) ;; ORIGINAL: MEVALATOMS ;; (resimplify (mevalatoms (if (and (not (atom exp)) (resimplify (meval (if (and (not (atom exp))  Comment By: Robert Dodier (robert_dodier) Date: 20050614 08:42 Message: Logged In: YES user_id=501686 OK, here is another attempt. I think I now understand this comment by Stavros in bug report # 740134  "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." ;; ORIGINAL: MEVAL ONCE ;; (mbinding (lind l*i) (meval exp)) ;; TRIED THIS: MEVAL TWICE ;; (mbinding (lind l*i) (meval (meval exp))) ;; THIRD TIME IS A CHARM ?? ($substitute *i ind (mbinding (lind l*i) (meval exp))) This version now yields this result  ex 9: f(x) := sum (x, i, 1, 3); f(x) => 3 x as expected, as well as the same results for ex 1 through ex 8.  Comment By: Robert Dodier (robert_dodier) Date: 20050613 23:00 Message: Logged In: YES user_id=501686 Actually, after looking at the code some more (specifically DOSUM in src/asum.lisp) it looks to me like the intent is indeed to evaluate the summand after binding the summation index to itself. In addition, there is code to assume the index is between its lower and upper limits (although assume/forget is handled incorrectly, see 851765). I believe that the observed behavior is a bug, in the narrow sense that the observed behavior is different from what the code author intended. See also my comments on SF bug # 740134. Here is a different patch. I like this one better than the previous one. In DOSUM: ;; ORIGINAL: MEVAL ONCE ;; (mbinding (lind l*i) (meval exp)) (mbinding (lind l*i) (meval (meval exp))) In MEVALSUMARG: ;; ORIGINAL: MEVALATOMS ;; (resimplify (mevalatoms (if (and (not (atom exp)) (resimplify (meval (if (and (not (atom exp)) With these changes, the results are as expected for the examples cited by the original poster, and also the example about the translated function produces the correct result, and some examples adapted from another bug report (740134) yield correct results. ex 1: f(x):=x^2$ b: 1/10$ Ak: b*f(k*b)$ sum(Ak,k,0,9); => 57/200 ex 2: A(k):=k*f(k*b)$ b:1/n$ A(k) => k^3/n^2 sum(A(k),k,0,n1) => ('sum(k^3,k,0,n1))/n^2 sum(A(k),k,0,n1), simpsum => ((n1)^4 + 2*(n1)^3 + (n1)^2) / (4*n^2) ex 3: ak : k^2$ g(a,n) := sum(a,k,1,n)$ g(ak,5) => 55 translate (g)$ g(ak,5) => 55 some other examples, adapted from bug # 740134: ex 4: sum (print (i), i, 1, 3) => prints 1, 2, 3 then returns 6 ex 5: sum (integrate (x^i ,x), i, 0, 2) => x^3/3 + x^2/2 + x ex 6: sum (integrate (1/(x^i + 1), x), i, 0, 1) => log(x+1) + x/2 ex 7: f[i](x):=x^i$ g[i](x):=x^i$ h[i](x):=x^i$ /* reference f[i] and g[i]  see 740134 for the effect this has on previous defn of sum */ f[i]$ g[i](t)$ sum (f[i](x), i, 0, n) => 'sum (x^i, i, 0, n) sum (g[i](x), i, 0, n) => 'sum (x^i, i, 0, n) sum (h[i](x), i, 0, n) => 'sum (x^i, i, 0, n) ex 8: sum (integrate (x^i, x), i, 0, n) => 'sum (x^(i+1) / (i+1), i, 0, n)  Comment By: Barton Willis (willisbl) Date: 20050613 05: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 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 
From: SourceForge.net <noreply@so...>  20050620 03:36:23

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: 20050619 22:36 Message: Logged In: YES user_id=895922 Does tmpsum6.lisp need a ratdisrep somewhere? (%i1) load("c:/maxima/tmpsum6.lisp")$ (%i2) sum(k,k,1,3); (%o2) 6 (%i3) sum(rat(k),k,1,3); Maxima encountered a Lisp error: Error in COND [or a callee]: Caught fatal error [memory may be damaged] Automatically continuing. To reenable the Lisp debugger set *debuggerhook* to nil. (%i4) Barton  Comment By: Robert Dodier (robert_dodier) Date: 20050619 21:28 Message: Logged In: YES user_id=501686 Yet another revision (attached file tmpsum6.lisp) of DOSUM and friends. This version passes run_testsuite() and batch ("rtestsum.mac", test) using the currently attached version of rtestsum.mac. This version avoids substituting for the index in expressions which are free of the index. This version also has an alternate definition of the function FREE. The simplification code (and other code) calls FREE instead of FREEOF. FREEOF looks for dummy variables, but FREE does not, so with the original defn of FREE, sum (lambda([i], i^2), i, 1, n) does not simplify to n lambda ([i], i^2), i, 1, n). I'm not very happy about changing FREE since it is called from all over the place, but I'm also not very happy about the presence of FREE, either; why not call FREEOF ? I don't think changing FREE at this point is such a good idea; it seems to me the two choices are (1) inspect the sum/product simplification code and change FREE to FREEOF where possible. That would be a lot of work. (2) Leave FREE as it is, and just accept that expressions with dummy variables can't be factored out of summations. At this point I think I'd rather leave FREE alone, and file a separate bug report about the inability to factor out expressions with dummy variables, and just leave it for another day.  Comment By: Robert Dodier (robert_dodier) Date: 20050619 21:04 Message: Logged In: YES user_id=501686 New version of rtestsum.mac. Two new test cases, sum (lambda ([i], i^2, 1, 3) and sum (lambda ([i], i^2), i, 1, n).  Comment By: Robert Dodier (robert_dodier) Date: 20050619 20:59 Message: Logged In: YES user_id=501686 Removing rtestsum.mac, will upload a new version momentarily.  Comment By: Robert Dodier (robert_dodier) Date: 20050619 11:52 Message: Logged In: YES user_id=501686 I'm attaching my latest and greatest revision (tmpsum5.lisp) of DOSUM, DO%SUM, and MEVALSUMARGS. I find that load ("tmpsum5.lisp"); batch ("rtestsum.mac", test); where rtestsum.mac is the currently attached version, yields all tests passed for Maxima 5.9.1cvs built with clisp 2.33.2 and with gcl 2.6.6. This revision uses a gensym index for cases handled by MEVALSUMARGS (i.e., cases for which (upper limit) minus (lower limit) is not an integer); the gensym index is the argument for assume/forget. When upper minus lower is an integer, the index is bound to lower, lower+1, lower+2, etc., the summand is evaluated, and then lower, lower+1, lower+2, etc. is substituted for any remaining instances of index.  Comment By: Robert Dodier (robert_dodier) Date: 20050619 11:33 Message: Logged In: YES user_id=501686 Attaching a longer list of test cases. batch ("rtestsum.mac", test); executes the test. As always the "correct" results (2nd line in each pair) are subject to review.  Comment By: Robert Dodier (robert_dodier) Date: 20050619 11:28 Message: Logged In: YES user_id=501686 I'm removing rtestsum.mac, in anticipation of attaching a new version in a minute.  Comment By: van_Nek (van_nek) Date: 20050618 12:42 Message: Logged In: YES user_id=1269745 Dear Maximadevelopers, thank you for your support. I tried the last fix from Robert Dodier and it works. Volker van Nek original (anonymous) poster  Comment By: Robert Dodier (robert_dodier) Date: 20050615 09:37 Message: Logged In: YES user_id=501686 I'm attaching a list of test cases for sum, which can be executed by batch ("rtestsum.mac", test) . Doubtless there will be some discussion as to what the expected output of each test should be. All tests pass after making these 2 changes: ;; ORIGINAL: MEVAL ONCE ;; (mbinding (lind l*i) (meval exp)) ;; TRIED THIS: MEVAL TWICE ;; (mbinding (lind l*i) (meval (meval exp))) ;; THIRD TIME IS A CHARM ?? ($substitute *i ind (mbinding (lind l*i) (meval exp))) ;; ORIGINAL: MEVALATOMS ;; (resimplify (mevalatoms (if (and (not (atom exp)) (resimplify (meval (if (and (not (atom exp))  Comment By: Robert Dodier (robert_dodier) Date: 20050614 09:42 Message: Logged In: YES user_id=501686 OK, here is another attempt. I think I now understand this comment by Stavros in bug report # 740134  "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." ;; ORIGINAL: MEVAL ONCE ;; (mbinding (lind l*i) (meval exp)) ;; TRIED THIS: MEVAL TWICE ;; (mbinding (lind l*i) (meval (meval exp))) ;; THIRD TIME IS A CHARM ?? ($substitute *i ind (mbinding (lind l*i) (meval exp))) This version now yields this result  ex 9: f(x) := sum (x, i, 1, 3); f(x) => 3 x as expected, as well as the same results for ex 1 through ex 8.  Comment By: Robert Dodier (robert_dodier) Date: 20050614 00:00 Message: Logged In: YES user_id=501686 Actually, after looking at the code some more (specifically DOSUM in src/asum.lisp) it looks to me like the intent is indeed to evaluate the summand after binding the summation index to itself. In addition, there is code to assume the index is between its lower and upper limits (although assume/forget is handled incorrectly, see 851765). I believe that the observed behavior is a bug, in the narrow sense that the observed behavior is different from what the code author intended. See also my comments on SF bug # 740134. Here is a different patch. I like this one better than the previous one. In DOSUM: ;; ORIGINAL: MEVAL ONCE ;; (mbinding (lind l*i) (meval exp)) (mbinding (lind l*i) (meval (meval exp))) In MEVALSUMARG: ;; ORIGINAL: MEVALATOMS ;; (resimplify (mevalatoms (if (and (not (atom exp)) (resimplify (meval (if (and (not (atom exp)) With these changes, the results are as expected for the examples cited by the original poster, and also the example about the translated function produces the correct result, and some examples adapted from another bug report (740134) yield correct results. ex 1: f(x):=x^2$ b: 1/10$ Ak: b*f(k*b)$ sum(Ak,k,0,9); => 57/200 ex 2: A(k):=k*f(k*b)$ b:1/n$ A(k) => k^3/n^2 sum(A(k),k,0,n1) => ('sum(k^3,k,0,n1))/n^2 sum(A(k),k,0,n1), simpsum => ((n1)^4 + 2*(n1)^3 + (n1)^2) / (4*n^2) ex 3: ak : k^2$ g(a,n) := sum(a,k,1,n)$ g(ak,5) => 55 translate (g)$ g(ak,5) => 55 some other examples, adapted from bug # 740134: ex 4: sum (print (i), i, 1, 3) => prints 1, 2, 3 then returns 6 ex 5: sum (integrate (x^i ,x), i, 0, 2) => x^3/3 + x^2/2 + x ex 6: sum (integrate (1/(x^i + 1), x), i, 0, 1) => log(x+1) + x/2 ex 7: f[i](x):=x^i$ g[i](x):=x^i$ h[i](x):=x^i$ /* reference f[i] and g[i]  see 740134 for the effect this has on previous defn of sum */ f[i]$ g[i](t)$ sum (f[i](x), i, 0, n) => 'sum (x^i, i, 0, n) sum (g[i](x), i, 0, n) => 'sum (x^i, i, 0, n) sum (h[i](x), i, 0, n) => 'sum (x^i, i, 0, n) ex 8: sum (integrate (x^i, x), i, 0, n) => 'sum (x^(i+1) / (i+1), i, 0, n)  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...>  20050620 02:28:38

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: 20050619 20:28 Message: Logged In: YES user_id=501686 Yet another revision (attached file tmpsum6.lisp) of DOSUM and friends. This version passes run_testsuite() and batch ("rtestsum.mac", test) using the currently attached version of rtestsum.mac. This version avoids substituting for the index in expressions which are free of the index. This version also has an alternate definition of the function FREE. The simplification code (and other code) calls FREE instead of FREEOF. FREEOF looks for dummy variables, but FREE does not, so with the original defn of FREE, sum (lambda([i], i^2), i, 1, n) does not simplify to n lambda ([i], i^2), i, 1, n). I'm not very happy about changing FREE since it is called from all over the place, but I'm also not very happy about the presence of FREE, either; why not call FREEOF ? I don't think changing FREE at this point is such a good idea; it seems to me the two choices are (1) inspect the sum/product simplification code and change FREE to FREEOF where possible. That would be a lot of work. (2) Leave FREE as it is, and just accept that expressions with dummy variables can't be factored out of summations. At this point I think I'd rather leave FREE alone, and file a separate bug report about the inability to factor out expressions with dummy variables, and just leave it for another day.  Comment By: Robert Dodier (robert_dodier) Date: 20050619 20:04 Message: Logged In: YES user_id=501686 New version of rtestsum.mac. Two new test cases, sum (lambda ([i], i^2, 1, 3) and sum (lambda ([i], i^2), i, 1, n).  Comment By: Robert Dodier (robert_dodier) Date: 20050619 19:59 Message: Logged In: YES user_id=501686 Removing rtestsum.mac, will upload a new version momentarily.  Comment By: Robert Dodier (robert_dodier) Date: 20050619 10:52 Message: Logged In: YES user_id=501686 I'm attaching my latest and greatest revision (tmpsum5.lisp) of DOSUM, DO%SUM, and MEVALSUMARGS. I find that load ("tmpsum5.lisp"); batch ("rtestsum.mac", test); where rtestsum.mac is the currently attached version, yields all tests passed for Maxima 5.9.1cvs built with clisp 2.33.2 and with gcl 2.6.6. This revision uses a gensym index for cases handled by MEVALSUMARGS (i.e., cases for which (upper limit) minus (lower limit) is not an integer); the gensym index is the argument for assume/forget. When upper minus lower is an integer, the index is bound to lower, lower+1, lower+2, etc., the summand is evaluated, and then lower, lower+1, lower+2, etc. is substituted for any remaining instances of index.  Comment By: Robert Dodier (robert_dodier) Date: 20050619 10:33 Message: Logged In: YES user_id=501686 Attaching a longer list of test cases. batch ("rtestsum.mac", test); executes the test. As always the "correct" results (2nd line in each pair) are subject to review.  Comment By: Robert Dodier (robert_dodier) Date: 20050619 10:28 Message: Logged In: YES user_id=501686 I'm removing rtestsum.mac, in anticipation of attaching a new version in a minute.  Comment By: van_Nek (van_nek) Date: 20050618 11:42 Message: Logged In: YES user_id=1269745 Dear Maximadevelopers, thank you for your support. I tried the last fix from Robert Dodier and it works. Volker van Nek original (anonymous) poster  Comment By: Robert Dodier (robert_dodier) Date: 20050615 08:37 Message: Logged In: YES user_id=501686 I'm attaching a list of test cases for sum, which can be executed by batch ("rtestsum.mac", test) . Doubtless there will be some discussion as to what the expected output of each test should be. All tests pass after making these 2 changes: ;; ORIGINAL: MEVAL ONCE ;; (mbinding (lind l*i) (meval exp)) ;; TRIED THIS: MEVAL TWICE ;; (mbinding (lind l*i) (meval (meval exp))) ;; THIRD TIME IS A CHARM ?? ($substitute *i ind (mbinding (lind l*i) (meval exp))) ;; ORIGINAL: MEVALATOMS ;; (resimplify (mevalatoms (if (and (not (atom exp)) (resimplify (meval (if (and (not (atom exp))  Comment By: Robert Dodier (robert_dodier) Date: 20050614 08:42 Message: Logged In: YES user_id=501686 OK, here is another attempt. I think I now understand this comment by Stavros in bug report # 740134  "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." ;; ORIGINAL: MEVAL ONCE ;; (mbinding (lind l*i) (meval exp)) ;; TRIED THIS: MEVAL TWICE ;; (mbinding (lind l*i) (meval (meval exp))) ;; THIRD TIME IS A CHARM ?? ($substitute *i ind (mbinding (lind l*i) (meval exp))) This version now yields this result  ex 9: f(x) := sum (x, i, 1, 3); f(x) => 3 x as expected, as well as the same results for ex 1 through ex 8.  Comment By: Robert Dodier (robert_dodier) Date: 20050613 23:00 Message: Logged In: YES user_id=501686 Actually, after looking at the code some more (specifically DOSUM in src/asum.lisp) it looks to me like the intent is indeed to evaluate the summand after binding the summation index to itself. In addition, there is code to assume the index is between its lower and upper limits (although assume/forget is handled incorrectly, see 851765). I believe that the observed behavior is a bug, in the narrow sense that the observed behavior is different from what the code author intended. See also my comments on SF bug # 740134. Here is a different patch. I like this one better than the previous one. In DOSUM: ;; ORIGINAL: MEVAL ONCE ;; (mbinding (lind l*i) (meval exp)) (mbinding (lind l*i) (meval (meval exp))) In MEVALSUMARG: ;; ORIGINAL: MEVALATOMS ;; (resimplify (mevalatoms (if (and (not (atom exp)) (resimplify (meval (if (and (not (atom exp)) With these changes, the results are as expected for the examples cited by the original poster, and also the example about the translated function produces the correct result, and some examples adapted from another bug report (740134) yield correct results. ex 1: f(x):=x^2$ b: 1/10$ Ak: b*f(k*b)$ sum(Ak,k,0,9); => 57/200 ex 2: A(k):=k*f(k*b)$ b:1/n$ A(k) => k^3/n^2 sum(A(k),k,0,n1) => ('sum(k^3,k,0,n1))/n^2 sum(A(k),k,0,n1), simpsum => ((n1)^4 + 2*(n1)^3 + (n1)^2) / (4*n^2) ex 3: ak : k^2$ g(a,n) := sum(a,k,1,n)$ g(ak,5) => 55 translate (g)$ g(ak,5) => 55 some other examples, adapted from bug # 740134: ex 4: sum (print (i), i, 1, 3) => prints 1, 2, 3 then returns 6 ex 5: sum (integrate (x^i ,x), i, 0, 2) => x^3/3 + x^2/2 + x ex 6: sum (integrate (1/(x^i + 1), x), i, 0, 1) => log(x+1) + x/2 ex 7: f[i](x):=x^i$ g[i](x):=x^i$ h[i](x):=x^i$ /* reference f[i] and g[i]  see 740134 for the effect this has on previous defn of sum */ f[i]$ g[i](t)$ sum (f[i](x), i, 0, n) => 'sum (x^i, i, 0, n) sum (g[i](x), i, 0, n) => 'sum (x^i, i, 0, n) sum (h[i](x), i, 0, n) => 'sum (x^i, i, 0, n) ex 8: sum (integrate (x^i, x), i, 0, n) => 'sum (x^(i+1) / (i+1), i, 0, n)  Comment By: Barton Willis (willisbl) Date: 20050613 05: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 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 
From: SourceForge.net <noreply@so...>  20050620 02:15:10

Bugs item #1217122, was opened at 20050608 11:47 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1217122&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: Fix for 5.9.2 Status: Open Resolution: None Priority: 5 Submitted By: Vadim V. Zhytnikov (vvzhy) Assigned to: Nobody/Anonymous (nobody) Summary: missing endofline Initial Comment: Extra end of line is needed after timing (showtime:true) messages on GCL and after run_testsuite(); on clisp: [vadim@... maxima]$ ./maximalocal l gcl Maxima 5.9.1.1cvs http://maxima.sourceforge.net Using Lisp GNU Common Lisp (GCL) GCL 2.6.6 (aka GCL) 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) showtime:true; Evaluation took 0.00 seconds (0.00 elapsed)(%o1) true (%i2) x^2; Evaluation took 0.00 seconds (0.00 elapsed) 2 (%o2) x (%i3) quit(); [vadim@... maxima]$ ./maximalocal l clisp i i i i i i i ooooo o ooooooo ooooo ooooo I I I I I I I 8 8 8 8 8 o 8 8 I \ `+' / I 8 8 8 8 8 8 \ `+' / 8 8 8 ooooo 8oooo `____' 8 8 8 8 8  8 o 8 8 o 8 8 + ooooo 8oooooo ooo8ooo ooooo 8 Copyright (c) Bruno Haible, Michael Stoll 1992, 1993 Copyright (c) Bruno Haible, Marcus Daniels 19941997 Copyright (c) Bruno Haible, Pierpaolo Bernardi, Sam Steingold 1998 Copyright (c) Bruno Haible, Sam Steingold 19992003  Maxima 5.9.1.1cvs http://maxima.sourceforge.net Using Lisp CLISP 2.33.2 (20040602) 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) run_testsuite(); Running tests in rtestnset.mac: 477/477 tests passed. Running tests in rtest1.mac: 28/28 tests passed. Running tests in rtest1a.mac: 23/23 tests passed. Running tests in rtest2.mac: 47/47 tests passed. Running tests in rtest4.mac: 82/82 tests passed. Running tests in rtest5.mac: 51/51 tests passed. Running tests in rtest6.mac: 4/4 tests passed. Running tests in rtest6a.mac: 56/56 tests passed. Running tests in rtest6b.mac: 16/16 tests passed. Running tests in rtest7.mac: 41/41 tests passed. Running tests in rtest9.mac: 77/77 tests passed. Running tests in rtest9a.mac: 21/21 tests passed. Running tests in rtest10.mac: 38/38 tests passed. Running tests in rtest11.mac: 86/86 tests passed. Running tests in rtest13.mac: 24/24 tests passed. Running tests in rtest13s.mac: 18/18 tests passed. Running tests in rtest14.mac: 143/143 tests passed. Running tests in rtest15.mac: 131/131 tests passed. Running tests in rtest16.mac: 12/12 tests passed. Running tests in rtestode.mac: 64/64 tests passed. Running tests in rtestode_zp.mac: 30/30 tests passed. Running tests in rtest3.mac: 94/94 tests passed. Running tests in rtest8.mac: 50/50 tests passed. Running tests in rtest12.mac: 74/74 tests passed. Running tests in rexamples.mac: 136/136 tests passed. Running tests in rtesthyp.mac: 103/103 tests passed. Running tests in rtestmt19937.mac: 15/15 tests passed. No unexpected errors found. Real time: 12.063071 sec. Run time: 11.963182 sec. Space: 136145016 Bytes GC: 116, GC time: 1.011852 sec.(%o0) done (%i1)  >Comment By: Robert Dodier (robert_dodier) Date: 20050619 20:15 Message: Logged In: YES user_id=501686 I've observed that newlines get messed up very often when there is some output (via FORMAT or some other Lisp function) aside from the return value of a function. Error messages very often cause the newline to get messed up. Examples: (%i1) trace(foo); foo has no functional properties.(%o1) [] (%i5) :lisp (trace meval) (%i5) x^2; 1. Trace: (MEVAL '((MEXPT) $X 2)) 2. Trace: (MEVAL '$X) 2. Trace: MEVAL ==> $X 2. Trace: (MEVAL '2) 2. Trace: MEVAL ==> 2 1. Trace: MEVAL ==> ((MEXPT SIMP) $X 2) 2 (%o5) x Maxima 5.9.1cvs on clisp 2.33.2 (linux).  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1217122&group_id=4933 
From: SourceForge.net <noreply@so...>  20050620 02:04:50

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: 20050619 20:04 Message: Logged In: YES user_id=501686 New version of rtestsum.mac. Two new test cases, sum (lambda ([i], i^2, 1, 3) and sum (lambda ([i], i^2), i, 1, n).  Comment By: Robert Dodier (robert_dodier) Date: 20050619 19:59 Message: Logged In: YES user_id=501686 Removing rtestsum.mac, will upload a new version momentarily.  Comment By: Robert Dodier (robert_dodier) Date: 20050619 10:52 Message: Logged In: YES user_id=501686 I'm attaching my latest and greatest revision (tmpsum5.lisp) of DOSUM, DO%SUM, and MEVALSUMARGS. I find that load ("tmpsum5.lisp"); batch ("rtestsum.mac", test); where rtestsum.mac is the currently attached version, yields all tests passed for Maxima 5.9.1cvs built with clisp 2.33.2 and with gcl 2.6.6. This revision uses a gensym index for cases handled by MEVALSUMARGS (i.e., cases for which (upper limit) minus (lower limit) is not an integer); the gensym index is the argument for assume/forget. When upper minus lower is an integer, the index is bound to lower, lower+1, lower+2, etc., the summand is evaluated, and then lower, lower+1, lower+2, etc. is substituted for any remaining instances of index.  Comment By: Robert Dodier (robert_dodier) Date: 20050619 10:33 Message: Logged In: YES user_id=501686 Attaching a longer list of test cases. batch ("rtestsum.mac", test); executes the test. As always the "correct" results (2nd line in each pair) are subject to review.  Comment By: Robert Dodier (robert_dodier) Date: 20050619 10:28 Message: Logged In: YES user_id=501686 I'm removing rtestsum.mac, in anticipation of attaching a new version in a minute.  Comment By: van_Nek (van_nek) Date: 20050618 11:42 Message: Logged In: YES user_id=1269745 Dear Maximadevelopers, thank you for your support. I tried the last fix from Robert Dodier and it works. Volker van Nek original (anonymous) poster  Comment By: Robert Dodier (robert_dodier) Date: 20050615 08:37 Message: Logged In: YES user_id=501686 I'm attaching a list of test cases for sum, which can be executed by batch ("rtestsum.mac", test) . Doubtless there will be some discussion as to what the expected output of each test should be. All tests pass after making these 2 changes: ;; ORIGINAL: MEVAL ONCE ;; (mbinding (lind l*i) (meval exp)) ;; TRIED THIS: MEVAL TWICE ;; (mbinding (lind l*i) (meval (meval exp))) ;; THIRD TIME IS A CHARM ?? ($substitute *i ind (mbinding (lind l*i) (meval exp))) ;; ORIGINAL: MEVALATOMS ;; (resimplify (mevalatoms (if (and (not (atom exp)) (resimplify (meval (if (and (not (atom exp))  Comment By: Robert Dodier (robert_dodier) Date: 20050614 08:42 Message: Logged In: YES user_id=501686 OK, here is another attempt. I think I now understand this comment by Stavros in bug report # 740134  "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." ;; ORIGINAL: MEVAL ONCE ;; (mbinding (lind l*i) (meval exp)) ;; TRIED THIS: MEVAL TWICE ;; (mbinding (lind l*i) (meval (meval exp))) ;; THIRD TIME IS A CHARM ?? ($substitute *i ind (mbinding (lind l*i) (meval exp))) This version now yields this result  ex 9: f(x) := sum (x, i, 1, 3); f(x) => 3 x as expected, as well as the same results for ex 1 through ex 8.  Comment By: Robert Dodier (robert_dodier) Date: 20050613 23:00 Message: Logged In: YES user_id=501686 Actually, after looking at the code some more (specifically DOSUM in src/asum.lisp) it looks to me like the intent is indeed to evaluate the summand after binding the summation index to itself. In addition, there is code to assume the index is between its lower and upper limits (although assume/forget is handled incorrectly, see 851765). I believe that the observed behavior is a bug, in the narrow sense that the observed behavior is different from what the code author intended. See also my comments on SF bug # 740134. Here is a different patch. I like this one better than the previous one. In DOSUM: ;; ORIGINAL: MEVAL ONCE ;; (mbinding (lind l*i) (meval exp)) (mbinding (lind l*i) (meval (meval exp))) In MEVALSUMARG: ;; ORIGINAL: MEVALATOMS ;; (resimplify (mevalatoms (if (and (not (atom exp)) (resimplify (meval (if (and (not (atom exp)) With these changes, the results are as expected for the examples cited by the original poster, and also the example about the translated function produces the correct result, and some examples adapted from another bug report (740134) yield correct results. ex 1: f(x):=x^2$ b: 1/10$ Ak: b*f(k*b)$ sum(Ak,k,0,9); => 57/200 ex 2: A(k):=k*f(k*b)$ b:1/n$ A(k) => k^3/n^2 sum(A(k),k,0,n1) => ('sum(k^3,k,0,n1))/n^2 sum(A(k),k,0,n1), simpsum => ((n1)^4 + 2*(n1)^3 + (n1)^2) / (4*n^2) ex 3: ak : k^2$ g(a,n) := sum(a,k,1,n)$ g(ak,5) => 55 translate (g)$ g(ak,5) => 55 some other examples, adapted from bug # 740134: ex 4: sum (print (i), i, 1, 3) => prints 1, 2, 3 then returns 6 ex 5: sum (integrate (x^i ,x), i, 0, 2) => x^3/3 + x^2/2 + x ex 6: sum (integrate (1/(x^i + 1), x), i, 0, 1) => log(x+1) + x/2 ex 7: f[i](x):=x^i$ g[i](x):=x^i$ h[i](x):=x^i$ /* reference f[i] and g[i]  see 740134 for the effect this has on previous defn of sum */ f[i]$ g[i](t)$ sum (f[i](x), i, 0, n) => 'sum (x^i, i, 0, n) sum (g[i](x), i, 0, n) => 'sum (x^i, i, 0, n) sum (h[i](x), i, 0, n) => 'sum (x^i, i, 0, n) ex 8: sum (integrate (x^i, x), i, 0, n) => 'sum (x^(i+1) / (i+1), i, 0, n)  Comment By: Barton Willis (willisbl) Date: 20050613 05: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 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 
From: SourceForge.net <noreply@so...>  20050620 01:59:26

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: 20050619 19:59 Message: Logged In: YES user_id=501686 Removing rtestsum.mac, will upload a new version momentarily.  Comment By: Robert Dodier (robert_dodier) Date: 20050619 10:52 Message: Logged In: YES user_id=501686 I'm attaching my latest and greatest revision (tmpsum5.lisp) of DOSUM, DO%SUM, and MEVALSUMARGS. I find that load ("tmpsum5.lisp"); batch ("rtestsum.mac", test); where rtestsum.mac is the currently attached version, yields all tests passed for Maxima 5.9.1cvs built with clisp 2.33.2 and with gcl 2.6.6. This revision uses a gensym index for cases handled by MEVALSUMARGS (i.e., cases for which (upper limit) minus (lower limit) is not an integer); the gensym index is the argument for assume/forget. When upper minus lower is an integer, the index is bound to lower, lower+1, lower+2, etc., the summand is evaluated, and then lower, lower+1, lower+2, etc. is substituted for any remaining instances of index.  Comment By: Robert Dodier (robert_dodier) Date: 20050619 10:33 Message: Logged In: YES user_id=501686 Attaching a longer list of test cases. batch ("rtestsum.mac", test); executes the test. As always the "correct" results (2nd line in each pair) are subject to review.  Comment By: Robert Dodier (robert_dodier) Date: 20050619 10:28 Message: Logged In: YES user_id=501686 I'm removing rtestsum.mac, in anticipation of attaching a new version in a minute.  Comment By: van_Nek (van_nek) Date: 20050618 11:42 Message: Logged In: YES user_id=1269745 Dear Maximadevelopers, thank you for your support. I tried the last fix from Robert Dodier and it works. Volker van Nek original (anonymous) poster  Comment By: Robert Dodier (robert_dodier) Date: 20050615 08:37 Message: Logged In: YES user_id=501686 I'm attaching a list of test cases for sum, which can be executed by batch ("rtestsum.mac", test) . Doubtless there will be some discussion as to what the expected output of each test should be. All tests pass after making these 2 changes: ;; ORIGINAL: MEVAL ONCE ;; (mbinding (lind l*i) (meval exp)) ;; TRIED THIS: MEVAL TWICE ;; (mbinding (lind l*i) (meval (meval exp))) ;; THIRD TIME IS A CHARM ?? ($substitute *i ind (mbinding (lind l*i) (meval exp))) ;; ORIGINAL: MEVALATOMS ;; (resimplify (mevalatoms (if (and (not (atom exp)) (resimplify (meval (if (and (not (atom exp))  Comment By: Robert Dodier (robert_dodier) Date: 20050614 08:42 Message: Logged In: YES user_id=501686 OK, here is another attempt. I think I now understand this comment by Stavros in bug report # 740134  "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." ;; ORIGINAL: MEVAL ONCE ;; (mbinding (lind l*i) (meval exp)) ;; TRIED THIS: MEVAL TWICE ;; (mbinding (lind l*i) (meval (meval exp))) ;; THIRD TIME IS A CHARM ?? ($substitute *i ind (mbinding (lind l*i) (meval exp))) This version now yields this result  ex 9: f(x) := sum (x, i, 1, 3); f(x) => 3 x as expected, as well as the same results for ex 1 through ex 8.  Comment By: Robert Dodier (robert_dodier) Date: 20050613 23:00 Message: Logged In: YES user_id=501686 Actually, after looking at the code some more (specifically DOSUM in src/asum.lisp) it looks to me like the intent is indeed to evaluate the summand after binding the summation index to itself. In addition, there is code to assume the index is between its lower and upper limits (although assume/forget is handled incorrectly, see 851765). I believe that the observed behavior is a bug, in the narrow sense that the observed behavior is different from what the code author intended. See also my comments on SF bug # 740134. Here is a different patch. I like this one better than the previous one. In DOSUM: ;; ORIGINAL: MEVAL ONCE ;; (mbinding (lind l*i) (meval exp)) (mbinding (lind l*i) (meval (meval exp))) In MEVALSUMARG: ;; ORIGINAL: MEVALATOMS ;; (resimplify (mevalatoms (if (and (not (atom exp)) (resimplify (meval (if (and (not (atom exp)) With these changes, the results are as expected for the examples cited by the original poster, and also the example about the translated function produces the correct result, and some examples adapted from another bug report (740134) yield correct results. ex 1: f(x):=x^2$ b: 1/10$ Ak: b*f(k*b)$ sum(Ak,k,0,9); => 57/200 ex 2: A(k):=k*f(k*b)$ b:1/n$ A(k) => k^3/n^2 sum(A(k),k,0,n1) => ('sum(k^3,k,0,n1))/n^2 sum(A(k),k,0,n1), simpsum => ((n1)^4 + 2*(n1)^3 + (n1)^2) / (4*n^2) ex 3: ak : k^2$ g(a,n) := sum(a,k,1,n)$ g(ak,5) => 55 translate (g)$ g(ak,5) => 55 some other examples, adapted from bug # 740134: ex 4: sum (print (i), i, 1, 3) => prints 1, 2, 3 then returns 6 ex 5: sum (integrate (x^i ,x), i, 0, 2) => x^3/3 + x^2/2 + x ex 6: sum (integrate (1/(x^i + 1), x), i, 0, 1) => log(x+1) + x/2 ex 7: f[i](x):=x^i$ g[i](x):=x^i$ h[i](x):=x^i$ /* reference f[i] and g[i]  see 740134 for the effect this has on previous defn of sum */ f[i]$ g[i](t)$ sum (f[i](x), i, 0, n) => 'sum (x^i, i, 0, n) sum (g[i](x), i, 0, n) => 'sum (x^i, i, 0, n) sum (h[i](x), i, 0, n) => 'sum (x^i, i, 0, n) ex 8: sum (integrate (x^i, x), i, 0, n) => 'sum (x^(i+1) / (i+1), i, 0, n)  Comment By: Barton Willis (willisbl) Date: 20050613 05: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 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 
From: SourceForge.net <noreply@so...>  20050619 17:18:20

Bugs item #1216157, was opened at 20050606 22:22 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1216157&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 Submitted By: Robert Dodier (robert_dodier) Assigned to: Nobody/Anonymous (nobody) Summary: killoperator fails to entirely kill prefix, matchfix, nofix Initial Comment: killoperator in src/nparse.lisp doesn't completely kill prefix, matchfix, and nofix operators. These operators have a NUD (null left denotation) property, since there is nothing to the left of the operator. killoperator is invoked by kill("op") and remove ("op", op) (the two ways of removing operator properties). Infix, nary, and postfix operators are not affected. The solution is to remove the NUD property along with the other operator properties. Here is a 1line patch.  nparse.lisp 12 Apr 2005 16:46:15 0000 1.23 +++ nparse.lisp 7 Jun 2005 04:06:58 0000 @@ 1842,7 +1842,7 @@ (remprop opr 'opr) (rempropchk opr) (mapc #'(lambda (x) (remprop op x))  '(nudexpr nudsubr ; NUD info + '(nud nudexpr nudsubr ; NUD info led ledexpr ledsubr ; LED info lbp rbp ; Binding power info lpos rpos pos ; PartOfSpeech info After applying this patch, run_testsuite() succeeds with all tests passed. This specific test also succeeds: (%i1) prefix("op1"); infix("op2"); nary("op3"); postfix("op4"); matchfix("op5", "op5b"); nofix("op6"); (%o1) op1 (%o2) op2 (%o3) op3 (%o4) op4 (%o5) op5 (%o6) op6 (%i7) op1 aa; (%o7) op1 aa (%i8) aa op2 bb; (%o8) aa op2 bb (%i9) aa op3 bb op3 cc; (%o9) aa op3 bb op3 cc (%i10) aa op4; (%o10) aa op4 (%i11) op5 aa, bb op5b; (%o11) op5aa, bbop5b (%i12) "op6"() := 8888; (%o12) op6 := 8888 (%i13) op6; (%o13) 8888 (%i14) kill ("op1", "op2", "op3", "op4", "op5", "op6"); (%o14) done  OK, now that the operators are killed,  attempting to use them should fail: (%i15) op1 aa; Incorrect syntax: aa is not an infix operator op1 aa; ^ (%i15) aa op2 bb; Incorrect syntax: op2 is not an infix operator aa op2 ^ (%i15) aa op3 bb op3 cc; Incorrect syntax: op3 is not an infix operator aa op3 ^ (%i15) aa op4; Incorrect syntax: op4 is not an infix operator aa op4; ^ (%i15) op5 aa, bb op5b; Incorrect syntax: aa is not an infix operator op5 aa, ^ (%i15) op6; (%o15) op6  Contrast these with the outputs from  an unpatched system.  Prefix, matchfix, and nofix operators are  recognized as such even though killed: (%i14) kill ("op1", "op2", "op3", "op4", "op5", "op6"); (%o14) done (%i15) op1 aa; (%o15) op1(aa) < OOPS (%i16) aa op2 bb; Incorrect syntax: OP2 is not an infix operator aa op2 ^ (%i16) aa op3 bb op3 cc; Incorrect syntax: OP3 is not an infix operator aa op3 ^ (%i16) aa op4; Incorrect syntax: OP4 is not an infix operator aa op4; ^ (%i16) op5 aa, bb op5b; (%o16) op5(aa, bb) < OOPS (%i17) op6; (%o17) op6() < OOPS (%i18)  >Comment By: Robert Dodier (robert_dodier) Date: 20050619 11:18 Message: Logged In: YES user_id=501686 Patch shown in original comment committed to cvs as version 1.24 of src/nparse.lisp. Tested with Maxima 5.9.1cvs on clisp 2.33.2 and gcl 2.6.6 (both linux). Closing this bug report as fixed.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1216157&group_id=4933 
From: SourceForge.net <noreply@so...>  20050619 16:52:28

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: 20050619 10:52 Message: Logged In: YES user_id=501686 I'm attaching my latest and greatest revision (tmpsum5.lisp) of DOSUM, DO%SUM, and MEVALSUMARGS. I find that load ("tmpsum5.lisp"); batch ("rtestsum.mac", test); where rtestsum.mac is the currently attached version, yields all tests passed for Maxima 5.9.1cvs built with clisp 2.33.2 and with gcl 2.6.6. This revision uses a gensym index for cases handled by MEVALSUMARGS (i.e., cases for which (upper limit) minus (lower limit) is not an integer); the gensym index is the argument for assume/forget. When upper minus lower is an integer, the index is bound to lower, lower+1, lower+2, etc., the summand is evaluated, and then lower, lower+1, lower+2, etc. is substituted for any remaining instances of index.  Comment By: Robert Dodier (robert_dodier) Date: 20050619 10:33 Message: Logged In: YES user_id=501686 Attaching a longer list of test cases. batch ("rtestsum.mac", test); executes the test. As always the "correct" results (2nd line in each pair) are subject to review.  Comment By: Robert Dodier (robert_dodier) Date: 20050619 10:28 Message: Logged In: YES user_id=501686 I'm removing rtestsum.mac, in anticipation of attaching a new version in a minute.  Comment By: van_Nek (van_nek) Date: 20050618 11:42 Message: Logged In: YES user_id=1269745 Dear Maximadevelopers, thank you for your support. I tried the last fix from Robert Dodier and it works. Volker van Nek original (anonymous) poster  Comment By: Robert Dodier (robert_dodier) Date: 20050615 08:37 Message: Logged In: YES user_id=501686 I'm attaching a list of test cases for sum, which can be executed by batch ("rtestsum.mac", test) . Doubtless there will be some discussion as to what the expected output of each test should be. All tests pass after making these 2 changes: ;; ORIGINAL: MEVAL ONCE ;; (mbinding (lind l*i) (meval exp)) ;; TRIED THIS: MEVAL TWICE ;; (mbinding (lind l*i) (meval (meval exp))) ;; THIRD TIME IS A CHARM ?? ($substitute *i ind (mbinding (lind l*i) (meval exp))) ;; ORIGINAL: MEVALATOMS ;; (resimplify (mevalatoms (if (and (not (atom exp)) (resimplify (meval (if (and (not (atom exp))  Comment By: Robert Dodier (robert_dodier) Date: 20050614 08:42 Message: Logged In: YES user_id=501686 OK, here is another attempt. I think I now understand this comment by Stavros in bug report # 740134  "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." ;; ORIGINAL: MEVAL ONCE ;; (mbinding (lind l*i) (meval exp)) ;; TRIED THIS: MEVAL TWICE ;; (mbinding (lind l*i) (meval (meval exp))) ;; THIRD TIME IS A CHARM ?? ($substitute *i ind (mbinding (lind l*i) (meval exp))) This version now yields this result  ex 9: f(x) := sum (x, i, 1, 3); f(x) => 3 x as expected, as well as the same results for ex 1 through ex 8.  Comment By: Robert Dodier (robert_dodier) Date: 20050613 23:00 Message: Logged In: YES user_id=501686 Actually, after looking at the code some more (specifically DOSUM in src/asum.lisp) it looks to me like the intent is indeed to evaluate the summand after binding the summation index to itself. In addition, there is code to assume the index is between its lower and upper limits (although assume/forget is handled incorrectly, see 851765). I believe that the observed behavior is a bug, in the narrow sense that the observed behavior is different from what the code author intended. See also my comments on SF bug # 740134. Here is a different patch. I like this one better than the previous one. In DOSUM: ;; ORIGINAL: MEVAL ONCE ;; (mbinding (lind l*i) (meval exp)) (mbinding (lind l*i) (meval (meval exp))) In MEVALSUMARG: ;; ORIGINAL: MEVALATOMS ;; (resimplify (mevalatoms (if (and (not (atom exp)) (resimplify (meval (if (and (not (atom exp)) With these changes, the results are as expected for the examples cited by the original poster, and also the example about the translated function produces the correct result, and some examples adapted from another bug report (740134) yield correct results. ex 1: f(x):=x^2$ b: 1/10$ Ak: b*f(k*b)$ sum(Ak,k,0,9); => 57/200 ex 2: A(k):=k*f(k*b)$ b:1/n$ A(k) => k^3/n^2 sum(A(k),k,0,n1) => ('sum(k^3,k,0,n1))/n^2 sum(A(k),k,0,n1), simpsum => ((n1)^4 + 2*(n1)^3 + (n1)^2) / (4*n^2) ex 3: ak : k^2$ g(a,n) := sum(a,k,1,n)$ g(ak,5) => 55 translate (g)$ g(ak,5) => 55 some other examples, adapted from bug # 740134: ex 4: sum (print (i), i, 1, 3) => prints 1, 2, 3 then returns 6 ex 5: sum (integrate (x^i ,x), i, 0, 2) => x^3/3 + x^2/2 + x ex 6: sum (integrate (1/(x^i + 1), x), i, 0, 1) => log(x+1) + x/2 ex 7: f[i](x):=x^i$ g[i](x):=x^i$ h[i](x):=x^i$ /* reference f[i] and g[i]  see 740134 for the effect this has on previous defn of sum */ f[i]$ g[i](t)$ sum (f[i](x), i, 0, n) => 'sum (x^i, i, 0, n) sum (g[i](x), i, 0, n) => 'sum (x^i, i, 0, n) sum (h[i](x), i, 0, n) => 'sum (x^i, i, 0, n) ex 8: sum (integrate (x^i, x), i, 0, n) => 'sum (x^(i+1) / (i+1), i, 0, n)  Comment By: Barton Willis (willisbl) Date: 20050613 05: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 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 
From: SourceForge.net <noreply@so...>  20050619 16:33:41

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: 20050619 10:33 Message: Logged In: YES user_id=501686 Attaching a longer list of test cases. batch ("rtestsum.mac", test); executes the test. As always the "correct" results (2nd line in each pair) are subject to review.  Comment By: Robert Dodier (robert_dodier) Date: 20050619 10:28 Message: Logged In: YES user_id=501686 I'm removing rtestsum.mac, in anticipation of attaching a new version in a minute.  Comment By: van_Nek (van_nek) Date: 20050618 11:42 Message: Logged In: YES user_id=1269745 Dear Maximadevelopers, thank you for your support. I tried the last fix from Robert Dodier and it works. Volker van Nek original (anonymous) poster  Comment By: Robert Dodier (robert_dodier) Date: 20050615 08:37 Message: Logged In: YES user_id=501686 I'm attaching a list of test cases for sum, which can be executed by batch ("rtestsum.mac", test) . Doubtless there will be some discussion as to what the expected output of each test should be. All tests pass after making these 2 changes: ;; ORIGINAL: MEVAL ONCE ;; (mbinding (lind l*i) (meval exp)) ;; TRIED THIS: MEVAL TWICE ;; (mbinding (lind l*i) (meval (meval exp))) ;; THIRD TIME IS A CHARM ?? ($substitute *i ind (mbinding (lind l*i) (meval exp))) ;; ORIGINAL: MEVALATOMS ;; (resimplify (mevalatoms (if (and (not (atom exp)) (resimplify (meval (if (and (not (atom exp))  Comment By: Robert Dodier (robert_dodier) Date: 20050614 08:42 Message: Logged In: YES user_id=501686 OK, here is another attempt. I think I now understand this comment by Stavros in bug report # 740134  "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." ;; ORIGINAL: MEVAL ONCE ;; (mbinding (lind l*i) (meval exp)) ;; TRIED THIS: MEVAL TWICE ;; (mbinding (lind l*i) (meval (meval exp))) ;; THIRD TIME IS A CHARM ?? ($substitute *i ind (mbinding (lind l*i) (meval exp))) This version now yields this result  ex 9: f(x) := sum (x, i, 1, 3); f(x) => 3 x as expected, as well as the same results for ex 1 through ex 8.  Comment By: Robert Dodier (robert_dodier) Date: 20050613 23:00 Message: Logged In: YES user_id=501686 Actually, after looking at the code some more (specifically DOSUM in src/asum.lisp) it looks to me like the intent is indeed to evaluate the summand after binding the summation index to itself. In addition, there is code to assume the index is between its lower and upper limits (although assume/forget is handled incorrectly, see 851765). I believe that the observed behavior is a bug, in the narrow sense that the observed behavior is different from what the code author intended. See also my comments on SF bug # 740134. Here is a different patch. I like this one better than the previous one. In DOSUM: ;; ORIGINAL: MEVAL ONCE ;; (mbinding (lind l*i) (meval exp)) (mbinding (lind l*i) (meval (meval exp))) In MEVALSUMARG: ;; ORIGINAL: MEVALATOMS ;; (resimplify (mevalatoms (if (and (not (atom exp)) (resimplify (meval (if (and (not (atom exp)) With these changes, the results are as expected for the examples cited by the original poster, and also the example about the translated function produces the correct result, and some examples adapted from another bug report (740134) yield correct results. ex 1: f(x):=x^2$ b: 1/10$ Ak: b*f(k*b)$ sum(Ak,k,0,9); => 57/200 ex 2: A(k):=k*f(k*b)$ b:1/n$ A(k) => k^3/n^2 sum(A(k),k,0,n1) => ('sum(k^3,k,0,n1))/n^2 sum(A(k),k,0,n1), simpsum => ((n1)^4 + 2*(n1)^3 + (n1)^2) / (4*n^2) ex 3: ak : k^2$ g(a,n) := sum(a,k,1,n)$ g(ak,5) => 55 translate (g)$ g(ak,5) => 55 some other examples, adapted from bug # 740134: ex 4: sum (print (i), i, 1, 3) => prints 1, 2, 3 then returns 6 ex 5: sum (integrate (x^i ,x), i, 0, 2) => x^3/3 + x^2/2 + x ex 6: sum (integrate (1/(x^i + 1), x), i, 0, 1) => log(x+1) + x/2 ex 7: f[i](x):=x^i$ g[i](x):=x^i$ h[i](x):=x^i$ /* reference f[i] and g[i]  see 740134 for the effect this has on previous defn of sum */ f[i]$ g[i](t)$ sum (f[i](x), i, 0, n) => 'sum (x^i, i, 0, n) sum (g[i](x), i, 0, n) => 'sum (x^i, i, 0, n) sum (h[i](x), i, 0, n) => 'sum (x^i, i, 0, n) ex 8: sum (integrate (x^i, x), i, 0, n) => 'sum (x^(i+1) / (i+1), i, 0, n)  Comment By: Barton Willis (willisbl) Date: 20050613 05: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 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 
From: SourceForge.net <noreply@so...>  20050619 16:29:05

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: 20050619 10:28 Message: Logged In: YES user_id=501686 I'm removing rtestsum.mac, in anticipation of attaching a new version in a minute.  Comment By: van_Nek (van_nek) Date: 20050618 11:42 Message: Logged In: YES user_id=1269745 Dear Maximadevelopers, thank you for your support. I tried the last fix from Robert Dodier and it works. Volker van Nek original (anonymous) poster  Comment By: Robert Dodier (robert_dodier) Date: 20050615 08:37 Message: Logged In: YES user_id=501686 I'm attaching a list of test cases for sum, which can be executed by batch ("rtestsum.mac", test) . Doubtless there will be some discussion as to what the expected output of each test should be. All tests pass after making these 2 changes: ;; ORIGINAL: MEVAL ONCE ;; (mbinding (lind l*i) (meval exp)) ;; TRIED THIS: MEVAL TWICE ;; (mbinding (lind l*i) (meval (meval exp))) ;; THIRD TIME IS A CHARM ?? ($substitute *i ind (mbinding (lind l*i) (meval exp))) ;; ORIGINAL: MEVALATOMS ;; (resimplify (mevalatoms (if (and (not (atom exp)) (resimplify (meval (if (and (not (atom exp))  Comment By: Robert Dodier (robert_dodier) Date: 20050614 08:42 Message: Logged In: YES user_id=501686 OK, here is another attempt. I think I now understand this comment by Stavros in bug report # 740134  "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." ;; ORIGINAL: MEVAL ONCE ;; (mbinding (lind l*i) (meval exp)) ;; TRIED THIS: MEVAL TWICE ;; (mbinding (lind l*i) (meval (meval exp))) ;; THIRD TIME IS A CHARM ?? ($substitute *i ind (mbinding (lind l*i) (meval exp))) This version now yields this result  ex 9: f(x) := sum (x, i, 1, 3); f(x) => 3 x as expected, as well as the same results for ex 1 through ex 8.  Comment By: Robert Dodier (robert_dodier) Date: 20050613 23:00 Message: Logged In: YES user_id=501686 Actually, after looking at the code some more (specifically DOSUM in src/asum.lisp) it looks to me like the intent is indeed to evaluate the summand after binding the summation index to itself. In addition, there is code to assume the index is between its lower and upper limits (although assume/forget is handled incorrectly, see 851765). I believe that the observed behavior is a bug, in the narrow sense that the observed behavior is different from what the code author intended. See also my comments on SF bug # 740134. Here is a different patch. I like this one better than the previous one. In DOSUM: ;; ORIGINAL: MEVAL ONCE ;; (mbinding (lind l*i) (meval exp)) (mbinding (lind l*i) (meval (meval exp))) In MEVALSUMARG: ;; ORIGINAL: MEVALATOMS ;; (resimplify (mevalatoms (if (and (not (atom exp)) (resimplify (meval (if (and (not (atom exp)) With these changes, the results are as expected for the examples cited by the original poster, and also the example about the translated function produces the correct result, and some examples adapted from another bug report (740134) yield correct results. ex 1: f(x):=x^2$ b: 1/10$ Ak: b*f(k*b)$ sum(Ak,k,0,9); => 57/200 ex 2: A(k):=k*f(k*b)$ b:1/n$ A(k) => k^3/n^2 sum(A(k),k,0,n1) => ('sum(k^3,k,0,n1))/n^2 sum(A(k),k,0,n1), simpsum => ((n1)^4 + 2*(n1)^3 + (n1)^2) / (4*n^2) ex 3: ak : k^2$ g(a,n) := sum(a,k,1,n)$ g(ak,5) => 55 translate (g)$ g(ak,5) => 55 some other examples, adapted from bug # 740134: ex 4: sum (print (i), i, 1, 3) => prints 1, 2, 3 then returns 6 ex 5: sum (integrate (x^i ,x), i, 0, 2) => x^3/3 + x^2/2 + x ex 6: sum (integrate (1/(x^i + 1), x), i, 0, 1) => log(x+1) + x/2 ex 7: f[i](x):=x^i$ g[i](x):=x^i$ h[i](x):=x^i$ /* reference f[i] and g[i]  see 740134 for the effect this has on previous defn of sum */ f[i]$ g[i](t)$ sum (f[i](x), i, 0, n) => 'sum (x^i, i, 0, n) sum (g[i](x), i, 0, n) => 'sum (x^i, i, 0, n) sum (h[i](x), i, 0, n) => 'sum (x^i, i, 0, n) ex 8: sum (integrate (x^i, x), i, 0, n) => 'sum (x^(i+1) / (i+1), i, 0, n)  Comment By: Barton Willis (willisbl) Date: 20050613 05: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 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 
From: SourceForge.net <noreply@so...>  20050619 02:24:55

Bugs item #1222927, was opened at 20050617 15:54 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1222927&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: Fix for 5.9.2 Status: Open Resolution: None Priority: 5 Submitted By: van_Nek (van_nek) Assigned to: Nobody/Anonymous (nobody) Summary: scope for a variable in buildq? Initial Comment: (%i1) printlist(list)::=buildq([temp:ev(list)],print(splice(temp)))$ (%i2) list:[1,2,3]$ (%i3) printlist(list); SPLICE(TEMP) returned LIST But SPLICE must return a list #0: printlist(list=LIST)  an error. Quitting. To debug this try DEBUGMODE(TRUE); (%i4) ref:list$ (%i5) printlist(ref); 1 2 3 (%o5) 3 this is confusing! (%i12) f(x):=x**2$ (%i13) x:3$ (%i14) f(x); (%o14) 9 that works! Am I not allowed to use any name for a variable in buildq? van_Nek van.Nek@...  >Comment By: Robert Dodier (robert_dodier) Date: 20050618 20:24 Message: Logged In: YES user_id=501686 The problem is that before expanding printlist, the formal argument list is bound to the actual argument, also named list. Given that, ev (list) => list (not the actual [1, 2, 3]) and then splice complains. Same complaint if the formal and actual arguments have the same name (something other than "list"), e.g., FOO. This is strange, although I'm not sure if it can be considered a bug, as it is a straightforward consequence of the general rules for binding and evaluation. In any event, maybe apply (print, list) has the effect you want? How about: printlist (list) := apply (print, list); list: [1,2,3]; printlist (list); 1 2 3 3  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1222927&group_id=4933 
From: SourceForge.net <noreply@so...>  20050618 17:42:45

Bugs item #1192935, was opened at 20050430 13:10 Message generated for change (Comment added) made by van_nek 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: van_Nek (van_nek) Date: 20050618 19:42 Message: Logged In: YES user_id=1269745 Dear Maximadevelopers, thank you for your support. I tried the last fix from Robert Dodier and it works. Volker van Nek original (anonymous) poster  Comment By: Robert Dodier (robert_dodier) Date: 20050615 16:37 Message: Logged In: YES user_id=501686 I'm attaching a list of test cases for sum, which can be executed by batch ("rtestsum.mac", test) . Doubtless there will be some discussion as to what the expected output of each test should be. All tests pass after making these 2 changes: ;; ORIGINAL: MEVAL ONCE ;; (mbinding (lind l*i) (meval exp)) ;; TRIED THIS: MEVAL TWICE ;; (mbinding (lind l*i) (meval (meval exp))) ;; THIRD TIME IS A CHARM ?? ($substitute *i ind (mbinding (lind l*i) (meval exp))) ;; ORIGINAL: MEVALATOMS ;; (resimplify (mevalatoms (if (and (not (atom exp)) (resimplify (meval (if (and (not (atom exp))  Comment By: Robert Dodier (robert_dodier) Date: 20050614 16:42 Message: Logged In: YES user_id=501686 OK, here is another attempt. I think I now understand this comment by Stavros in bug report # 740134  "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." ;; ORIGINAL: MEVAL ONCE ;; (mbinding (lind l*i) (meval exp)) ;; TRIED THIS: MEVAL TWICE ;; (mbinding (lind l*i) (meval (meval exp))) ;; THIRD TIME IS A CHARM ?? ($substitute *i ind (mbinding (lind l*i) (meval exp))) This version now yields this result  ex 9: f(x) := sum (x, i, 1, 3); f(x) => 3 x as expected, as well as the same results for ex 1 through ex 8.  Comment By: Robert Dodier (robert_dodier) Date: 20050614 07:00 Message: Logged In: YES user_id=501686 Actually, after looking at the code some more (specifically DOSUM in src/asum.lisp) it looks to me like the intent is indeed to evaluate the summand after binding the summation index to itself. In addition, there is code to assume the index is between its lower and upper limits (although assume/forget is handled incorrectly, see 851765). I believe that the observed behavior is a bug, in the narrow sense that the observed behavior is different from what the code author intended. See also my comments on SF bug # 740134. Here is a different patch. I like this one better than the previous one. In DOSUM: ;; ORIGINAL: MEVAL ONCE ;; (mbinding (lind l*i) (meval exp)) (mbinding (lind l*i) (meval (meval exp))) In MEVALSUMARG: ;; ORIGINAL: MEVALATOMS ;; (resimplify (mevalatoms (if (and (not (atom exp)) (resimplify (meval (if (and (not (atom exp)) With these changes, the results are as expected for the examples cited by the original poster, and also the example about the translated function produces the correct result, and some examples adapted from another bug report (740134) yield correct results. ex 1: f(x):=x^2$ b: 1/10$ Ak: b*f(k*b)$ sum(Ak,k,0,9); => 57/200 ex 2: A(k):=k*f(k*b)$ b:1/n$ A(k) => k^3/n^2 sum(A(k),k,0,n1) => ('sum(k^3,k,0,n1))/n^2 sum(A(k),k,0,n1), simpsum => ((n1)^4 + 2*(n1)^3 + (n1)^2) / (4*n^2) ex 3: ak : k^2$ g(a,n) := sum(a,k,1,n)$ g(ak,5) => 55 translate (g)$ g(ak,5) => 55 some other examples, adapted from bug # 740134: ex 4: sum (print (i), i, 1, 3) => prints 1, 2, 3 then returns 6 ex 5: sum (integrate (x^i ,x), i, 0, 2) => x^3/3 + x^2/2 + x ex 6: sum (integrate (1/(x^i + 1), x), i, 0, 1) => log(x+1) + x/2 ex 7: f[i](x):=x^i$ g[i](x):=x^i$ h[i](x):=x^i$ /* reference f[i] and g[i]  see 740134 for the effect this has on previous defn of sum */ f[i]$ g[i](t)$ sum (f[i](x), i, 0, n) => 'sum (x^i, i, 0, n) sum (g[i](x), i, 0, n) => 'sum (x^i, i, 0, n) sum (h[i](x), i, 0, n) => 'sum (x^i, i, 0, n) ex 8: sum (integrate (x^i, x), i, 0, n) => 'sum (x^(i+1) / (i+1), i, 0, n)  Comment By: Barton Willis (willisbl) Date: 20050613 13: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: 20050613 04: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 14: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...>  20050617 21:54:02

Bugs item #1222927, was opened at 20050617 23:54 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=1222927&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: Fix for 5.9.2 Status: Open Resolution: None Priority: 5 Submitted By: van_Nek (van_nek) Assigned to: Nobody/Anonymous (nobody) Summary: scope for a variable in buildq? Initial Comment: (%i1) printlist(list)::=buildq([temp:ev(list)],print(splice(temp)))$ (%i2) list:[1,2,3]$ (%i3) printlist(list); SPLICE(TEMP) returned LIST But SPLICE must return a list #0: printlist(list=LIST)  an error. Quitting. To debug this try DEBUGMODE(TRUE); (%i4) ref:list$ (%i5) printlist(ref); 1 2 3 (%o5) 3 this is confusing! (%i12) f(x):=x**2$ (%i13) x:3$ (%i14) f(x); (%o14) 9 that works! Am I not allowed to use any name for a variable in buildq? van_Nek van.Nek@...  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1222927&group_id=4933 
From: SourceForge.net <noreply@so...>  20050615 14:37:16

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: 20050615 08:37 Message: Logged In: YES user_id=501686 I'm attaching a list of test cases for sum, which can be executed by batch ("rtestsum.mac", test) . Doubtless there will be some discussion as to what the expected output of each test should be. All tests pass after making these 2 changes: ;; ORIGINAL: MEVAL ONCE ;; (mbinding (lind l*i) (meval exp)) ;; TRIED THIS: MEVAL TWICE ;; (mbinding (lind l*i) (meval (meval exp))) ;; THIRD TIME IS A CHARM ?? ($substitute *i ind (mbinding (lind l*i) (meval exp))) ;; ORIGINAL: MEVALATOMS ;; (resimplify (mevalatoms (if (and (not (atom exp)) (resimplify (meval (if (and (not (atom exp))  Comment By: Robert Dodier (robert_dodier) Date: 20050614 08:42 Message: Logged In: YES user_id=501686 OK, here is another attempt. I think I now understand this comment by Stavros in bug report # 740134  "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." ;; ORIGINAL: MEVAL ONCE ;; (mbinding (lind l*i) (meval exp)) ;; TRIED THIS: MEVAL TWICE ;; (mbinding (lind l*i) (meval (meval exp))) ;; THIRD TIME IS A CHARM ?? ($substitute *i ind (mbinding (lind l*i) (meval exp))) This version now yields this result  ex 9: f(x) := sum (x, i, 1, 3); f(x) => 3 x as expected, as well as the same results for ex 1 through ex 8.  Comment By: Robert Dodier (robert_dodier) Date: 20050613 23:00 Message: Logged In: YES user_id=501686 Actually, after looking at the code some more (specifically DOSUM in src/asum.lisp) it looks to me like the intent is indeed to evaluate the summand after binding the summation index to itself. In addition, there is code to assume the index is between its lower and upper limits (although assume/forget is handled incorrectly, see 851765). I believe that the observed behavior is a bug, in the narrow sense that the observed behavior is different from what the code author intended. See also my comments on SF bug # 740134. Here is a different patch. I like this one better than the previous one. In DOSUM: ;; ORIGINAL: MEVAL ONCE ;; (mbinding (lind l*i) (meval exp)) (mbinding (lind l*i) (meval (meval exp))) In MEVALSUMARG: ;; ORIGINAL: MEVALATOMS ;; (resimplify (mevalatoms (if (and (not (atom exp)) (resimplify (meval (if (and (not (atom exp)) With these changes, the results are as expected for the examples cited by the original poster, and also the example about the translated function produces the correct result, and some examples adapted from another bug report (740134) yield correct results. ex 1: f(x):=x^2$ b: 1/10$ Ak: b*f(k*b)$ sum(Ak,k,0,9); => 57/200 ex 2: A(k):=k*f(k*b)$ b:1/n$ A(k) => k^3/n^2 sum(A(k),k,0,n1) => ('sum(k^3,k,0,n1))/n^2 sum(A(k),k,0,n1), simpsum => ((n1)^4 + 2*(n1)^3 + (n1)^2) / (4*n^2) ex 3: ak : k^2$ g(a,n) := sum(a,k,1,n)$ g(ak,5) => 55 translate (g)$ g(ak,5) => 55 some other examples, adapted from bug # 740134: ex 4: sum (print (i), i, 1, 3) => prints 1, 2, 3 then returns 6 ex 5: sum (integrate (x^i ,x), i, 0, 2) => x^3/3 + x^2/2 + x ex 6: sum (integrate (1/(x^i + 1), x), i, 0, 1) => log(x+1) + x/2 ex 7: f[i](x):=x^i$ g[i](x):=x^i$ h[i](x):=x^i$ /* reference f[i] and g[i]  see 740134 for the effect this has on previous defn of sum */ f[i]$ g[i](t)$ sum (f[i](x), i, 0, n) => 'sum (x^i, i, 0, n) sum (g[i](x), i, 0, n) => 'sum (x^i, i, 0, n) sum (h[i](x), i, 0, n) => 'sum (x^i, i, 0, n) ex 8: sum (integrate (x^i, x), i, 0, n) => 'sum (x^(i+1) / (i+1), i, 0, n)  Comment By: Barton Willis (willisbl) Date: 20050613 05: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 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 
From: SourceForge.net <noreply@so...>  20050615 07:18:06

Bugs item #1220979, was opened at 20050615 00:18 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=1220979&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 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Taylor Initial Comment: M : MATRIX([a,b],[b,c]); L : eigenvalues(M) Tc : taylor(L[1][1],c,0,2); Ta : taylor(L[1][1],a,0,2); But "a" and "c" is simmetric. it work for Tc, but don't work for Ta.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1220979&group_id=4933 