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

2
(9) 
3
(5) 
4

5
(5) 
6
(4) 
7

8

9
(3) 
10

11
(7) 
12
(7) 
13

14

15
(2) 
16
(1) 
17

18
(1) 
19
(2) 
20

21
(2) 
22

23
(6) 
24
(5) 
25
(2) 
26
(2) 
27

28

29
(7) 
30



From: SourceForge.net <noreply@so...>  20100902 20:55:55

Bugs item #3058324, was opened at 20100902 20:52 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3058324&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Dieter Kaiser (crategus) Assigned to: Nobody/Anonymous (nobody) Summary: $save must bind *printcircle* to NIL Initial Comment: The function $save saves LispExpressions. Therefore, the global Lisp variable *printcircle* must be bound to NIL. This is an example for wrong output: (%i1) display2d:false$ (%i2) assume(a>0,b>0)$ (%i3) save("maxima.log",all); (%o3) "/home/dieter/workspace/maxima/maxima.log" (%i4) printfile("maxima.log"); ;;; * Mode: LISP; package:maxima; syntax:commonlisp; * (inpackage :maxima) (DSKSETQ $%I1 '((MSETQ) $DISPLAY2D NIL)) (ADDLABEL '$%I1) (DSKSETQ $%O1 NIL) (ADDLABEL '$%O1) (DSKSETQ $%I2 '(($ASSUME) (#1=(MGREATERP) $A 0) (#1# $B 0))) (ADDLABEL '$%I2) (DSKSETQ $%O2 '((MLIST . #1=(SIMP)) ((MGREATERP . #1#) $A 0) ((MGREATERP . #1#) $B 0))) [...] (%o4) "maxima.log" Dieter Kaiser  >Comment By: Dieter Kaiser (crategus) Date: 20100902 22:55 Message: Sorry, I was too fast. You are right. It is no problem to load a file which is stored with *printcircle* bind to T. The only difference is, that the file is more readable, when the data is stored with *printcircle* bind to NIL. So, should we revert the change I have already done? Dieter Kaiser  Comment By: Robert Dodier (robert_dodier) Date: 20100902 22:44 Message: I'm not convinced there is actually a problem here. The Lisp input reader knows how to deal with those #1=... references, right? So the file is actually readable as it stands, if I'm not mistaken. Or is it not guaranteed that Sexpressions with such references are readable?  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3058324&group_id=4933 
From: SourceForge.net <noreply@so...>  20100902 20:44:07

Bugs item #3058324, was opened at 20100902 12:52 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3058324&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Dieter Kaiser (crategus) Assigned to: Nobody/Anonymous (nobody) Summary: $save must bind *printcircle* to NIL Initial Comment: The function $save saves LispExpressions. Therefore, the global Lisp variable *printcircle* must be bound to NIL. This is an example for wrong output: (%i1) display2d:false$ (%i2) assume(a>0,b>0)$ (%i3) save("maxima.log",all); (%o3) "/home/dieter/workspace/maxima/maxima.log" (%i4) printfile("maxima.log"); ;;; * Mode: LISP; package:maxima; syntax:commonlisp; * (inpackage :maxima) (DSKSETQ $%I1 '((MSETQ) $DISPLAY2D NIL)) (ADDLABEL '$%I1) (DSKSETQ $%O1 NIL) (ADDLABEL '$%O1) (DSKSETQ $%I2 '(($ASSUME) (#1=(MGREATERP) $A 0) (#1# $B 0))) (ADDLABEL '$%I2) (DSKSETQ $%O2 '((MLIST . #1=(SIMP)) ((MGREATERP . #1#) $A 0) ((MGREATERP . #1#) $B 0))) [...] (%o4) "maxima.log" Dieter Kaiser  >Comment By: Robert Dodier (robert_dodier) Date: 20100902 14:44 Message: I'm not convinced there is actually a problem here. The Lisp input reader knows how to deal with those #1=... references, right? So the file is actually readable as it stands, if I'm not mistaken. Or is it not guaranteed that Sexpressions with such references are readable?  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3058324&group_id=4933 
From: SourceForge.net <noreply@so...>  20100902 18:52:39

