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

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 





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

11
(11) 
12
(2) 
13
(1) 
14
(8) 
15
(1) 
16
(3) 
17
(4) 
18
(5) 
19
(14) 
20
(5) 
21
(5) 
22
(15) 
23
(16) 
24
(1) 
25
(3) 
26
(3) 
27

28
(2) 



From: SourceForge.net <noreply@so...>  20070219 22:59:21

Bugs item #1646761, was opened at 20070128 23:08 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1646761&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: limit atanh @ 1 / 1 all wrong... Initial Comment: limit(atanh(x),x,1) => minf NO This should be complex infinity (INFINITY) since for x>1, the imagpart = %pi/2 limit(2*atanh(x),x,1) => ERROR: The number 1 isn't in the domain of atanh Well, that's why I'm trying to take the limit! limit( atanh(a1)log(a)/2 , a, 0) => domain error but as taylor will show you, it is finite: log(2)/2. Same problems at 1.  >Comment By: Raymond Toy (rtoy) Date: 20070219 17:59 Message: Logged In: YES user_id=28849 Originator: NO Oh, the last limit can't be taken because HYPEREX1 doesn't bind $logarc (or $exponentialize) to T anymore. The comment says the complex plane isn't handled right. However, binding $logarc to t would allow maxima to compute the limit correctly: limit(atanh(a1)log(a)/2,a,0,'plus),logarc:true; > log(2)/2  Comment By: Raymond Toy (rtoy) Date: 20070219 17:54 Message: Logged In: YES user_id=28849 Originator: NO For the first limit do you really mean minf? Mine says inf. A change to simplim%atanh to take an extra arg indicating the direction and the corresponding change in simplimit to pass the extra arg fixes this issue. Maxima returns infinity for the first limit above. For the second, the message comes from domainerror. Changing noerrsub to bind $errormsg to nil gets rid of the message. Don't know what to do about the third limit.  Comment By: Barton Willis (willisbl) Date: 20070130 09:41 Message: Logged In: YES user_id=895922 Originator: NO By the way, for atanh(1.0) or atanh(1.0), GCL prints a silly message: (%i45) atanh(1.0); Maxima encountered a Lisp error: Error in PROGN [or a callee]: The argument, 1.0, is a logarithmic singularity. Don't be foolish, GLS.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1646761&group_id=4933 
From: SourceForge.net <noreply@so...>  20070219 22:54:31

Bugs item #1646761, was opened at 20070128 23:08 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1646761&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: limit atanh @ 1 / 1 all wrong... Initial Comment: limit(atanh(x),x,1) => minf NO This should be complex infinity (INFINITY) since for x>1, the imagpart = %pi/2 limit(2*atanh(x),x,1) => ERROR: The number 1 isn't in the domain of atanh Well, that's why I'm trying to take the limit! limit( atanh(a1)log(a)/2 , a, 0) => domain error but as taylor will show you, it is finite: log(2)/2. Same problems at 1.  >Comment By: Raymond Toy (rtoy) Date: 20070219 17:54 Message: Logged In: YES user_id=28849 Originator: NO For the first limit do you really mean minf? Mine says inf. A change to simplim%atanh to take an extra arg indicating the direction and the corresponding change in simplimit to pass the extra arg fixes this issue. Maxima returns infinity for the first limit above. For the second, the message comes from domainerror. Changing noerrsub to bind $errormsg to nil gets rid of the message. Don't know what to do about the third limit.  Comment By: Barton Willis (willisbl) Date: 20070130 09:41 Message: Logged In: YES user_id=895922 Originator: NO By the way, for atanh(1.0) or atanh(1.0), GCL prints a silly message: (%i45) atanh(1.0); Maxima encountered a Lisp error: Error in PROGN [or a callee]: The argument, 1.0, is a logarithmic singularity. Don't be foolish, GLS.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1646761&group_id=4933 
From: SourceForge.net <noreply@so...>  20070219 21:39:52

Bugs item #1661490, was opened at 20070216 07:51 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1661490&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  Integration Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: An integral gives a wrong result. Initial Comment: integrate (exp((a+(%i)*b)*x^2),x,inf,inf); with a>0 and b>0 gives: sqrt(%pi/b) instead of sqrt(%pi/(a+%i*b)) Maxima version: 5.11.0Maxima build date: 22:25 12/26/2006host type: i686pcmingw32lispimplementationtype: GNU Common Lisp (GCL)lispimplementationversion: GCL 2.6.8  >Comment By: Raymond Toy (rtoy) Date: 20070219 16:39 Message: Logged In: YES user_id=28849 Originator: NO Fixed. Result (once you answer all the questions with positive), is equivalent to sqrt(%pi)*rectform(1/sqrt(a+%i*b)).  Comment By: Raymond Toy (rtoy) Date: 20070219 12:55 Message: Logged In: YES user_id=28849 Originator: NO This is caused by the routine GGR in defint.lisp. It is meant to handle the case x^n*exp(k*x^n) where k is purely imaginary or purely real. Fixing this (by having GGR decline to return a result) causes maxima to use DINTEXP to evaluate this integral, and the result is the same, except it appears as if rectform had been called.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1661490&group_id=4933 
From: SourceForge.net <noreply@so...>  20070219 21:35:40

