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}
(100) 
_{Oct}
(57) 
_{Nov}
(33) 
_{Dec}
(46) 
2016 
_{Jan}
(76) 
_{Feb}
(53) 
_{Mar}
(88) 
_{Apr}
(79) 
_{May}
(62) 
_{Jun}
(65) 
_{Jul}
(37) 
_{Aug}
(23) 
_{Sep}
(108) 
_{Oct}
(68) 
_{Nov}
(66) 
_{Dec}
(47) 
2017 
_{Jan}
(55) 
_{Feb}
(11) 
_{Mar}
(30) 
_{Apr}
(19) 
_{May}
(14) 
_{Jun}
(21) 
_{Jul}
(30) 
_{Aug}
(48) 
_{Sep}
(39) 
_{Oct}
(24) 
_{Nov}

_{Dec}

From: SourceForge.net <noreply@so...>  20060517 17:12:32

Bugs item #1490397, was opened at 20060517 13: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=1490397&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: Raymond Toy (rtoy) Assigned to: Nobody/Anonymous (nobody) Summary: subres gcd wrong Initial Comment: Here is an example of where subres produces the wrong result but spmod is ok. p:(x^3+1)/(2*x^5+2); q:(sqrt(5)+5)/(20*x^2+(10*sqrt(5)10)*x+20); gcd:subres; ratsimp(p+q); => ((sqrt(5)+5)*x^32*sqrt(5)*x^22*sqrt(5)*x+sqrt(5)15)/(80*x^5+80) But now see what happens with spmod: gcd:spmod; ratsimp(p+q); => ((sqrt(5)+5)*x^5+(5*sqrt(5)5)*x^4+10*x^310*x^2+(5*sqrt(5)+5)*x +sqrt(5)15) /(20*x^7+(10*sqrt(5)10)*x^6+20*x^5+20*x^2+(10*sqrt(5)10)*x+20) factor(%): => (sqrt(5)*x^5+5*x^55*sqrt(5)*x^45*x^4+10*x^310*x^2+5*sqrt(5)*x+5*x +sqrt(5)15) /(10*(x+1)*(2*x^2sqrt(5)*xx+2)*(x^4x^3+x^2x+1)) Maxima doesn't notice but the numerator has the factor 2*x^2sqrt(5)*xx+2: divide((sqrt(5)*x^5+5*x^55*sqrt(5)*x^45*x^4+10*x^310*x^2+5*sqrt(5)*x+5*x +sqrt(5)15), (2*x^2sqrt(5)*xx+2)); => [((sqrt(5)+5)*x^32*sqrt(5)*x^22*sqrt(5)*x+sqrt(5)15)/2,0] So the final result of ratsimp is ((sqrt(5)+5)*x^32*sqrt(5)*x^22*sqrt(5)*x+sqrt(5)15)/2/(10*(x+1)*(x^4x^3+x^2x+1)); Notice that the numerator matches the numerator for the subres result, but the denominator is off by a factor of 4!  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1490397&group_id=4933 
From: SourceForge.net <noreply@so...>  20060517 03:15:46

Bugs item #1488344, was opened at 20060514 09:24 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1488344&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: Barton Willis (willisbl) Summary: conjugate limitation Initial Comment: The conjugate function doesn't handle long argument lists. For example (%i17) m :genmatrix(a,100,100)$ (%i18) conjugate(m)$ Maxima encountered a Lisp error: Error in MEVAL [or a callee]: MEVAL [or a callee] requires less than one hundred arguments. Barton  >Comment By: Robert Dodier (robert_dodier) Date: 20060516 21:15 Message: Logged In: YES user_id=501686 I don't know that we should associate this bug with conjugate  this appears to be the GCL limitation on the number of arguments (64 at present), so it seems like we should either label it a GCL bug, or maybe a $MATRIX bug (since it might be that the GCL limitation is triggered by $MATRIX).  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1488344&group_id=4933 
From: SourceForge.net <noreply@so...>  20060517 03:11:57

