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

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 




1
(1) 
2

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

12
(3) 
13

14
(3) 
15
(1) 
16

17
(1) 
18
(4) 
19
(1) 
20
(1) 
21

22

23

24
(1) 
25
(1) 
26
(3) 
27
(3) 
28
(1) 
29
(8) 
30
(4) 


From: SourceForge.net <noreply@so...>  20061105 16:14:51

Bugs item #1588623, was opened at 20061101 07:42 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1588623&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Lisp Core  Integration Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: romberg with % or %o argument Initial Comment: (%i1) sqrt(1+x^3); (%o1) sqrt(x^3+1) (%i2) romberg(%, x,0,1); Maxima encountered a Lisp error: Also, the command romberg(%o1,x,0,1) gives a Lisp error. This works OK: (%i4) romberg(sqrt(1+x^3), x,0,1); (%o4) 1.111447999508385 (%i1) build_info(); Maxima version: 5.10.0 Maxima build date: 19:9 9/21/2006 host type: i686pcmingw32 lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.7  >Comment By: Robert Dodier (robert_dodier) Date: 20061105 09:14 Message: Logged In: YES user_id=501686 I don't recommend trying to fix romberg. The quadpack functions are more extensive implementations of the same basic idea (extrapolation from simple quadrature ruls); quadpack subsumes romberg and goes much farther. I'd like to cut out romberg entirely.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1588623&group_id=4933 
From: SourceForge.net <noreply@so...>  20061105 16:11:10

Bugs item #1590528, was opened at 20061104 09:27 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1590528&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 Private: No Submitted By: Raymond Toy (rtoy) Assigned to: Nobody/Anonymous (nobody) Summary: Does debugmode(true) actually do anything? Initial Comment: debugmode(true)$ integrate((4*x^2+8*x+4)/(17*x^4+64*x^3+96*x^2+64*x+16),x,0,inf); This should give a division by zero error, and we enter debug mode: (dbm:1) :bt (dbm:1) I tried this with gcl, clisp, and cmucl. Nothing really seems to happen. Does debugmode work for anything? At least with CMUCL, it doesn't seem to matter too much, because I can press Cc to get to CMUCL's debugger which can then produce backtraces and such.  >Comment By: Robert Dodier (robert_dodier) Date: 20061105 09:11 Message: Logged In: YES user_id=501686 Maxima debugmode can print a backtrace of functions defined in Maxima by := . So far as I can tell, debugmode doesn't know anything about functions defined by defun or defmfun or defmspec. Given that most functions in Maxima are defined by defun, defmfun, and defmspec, it is not very informative to use debugmode. Since debugmode is useful in a certain context (namely debugging userdefined functions) I think we should keep it, but let's change "  an error. Quitting. To debug this try debugmode(true);" to just "  an error." (i.e. cut out the recommendation to use debugmode, which is usually not helpful, and also the "Quitting." because, in fact, Maxima is not executing (quit) nor quit()).  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1590528&group_id=4933 
From: SourceForge.net <noreply@so...>  20061105 03:20:15

Bugs item #1575120, was opened at 20061011 01:54 Message generated for change (Comment added) made by sfrobot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1575120&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: Closed Resolution: Rejected Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Some laws are still missing Initial Comment: is(equal((x/y)^z,(x^z/y^z))); is(equal((x*y)^z,(x^z*y^z))); is(equal((x^y)^z,(x^(y*z)))); of course they are equal! Those are laws! Mario/Mexico  >Comment By: SourceForge Robot (sfrobot) Date: 20061104 19: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: Robert Dodier (robert_dodier) Date: 20061021 13:26 Message: Logged In: YES user_id=501686 As mentioned by Barton, Maxima's default behavior is correct (since there are examples for which those equations fail to hold). I find that assuming x > 0 and y > 0, Maxima does evaluate those to true; I believe that is correct. assume(x>0,y>0); is(equal((x/y)^z,(x^z/y^z))); => true is(equal((x*y)^z,(x^z*y^z))); => true is(equal((x^y)^z,(x^(y*z)))); => true A possible enhancement (very far away at this point) would be for is(equal(...)) to return a result with one or more guard clauses specifying the applicability of various particular results. I won't try to spec that here. Marking this report "rejected" and "pending" (so that it will be closed automatically in 2 weeks, in case the original poster comes back).  Comment By: Barton Willis (willisbl) Date: 20061011 03:09 Message: Logged In: YES user_id=895922 For real x,y,z, the equation (x*y)^z = x^z*y^z isn't an identity. To see this, let x > 1, y > 1, and z > 1/2. If Maxima did is(equal((x*y)^z,(x^z*y^z))) > true that would be a bug. Similarly, all your other laws are not valid for all real numbers. (1) We're working on improving the function equal; it has many known problems. (2) The function 'radcan' does (%i16) radcan((x*y)^z); (%o16) x^z*y^z Maybe you would like to use it.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1575120&group_id=4933 
From: SourceForge.net <noreply@so...>  20061105 03:20:09

