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

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 



1
(3) 
2

3
(2) 
4

5

6
(2) 
7
(9) 
8
(6) 
9
(1) 
10

11
(8) 
12
(11) 
13
(1) 
14
(5) 
15
(1) 
16
(1) 
17

18

19
(5) 
20

21

22
(1) 
23
(1) 
24
(1) 
25
(3) 
26

27

28
(1) 
29
(2) 
30

31



From: SourceForge.net <noreply@so...>  20030711 22:54:44

Bugs item #614203, was opened at 20020925 01:08 Message generated for change (Comment added) made by macrakis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=614203&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: Taylor gives undefined limit error Initial Comment: test: (1x^a)/(1+x^a); taylor(test,a,inf,2); asks sign of x1 If you answer pos, it works fine. If you answer zero, it gives "Break: Undefined limit product" and then "Error: Format error: arguments exhausted" (presumably there's some error in the error reporting...). The result should be zero. If you answer neg, it gives "Invalid call to varexpand". I am not sure what the correct result is, but it shouldn't cause an internal error.  >Comment By: Stavros Macrakis (macrakis) Date: 20030711 18:54 Message: Logged In: YES user_id=588346 A simpler case. In this case too, the answer is trivial: since sin(x)1 == 0 , then sin(x)==1 and sin(x)^a == 1 for all a.... taylor(sin(x)^a,a,inf,2); Is SIN(x)  1 positive, negative, or zero? zero; Break: Undefined limit product Error: Format error: arguments exhausted. V "Undefined limit product ~A * ~A in limtimes lim1 lim2" Does the same for f(x) instead of sin(x). The problem appears to be that it doesn't realize that the $zero here is a *constant* zero whereas the $INF is a limiting infinity only. Constant zero * limiting infinity = zero, though of course lmiiting zero * limiting infinity is undefined.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=614203&group_id=4933 
From: SourceForge.net <noreply@so...>  20030711 22:22:24

Bugs item #769910, was opened at 20030711 18:22 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=769910&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: asksign asks redundant question Initial Comment: assume(a*b>0) assume(a+b>0) asksign(a*b) => pos (ok) asksign(a+b) => pos (ok) asksign(a*b*(a+b)) Is a b positive,negative, or zero? But it just answered that correctly! I *am* surprised, I must say, that it doesn't even get is (equal(a,0)) => false since a*b>0 immediately gives you a#0 and b#0. For that matter, assume(not equal (c*d,0)) *does* get is(equal(c,0)) => false. By the way, with those facts, you can deduce that a>0 and b>0, but that would be a feature request, not a bug report. Transcript below. (C1) assume(a*b>0,a+b>0); (D1) [a b > 0, b + a > 0] (C2) asksign(a*b); (D2) POS (C3) asksign(a+b); (D3) POS (C4) asksign(a*b*(a+b)); Is a b positive, negative, or zero? pos; (D4) POS (C5) is(equal(a,0)); MACSYMA was unable to evaluate the predicate: EQUAL(a, 0)  an error. Quitting. To debug this try DEBUGMODE (TRUE);) (C6) assume(not equal(c*d,0)); (D6) [NOT EQUAL(C d, 0)] (C7) is(equal(c,0)); (D7) FALSE (C8) facts(); (D8) [a b > 0, b + a > 0, NOT EQUAL(C, 0), NOT EQUAL(d, 0)] << note how it recorded not equal(c*d,0) >> Maxima 5.9.0 gcl 2.5.0  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=769910&group_id=4933 
From: SourceForge.net <noreply@so...>  20030711 21:59:42

Bugs item #769905, was opened at 20030711 17:59 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=769905&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 4 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: asksign(sin(x)<2) doesn't know Initial Comment: is/asksign don't know the ranges of the common trig functions: is ( sin(x)<2 ) => unknown is ( atan(x) < %pi) => unknown etc.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=769905&group_id=4933 
From: SourceForge.net <noreply@so...>  20030711 21:50:20

