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}
(87) 
_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 



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

5
(1) 
6
(1) 
7
(2) 
8
(1) 
9
(5) 
10

11

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

18

19
(1) 
20

21
(1) 
22
(2) 
23

24
(16) 
25
(3) 
26

27

28

29
(3) 
30
(12) 



From: SourceForge.net <noreply@so...>  20051130 22:38:24

Bugs item #1370433, was opened at 20051130 14:38 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=1370433&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: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: trigsimp(sqrt(%i2)) != sqrt(trigsimp(%i2)) Initial Comment:  Maxima version: 5.9.2 Maxima build date: 9:5 10/12/2005 host type: i686pcmingw32 lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.7  ################################################## # Start problem with sqrt and trigsimp: # # # # (%i2) 2*(cos(x)^2sin(x)^2)+2; # # 2 2 # # (%o2) 2 (cos (x)  sin (x)) + 2 # # (%i3) trigsimp(sqrt(%i2)); # # (%o3)  2 abs(cos(x)) # # (%i4) sqrt(trigsimp(%i2)); # # (%o4) 2 abs(cos(x)) # # # # End problem with sqrt and trigsimp. # ##################################################  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1370433&group_id=4933 
From: SourceForge.net <noreply@so...>  20051130 16:46:10

Bugs item #1370199, was opened at 20051130 11:46 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1370199&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: Raymond Toy (rtoy) Assigned to: Nobody/Anonymous (nobody) Summary: complex log not accurate Initial Comment: (%i52) rectform(log(1.b0+%i*1b5)); `rat' replaced 1.0B0 by 1/1 = 1.0B0 `rat' replaced 1.0B5 by 1/100000 = 1.0B5 (%o52) 9.999999999666667b6*%i+5.000000413576855b11 (%i53) :lisp (log #c(1d0 1d5)) #C(4.999999999750001e11 9.999999999666668e6) The lisp result is right, I think.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1370199&group_id=4933 
From: SourceForge.net <noreply@so...>  20051130 16:27:27

Bugs item #1370188, was opened at 20051130 11:27 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=1370188&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: Raymond Toy (rtoy) Assigned to: Nobody/Anonymous (nobody) Summary: complex sqrt not accurate Initial Comment: Complex sqrt is not accurate: (%i38) display2d:false; (%o38) false (%i39) fpprec; (%o39) 16 (%i40) rectform(sqrt(1b0+%i*1b5)),bfloat; (%o40) 5.000000206850923b6*%i+1.0000000000125b0 (%i41) rectform(sqrt(1d0+%i*1d5)),numer; (%o41) 4.9999999999375005e6*%i+1.0000000000125 (%i42) :lisp (sqrt #c(1d0 1d5)) #C(1.0000000000125 4.9999999999375e6) %o41 and %o42 are more accurate.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1370188&group_id=4933 
From: SourceForge.net <noreply@so...>  20051130 04:39:07

Bugs item #1063219, was opened at 20041109 11:37 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1063219&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Pending Resolution: Accepted Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: plot2d Initial Comment: 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 plot2d function does nothing at all. It worked perfectly in v. 5.9.0. ristoid@...  >Comment By: Raymond Toy (rtoy) Date: 20051129 23:39 Message: Logged In: YES user_id=28849 Changed to pending.  Comment By: Raymond Toy (rtoy) Date: 20041123 10:28 Message: Logged In: YES user_id=28849 Do you have gnuplot? Does it work? What plot2d command did you give? What is plot_options? Hmm. I don't use windows.  Comment By: Raymond Toy (rtoy) Date: 20041122 18:41 Message: Logged In: YES user_id=28849 No additional information, and it works for me, so I'm closing this bug.  Comment By: Nobody/Anonymous (nobody) Date: 20041112 21:31 Message: Logged In: NO Look if you have installed gnuplot correctly.  Comment By: Raymond Toy (rtoy) Date: 20041109 14:37 Message: Logged In: YES user_id=28849 More information needed. What did you plot? Do you have gnuplot? What exactly happened?  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1063219&group_id=4933 
From: SourceForge.net <noreply@so...>  20051130 04:35:46