Bugs item #1572963, was opened at 20061007 17:06 Message generated for change (Comment added) made by sfrobot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1572963&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed Resolution: Wont Fix Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Inequalities bug Initial Comment: hi there is list bugs for maxima at: http://www.texsales.se/Artiklar/MaximaMuPAD.pdf#search=%22mupad%20vs%20maxima%22 I've personally checked this inequality: assume(x >= y, y >= z, z >= x)$ is( x = z ); I'm using maxima5.10.0.  >Comment By: SourceForge Robot (sfrobot) Date: 20061104 19: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: Robert Dodier (robert_dodier) Date: 20061021 11:18 Message: Logged In: YES user_id=501686 x = z means x has the same structure as z. equal(x, z) means x is equivalent to z. assume(x >= y, y >= z, z >= x)$ is(equal(x, z)) yields true as one would hope. Marking this report "won't fix" and "pending" (so that it will be automatically closed in 2 weeks in case original poster comes back).  Comment By: Nobody/Anonymous (nobody) Date: 20061016 11:19 Message: Logged In: NO is(equal(a,b)); works. The distinction of "=" vs. "equal" is confusing  perhaps it should be revised for Maxima 6.0.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1572963&group_id=4933 
From: SourceForge.net <noreply@so...>  20061105 02:53:46

Bugs item #1582625, was opened at 20061023 00:22 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1582625&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Integration Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: integrate(t^2*log(t)/((t^21)*(t^4+1)), t, 0, 1) wrong? Initial Comment: Symbolic integration seems to return an incorrect result: (%i1) integrate(t^2*log(t)/((t^21)*(t^4+1)), t, 0, 1); (sqrt(2) + 1) %pi (%o1)  16 sqrt(2) (%i2) float(%); (%o2) 1.053029287545515 (%i3) romberg(t^2*log(t)/((t^21)*(t^4+1)), t, 0.0000001, 0.9999999); (%o3) 0.1806718095951 (%i4) float(%pi^2/(16*(2+sqrt(2)))); (%o4) 0.18067126259065  >Comment By: Raymond Toy (rtoy) Date: 20061104 21:53 Message: Logged In: YES user_id=28849 Fixed in defint.lisp as suggested.  Comment By: Raymond Toy (rtoy) Date: 20061103 16:40 Message: Logged In: YES user_id=28849 The issue appears to be in logimag02%pi. Some of the poles are of the form (1)^(1/4) or sqrt(%i). The call to simplify %plog(pole) doesn't actually simplify and the noun form is returned (I think). If we replace (defun logimag02%pi (x) (let ((plog (simplify ((%plog) ,x)))) with (defun logimag02%pi (x) (let ((plog (simplify ($rectform `((%plog) ,x))))) maxima returns (sqrt(2)2)*%pi^2/32 which is .1806712625906549, which corresponds pretty well with the numerical result from romberg and quad_qags. The test suite runs fine with this change. I think the real problem is in the simplifier for plog, but I'm not too motivated in fixing that.  Comment By: Raymond Toy (rtoy) Date: 20061023 13:57 Message: Logged In: YES user_id=28849 Maxima uses the substitution t = exp(y) to change the integral from 0 to 1 to 0 to inf. Then it uses its routine to handle this infinite integral by converting it to an integral from minf to inf, because the integrand is even. Finally, it uses rectzto%pi2 to integrate this final integrand. rectzto%pi2 needs to find the poles of the denominator. I'm guessing it's getting that wrong.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1582625&group_id=4933 
From: SourceForge.net <noreply@so...>  20061105 02:44:57

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: Closed >Resolution: Fixed Priority: 5 Private: No 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: 20061104 21:44 Message: Logged In: YES user_id=28849 The bug is really in $TAYLOR. A workaround is to call $RATSIMP in RESM1 to simplify the pole somewhat. Closing this bug.  Comment By: Raymond Toy (rtoy) Date: 20061104 11:54 Message: Logged In: YES user_id=28849 Not sure if this is right, but the maxima calculates the roots of 17*x^4+64*x^3+96*x^2+16 in a rather messy form. This seems to confuse $residue (used in RES). If we modify the calls to $residue to call $rectform for the pole to simplify it, this integral works. Not exactly sure whether $residue should do this itself or if RES should do it.  Comment By: Raymond Toy (rtoy) Date: 20061104 11:03 Message: Logged In: YES user_id=28849 For the record, here's is what is happening. The integral is converted to an integral from 0 to inf. Since it's still rational, it uses contour integration over the poles of the rational inside the keyhole contour. To compute this, a partial fraction expansion is done, and all parts are integrated separately. This works until the rational (4*x^2+8*x+4)/(17*x^4+64*x^3+96*x^2+64*x+16) is integrated. At this point the function RES is called and gets a division by zero. Not sure why yet. Perhaps some confusion on computing the residues for the complicated roots of the denominator above?  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 