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

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 



1

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

8

9

10
(2) 
11
(3) 
12
(18) 
13
(11) 
14
(4) 
15
(25) 
16

17

18

19

20

21

22

23

24
(9) 
25

26
(17) 
27
(19) 
28
(2) 
29
(4) 
30
(2) 
31
(10) 


From: SourceForge.net <noreply@so...>  20060831 23:46:21

Bugs item #1374700, was opened at 20051206 13:41 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1374700&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 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: integrate((1+tan(x)^2)/tan(x),x); Initial Comment: Nonreal result  >Comment By: Raymond Toy (rtoy) Date: 20060831 19:46 Message: Logged In: YES user_id=28849 Yes, replacing all occurrences of b in schatc.lisp with bb makes clisp behave like cmucl. But we can see now how to get log(tan(x)) as the answer. We can move case 5 before case 4. Not exactly sure what impact that will have on the algorithm.  Comment By: Raymond Toy (rtoy) Date: 20060831 19:41 Message: Logged In: YES user_id=28849 FWIW, maxima uses trigint to do this integral, and when it gets to case 4, it tries to match the integrand. With cmucl, it matches, but with clisp it doesn't. In rat1, b is NIL in clisp, but is 'cos* in cmucl. b is declared special, and is set to 'cos* in case 4, just before the call to m2, which calls rat1. But note that coeffpt in schatc.lisp also uses the variable b. There is probably some confusion with b here. I am guessing the b in coeffpt is not the global special variablle b in sin.lisp.  Comment By: Raymond Toy (rtoy) Date: 20060831 16:40 Message: Logged In: YES user_id=28849 Maxima 5.9.3.99rc2 and cmucl 200609 says log(sin(x))  log(sin(x)^21)/2 But the same maxima with clisp 2.35 says log(tan(x)). I don't know why.  Comment By: Robert Dodier (robert_dodier) Date: 20060814 22:46 Message: Logged In: YES user_id=501686 Maxima 5.9.3.99rc1 / Clisp 2.38: integrate((1+tan(x)^2)/tan(x),x); => log(tan(x)) which seems right. Maybe if someone else wants to weigh in here. If someone else agrees this result is OK, we can close this report.  Comment By: Raymond Toy (rtoy) Date: 20060213 13:07 Message: Logged In: YES user_id=28849 This integral is transformed to cos(x)/sin(x)*(sin(x)^2/cos(x)^2+1). Then maxima uses the substitution y=sin(x) to get 1/y*(y^2/(1y^2)+1. However: integrate(1/y*(y^2/(1y^2)+1),y) > log(y)log(y^21)/2. But integrate(expand(1/y*(y^2/(1y^2)+1)),y) > log(y)log(1y^2)/2. The former is wrong for our integration problem; the latter would produce the desired answer.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1374700&group_id=4933 
From: SourceForge.net <noreply@so...>  20060831 23:41:29

Bugs item #1374700, was opened at 20051206 13:41 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1374700&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 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: integrate((1+tan(x)^2)/tan(x),x); Initial Comment: Nonreal result  >Comment By: Raymond Toy (rtoy) Date: 20060831 19:41 Message: Logged In: YES user_id=28849 FWIW, maxima uses trigint to do this integral, and when it gets to case 4, it tries to match the integrand. With cmucl, it matches, but with clisp it doesn't. In rat1, b is NIL in clisp, but is 'cos* in cmucl. b is declared special, and is set to 'cos* in case 4, just before the call to m2, which calls rat1. But note that coeffpt in schatc.lisp also uses the variable b. There is probably some confusion with b here. I am guessing the b in coeffpt is not the global special variablle b in sin.lisp.  Comment By: Raymond Toy (rtoy) Date: 20060831 16:40 Message: Logged In: YES user_id=28849 Maxima 5.9.3.99rc2 and cmucl 200609 says log(sin(x))  log(sin(x)^21)/2 But the same maxima with clisp 2.35 says log(tan(x)). I don't know why.  Comment By: Robert Dodier (robert_dodier) Date: 20060814 22:46 Message: Logged In: YES user_id=501686 Maxima 5.9.3.99rc1 / Clisp 2.38: integrate((1+tan(x)^2)/tan(x),x); => log(tan(x)) which seems right. Maybe if someone else wants to weigh in here. If someone else agrees this result is OK, we can close this report.  Comment By: Raymond Toy (rtoy) Date: 20060213 13:07 Message: Logged In: YES user_id=28849 This integral is transformed to cos(x)/sin(x)*(sin(x)^2/cos(x)^2+1). Then maxima uses the substitution y=sin(x) to get 1/y*(y^2/(1y^2)+1. However: integrate(1/y*(y^2/(1y^2)+1),y) > log(y)log(y^21)/2. But integrate(expand(1/y*(y^2/(1y^2)+1)),y) > log(y)log(1y^2)/2. The former is wrong for our integration problem; the latter would produce the desired answer.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1374700&group_id=4933 
From: SourceForge.net <noreply@so...>  20060831 20:40:42