Bugs item #1094108, was opened at 20050101 12:04 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1094108&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Pending Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Maxima crashed Dell 8400 Initial Comment: I installed Maxima on two dells for trial runs: Dell 8400 (P4, 3.2GHz) and Dell Latitude C610 (P3, 1.2 GHz). All installed tests cases run and my simple tests also work. Maxima is granted with full network access in firewall setting. And Maxima is brought up in the startup as installed. Dell 8400 has multiple user setup. When the machine is idled, sometime the machine will freeze. When the user switched, the machine always froze. I uninstalled Maxima on Dell 8400. Everything else function properly.  >Comment By: Raymond Toy (rtoy) Date: 20051129 23:35 Message: Logged In: YES user_id=28849 There hasn't been any additional information, so changing this to Pending, so it will be automatically closed in soon.  Comment By: Stavros Macrakis (macrakis) Date: 20050124 17:29 Message: Logged In: YES user_id=588346 What version of Maxima (use bug_report() for configuration information)? What operating system and version on each computer? What firewall? What exactly do you mean by "when the user switched"?  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1094108&group_id=4933 
From: SourceForge.net <noreply@so...>  20051130 03:27:30

Bugs item #1369669, was opened at 20051129 20:01 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1369669&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: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: csc & trigexpand Initial Comment: I think trigexpandtimes with csc is buggy: (%i59) csc(3*x),trigexpand; (%o59) (csc(x)^3*sec(x)^3)/(3*csc(x)*sec(x)^2csc(x) ^3) (%i60) %csc(3*x); (%o60) (csc(x)^3*sec(x)^3)/(3*csc(x)*sec(x)^2csc(x) ^3)csc(3*x) (%i61) subst(x=0.3,%); (%o61) 2.8853320239249447 < should be zero. Barton  >Comment By: Raymond Toy (rtoy) Date: 20051129 22:27 Message: Logged In: YES user_id=28849 In csc\Sectimes, the last lines says (sin\Costimes l m n f1 f2 flag))) If we swap f1 and f2 like so: (sin\Costimes l m n f2 f1 flag))) With this change: (%i35) csc(3*x),trigexpand; (%o35) csc(x)^3*sec(x)^3/(3*csc(x)^2*sec(x)sec(x)^3) (%i36) ev(%csc(3*x),x=0.3); (%o36) 6.661338147750939e16 This looks better.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1369669&group_id=4933 
From: SourceForge.net <noreply@so...>  20051130 03:24:14

Bugs item #1369451, was opened at 20051129 14:08 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1369451&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: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: secant & trigexpand Initial Comment: I believe the correct trigexpanded expression for sec (x+y) is (%o104) (csc(x)*sec(x)*csc(y)*sec(y))/(sec(x)*sec(y) csc(x)*csc(y)) But Maxima gives (%i105) sec(x+y),trigexpand; (%o105) (csc(x)*sec(x)*csc(y)*sec(y))/(sec(x)*sec(y) csc(x)*csc(y)) Testing for x = 1 and y = 1 verifies Maxima makes a sign error for trigexoand(sec(x+y)): (%i106) sec(x+y),trigexpand; (%o106) (csc(x)*sec(x)*csc(y)*sec(y))/(sec(x)*sec(y) csc(x)*csc(y)) (%i107) subst([x=1,y=1],%); (%o107) (csc(1)^2*sec(1)^2)/(sec(1)^2csc(1)^2) (%i108) float(%); (%o108) 2.4029979617223818 (%i109) sec(2.0); (%o109) 2.4029979617223809 Barton  >Comment By: Raymond Toy (rtoy) Date: 20051129 22:24 Message: Logged In: YES user_id=28849 Not 100% sure, but in csc\Secplus (we should change that name to csc/secplus) the last line says (sin\Cosplus l n f1 f2 flag))) If we change it to read (sin\Cosplus l n f2 f1 flag))) we get the right answer.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1369451&group_id=4933 
From: SourceForge.net <noreply@so...>  20051130 02:24:16

Bugs item #1369697, was opened at 20051129 21: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=1369697&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: Raymond Toy (rtoy) Assigned to: Nobody/Anonymous (nobody) Summary: asinh(bigfloat) is inaccurate for small bigfloats Initial Comment: Like sinh, asinh is inaccurate for small bigfloats: (%i39) asinh(1b5); (%o39) 9.9999999998333304288B6 (%i40) taylor(asinh(x),x,0,5); (%o40) xx^3/6+3*x^5/40 (%i41) ev(xx^3/6+3*x^5/40,x=1b5); (%o41) 9.9999999998333333333B6  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1369697&group_id=4933 
From: SourceForge.net <noreply@so...>  20051130 02:21:50

Bugs item #1369694, was opened at 20051129 21:21 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=1369694&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: Raymond Toy (rtoy) Assigned to: Nobody/Anonymous (nobody) Summary: taylor(acosh(x),x,1...) is wrong Initial Comment: (%i30) taylor(acosh(x),x,1,5); (%o30) (%pi2*log(sqrt(2)+1))/2sqrt(2)*(x1)/2+sqrt(2)*(x1)^2/8 sqrt(2)*(x1)^3/48sqrt(2)*(x1)^4/128 +13*sqrt(2)*(x1)^5/1280 (%i31) ev(%,x=1); (%o31) (2*log(sqrt(2)+1)%pi)/2 (%i32) acosh(1); (%o32) 0 (%i33) ev(%o31,numer); (%o33) 0.6894227397753536 The %pi in %o30 looks clearly wrong. In fact, the taylor expansion looks like the %pi/2  taylor(asinh(x),x,1,5).  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1369694&group_id=4933 
From: SourceForge.net <noreply@so...>  20051130 02:17:06

