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}

S  M  T  W  T  F  S 







1
(1) 
2

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

9
(100) 
10
(57) 
11
(1) 
12
(11) 
13
(2) 
14
(2) 
15
(2) 
16

17
(5) 
18
(1) 
19

20

21

22

23

24
(1) 
25

26
(2) 
27
(4) 
28
(1) 
29

30
(5) 






From: SourceForge.net <noreply@so...>  20060410 15:16:10

Bugs item #1467778, was opened at 20060410 09:16 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=1467778&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: Robert Dodier (robert_dodier) Assigned to: Nobody/Anonymous (nobody) Summary: Debug output provokes Clisp complaint about closed stream Initial Comment: Sometimes the quadpack functions want to print debug messages. Clisp doesn't like that, GCL and SBCL think it's OK. I don't know a workaround. Probably the problem has something to do with the way Fortran WRITE statements get translated into Lisp. Clisp 2.34: (%i1) quad_qags (sin(x), x, 0, 200*%pi), numer; Maxima encountered a Lisp error: WRITECHAR on #<CLOSED IO TERMINALSTREAM> is illegal GCL 2.6.7: (%i1) quad_qags (sin(x), x, 0, 200*%pi), numer; Compiling gazonk0.lsp. [...] ***MESSAGE FROM ROUTINE DQAGS IN LIBRARY SLATEC. ***INFORMATIVE MESSAGE, PROG CONTINUES, TRACEBACK REQUESTED * ABNORMAL RETURN * ERROR NUMBER = 2 * ***END OF MESSAGE (%o1) [ 2.2784436628435217E13, 3.9575719140433691E12, 21, 2] SBCL 0.9.9: (%i1) quad_qags (sin(x), x, 0, 200*%pi), numer; ***MESSAGE FROM ROUTINE DQAGS IN LIBRARY SLATEC. ***INFORMATIVE MESSAGE, PROG CONTINUES, TRACEBACK REQUESTED * ABNORMAL RETURN * ERROR NUMBER = 2 * ***END OF MESSAGE (%o1) [2.407196885346775e12, 3.955640448980319e12, 21, 2]  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1467778&group_id=4933 
From: SourceForge.net <noreply@so...>  20060410 13:32:50

Bugs item #1152668, was opened at 20050226 19:16 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1152668&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: Closed >Resolution: Fixed Priority: 5 Submitted By: Andreas J Guelzow (aguelzow) Assigned to: Nobody/Anonymous (nobody) Summary: twosided limit under numer:true Initial Comment: Maxima version: 5.9.1 Maxima build date: 20:37 2/23/2005 host type: i686pclinuxgnu lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.6 numer:true; limit(sin(x)/x, x, 0); this should yield 1 but yields UND It looks like the problem is that limit(sin(x)/x, x, 0,PLUS); yields 1 but limit(sin(x)/x, x, 0,MINUS); yields 1.0  >Comment By: Raymond Toy (rtoy) Date: 20060410 09:32 Message: Logged In: YES user_id=28849 Appears to be fixed in CVS. All three limits give 1.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1152668&group_id=4933 
From: SourceForge.net <noreply@so...>  20060410 05:46:23

Bugs item #1122388, was opened at 20050214 07:06 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1122388&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: Open Resolution: None >Priority: 2 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Help Window is edit enabled Initial Comment: Maxima version: 5.9.1 Maxima build date: 7:34 9/24/2004 host type: i686pcmingw32 lispimplementationtype: Kyoto Common Lisp lispimplementationversion: GCL 2.6.5 Help window can be edited! Surely this should be read only.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1122388&group_id=4933 
From: SourceForge.net <noreply@so...>  20060410 05:45:11