Bugs item #3058324, was opened at 20100902 20:52 Message generated for change (Tracker Item Submitted) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3058324&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Dieter Kaiser (crategus) Assigned to: Nobody/Anonymous (nobody) Summary: $save must bind *printcircle* to NIL Initial Comment: The function $save saves LispExpressions. Therefore, the global Lisp variable *printcircle* must be bound to NIL. This is an example for wrong output: (%i1) display2d:false$ (%i2) assume(a>0,b>0)$ (%i3) save("maxima.log",all); (%o3) "/home/dieter/workspace/maxima/maxima.log" (%i4) printfile("maxima.log"); ;;; * Mode: LISP; package:maxima; syntax:commonlisp; * (inpackage :maxima) (DSKSETQ $%I1 '((MSETQ) $DISPLAY2D NIL)) (ADDLABEL '$%I1) (DSKSETQ $%O1 NIL) (ADDLABEL '$%O1) (DSKSETQ $%I2 '(($ASSUME) (#1=(MGREATERP) $A 0) (#1# $B 0))) (ADDLABEL '$%I2) (DSKSETQ $%O2 '((MLIST . #1=(SIMP)) ((MGREATERP . #1#) $A 0) ((MGREATERP . #1#) $B 0))) [...] (%o4) "maxima.log" Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3058324&group_id=4933 
From: SourceForge.net <noreply@so...>  20100902 17:54:48

Bugs item #3056276, was opened at 20100830 16:24 Message generated for change (Comment added) made by macrakis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3056276&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  Complex Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: abs(x^2) with domain:complex Initial Comment: abs(x)^2,domain:real => x^2 OK abs(x^2),domain:real => x^2 OK abs(x)^2,domain:complex => abs(x)^2 OK abs(x^2),domain:complex => x^2 NO! Should be abs(x)^2 The abs(x)^2 behavior is not documented by the docstring, but makes sense and should also apply to the abs(x^2) case.  >Comment By: Stavros Macrakis (macrakis) Date: 20100902 13:54 Message: Dieter, Barton: yes, declare(x,complex) handles this case. Barton: Do we have a policy for what domain : complex means? It is documented to only deal with powers. The abs case seems like a reasonable extension... but of course lots of things could be 'reasonable extensions'.  Comment By: Barton Willis (willisbl) Date: 20100901 22:58 Message: Declaring x to be complex allows Maxima to return the correct value: (%i1) declare(x,complex)$ (%i2) abs(x^2),domain:complex; (%o2) abs(x)^2 (%i3) abs(x^2),domain:real; (%o3) abs(x)^2 Do we have a policy for what domain : complex means?  Comment By: Stavros Macrakis (macrakis) Date: 20100831 17:14 Message: Maybe one way to simplify the logic here is to consider that domain:complex means that all variables are implicitly declared complex (unless explicitly declared otherwise).  Comment By: Dieter Kaiser (crategus) Date: 20100831 17:07 Message: For the record: Both examples are correct for a symbol declared to be complex: (%i2) declare(z,complex)$ (%i3) abs(z^2),domain:real; (%o3) abs(z)^2 (%i4) abs(z^2),domain:complex; (%o4) abs(z)^2 The wrong simplification of abs(x^2) for a complex domain happens in the simplifier simpabs for the Abs function. The simplifier does not respect the global value of $domain. I think this bug report shows a general problem. Almost all functions in Maxima do not respect the concept of a real and complex domain. There are only some functions which take into account this concept. One example is the simplifier simpexpt for the power function. In Maxima core code I have counted 10 tests of the variable $domain. 9 of these tests are in simpexpt or related functions and 1 test we have in $rootscontract. We have the two functions risplit and $defint which set the global variable $domain to a value. In Maxima share code I have counted one test of the variable $complex. I had a look only at Lisp code. Perhaps, it is necessary to decide if it is desirable to fully implement the concept of a real and domain complex or to cut out the few examples of code, which we have. We always can declare symbols to be complex. This concept is implemented much more complete. Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3056276&group_id=4933 
From: SourceForge.net <noreply@so...>  20100902 17:41:06

Bugs item #3058290, was opened at 20100902 13:41 Message generated for change (Tracker Item Submitted) made by macrakis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3058290&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  Trigonometry Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: tan(%pi*integer) simplification Initial Comment: declare(nnn,integer)$ tan(nnn*%pi) => unsimplified tan(2*nnn*%pi) => 0 But tan has zeroes for all integral multiples of %pi, not just even ones.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3058290&group_id=4933 
From: SourceForge.net <noreply@so...>  20100902 17:35:39

