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

_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 



1
(5) 
2
(1) 
3
(4) 
4
(4) 
5
(2) 
6
(1) 
7
(2) 
8
(3) 
9
(4) 
10
(5) 
11
(4) 
12
(8) 
13
(3) 
14

15
(6) 
16
(3) 
17
(5) 
18
(7) 
19
(1) 
20
(1) 
21
(2) 
22
(1) 
23
(1) 
24

25
(2) 
26
(12) 
27
(2) 
28
(1) 
29
(2) 
30
(11) 
31



From: SourceForge.net <noreply@so...>  20080730 23:01:59

Bugs item #1613390, was opened at 20061211 11:17 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1613390&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  Solving equations Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: find_root evaluates its arguments strangely Initial Comment: Someone asked a question on the mailing list about using the output of solve to do numerical root finding. we found that you could not use the output of solve directly in find_root because it evaluates its first argument strangely. Instead it required explicit evaluation with the '' operator. This behavior is very confusing even for relatively advanced maxima users, but especially for new users. example of the problem below: Transcript Maxima 5.10.0 http://maxima.sourceforge.net Using Lisp GNU Common Lisp (GCL) GCL 2.6.7 (aka GCL) (%i1) h1(s):=1/(1+tau[1]*s); h2(s):=1/(1+tau[2]*s); x(s):=1/s; tau[1]:33e6; tau[2]:33e6; eqn:first(solve(ilt(h1(s)*h2(s)*x(s),s,t)=0.1,t)); 1 (%o1) h1(s) :=  1 + tau s 1 (%i2) 1 (%o2) h2(s) :=  1 + tau s 2 (%i3) 1 (%o3) x(s) :=  s (%i4) (%o4) 3.2999999999999996E5 (%i5) (%o5) 3.2999999999999996E5 (%i6) `rat' replaced 3.2999999999999996E5 by 33//1000000 = 3.3000000000000003E5 `rat' replaced 0.9 by 9//10 = 0.9 1000000 t  33 297 %e  330 (%o6) t =  10000000 (%i7) find_root(%,t,0,2); Maxima encountered a Lisp error: Error in MACSYMATOPLEVEL [or a callee]: ((MEQUAL SIMP) $T ((MTIMES SIMP) ((RAT SIMP) 1 10000000) ((MPLUS SIMP) 330 ((MTIMES SIMP) 297 ((MEXPT SIMP) $%E ((MTIMES SIMP) ((RAT SIMP) 1000000 33) $T)))))) is not of type (OR RATIONAL LISP:FLOAT).  Comment By: Robert Dodier (robert_dodier) Date: 20080730 17:01 Message: Logged In: YES user_id=501686 Originator: NO Since a revision or two ago, find_root evaluates its arguments as an ordinary function. This particular example can't be solved by find_root(..., 0, 2) because the expression overflows at 2. However find_root(..., 0, 1/1000) succeeds and yields 1.7549783076857198E5. Closing this report as fixed.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1613390&group_id=4933 
From: SourceForge.net <noreply@so...>  20080730 23:01:46

Bugs item #1613390, was opened at 20061211 11:17 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1613390&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  Solving equations Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: find_root evaluates its arguments strangely Initial Comment: Someone asked a question on the mailing list about using the output of solve to do numerical root finding. we found that you could not use the output of solve directly in find_root because it evaluates its first argument strangely. Instead it required explicit evaluation with the '' operator. This behavior is very confusing even for relatively advanced maxima users, but especially for new users. example of the problem below: Transcript Maxima 5.10.0 http://maxima.sourceforge.net Using Lisp GNU Common Lisp (GCL) GCL 2.6.7 (aka GCL) (%i1) h1(s):=1/(1+tau[1]*s); h2(s):=1/(1+tau[2]*s); x(s):=1/s; tau[1]:33e6; tau[2]:33e6; eqn:first(solve(ilt(h1(s)*h2(s)*x(s),s,t)=0.1,t)); 1 (%o1) h1(s) :=  1 + tau s 1 (%i2) 1 (%o2) h2(s) :=  1 + tau s 2 (%i3) 1 (%o3) x(s) :=  s (%i4) (%o4) 3.2999999999999996E5 (%i5) (%o5) 3.2999999999999996E5 (%i6) `rat' replaced 3.2999999999999996E5 by 33//1000000 = 3.3000000000000003E5 `rat' replaced 0.9 by 9//10 = 0.9 1000000 t  33 297 %e  330 (%o6) t =  10000000 (%i7) find_root(%,t,0,2); Maxima encountered a Lisp error: Error in MACSYMATOPLEVEL [or a callee]: ((MEQUAL SIMP) $T ((MTIMES SIMP) ((RAT SIMP) 1 10000000) ((MPLUS SIMP) 330 ((MTIMES SIMP) 297 ((MEXPT SIMP) $%E ((MTIMES SIMP) ((RAT SIMP) 1000000 33) $T)))))) is not of type (OR RATIONAL LISP:FLOAT).  >Comment By: Robert Dodier (robert_dodier) Date: 20080730 17:01 Message: Logged In: YES user_id=501686 Originator: NO Since a revision or two ago, find_root evaluates its arguments as an ordinary function. This particular example can't be solved by find_root(..., 0, 2) because the expression overflows at 2. However find_root(..., 0, 1/1000) succeeds and yields 1.7549783076857198E5. Closing this report as fixed.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1613390&group_id=4933 
From: SourceForge.net <noreply@so...>  20080730 18:35:53