Bugs item #1276259, was opened at 20050829 21: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=1276259&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: Xmaxima Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Closing xmaxima issues "kill TERM 1" Initial Comment: At least for my particular setup, xmaxima has a very unfortunate behaviour at shutdown. I'm running a Linux x86 box, KDE 3.4, Tcl 8.4, maxima 5.9.1. Somehow, it seems that "pid" is set to 1 in line 13603 of xmaxima. This sends a kill TERM to every process it can, wiping out my login session and any associated jobs running. If run as root, it wipes out every logged in session and every running daemon. A sanity check on that parameter might be in order before issuing the kill on Linux.  >Comment By: Robert Dodier (robert_dodier) Date: 20060516 21:11 Message: Logged In: YES user_id=501686 Fixed by modifying the #+clisp version of GETPID in src/server.lisp (r1.10) so that it calls PROCESSID. Bug not observed in Xmaxima from Maxima 5.9.3 / Clisp 2.34, and referredto Redhat Bugzilla item is closed. Closing this report as fixed.  Comment By: Kevin Kofler (kevinkofler) Date: 20050922 20:53 Message: Logged In: YES user_id=573515 Please look at the Red Hat bugzilla #168451, they have pretty much tracked it down. Looks like it depends on the LISP runtime (Fedora uses clisp). https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=168451  Comment By: Robert Dodier (robert_dodier) Date: 20050922 14:38 Message: Logged In: YES user_id=501686 To the anonymous person or persons adding comments to this item: can you PLEASE PLEASE PLEASE login or leave an email address or something? PLEASE. I would like to fix this bug  really I would  but I can't reproduce it, and therefore I need your help to track down what's going on here. Without further information, which only you can provide, it's not going to get fixed. Thanks so much for your help, and sorry for shouting. Robert Dodier  Comment By: Nobody/Anonymous (nobody) Date: 20050922 13:06 Message: Logged In: NO Hello. Installed Maxima 5.9.1 today and the first time I tried it, it crashed my xserver. This is very very bad. This needs to be fixed pronto. Using the Fedora Core 4 distribution rpm from fedoraextras. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=168451  Comment By: Robert Dodier (robert_dodier) Date: 20050914 21:26 Message: Logged In: YES user_id=501686 reopening this bug report  issue is unresolved. I didn't realize that marking it "pending" would cause it to be closed in 14 days automatically. Oh well.  Comment By: SourceForge Robot (sfrobot) Date: 20050914 20:20 Message: Logged In: YES user_id=1312539 This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker).  Comment By: Nobody/Anonymous (nobody) Date: 20050831 14:58 Message: Logged In: NO No, I'm afraid my version of xmaxima is uptodate, I installed from maxima5.9.1, and have never installed any version previously. I'm still getting "kill TERM 1". My RunMaxima.tcl file is version 1.18, and the version string embedded in the concatenated xmaxima file in my path matches that value. If you see the loop at line 295, it will only continue to the "xmaxima is running" state when pid becomes something other than "none". Apparently, it's coming back set to 1.  Comment By: Robert Dodier (robert_dodier) Date: 20050831 08:37 Message: Logged In: YES user_id=501686 It would appear that you're running an old version of xmaxima; at present the default value for pid is "none". The "kill 1" bug appears to have been fixed in r1.15 interfaces/xmaxima/Tkmaxima/RunMaxima.tcl (see http://cvs.sf.net/viewcvs.py/maxima/maxima/ and drill down from there). If your xmaxima says ``set pid 1'' instead of ``set pid "none"'' then your version is out of date. Is there more than one xmaxima on your system?  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1276259&group_id=4933 
From: SourceForge.net <noreply@so...>  20060517 02:30:08

Bugs item #1471813, was opened at 20060417 10:07 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1471813&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: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: integrate(1/(x^2 + 4)^(3/2),x,0,inf); Initial Comment: (%i1) integrate(1/(x^2 + 4)^(3/2),x,0,inf); Maxima encountered a Lisp error: Error in PROGN [or a callee]: Error in doargcounterror: DESTRUCTURINGBIND NIL NIL (L ... Let's try the integral from minf to inf: (%i2) integrate(1/(x^2 + 4)^(3/2),x,minf,inf); Is x positive or negative? pos; (%o2) 1/2 The question is silly, but 1/2 is the correct value for the integral. (%i3) build_info(); Maxima version: 5.9.2.19cvs Maxima build date: 9:42 4/10/2006 host type: i686pcmingw32 lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.7 (%o3) Barton  Comment By: Raymond Toy (rtoy) Date: 20060506 07:57 Message: Logged In: YES user_id=28849 FWIW, the question comes when maxima is computing limit(x*(4+x^2)^(3/2),x,minf). I think this is really a bug in limitit ought to know that x is negative in this case.  Comment By: Raymond Toy (rtoy) Date: 20060417 10:14 Message: Logged In: YES user_id=28849 Try with the CVS version. It returns 1/4 for the first integral, but still asks about x for the second integral.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1471813&group_id=4933 
From: SourceForge.net <noreply@so...>  20060517 02:18:04

Bugs item #1488359, was opened at 20060514 10:13 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1488359&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  Complex Group: None Status: Open Resolution: None Priority: 5 Submitted By: Barton Willis (willisbl) Assigned to: Barton Willis (willisbl) Summary: conjuate of subscripted function Initial Comment: (%o20) f[6](x) (%i21) conjugate(%); Maxima encountered a Lisp error: Error in GET [or a callee]: (($F SIMP ARRAY) 6) is not of type SYMBOL. Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1488359&group_id=4933 
From: SourceForge.net <noreply@so...>  20060517 02:17:15