Bugs item #1369693, was opened at 20051129 21:17 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=1369693&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: Raymond Toy (rtoy) Assigned to: Nobody/Anonymous (nobody) Summary: tanh and atanh not accurate for small bigfloats Initial Comment: tanh and atanh are not very accurate for small bigfloats. (%i21) taylor(atanh(x),x,0,5); (%o21) x+x^3/3+x^5/5 (%i22) atanh(1b6); (%o22) 1.0000000000003328136B6 (%i24) x+x^3/3+x^5/5; (%o24) x^5/5+x^3/3+x (%i25) ev(%o24,x=1b6); (%o25) 1.0000000000003333333B6 Compare %o25 with %o22. %o25 is right. (%i26) tanh(1b6); (%o26) 9.9999999999966745551B7 (%i27) taylor(tanh(x),x,0,5); (%o27) xx^3/3+2*x^5/15 (%i28) xx^3/3+2*x^5/15; (%o28) 2*x^5/15x^3/3+x (%i29) ev(%,x=1b6); (%o29) 9.9999999999966666667B7 Compare %o26 with %o29. %o29 is right.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1369693&group_id=4933 
From: SourceForge.net <noreply@so...>  20051130 02:12:18

Bugs item #1369689, was opened at 20051129 21:12 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=1369689&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: Raymond Toy (rtoy) Assigned to: Nobody/Anonymous (nobody) Summary: sinh(bigfloat) not accurate Initial Comment: sinh for small bigfloats is not very accurate: (%i14) display2d:false; (%o14) false (%i15) fpprec:20; (%o15) 20 (%i16) sinh(1b8); (%o16) 9.9999999999999042563B9 (%i17) x+x^3/3!+x^5/5!; (%o17) x^5/120+x^3/6+x (%i18) ev(%,x=1b8); (%o18) 1.0000000000000000167B8 Maxima converts sinh to exponential form and computes the value using that formula, which is not very accurate for x near 0.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1369689&group_id=4933 
From: SourceForge.net <noreply@so...>  20051130 01:01:54

Bugs item #1369669, was opened at 20051129 19:01 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=1369669&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: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: csc & trigexpand Initial Comment: I think trigexpandtimes with csc is buggy: (%i59) csc(3*x),trigexpand; (%o59) (csc(x)^3*sec(x)^3)/(3*csc(x)*sec(x)^2csc(x) ^3) (%i60) %csc(3*x); (%o60) (csc(x)^3*sec(x)^3)/(3*csc(x)*sec(x)^2csc(x) ^3)csc(3*x) (%i61) subst(x=0.3,%); (%o61) 2.8853320239249447 < should be zero. Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1369669&group_id=4933 
From: SourceForge.net <noreply@so...>  20051129 20:18:31

Bugs item #1369507, was opened at 20051129 14: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=1369507&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: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: atan(x), logarc is wrong Initial Comment: (%i191) atan(x), logarc; (%o191) (%i*log((1%i*x)/(%i*x+1)))/2 The correct expression is (%i*(log(%i*x+1)log(1%i*x)))/2 Note: A&S 4.4.28 clearly mark the expression in %o191 as correct for real x. For complex x, the A&S 4.4.28 isn't always correct. See also http://www.franz.com/support/documentation/7.0/ansicl/ dictentr/asinacos.htm Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1369507&group_id=4933 
From: SourceForge.net <noreply@so...>  20051129 19:28:19

Bugs item #1366253, was opened at 20051125 07:29 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1366253&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: plot2d(log(x),[x.5,5]) Initial Comment: Using Maxima5.9.2 plot2d(log(x),[x.5,5]) Result is a graph of the log(x)including a mirrored graph concerning the yaxis. When i use wgnuplot.exe directly, this problem does not occur.  >Comment By: Raymond Toy (rtoy) Date: 20051129 14:28 Message: Logged In: YES user_id=28849 This is caused by plot2d plotting the realpart of the function. Not sure if that's what's wanted or not.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1366253&group_id=4933 
From: SourceForge.net <noreply@so...>  20051129 19:08:57

