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}
(8) 
_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

From: SourceForge.net <noreply@so...>  20050325 03:28:16

Bugs item #1156759, was opened at 20050304 10:00 Message generated for change (Comment added) made by amundson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1156759&group_id=4933 Category: Lisp Core >Group: Fix for 5.9.2 Status: Open Resolution: None Priority: 6 Submitted By: Robert Dodier (robert_dodier) >Assigned to: James Amundson (amundson) Summary: plot2d complains about Unknown plot option if given a range Initial Comment: plot2d complains about Unknown plot option if given a range for y (ordinary) or t (parametric). These examples work in 5.9.1 official release (cmucl), but fail with Unknown plot option in current cvs (2005/03/03). (%i3) plot2d(sec(x),[x,2,2],[y,20,20],[nticks,200]); Unknown plot option specified: y (%i4) plot2d([parametric,cos(t),sin(t),[t,%pi*2,%pi*2], [nticks,80]]); Unknown plot option specified: t (%i5) plot2d([parametric,cos(t),sin(t),[t,%pi*2,%pi*2], [nticks,8]]); Unknown plot option specified: t These examples work in current cvs: (%i2) plot2d(sin(x),[x,5,5]); (%i6) plot2d([x^3+2,[parametric,cos(t),sin(t),[t,5,5], [nticks,80]]],[x,3,3]); These examples are copied from the ? plot2d examples.  >Comment By: James Amundson (amundson) Date: 20050324 21:28 Message: Logged In: YES user_id=28457 I'm sure this is my fault. I must have introduced a bug when I made my last round of fixes in plot2d.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1156759&group_id=4933 
From: SourceForge.net <noreply@so...>  20050325 03:26:59

Bugs item #1116091, was opened at 20050204 04:53 Message generated for change (Comment added) made by amundson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1116091&group_id=4933 Category: Tests >Group: Fix for 5.9.2 Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: James Amundson (amundson) Summary: error in run_testsuite Initial Comment: Repeated run of run_testsuite() display errors like these Error summary: Error found in /usr/local/share/maxima/5.9.1/tests/rtest1.mac, problem: (10) Error found in /usr/local/share/maxima/5.9.1/tests/rtest15.mac, problem: (46) Error found in /usr/local/share/maxima/5.9.1/tests/rtest12.mac, problem: (20) However, the first run of run_testsuite ends with no error message! Maxima version: 5.9.1 Maxima build date: 18:21 1/12/2005 host type: i686pclinuxgnu lispimplementationtype: Kyoto Common Lisp lispimplementationversion: GCL 2.6.5 Dr. T.I. Toth Cardiff University Cardiff U.K.  >Comment By: James Amundson (amundson) Date: 20050324 21:26 Message: Logged In: YES user_id=28457 The main problem here is the broken behavior of kill, but there may be a few other minor problems. I'm working on it.  Comment By: Robert Dodier (robert_dodier) Date: 20050210 01:32 Message: Logged In: YES user_id=501686 I've reproduced this behavior on my machine (Maxima 5.9.1cvs on clisp 2.31 on linux). It seems likely this is due to global variables being assigned by some tests which hang around after the test is over, and then change the way results are computed for other tests when run_testsuite() is executed again. This theory could be tested by doing a global save before run_testsuite(), then restoring, then doing run_testsuite() again. Unfortunately there's no built in mechanism for global save  "save (filename, all)" isn't it.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1116091&group_id=4933 
From: SourceForge.net <noreply@so...>  20050324 16:28:23

Bugs item #1169996, was opened at 20050324 10:28 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=1169996&group_id=4933 Category: Lisp Core Group: Fix for 5.9.2 Status: Open Resolution: None Priority: 5 Submitted By: James Amundson (amundson) Assigned to: James Amundson (amundson) Summary: Prompt missing after example Initial Comment: From: Andrej Vodopivec <andrej.vodopivec@...> To: Maxima List <maxima@...> Subject: [Maxima] Prompt missing after example Date: Wed, 23 Mar 2005 14:18:31 +0100 Hi, cvs version of maxima does not display prompts after example commands. Bellow, prompt %i2 is missing.  (%i1) example(product); (%i2) product(i*(1+i)/2+x,i,1,4) (%o2) (x + 1) (x + 3) (x + 6) (x + 10) (%o2) done 1; (%o3) 1 (%i4) build_info(); Maxima version: 5.9.1.1cvs Maxima build date: 15:43 3/20/2005 host type: i686pclinuxgnu lispimplementationtype: Kyoto Common Lisp lispimplementationversion: GCL 2.6.5  Andrej  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1169996&group_id=4933 
From: SourceForge.net <noreply@so...>  20050324 15:49:52

Bugs item #1169964, was opened at 20050324 09:49 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1169964&group_id=4933 Category: Documentation Group: Fix for 5.9.2 Status: Open Resolution: None Priority: 5 Submitted By: James Amundson (amundson) Assigned to: James Amundson (amundson) Summary: no documentation for discrete plots Initial Comment: The discrete plot option I added has no documentation.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1169964&group_id=4933 
From: SourceForge.net <noreply@so...>  20050324 15:45:34

Bugs item #1169962, was opened at 20050324 09:45 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=1169962&group_id=4933 Category: Lisp Core Group: Fix for 5.9.2 Status: Open Resolution: None Priority: 5 Submitted By: James Amundson (amundson) Assigned to: James Amundson (amundson) Summary: cmucl runtime not detected properly Initial Comment: configure is unable to determine the cmucl runtime when using the kderedhat version of cmucl. The runtime detection code needs to be smarter overall.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1169962&group_id=4933 
From: SourceForge.net <noreply@so...>  20050324 15:43:42

Bugs item #1169961, was opened at 20050324 09:43 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=1169961&group_id=4933 Category: Lisp Core Group: Fix for 5.9.2 Status: Open Resolution: None Priority: 5 Submitted By: James Amundson (amundson) Assigned to: James Amundson (amundson) Summary: configure should check for gcl ansi Initial Comment: When gcl is selected at configure time, we should check that gcl has been compiled with the ansi flag.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1169961&group_id=4933 
From: SourceForge.net <noreply@so...>  20050324 15:32:14

