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}
(46) 
2016 
_{Jan}
(76) 
_{Feb}
(53) 
_{Mar}
(88) 
_{Apr}
(79) 
_{May}
(62) 
_{Jun}
(65) 
_{Jul}
(37) 
_{Aug}
(23) 
_{Sep}
(108) 
_{Oct}
(68) 
_{Nov}
(66) 
_{Dec}
(47) 
2017 
_{Jan}
(55) 
_{Feb}
(11) 
_{Mar}
(30) 
_{Apr}
(19) 
_{May}
(14) 
_{Jun}
(10) 
_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 


1
(2) 
2

3
(1) 
4

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

9
(7) 
10
(5) 
11
(3) 
12
(2) 
13
(8) 
14
(10) 
15
(1) 
16
(12) 
17
(4) 
18
(14) 
19
(9) 
20
(1) 
21
(10) 
22
(5) 
23
(3) 
24
(2) 
25
(8) 
26
(6) 
27

28
(5) 
29
(2) 
30
(3) 
31
(10) 



From: SourceForge.net <noreply@so...>  20070119 22:07:05

Bugs item #1639890, was opened at 20070119 16: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=1639890&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: 3 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Barton Willis (willisbl) Summary: conjugate(log(1 + %i * y)), with y # 0 Initial Comment: (%i1) assume(notequal(y,0))$ (%i2) conjugate(log(1 + %i*y)); (%o2) conjugate(log(%i*y1)) Since y # 0, 1 + %i * y isn't on the negative real axis. So conjugate should commute with log. (This is mostly a feature request, not a bug.)  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1639890&group_id=4933 
From: SourceForge.net <noreply@so...>  20070119 20:03:01

Bugs item #1629724, was opened at 20070107 01:18 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1629724&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: Share Libraries Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Documentation in fourie pkg, meaning of p in fourier(f,x,p) Initial Comment: quoted from the mailing list: Daniel Lakeland wrote: >I'm confused by the documentation for the fourier package. In the >following: > >Function: fourier (f, x, p) > > Returns a list of the Fourier coefficients of f(x) defined on the > interval [%pi, %pi]. > >what is the role of "p" ??? > >From a brief look at the code, it seems that p is used to indicate the interval [p, p]. I think the documentation is wrong about the interval being %pi to %pi. Ray  >Comment By: Raymond Toy (rtoy) Date: 20070119 15:02 Message: Logged In: YES user_id=28849 Originator: NO Fixed documentation to say interval is [p, p] instead of [%pi,%pi].  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1629724&group_id=4933 
From: SourceForge.net <noreply@so...>  20070119 19:55:41

Bugs item #1631105, was opened at 20070108 22:44 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1631105&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 Private: No Submitted By: Robert Dodier (robert_dodier) Assigned to: Nobody/Anonymous (nobody) Summary: integrate(sin(n*x)*x, x) => fixnum overflow Initial Comment: When n is a literal integer too big to fit into a fixnum, integrate(sin(n*x)*x, x) either triggers an error message (SBCL, Clisp) or silently overflows and produces an incorrect result (GCL). The overflow appears to happen in PEXPT (src/rat3a.lisp). It might be possible to fix this problem by simply removing all the (DECLARE (FIXNUM ...)) stuff, but at present there's nothing to gain by that, since if there's no fixnum overflow then the PCOEFADD/PEXPT linear time bug comes into play (SF bug # 1631094).  >Comment By: Raymond Toy (rtoy) Date: 20070119 14:55 Message: Logged In: YES user_id=28849 Originator: NO Bug 1631094 fixed, so this doesn't show up there anymore. However, I think, in general, we should remove the (DECLARE (FIXNUM ...)) anyway, since, clearly, there are scenarios where it is not a fixnum. I think this also means replacing things like f*, f+ with *, +, respectively. However, this might slow down these operations. Would it slow them down enough to matter? But slow and right is better than fast and wrong.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1631105&group_id=4933 
From: SourceForge.net <noreply@so...>  20070119 18:44:49

Bugs item #1638731, was opened at 20070118 09:43 Message generated for change (Comment added) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1638731&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: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: abs(x^k) with k declared integer Initial Comment: For a *declared* integer k, I think we should allow abs(x^k) > abs(x)^k. With this change, for example, sum(abs(x^k),k,0,inf), simpsum > 1/(1abs(x)), when abs(x) < 1. This isn't really a bug, but feature requests seem to get lost.  >Comment By: Barton Willis (willisbl) Date: 20070119 12:44 Message: Logged In: YES user_id=895922 Originator: YES Yes, I think that z^a = z^a, for all real a is an identity. I decided not to do this because: (1) I wasn't sure I wanted Maxima to ask questions: conjugate(z^asin(x)) > is (x1)*(x+1) positive, negative, or zero? I think asksign is basically brokenit sometimes asks the same question several times, asks impossible to answer questions, and the final result contains no record of the user choices. (2) I'm not confident that featurep(e, 'real) is trustworthy. That was my thinking, so I choose to check for an integer exponent. There is an argument that it's a good thing to write code that exposes bugs or weaknesses (it might motivate somebody to fix them).  Comment By: Stavros Macrakis (macrakis) Date: 20070119 11:11 Message: Logged In: YES user_id=588346 Originator: NO Isn't this true for all real k (even with complex x)? After all, Maxima assumes principal value, i.e. positive real, for pos^k.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1638731&group_id=4933 
From: SourceForge.net <noreply@so...>  20070119 18:03:26

