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}
(89) 
_{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...>  20030712 03:22:11

Bugs item #769988, was opened at 20030711 23: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=769988&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: Warning for nonpolynomial algsys Initial Comment: Solve for multiple variables calls Algsys. As it says (clearly!) in the documentation, this only works for polynomial equations. It would be useful, I think, if we would give a warning (or an error?) when a nonpolynomial equation were passed to algsys, e.g. (C1) solve(sqrt(a^2+b^2)=0,[a,b]) Warning: Solve/Algsys can only solve for multiple variables when the equations are polynomial. The equation sqrt(a^2+b^2)=0 is not polynomial. (D1) [] This is a common beginner's error, I think, encouraged of course by the fact that the command is called "solve"  you'd think it could solve any simple equation....  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=769988&group_id=4933 
From: SourceForge.net <noreply@so...>  20030712 03:07:26

Bugs item #769985, was opened at 20030711 23:07 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=769985&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: sign(rat(x)) fatal error/FIX Initial Comment: sign(rat(1)) => fatal error FIX $sign needs to call SPECREPCHECK, e.g. (defmfun $sign (x) (setq x (specrepcheck x)) ...  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=769985&group_id=4933 
From: SourceForge.net <noreply@so...>  20030712 02:19:49

Bugs item #769910, was opened at 20030711 18:22 Message generated for change (Comment added) made by macrakis 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  >Comment By: Stavros Macrakis (macrakis) Date: 20030711 22:19 Message: Logged In: YES user_id=588346 Hmm. Further experimentation shows that with assume(a*b): asksign(a*b*c) asks the sign of a*b*c, not just c asksign(a^2*b) asks the sign of a^2*b and most surprisingly asksign atan(a*b) asks the sign of atan(a*b), not just a*b. This one is actually easy to fix: in signoddinc, use sign1 rather than sign. The first two cases can be explained by assuming that it doesn't check the sign of the a*b subexpression, since it doesn't "notice" it as a subexpression. It's not clear how you'd fix that: do you really want signmtimes to check all 2^nn2 subproducts of a lengthn product to see if they're in the database? This will rarely be useful and is expensive. Perhaps the database needs to keep a list of "terms included in products".... There are similar issues with sums. Consider assume (m>n,n>0); sign(mn)=>pos, but sign(mn+1)=>pnz. The original problem can probably be solved by rechecking the sign of the product of the odds before returning from sign1, but you have to be careful to avoid an infinite recursion here.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=769910&group_id=4933 
From: SourceForge.net <noreply@so...>  20030712 01:18:58

Bugs item #769956, was opened at 20030711 20:47 Message generated for change (Settings changed) made by macrakis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=769956&group_id=4933 Category: None Group: None >Status: Closed >Resolution: Invalid >Priority: 1 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: (sourceforge test  ignore) Initial Comment: Tab test aaaTaaaTaaaTaaa aaa aaa aaa aaa aaa aaa aaa aaa aaaSSSSSaaaSSSSSaaaSSSSSaaa  Comment By: Stavros Macrakis (macrakis) Date: 20030711 21:18 Message: Logged In: YES user_id=588346 OK, here's what sourceforge does with tabs and spaces. In the main bug report, they are preserved in the HTML, but are in a P context which compresses all tab/space sequences to a single space. SF does preserve linebreaks by adding <BR /> tags. Followup comments are formatted in PRE, so preserve spaces (though tabs get screwed up).  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=769956&group_id=4933 
From: SourceForge.net <noreply@so...>  20030712 01:18:04

Bugs item #769956, was opened at 20030711 20:47 Message generated for change (Comment added) made by macrakis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=769956&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: (sourceforge test  ignore) Initial Comment: Tab test aaaTaaaTaaaTaaa aaa aaa aaa aaa aaa aaa aaa aaa aaaSSSSSaaaSSSSSaaaSSSSSaaa  >Comment By: Stavros Macrakis (macrakis) Date: 20030711 21:18 Message: Logged In: YES user_id=588346 OK, here's what sourceforge does with tabs and spaces. In the main bug report, they are preserved in the HTML, but are in a P context which compresses all tab/space sequences to a single space. SF does preserve linebreaks by adding <BR /> tags. Followup comments are formatted in PRE, so preserve spaces (though tabs get screwed up).  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=769956&group_id=4933 
From: SourceForge.net <noreply@so...>  20030712 00:47:43

Bugs item #769956, was opened at 20030711 20:47 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=769956&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: (sourceforge test  ignore) Initial Comment: Tab test aaaTaaaTaaaTaaa aaa aaa aaa aaa aaa aaa aaa aaa aaaSSSSSaaaSSSSSaaaSSSSSaaa  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=769956&group_id=4933 
From: SourceForge.net <noreply@so...>  20030712 00:46:42

Bugs item #769860, was opened at 20030711 16:49 Message generated for change (Comment added) made by macrakis 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)  >Comment By: Stavros Macrakis (macrakis) Date: 20030711 20:46 Message: Logged In: YES user_id=588346 Untabified: 2 COS(2 ATAN(q)) (x  q)  + SIN(2 ATAN(q)) 2 q + 1 map(factor,trigexpand(r3)); 2 q 2 (q  1) (q + 1) (x  q)    2 2 2 q + 1 (q + 1)  Comment By: Stavros Macrakis (macrakis) Date: 20030711 20:44 Message: Logged In: YES user_id=588346 Did I forget to untabify? Or is sourceforge compressing spaces now? Testing: aaaTaaaTaaaTaaa aaa aaa aaa aaa aaa aaa aaa aaa aaaSSSSSaaaSSSSSaaaSSSSSaaa  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=769860&group_id=4933 
From: SourceForge.net <noreply@so...>  20030712 00:44:19

Bugs item #769860, was opened at 20030711 16:49 Message generated for change (Comment added) made by macrakis 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)  >Comment By: Stavros Macrakis (macrakis) Date: 20030711 20:44 Message: Logged In: YES user_id=588346 Did I forget to untabify? Or is sourceforge compressing spaces now? Testing: aaaTaaaTaaaTaaa aaa aaa aaa aaa aaa aaa aaa aaa aaaSSSSSaaaSSSSSaaaSSSSSaaa  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=769860&group_id=4933 
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 
From: SourceForge.net <noreply@so...>  20030709 18:06:02

Bugs item #768631, was opened at 20030709 14:06 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=768631&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: dot simplifier doesn't simplify Initial Comment: The expression b . (b+1) . b is equivalent to b^^2 . (b+1) because univariate terms containing the same variable commute in ALL rings. But Maxima doesn't know this. Of course, in this example, Expand gives the correct result, but how about b . (b+1)^^n . b or (b+1)^^n . b . (b+1)^^n Expand can't do those.... This is really an enhancement request, not a bug.... Also, I am not sure whether this belongs in the general simplifier for dot (simpnct), or whether an explicit call to a dotsimplify routine would be better. Maxima 5.9.0  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=768631&group_id=4933 
From: SourceForge.net <noreply@so...>  20030708 18:07:27

Bugs item #767953, was opened at 20030708 14:07 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=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.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=767953&group_id=4933 
From: SourceForge.net <noreply@so...>  20030708 15:36:26

Bugs item #767408, was opened at 20030707 19:01 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=767408&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: plot2d parametric miscalculates yminmax Initial Comment: plot2d([parametric,t*cos(t),t*sin(t),[t,0,2*%pi]]) clips off pieces on the left and the right. For some reason, it is using the ymin/max from plot_options, but calculates the xmin/max from the data. It should either use plot_options for both axes, or determine x/y min/max from the data. If I try deleting [x,...] or [y,...] from plot_options, I get an internal error. Maxima 5.9.0 gcl 2.5.0 mingw Windows 2000 Athlon  >Comment By: Raymond Toy (rtoy) Date: 20030708 11:36 Message: Logged In: YES user_id=28849 With the CVS version, this doesn't clip the plot. In fact, I'm pretty sure the CVS version changed the plot limits for y from a default of +/ 3 to be +/ "number close to largest doublefloat". However, the plot contains 10 line segments, instead of a smooth curve. Probably related to the adaptive plotting stuff.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=767408&group_id=4933 
From: SourceForge.net <noreply@so...>  20030708 05:00:03

Bugs item #767556, was opened at 20030708 01:00 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=767556&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: Distributing operations over = Initial Comment: x * (a=b) => x*a = x*b x + (a=b) => x+a = x+b (a=b)^2 => a^2 = b^2 so why do we have x . (a=b) => x . (a=b) (??) rather than x . a = x . b (a=b)^^2 => (a=b)^^2 (??) etc. I do understand why we have f(a=b) => f(a=b) rather than f(a)=f(b) ... because in general f may be an operation on equations. Some operations nonetheless do distribute over "=", notably diff, taylor, limit, cabs, rectform, realpart, imagpart, etc. integrate is particularly clever, adding an integration constant though mathematical functions such as sin, log, etc. do not.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=767556&group_id=4933 
From: SourceForge.net <noreply@so...>  20030708 04:12:01

Bugs item #767528, was opened at 20030708 00: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=767528&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 2 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: op(box(a)) bogus Initial Comment: op(box(a)) => MBOX (internal name) i.e. ?mbox op(box(a,b)) => MLABOX (internal name) i.e. ?mlabox It is not clear how to fix this because $box is a function, and there are different operators for different numbers of args (why?). Anyway, it is not terribly important.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=767528&group_id=4933 
From: SourceForge.net <noreply@so...>  20030708 01:11:56

Bugs item #767461, was opened at 20030707 21:11 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=767461&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: translate doesn't check return types Initial Comment: five():=block([], modedeclare(function(f),float), 5); translate(f) gives no error message translate clearly has the information necessary to detect this error, since it puts the property function mode:$fixnum onto $five. Compare for that matter: (C54) fivea():=block([r],modedeclare(r,float),r:5,r)$ (C55) translate(fivea)$ (C56) fivea(); (D56) 5.0 (C57) fiveb():=block([],modedeclare(function (fiveb),float),5)$ (C58) translate(fiveb)$ (C59) fiveb(); (D59) 5 Note that declaring a *variable* as float forces operations to be float, whereas declaring a function value to be float does not.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=767461&group_id=4933 
From: SourceForge.net <noreply@so...>  20030708 01:00:36

Bugs item #767454, was opened at 20030707 21:00 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=767454&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: plot of translated fnc incompatible with interp Initial Comment: ********First kind of error ********* f(x):=entier(x)$ plot2d(f(x),[x,0,1]) /* fine */ $ translate(f)$ plot2d(f(x),[x,0,1])$ => can't use nonnumeric string as operand of "" (from the tcl process) ********** Second kind of error ********* plot2d(sin,[x,0,%pi]) => undefined func Instead, you have to say: plot2d(verbify(sin),[x,0,%pi]) Yuck. ****************** Coercefloatfun is responsible for wrapping the input function with ($float ($realpart (meval* ...))). But it does NOT wrap translated functions (or any other function defined in Lisp or natively). It apparently assumes that they produce real, floatingpoint results. That is a poor assumption. It should wrap them with ($float ($realpart ...)) for compatibility with the interpreted version. I don't know exactly what goes wrong after that, but he tcl error log reads: >>>>>>>>>>> can't use nonnumeric string as operand of "" while executing "expr {($max$min)/1.7}" (procedure "plot2dRangesToRadius" line 15) invoked from within "plot2dRangesToRadius {0.0000000000 1.0000000000} {1.0000000000 4.2522806284830684E314} {}" <<<<<<<<<<<< Note that 4.24E314 is a denormalized number; was this created by interpreting a fixnum as a float? Does tcl have some problem handling denormalized numbers?  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=767454&group_id=4933 
From: SourceForge.net <noreply@so...>  20030707 23:01:36

Bugs item #767408, was opened at 20030707 19:01 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=767408&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: plot2d parametric miscalculates yminmax Initial Comment: plot2d([parametric,t*cos(t),t*sin(t),[t,0,2*%pi]]) clips off pieces on the left and the right. For some reason, it is using the ymin/max from plot_options, but calculates the xmin/max from the data. It should either use plot_options for both axes, or determine x/y min/max from the data. If I try deleting [x,...] or [y,...] from plot_options, I get an internal error. Maxima 5.9.0 gcl 2.5.0 mingw Windows 2000 Athlon  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=767408&group_id=4933 
From: SourceForge.net <noreply@so...>  20030707 22:44:13

Bugs item #766778, was opened at 20030706 14:20 Message generated for change (Comment added) made by macrakis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=766778&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Barton Willis (willisb) Assigned to: Nobody/Anonymous (nobody) Summary: declare complex mostly ignored Initial Comment: The functions "is" and "assume" ignore the complex declaration (C1) declare(x,complex); (D1) DONE (C2) is(x^2 + 1 > 0); (D2) TRUE This isn't correct. Additionally, assume doesn't care that x is complex and it allows the assumption (C3) assume(x > 1); (D3) [x > 1] (C4) 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 Until things like this are fixed, at least the documentation for declare should clearly state the limitations of declaring a symbol to be complex. The functions realpart & friends are the only ones I know of that make use of it; for example (C5) rectform(x); (D5) REALPART(x) + % IMAGPART(x) (C6) Barton  >Comment By: Stavros Macrakis (macrakis) Date: 20030707 18:44 Message: Logged In: YES user_id=588346 Note by the way that besides the above problems, declare/featurep have some important bugs (see bug report 767401). Checking the code, the Complex declaration is also used in simpexpt: abs(rrr)^2 => rrr^2, while abs(ccc)^2 doesn't. Similarly, (rrr^2)^(1/3)=>rrr^(2/3), while (ccc^2)^(1/3) =>abs(ccc)^(1/3).  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=766778&group_id=4933 