Bugs item #1169951, was opened at 20050324 09:32 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=1169951&group_id=4933 Category: Documentation Group: Fix for 5.9.2 Status: Open Resolution: None Priority: 5 Submitted By: James Amundson (amundson) Assigned to: James Amundson (amundson) Summary: init file location not clear in man page Initial Comment: It is not clear from the man page where the user maximainit.(lisp,mac) files should go.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1169951&group_id=4933 
From: SourceForge.net <noreply@so...>  20050324 04:08:11

Bugs item #1169382, was opened at 20050323 14:22 Message generated for change (Comment added) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1169382&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: for matrix A, A[1,0] give "[" Initial Comment: Example : (%i1) A:matrix([1,2],[3,4]); [1 2] (%o1) [ ] [ 3 4] (%i2) A[1,0]; (%o2) [  >Comment By: Barton Willis (willisbl) Date: 20050323 22:08 Message: Logged In: YES user_id=895922 Matrices and lists are indexed starting at 1. If you want the element of A in the 2nd row first column, use A[2,1]. So why does A[1,0] evaluate to [ ? Because A[1,0] == part(A,1,0). The zeroth part of a nonatom is its operator. Now, part(A,1) is a list and part(A,1,0) is the operator of a list. Finally, the operator of a list is [. I don't consider A[1,0] > [ to be a bug. Others may have different opinions. Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1169382&group_id=4933 
From: SourceForge.net <noreply@so...>  20050323 20:22:45

Bugs item #1169382, was opened at 20050323 12:22 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1169382&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: for matrix A, A[1,0] give "[" Initial Comment: Example : (%i1) A:matrix([1,2],[3,4]); [1 2] (%o1) [ ] [ 3 4] (%i2) A[1,0]; (%o2) [  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1169382&group_id=4933 
From: SourceForge.net <noreply@so...>  20050323 09:43:25

Bugs item #1168962, was opened at 20050323 01:43 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=1168962&group_id=4933 Category: None Group: Fix for 5.9.0 Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Batchmode Initial Comment: How Can I Run Maxima in background from shell! Like gnuplot runs from shell with $ gnuplot persist {loadfile} Since some computations are time consuming, and interactive mode means a window is always open. I want to have it in batchmode so that computations are done in background with no maxima shell or xmaxima xwindow need to be opened for prolonged interval  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1168962&group_id=4933 
From: SourceForge.net <noreply@so...>  20050323 00:35:15

Bugs item #1167441, was opened at 20050321 04:49 Message generated for change (Comment added) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1167441&group_id=4933 Category: Share Libraries Group: None >Status: Closed Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: integrate pbs.? Initial Comment: maxima chokes on integrate(1/(x**3+a*x**2+x),x); MuPAD, by comparison, gives an ans. in ca. 2 sec. maxima 5.9.1 bld: 21/24 9/23/04 host: i686 linux lisp Common, 19a  >Comment By: Barton Willis (willisbl) Date: 20050322 18:35 Message: Logged In: YES user_id=895922 Thanks for following up on this. I'll close the bug. Barton  Comment By: Nobody/Anonymous (nobody) Date: 20050322 16:53 Message: Logged In: NO Barton is correct. My pb. was due to texmacs not passing the question forward. Perhaps this whole thread should be deleated here.  Comment By: Barton Willis (willisbl) Date: 20050321 05:05 Message: Logged In: YES user_id=895922 I didn't check these answers by hand, but I don't see a problem. Maybe you could send a copy of your session, or explain why these antiderivatives are wrong. (%i1) integrate(1/(x**3+a*x**2+x),x); Is a^24positive or negative?neg; (%o1) log(x^2+a*x+1)/2(a*atan((2*x+a)/sqrt(4a^2)))/sqrt(4a^2)+log(x) (%i2) radcan(diff(%,x)); (%o2) 1/(x^3+a*x^2+x) (%i3) integrate(1/(x**3+a*x**2+x),x); Is a^24positive or negative?pos; (%o3) (a*log((2*xsqrt(a^24)+a)/(2*x+sqrt(a^24)+a)))/(2*sqrt(a^24))log(x^2+a*x+1)/2+log(x) (%i4) radcan(diff(%,x)); (%o4) 1/(x^3+a*x^2+x) (%i5) build_info(); Maxima version: 5.9.1 Maxima build date: 7:34 9/24/2004 host type: i686pcmingw32 lispimplementationtype: Kyoto Common Lisp lispimplementationversion: GCL 2.6.5 Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1167441&group_id=4933 
From: SourceForge.net <noreply@so...>  20050322 22:53:47

Bugs item #1167441, was opened at 20050321 02:49 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1167441&group_id=4933 Category: Share Libraries Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: integrate pbs.? Initial Comment: maxima chokes on integrate(1/(x**3+a*x**2+x),x); MuPAD, by comparison, gives an ans. in ca. 2 sec. maxima 5.9.1 bld: 21/24 9/23/04 host: i686 linux lisp Common, 19a  Comment By: Nobody/Anonymous (nobody) Date: 20050322 14:53 Message: Logged In: NO Barton is correct. My pb. was due to texmacs not passing the question forward. Perhaps this whole thread should be deleated here.  Comment By: Barton Willis (willisbl) Date: 20050321 03:05 Message: Logged In: YES user_id=895922 I didn't check these answers by hand, but I don't see a problem. Maybe you could send a copy of your session, or explain why these antiderivatives are wrong. (%i1) integrate(1/(x**3+a*x**2+x),x); Is a^24positive or negative?neg; (%o1) log(x^2+a*x+1)/2(a*atan((2*x+a)/sqrt(4a^2)))/sqrt(4a^2)+log(x) (%i2) radcan(diff(%,x)); (%o2) 1/(x^3+a*x^2+x) (%i3) integrate(1/(x**3+a*x**2+x),x); Is a^24positive or negative?pos; (%o3) (a*log((2*xsqrt(a^24)+a)/(2*x+sqrt(a^24)+a)))/(2*sqrt(a^24))log(x^2+a*x+1)/2+log(x) (%i4) radcan(diff(%,x)); (%o4) 1/(x^3+a*x^2+x) (%i5) build_info(); Maxima version: 5.9.1 Maxima build date: 7:34 9/24/2004 host type: i686pcmingw32 lispimplementationtype: Kyoto Common Lisp lispimplementationversion: GCL 2.6.5 Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1167441&group_id=4933 
From: SourceForge.net <noreply@so...>  20050322 05:04:14

