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}
(45) 
_{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 20:23:34

Bugs item #635627, was opened at 20021108 13:35 Message generated for change (Comment added) made by macrakis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=635627&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: subst([...] is orderdependent Initial Comment: I would have expected subst([a=...,b=...],...) to substitute a and b simultaneously (like Lisp Sublis), but it does not, and it simplifies along the way. Here are some cases where it matters. The most obvious case is subst([b=c,a=b],b) => c This means that subst cannot be used to permute variables, e.g. subst([x=y,y=x],...) That is not good.  But there are other cases:  subst([a=0,b=0],atan2(a,b)) Depending on the answers to a>0 etc., this can return 0 or %pi, whereas subst([b=0,a=0],...) can return pi/2 or  pi/2. I believe that it should give the error: atan2(0.0) has been generated.  subst(["="="+","["="*"],[x=1,x=2]); gives (x+1) * (x+2) as expected, but subst(["["="*","="="+"],[x=1,x=2]); gives x^2+2 ((It would have been nice if minus were nary, so that I could use "="=""...))  These two cases can be worked around by turning simp off temporarily, e.g. subst(["["="*","="="+"],[x=1,x=2]), simp:false; but the workaround for the first case is much clumsier: subst([x=x0,y=x,x0=y],...)  >Comment By: Stavros Macrakis (macrakis) Date: 20030712 16:23 Message: Logged In: YES user_id=588346 Another case where simultaneous substitution is necessary... subst([a=[1,2],b=[3,4]],a+b) => [[4,5],[5,6]] instead of the expected [4,6] because [1,2]+b => [1+b,2+b], then 1+[3,4] => = [4,5] etc. I am arguing that simultaneous substitution is the only reasonable default behavior.  Comment By: Stavros Macrakis (macrakis) Date: 20021119 14:48 Message: Logged In: YES user_id=588346 Sublis is broken for operators, e.g. sublis(["+"="*"],x+y) And the online documentation (describe) of subst does not mention the parallel substitution issue. I do not think we need both subst([...]) and sublis([...]...). My guess is that sublis was defined before subst was extended to cover the multiple substitution case.  Comment By: Nobody/Anonymous (nobody) Date: 20021116 11:43 Message: Logged In: NO The info tells you to use SUBLIS if you want to do substitution in parallel.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=635627&group_id=4933 
From: SourceForge.net <noreply@so...>  20030712 20:05:21

Bugs item #740134, was opened at 20030519 18:13 Message generated for change (Comment added) made by macrakis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=740134&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: sum evals first argument inconsistently Initial Comment: Consider foo: i^2; sum('foo,i,0,2) => 3*foo (correct) sum(foo,i,0,2) => 3*i^2 WRONG sum(foo,i,0,n) => 'sum(i^2,i,0,n) (correct) In the case where upperlimitlowerlimit is a known integer, simpsum is checking whether foo is free of i *before* evaluating foo. I believe the correct way to handle this case is as follows: First evaluate foo with i bound to itself, and check if that result is free of i. If so, return the product. If not, *substitute* (don't evaluate) i=lowerlimit, i=lowerlimit+1, etc. This means that sum(print(i),i,1,2) would print "i", and not "1 2". That makes it consistent with Integrate: integrate('foo,i,0,2) => 2*foo (correct) integrate(foo,i,0,2) => 8/3 (correct) integrate(foo,i,0,n) => n^3/3 (correct) It also makes it consistent with Integrate in the presence of sideeffects: integrate(print(i),i,0,1) prints i sum(print(i),i,0,1) currently prints 0 1 but in this proposal would print i It is true that it would also create some funny situations. Currently, sum(integrate(x^i,x),i,0,2) evaluates correctly to x+x^2/2+x^3/3. Under this proposal, it would also evaluate *correctly*, but would first ask whether i+1 is zero or nonzero. Unless, that is, simpsum binds i to be an integer and to have a value >=lowerlimit and <=upperlimit (which is a sensible thing to do anyway). Now consider sum(integrate(1/(x^i+1),i),i,0,1) This currently correctly evaluates to x/2+log(x+1). Under the proposal, however, it would evaluate to a sum of noun forms, since the integral does not exist in closed form. I think we can live with that; an ev (...,integrate) takes care of it. But I still like the proposal. After all, if you set the result of the integration expression above to a temporary variable (which seems like a sensible thing to do), you will run into the original bad behavior.  >Comment By: Stavros Macrakis (macrakis) Date: 20030712 16:05 Message: Logged In: YES user_id=588346 More problems with the interaction between sumevaluation and hash arrays: (C1) f[i](x):=x^i$ (C2) g[i](x):=x^i$ (C3) h[i](x):=x^i$ (C4) f[i]; (D4) LAMBDA([x],x^i) (C5) g[i](t); (D5) t^i /* fine so far */ (C6) sum(f[i](x),i,0,n); (D6) 'SUM(LAMBDA([x],x^i)(x),i,0,n) /* oops, why are we seeing the lambda form here? This is some sort of partial evaluation.... */ (C7) sum(g[i](x),i,0,n); (D7) 'SUM(LAMBDA([x],x^i)(x),i,0,n) /* and here */ (C8) sum(h[i](x),i,0,n); (D8) 'SUM(h[i](x),i,0,n) /* but here we're not getting h[i] to evaluate at all, which is consistent with other cases, e.g.: */ (C9) sum(integrate(x^i,x),i,0,n); (D9) 'SUM(INTEGRATE(x^i,x),i,0,n);  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=740134&group_id=4933 
From: SourceForge.net <noreply@so...>  20030712 19:38:35

Bugs item #770258, was opened at 20030712 15:38 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=770258&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: redefining builtin functions (binom) Initial Comment: This is a documentation issue, an error message issue, and a semantics issue.... binom() is defined as an alias for binomial(), but this is not mentioned in the documentation. I wanted to use binom for the explicit form (in terms of factorials) and when I said binom(a,b):=... was surprised to get Warning  you are redefining the MACSYMA command BINOMIAL This redefines the verb form, but not the noun form, so if you now enter binom(2,x), you get back binomial(2,x), and NOT 2/((2x)!*x!). You can only get that using ev (...,binomial) or by explicitly using verbify(binomial). This is all rather unintuitive. I think that more "natural" ways to do things would be either: 1) forbid redefining builtins; or 2) when they're redefined, remove their simplification properties etc. and have them operate like normal functions; or 3) at least remove the alias which makes it function as the noun form on input  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=770258&group_id=4933 
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 