Bugs item #1488457, was opened at 20060514 14:35 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1488457&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Lisp Core  Assume Group: None Status: Open Resolution: None Priority: 5 Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: featurep of subscripted variables Initial Comment: (%i1) featurep(a,real); (%o1) false < OK (%i2) featurep(a[1],real); (%o2) true < not OK Do we have a policy? Are all mapatoms except %i and infinity real? That would make %o1 wrong and %o2 correct. Should the setting of domain make a difference? Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1488457&group_id=4933 
From: SourceForge.net <noreply@so...>  20060516 03:14:04

Bugs item #1489285, was opened at 20060515 22:14 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=1489285&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  Complex Group: None Status: Open Resolution: None Priority: 5 Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: conjugate is real valued Initial Comment: (%i1) declare(z,complex); (%o1) done (%i2) imagpart(conjugate(z)); (%o2) 0 To cure this, declare conjugate to be complex: (%i3) declare(conjugate,complex); (%o3) done (%i4) imagpart(conjugate(z)); (%o4) imagpart(conjugate(z)) Now %o4 could be imagpart(z). Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1489285&group_id=4933 
From: SourceForge.net <noreply@so...>  20060516 00:09:22

Bugs item #1489164, was opened at 20060515 16:25 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1489164&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(equla(%i,0)) Initial Comment: (%i9) is(equal(%i,0)); `sign' called on an imaginary argument: (%i10) is(equal(und,0)); `sign' called on `und'. I claim that both of these should evaluate to false. It seems that equal should call csign, not $sign. Barton  >Comment By: Robert Dodier (robert_dodier) Date: 20060515 18:09 Message: Logged In: YES user_id=501686 Agreed, these are bugs, and these should both yield false.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1489164&group_id=4933 
From: SourceForge.net <noreply@so...>  20060516 00:08:33

Bugs item #1483121, was opened at 20060506 14:47 Message generated for change (Comment added) made by robert_dodier 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: Robert Dodier (robert_dodier) Date: 20060515 18: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 15: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...>  20060515 22:25:43

Bugs item #1489164, was opened at 20060515 17:25 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=1489164&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(equla(%i,0)) Initial Comment: (%i9) is(equal(%i,0)); `sign' called on an imaginary argument: (%i10) is(equal(und,0)); `sign' called on `und'. I claim that both of these should evaluate to false. It seems that equal should call csign, not $sign. Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1489164&group_id=4933 
From: SourceForge.net <noreply@so...>  20060515 16:34:16

Bugs item #1488949, was opened at 20060515 12:34 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=1488949&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: 1 Submitted By: Raymond Toy (rtoy) Assigned to: Nobody/Anonymous (nobody) Summary: gcd:eez not implemented Initial Comment: Setting gcd to eez, which is documented via describe to be a valid possibility, causes an error when used. Maxima says eezgcd not implemented. This is one way to trigger the message: gcd:eez; ratsimp(diff(integrate(1/(x^5+1),x),x)); I suggest changing the documentation to remove the entry for eez.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1488949&group_id=4933 
From: SourceForge.net <noreply@so...>  20060515 13:36:08

Bugs item #1452341, was opened at 20060317 08:46 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1452341&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 Submitted By: Raymond Toy (rtoy) Assigned to: Nobody/Anonymous (nobody) Summary: solve(x^(5/2)+1,x) produces incorrect roots Initial Comment: Consider: (%i16) display2d:false; (%o16) false (%i17) solve(x^(5/2)+1,x); (%o17) [x = %e^(4*%i*%pi/5),x = %e^(2*%i*%pi/5),x = %e^(2*%i*%pi/5), x = %e^(4*%i*%pi/5),sqrt(x) = 1] (%i18) map(lambda([u],rhs(u)^(5/2)+1),%); (%o18) [2,0,0,2,%i+1] Clearly some of the roots are wrong.  >Comment By: Raymond Toy (rtoy) Date: 20060515 09:35 Message: Logged In: YES user_id=28849 This fails because solvespec and solvespec1 (src/solve.lisp) tries to solve y^5+1 = 0 and then x^(1/2) = y, and assumes all the roots are actually roots. More care is needed. This is complicated because solvespec1 calls solve to find the roots, which saves them on the global variable, so we need to examine the global vars to find our roots.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1452341&group_id=4933 
From: SourceForge.net <noreply@so...>  20060515 13:28:50