Bugs item #1168099, was opened at 20050321 23:04 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=1168099&group_id=4933 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Cliff Yapp (starseeker) Assigned to: Nobody/Anonymous (nobody) Summary: Need to detail the available "maximaized" lisp functions Initial Comment: There exist many functions in Maxima that are expressions of basic programming tools in lisp, but tweaked to conveniently handle Maxima level interactions. These should be identified and documented. Example mfboundp is a version of fboundp in lisp which works on maxima functions.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1168099&group_id=4933 
From: SourceForge.net <noreply@so...>  20050321 11:05:34

Bugs item #1167441, was opened at 20050321 04:49 Message generated for change (Comment added) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1167441&group_id=4933 Category: Share Libraries Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: integrate pbs.? Initial Comment: maxima chokes on integrate(1/(x**3+a*x**2+x),x); MuPAD, by comparison, gives an ans. in ca. 2 sec. maxima 5.9.1 bld: 21/24 9/23/04 host: i686 linux lisp Common, 19a  >Comment By: Barton Willis (willisbl) Date: 20050321 05:05 Message: Logged In: YES user_id=895922 I didn't check these answers by hand, but I don't see a problem. Maybe you could send a copy of your session, or explain why these antiderivatives are wrong. (%i1) integrate(1/(x**3+a*x**2+x),x); Is a^24positive or negative?neg; (%o1) log(x^2+a*x+1)/2(a*atan((2*x+a)/sqrt(4a^2)))/sqrt(4a^2)+log(x) (%i2) radcan(diff(%,x)); (%o2) 1/(x^3+a*x^2+x) (%i3) integrate(1/(x**3+a*x**2+x),x); Is a^24positive or negative?pos; (%o3) (a*log((2*xsqrt(a^24)+a)/(2*x+sqrt(a^24)+a)))/(2*sqrt(a^24))log(x^2+a*x+1)/2+log(x) (%i4) radcan(diff(%,x)); (%o4) 1/(x^3+a*x^2+x) (%i5) build_info(); Maxima version: 5.9.1 Maxima build date: 7:34 9/24/2004 host type: i686pcmingw32 lispimplementationtype: Kyoto Common Lisp lispimplementationversion: GCL 2.6.5 Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1167441&group_id=4933 
From: SourceForge.net <noreply@so...>  20050321 10:49:26

Bugs item #1167441, was opened at 20050321 02:49 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1167441&group_id=4933 Category: Share Libraries Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: integrate pbs.? Initial Comment: maxima chokes on integrate(1/(x**3+a*x**2+x),x); MuPAD, by comparison, gives an ans. in ca. 2 sec. maxima 5.9.1 bld: 21/24 9/23/04 host: i686 linux lisp Common, 19a  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1167441&group_id=4933 
From: SourceForge.net <noreply@so...>  20050321 10:42:51

Bugs item #1086880, was opened at 20041216 21:40 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1086880&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: for maxima5.9.11 Initial Comment: after rpm on RedHat9.0 #maxima #/usr/bin/maxima: unable to determine MAXIMA_PREFIX I don't know why it doesn't work. Give me a hand,THX!!  Comment By: Nobody/Anonymous (nobody) Date: 20050321 02:42 Message: Logged In: NO This diagnostic appeared on at least one system because no maximaexec...rpm was installed. Can be seen as a bug in the maxima...rpm package, which fail if there is no exec.  Comment By: Nobody/Anonymous (nobody) Date: 20050316 17:14 Message: Logged In: NO I have the same pb. with SuSE 8.1! Even after: export MAXIMA_PREFIX=/usr/share/maxima/5.9.1 and variations. Tricks welcome! kracklau@...  Comment By: Robert Dodier (robert_dodier) Date: 20041231 12:11 Message: Logged In: YES user_id=501686 To the author of the original bug report, if you're still watching  I'd like to help but I think more info is needed. I have a very similar system (RH Fedora) and I can run Maxima as installed from the maxima5.9.11 and maximaexeccmucl5.9.11 rpm's (downloaded from Sourceforge). So it looks like your environment is different. Maybe you can give some more details to help us get started.  Robert Dodier (robert_dodier@...)  Comment By: Nobody/Anonymous (nobody) Date: 20041217 20:32 Message: Logged In: NO [root@... root]# rpm Uvh maximaxmaxima5.9.11.i386.rpm error: Failed dependencies: tk is needed by maximaxmaxima5.9.11  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1086880&group_id=4933 
From: SourceForge.net <noreply@so...>  20050318 17:37:42

Bugs item #1165488, was opened at 20050317 13:52 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1165488&group_id=4933 Category: Lisp Core Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: elliptic_kc and diff Initial Comment: The dérivative of elliptic_kc gives 2 times the exact value. To remedy 1. make a lisp file that contains (defprop %elliptic_kc ((m) ;; diff wrt m ((mtimes) ((rat) 1 2) ((mplus) ((%elliptic_ec) m) ((mtimes) 1 ((%elliptic_kc) m) ((mplus) 1 ((mtimes) 1 m)))) ((mexpt) ((mplus) 1 ((mtimes) 1 m)) 1) ((mexpt) m 1))) grad) (the same function as in .../maxima/5.9.1/src/ellipt.lisp modified by the "((rat) 1 2)" ) 2. load this file at the beginnig of a session. That's all. To see the error plot2d([(elliptic_kc(x+0.001)elliptic_kc(x))/0.001,diff(elliptic_kc(x),x)],[x,0.1,0.9]); the two curves are : a discrete derivative of elliptic_kc and the exact derivative.  >Comment By: Raymond Toy (rtoy) Date: 20050318 12:37 Message: Logged In: YES user_id=28849 Fixed. Thanks. This can also be seen by differentiating elliptic_f(phi,m) wrt m and substituting %pi/2 for phi.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1165488&group_id=4933 
From: SourceForge.net <noreply@so...>  20050318 17:33:19

