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

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 







1
(29) 
2
(6) 
3

4
(26) 
5
(3) 
6
(10) 
7
(25) 
8
(20) 
9

10
(21) 
11
(10) 
12
(3) 
13
(10) 
14
(7) 
15
(1) 
16
(1) 
17
(1) 
18

19
(15) 
20

21
(1) 
22
(7) 
23
(10) 
24
(10) 
25

26
(1) 
27
(1) 
28
(5) 
29
(26) 
30

31
(30) 





From: SourceForge.net <noreply@so...>  20060723 19:25:19

Bugs item #889922, was opened at 20040203 13:14 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=889922&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Lisp Core Group: None >Status: Closed >Resolution: Fixed Priority: 1 Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: linnew.lisp broken Initial Comment: The file src/linnew.lisp is a "new linear algebra" package. For matrices larger that 9 by 9, it's broken. (There is a switch in the package that handles something differently for matrices that are 10 by 10 or larger.) (C1) h[i,j] := 1/(i + j 1)$ (C2) m : genmatrix(h,10,10)$ (C3) tminverse(m); Error: Too many args (10) to aref Fast links are on: do (si::usefastlinks nil) for debugging Error signalled by MACSYMATOPLEVEL. Broken at AREF. Type :H for Help. MAXIMA>>:q (C4) m : genmatrix(h,3,3)$ (C5) tminverse(m); (big mess deleted ... it's okay.) I don't think linnew.lisp belongs in the src directory. Barton  >Comment By: Robert Dodier (robert_dodier) Date: 20060723 13:25 Message: Logged In: YES user_id=501686 src/linnew.lisp moved to archive/src/ and Makefile.am, maxima.system, *depends.mk updated to remove linnew.lisp from list of files. After this, make and make install succeed and run_testsuite reports no unexpected errors. The Maximavisible functions in linnew.lisp (tmlin, tmlinsolve, tmnewdet, and tminverse) aren't mentioned in any others files. In particular they are undocumented and there are no tests in the test suite files, so nothing else to clean up. Closing this report as fixed.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=889922&group_id=4933 
From: SourceForge.net <noreply@so...>  20060723 18:54:30

Bugs item #902694, was opened at 20040223 06:58 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=902694&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: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: equal(ind,ind) should be false; also und, NaN Initial Comment: is(ind=ind) => true OK, is/= is syntactic is(equal(ind,ind)) => true NO! is/equal should be semantic Unlike IEEE floating point, Maxima carefully distinguishes syntactic and semantic equality tests. Clearly everything, including ind / und / IEEE_NaN, is syntactically equal to itself. However, not everything is semantically equal to itself. In particular, equal(und,und), equal(ind,ind), and equal(IEEE_NaN, IEEE_NaN) (when we support it) should be false.  >Comment By: Robert Dodier (robert_dodier) Date: 20060723 12:54 Message: Logged In: YES user_id=501686 Observed in 5.9.3cvs. Incidentally I'm not convinced these are errors. A useful definition of Maxima equal(a,b) is that substituting a for b in any expression yields an equivalent expression. Certainly when a and b are the same symbol, that's true. To forestall two criticisms which I can see coming: (1) ratsimp(a  b) = 0 might be suggested as an alternate definition of equal(a,b). That's too narrow, as there are interesting expressions for which a  b isn't defined. E.g. a is a set and b is a matrix. (2) equal(a,a) => true for all symbols a isn't consistent with IEEE floating point. Well, I've given up on IEEE floating point special values in Maxima because Common Lisp doesn't require them, and some implementations (Clisp, GCL at least) don't support them.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=902694&group_id=4933 
From: SourceForge.net <noreply@so...>  20060723 18:41:47

Bugs item #902290, was opened at 20040222 14: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=902290&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  Simplification Group: None Status: Open Resolution: None >Priority: 8 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: Nonsimplifying nounforms: abs, realpart, carg, etc. Initial Comment: declare(q,complex)$ expr: rectform(q) => 'realpart(q) + %i * 'imagpart(q) subst(1,q,expr) => 'realpart(1) + %i * 'imagpart(1) (no simplification!)  Several Maxima mathematical functions do not simplify correctly as nounforms. As a general rule, simplifications should happen with all mathematicalfunction nounforms. For example, sin(0) == 'sin(0) == cos(%pi/2) == 'cos(%pi/2) == 0 But the following don't simplify: 'abs(1) 'realpart(1) 'imagpart(1) 'carg(1) Note also that cabs/carg are not treated symmetrically. cabs is an expressionmanipulating function (like factor) which can return the mathematical operator abs. But there is no mathematical operator corresponding to the expressionmanipuating function carg (cf also bug 620246).  >Comment By: Robert Dodier (robert_dodier) Date: 20060723 12:41 Message: Logged In: YES user_id=501686 Observed in 5.9.3cvs. Also increasing the priority  this is a very weak point for Maxima.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=902290&group_id=4933 
From: SourceForge.net <noreply@so...>  20060723 18:38:56