Bugs item #1480338, was opened at 20060502 07:59 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1480338&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: ratsimp(exp(constant)) very slow Initial Comment: ratsimp, when applied to %e^((sqrt(852469675641479773175661572149741) 15762598695796738)/2251799813685248); is very slow. But can ratsimp simplify the argument to exp quickly. This expression happended towards the end of a matrixexp calculation. I've tried variations of this expression (delete hunks of various numbers)  sometimes ratsimp is very fast, other times it seems to hang. (%i18) build_info(); 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 Barton  >Comment By: Raymond Toy (rtoy) Date: 20060515 09:28 Message: Logged In: YES user_id=28849 Very good! Let's close this.  Comment By: Andrej Vodopivec (andrejv) Date: 20060512 21:36 Message: Logged In: YES user_id=1179910 I updated ifactor.lisp  maxima now returns the answer without delays and warnings. Andrej  Comment By: Raymond Toy (rtoy) Date: 20060512 21:20 Message: Logged In: YES user_id=28849 All of the tests listed herein are fixed. But the original report about exp(sqrt(foo)...) is still slow. That does appear to be an issue with factor (ifactor).  Comment By: Raymond Toy (rtoy) Date: 20060510 07:37 Message: Logged In: YES user_id=28849 Oh. I had already made that change in my sources because cmucl complained about it. Now if we could only check in the fix!  Comment By: Andrej Vodopivec (andrejv) Date: 20060510 02:07 Message: Logged In: YES user_id=1179910 Actually just this does not fix a^(10/11..) issue  if you call ratsimp on it it still fails. To solve this and get Bartons example done fast I had to change f< to < in palgsimp and f to  in pasimp1 in rat3a.lisp. Andrej  Comment By: Raymond Toy (rtoy) Date: 20060509 22:06 Message: Logged In: YES user_id=28849 Neat. I think I found the issue. In src/rat3d.lisp, in the function iroot, there's the line (cond ((f< (haulong a) n) (list 1 (sub1 a))) That f< seems to be the problem because n is not a fixnum. Replacing f< with plain < solves both the 2^(1/111...) and a^(10/111....) issue. Someone should look at all of the uses of f<, f+, etc. in rat3*.lisp and replace them with <, +, etc., as needed.  Comment By: Andrej Vodopivec (andrejv) Date: 20060509 14:57 Message: Logged In: YES user_id=1179910 Some more examples: (%i1) display2d:false$ (%i2) build_info()$ 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 %i3 is OK but %i4 takes a long time  the same for all higher denominators and other bases. (%i3) 2^(1/1111111111); (%o3) 2^(1/1111111111) (%i4) 2^(1/11111111111); Maxima encountered a Lisp error: Console interrupt. Automatically continuing. To reenable the Lisp debugger set *debuggerhook* to nil. Again %i5 is OK and %i6 has an extra (a+1)^9 factor. Similar with other examples with bigger denominators in exponent. The numerator in the exponent must be bigger than one to trigger this bug. (%i5) a^(10/1111111111); (%o5) a^(10/1111111111) (%i6) ratsimp(%); (%o6) a^(10/1111111111) (%i7) a^(10/11111111111); (%o7) a^(10/11111111111) (%i8) ratsimp(%); (%o8) a^(10/11111111111)*(a^9+9*a^8+36*a^7+84*a^6+126*a^5+126*a^4+84*a^3+36*a^2+9*a+1) Andrej  Comment By: Andrej Vodopivec (andrejv) Date: 20060508 12:37 Message: Logged In: YES user_id=1179910 The problem is not with the factoring code. Barton is reporting long times with version 5.9.3 (gcl+win) before ifactor was moved to src and it is not just a delay because of factoring  I interrupted the execution after a couple of minutes. Anyway I will remove the warning that factoring failed. I could also make the code give up sooner. The way things were set up before the factorization was more like testing for small factors rather than trying for complete factorization. Andrej  Comment By: Raymond Toy (rtoy) Date: 20060508 10:47 Message: Logged In: YES user_id=28849 Interesting. Barton's simplified ratsimp example causes 2 errors with CMUCL because pcetimes1 does f+ with a bignum and palgsimp does f< with a bignum. Replacing these with + and < fixes the issue. However, the ratsimp example causes a warning from cmucl because it wants to compute 1^1932473987149817. This is a cmucl problem, but depending on how smart the Lisp is, it might actually try to compute that power. Finally, for the complicated ratsimp(exp((sqrt ...))) example, I think the real issue is that maxima is trying to simplify the sqrt. If you just enter sqrt(852469675641479773175661572149741); there's a delay before maxima prints out the warning about not finding the factors. Also, factor(852469675641479773175661572149741) spends some time and returns 2 factors: 34130646845983 24976663333933005427. Not sure why there's a warning at all. So I think it used to be fast because sqrt(852...) factor or somebody gave up early and returned sqrt(852...). ifactor works harder before giving up.  Comment By: Robert Dodier (robert_dodier) Date: 20060506 23:03 Message: Logged In: YES user_id=501686 Not sure what's going on here, but maybe the problem is in the factoring code. Maxima 5.9.3 / clisp 2.34: ratsimp (%e^((sqrt(852469675641479773175661572149741) 15762598695796738)/2251799813685248)); => fast Maxima 5.9.3 / clisp 2.38 (after factor code was revised): => slow, and it complains "WARNING: could not find factors of composite: 852469675641479773175661572149741"  Comment By: Barton Willis (willisbl) Date: 20060506 07:40 Message: Logged In: YES user_id=895922 A simpler example: ratsimp(exp((1932473987149817)/589347638476187146)) Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1480338&group_id=4933 
From: SourceForge.net <noreply@so...>  20060515 05:57:31