Bugs item #1165530, was opened at 20050317 15:11 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1165530&group_id=4933 Category: Lisp Core Group: None >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: elliptic_kc and diff Initial Comment: The dérivative of elliptic_kc gives 2 times the exact value. To remedy 1. make a lisp file that contains (defprop %elliptic_kc ((m) ;; diff wrt m ((mtimes) ((rat) 1 2) ((mplus) ((%elliptic_ec) m) ((mtimes) 1 ((%elliptic_kc) m) ((mplus) 1 ((mtimes) 1 m)))) ((mexpt) ((mplus) 1 ((mtimes) 1 m)) 1) ((mexpt) m 1))) grad) (the same function as in .../maxima/5.9.1/src/ellipt.lisp modified by the "((rat) 1 2)" ) 2. load this file at the beginnig of a session. That's all. To see the error plot2d([(elliptic_kc(x+0.001)elliptic_kc(x))/0.001,diff(elliptic_kc(x),x)],[x,0.1,0.9]); the two curves are : a discrete derivative of elliptic_kc and the exact derivative.  >Comment By: Raymond Toy (rtoy) Date: 20050318 12:33 Message: Logged In: YES user_id=28849 Duplicate of 1165488.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1165530&group_id=4933 
From: SourceForge.net <noreply@so...>  20050317 20:11:26

Bugs item #1165530, was opened at 20050317 12:11 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=1165530&group_id=4933 Category: Lisp Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: elliptic_kc and diff Initial Comment: The dérivative of elliptic_kc gives 2 times the exact value. To remedy 1. make a lisp file that contains (defprop %elliptic_kc ((m) ;; diff wrt m ((mtimes) ((rat) 1 2) ((mplus) ((%elliptic_ec) m) ((mtimes) 1 ((%elliptic_kc) m) ((mplus) 1 ((mtimes) 1 m)))) ((mexpt) ((mplus) 1 ((mtimes) 1 m)) 1) ((mexpt) m 1))) grad) (the same function as in .../maxima/5.9.1/src/ellipt.lisp modified by the "((rat) 1 2)" ) 2. load this file at the beginnig of a session. That's all. To see the error plot2d([(elliptic_kc(x+0.001)elliptic_kc(x))/0.001,diff(elliptic_kc(x),x)],[x,0.1,0.9]); the two curves are : a discrete derivative of elliptic_kc and the exact derivative.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1165530&group_id=4933 
From: SourceForge.net <noreply@so...>  20050317 18:52:56

Bugs item #1165488, was opened at 20050317 10:52 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=1165488&group_id=4933 Category: Lisp Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: elliptic_kc and diff Initial Comment: The dérivative of elliptic_kc gives 2 times the exact value. To remedy 1. make a lisp file that contains (defprop %elliptic_kc ((m) ;; diff wrt m ((mtimes) ((rat) 1 2) ((mplus) ((%elliptic_ec) m) ((mtimes) 1 ((%elliptic_kc) m) ((mplus) 1 ((mtimes) 1 m)))) ((mexpt) ((mplus) 1 ((mtimes) 1 m)) 1) ((mexpt) m 1))) grad) (the same function as in .../maxima/5.9.1/src/ellipt.lisp modified by the "((rat) 1 2)" ) 2. load this file at the beginnig of a session. That's all. To see the error plot2d([(elliptic_kc(x+0.001)elliptic_kc(x))/0.001,diff(elliptic_kc(x),x)],[x,0.1,0.9]); the two curves are : a discrete derivative of elliptic_kc and the exact derivative.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1165488&group_id=4933 
From: SourceForge.net <noreply@so...>  20050317 01:14:05

Bugs item #1086880, was opened at 20041216 21:40 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1086880&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: for maxima5.9.11 Initial Comment: after rpm on RedHat9.0 #maxima #/usr/bin/maxima: unable to determine MAXIMA_PREFIX I don't know why it doesn't work. Give me a hand,THX!!  Comment By: Nobody/Anonymous (nobody) Date: 20050316 17:14 Message: Logged In: NO I have the same pb. with SuSE 8.1! Even after: export MAXIMA_PREFIX=/usr/share/maxima/5.9.1 and variations. Tricks welcome! kracklau@...  Comment By: Robert Dodier (robert_dodier) Date: 20041231 12:11 Message: Logged In: YES user_id=501686 To the author of the original bug report, if you're still watching  I'd like to help but I think more info is needed. I have a very similar system (RH Fedora) and I can run Maxima as installed from the maxima5.9.11 and maximaexeccmucl5.9.11 rpm's (downloaded from Sourceforge). So it looks like your environment is different. Maybe you can give some more details to help us get started.  Robert Dodier (robert_dodier@...)  Comment By: Nobody/Anonymous (nobody) Date: 20041217 20:32 Message: Logged In: NO [root@... root]# rpm Uvh maximaxmaxima5.9.11.i386.rpm error: Failed dependencies: tk is needed by maximaxmaxima5.9.11  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1086880&group_id=4933 
From: SourceForge.net <noreply@so...>  20050316 15:38:46