Bugs item #1977992, was opened at 20080529 11:45 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1977992&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  Limit Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: no limit calculation Initial Comment: /*wxMaxima 0.7.1 http://wxmaxima.sourceforge.netMaxima 5.12.0 http://maxima.sourceforge.netUsing Lisp GNU Common Lisp (GCL) GCL 2.6.7 (aka GCL)Distributed under the GNU Public License. See the file COPYING.Dedicated to the memory of William Schelter.This is a development version of Maxima. The function bug_report()provides bug reporting information. Maxima version: 5.12.0Maxima build date: 15:52 7/20/2007host type: i686pclinuxgnulispimplementationtype: GNU Common Lisp (GCL)lispimplementationversion: GCL 2.6.7 (%i1) abs(sin(x))/sqrt(1cos(x)); (%o1) abs(sin(x))/sqrt(1cos(x)) (%i2) limit(%o1, x, 0); (%o2) lim(abs(sin(x))/sqrt(1cos(x)),x,0) amedeo.maddalena@...  >Comment By: Raymond Toy (rtoy) Date: 20080730 14:35 Message: Logged In: YES user_id=28849 Originator: NO See also bug 104933 http://sourceforge.net/tracker/index.php?func=detail&aid=1978090&group_id=4933&atid=104933  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1977992&group_id=4933 
From: SourceForge.net <noreply@so...>  20080730 18:15:44