Bugs item #1374700, was opened at 20051206 13:41 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1374700&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 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: integrate((1+tan(x)^2)/tan(x),x); Initial Comment: Nonreal result  >Comment By: Raymond Toy (rtoy) Date: 20060831 16:40 Message: Logged In: YES user_id=28849 Maxima 5.9.3.99rc2 and cmucl 200609 says log(sin(x))  log(sin(x)^21)/2 But the same maxima with clisp 2.35 says log(tan(x)). I don't know why.  Comment By: Robert Dodier (robert_dodier) Date: 20060814 22:46 Message: Logged In: YES user_id=501686 Maxima 5.9.3.99rc1 / Clisp 2.38: integrate((1+tan(x)^2)/tan(x),x); => log(tan(x)) which seems right. Maybe if someone else wants to weigh in here. If someone else agrees this result is OK, we can close this report.  Comment By: Raymond Toy (rtoy) Date: 20060213 13:07 Message: Logged In: YES user_id=28849 This integral is transformed to cos(x)/sin(x)*(sin(x)^2/cos(x)^2+1). Then maxima uses the substitution y=sin(x) to get 1/y*(y^2/(1y^2)+1. However: integrate(1/y*(y^2/(1y^2)+1),y) > log(y)log(y^21)/2. But integrate(expand(1/y*(y^2/(1y^2)+1)),y) > log(y)log(1y^2)/2. The former is wrong for our integration problem; the latter would produce the desired answer.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1374700&group_id=4933 
From: SourceForge.net <noreply@so...>  20060831 20:14:39

Bugs item #1547769, was opened at 20060828 05:36 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1547769&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 Submitted By: Ralf Stephan (rwst) Assigned to: Nobody/Anonymous (nobody) Summary: integrate(sqrt(x^3/(2*ax)),x,0,2*a); ==> internal error Initial Comment: (%i1) integrate(sqrt(x^3/(2*ax)),x,0,2*a); Is a positive, negative, or zero? pos; `sign' called on an imaginary argument: %i  an error. Quitting. To debug this try debugmode(true); (%i2) AFAIK, this indefinite integral should have a definite value.  >Comment By: Raymond Toy (rtoy) Date: 20060831 16:14 Message: Logged In: YES user_id=28849 Maxima can't evaluate the integral, but it can evaluate the equivalent integral integrate(sqrt(x^3)/sqrt(2*ax),x,0,2*a). The problem is bata0 doesn't recognize that sqrt(x^3/(2*ax)) has the form x^kk*(b*x^n+a)^l.  Comment By: Raymond Toy (rtoy) Date: 20060830 17:12 Message: Logged In: YES user_id=28849 I tried this with CVS maxima. I don't get the error; the integral is returned. Not sure if maxima should be able to evaluate this integral or not, though. It currently can't.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1547769&group_id=4933 
From: SourceForge.net <noreply@so...>  20060831 19:15:16

Bugs item #1528607, was opened at 20060725 13:19 Message generated for change (Settings changed) made by andrei_dubovik You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1528607&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 Submitted By: andrei_dubovik (andrei_dubovik) Assigned to: Nobody/Anonymous (nobody) Summary: limit(a^x,x,inf) can't solve for a : abs(a) < 1 Initial Comment: limit(a^x,x,inf) can't solve for x : abs(x) < 1. Consider the following session (there is also a screenshot for easy reading): (%i1) limit((1/2)^x,x,inf); (%o1) 0 (%i2) limit((2/3)^x,x,inf); x ( 2) (%o2) limit  x > inf x 3 (%i3) limit((1/%pi)^x,x,inf); (%o3) und (%i4) declare(x,integer); (%o4) done (%i5) limit((1/%pi)^x,x,inf); (%o5) 0 (%i6) limit((2/%pi)^x,x,inf); x ( 2) (%o6) limit  x > inf x  >Comment By: andrei_dubovik (andrei_dubovik) Date: 20060725 13:20 Message: Logged In: YES user_id=1560916 I meant in title, of course, for a : abs(a) < 1.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1528607&group_id=4933 
From: SourceForge.net <noreply@so...>  20060831 18:56:04