Bugs item #1224960, was opened at 20050621 10: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=1224960&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: Volker van Nek (van_nek) Assigned to: Nobody/Anonymous (nobody) Summary: sideeffect with copylist Initial Comment: (%i1) list:[1,[2,2],3]$ (%i2) copy:copylist(list)$ (%i3) copy[2][2]:42$ (%i4) list; (%o4) [1, [2, 42], 3]  Maxima version: 5.9.1 Maxima build date: 7:34 9/24/2004 host type: i686pcmingw32 lispimplementationtype: Kyoto Common Lisp lispimplementationversion: GCL 2.6.5  I expected copylist to be fully functional. That is not the case. I had a look into comm2.lisp where copylist is defined. copylist uses copytoplevel from maxmac.lisp, which I do not understand, but I have doubts, that copylist does really cons recursively in sublists. The effect is, that for a sublist the full pointer is copied. Volker van Nek  >Comment By: Robert Dodier (robert_dodier) Date: 20060409 23:45 Message: Logged In: YES user_id=501686 $COPYMATRIX, $COPYLIST, and $COPY in src/comm2.lisp all call COPYTREE now, avoiding side effect. Change was put in place sometime before 5.9.3. Closing this report as fixed.  Comment By: Robert Dodier (robert_dodier) Date: 20050901 23:58 Message: Logged In: YES user_id=501686 Moving this item out of the category "fix for 5.9.2" since I don't see it as necessary to fix before releasing 5.9.2; there are lot of bugs of similar (moderate) severity.  Comment By: Barton Willis (willisbl) Date: 20050831 09:07 Message: Logged In: YES user_id=895922 The function copytree copies any Maxima expression  whether it matters or not. With my 'copy' function, I suppose some users might think they need to do things like x : copy(y^2) instead of just x : y^2. Maybe we should stick to functions copylist and copymatrix that both call copytree. Barton  Comment By: Robert Dodier (robert_dodier) Date: 20050831 08:49 Message: Logged In: YES user_id=501686 I agree that copylist and copymatrix should be "deep" copies. The issue that I see is that most Maxima expressions cannot be modified inplace (ignoring Lisp hacking here). Lists and matrices are the only two kinds of expressions which allow inplace modification. So a copy operation can be faster and use less memory if it only actually copies lists and matrices. (I consider faster and less memory a significant issue, as I don't want to rule out the use of Maxima on large problems.) Does copytree distinguish lists and matrices from other Maxima expressions?  Comment By: Barton Willis (willisbl) Date: 20050625 14:04 Message: Logged In: YES user_id=895922 One fix is to replace copytoplevel with copytree. (defmfun $copylist (x) (if (not ($listp x)) (merror "argument not a list  copylist:~%~m" x)) (cons (car x) (copytree (cdr x)))) I don't know why copylist doesn't just do copytree on all of x. A second fix (change the error message too): (defun $copylist (x) (if ($listp x) (copytree x) (merror "The argument to 'copylist' must be a list; instead the argument was ~:M" x))) Finally, I don't understand the need for copylist and copymatrix. What's wrong with simply copy (maybe this copy doesn't work with maxima arrays? Anything else?) (defun $copy (x) (copytree x)) Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1224960&group_id=4933 
From: SourceForge.net <noreply@so...>  20060410 05:39:47

Bugs item #1202155, was opened at 20050514 18:31 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1202155&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: 3 Submitted By: Robert Dodier (robert_dodier) Assigned to: Nobody/Anonymous (nobody) Summary: clabels, dlabels, elabels recognized by kill and save Initial Comment: $clabels, $dlabels, $elabels are recognized as special keywords by kill and save. These should probably be changed to $ilabels, $olabels, and $tlabels, respectively. The only instances of $clabels, $dlabels, and $elabels are in dskfn.lisp (save code) and suprv1.lisp (kill code).  >Comment By: Robert Dodier (robert_dodier) Date: 20060409 23:39 Message: Logged In: YES user_id=501686 clabels, dlabels, elabels were changed to inlabels, outlabels, and linelabels sometime before 5.9.3. Documentation for kill was updated accordingly.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1202155&group_id=4933 
From: SourceForge.net <noreply@so...>  20060410 05:30:29