Bugs item #1663704, was opened at 20070219 13:28 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1663704&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Raymond Toy (rtoy) Assigned to: Nobody/Anonymous (nobody) Summary: integrate(sin(r*x)^7/x^4,x,0,inf) > r^3*false Initial Comment: Maxima returns r^3*false for the result. That's wrong.  >Comment By: Raymond Toy (rtoy) Date: 20070219 16:34 Message: Logged In: YES user_id=28849 Originator: YES Fixed by returning the integral.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1663704&group_id=4933 
From: SourceForge.net <noreply@so...>  20070219 18:47:14

Bugs item #1663530, was opened at 20070219 08:39 Message generated for change (Comment added) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1663530&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: Share Libraries Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Barton Willis (willisbl) Summary: lu condition number Initial Comment: (%i2) lu_factor(matrix([1]),floatfield); (%o2) [matrix([1.0]),[1],floatfield,0.0,0.0] The final two members of the list in (%o2) should be lower and upper bounds for the infinity norm condition number of the matrix. I think there are several 'off by one' bugs in lu.lisp. As far as I know, these bugs only cause trouble with the lu condition number bounds. (The regression tests for LU don't test the LU condition number.)  >Comment By: Barton Willis (willisbl) Date: 20070219 12:47 Message: Logged In: YES user_id=895922 Originator: YES Fixed by lu.lisp CVS r 1.18.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1663530&group_id=4933 
From: SourceForge.net <noreply@so...>  20070219 18:28:21

Bugs item #1663704, was opened at 20070219 13: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=1663704&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Raymond Toy (rtoy) Assigned to: Nobody/Anonymous (nobody) Summary: integrate(sin(r*x)^7/x^4,x,0,inf) > r^3*false Initial Comment: Maxima returns r^3*false for the result. That's wrong.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1663704&group_id=4933 
From: SourceForge.net <noreply@so...>  20070219 17:55:30

Bugs item #1661490, was opened at 20070216 07:51 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1661490&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  Integration Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: An integral gives a wrong result. Initial Comment: integrate (exp((a+(%i)*b)*x^2),x,inf,inf); with a>0 and b>0 gives: sqrt(%pi/b) instead of sqrt(%pi/(a+%i*b)) Maxima version: 5.11.0Maxima build date: 22:25 12/26/2006host type: i686pcmingw32lispimplementationtype: GNU Common Lisp (GCL)lispimplementationversion: GCL 2.6.8  >Comment By: Raymond Toy (rtoy) Date: 20070219 12:55 Message: Logged In: YES user_id=28849 Originator: NO This is caused by the routine GGR in defint.lisp. It is meant to handle the case x^n*exp(k*x^n) where k is purely imaginary or purely real. Fixing this (by having GGR decline to return a result) causes maxima to use DINTEXP to evaluate this integral, and the result is the same, except it appears as if rectform had been called.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1661490&group_id=4933 
From: SourceForge.net <noreply@so...>  20070219 15:34:46

Bugs item #1654183, was opened at 20070207 09:31 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1654183&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  Integration Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: integrate(x^2 / (1+x^6)^(3/2),x); Initial Comment: (%i2) integrate(x^2 / (1+x^6)^(3/2),x); (%o2) abs(x)^3/(3*sqrt(x^6+1)) (%i3) integrate(x^2 / (1+x^6)^(3/2),x,1,1); (%o3) 0 (%o2) should be x^3/(3*sqrt(x^6+1)), and (%o3) should be sqrt(2) / 3.  >Comment By: Raymond Toy (rtoy) Date: 20070219 10:34 Message: Logged In: YES user_id=28849 Originator: NO Suggested change applied. I couldn't find any case where setting radexpand to 'all would produce a wrong result. Fixed in sin.lisp, rev 1.22.  Comment By: Raymond Toy (rtoy) Date: 20070214 14:53 Message: Logged In: YES user_id=28849 Originator: NO Binding $radexpand to '$all in chebyf fixes this particular issue. I only did it around the substitution part and not over the entire function. I think this is reasonably safe, but it would be useful if someone else can look at the code to see if this is really valid in all cases. ((integerp2 (add2* r1 r2)) (return (substint (let (($radexpand '$all)) ; HERE! ;; Setting $radexpand to $all here gets rid of ;; ABS in the subtitution. I think that's ok in ;; this case. (subliss w '((mexpt) ((mquotient) ((mplus) c1 ((mtimes) c2 ((mexpt) var q))) ((mexpt) var q)) ((mquotient) 1 d1)))) var (ratint (simplify (subliss w  Comment By: Raymond Toy (rtoy) Date: 20070212 11:58 Message: Logged In: YES user_id=28849 Originator: NO integrate(x^2/(1+x^6)^(3/2),x),radexpand:all; > x^3/3/sqrt(1+x^6) works too.  Comment By: Barton Willis (willisbl) Date: 20070211 18:56 Message: Logged In: YES user_id=895922 Originator: YES Maybe all that is needed to set domain to complex: (%i12) x^2/(1+x^6)^(3/2); (%o12) x^2/(x^6+1)^(3/2) (%i13) integrate(%,x), domain : complex; (%o13) sqrt(x^6)/(3*sqrt(x^6+1))  Comment By: Raymond Toy (rtoy) Date: 20070211 17:19 Message: Logged In: YES user_id=28849 Originator: NO As far as I can tell, maxima computes this integral using the function chebyf in sin.lisp. I think this function, in this case, uses the substitution x^6 = z to transform the integral to 1/6*(1+z)^(3/2)/sqrt(z). Maxima returns 1/3/sqrt((1+z)/z). The inverse substitution z = x^(1/6) results in the form %o2 above. Not sure how to get rid of that.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1654183&group_id=4933 
From: SourceForge.net <noreply@so...>  20070219 14:52:32