Bugs item #1631094, was opened at 20070108 22:20 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1631094&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: Fixed Priority: 5 Private: No Submitted By: Robert Dodier (robert_dodier) Assigned to: Nobody/Anonymous (nobody) Summary: integrate(sin(n*x)*x, x) => linear time when n is an integer Initial Comment: When n is a liternal fixnum, integrate(sin(n*x)*x, x) eventually invokes PCOEFADD and then PEXPT n times. This takes a very long time when n is a large fixnum. But for symbolic n, integrate returns immediately (with the correct result). Not sure what's going on here. PCOEFADD and PEXPT appear to be called from the Risch code, after (I'm guessing) reformulating the sine as a complex exponential. A separate issue is that the integration fails where n is too big to fit into a fixnum. I'll make a separate report about that.  >Comment By: Raymond Toy (rtoy) Date: 20070119 13:03 Message: Logged In: YES user_id=28849 Originator: NO Fixed in CVS. We look for a trig argument of the form n*x+b where n is a number and b is free of x. Then we use the substitution y=n*x+b to evaluate the integral.  Comment By: Robert Dodier (robert_dodier) Date: 20070108 22:45 Message: Logged In: YES user_id=501686 Originator: YES The fixnum overflow bug is # 1631105.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1631094&group_id=4933 
From: SourceForge.net <noreply@so...>  20070119 17:47:36

Bugs item #1639678, was opened at 20070119 11:18 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1639678&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: Kirill Smelkov (kirr) Assigned to: Nobody/Anonymous (nobody) Summary: 3*sqrt(2)/sqrt(3)/sqrt(6) != 1 Initial Comment: Maxima can't simplify this to 1:: (%i1) 3*sqrt(2)/sqrt(3)/sqrt(6); 3 sqrt(2) (%o1)  sqrt(3) sqrt(6)  (%i2) %^2; (%o2) 1 (%i3) build_info(); Maxima version: 5.11.0cvs Maxima build date: 19:58 1/12/2007 host type: i686pclinuxgnu lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.6  >Comment By: Raymond Toy (rtoy) Date: 20070119 12:47 Message: Logged In: YES user_id=28849 Originator: NO radcan(%o1) > 1.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1639678&group_id=4933 
From: SourceForge.net <noreply@so...>  20070119 17:11:08

Bugs item #1638731, was opened at 20070118 10:43 Message generated for change (Comment added) made by macrakis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1638731&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: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: abs(x^k) with k declared integer Initial Comment: For a *declared* integer k, I think we should allow abs(x^k) > abs(x)^k. With this change, for example, sum(abs(x^k),k,0,inf), simpsum > 1/(1abs(x)), when abs(x) < 1. This isn't really a bug, but feature requests seem to get lost.  >Comment By: Stavros Macrakis (macrakis) Date: 20070119 12:11 Message: Logged In: YES user_id=588346 Originator: NO Isn't this true for all real k (even with complex x)? After all, Maxima assumes principal value, i.e. positive real, for pos^k.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1638731&group_id=4933 
From: SourceForge.net <noreply@so...>  20070119 17:03:19

Bugs item #1639703, was opened at 20070119 12:03 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=1639703&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: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: (8.0)^(1/3.1),numer gives real result Initial Comment: (8.0)^(1/3.1),numer => 1.955777072670865 This is the correct absolute value, but the result should not be real: ex:(8.0)^(1/3.1) ev(ex,numer) => 1.955777072670865 carg(ex) => 0.32258064516129 %pi float(carg(ex)) => 1.013416985028966 realpart(ex) => 1.034535683665508 imagpart(ex) => 1.659758981662024 ex,float and ex,bfloat are OK.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1639703&group_id=4933 
From: SourceForge.net <noreply@so...>  20070119 16:18:55

Bugs item #1639678, was opened at 20070119 19:18 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=1639678&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: Kirill Smelkov (kirr) Assigned to: Nobody/Anonymous (nobody) Summary: 3*sqrt(2)/sqrt(3)/sqrt(6) != 1 Initial Comment: Maxima can't simplify this to 1:: (%i1) 3*sqrt(2)/sqrt(3)/sqrt(6); 3 sqrt(2) (%o1)  sqrt(3) sqrt(6)  (%i2) %^2; (%o2) 1 (%i3) build_info(); Maxima version: 5.11.0cvs Maxima build date: 19:58 1/12/2007 host type: i686pclinuxgnu lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.6  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1639678&group_id=4933 