Bugs item #711727, was opened at 20030329 00:10 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=711727&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: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: Assume DB context names interfere with variables Initial Comment: This is a very hard bug to believe. And it was very hard to reproduce, because it only bites under very particular circumstances. block([context:b],assume(b>c,c>a),sign(bc)); returns NEG, which is incorrect. The *name* of the context is important. It must be the same as the larger variable. The context name may be quoted (context:'b) or not  it doesn't matter. There must be TWO assumptions, with related variables. But the order doesn't matter. So apparently the context name is somehow getting mixed up with the variables within the context.  Comment By: Stavros Macrakis (macrakis) Date: 20030329 00:11 Message: Logged In: YES user_id=588346 Oh, yes, I should mention that to be sure that there are no extraneous issues, I did the testing each time in a completely fresh Maxima (restarted, not just Kill(all)). Maxima 5.9.0 GCL 2.5.0 mingw32 Windows 2000  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=711727&group_id=4933 
From: SourceForge.net <noreply@so...>  20060410 05:30:29

Bugs item #1052382, was opened at 20041022 12:33 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1052382&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: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: assume hard to use programmatically Initial Comment: assume(r>0 and r<1) works fine. However, if I have a function withassume(pred,expr) := ( assume(pred), expand(expr) ); you get withassume(r>0 and r<1, abs(r)) => ERROR: can't eval predicate r>0 Quoting doesn't help: withassume('(r>0 and r<1), abs(r)) => error withassume('('(r>0) and '(r<1)), abs(r)) => error withassume(('"and")(r>0) and '(r<1)), abs(r)) => error withassume('("and")(r>0) and '(r<1)), abs(r)) => error There is a workaround, however: withassume(pred,expr) := ( apply('assume,[pred]), expand(expr) ); You still have to quote the argument, but it works now: withassume('(r>0 and r<1), abs(r)) => r Alternatively, you can use the noun form of AND: withassume('("and")(r>0,r<1),abs(r)) => r Yuck in both cases.  Discussion The underlying problem is that "is", "assume", "forget", etc. quote their arguments then depend on their own little idiosyncratic evaluator.... Also that nounform logical connectives (and, or, if) aren't really supported. Maxima version: 5.9.0.9beta2 Maxima build date: 10:50 7/27/2004 host type: i686pcmingw32 lispimplementationtype: Kyoto Common Lisp lispimplementationversion: GCL 2.6.3  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1052382&group_id=4933 
From: SourceForge.net <noreply@so...>  20060410 05:30:29

Bugs item #903166, was opened at 20040223 19:04 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=903166&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: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: assume works for real values only Initial Comment: assume(notequal(x,%i)) causes an error. cf 752332 Though of course there is no order relation on complexes, equal/notequal are perfectly meaningful. If we can't fix this easily (which we probably can't, alas), then at least it should be documented that assume only handles reals.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=903166&group_id=4933 
From: SourceForge.net <noreply@so...>  20060410 05:30:29

Bugs item #769884, was opened at 20030711 15:27 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=769884&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: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: Inconsistency in Assume Initial Comment: Simple assume works: (C1) assume(a>b); (D1) [ a > b] Assume of negations works: (C2) assume(not c>d); (D2) [d >= C] Assume of 'and' works: (C3) assume(e>=f and e<=f); (D3) [e >= f, f >= e] But assume of 'and' with negation doesn't: (C4) assume(g>=h and not(g>h)); MACSYMA was unable to evaluate the predicate: g >= h  an error. Quitting. To debug this try DEBUGMODE  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=769884&group_id=4933 
From: SourceForge.net <noreply@so...>  20060410 05:30:29