Bugs item #887025, was opened at 20040129 16:19 Message generated for change (Comment added) made by rongten You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=887025&group_id=4933 Category: Lisp Core Group: Fix for 5.9.0 Status: Open Resolution: None Priority: 5 Submitted By: Giammanco Raimondo (rongten) Assigned to: Nobody/Anonymous (nobody) Summary: linsolve/algsys erroneous behavior Initial Comment: The linsolve and algsys command are used to solve two different linear systems: ####################### kill (all)$ array(coe,4)$ list_eq : [coe[4]+coe[3]+coe[2]+coe[1] = 1, coe[2]*DY/(2*coeff_y)coe[1]*DY/(2*coeff_y)+coe[4]*DY/2+coe[3]*DY/2 = 0, coe[4]*DX/(2*coeff_x)+coe[3]*DX/(2*coeff_x)coe[2]*DX/(2*coeff_x) + coe[1]*DX/(2*coeff_x) = 0]$ list_un : [coe[1],coe[2],coe[3],coe[4]]$ sol : linsolve(list_eq,list_un)$ test : ratsimp(subst(sol,list_eq))$ display(test)$ sol_bis : (algsys(list_eq,list_un))[1]$ test_bis : ratsimp(subst(sol_bis,list_eq)); display(test_bis)$ array(coe_2,6)$ list_eq_2 : [coe_2[3]+coe_2[2]+coe_2[1] = 0,coe_2[3]*DXcoe_2[2]*DX+coe_2[6]+coe_2[5]+coe_2[4] = 1, coe_2[3]*DX^2/2+coe_2[2]*DX^2/2+coe_2[6]*DXcoe_2[5]*DX = 0, coe_2[3]*DX^3/6coe_2[2]*DX^3/6+coe_2[6]*DX^2/2+coe_2[5]*DX^2/2 = 0, coe_2[3]*DX^4/24+coe_2[2]*DX^4/24+coe_2[6]*DX^3/6coe_2[5]*DX^3/6 = 0]$ list_un_2 : [coe_2[1],coe_2[2],coe_2[3],coe_2[4],coe_2[5],coe_2[6]]$ sol_2 : linsolve(list_eq_2,list_un_2)$ test_2 : ratsimp(subst(sol_2,list_eq_2)); display(test_2)$ sol_2_bis : (algsys(list_eq_2,list_un_2))[1]$ test_2_bis : ratsimp(subst(sol_2_bis,list_eq_2)); display(test_2_bis)$ ##################### For the first system linsolve provide an erroneous result, while algsys gives the correct answer. For the second one, linsolve is correct, while algsys crashes with output: ############################## Typeerror in KERNEL::OBJECTNOTLISTERRORHANDLER: #:G4445 is not of type LIST ############################## This behavior has been reported to the maxima mailing list with the initial thread of "linsolve strange behavior" on 26 Jan 2004. According to a response to the thread: >>>> My guess is this is yet (another) bug related to expressions that are made into CRE expressions in some incorrect manner, jumbling the correspondence between internal generated symbols and external names. <<<< System Specs: Gentoo/GNU/Linux Kernel: 2.4.24 Glibc: glibc2.3.2 Gcc: gcc3.2.3 GCL: gcl2.5.2 CMUCL: cmucl18e MAXIMA:5.9.0 Reported the same problem on W2K, 5.9.0, GCL 2.5. Best Regards  >Comment By: Giammanco Raimondo (rongten) Date: 20050316 16:38 Message: Logged In: YES user_id=963123 Mr. Dodier, I am sorry, I realize now I was not clear in my previous message. Linsolve is not issuing any complaint, just returning the wrong result. When I read "Omitting the array declarations, the same solutions are found for the above examples." I thought that linsolve in your case was returning the correct answer. Since I have seen that in the Mailing List you pointed to another person that linsolve was rather buggy, pointing to this very same bug, I wanted to make sure that there was not a problem with my software configuration. I am picking back my code as we speak, and I will modify all the linsolve occurences to algsys. Since I have checks everywhere, I will able to report if there are additional problems with algsys. Best Regards  Comment By: Robert Dodier (robert_dodier) Date: 20050316 15:50 Message: Logged In: YES user_id=501686 To answer this question  "Now, when you suggented to remove the array definitions, you meant that without them you can retrieve the correct result for the first system even with linsolve?"  Yes. To be very specific, when I execute the following code (example 1 without the array declaration) "linsolve" returns without printing an error message in Maxima 5.9.1/cmucl (official release) and 5.9.1cvs/clisp. (The "linsolve" result is incorrect, but it doesn't complain about an error.) list_eq : [coe[4]+coe[3]+coe[2]+coe[1] = 1, coe[2]*DY/(2*coeff_y)coe[1]*DY/(2*coeff_y)+coe[4]*DY/2+coe[3]*DY/2 = 0, coe[4]*DX/(2*coeff_x)+coe[3]*DX/(2*coeff_x)coe[2]*DX/(2*coeff_x) + coe[1]*DX/(2*coeff_x) = 0]$ list_un : [coe[1],coe[2],coe[3],coe[4]]$ sol : linsolve(list_eq,list_un)$ I believe Maxima creates a hash array when it sees foo[x] and foo is not already known to be a list or array. Maybe that explains why linsolve is able to handle the coe elements. Raimondo, can you tell us what are the inputs which cause "linsolve" to complain about the undeclared array? All the best, Robert Dodier  Comment By: Giammanco Raimondo (rongten) Date: 20050316 12:50 Message: Logged In: YES user_id=963123 Mr. Dodier, I have tested the code in Maxima 5.9.1 official release with CLISP 2.33.2 (20040602); while the first system still gives wrong results with linsolve, but correct ones with algsys, at least the second system does not make algsys crash anymore. I think the crash was confirmed in the mailinglist, so somewhere along the way the problem got fixed. Now, when you suggented to remove the array definitions, you meant that without them you can retrieve the correct result for the first system even with linsolve? Without array definition, I still have error with gcl cmucl and clisp.  Comment By: Giammanco Raimondo (rongten) Date: 20050315 11:09 Message: Logged In: YES user_id=963123 It still matters, I have put aside the problem for the moment, so I cannot immediately jump back to it, but as soon I have a couple of hours to collect myself and check my maxima files I will look into it. I try to give my maxima codes the more structure I can, so that's why I use the array allocation. This snipped of code is taken from a larger one, where most likely I needed to define the array. But if it works without arrayness, I will try to implement it like that. I will report on that. In any case, I thank you for your input, and I am happy that this bug has not been forgotten. I have little time and insufficient background to follow the mailinglist, so I thank you again, Mr. Dodier. Best Regards  Comment By: Robert Dodier (robert_dodier) Date: 20050314 17:06 Message: Logged In: YES user_id=501686 Testing w/ Maxima 5.9.1 official release (cmucl) and 5.9.1 cvs version of a couple of days ago (clisp), I see the incorrect result from linsolve in example 1, but I do not see algsys crash in example 2. I don't know if it matters at this point, but I don't think the declaration of coe and coe_2 as arrays is necessary. Not necessary, because Maxima seems to treat coe[1], coe[2], etc., essentially as automatically generated names (i.e., the subscript is just a tag that is carried around with the name; the "arrayness" of it doesn't matter). Omitting the array declarations, the same solutions are found for the above examples.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=887025&group_id=4933 
From: SourceForge.net <noreply@so...>  20050316 14:50:22