Bugs item #900860, was opened at 20040219 20:53 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=900860&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  Simplification Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: Simplifications involving abs Initial Comment: abs(q)/q^2 and q^2/abs(q) currently don't simplify. These should simplify to 1/abs(q) and abs(q). This is especially useful since things like sqrt(q^2) simplify to abs(q). It would be even nicer if GCD understood this case, but I can understand that that would be harder, e.g. gcd(abs(q)+q^2,abs(q)) => 1+abs(q) This seems practically justifiable; is there any theoretical reason it might not be justifiable?  >Comment By: Robert Dodier (robert_dodier) Date: 20060723 12:38 Message: Logged In: YES user_id=501686 Observed in 5.9.3cvs.  Comment By: Stavros Macrakis (macrakis) Date: 20050221 13:03 Message: Logged In: YES user_id=588346 abs(x)^(2*n+1) should simplify to x^(2*n)*abs(x), extending the current case where abs(x)^(2*n) simplifies to x^(2*n). This simple change makes (e.g.) abs(x)^3/x simplify with no further work.  Comment By: Stavros Macrakis (macrakis) Date: 20040222 14:16 Message: Logged In: YES user_id=588346 With declare(q,complex), q/abs(q) should presumably simplify to carg(q), except for the problems with that (620246, 902290). Assuming definition by continuity, q/abs(q) and carg (q) even have the same 'value' (ind) at q=0. With *real* r, r/abs(r) = signum(r) *except* at r=0, where the first is undefined, but the second is welldefined (=0).  Comment By: Barton Willis (willisbl) Date: 20040222 13:35 Message: Logged In: YES user_id=895922 When 'domain' is complex or q has been declared complex, the simplification abs(q) / q^2 > 1/abs(q) shouldn't happen. Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=900860&group_id=4933 
From: SourceForge.net <noreply@so...>  20060723 18:38:06

Bugs item #893638, was opened at 20040209 12:50 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=893638&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  Assume Group: None Status: Open Resolution: None Priority: 3 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: declare evenfun/oddfun Initial Comment: declare(f,evenfun) declare(f,oddfun) => Inconsistent Declaration: ...  an error. But if f(x):=0 it is both an evenfun (i.e. f(x)=f(x)) and an oddfun (f(x)=f(x)). So this should be a warning, e.g. Warning: f is being declared as both an evenfun and an oddfun; therefore f is the constant function 0.  >Comment By: Robert Dodier (robert_dodier) Date: 20060723 12:38 Message: Logged In: YES user_id=501686 Observed in 5.9.3cvs.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=893638&group_id=4933 
From: SourceForge.net <noreply@so...>  20060723 18:37:06

Bugs item #893633, was opened at 20040209 12:38 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=893633&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: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: depends(a,[b,b,b]) Initial Comment: depends(a,[b,b,b]); diff(a,b) => 3 * (da/db) NO! The correct result is (da/db). The original depends should either have given an error, or been synonymous with depends(a,b,a,b,a,b) which is synonymous with ( depends(a,b), depends(a,b), depends (a,b) ). Originally reported by Dan Stanger on Maxima list (02/09/2004 07:02 AM)  Comment By: Barton Willis (willisbl) Date: 20040212 10:54 Message: Logged In: YES user_id=895922 Depends should check for some other things too: (C1) depends(f,x*y); (D1) [f(x y)] (C2) depends(f,x); (D2) [f(x)] (C3) diff(f,x); Error: Frame stack overflow. Fast links are on: do (si::usefastlinks nil) for debugging Error signalled by OR. Broken at DEPENDS. Type :H for Help. MAXIMA>> I think the second argument to depends should be required to be a symbol. For anything more complex than a symbol, I'd suggest a user try pdiff. The same holds for gradef: (C4) gradef(f, x < y, g); (D4) f (C5) diff(f,x); (D5) g*'DIFF(x < y,x,1) Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=893633&group_id=4933 
From: SourceForge.net <noreply@so...>  20060723 18:02:18