Bugs item #1041570, was opened at 20041006 10:05 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1041570&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: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: assume(abs(x)<1) should imply x<1 and x>1 Initial Comment: assume(abs(x)<1)$ sign(x1) => doesn't know (should be NEG) sign(1x) => doesn't know (should be POS) assume(x>1) => doesn't notice contradiction The easy fix is of course to make the original assumption add x<1 and x>1 to the database, but how do you ensure that they get *removed* if you remove (forget) the original assertion. And what if x<1 has been explicitly added in the meantime? Same problem in the reverse direction: assume(y<1,y>1)$ sign(abs(y)1) => PNZ (should be NEG)  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1041570&group_id=4933 
From: SourceForge.net <noreply@so...>  20060410 05:30:29

Bugs item #1318843, was opened at 20051008 14:52 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1318843&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: Robert Dodier (robert_dodier) Assigned to: Nobody/Anonymous (nobody) Summary: assume failure to deduce, and consequent infinite looping Initial Comment: assume (a > 0, b > 0, c > 0, d > 0); assume (c*s + d < 0); assume (equal (c*r + d, 0)); At this point, r = d/c and s < d/c, so s < r. However, integrate ((a*x+b)/(c*x+d), x, r, s); => Is s  r positive, negative, or zero? response: n; => a solution response: p; or z; => somebody calls ASKSIGN1 over and over 1> (ASKSIGN1 ((MPLUS SIMP) ((MTIMES SIMP RATSIMP) 1 $D) ((MTIMES SIMP RATSIMP) 1 $C $R))) <1 (ASKSIGN1 $ZERO) 1> (ASKSIGN1 ((MPLUS SIMP) $D ((MTIMES SIMP RATSIMP) $C $R))) <1 (ASKSIGN1 $ZERO) 1> (ASKSIGN1 ((MPLUS SIMP) ((MTIMES SIMP RATSIMP) 1 $D) ((MTIMES SIMP RATSIMP) 1 $C $R))) <1 (ASKSIGN1 $ZERO) 1> (ASKSIGN1 ((MPLUS SIMP) $D ((MTIMES SIMP RATSIMP) $C $R))) <1 (ASKSIGN1 $ZERO) etc etc indefinitely. There are at least 2 problems here. (1) ASKSIGN failed to determine that s < r and therefore there is no need for asking about it. (2) If the response implies something inconsistent with the facts assumed thus far, something (maybe ASKSIGN) goes nuts. I'm inclined to think (2) is more serious. Whatever the limitations of the assume mechanism to derive stuff from facts, it shouldn't freak out under any circumstances. Problem verified in 5.9.0 on Allegro CL 6.2, and 5.9.1.9rc4 on GCL 2.6.7.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1318843&group_id=4933 
From: SourceForge.net <noreply@so...>  20060410 05:30:29

Bugs item #888396, was opened at 20040131 18:34 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=888396&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: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: assume conflates programming and math vrbls Initial Comment: Assume/is is not consistent in its treatment of programming vs. mathematical variables x:1$ assume(x<0) => Inconsistent OK, this presumably is equivalent to assume(1<0) assume('x<0) => Inconsistent Questionable. Should 'x really refer to the *programming variable* x here even though it's quoted? but assume(y<0)$ y:1$ => no error This is inconsistent with the situation above. But I certainly don't want every variable assignment to be checking the Assume database! is(y<0) => false OK, 1<0 is false. is('y<0) => true OK if 'y is treated as a *mathematical variable* and uses the assume database, not the programming variable y. But above, assume('x<0) treats them as the same.  Comment By: Stavros Macrakis (macrakis) Date: 20040202 14:43 Message: Logged In: YES user_id=588346 Clearer demonstration: assume(equal('r,0)) r:10 is(equal('r,0)) => true assume(equal('r,0)) => [inconsistent] assume(not(equal('r,0))) => [redundant] facts() => [ equal(r,0) ] is(equal('r,10)) => false assume(equal('r,10)) => [redundant] is(not(equal('r,10))) => true  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=888396&group_id=4933 
From: SourceForge.net <noreply@so...>  20060410 04:59:02