Bugs item #1488629, was opened at 20060514 22:57 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=1488629&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: Fix for 5.9.2 Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: sign errors in cartan package Initial Comment: (%i1) load(cartan); /usr/share/maxima/5.9.2/share/calculus/cartan.lisp (%i2) init_cartan([x1,x2,x11,x21]); (%o2) [dx1, dx2, dx11, dx21] (%i3) ff:x11*dx2+x21*dx1; (%o3) x11 dx2 + x21 dx1 (%i4) ext_diff(ff); (%o4)  dx1 dx21  dx11 dx2 (%i5) The result should be  dx1 dx21 + dx11 dx2  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1488629&group_id=4933 
From: SourceForge.net <noreply@so...>  20060514 20:35:14

Bugs item #1488457, was opened at 20060514 15:35 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=1488457&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 Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: featurep of subscripted variables Initial Comment: (%i1) featurep(a,real); (%o1) false < OK (%i2) featurep(a[1],real); (%o2) true < not OK Do we have a policy? Are all mapatoms except %i and infinity real? That would make %o1 wrong and %o2 correct. Should the setting of domain make a difference? Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1488457&group_id=4933 
From: SourceForge.net <noreply@so...>  20060514 17:33:52

Bugs item #1487703, was opened at 20060512 19:36 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1487703&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 Submitted By: David Billinghurst (billingd) Assigned to: Nobody/Anonymous (nobody) Summary: integrate((sqrt(x^46*x^2+1)x^2+1)/(2*x),x) fails Initial Comment: With CVS maxima (20060513) e:(sqrt(x^46*x^2+1)x^2+1)/(2*x); integrate(e,x); ***  Lisp stack overflow. RESET The change is recent  since Feb 06. With maxima 5.9.3 (%i2) integrate(e,x); 2 2 log(x + 2 x  1) log(x  2 x  1)  +  / 2 2 2 [ % e x I  dx + log(x)   ] x 2 / (%o2)   2 When fixed, reenable DE 105 in share/contrib/diffequations/tests/rtestode_murphy_2_2. mac  >Comment By: Raymond Toy (rtoy) Date: 20060514 13:33 Message: Logged In: YES user_id=28849 I tried the checkedin version of sin.lisp. I think the 6 test integrals now produce the same answers now as in 5.9.3.  Comment By: David Billinghurst (billingd) Date: 20060513 20:21 Message: Logged In: YES user_id=365569 I tried this (diff attached). There isn't any change to the testsuite but there are a number of changes to the ode_contrib testsuite. I have reduced the first few to find the changes in integrate() results. There are both good and bad changes. integrate(2*(1tan(x)^2)*csc(2*x)*(csc(2*x)+cot(2*x)),x); integrate(1/(u*((sqrt(u^2+1)*abs(x)+u*x)/(u*x)1)),u); integrate(1/(u*((sqrt(1u^2)*abs(x)+u*x)/(u*x)1)),u); integrate((x*sqrt(y^2+x^2)+y)/(x*sqrt(y^2+x^2)),x); integrate(1/(u*((a*sqrt(u^2+b)*abs(x)+u*x)/(u*x)1)),u); integrate((a*x^3x*sqrt(a^2*x^4b))/sqrt(a^2*x^4b),x); I haven't attached the results  it looks ugly  but can do if required.  Comment By: Raymond Toy (rtoy) Date: 20060512 21:55 Message: Logged In: YES user_id=28849 There are two causes for this, I think. First, intform no longer sets $radexand to $all because that causes sqrt(x^2) to be x, which is not always right. Second, the line cond test ((not (alike1 exp (setq y ($expand exp)))) near the end of integrator is the actual source of the loop. I don't really understand why it wants to do this, but commenting out test and body allows this integral to work as it used to. Plus there are no failures in the testsuite. Additionally, some commented out integration tests no longer loop either.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1487703&group_id=4933 
From: SourceForge.net <noreply@so...>  20060514 16:13:04

Bugs item #1488359, was opened at 20060514 11:13 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=1488359&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: Barton Willis (willisbl) Summary: conjuate of subscripted function Initial Comment: (%o20) f[6](x) (%i21) conjugate(%); Maxima encountered a Lisp error: Error in GET [or a callee]: (($F SIMP ARRAY) 6) is not of type SYMBOL. Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1488359&group_id=4933 
From: SourceForge.net <noreply@so...>  20060514 15:24:16