Bugs item #1504505, was opened at 20060611 18:24 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1504505&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 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: integrate( 1/(x^81),x,0,1/2) => internal error Initial Comment: integrate( 1/(x^81), x, 0, 1/2 ) => Divison by 0 Smaller exponents don't cause problem. Same problem with gcd: spmod. Using the indefiniteintegral at the limits works fine. 5.9.3 gcl windows  Comment By: Raymond Toy (rtoy) Date: 20060831 14:55 Message: Logged In: YES user_id=28849 What is happening, partially, is that maxima wants to convert the given integral to an equivalent integral from 0 to infinity. I don't know why we get an internal error for 1/(x^81). However, we can work around the problem by changing the order in methodradicalpoly. The third cond clause could be moved up one more, just before the second clause containing the calls to ratp and ratfnt (which converts the finite integral to an infinite integral). What this does is try to compute the indefinite integral, and if we succeed, we just substitute the limits in. Then all of the examples here work, and the test suite passes.  Comment By: Stavros Macrakis (macrakis) Date: 20060621 01:24 Message: Logged In: YES user_id=588346 integrate(1/(x^4+1),x,0,1/2) same problem. This is a subproblem (by partfrac) of previous problem.  Comment By: Robert Dodier (robert_dodier) Date: 20060620 23:38 Message: Logged In: YES user_id=501686 Assign category (Lisp Core  Integration). I looked at this a little bit but I can't tell what's going on. trace output from :lisp (trace polyform methodbylimits initialanalysis) suggests something interesting is happening but I can't tell what.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1504505&group_id=4933 
From: SourceForge.net <noreply@so...>  20060831 18:49:06

Bugs item #1504505, was opened at 20060611 15:24 Message generated for change (Comment added) made by macrakis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1504505&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 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: integrate( 1/(x^81),x,0,1/2) => internal error Initial Comment: integrate( 1/(x^81), x, 0, 1/2 ) => Divison by 0 Smaller exponents don't cause problem. Same problem with gcd: spmod. Using the indefiniteintegral at the limits works fine. 5.9.3 gcl windows  Comment By: Stavros Macrakis (macrakis) Date: 20060620 22:24 Message: Logged In: YES user_id=588346 integrate(1/(x^4+1),x,0,1/2) same problem. This is a subproblem (by partfrac) of previous problem.  Comment By: Robert Dodier (robert_dodier) Date: 20060620 20:38 Message: Logged In: YES user_id=501686 Assign category (Lisp Core  Integration). I looked at this a little bit but I can't tell what's going on. trace output from :lisp (trace polyform methodbylimits initialanalysis) suggests something interesting is happening but I can't tell what.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1504505&group_id=4933 
From: SourceForge.net <noreply@so...>  20060831 16:19:18

Bugs item #1528607, was opened at 20060725 13:19 Message generated for change (Settings changed) made by andrei_dubovik You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1528607&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 Submitted By: andrei_dubovik (andrei_dubovik) Assigned to: Nobody/Anonymous (nobody) Summary: limit(a^x,x,inf) can't solve for a : abs(a) < 1 Initial Comment: limit(a^x,x,inf) can't solve for x : abs(x) < 1. Consider the following session (there is also a screenshot for easy reading): (%i1) limit((1/2)^x,x,inf); (%o1) 0 (%i2) limit((2/3)^x,x,inf); x ( 2) (%o2) limit  x > inf x 3 (%i3) limit((1/%pi)^x,x,inf); (%o3) und (%i4) declare(x,integer); (%o4) done (%i5) limit((1/%pi)^x,x,inf); (%o5) 0 (%i6) limit((2/%pi)^x,x,inf); x ( 2) (%o6) limit  x > inf x  >Comment By: andrei_dubovik (andrei_dubovik) Date: 20060725 13:20 Message: Logged In: YES user_id=1560916 I meant in title, of course, for a : abs(a) < 1.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1528607&group_id=4933 
From: SourceForge.net <noreply@so...>  20060831 14:02:12

Bugs item #1531688, was opened at 20060731 07:52 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1531688&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: 3 Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: hgfred([ ], [ ], 0) Initial Comment: All the following should simplify to 1: hgfred([3,4],[7],0) > unsimplified mess that is also wrong hgfred([1,1],[2],0) > division by zero hgfred([1,1],[1],0) > 1 (OK) Barton  >Comment By: Raymond Toy (rtoy) Date: 20060831 10:02 Message: Logged In: YES user_id=28849 I don't think hgfred was ever intended for numerical evaluation. Should it? limit(hgfred(foo,x),x,0) seems to produce the correct result.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1531688&group_id=4933 
From: SourceForge.net <noreply@so...>  20060831 01:40:38