Bugs item #760722, was opened at 20030625 13:37 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=760722&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: Works For Me Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: errors in integrate and factor Initial Comment: 2 6 4 4 6 2 8 432 a y  504 a y + 6 a y  3 a  2 2 11/2 2 (y + a ) (C26) integrate(%,y,minf,inf); Typeerror in KERNEL::OBJECTNOTFIXNUMERRORHANDLER: NIL is not of type FIXNUM The same error occured in FACTOR on sqrt(y^2+a^2)*(432*a^2*y^6504*a^4*y^4+6*a^6*y^23*a^8)/(2*y^12+12*a^2*y^10+30*a^4*y^8+30*a^8*y^2 +12*a^10*y^2+2*a^12) These errors occured in the following version: Maxima version: 5.9.0 Maxima build date: 21:17 2/9/2003 host type: i386redhatlinuxgnu lispimplementationtype: CMU Common Lisp lispimplementationversion: 18d  >Comment By: Robert Dodier (robert_dodier) Date: 20060409 22:58 Message: Logged In: YES user_id=501686 I don't see the " NIL is not of type FIXNUM" errors cited by the original poster. (1) (432 * a^2 * y^6  504 * a^4 * y^4 + 6 * a^6 * y^2  3 * a^8) / (2*(y^2 + a^2)^(11/2)); integrate(%,y,minf,inf); => 0 after spurious asksign for y and (meaningful) asksign for a. From what I can tell, 0 is correct: realroots applied the numerator of the above expr yields [y = 36136957/33554432,y = 36136957/33554432], and integrating from 0 to 36136957/33554432 and from 36136957/33554432 to inf shows the pieces are equal and opposite. Also quad_qagi (quadpack function for infinite interval) seems to show integral is 0 to within tolerance. (By the way, I got the above expression by inspecting the HTML page source  the ascii art layout is comprehensible that way.) (2) sqrt(y^2+a^2) * (432*a^2*y^6504*a^4*y^4+6*a^6*y^23*a^8) / (2*y^12+12*a^2*y^10+30*a^4*y^8+30*a^8*y^2 + 12*a^10*y^2+2*a^12); factor(%); => pretty much the same expression (no error) Works the same with 5.9.1 / CMUCL 19a and 5.9.3 / Clisp 2.34 (both Linux). Closing this report as "works for me" (but I'll open another about the spurious asksign for y).  Comment By: Stavros Macrakis (macrakis) Date: 20030706 22:05 Message: Logged In: YES user_id=588346 Please use the linear form of expressions  this bug reporting system loses formatting. I believe the original expression was (432*a^2*y^2504*a^4*y^4+6*a^6*y^23*a^9) / (2 * (y^2 + a^2) ^(11/2) ) Is that right? In 5.9.0/gcl/Windows, I don't get the error you report. ON the other hand, Maxima stupidly asks whether y is pos or neg (but y only appears as y^2). It does give a result in terms of a after a few questions. I have no idea whether this result is correct.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=760722&group_id=4933 
From: SourceForge.net <noreply@so...>  20060410 04:09:13

Bugs item #1374700, was opened at 20051206 11:41 Message generated for change (Settings changed) made by robert_dodier 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: 20060213 11: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...>  20060410 04:09:13