Bugs item #1488344, was opened at 20060514 10:24 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=1488344&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: Barton Willis (willisbl) Summary: conjugate limitation Initial Comment: The conjugate function doesn't handle long argument lists. For example (%i17) m :genmatrix(a,100,100)$ (%i18) conjugate(m)$ Maxima encountered a Lisp error: Error in MEVAL [or a callee]: MEVAL [or a callee] requires less than one hundred arguments. Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1488344&group_id=4933 
From: SourceForge.net <noreply@so...>  20060514 00:21:14

Bugs item #1487703, was opened at 20060513 09:36 Message generated for change (Comment added) made by billingd You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1487703&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 Submitted By: David Billinghurst (billingd) Assigned to: Nobody/Anonymous (nobody) Summary: integrate((sqrt(x^46*x^2+1)x^2+1)/(2*x),x) fails Initial Comment: With CVS maxima (20060513) e:(sqrt(x^46*x^2+1)x^2+1)/(2*x); integrate(e,x); ***  Lisp stack overflow. RESET The change is recent  since Feb 06. With maxima 5.9.3 (%i2) integrate(e,x); 2 2 log(x + 2 x  1) log(x  2 x  1)  +  / 2 2 2 [ % e x I  dx + log(x)   ] x 2 / (%o2)   2 When fixed, reenable DE 105 in share/contrib/diffequations/tests/rtestode_murphy_2_2. mac  >Comment By: David Billinghurst (billingd) Date: 20060514 10:21 Message: Logged In: YES user_id=365569 I tried this (diff attached). There isn't any change to the testsuite but there are a number of changes to the ode_contrib testsuite. I have reduced the first few to find the changes in integrate() results. There are both good and bad changes. integrate(2*(1tan(x)^2)*csc(2*x)*(csc(2*x)+cot(2*x)),x); integrate(1/(u*((sqrt(u^2+1)*abs(x)+u*x)/(u*x)1)),u); integrate(1/(u*((sqrt(1u^2)*abs(x)+u*x)/(u*x)1)),u); integrate((x*sqrt(y^2+x^2)+y)/(x*sqrt(y^2+x^2)),x); integrate(1/(u*((a*sqrt(u^2+b)*abs(x)+u*x)/(u*x)1)),u); integrate((a*x^3x*sqrt(a^2*x^4b))/sqrt(a^2*x^4b),x); I haven't attached the results  it looks ugly  but can do if required.  Comment By: Raymond Toy (rtoy) Date: 20060513 11:55 Message: Logged In: YES user_id=28849 There are two causes for this, I think. First, intform no longer sets $radexand to $all because that causes sqrt(x^2) to be x, which is not always right. Second, the line cond test ((not (alike1 exp (setq y ($expand exp)))) near the end of integrator is the actual source of the loop. I don't really understand why it wants to do this, but commenting out test and body allows this integral to work as it used to. Plus there are no failures in the testsuite. Additionally, some commented out integration tests no longer loop either.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1487703&group_id=4933 
From: SourceForge.net <noreply@so...>  20060513 21:30:36

Bugs item #1483121, was opened at 20060506 15:47 Message generated for change (Comment added) made by willisbl 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: None 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: Barton Willis (willisbl) Date: 20060513 16: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...>  20060513 21:27:39

Bugs item #1479149, was opened at 20060429 21:13 Message generated for change (Comment added) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1479149&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: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Integration with trigonometric function and following diff Initial Comment: integrate(k*x/f(x),x), knumber, f(x)thrigonometric function  sin(x)^2, cos(x)^2, Sin(x)^3 etc. gives a very poor result. axiom gives a better and short result. following diff(%,x) gives a non simply formula. So, maxima has a problem with a trigonometric function ;)  >Comment By: Barton Willis (willisbl) Date: 20060513 16:27 Message: Logged In: YES user_id=895922 No real bug hereI'm closing the report. Barton  Comment By: Barton Willis (willisbl) Date: 20060501 12:04 Message: Logged In: YES user_id=895922 Maxima uses a constant of integration when it thinks one is really needed: (%i12) integrate(x=1,x); (%o12) x^2/2=x+integrationconstant1 This is a bug listfor a better place to ask questions about how to use Maxima see: http://maxima.sourceforge.net/maximalist.html Barton  Comment By: Raymond Toy (rtoy) Date: 20060501 11:54 Message: Logged In: YES user_id=28849 Judicious use of logcontract, trigexpand and trigsimp will produce log(44*cos(x)^2)2*x*cos(x)/sin(x). That's pretty comparable to axiom's result. Also, integrate never returns a gratuitious constant of integration, just like tables of integrals never do If you want it, you have to add it yourself.  Comment By: Nobody/Anonymous (nobody) Date: 20060501 08:19 Message: Logged In: NO Yes, trigsimp was help me, it gives simpler, but not simplest formula. For example, k=2, f(x)=sin(x)^2 integrate(2*x/(sin(x)^2,x) with trigsimp gives a following formula: [{(cos(2x)1)*log(2*cos(x)+2)}+{(cos(2*x)1)*log(22*cos(x))}+2*x*sin(2*x)]/(cos(2*x)1) Simplest result is: 2*(log(sin(x)/2)x*ctg(x)) Or, maxima don't gives (don't can) a simplest result? P.S. By the way, how about C? integrate(x,x) = x^2/2 + C. doble integrate gives a x^3/6 + C*x + c(1)  Comment By: Barton Willis (willisbl) Date: 20060430 06:55 Message: Logged In: YES user_id=895922 Did Maxima give an incorrect result for any of these integrals? Maxima does gives a lengthy formula for integrate(x / sin(x)^2,x), but it seems to be correct: (%i1) integrate(x / sin(x)^2,x)$ (%i2) diff(%,x)  x/sin(x)^2$ (%i3) exponentialize(%)$ (%i4) ratsimp(%); (%o4) 0 In addition to exponentialize and ratsimp, Maxima has functions trigsimp, trigreduce, and trigexpand. Did you try using these functions to convert the antiderivatives into the form you were looking for? Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1479149&group_id=4933 
From: SourceForge.net <noreply@so...>  20060513 21:25:59