Bugs item #1369451, was opened at 20051129 13:08 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=1369451&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: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: secant & trigexpand Initial Comment: I believe the correct trigexpanded expression for sec (x+y) is (%o104) (csc(x)*sec(x)*csc(y)*sec(y))/(sec(x)*sec(y) csc(x)*csc(y)) But Maxima gives (%i105) sec(x+y),trigexpand; (%o105) (csc(x)*sec(x)*csc(y)*sec(y))/(sec(x)*sec(y) csc(x)*csc(y)) Testing for x = 1 and y = 1 verifies Maxima makes a sign error for trigexoand(sec(x+y)): (%i106) sec(x+y),trigexpand; (%o106) (csc(x)*sec(x)*csc(y)*sec(y))/(sec(x)*sec(y) csc(x)*csc(y)) (%i107) subst([x=1,y=1],%); (%o107) (csc(1)^2*sec(1)^2)/(sec(1)^2csc(1)^2) (%i108) float(%); (%o108) 2.4029979617223818 (%i109) sec(2.0); (%o109) 2.4029979617223809 Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1369451&group_id=4933 
From: SourceForge.net <noreply@so...>  20051125 16:02:39

Bugs item #649428, was opened at 20021206 02:42 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=649428&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: Martin Rubey (kratt5) Assigned to: Nobody/Anonymous (nobody) Summary: new simpsum / taylor bug Initial Comment: This is a new simpsum / taylor bug. Note that I used a patched version of Maxima, as described in the simpsum bug thread: combin.lisp 933,935c927,929 < ;; nil ;; Kratt5 26.11.2002 < ; #cl < (let (*a *n (var *var*)) ; freevar expects "var", not "*var*"  > nil > #cl > (let (*a *n) (C1) build_info(); Maxima version: 5.9.0rc3 Maxima build date: 21:0 11/26/2002 host type: i686pclinuxgnu lispimplementationtype: Kyoto Common Lisp lispimplementationversion: GCL25.0 (D1) (C2) factsum3(mt,ej):=sum((1)^(k+1)/(k*mt^k)*sum((1l)^kl^k,l,1,ej),k,1,INF)$ (C3) taylor(factsum3(mt,ej),[mt,0,3,ASYMP]); ej ej ej ==== ==== ==== \ \ \ 3 2 > ( 2 l + 1) > ( 2 l + 1) > ( 2 l + 3 l  3 l + 1) / / / ==== ==== ==== l = 1 l = 1 l = 1 (D3)/T/    +  mt 2 3 2 mt 3 mt + . . . (C4) taylor(factsum3(mt,ej),[mt,0,3,ASYMP]),simpsum; 2 2 4 2 l l l + l (D4)/T/   +    + . . . mt 2 3 2 mt 6 mt (C5) This is nearly correct, only l should be changed to ej... Martin  >Comment By: Robert Dodier (robert_dodier) Date: 20051125 09:02 Message: Logged In: YES user_id=501686 Reopening this bug report; it was closed by mistake. The reported problem is still present in cvs Maxima. For the record here is a more readable presentation of the same example. (%i2) factsum3(mt,ej):=sum((1)^(k+1)/(k*mt^k)*sum((1l)^kl^k,l,1,ej),k,1,inf); (%o2) factsum3(mt,ej):=sum( (1)^(k+1)/(k*mt^k)*sum((1l)^kl^k,l,1,ej),k,1, inf) (%i3) taylor(factsum3(mt,ej),[mt,0,3,asymp]); (%o3) ('sum(2*l+1,l,1,ej))/mt('sum(2*l+1,l,1,ej))/(2*mt^2) +('sum(2*l^3+3*l^23*l+1,l,1,ej)) /(3*mt^3) (%i4) ''%, simpsum; (%o4) (6*ej^2*mt^23*ej^2*mt+ej^4+ej^2)/(6*mt^3) < OK (%i5) taylor(factsum3(mt,ej),[mt,0,3,asymp]), simpsum; (%o5) l^2/mt+l^2/(2*mt^2)(l^4+l^2)/(6*mt^3) < OOPS  Comment By: Robert Dodier (robert_dodier) Date: 20051124 01:43 Message: Logged In: YES user_id=501686 The reported bug is not present in the current cvs version of Maxima. Thank you for your report. If you see this bug in a later version of Maxima, please submit a new bug report.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=649428&group_id=4933 
From: SourceForge.net <noreply@so...>  20051125 15:51:25