Bugs item #1548643, was opened at 20060829 11:09 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1548643&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 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: limit with abs: tag LIMIT is undefined Initial Comment: ex:abs(sqrt(11/x)1) limit(ex,x,0); Maxima encountered a Lisp error: Error in PROGN [or a callee]: The tag LIMIT is undefined.  >Comment By: Raymond Toy (rtoy) Date: 20060830 21:40 Message: Logged In: YES user_id=28849 In mabssubst, near the very beginning, there's the line (equal ($imagpart (limit d var val 'think)) 0) Replace the call to limit with (let ((v (limitcatch d var val))) (unless v (throw 'mabs '$und)) v) This causes the given test to return "und". Not sure if that's what we want to return, but certainly better than an error. The testsuite passes with this change, FWIW.  Comment By: Raymond Toy (rtoy) Date: 20060830 19:49 Message: Logged In: YES user_id=28849 Ok. This is caused by mabssubst calling limit, but forgetting that limit might throw to the tag LIMIT. Not exactly sure what the right solution would be. Perhaps in that case mabssubst should, itself, throw 'mabs 'retn?  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1548643&group_id=4933 
From: SourceForge.net <noreply@so...>  20060830 23:49:14

Bugs item #1548643, was opened at 20060829 11:09 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1548643&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 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: limit with abs: tag LIMIT is undefined Initial Comment: ex:abs(sqrt(11/x)1) limit(ex,x,0); Maxima encountered a Lisp error: Error in PROGN [or a callee]: The tag LIMIT is undefined.  >Comment By: Raymond Toy (rtoy) Date: 20060830 19:49 Message: Logged In: YES user_id=28849 Ok. This is caused by mabssubst calling limit, but forgetting that limit might throw to the tag LIMIT. Not exactly sure what the right solution would be. Perhaps in that case mabssubst should, itself, throw 'mabs 'retn?  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1548643&group_id=4933 
From: SourceForge.net <noreply@so...>  20060830 21:12:56

Bugs item #1547769, was opened at 20060828 05:36 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1547769&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 Submitted By: Ralf Stephan (rwst) Assigned to: Nobody/Anonymous (nobody) Summary: integrate(sqrt(x^3/(2*ax)),x,0,2*a); ==> internal error Initial Comment: (%i1) integrate(sqrt(x^3/(2*ax)),x,0,2*a); Is a positive, negative, or zero? pos; `sign' called on an imaginary argument: %i  an error. Quitting. To debug this try debugmode(true); (%i2) AFAIK, this indefinite integral should have a definite value.  >Comment By: Raymond Toy (rtoy) Date: 20060830 17:12 Message: Logged In: YES user_id=28849 I tried this with CVS maxima. I don't get the error; the integral is returned. Not sure if maxima should be able to evaluate this integral or not, though. It currently can't.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1547769&group_id=4933 
From: SourceForge.net <noreply@so...>  20060829 15:16:04

Bugs item #1483121, was opened at 20060506 16:47 Message generated for change (Comment added) made by macrakis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1483121&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 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: limit(1/x, x, infinity) Initial Comment: (%i15) limit(1/x, x, infinity); (%o15) 0 (%i16) limit(1/x, x, infinity); (%o16) 1/infinity (should it be 0!) Please include the following build information with your bug report:  Maxima version: 5.9.3 Maxima build date: 0:52 3/20/2006 host type: i686pcmingw32 lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.7   >Comment By: Stavros Macrakis (macrakis) Date: 20060829 11:16 Message: Logged In: YES user_id=588346 It's very simple. The third argument to limit can only be a finite number, inf, minf, inf, or infinity. Limit doesn't accept other values. So, for example, limit(2*inf) => inf, but limit(x,x,2*inf) gives 2*inf, because limit interprets that as a finite value. I suppose as a matter of userfriendliness, we could have limit first apply the singleargument version of limit to its third argument. But that might encourage misunderstandings.  Comment By: Robert Dodier (robert_dodier) Date: 20060515 20:08 Message: Logged In: YES user_id=501686 Given that limit (1/infinity) => 0, the result limit (1/x, x, infinity) => 1/infinity certainly looks like a bug to me (i.e., can't be explained away by invoking the inf/infinity distinction).  Comment By: Barton Willis (willisbl) Date: 20060513 17:30 Message: Logged In: YES user_id=895922 infinity is the complex infinity. Maybe you wanted to do limit(1/x,x,minf). Notice that limit(infinity) > infinity and limit(1/infinity) > 0. Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1483121&group_id=4933 
From: SourceForge.net <noreply@so...>  20060829 15:09:32