Bugs item #1479151, was opened at 20060429 21:24 Message generated for change (Settings changed) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1479151&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: Invalid Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: maxima don't use a   Initial Comment: Example: integrate(1/x,x) gives a log(x), but must be gives a log(abs(x)). May be, maxima don't verify permissible value anyhere.  Comment By: Barton Willis (willisbl) Date: 20060430 06:34 Message: Logged In: YES user_id=895922 If you want integrate(1/x,x) = log(abs(x)), set the option variable 'logabs' to true: (%i1) logabs : true$ (%i2) integrate(1/x,x); (%o2) log(abs(x)) (%i3) logabs : false$ (%i4) integrate(1/x,x); (%o4) log(x) Since integrate(1/x,x) = log(abs(x)) isn't correct off the real axis, the default for 'logabs' is false. Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1479151&group_id=4933 
From: SourceForge.net <noreply@so...>  20060513 21:24:32

Bugs item #1488101, was opened at 20060513 16:24 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=1488101&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: subst and subscripted operators Initial Comment: This works ok: (%i1) subst("[",f, f(1,2,3)); (%o1) [1,2,3] This doesn't (but ought to): (%i2) subst("[",f[1], f[1](1,2,3)); (%o2) [(1,2,3) (%i3) ?print(%); ((&[ SIMP) 1 2 3) < needs to $verbify caar Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1488101&group_id=4933 
From: SourceForge.net <noreply@so...>  20060513 01:55:31

Bugs item #1487703, was opened at 20060512 19:36 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1487703&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 Submitted By: David Billinghurst (billingd) Assigned to: Nobody/Anonymous (nobody) Summary: integrate((sqrt(x^46*x^2+1)x^2+1)/(2*x),x) fails Initial Comment: With CVS maxima (20060513) e:(sqrt(x^46*x^2+1)x^2+1)/(2*x); integrate(e,x); ***  Lisp stack overflow. RESET The change is recent  since Feb 06. With maxima 5.9.3 (%i2) integrate(e,x); 2 2 log(x + 2 x  1) log(x  2 x  1)  +  / 2 2 2 [ % e x I  dx + log(x)   ] x 2 / (%o2)   2 When fixed, reenable DE 105 in share/contrib/diffequations/tests/rtestode_murphy_2_2. mac  >Comment By: Raymond Toy (rtoy) Date: 20060512 21:55 Message: Logged In: YES user_id=28849 There are two causes for this, I think. First, intform no longer sets $radexand to $all because that causes sqrt(x^2) to be x, which is not always right. Second, the line cond test ((not (alike1 exp (setq y ($expand exp)))) near the end of integrator is the actual source of the loop. I don't really understand why it wants to do this, but commenting out test and body allows this integral to work as it used to. Plus there are no failures in the testsuite. Additionally, some commented out integration tests no longer loop either.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1487703&group_id=4933 
From: SourceForge.net <noreply@so...>  20060513 01:36:14