Bugs item #887025, was opened at 20040129 08:19 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=887025&group_id=4933 Category: Lisp Core Group: Fix for 5.9.0 Status: Open Resolution: None Priority: 5 Submitted By: Giammanco Raimondo (rongten) Assigned to: Nobody/Anonymous (nobody) Summary: linsolve/algsys erroneous behavior Initial Comment: The linsolve and algsys command are used to solve two different linear systems: ####################### kill (all)$ array(coe,4)$ list_eq : [coe[4]+coe[3]+coe[2]+coe[1] = 1, coe[2]*DY/(2*coeff_y)coe[1]*DY/(2*coeff_y)+coe[4]*DY/2+coe[3]*DY/2 = 0, coe[4]*DX/(2*coeff_x)+coe[3]*DX/(2*coeff_x)coe[2]*DX/(2*coeff_x) + coe[1]*DX/(2*coeff_x) = 0]$ list_un : [coe[1],coe[2],coe[3],coe[4]]$ sol : linsolve(list_eq,list_un)$ test : ratsimp(subst(sol,list_eq))$ display(test)$ sol_bis : (algsys(list_eq,list_un))[1]$ test_bis : ratsimp(subst(sol_bis,list_eq)); display(test_bis)$ array(coe_2,6)$ list_eq_2 : [coe_2[3]+coe_2[2]+coe_2[1] = 0,coe_2[3]*DXcoe_2[2]*DX+coe_2[6]+coe_2[5]+coe_2[4] = 1, coe_2[3]*DX^2/2+coe_2[2]*DX^2/2+coe_2[6]*DXcoe_2[5]*DX = 0, coe_2[3]*DX^3/6coe_2[2]*DX^3/6+coe_2[6]*DX^2/2+coe_2[5]*DX^2/2 = 0, coe_2[3]*DX^4/24+coe_2[2]*DX^4/24+coe_2[6]*DX^3/6coe_2[5]*DX^3/6 = 0]$ list_un_2 : [coe_2[1],coe_2[2],coe_2[3],coe_2[4],coe_2[5],coe_2[6]]$ sol_2 : linsolve(list_eq_2,list_un_2)$ test_2 : ratsimp(subst(sol_2,list_eq_2)); display(test_2)$ sol_2_bis : (algsys(list_eq_2,list_un_2))[1]$ test_2_bis : ratsimp(subst(sol_2_bis,list_eq_2)); display(test_2_bis)$ ##################### For the first system linsolve provide an erroneous result, while algsys gives the correct answer. For the second one, linsolve is correct, while algsys crashes with output: ############################## Typeerror in KERNEL::OBJECTNOTLISTERRORHANDLER: #:G4445 is not of type LIST ############################## This behavior has been reported to the maxima mailing list with the initial thread of "linsolve strange behavior" on 26 Jan 2004. According to a response to the thread: >>>> My guess is this is yet (another) bug related to expressions that are made into CRE expressions in some incorrect manner, jumbling the correspondence between internal generated symbols and external names. <<<< System Specs: Gentoo/GNU/Linux Kernel: 2.4.24 Glibc: glibc2.3.2 Gcc: gcc3.2.3 GCL: gcl2.5.2 CMUCL: cmucl18e MAXIMA:5.9.0 Reported the same problem on W2K, 5.9.0, GCL 2.5. Best Regards  >Comment By: Robert Dodier (robert_dodier) Date: 20050316 07:50 Message: Logged In: YES user_id=501686 To answer this question  "Now, when you suggented to remove the array definitions, you meant that without them you can retrieve the correct result for the first system even with linsolve?"  Yes. To be very specific, when I execute the following code (example 1 without the array declaration) "linsolve" returns without printing an error message in Maxima 5.9.1/cmucl (official release) and 5.9.1cvs/clisp. (The "linsolve" result is incorrect, but it doesn't complain about an error.) list_eq : [coe[4]+coe[3]+coe[2]+coe[1] = 1, coe[2]*DY/(2*coeff_y)coe[1]*DY/(2*coeff_y)+coe[4]*DY/2+coe[3]*DY/2 = 0, coe[4]*DX/(2*coeff_x)+coe[3]*DX/(2*coeff_x)coe[2]*DX/(2*coeff_x) + coe[1]*DX/(2*coeff_x) = 0]$ list_un : [coe[1],coe[2],coe[3],coe[4]]$ sol : linsolve(list_eq,list_un)$ I believe Maxima creates a hash array when it sees foo[x] and foo is not already known to be a list or array. Maybe that explains why linsolve is able to handle the coe elements. Raimondo, can you tell us what are the inputs which cause "linsolve" to complain about the undeclared array? All the best, Robert Dodier  Comment By: Giammanco Raimondo (rongten) Date: 20050316 04:50 Message: Logged In: YES user_id=963123 Mr. Dodier, I have tested the code in Maxima 5.9.1 official release with CLISP 2.33.2 (20040602); while the first system still gives wrong results with linsolve, but correct ones with algsys, at least the second system does not make algsys crash anymore. I think the crash was confirmed in the mailinglist, so somewhere along the way the problem got fixed. Now, when you suggented to remove the array definitions, you meant that without them you can retrieve the correct result for the first system even with linsolve? Without array definition, I still have error with gcl cmucl and clisp.  Comment By: Giammanco Raimondo (rongten) Date: 20050315 03:09 Message: Logged In: YES user_id=963123 It still matters, I have put aside the problem for the moment, so I cannot immediately jump back to it, but as soon I have a couple of hours to collect myself and check my maxima files I will look into it. I try to give my maxima codes the more structure I can, so that's why I use the array allocation. This snipped of code is taken from a larger one, where most likely I needed to define the array. But if it works without arrayness, I will try to implement it like that. I will report on that. In any case, I thank you for your input, and I am happy that this bug has not been forgotten. I have little time and insufficient background to follow the mailinglist, so I thank you again, Mr. Dodier. Best Regards  Comment By: Robert Dodier (robert_dodier) Date: 20050314 09:06 Message: Logged In: YES user_id=501686 Testing w/ Maxima 5.9.1 official release (cmucl) and 5.9.1 cvs version of a couple of days ago (clisp), I see the incorrect result from linsolve in example 1, but I do not see algsys crash in example 2. I don't know if it matters at this point, but I don't think the declaration of coe and coe_2 as arrays is necessary. Not necessary, because Maxima seems to treat coe[1], coe[2], etc., essentially as automatically generated names (i.e., the subscript is just a tag that is carried around with the name; the "arrayness" of it doesn't matter). Omitting the array declarations, the same solutions are found for the above examples.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=887025&group_id=4933 
From: SourceForge.net <noreply@so...>  20050316 11:50:21