Bugs item #1981623, was opened at 20080601 23:39 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1981623&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 Private: No Submitted By: Satoshi Adachi (satoshi_adachi) Assigned to: Nobody/Anonymous (nobody) Summary: wrong sign of sqrt() Initial Comment: Dear Developers of Maxima, I found that sqrt() returns the incorrect expression that has the sign opposite to the ture expression when some certain argument is given to sqrt(). Namely, sqrt() interprets incorrectly the database that is prepared by assume(). Here is an demonstration program:  /* * wrong_sign_of_sqrt.maxima * * S.Adachi 2008/06/01 */ display2d:false; assume(x >= 0, x <= 1); correct_result_1:sqrt((x1)^2); correct_result_2:sqrt(1/(x1)^2); correct_result_3:sqrt(a*(x1)^2); incorrect_result_1:sqrt(a/(x1)^2); incorrect_result_2:sqrt(a^2/(x1)^2); incorrect_result_3:sqrt(x^2/(x1)^2); /* END */  The result of execution is as follows:  Maxima 5.14.0cvs http://maxima.sourceforge.net Using Lisp GNU Common Lisp (GCL) GCL 2.6.7 (aka GCL) Distributed under the GNU Public License. See the file COPYING. Dedicated to the memory of William Schelter. The function bug_report() provides bug reporting information. (%i1) batch(wrong_sign_of_sqrt.maxima) batching #p/Volumes/HFS+2/home/adachi/work/299/wrong_sign_of_sqrt.maxima (%i2) display2d : false (%o2) false (%i3) assume(x >= 0,x <= 1) (%o3) [x >= 0,x <= 1] (%i4) correct_result_1:sqrt((x1)^2) (%o4) 1x (%i5) correct_result_2:sqrt(1/(x1)^2) (%o5) 1/(1x) (%i6) correct_result_3:sqrt(a*(x1)^2) (%o6) sqrt(a)*(1x) (%i7) incorrect_result_1:sqrt(a/(x1)^2) (%o7) sqrt(a)/(x1) (%i8) incorrect_result_2:sqrt(a^2/(x1)^2) (%o8) abs(a)/(x1) (%i9) incorrect_result_3:sqrt(x^2/(x1)^2) (%o9) x/(x1) (%o10) "wrong_sign_of_sqrt.maxima"  I wonder why sqrt() returns the wrong expression if sqrt((x1)^2) appears in the denominator of some fraction in the argument that is more complex than some threshold (e.g. the numerator is not a simple number or something like that). I think that this is a very severe bug of sqrt() and the database that is prepared by assume(). This bug puts many user programs to the state producing many wrong results. Please fix this severe bug. Sincerely yours, Satoshi Adachi  >Comment By: Raymond Toy (rtoy) Date: 20080730 14:15 Message: Logged In: YES user_id=28849 Originator: NO FWIW, the code that handles this is simpexpt in simp.lisp. For the case of sqrt((x1)^2), the e1 tag is done, and the second cond case is executed. The result is correct in this case. However, for sqrt(1/(x1)^2), the e1 tag is also done, but the first cond case is executed because the (noneg (cadr gr)) returns nonnil. In the former case the noneg call returns NIL, which is correct because x1 is not negative. I don't know why the two different calls to noneg return different values for x1. NIL should be returned in each case because x <= 1. There is one difference, though. The z arg to simpexpt is NIL for the case that works and T for the case that is incorrect.  Comment By: Robert Dodier (robert_dodier) Date: 20080623 10:26 Message: Logged In: YES user_id=501686 Originator: NO Assign category = lisp core / simplification.  Comment By: Satoshi Adachi (satoshi_adachi) Date: 20080611 02:50 Message: Logged In: YES user_id=1953419 Originator: YES Thank you for your suggestion. But, your suggestion just forbids Maxima to simplify certain expressions in order not to produce wrong results. Is someone trying to fix this bug now? If not yet, I will read lisp source code in some future (maybe, several months later) to try to fix the problem...  Comment By: Barton Willis (willisbl) Date: 20080604 07:20 Message: Logged In: YES user_id=895922 Originator: NO As a workaround, you might try setting radexpand to false: (%i1) assume(0 < x, x <= 1)$ (%i2) sqrt(a/(x1)^2); (%o2) sqrt(a)/(x1) (%i3) sqrt(a/(x1)^2), radexpand : false; (%o3) sqrt(a/(x1)^2)  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1981623&group_id=4933 
From: SourceForge.net <noreply@so...>  20080730 18:14:10

Bugs item #2033006, was opened at 20080730 14:05 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2033006&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  Solving equations Group: None >Status: Pending >Resolution: Invalid Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Bug Initial Comment: (%i17) ratsimp(10*(3*6/2+5*6/2*6)=(1/2+56/3)*6) (%o17) 990=115 A miscalculation with parenthse. I am French. I do not speak English sorry. ENTITEINFORMATIQUE@...  >Comment By: Raymond Toy (rtoy) Date: 20080730 14:14 Message: Logged In: YES user_id=28849 Originator: NO You are missing a parenthesis. You probably wanted to say 10*(3*6/2+5*6/(2*6)) 5*6/2*6 is, as is normal, parsed as ((5*6)/2)*6, not (5*6)/(2*6). Marking this as pending/invalid. Please update this if this analysis is incorrect.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2033006&group_id=4933 
From: SourceForge.net <noreply@so...>  20080730 18:05:09

Bugs item #2033006, was opened at 20080730 18:05 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=2033006&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  Solving equations Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Bug Initial Comment: (%i17) ratsimp(10*(3*6/2+5*6/2*6)=(1/2+56/3)*6) (%o17) 990=115 A miscalculation with parenthse. I am French. I do not speak English sorry. ENTITEINFORMATIQUE@...  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2033006&group_id=4933 
From: SourceForge.net <noreply@so...>  20080730 15:43:20

Bugs item #2032827, was opened at 20080730 11:15 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2032827&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: Pending >Resolution: Invalid Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: maxima freeze on 8/*9; Initial Comment: When entering 8/*9; maxima is blocking.  >Comment By: Raymond Toy (rtoy) Date: 20080730 11:43 Message: Logged In: YES user_id=28849 Originator: NO /* is maxima's start of comment sequence. You have to close the comment with */. Marking this as pending/invalid. If this is not correct, please update this bug report.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2032827&group_id=4933 
From: SourceForge.net <noreply@so...>  20080730 15:15:17