Bugs item #1548643, was opened at 20060829 11:09 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=1548643&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 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: limit with abs: tag LIMIT is undefined Initial Comment: ex:abs(sqrt(11/x)1) limit(ex,x,0); Maxima encountered a Lisp error: Error in PROGN [or a callee]: The tag LIMIT is undefined.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1548643&group_id=4933 
From: SourceForge.net <noreply@so...>  20060829 14:58:56

Bugs item #719968, was opened at 20030411 18:36 Message generated for change (Comment added) made by macrakis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=719968&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: No SIMP function Initial Comment: The info file documents a function SIMP, which "causes exp to be simplified regardless of the setting of the switch SIMP which inhibits simplification if FALSE". But there is no such function defined. It is also not clear if this is supposed to force resimplification of the whole expression, or only the part without SIMP flags.  >Comment By: Stavros Macrakis (macrakis) Date: 20060829 10:58 Message: Logged In: YES user_id=588346 expand(...,0,0) calls ?resimplify. The difference is that expand does a specrepcheck. Since almost no simplification flags apply to specreps, it is probably appropriate to do the specrepcheck. You could argue that if the input is in CRE form, you should just rerat it to get the effect of changed keepfloat, ratfac, etc. flags, but I think that's too complicated; and you can always call rat to rerat. ex:log(a*b) => log(a b) rex:rat(ex)$ logexpand:all$ ex => log(a b) rex => /R/ log(a b) expand(ex) => log(b) + log(a) ?resimplify(ex) => log(b) + log(a) expand(rex) => log(b) + log(a) ?resimplify(rex) => /R/ log(a b)  Comment By: Robert Dodier (robert_dodier) Date: 20060829 10:34 Message: Logged In: YES user_id=501686 There exists a Lisp function RESIMPLIFY  How does expand(foo, 0, 0) differ from ?resimplify(foo) ?  Comment By: Stavros Macrakis (macrakis) Date: 20060828 10:48 Message: Logged In: YES user_id=588346 Robert, you suggest that we expose Simplifya. But Simplifya is called automatically by meval every time you evaluate anything. You might think it was useful when simp=false. But when simp=false, it has no effect. I think what you want is a "resimplify" function, which would resimplify all subparts of an expression with current settings. As I've mentioned in email before, this already exists, though admittedly in a very obscure form: expand(...,0,0). It would be reasonable to have a userfriendly name for it, e.g. resimplify.  Comment By: Robert Dodier (robert_dodier) Date: 20050410 23:23 Message: Logged In: YES user_id=501686 The description of the simp function went away some months ago (late 2004, I think). So the documentation of a nonexistent function is no longer a problem. It makes me wonder, though, if we to expose SIMPLIFYA somehow or something like that. If the answer is "no", let's close this bug report.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=719968&group_id=4933 
From: SourceForge.net <noreply@so...>  20060829 14:34:43

Bugs item #719968, was opened at 20030411 16:36 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=719968&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: No SIMP function Initial Comment: The info file documents a function SIMP, which "causes exp to be simplified regardless of the setting of the switch SIMP which inhibits simplification if FALSE". But there is no such function defined. It is also not clear if this is supposed to force resimplification of the whole expression, or only the part without SIMP flags.  >Comment By: Robert Dodier (robert_dodier) Date: 20060829 08:34 Message: Logged In: YES user_id=501686 There exists a Lisp function RESIMPLIFY  How does expand(foo, 0, 0) differ from ?resimplify(foo) ?  Comment By: Stavros Macrakis (macrakis) Date: 20060828 08:48 Message: Logged In: YES user_id=588346 Robert, you suggest that we expose Simplifya. But Simplifya is called automatically by meval every time you evaluate anything. You might think it was useful when simp=false. But when simp=false, it has no effect. I think what you want is a "resimplify" function, which would resimplify all subparts of an expression with current settings. As I've mentioned in email before, this already exists, though admittedly in a very obscure form: expand(...,0,0). It would be reasonable to have a userfriendly name for it, e.g. resimplify.  Comment By: Robert Dodier (robert_dodier) Date: 20050410 21:23 Message: Logged In: YES user_id=501686 The description of the simp function went away some months ago (late 2004, I think). So the documentation of a nonexistent function is no longer a problem. It makes me wonder, though, if we to expose SIMPLIFYA somehow or something like that. If the answer is "no", let's close this bug report.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=719968&group_id=4933 
From: SourceForge.net <noreply@so...>  20060828 14:48:17