Bugs item #1309432, was opened at 20050930 06:19 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1309432&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/cosh(a*x)^2,x,inf,inf); Initial Comment:  Maxima version: 5.9.1 Maxima build date: 16:35 2/10/2005 host type: i686pclinuxgnu lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.6  integrate(1/cosh(a*x)^2,x,inf,inf); Is a positive, negative, or zero? p; (%o3) 0 Correct answer is 2/a.  Comment By: Raymond Toy (rtoy) Date: 20060215 13:23 Message: Logged In: YES user_id=28849 I think this integral fails because polelist is unable to find the roots of z^(4*a)+2*z^(2*a)+1.  Comment By: Stavros Macrakis (macrakis) Date: 20051109 12:39 Message: Logged In: YES user_id=588346 Interestingly, if you exponentialize the expression first, it gets the right answer. But still asks, unnecessarily, the sign of 'a'.  Comment By: Stavros Macrakis (macrakis) Date: 20051109 12:34 Message: Logged In: YES user_id=588346 Interestingly, if you exponentialize the expression first, it gets the right answer. But still asks, unnecessarily, the sign of 'a'.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1309432&group_id=4933 
From: SourceForge.net <noreply@so...>  20060410 04:09:12

Bugs item #1051437, was opened at 20041021 06:21 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1051437&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: David Billinghurst (billingd) Assigned to: Nobody/Anonymous (nobody) Summary: Trig integral error Initial Comment: The integral of 2*COT(x)^2*COS(2*x)/(CSC(2*x)+COT(2*x)); is wrong for maxima5.9.1 (%i1) display2d:false; (%o1) FALSE (%i2) h: 2*COT(x)^2*COS(2*x)/(CSC(2*x)+COT(2*x)); (%o2) 2*COT(x)^2*COS(2*x)/(CSC(2*x)+COT(2*x)) (%i3) ih:integrate(h,x); (%o3) (2*LOG(SIN(x)^2+COS(x)^2+2*COS(x)+1) +2*LOG(SIN(x)^2+COS(x)^22*COS(x)+1) +COS(2*x)) /2 (%i4) ev(ih,x=1.0,numer)ev(ih,x=0.5,numer); (%o4) .6469013090248041 (%i5) quad_qags(h,x,0.5,1); (%o5) [.1686767378171631,3.37999776996994E 15,21,0] (%i6) h2:trigsimp(trigexpand(h)); (%o6) (4*COS(x)^32*COS(x))/SIN(x) (%i7) ih2:integrate(h2,x); (%o7) LOG(COS(x)+1)+LOG(COS(x)1)+2*COS(x)^2 (%i8) ev(ih2,x=1.0,numer)ev(ih2,x=0.5,numer); (%o8) .1686767378171636 The integral over 0.5 < x < 1.0 at %o4 differs from the numerical integral %o5 and the analytic integral of an equivalent expression %o8.  Comment By: Raymond Toy (rtoy) Date: 20060216 08:26 Message: Logged In: YES user_id=28849 This seems to be a bug in the Risch integrator. If you trace(?rischint), you can see h is converted to exponential form and the Risch integrator returns log(exp(%i*x)+1)+log(exp(%i*x)1)+(exp(2*%i*x)4*%i*x)/4. However integrate(trigsimp(exponentialize(h)),x); (which uses the Risch integrator too!) returns 2*log(%e^(%i*x)+1)+2*log(%e^(%i*x)1)+%e^(2*%i*x)/2+%e^(2*%i*x)/22*%i*x I think this simplifies to log(2*cos(x)+2)+log(22*cos(x))+cos(2*x) Differentiating this produces something equal to h.  Comment By: David Billinghurst (billingd) Date: 20041021 06:29 Message: Logged In: YES user_id=365569 Once this is fixed, activate equation (22) in share/contrib/diffequations/tests/rtestode_murphy1.mac  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1051437&group_id=4933 
From: SourceForge.net <noreply@so...>  20060410 04:09:12