Bugs item #625278, was opened at 20021018 09:18 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=625278&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: Robert Dodier (robert_dodier) Summary: simpsum bug Initial Comment: Hi! Unfortunately I have found a bug in simpsum (it seems): (C1) 'SUM(BINOMIAL(2,2k)BINOMIAL(2,1k),k,1,2),simpsum; (D1) 3 ***************** wrong ********************** (C2) 'SUM(BINOMIAL(2,2k)BINOMIAL(2,1k),k,1,2),sum; (D2) 2 ***************** correct ******************** ***************** however : ****************** (C3) 'SUM(BINOMIAL(x,2k)BINOMIAL(x,1k),k,1,2),simpsum; (D3) x (C4) 'SUM(BINOMIAL(x,2k)BINOMIAL(x,1k),k,1,2),sum; (D4) x (C5) bug_report(); Maxima version: 5.9.0rc1 Maxima build date: 11:40 9/3/2002 host type: i686pclinuxgnu lispimplementationtype: Kyoto Common Lisp lispimplementationversion: GCL25.0 Martin  >Comment By: Robert Dodier (robert_dodier) Date: 20051125 08:51 Message: Logged In: YES user_id=501686 Reopening this report because the example shown below (sum(f(k)+1,k,1,n),simpsum;) is still present. Not clear to me whether any of the patches shown below was ever applied.  Comment By: Robert Dodier (robert_dodier) Date: 20051124 01:43 Message: Logged In: YES user_id=501686 The reported bug is not present in the current cvs version of Maxima. Thank you for your report. If you see this bug in a later version of Maxima, please submit a new bug report.  Comment By: Stavros Macrakis (macrakis) Date: 20040223 22:04 Message: Logged In: YES user_id=588346 Thanks for the patch. You might also be interested to know that nusum does very nicely on this case (generalized) with a little massaging: summand: binomial(q,2k)binomial(q,1k); sum0: nusum( minfactorial(makefact(summand)), k,1,n); factcomb(minfactorial(sum0)) => qq!/((1n)!*(q+n1)!) For more fun, try summand: binomial(q,7k)binomial(q,3k); PS Could you please post the complete patched 'sum' function? I am more confident with that than with merged patches. Thanks.  Comment By: Martin Rubey (kratt5) Date: 20021126 12:16 Message: Logged In: YES user_id=651552 sorry, below was a typo (a parenthesis didn't get deleted) 933,935c927,929 < ;; nil ;; Kratt5 26.11.2002 < ; #cl < (let (*a *n (var *var*)) ; freevar expects "var", not "*var*"  > nil > #cl > (let (*a *n)  Comment By: Martin Rubey (kratt5) Date: 20021126 12:04 Message: Logged In: YES user_id=651552 > Can you explain why there is a conditionalization > for #+cl there? I don't see any reason for this > code to depend on common lisp or not. My thought > on fixing the code previously displayed was to > just remove #cl > RJF Yes, I can explain it. It's there because I was very stupid. Here is the right fix: (and THANK YOU, I feel a little ashamed...) diff combin.lisp combin.lisp.~1.2.~ 915,920d914 < ; Kratt5, 26.11.2002 < ; adsum's and adusum's the sum of e. < < ; It's result is discarded. (at least I think that this function is < ; only called by sumsum, but there are lots of places where a variable < ; is called "sum"...) 933,935c927,929 < ;; nil ;; Kratt5 26.11.2002 < ; #cl < (let (*a *n) (var *var*)) ; freevar expects "var", not "*var*"  > nil > #cl > (let (*a *n)  Comment By: Martin Rubey (kratt5) Date: 20021126 06:49 Message: Logged In: YES user_id=651552 OK, I got the bug now: The fix is rather obvious (except that I had to dig through all of sum, see below) and the bug is rather serious (I can produce lots of everyday examples, (C1) sum(f(k)+1,k,1,n),simpsum; (D2) n so I propose to include it in 5.9.0 !!! I didn't change some things I would like to, I think this is for after 5.9.0... fix and explanation below Martin fix diff combin.lisp combin.lisp.~1.2.~ 915,920d914 < ; Kratt5, 26.11.2002 < ; adsum's and adusum's the sum of e. < < ; It's result is discarded. (at least I think that this function is < ; only called by sumsum, but there are lots of places where a variable < ; is called "sum"...) 930,939d923 < ; this is to deal with linearity Kratt5, 26.11.2002 < ((let (*a *n (var *var*)) < (cond ((prog2 (m2 e '((mtimes) ((coefftt) (var* (set) *a freevar)) < ((coefftt) (var* (set) *n true))) < nil) < (not (equal *a 1))) < ;; we have to return T, so that sum is exited if the test was successful < (prog2 (sum *n (list '(mtimes) y *a)) < T))))) < ;; 943,944c927 < #+cl (adusum (list '(mtimes) e y)) ;; Kratt5 26.11.2002 < ;; nil  > nil end fix I tested it with Maxima version: 5.9.0rc3 Maxima build date: 13:52 11/18/2002 host type: i686pclinuxgnu lispimplementationtype: Kyoto Common Lisp lispimplementationversion: GCL25.0 explanation  (lisp level) the structure of $sum is roughly as follows: $sum: argcheck, call dosum with meval'd bounds dosum: didn't look at this too much after this, meval calls simpsum **** if you type 'sum(f(k),k,1,n),simpsum; meval calls only simpsum **** $simpsum: call simpsum1 simpsum1: checks lo=hi, otherwise exp not depending on the summation index, otherwise if $simpsum, call simpsum2 **** simpsum2 is found in combin.lisp **** simpsum2: sets up a variable *plus, which will contain all the stuff which is added together at the end calls sumsum sumsum: returns the part of the expression it was able to sum up (this is the contents of the variable "usum"), all the rest (the contents of the variable "sum") is put into the variable *plus, which is then used by simpsum2 calls sum sum: adsum's and adusum's the sum of e. It's result is discarded. (at least I think that this function is only called by sumsum, but there are lots of places where a variable is called "sum"...)  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=625278&group_id=4933 
From: SourceForge.net <noreply@so...>  20051125 12:29:20