Bugs item #719968, was opened at 20030411 18:36 Message generated for change (Comment added) made by macrakis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=719968&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: No SIMP function Initial Comment: The info file documents a function SIMP, which "causes exp to be simplified regardless of the setting of the switch SIMP which inhibits simplification if FALSE". But there is no such function defined. It is also not clear if this is supposed to force resimplification of the whole expression, or only the part without SIMP flags.  >Comment By: Stavros Macrakis (macrakis) Date: 20060828 10:48 Message: Logged In: YES user_id=588346 Robert, you suggest that we expose Simplifya. But Simplifya is called automatically by meval every time you evaluate anything. You might think it was useful when simp=false. But when simp=false, it has no effect. I think what you want is a "resimplify" function, which would resimplify all subparts of an expression with current settings. As I've mentioned in email before, this already exists, though admittedly in a very obscure form: expand(...,0,0). It would be reasonable to have a userfriendly name for it, e.g. resimplify.  Comment By: Robert Dodier (robert_dodier) Date: 20050410 23:23 Message: Logged In: YES user_id=501686 The description of the simp function went away some months ago (late 2004, I think). So the documentation of a nonexistent function is no longer a problem. It makes me wonder, though, if we to expose SIMPLIFYA somehow or something like that. If the answer is "no", let's close this bug report.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=719968&group_id=4933 
From: SourceForge.net <noreply@so...>  20060828 09:36:41

Bugs item #1547769, was opened at 20060828 11:36 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=1547769&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 Submitted By: Ralf Stephan (rwst) Assigned to: Nobody/Anonymous (nobody) Summary: integrate(sqrt(x^3/(2*ax)),x,0,2*a); ==> internal error Initial Comment: (%i1) integrate(sqrt(x^3/(2*ax)),x,0,2*a); Is a positive, negative, or zero? pos; `sign' called on an imaginary argument: %i  an error. Quitting. To debug this try debugmode(true); (%i2) AFAIK, this indefinite integral should have a definite value.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1547769&group_id=4933 
From: SourceForge.net <noreply@so...>  20060827 20:30:58

Bugs item #1547584, was opened at 20060827 15:23 Message generated for change (Comment added) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1547584&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: is(equal([a],[a,b]) Initial Comment: is(equal([a],[a,b])) signals an error (from fullmap). That's not right. It should evaluate to false. Barton  >Comment By: Barton Willis (willisbl) Date: 20060827 15:30 Message: Logged In: YES user_id=895922 Another problem with is(equal(...)): assume(equal(a,aa)); is(equal(f(a), f(aa)) > error or unknown depending on prederror (should be true), is(equal(a < b, [a,b]) > error or unknown depending on prederror (should be false) and ....  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1547584&group_id=4933 
From: SourceForge.net <noreply@so...>  20060827 20:23:42

Bugs item #1547584, was opened at 20060827 15:23 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=1547584&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: is(equal([a],[a,b]) Initial Comment: is(equal([a],[a,b])) signals an error (from fullmap). That's not right. It should evaluate to false. Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1547584&group_id=4933 
From: SourceForge.net <noreply@so...>  20060827 06:45:20

