Menu
▾
▴
[Maxima-bugs] [ maxima-Bugs-887025 ] linsolve/algsys erroneous behavior
|
From: SourceForge.net <no...@so...> - 2005-03-16 14:50:22
|
Bugs item #887025, was opened at 2004-01-29 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]*DX-coe_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]*DX-coe_2[5]*DX = 0, coe_2[3]*DX^3/6-coe_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/6-coe_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: ############################## Type-error in KERNEL::OBJECT-NOT-LIST-ERROR-HANDLER: #: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: glibc-2.3.2 Gcc: gcc-3.2.3 GCL: gcl-2.5.2 CMUCL: cmucl-18e 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: 2005-03-16 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: 2005-03-16 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 (2004-06-02); 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 mailing-list, 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: 2005-03-15 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 mailing-list, so I thank you again, Mr. Dodier. Best Regards ---------------------------------------------------------------------- Comment By: Robert Dodier (robert_dodier) Date: 2005-03-14 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 |