Bugs item #1366253, was opened at 20051125 04:29 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=1366253&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: plot2d(log(x),[x.5,5]) Initial Comment: Using Maxima5.9.2 plot2d(log(x),[x.5,5]) Result is a graph of the log(x)including a mirrored graph concerning the yaxis. When i use wgnuplot.exe directly, this problem does not occur.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1366253&group_id=4933 
From: SourceForge.net <noreply@so...>  20051124 08:43:07

Bugs item #625278, was opened at 20021018 09:18 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=625278&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core Group: None Status: Closed Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: simpsum bug Initial Comment: Hi! Unfortunately I have found a bug in simpsum (it seems): (C1) 'SUM(BINOMIAL(2,2k)BINOMIAL(2,1k),k,1,2),simpsum; (D1) 3 ***************** wrong ********************** (C2) 'SUM(BINOMIAL(2,2k)BINOMIAL(2,1k),k,1,2),sum; (D2) 2 ***************** correct ******************** ***************** however : ****************** (C3) 'SUM(BINOMIAL(x,2k)BINOMIAL(x,1k),k,1,2),simpsum; (D3) x (C4) 'SUM(BINOMIAL(x,2k)BINOMIAL(x,1k),k,1,2),sum; (D4) x (C5) bug_report(); Maxima version: 5.9.0rc1 Maxima build date: 11:40 9/3/2002 host type: i686pclinuxgnu lispimplementationtype: Kyoto Common Lisp lispimplementationversion: GCL25.0 Martin  Comment By: Robert Dodier (robert_dodier) Date: 20051124 01:43 Message: Logged In: YES user_id=501686 The reported bug is not present in the current cvs version of Maxima. Thank you for your report. If you see this bug in a later version of Maxima, please submit a new bug report.  Comment By: Stavros Macrakis (macrakis) Date: 20040223 22:04 Message: Logged In: YES user_id=588346 Thanks for the patch. You might also be interested to know that nusum does very nicely on this case (generalized) with a little massaging: summand: binomial(q,2k)binomial(q,1k); sum0: nusum( minfactorial(makefact(summand)), k,1,n); factcomb(minfactorial(sum0)) => qq!/((1n)!*(q+n1)!) For more fun, try summand: binomial(q,7k)binomial(q,3k); PS Could you please post the complete patched 'sum' function? I am more confident with that than with merged patches. Thanks.  Comment By: Martin Rubey (kratt5) Date: 20021126 12:16 Message: Logged In: YES user_id=651552 sorry, below was a typo (a parenthesis didn't get deleted) 933,935c927,929 < ;; nil ;; Kratt5 26.11.2002 < ; #cl < (let (*a *n (var *var*)) ; freevar expects "var", not "*var*"  > nil > #cl > (let (*a *n)  Comment By: Martin Rubey (kratt5) Date: 20021126 12:04 Message: Logged In: YES user_id=651552 > Can you explain why there is a conditionalization > for #+cl there? I don't see any reason for this > code to depend on common lisp or not. My thought > on fixing the code previously displayed was to > just remove #cl > RJF Yes, I can explain it. It's there because I was very stupid. Here is the right fix: (and THANK YOU, I feel a little ashamed...) diff combin.lisp combin.lisp.~1.2.~ 915,920d914 < ; Kratt5, 26.11.2002 < ; adsum's and adusum's the sum of e. < < ; It's result is discarded. (at least I think that this function is < ; only called by sumsum, but there are lots of places where a variable < ; is called "sum"...) 933,935c927,929 < ;; nil ;; Kratt5 26.11.2002 < ; #cl < (let (*a *n) (var *var*)) ; freevar expects "var", not "*var*"  > nil > #cl > (let (*a *n)  Comment By: Martin Rubey (kratt5) Date: 20021126 06:49 Message: Logged In: YES user_id=651552 OK, I got the bug now: The fix is rather obvious (except that I had to dig through all of sum, see below) and the bug is rather serious (I can produce lots of everyday examples, (C1) sum(f(k)+1,k,1,n),simpsum; (D2) n so I propose to include it in 5.9.0 !!! I didn't change some things I would like to, I think this is for after 5.9.0... fix and explanation below Martin fix diff combin.lisp combin.lisp.~1.2.~ 915,920d914 < ; Kratt5, 26.11.2002 < ; adsum's and adusum's the sum of e. < < ; It's result is discarded. (at least I think that this function is < ; only called by sumsum, but there are lots of places where a variable < ; is called "sum"...) 930,939d923 < ; this is to deal with linearity Kratt5, 26.11.2002 < ((let (*a *n (var *var*)) < (cond ((prog2 (m2 e '((mtimes) ((coefftt) (var* (set) *a freevar)) < ((coefftt) (var* (set) *n true))) < nil) < (not (equal *a 1))) < ;; we have to return T, so that sum is exited if the test was successful < (prog2 (sum *n (list '(mtimes) y *a)) < T))))) < ;; 943,944c927 < #+cl (adusum (list '(mtimes) e y)) ;; Kratt5 26.11.2002 < ;; nil  > nil end fix I tested it with Maxima version: 5.9.0rc3 Maxima build date: 13:52 11/18/2002 host type: i686pclinuxgnu lispimplementationtype: Kyoto Common Lisp lispimplementationversion: GCL25.0 explanation  (lisp level) the structure of $sum is roughly as follows: $sum: argcheck, call dosum with meval'd bounds dosum: didn't look at this too much after this, meval calls simpsum **** if you type 'sum(f(k),k,1,n),simpsum; meval calls only simpsum **** $simpsum: call simpsum1 simpsum1: checks lo=hi, otherwise exp not depending on the summation index, otherwise if $simpsum, call simpsum2 **** simpsum2 is found in combin.lisp **** simpsum2: sets up a variable *plus, which will contain all the stuff which is added together at the end calls sumsum sumsum: returns the part of the expression it was able to sum up (this is the contents of the variable "usum"), all the rest (the contents of the variable "sum") is put into the variable *plus, which is then used by simpsum2 calls sum sum: adsum's and adusum's the sum of e. It's result is discarded. (at least I think that this function is only called by sumsum, but there are lots of places where a variable is called "sum"...)  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=625278&group_id=4933 
From: SourceForge.net <noreply@so...>  20051124 08:43:07