Bugs item #1073338, was opened at 20041125 11:21 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1073338&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: Robert Dodier (robert_dodier) Assigned to: Nobody/Anonymous (nobody) Summary: integrate yields incorrect result on rational function Initial Comment: "integrate" yields incorrect results on some rational functions. "Division by 0" is strange. The definite integral below is certainly greater than 0 as the integrand is positive over [0, 1]. "integrate (1/((x3)^4+1/2), x)" returns the noun form, so maybe (maybe) what happens is that the noun form is evaluated at the limits of integration and it's the same, hence 0 is the result. (Just guessing there.) Note that the difference between the two integrands is that one is 1/(something + 1), while the other is 1/(same something + 1/2).  (%i1) integrate (1/((x3)^4+1), x, 0, 1); Division by 0  an error. Quitting. To debug this try DEBUGMODE(TRUE); (%i2) integrate (1/((x3)^4+1/2), x, 0, 1); (%o2) 0 (%i3) build_info (); Maxima version: 5.9.1 Maxima build date: 21:24 9/23/2004 host type: i686pclinuxgnu lispimplementationtype: CMU Common Lisp lispimplementationversion: 19a  Same behavior observed in CVS build of 2004/11/24.  Comment By: Stavros Macrakis (macrakis) Date: 20050130 16:04 Message: Logged In: YES user_id=588346 This is apparently another GCD problem. Fixed by setting the 'algebraic' flag: integrate (1/((x3)^4+1), x, 0, 1),algebraic:true For the indefinite integral, you can factor over the Gaussians then use partfrac: integrate ( partfrac ( gfactor( 1/((x3)^4+1) ), x ), x ) You can simplify the result using ratsimp(rectform(...)) s  Comment By: Nobody/Anonymous (nobody) Date: 20050118 14:17 Message: Logged In: NO Two remarks: The method that Maxima uses to solve such integrals is integration by residues. Trace (residue) shows that this function is called with the correct arguments but answers zeroes for integrate (1/((x3)^4+1/2), x, 0, 1); and runs into a division by zero for the other integral. The indefinite integrals can be solved with changevar: 'Integrate(1/((x3)^4+1/2), x); changevar (%, x  3  y ,y ,x); ev (%, Integrate);  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1073338&group_id=4933 
From: SourceForge.net <noreply@so...>  20060410 04:09:12

Bugs item #1430843, was opened at 20060213 11:10 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1430843&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: Raymond Toy (rtoy) Assigned to: Nobody/Anonymous (nobody) Summary: integrate(x/(1x^2),x) and integrate(x/(x^21),x) Initial Comment: integrate(x/(1x^2),x) and integrate(x/(x^21),x) don't ask if x < 1 or x > 1. Because of this we get two different results, when they should be equivalent, depending on the range of integration.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1430843&group_id=4933 
From: SourceForge.net <noreply@so...>  20060410 04:09:12

Bugs item #1290363, was opened at 20050913 12:39 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1290363&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: Vadim V. Zhytnikov (vvzhy) Assigned to: Nobody/Anonymous (nobody) Summary: integrate((tan(x)^2+1)/tan(x),x,%pi/6,%pi/3)  error Initial Comment: (%i1) integrate((tan(x)^2+1)/tan(x),x,%pi/6,%pi/3); `sign' called on an imaginary argument: 1/4 ( 1)  an error. Quitting. To debug this try debugmode(true); Right result is log(3).  Comment By: Raymond Toy (rtoy) Date: 20060216 07:35 Message: Logged In: YES user_id=28849 This integral is converted to integrate((1+tan(x+%pi/6)^2)/tan(x+%pi/6),x,0,%pi/6) Eventually, rischint is called and the error comes from somewhere in rischint.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1290363&group_id=4933 
From: SourceForge.net <noreply@so...>  20060410 04:09:12

Bugs item #1418010, was opened at 20060129 08:54 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1418010&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: Raymond Toy (rtoy) Assigned to: Nobody/Anonymous (nobody) Summary: integrate(sin(x)/cos(x)^2,x,0,%pi/3) not simplified Initial Comment: If we apply the fix from Bug 137470 (http://sourceforge.net/tracker/index.php?func=detail&aid=1374704&group_id=4933&atid=104933) The result is 1/cos(%pi/3)1/cos(0). This is right but is not simplified to 1.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1418010&group_id=4933 
From: SourceForge.net <noreply@so...>  20060410 04:09:12