Bugs item #3058208, was opened at 20100902 16:38 Message generated for change (Settings changed) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3058208&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Invalid Priority: 5 Private: No Submitted By: Christopher Fair (quenyen314) Assigned to: Nobody/Anonymous (nobody) Summary: Error in identity Initial Comment: cos(%pi) + i*sin(%pi) evaluates to 1....that is an error it should be cos(%pi)+%i*sin(%pi) evaluating to 1...... On a related note the ln(1) should evaluate to %i*%pi....it does not...%e^(%i*%pi) correctly evaluates to 1 though  >Comment By: Dieter Kaiser (crategus) Date: 20100902 19:35 Message: I do not see a problem. sin(%pi) is 0 and cos(%pi) is 1. Therefore, both of your examples have the value 1. log(1) does not evaluate to %i*%pi by default. But it is possible to set the option variable lognegint or to use the function rectform: (%i4) log(1),lognegint; (%o4) %i*%pi (%i5) rectform(log(1)); (%o5) %i*%pi Furthermore, it is possible to set the option variable lognegint globally: (%i6) lognegint:true; (%o6) true (%i7) log(1); (%o7) %i*%pi Closing this bug report as invalid. Dieter Kaiser  Comment By: Christopher Fair (quenyen314) Date: 20100902 16:40 Message: btw....I made a mistake in that it should be log(1) in maxima log is natural log not ln  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3058208&group_id=4933 
From: SourceForge.net <noreply@so...>  20100902 14:40:50

Bugs item #3058208, was opened at 20100902 08:38 Message generated for change (Comment added) made by quenyen314 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3058208&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Christopher Fair (quenyen314) Assigned to: Nobody/Anonymous (nobody) Summary: Error in identity Initial Comment: cos(%pi) + i*sin(%pi) evaluates to 1....that is an error it should be cos(%pi)+%i*sin(%pi) evaluating to 1...... On a related note the ln(1) should evaluate to %i*%pi....it does not...%e^(%i*%pi) correctly evaluates to 1 though  >Comment By: Christopher Fair (quenyen314) Date: 20100902 08:40 Message: btw....I made a mistake in that it should be log(1) in maxima log is natural log not ln  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3058208&group_id=4933 
From: SourceForge.net <noreply@so...>  20100902 14:38:59

Bugs item #3058208, was opened at 20100902 08:38 Message generated for change (Tracker Item Submitted) made by quenyen314 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3058208&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Christopher Fair (quenyen314) Assigned to: Nobody/Anonymous (nobody) Summary: Error in identity Initial Comment: cos(%pi) + i*sin(%pi) evaluates to 1....that is an error it should be cos(%pi)+%i*sin(%pi) evaluating to 1...... On a related note the ln(1) should evaluate to %i*%pi....it does not...%e^(%i*%pi) correctly evaluates to 1 though  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3058208&group_id=4933 
From: SourceForge.net <noreply@so...>  20100902 02:58:26

Bugs item #3056276, was opened at 20100830 15:24 Message generated for change (Comment added) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3056276&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  Complex Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: abs(x^2) with domain:complex Initial Comment: abs(x)^2,domain:real => x^2 OK abs(x^2),domain:real => x^2 OK abs(x)^2,domain:complex => abs(x)^2 OK abs(x^2),domain:complex => x^2 NO! Should be abs(x)^2 The abs(x)^2 behavior is not documented by the docstring, but makes sense and should also apply to the abs(x^2) case.  >Comment By: Barton Willis (willisbl) Date: 20100901 21:58 Message: Declaring x to be complex allows Maxima to return the correct value: (%i1) declare(x,complex)$ (%i2) abs(x^2),domain:complex; (%o2) abs(x)^2 (%i3) abs(x^2),domain:real; (%o3) abs(x)^2 Do we have a policy for what domain : complex means?  Comment By: Stavros Macrakis (macrakis) Date: 20100831 16:14 Message: Maybe one way to simplify the logic here is to consider that domain:complex means that all variables are implicitly declared complex (unless explicitly declared otherwise).  Comment By: Dieter Kaiser (crategus) Date: 20100831 16:07 Message: For the record: Both examples are correct for a symbol declared to be complex: (%i2) declare(z,complex)$ (%i3) abs(z^2),domain:real; (%o3) abs(z)^2 (%i4) abs(z^2),domain:complex; (%o4) abs(z)^2 The wrong simplification of abs(x^2) for a complex domain happens in the simplifier simpabs for the Abs function. The simplifier does not respect the global value of $domain. I think this bug report shows a general problem. Almost all functions in Maxima do not respect the concept of a real and complex domain. There are only some functions which take into account this concept. One example is the simplifier simpexpt for the power function. In Maxima core code I have counted 10 tests of the variable $domain. 9 of these tests are in simpexpt or related functions and 1 test we have in $rootscontract. We have the two functions risplit and $defint which set the global variable $domain to a value. In Maxima share code I have counted one test of the variable $complex. I had a look only at Lisp code. Perhaps, it is necessary to decide if it is desirable to fully implement the concept of a real and domain complex or to cut out the few examples of code, which we have. We always can declare symbols to be complex. This concept is implemented much more complete. Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3056276&group_id=4933 