Bugs item #531466, was opened at 20020318 11:09 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=531466&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  Floating point Group: None Status: Open Resolution: None Priority: 5 Submitted By: Daniel Lemire (lemire) Assigned to: Nobody/Anonymous (nobody) Summary: float needs to be eval. with numer Initial Comment: See below... we'd like to see "float(exp(exp(2)))" evaluated to 1618.177991912654. (C1) float(exp(exp(2))); 2 %E (D1) 2.718281828459045 (C2) float(exp(exp(2))),numer; (D2) 1618.177991912654 (C3)  Comment By: Robert Dodier (robert_dodier) Date: 20060326 16:50 Message: Logged In: YES user_id=501686 More of the same: [ 609464 ] 1+%e,numer and %e^%e,numer  Comment By: Robert Dodier (robert_dodier) Date: 20060326 16:46 Message: Logged In: YES user_id=501686 See also [ 586688 ] numer and float problem. (more of the same, with different examples).  Comment By: Robert Dodier (robert_dodier) Date: 20060326 16:18 Message: Logged In: YES user_id=501686 For the record, same behavior for all examples in Maxima 5.9.3. (%i10) float(exp(exp(2))); (%o10) 2.718281828459045^%e^2 (%i11) float(exp(exp(2))), numer; (%o11) 1618.177991912654 (%i12) float(%pi^%pi); (%o12) 3.141592653589793^%pi (%i13) float(2^%pi); (%o13) 2.0^%pi (%i14) float((%e+%pi)^2); (%o14) 34.33812894536713  Comment By: Stavros Macrakis (macrakis) Date: 20040223 16:51 Message: Logged In: YES user_id=588346 More cases: float(%pi^%pi)=> 3.14^%pi; float(2^%pi) =>2.0^%pi; but float((%e+%pi)^2) => 34.3. The intent is to avoid floating powers of symbolic objects. For example, you don't want float(x^2)=>x^2.0 or float(x^ (1/3)) => x^0.333. But obviously this has been taken too far. If we can get a numerical result for the whole expression, we should (2^%e, %e^2, even %e^%pi). Numer and float just aren't very well thoughtout.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=531466&group_id=4933 
From: SourceForge.net <noreply@so...>  20060827 06:45:19

Bugs item #609464, was opened at 20020914 21:18 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=609464&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  Floating point Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: 1+%e,numer and %e^%e,numer Initial Comment: %e^%e,numer does not evaluate numerically to 15.15... as it should, it simply returns the simplified expression %e^%e.  Comment By: Robert Dodier (robert_dodier) Date: 20060626 12:17 Message: Logged In: YES user_id=501686 Still present in 5.9.3.  Comment By: Stavros Macrakis (macrakis) Date: 20040323 10:48 Message: Logged In: YES user_id=588346 cf. bug 531466 re float(exp(exp(2)))  Comment By: Stavros Macrakis (macrakis) Date: 20020918 21:12 Message: Logged In: YES user_id=588346 1+%e,numer also fails These examples work with bfloat, e.g. 1+%e,bfloat; %e^%e,bfloat;  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=609464&group_id=4933 
From: SourceForge.net <noreply@so...>  20060827 06:45:18

Bugs item #586688, was opened at 20020725 14: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=586688&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  Floating point Group: None Status: Open Resolution: None Priority: 5 Submitted By: Raymond Toy (rtoy) Assigned to: Nobody/Anonymous (nobody) Summary: numer and float problem. Initial Comment: Consider this simple transcript with CMUCL with current sources: (C1) exp(1); (D1) %E (C2) ev(%,numer); (D2) %E (C3) float(%); (D3) 2.718281828459045 (C4) exp(2); 2 (D4) %E (C5) ev(%,numer); (D5) 7.389056 (C6) float(d4); (D6) 7.389056 Why is D2 still %E? Shouldn't it be the same as D3? And why does D5 and D6 only have single precision results? They ought to be at least double precision. Clisp has the same problem. GCL doesn't since singlefloat and doublefloat are the same on GCL.  Comment By: Robert Dodier (robert_dodier) Date: 20060326 16:46 Message: Logged In: YES user_id=501686 See also [ 531466 ] float needs to be eval. with numer (more of the same, with different examples).  Comment By: Robert Dodier (robert_dodier) Date: 20050801 23:44 Message: Logged In: YES user_id=501686 I get similar output, except that now all numerical values are doubles as expected  (%i21) exp(1); (%o21) %e (%i22) ev(%,numer); (%o22) %e (%i23) float(%); (%o23) 2.718281828459045 (%i24) exp(2); (%o24) %e^2 (%i25) ev(%,numer); (%o25) 7.38905609893065 (%i26) float (%o24); (%o26) 7.38905609893065 (%i27) float(exp(4)); (%o27) 54.59815003314424 Compare these to %i22/%o22  (%i28) %e, numer; (%o28) 2.718281828459045 (%i37) :lisp (setq $% '((mexpt) $%e 1)) ((MEXPT) $%E 1) (%i37) %, numer; (%o37) 2.718281828459045 Hmm. Maxima version: 5.9.1.1cvs Maxima build date: 10:5 7/28/2005 host type: i686redhatlinuxgnu lispimplementationtype: CLISP lispimplementationversion: 2.33.2 (20040602)  Comment By: Raymond Toy (rtoy) Date: 20041109 08:05 Message: Logged In: YES user_id=28849 float(exp(2)) should return a doublefloat now. float(exp(n)) when n is an integer should be a doublefloat too.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=586688&group_id=4933 
From: SourceForge.net <noreply@so...>  20060827 00:24:13