Bugs item #817521, was opened at 20031003 19:48 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=817521&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: Closed Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: translate sum(a[i//fixnum]) very wrong Initial Comment: Translate seems to get confused about subscripted variables when the subscript is declared fixnum in certain contexts: (C1) foo(n):= block([m], modedeclare(m,fixnum), m:n, [ aaa[1], aaa[n], aaa[m], aaa[1]+aaa[2], sum(aaa[i],i,1,m) ] ) $ ... The problem comes in the sum, so I've included array references outside a sum to show that they work. (C2) foo(2); (D2) [aaa[1],aaa[2],aaa[2],aaa[2]+aaa[1], aaa[2]+aaa[1]] ... no problem with interpreted form (C3) translate(foo)$ WARNING> Assigning variable m, whose mode is FIXNUM,a value of mode ANY. Warning> aaa is an undefined global variable. ...These are warnings, so we hope they don't affect anything (C4) foo(2); (D4) [aaa[1],aaa[2],aaa[2],aaa[2]+aaa[1],553729296] !!! Everything is fine until we get to the sum, which is completely crazy. Looking at the translated code, we find that it's using F+ (fixnum plus) to add aaa[1] and aaa[2].  Comment By: Robert Dodier (robert_dodier) Date: 20051124 01:43 Message: Logged In: YES user_id=501686 The reported bug is not present in the current cvs version of Maxima. Thank you for your report. If you see this bug in a later version of Maxima, please submit a new bug report.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=817521&group_id=4933 
From: SourceForge.net <noreply@so...>  20051124 08:43:07

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