Bugs item #1663537, was opened at 20070219 08: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=1663537&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: Share Libraries Group: None Status: Open Resolution: None Priority: 3 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: newton & listconstvars Initial Comment: I think newton should set listconstvars to false: (%i22) newton(x^2  %i, 1  %i/2), listconstvars : true; (%o22) x^2 (%i23) newton(x^2  %i, 1  %i/2), listconstvars : false; (%o23) 7.071067828336269b1*%i+7.071067804126268b1 Or maybe newton should require a var argument.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1663537&group_id=4933 
From: SourceForge.net <noreply@so...>  20070219 14:50:12

Bugs item #1663536, was opened at 20070219 08: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=1663536&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: newton sometines very slow Initial Comment: Fast: (%i19) newton(x^2  %i, 1  %i/5); (%o19) 7.071067853080116b1*%i+7.071067813155526b1 So slow I don't know that it ever finishes: (%i20) newton(x^2  %i, 1  %i);  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1663536&group_id=4933 
From: SourceForge.net <noreply@so...>  20070219 14:42:20

Bugs item #1663399, was opened at 20070219 05:47 Message generated for change (Comment added) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1663399&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Vadim V. Zhytnikov (vvzhy) Assigned to: Nobody/Anonymous (nobody) Summary: solve/algsys bug Initial Comment: sys:[b2 + a1 = r2, a1 * b2 = r3, a2 * b2 + a3 * b1 = r4, a3 * b2 + a5 + r4 = d5, a5 * b1 = 0]; solve(sys, [a1, a2, a3, a5, r2, r3, r4, b1, b2]); result in Maxima encountered a Lisp error: Error in MACSYMATOPLEVEL [or a callee]: 0 is not of type LIST. Reported by Laurent Couraud  >Comment By: Barton Willis (willisbl) Date: 20070219 08:42 Message: Logged In: YES user_id=895922 Originator: NO With algebraic : true, we get a different error: (%i7) solve(sys, [a1, a2, a3, a5, r2, r3, r4, b1, b2]), algebraic : true; `algsys' cannot solve  system too complicated.  an error. To debug this try debugmode(true);  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1663399&group_id=4933 
From: SourceForge.net <noreply@so...>  20070219 14:39:46

Bugs item #1663530, was opened at 20070219 08:39 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=1663530&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: Share Libraries Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Barton Willis (willisbl) Summary: lu condition number Initial Comment: (%i2) lu_factor(matrix([1]),floatfield); (%o2) [matrix([1.0]),[1],floatfield,0.0,0.0] The final two members of the list in (%o2) should be lower and upper bounds for the infinity norm condition number of the matrix. I think there are several 'off by one' bugs in lu.lisp. As far as I know, these bugs only cause trouble with the lu condition number bounds. (The regression tests for LU don't test the LU condition number.)  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1663530&group_id=4933 
From: SourceForge.net <noreply@so...>  20070219 11:47:56

Bugs item #1663399, was opened at 20070219 11:47 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=1663399&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Vadim V. Zhytnikov (vvzhy) Assigned to: Nobody/Anonymous (nobody) Summary: solve/algsys bug Initial Comment: sys:[b2 + a1 = r2, a1 * b2 = r3, a2 * b2 + a3 * b1 = r4, a3 * b2 + a5 + r4 = d5, a5 * b1 = 0]; solve(sys, [a1, a2, a3, a5, r2, r3, r4, b1, b2]); result in Maxima encountered a Lisp error: Error in MACSYMATOPLEVEL [or a callee]: 0 is not of type LIST. Reported by Laurent Couraud  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1663399&group_id=4933 
From: SourceForge.net <noreply@so...>  20070219 11:27:58

Bugs item #1663385, was opened at 20070219 11:27 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1663385&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Vadim V. Zhytnikov (vvzhy) Assigned to: Nobody/Anonymous (nobody) Summary: declare multiplicative  wrong simplification Initial Comment: (%i1) declare(p,additive,p, multiplicative); (%o1) done (%i2) p(a*b); (%o2) p(a) p(b) (%i3) p(c+a*b); (%o3) p(c) + p(a b) (%i4) ev(%); (%o4) p(c) + p(a) p(b) (%i5) %o3 must be like %o4. This simplification bug was first noticed by Barton Willis  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1663385&group_id=4933 