Bugs item #721575, was opened at 20030414 21: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=721575&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: 2/sqrt(2) doesn\'t simplify Initial Comment: 2/sqrt(2) doesn't simplify. Similarly for 2/2^(2/3). On the other hand, x/sqrt(x) => sqrt(x). And of course sqrt(2) simplifies to itself  it doesn't become 2/sqrt(2)!! I believe the original examples should simplify to sqrt(2) and 2^(1/3). Note that 2^(4/3) => 2*2^(1/3) (the current behavior) is probably CORRECT, in order to make things like 10^(10/3) intelligible. Or is there something I'm missing? Maxima 5.9.0 gcl 2.5.0 mingw32 Windows 2000 Athlon  Comment By: Stavros Macrakis (macrakis) Date: 20031008 21:21 Message: Logged In: YES user_id=588346 More examples. Righthand side is after ratsimp/algebraic. I believe the general simplifier should be giving those forms. 1/(2*2^(2/3)) 2^(1/3)/4 1/2^(2/3) 2^(1/3)/2 1/(2*SQRT(2)) SQRT(2)/4 1/SQRT(2) SQRT(2)/2 1/(2*2^(1/3)) 2^(2/3)/4 1/2^(1/3) 2^(2/3)/2 Things get worse with nonnumeric contents. In the following, each group of expressions denotes the same thing, but none simplifies to the others. I have put *** next to those forms which are the results of ratsimp/algebraic. Note that in several cases, there is more than one equivalent ratsimp'ed form.... 1/(a*b)^(5/2) 1/(a^2*b^2*SQRT(a*b)) *** SQRT(a*b)/(a^3*b^3) *** 1/(a*b)^(3/2) 1/(a*b*SQRT(a*b)) *** SQRT(a*b)/(a^2*b^2) *** 1/(a*b)^(7/6) 1/(a^(2/3)*b^(2/3)*SQRT(a*b)) *** SQRT(a*b)/(a^(5/3)*b^(5/3)) *** (a*b)^(5/6)/(a^2*b^2) *** 1/(a*b)^(5/6) *** 1/(a^(1/3)*b^(1/3)*SQRT(a*b)) *** (a*b)^(1/6)/(a*b) *** SQRT(a*b)/(a^(4/3)*b^(4/3)) *** 1/SQRT(a*b) *** SQRT(a*b)/(a*b) *** a^(1/3)*b^(1/3)/SQRT(a*b) *** 1/(a*b)^(1/6) *** SQRT(a*b)/(a^(2/3)*b^(2/3)) *** (a*b)^(5/6)/(a*b) *** Now it is true that these expressions are in fact not all equivalent as to principal value, but I will leave that exercise for later. Many of them are, and they are not being canonicalized.  Comment By: Stavros Macrakis (macrakis) Date: 20030417 12:53 Message: Logged In: YES user_id=588346 Yes, of course there are ways within Maxima to perform this simplification. But it should be the default in the general simplifer. The logic already appears to be in the general simplifier, but there is a bug in this particular case. If the general simplifier's philosophy were to leave such things untouched, why does it simplify x/sqrt(x) and the like?  Comment By: Barton Willis (willisb) Date: 20030417 12:44 Message: Logged In: YES user_id=570592 Try ratsimp with algebraic : true (C1) z : 2/sqrt(2); (D1) 2/SQRT(2) (C2) ratsimp(z); (D2) 2/SQRT(2) (C3) ratsimp(z),algebraic; (D3) SQRT(2) (C4) z : 2/2^(2/3); (D4) 2/2^(2/3) (C5) ratsimp(z); (D5) 2/2^(2/3) (C6) ratsimp(z),algebraic; (D6) 2^(1/3) (C7)  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=721575&group_id=4933 
From: SourceForge.net <noreply@so...>  20060827 00:24:13

Bugs item #719968, was opened at 20030411 16:36 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=719968&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: No SIMP function Initial Comment: The info file documents a function SIMP, which "causes exp to be simplified regardless of the setting of the switch SIMP which inhibits simplification if FALSE". But there is no such function defined. It is also not clear if this is supposed to force resimplification of the whole expression, or only the part without SIMP flags.  Comment By: Robert Dodier (robert_dodier) Date: 20050410 21:23 Message: Logged In: YES user_id=501686 The description of the simp function went away some months ago (late 2004, I think). So the documentation of a nonexistent function is no longer a problem. It makes me wonder, though, if we to expose SIMPLIFYA somehow or something like that. If the answer is "no", let's close this bug report.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=719968&group_id=4933 