Bugs item #887025, was opened at 20040129 16:19 Message generated for change (Comment added) made by rongten You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=887025&group_id=4933 Category: Lisp Core Group: Fix for 5.9.0 Status: Open Resolution: None Priority: 5 Submitted By: Giammanco Raimondo (rongten) Assigned to: Nobody/Anonymous (nobody) Summary: linsolve/algsys erroneous behavior Initial Comment: The linsolve and algsys command are used to solve two different linear systems: ####################### kill (all)$ array(coe,4)$ list_eq : [coe[4]+coe[3]+coe[2]+coe[1] = 1, coe[2]*DY/(2*coeff_y)coe[1]*DY/(2*coeff_y)+coe[4]*DY/2+coe[3]*DY/2 = 0, coe[4]*DX/(2*coeff_x)+coe[3]*DX/(2*coeff_x)coe[2]*DX/(2*coeff_x) + coe[1]*DX/(2*coeff_x) = 0]$ list_un : [coe[1],coe[2],coe[3],coe[4]]$ sol : linsolve(list_eq,list_un)$ test : ratsimp(subst(sol,list_eq))$ display(test)$ sol_bis : (algsys(list_eq,list_un))[1]$ test_bis : ratsimp(subst(sol_bis,list_eq)); display(test_bis)$ array(coe_2,6)$ list_eq_2 : [coe_2[3]+coe_2[2]+coe_2[1] = 0,coe_2[3]*DXcoe_2[2]*DX+coe_2[6]+coe_2[5]+coe_2[4] = 1, coe_2[3]*DX^2/2+coe_2[2]*DX^2/2+coe_2[6]*DXcoe_2[5]*DX = 0, coe_2[3]*DX^3/6coe_2[2]*DX^3/6+coe_2[6]*DX^2/2+coe_2[5]*DX^2/2 = 0, coe_2[3]*DX^4/24+coe_2[2]*DX^4/24+coe_2[6]*DX^3/6coe_2[5]*DX^3/6 = 0]$ list_un_2 : [coe_2[1],coe_2[2],coe_2[3],coe_2[4],coe_2[5],coe_2[6]]$ sol_2 : linsolve(list_eq_2,list_un_2)$ test_2 : ratsimp(subst(sol_2,list_eq_2)); display(test_2)$ sol_2_bis : (algsys(list_eq_2,list_un_2))[1]$ test_2_bis : ratsimp(subst(sol_2_bis,list_eq_2)); display(test_2_bis)$ ##################### For the first system linsolve provide an erroneous result, while algsys gives the correct answer. For the second one, linsolve is correct, while algsys crashes with output: ############################## Typeerror in KERNEL::OBJECTNOTLISTERRORHANDLER: #:G4445 is not of type LIST ############################## This behavior has been reported to the maxima mailing list with the initial thread of "linsolve strange behavior" on 26 Jan 2004. According to a response to the thread: >>>> My guess is this is yet (another) bug related to expressions that are made into CRE expressions in some incorrect manner, jumbling the correspondence between internal generated symbols and external names. <<<< System Specs: Gentoo/GNU/Linux Kernel: 2.4.24 Glibc: glibc2.3.2 Gcc: gcc3.2.3 GCL: gcl2.5.2 CMUCL: cmucl18e MAXIMA:5.9.0 Reported the same problem on W2K, 5.9.0, GCL 2.5. Best Regards  >Comment By: Giammanco Raimondo (rongten) Date: 20050316 12:50 Message: Logged In: YES user_id=963123 Mr. Dodier, I have tested the code in Maxima 5.9.1 official release with CLISP 2.33.2 (20040602); while the first system still gives wrong results with linsolve, but correct ones with algsys, at least the second system does not make algsys crash anymore. I think the crash was confirmed in the mailinglist, so somewhere along the way the problem got fixed. Now, when you suggented to remove the array definitions, you meant that without them you can retrieve the correct result for the first system even with linsolve? Without array definition, I still have error with gcl cmucl and clisp.  Comment By: Giammanco Raimondo (rongten) Date: 20050315 11:09 Message: Logged In: YES user_id=963123 It still matters, I have put aside the problem for the moment, so I cannot immediately jump back to it, but as soon I have a couple of hours to collect myself and check my maxima files I will look into it. I try to give my maxima codes the more structure I can, so that's why I use the array allocation. This snipped of code is taken from a larger one, where most likely I needed to define the array. But if it works without arrayness, I will try to implement it like that. I will report on that. In any case, I thank you for your input, and I am happy that this bug has not been forgotten. I have little time and insufficient background to follow the mailinglist, so I thank you again, Mr. Dodier. Best Regards  Comment By: Robert Dodier (robert_dodier) Date: 20050314 17:06 Message: Logged In: YES user_id=501686 Testing w/ Maxima 5.9.1 official release (cmucl) and 5.9.1 cvs version of a couple of days ago (clisp), I see the incorrect result from linsolve in example 1, but I do not see algsys crash in example 2. I don't know if it matters at this point, but I don't think the declaration of coe and coe_2 as arrays is necessary. Not necessary, because Maxima seems to treat coe[1], coe[2], etc., essentially as automatically generated names (i.e., the subscript is just a tag that is carried around with the name; the "arrayness" of it doesn't matter). Omitting the array declarations, the same solutions are found for the above examples.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=887025&group_id=4933 
From: SourceForge.net <noreply@so...>  20050315 10:09:23