Bugs item #887639, was opened at 20040130 07:45 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=887639&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: listarray when use_fast_arrays : true Initial Comment: Outputs (D2) and (D4) are okay. But the list (D6) should not contain 'true'. (C1) a[0] : 1$ (C2) listarray(a); (D2) [1] (C3) use_fast_arrays : true$ (C4) listarray(a); (D4) [1] (C5) b[0] : 1$ (C6) listarray(b); (D6) [TRUE, 1] (C7) build_info(); Maxima version: 5.9.0 Maxima build date: 19:10 2/9/2003 host type: i686pcmingw32 lispimplementationtype: Kyoto Common Lisp lispimplementationversion: GCL25.0 Barton  Comment By: Stavros Macrakis (macrakis) Date: 20040202 16:12 Message: Logged In: YES user_id=588346 use_fast_arrays:true has lots of problems: use_fast_arrays: false$ a: [1,2]$ a[3]$ => error OK a[3]: 5$ => error OK a[1,1] => error OK Now compare with the use_fast_arrays: true case. use_fast_arrays: true$ b: [1,2]$ b[3] => error OK b[3]: 5$ => no error ??? b[3] => error ??? b => [1,2] ??? setting b[3] didn't give an error, but has no effect on b c[1]: 5$ c => #<hashtable 234234234> (ridiculous internal thingy prints out) limit(c,x,inf) => internal error, limit doesn't know about arrays d[1,1]:5$ d[1] => false ????  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=887639&group_id=4933 
From: SourceForge.net <noreply@so...>  20060723 17:52:44

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 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.0 >Status: Closed >Resolution: Works For Me 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: 20060723 11:52 Message: Logged In: YES user_id=501686 Two examples are given in the original report. (1) linsolve incorrect, algsys correct. (2) linsolve correct, algsys => internal error. Problem (2) is not observed in 5.9.1 (as reported in other comments) and 5.9.3cvs. Problem (1) is still observed in 5.9.3cvs. Closing this report as "works for me" to resolve (2). I've opened a separate report (1527404) for (1).  Comment By: Giammanco Raimondo (rongten) Date: 20050316 08: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 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...>  20060723 17:50:22

Bugs item #1527404, was opened at 20060723 11:50 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=1527404&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: Robert Dodier (robert_dodier) Assigned to: Nobody/Anonymous (nobody) Summary: linsolve incorrect result Initial Comment: Maxima 5.9.3cvs. linsolve returns an incorrect result for this example (adapted from bug report 887025). array(A,4)$ list_eq : [A[4]+A[3]+A[2]+A[1] = 1, A[2]*DY/(2*coeff_y)A[1]*DY/(2*coeff_y)+A[4]*DY/2+A[3]*DY/2 = 0, A[4]*DX/(2*coeff_x)+A[3]*DX/(2*coeff_x)A[2]*DX/(2*coeff_x) + A[1]*DX/(2*coeff_x) = 0]; list_un : [A[1],A[2],A[3],A[4]]; soln_linsolve : linsolve(list_eq,list_un); => [A[1] = ((2*%r1+1)*DX+2*%r11)/(2*DX+2), A[2] = (2*%r11)/2,A[3] = (%r1*DX+%r11)/(DX+1), A[4] = %r1] Then ratsimp(subst(soln_linsolve,list_eq)); => [1 = 1,(DXcoeff_y)*DY/(2*coeff_y*DX+2*coeff_y) = 0, 0 = 0]  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1527404&group_id=4933 
From: SourceForge.net <noreply@so...>  20060723 17:15:20

Bugs item #886418, was opened at 20040128 12:15 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=886418&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  Assume Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: featurep believes that most things are complex Initial Comment: featurep believes that most things are complex; some examples (C1) featurep([],complex); (D1) TRUE (C2) featurep(a < b, complex); (D2) TRUE (C3) build_info(); Maxima version: 5.9.0 Maxima build date: 19:10 2/9/2003 host type: i686pcmingw32 lispimplementationtype: Kyoto Common Lisp lispimplementationversion: GCL25.0 What featurep should in these (and many other cases) isn't clear... Barton  >Comment By: Robert Dodier (robert_dodier) Date: 20060723 11:15 Message: Logged In: YES user_id=501686 All examples  featurep([],complex); featurep(a < b, complex); featurep(asin(x),real);  same behavior in 5.9.3cvs.  Comment By: Barton Willis (willisbl) Date: 20040129 12:18 Message: Logged In: YES user_id=895922 Yes, make that all! A related problem  Function: FEATUREP (a,f) attempts to determine whether the object a has the feature f on the basis of the facts in the current data base. If so, it returns TRUE, else FALSE. But consider: (C1) featurep(asin(x),real); Is (x  1) (x + 1) positive, negative, or zero? neg; (D1) TRUE This is inconsistent with the documentation  featurep is using facts outside the current database! The next case is just plain wrong; my answers imply x == 1. And asin(1) is real. (C2) featurep(asin(x),real); Is (x  1) (x + 1) positive, negative, or zero? zero; Is x positive or negative? pos; (D2) FALSE (C3) Barton  Comment By: Stavros Macrakis (macrakis) Date: 20040129 11:06 Message: Logged In: YES user_id=588346 Not most things, all things!: (defmfun $featurep (e ind) (cond ... ((eq ind '$complex) t) ...))  Comment By: Barton Willis (willisbl) Date: 20040128 13:25 Message: Logged In: YES user_id=895922 I forgot to login; so that comments get sent to me, I'll attach this comment. Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=886418&group_id=4933 