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

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 



1

2
(1) 
3
(4) 
4
(3) 
5
(1) 
6

7

8

9

10

11
(1) 
12

13
(1) 
14
(5) 
15
(1) 
16
(3) 
17
(3) 
18
(2) 
19

20

21
(3) 
22
(2) 
23
(3) 
24
(6) 
25
(3) 
26

27

28
(3) 
29

30
(3) 
31
(4) 


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 