Bugs item #1265894, was opened at 20050821 22:27 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1265894&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: Robert Dodier (robert_dodier) Assigned to: Nobody/Anonymous (nobody) Summary: integrate (exp (a*x), x, 0, inf) => 0 after choosing zero Initial Comment: (%i1) integrate (exp (a*x), x, 0, inf); Is a positive, negative, or zero? z; Principal Value(%o1) 0  but  (%i2) a: 0; (%o2) 0 (%i3) integrate (exp (a*x), x, 0, inf); Integral is divergent Observed on 5.9.1cvs / gcl 2.6.6 but same behavior observed in 5.9.1 on cmucl 19a, and 5.9.1cvs / clisp 2.33.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1265894&group_id=4933 
From: SourceForge.net <noreply@so...>  20060410 04:09:11

Bugs item #1047432, was opened at 20041014 17:01 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1047432&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: Integral gives unsimplified erf Initial Comment: assume(m<0)$ integrate((ym)*%e^y^2,y,m,inf); gives a result containing erf(m), which should have simplified to erf(m). Workaround is easy: just do expand(<<result>>,0,0) to force resimplification.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1047432&group_id=4933 
From: SourceForge.net <noreply@so...>  20060410 04:09:11

Bugs item #991628, was opened at 20040715 08: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=991628&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(x^n,x,a,b) wrong for a<0<b Initial Comment: integrate(x^n,x,a,b); Is n positive, negative, or zero? neg; Is n + 1 zero or nonzero? n; Is b  a positive, negative, or zero? pos; => b^(n+1)/(n+1)a^(n+1)/(n+1) (NO!) This is incorrect for (e.g.) n=2, a<0<b: integrate(x^2,x,a,1); Is a  1 positive, negative, or zero? neg; => Integral is divergent (OK) Same thing, but a more dramatic demo: assume(equal(a,1),equal(b,1),equal(n,2)); integrate(x^n,x,a,b) => b^(n+1)/(n+1)a^(n+1)/(n+1) (NO!) vs. integrate(x^2,x,1,1) => Divergent (OK) Also assume(equal(n,2)); integrate(x^n,x,1,1); => (1)^n/(n+1)+1/(n+1) (NO!)  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=991628&group_id=4933 
From: SourceForge.net <noreply@so...>  20060410 04:09:10

Bugs item #887646, was opened at 20040130 07:49 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=887646&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: bogus PV integral [defint(exp(a*x),x,0,inf)] Initial Comment: (C1) defint(exp(a*x),x,0,inf); Is a positive, negative, or zero? zero;Principal Value (D1) 0 This isn't a PV integral; the integral diverges when a == 0. (C2) build_info(); Maxima version: 5.9.0 Maxima build date: 19:10 2/9/2003 host type: i686pcmingw32 lispimplementationtype: Kyoto Common Lisp lispimplementationversion: GCL25.0  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=887646&group_id=4933 
From: SourceForge.net <noreply@so...>  20060410 04:09:10

Bugs item #826627, was opened at 20031019 22:49 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=826627&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 quotient (gcd?) problems Initial Comment: integrate( x*%E^(a*x/2)*SIN(SQRT(ba^2)*x) , x) => Quotient by a polynomial of higher degree Another similar problem: integrate( x*%E^(a*x)*SIN(SQRT(ba^2)*x/2) , x) => quotient is not exact Usually, this sort of problem is solved by changing GCD algorithm (setting the GCD variable), but in this case, all the GCD routines have the same problem. (Problem originally found by Jared Alem in assume (4*b>a^2)$ 'diff(y,x,2) + a*'diff(y,x) + b*y = c*x;) Maxima 5.9.0 gcl 2.5.0 mingw32 W2k Athlon  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=826627&group_id=4933 