Bugs item #649428, was opened at 20021206 02:42 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=649428&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: Closed Resolution: None Priority: 5 Submitted By: Martin Rubey (kratt5) Assigned to: Nobody/Anonymous (nobody) Summary: new simpsum / taylor bug Initial Comment: This is a new simpsum / taylor bug. Note that I used a patched version of Maxima, as described in the simpsum bug thread: combin.lisp 933,935c927,929 < ;; nil ;; Kratt5 26.11.2002 < ; #cl < (let (*a *n (var *var*)) ; freevar expects "var", not "*var*"  > nil > #cl > (let (*a *n) (C1) build_info(); Maxima version: 5.9.0rc3 Maxima build date: 21:0 11/26/2002 host type: i686pclinuxgnu lispimplementationtype: Kyoto Common Lisp lispimplementationversion: GCL25.0 (D1) (C2) factsum3(mt,ej):=sum((1)^(k+1)/(k*mt^k)*sum((1l)^kl^k,l,1,ej),k,1,INF)$ (C3) taylor(factsum3(mt,ej),[mt,0,3,ASYMP]); ej ej ej ==== ==== ==== \ \ \ 3 2 > ( 2 l + 1) > ( 2 l + 1) > ( 2 l + 3 l  3 l + 1) / / / ==== ==== ==== l = 1 l = 1 l = 1 (D3)/T/    +  mt 2 3 2 mt 3 mt + . . . (C4) taylor(factsum3(mt,ej),[mt,0,3,ASYMP]),simpsum; 2 2 4 2 l l l + l (D4)/T/   +    + . . . mt 2 3 2 mt 6 mt (C5) This is nearly correct, only l should be changed to ej... Martin  Comment By: Robert Dodier (robert_dodier) Date: 20051124 01:43 Message: Logged In: YES user_id=501686 The reported bug is not present in the current cvs version of Maxima. Thank you for your report. If you see this bug in a later version of Maxima, please submit a new bug report.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=649428&group_id=4933 
From: SourceForge.net <noreply@so...>  20051124 08:43:07

Bugs item #851765, was opened at 20031130 15:59 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=851765&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: Closed Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: sum mishandles assume scopes Initial Comment: assume(i>=a); [i >= a] facts(); [i >= a] so far, so good sum(i,i,a,b)$ facts() [] oops! It removed the assumption is(i>=a) MACSYMA was unable to evaluate the predicate: i >= a The problem is that dosum adds the assumption a<=i<=b, and then removes it when it's done. But it does this in the global database, not a local one. So it also removes any preexisting identical assumption. It also ignores any inconsistent assumptions: assume(a>i) sum(i,i,a,b) => no error message This is sort of defensible on the grounds that the inner 'i' really isn't the same variable as the global 'i' (as though Maxima understood that)... except that it *is* obeying the global assumptions: assume(i<0) sum(abs(i),i,1,a) => 'sum(i,i,1,a)  Comment By: Robert Dodier (robert_dodier) Date: 20051124 01:43 Message: Logged In: YES user_id=501686 The reported bug is not present in the current cvs version of Maxima. Thank you for your report. If you see this bug in a later version of Maxima, please submit a new bug report.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=851765&group_id=4933 
From: SourceForge.net <noreply@so...>  20051124 08:43:06

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: Closed 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: 20051124 01:43 Message: Logged In: YES user_id=501686 The reported bug is not present in the current cvs version of Maxima. Thank you for your report. If you see this bug in a later version of Maxima, please submit a new bug report.  Comment By: Robert Dodier (robert_dodier) Date: 20050819 23:08 Message: Logged In: YES user_id=501686 removing old versions of files  Comment By: Robert Dodier (robert_dodier) Date: 20050819 23:03 Message: Logged In: YES user_id=501686 attaching a zip file containing unksum6.lisp, tmpsum13.lisp (two different sum reimplementations), rtestsum.mac, and mand.lisp (a reimplementation of mcondrelated stuff  needed for the one test which makes use of an unevaluated conditional).  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...>  20051124 08:43:06

Bugs item #1363411, was opened at 20051121 22:11 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1363411&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core Group: None Status: Closed Resolution: None Priority: 5 Submitted By: Robert Dodier (robert_dodier) Assigned to: Nobody/Anonymous (nobody) Summary: finite summation simpsum bug Initial Comment: The following bug was noted by Martin Rubey: http://www.math.utexas.edu/pipermail/maxima/2002/003145.html (%i1) 'sum(1+f(k),k,1,2),simpsum; (%o1) 2 (Should be f(1) + f(2) + 2.) It is still present. (%i2) build_info(); Maxima version: 5.9.2.3cvs Maxima build date: 7:46 11/17/2005 host type: i686redhatlinuxgnu lispimplementationtype: CLISP lispimplementationversion: 2.34 (20050720)  Comment By: Robert Dodier (robert_dodier) Date: 20051124 01:43 Message: Logged In: YES user_id=501686 The reported bug is not present in the current cvs version of Maxima. Thank you for your report. If you see this bug in a later version of Maxima, please submit a new bug report.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1363411&group_id=4933 