Bugs item #1480338, was opened at 20060502 13:59 Message generated for change (Comment added) made by andrejv You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1480338&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: ratsimp(exp(constant)) very slow Initial Comment: ratsimp, when applied to %e^((sqrt(852469675641479773175661572149741) 15762598695796738)/2251799813685248); is very slow. But can ratsimp simplify the argument to exp quickly. This expression happended towards the end of a matrixexp calculation. I've tried variations of this expression (delete hunks of various numbers)  sometimes ratsimp is very fast, other times it seems to hang. (%i18) build_info(); 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 Barton  >Comment By: Andrej Vodopivec (andrejv) Date: 20060513 03:36 Message: Logged In: YES user_id=1179910 I updated ifactor.lisp  maxima now returns the answer without delays and warnings. Andrej  Comment By: Raymond Toy (rtoy) Date: 20060513 03:20 Message: Logged In: YES user_id=28849 All of the tests listed herein are fixed. But the original report about exp(sqrt(foo)...) is still slow. That does appear to be an issue with factor (ifactor).  Comment By: Raymond Toy (rtoy) Date: 20060510 13:37 Message: Logged In: YES user_id=28849 Oh. I had already made that change in my sources because cmucl complained about it. Now if we could only check in the fix!  Comment By: Andrej Vodopivec (andrejv) Date: 20060510 08:07 Message: Logged In: YES user_id=1179910 Actually just this does not fix a^(10/11..) issue  if you call ratsimp on it it still fails. To solve this and get Bartons example done fast I had to change f< to < in palgsimp and f to  in pasimp1 in rat3a.lisp. Andrej  Comment By: Raymond Toy (rtoy) Date: 20060510 04:06 Message: Logged In: YES user_id=28849 Neat. I think I found the issue. In src/rat3d.lisp, in the function iroot, there's the line (cond ((f< (haulong a) n) (list 1 (sub1 a))) That f< seems to be the problem because n is not a fixnum. Replacing f< with plain < solves both the 2^(1/111...) and a^(10/111....) issue. Someone should look at all of the uses of f<, f+, etc. in rat3*.lisp and replace them with <, +, etc., as needed.  Comment By: Andrej Vodopivec (andrejv) Date: 20060509 20:57 Message: Logged In: YES user_id=1179910 Some more examples: (%i1) display2d:false$ (%i2) build_info()$ 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 %i3 is OK but %i4 takes a long time  the same for all higher denominators and other bases. (%i3) 2^(1/1111111111); (%o3) 2^(1/1111111111) (%i4) 2^(1/11111111111); Maxima encountered a Lisp error: Console interrupt. Automatically continuing. To reenable the Lisp debugger set *debuggerhook* to nil. Again %i5 is OK and %i6 has an extra (a+1)^9 factor. Similar with other examples with bigger denominators in exponent. The numerator in the exponent must be bigger than one to trigger this bug. (%i5) a^(10/1111111111); (%o5) a^(10/1111111111) (%i6) ratsimp(%); (%o6) a^(10/1111111111) (%i7) a^(10/11111111111); (%o7) a^(10/11111111111) (%i8) ratsimp(%); (%o8) a^(10/11111111111)*(a^9+9*a^8+36*a^7+84*a^6+126*a^5+126*a^4+84*a^3+36*a^2+9*a+1) Andrej  Comment By: Andrej Vodopivec (andrejv) Date: 20060508 18:37 Message: Logged In: YES user_id=1179910 The problem is not with the factoring code. Barton is reporting long times with version 5.9.3 (gcl+win) before ifactor was moved to src and it is not just a delay because of factoring  I interrupted the execution after a couple of minutes. Anyway I will remove the warning that factoring failed. I could also make the code give up sooner. The way things were set up before the factorization was more like testing for small factors rather than trying for complete factorization. Andrej  Comment By: Raymond Toy (rtoy) Date: 20060508 16:47 Message: Logged In: YES user_id=28849 Interesting. Barton's simplified ratsimp example causes 2 errors with CMUCL because pcetimes1 does f+ with a bignum and palgsimp does f< with a bignum. Replacing these with + and < fixes the issue. However, the ratsimp example causes a warning from cmucl because it wants to compute 1^1932473987149817. This is a cmucl problem, but depending on how smart the Lisp is, it might actually try to compute that power. Finally, for the complicated ratsimp(exp((sqrt ...))) example, I think the real issue is that maxima is trying to simplify the sqrt. If you just enter sqrt(852469675641479773175661572149741); there's a delay before maxima prints out the warning about not finding the factors. Also, factor(852469675641479773175661572149741) spends some time and returns 2 factors: 34130646845983 24976663333933005427. Not sure why there's a warning at all. So I think it used to be fast because sqrt(852...) factor or somebody gave up early and returned sqrt(852...). ifactor works harder before giving up.  Comment By: Robert Dodier (robert_dodier) Date: 20060507 05:03 Message: Logged In: YES user_id=501686 Not sure what's going on here, but maybe the problem is in the factoring code. Maxima 5.9.3 / clisp 2.34: ratsimp (%e^((sqrt(852469675641479773175661572149741) 15762598695796738)/2251799813685248)); => fast Maxima 5.9.3 / clisp 2.38 (after factor code was revised): => slow, and it complains "WARNING: could not find factors of composite: 852469675641479773175661572149741"  Comment By: Barton Willis (willisbl) Date: 20060506 13:40 Message: Logged In: YES user_id=895922 A simpler example: ratsimp(exp((1932473987149817)/589347638476187146)) Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1480338&group_id=4933 