Bugs item #2032827, was opened at 20080730 15:15 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=2032827&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: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: maxima freeze on 8/*9; Initial Comment: When entering 8/*9; maxima is blocking.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2032827&group_id=4933 
From: SourceForge.net <noreply@so...>  20080730 11:30:19

Bugs item #2029041, was opened at 20080726 19:18 Message generated for change (Comment added) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2029041&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 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: a*sqrt(2)/2 unsimplified Initial Comment: a*sqrt(2)/2 => 2^(1/2)*a whereas the normal display form is a/sqrt(2). Internal form is: ((MTIMES SIMP) ((MEXPT) 2 ((RAT SIMP) 1 2)) $A) ^^ no simp marker! expand(%,0,0) correctly gives: ((MTIMES SIMP) ((MEXPT SIMP) 2 ((RAT SIMP) 1 2)) $A) which displays correctly.  >Comment By: Barton Willis (willisbl) Date: 20080730 06:30 Message: Logged In: YES user_id=895922 Originator: NO By the way: (%i1) a : 1/sqrt(2)$ (%i2) b : 5*sqrt(2)/2$ (%i3) to_lisp(); No simp marker with add2: MAXIMA> (add2 (meval '$a) (meval '$b)) ((MTIMES SIMP) 6 ((MEXPT) 2 ((RAT SIMP) 1 2))) A simp marker with add: MAXIMA> (add (meval '$a) (meval '$b)) ((MTIMES SIMP) 6 ((MEXPT SIMP) 2 ((RAT SIMP) 1 2)))  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2029041&group_id=4933 
From: SourceForge.net <noreply@so...>  20080730 02:33:10

Bugs item #2032110, was opened at 20080729 21:12 Message generated for change (Comment added) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2032110&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  Solving equations Group: None Status: Open Resolution: None Priority: 7 Private: No Submitted By: Robert Dodier (robert_dodier) Assigned to: Nobody/Anonymous (nobody) Summary: spurious solution of trig equation, missed actual solution Initial Comment: (sin(x)  8*cos(x)*sin(x))*(sin(x)^2 + cos(x))  (2*cos(x)*sin(x)  sin(x))*(2*sin(x)^2 + 2*cos(x)^2  cos(x)); solve (%, x); `solve' is using arctrig functions to get a solution. Some solutions will be lost. => [x = %pi,x = %pi/2,x = 0] x = %pi and x = 0 are bona fide solutions, x = %pi/2 is spurious. A plot shows a root near 1.9 which find_root says is 1.9106.... Forwarded from sagedevel 20080729.  >Comment By: Barton Willis (willisbl) Date: 20080729 21:33 Message: Logged In: YES user_id=895922 Originator: NO Of course, Maxima should solve this equation without help. At least Maxima has the tools to solve it: (%o45) (sin(x)8*cos(x)*sin(x))*(sin(x)^2+cos(x))(2*cos(x)*sin(x)sin(x))*(2*sin(x)^2+2*cos(x)^2cos(x)) (%i46) exponentialize(%)$ (%i47) ratsubst(z, exp(%i*x),%)$ (%i48) solve(%,z)$ (%i49) subst(exp(%i*x),z,%)$ (%i50) map(lambda([s], solve(s,x)),%); (%o50) [[x=%i*log((2*sqrt(2)*%i)/31/3)],[x=%i*log((2*sqrt(2)*%i)/31/3)],[x=0],[x=%i*log(1)]]  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2032110&group_id=4933 
From: SourceForge.net <noreply@so...>  20080730 02:12:33

Bugs item #2032110, was opened at 20080729 20:12 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=2032110&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  Solving equations Group: None Status: Open Resolution: None Priority: 7 Private: No Submitted By: Robert Dodier (robert_dodier) Assigned to: Nobody/Anonymous (nobody) Summary: spurious solution of trig equation, missed actual solution Initial Comment: (sin(x)  8*cos(x)*sin(x))*(sin(x)^2 + cos(x))  (2*cos(x)*sin(x)  sin(x))*(2*sin(x)^2 + 2*cos(x)^2  cos(x)); solve (%, x); `solve' is using arctrig functions to get a solution. Some solutions will be lost. => [x = %pi,x = %pi/2,x = 0] x = %pi and x = 0 are bona fide solutions, x = %pi/2 is spurious. A plot shows a root near 1.9 which find_root says is 1.9106.... Forwarded from sagedevel 20080729.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2032110&group_id=4933 