Bugs item #769900, was opened at 20030711 17:50 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=769900&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: asksign(a^b) WRONG! Initial Comment: asksign(a^b); Is a pos neg or zero? neg; => neg It does not ask whether b is an integer, or if it's even or odd!!! I believe the correct behavior is: if b is an even integer => pos if b is an odd integer => neg if b is not an integer, ask user about the sign of a^b directly  I suppose we could ask if b is rational, and if so whether it is even/odd (pos), odd/odd (neg), or odd/even (undefined  is actually complex), but why get into that mess?  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=769900&group_id=4933 
From: SourceForge.net <noreply@so...>  20030711 21:28:28

Bugs item #767953, was opened at 20030708 14:07 Message generated for change (Settings changed) made by macrakis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=767953&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) >Summary: Predicate evaluation internal error with bad arg Initial Comment: l: [a+b+c]$ while l do 1; gives an internal error: Error: Bad plist ($a $b $C) Error signalled by QUEUE+P. While should be checking whether its argument is valid. The idiom while (list)... of course comes from Lisp and is not correct in Maxima; it should be while l # [] ... But it should give a reasonable error, not an indecipherable internal error.  Comment By: Stavros Macrakis (macrakis) Date: 20030711 17:23 Message: Logged In: YES user_id=588346 Simpler way to get this error: is([a+b+c]) Of course, this is less likely to be entered by a user.... The root of the error seems to be in mevalp1, whose last clause assumes that an evaluated condition is of the form ((predicate) arg1 arg2) if it is not one of the known relational predicates (=, >, etc.). It's not clear to me what is going on in the last clause of mevalp2  and what isp, truep, and semant are trying to do. Note that semant looks for a VAR property, but I can't find anyplace in the Maxima code that sets a VAR property. My guess is that this was intended to allow not just relational assertions like a>b but also logical assertions like implies(a,b), but that this was never fully implemented. But I am just guessing.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=767953&group_id=4933 
From: SourceForge.net <noreply@so...>  20030711 21:27:30

Bugs item #769884, was opened at 20030711 17:27 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=769884&group_id=4933 Category: None 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...>  20030711 21:23:29

Bugs item #767953, was opened at 20030708 14:07 Message generated for change (Comment added) made by macrakis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=767953&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: while internal error with wrong arg Initial Comment: l: [a+b+c]$ while l do 1; gives an internal error: Error: Bad plist ($a $b $C) Error signalled by QUEUE+P. While should be checking whether its argument is valid. The idiom while (list)... of course comes from Lisp and is not correct in Maxima; it should be while l # [] ... But it should give a reasonable error, not an indecipherable internal error.  >Comment By: Stavros Macrakis (macrakis) Date: 20030711 17:23 Message: Logged In: YES user_id=588346 Simpler way to get this error: is([a+b+c]) Of course, this is less likely to be entered by a user.... The root of the error seems to be in mevalp1, whose last clause assumes that an evaluated condition is of the form ((predicate) arg1 arg2) if it is not one of the known relational predicates (=, >, etc.). It's not clear to me what is going on in the last clause of mevalp2  and what isp, truep, and semant are trying to do. Note that semant looks for a VAR property, but I can't find anyplace in the Maxima code that sets a VAR property. My guess is that this was intended to allow not just relational assertions like a>b but also logical assertions like implies(a,b), but that this was never fully implemented. But I am just guessing.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=767953&group_id=4933 
From: SourceForge.net <noreply@so...>  20030711 20:49:37

Bugs item #769860, was opened at 20030711 16:49 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=769860&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: taylor bind stack overflow: sin(2*atan(x))@q Initial Comment: taylor(sin(2*atan(x)),x,q,1) results in a bind stack overflow (internal error)  try expand appears to be in an infinite recursion. The expansion is wellbehaved, and can be derived using the TaylorMacLaurin formula: r1: taylor(f(x),x,q,1)$ r2: subst(lambda([x],sin(2*atan(x))),f,r1)$ r3: ev(r2,diff,at)$ Which gives: 2 COS(2 ATAN(q)) (x  q)  + SIN(2 ATAN(q)) 2 q + 1 This can be prettified: map(factor,trigexpand(r3)) ...=> 2 q 2 (q  1) (q + 1) (x  q)    2 2 2 q + 1 (q + 1)  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=769860&group_id=4933 