Bugs item #887025, was opened at 20040129 16:19 Message generated for change (Comment added) made by rongten You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=887025&group_id=4933 Category: Lisp Core Group: Fix for 5.9.0 Status: Open Resolution: None Priority: 5 Submitted By: Giammanco Raimondo (rongten) Assigned to: Nobody/Anonymous (nobody) Summary: linsolve/algsys erroneous behavior Initial Comment: The linsolve and algsys command are used to solve two different linear systems: ####################### kill (all)$ array(coe,4)$ list_eq : [coe[4]+coe[3]+coe[2]+coe[1] = 1, coe[2]*DY/(2*coeff_y)coe[1]*DY/(2*coeff_y)+coe[4]*DY/2+coe[3]*DY/2 = 0, coe[4]*DX/(2*coeff_x)+coe[3]*DX/(2*coeff_x)coe[2]*DX/(2*coeff_x) + coe[1]*DX/(2*coeff_x) = 0]$ list_un : [coe[1],coe[2],coe[3],coe[4]]$ sol : linsolve(list_eq,list_un)$ test : ratsimp(subst(sol,list_eq))$ display(test)$ sol_bis : (algsys(list_eq,list_un))[1]$ test_bis : ratsimp(subst(sol_bis,list_eq)); display(test_bis)$ array(coe_2,6)$ list_eq_2 : [coe_2[3]+coe_2[2]+coe_2[1] = 0,coe_2[3]*DXcoe_2[2]*DX+coe_2[6]+coe_2[5]+coe_2[4] = 1, coe_2[3]*DX^2/2+coe_2[2]*DX^2/2+coe_2[6]*DXcoe_2[5]*DX = 0, coe_2[3]*DX^3/6coe_2[2]*DX^3/6+coe_2[6]*DX^2/2+coe_2[5]*DX^2/2 = 0, coe_2[3]*DX^4/24+coe_2[2]*DX^4/24+coe_2[6]*DX^3/6coe_2[5]*DX^3/6 = 0]$ list_un_2 : [coe_2[1],coe_2[2],coe_2[3],coe_2[4],coe_2[5],coe_2[6]]$ sol_2 : linsolve(list_eq_2,list_un_2)$ test_2 : ratsimp(subst(sol_2,list_eq_2)); display(test_2)$ sol_2_bis : (algsys(list_eq_2,list_un_2))[1]$ test_2_bis : ratsimp(subst(sol_2_bis,list_eq_2)); display(test_2_bis)$ ##################### For the first system linsolve provide an erroneous result, while algsys gives the correct answer. For the second one, linsolve is correct, while algsys crashes with output: ############################## Typeerror in KERNEL::OBJECTNOTLISTERRORHANDLER: #:G4445 is not of type LIST ############################## This behavior has been reported to the maxima mailing list with the initial thread of "linsolve strange behavior" on 26 Jan 2004. According to a response to the thread: >>>> My guess is this is yet (another) bug related to expressions that are made into CRE expressions in some incorrect manner, jumbling the correspondence between internal generated symbols and external names. <<<< System Specs: Gentoo/GNU/Linux Kernel: 2.4.24 Glibc: glibc2.3.2 Gcc: gcc3.2.3 GCL: gcl2.5.2 CMUCL: cmucl18e MAXIMA:5.9.0 Reported the same problem on W2K, 5.9.0, GCL 2.5. Best Regards  >Comment By: Giammanco Raimondo (rongten) Date: 20050315 11:09 Message: Logged In: YES user_id=963123 It still matters, I have put aside the problem for the moment, so I cannot immediately jump back to it, but as soon I have a couple of hours to collect myself and check my maxima files I will look into it. I try to give my maxima codes the more structure I can, so that's why I use the array allocation. This snipped of code is taken from a larger one, where most likely I needed to define the array. But if it works without arrayness, I will try to implement it like that. I will report on that. In any case, I thank you for your input, and I am happy that this bug has not been forgotten. I have little time and insufficient background to follow the mailinglist, so I thank you again, Mr. Dodier. Best Regards  Comment By: Robert Dodier (robert_dodier) Date: 20050314 17:06 Message: Logged In: YES user_id=501686 Testing w/ Maxima 5.9.1 official release (cmucl) and 5.9.1 cvs version of a couple of days ago (clisp), I see the incorrect result from linsolve in example 1, but I do not see algsys crash in example 2. I don't know if it matters at this point, but I don't think the declaration of coe and coe_2 as arrays is necessary. Not necessary, because Maxima seems to treat coe[1], coe[2], etc., essentially as automatically generated names (i.e., the subscript is just a tag that is carried around with the name; the "arrayness" of it doesn't matter). Omitting the array declarations, the same solutions are found for the above examples.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=887025&group_id=4933 