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}
(22) 
_{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...>  20070121 20:14:02

Bugs item #769860, was opened at 20030711 15:49 Message generated for change (Comment added) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=769860&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  Taylor Group: None Status: Open Resolution: None Priority: 5 Private: No 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: Barton Willis (willisbl) Date: 20070121 14:14 Message: Logged In: YES user_id=895922 Originator: NO I don't get a bind stack overflow (5.11, 2.6.8 GCL) (%i1) taylor(sin(2*atan(x)),x,q,1); (%o1) sinh(log(sqrt(q^2+1)*%e^(%i*atan(q)))log(sqrt(q^2+1)*%e^(%i*atan(q))))*%i+(2*cosh(log(sqrt(q^2+1)*%e^(%i*atan(q)))log(sqrt(q^2+1)*%e^(%i*atan(q))))*(xq))/(q^2+1)+... (%i2) map(rectform,%); (%o2) (2*cos(2*atan(q))*(xq))/(q^2+1)+sin(2*atan(q))  Comment By: Stavros Macrakis (macrakis) Date: 20030711 19: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 19: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...>  20070121 20:01:09

Bugs item #623904, was opened at 20021015 22:39 Message generated for change (Comment added) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=623904&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  Taylor Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: Taylor should be contagious in more plac Initial Comment: taylor(x,x,0,1)+x^4 => x + ... (correct) taylor(x,x,0,1)^3 => x^3 + ... (correct) BUT exp(taylor(x,x,0,1)) => %E^x (???) sin(taylor(x,x,0,1)) => sin(x) (???) I'd think that Taylor form should be contagious in these cases, but I haven't looked into how hard that is to do.  >Comment By: Barton Willis (willisbl) Date: 20070121 14:01 Message: Logged In: YES user_id=895922 Originator: NO The trig functions, but not log and exp are now taylor polynomial contagious.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=623904&group_id=4933 
From: SourceForge.net <noreply@so...>  20070121 19:41:06

Bugs item #817516, was opened at 20031003 20:27 Message generated for change (Comment added) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=817516&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  Taylor Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: taylor(xxx)xxx incorrect Initial Comment: Define q: q:(LOG(n)n)/(LOG(n)1)$ Get a series representation around infinity to 1 term: qt: taylor(q,n,inf,1); ((1/LOG(n))+...)*n+(1+1/LOG(n)+...)+... OK so far. Now take the difference of the original q and the series: qdiff: qqt; (11/LOG(n)1/LOG(n)^21/LOG(n)^3 1/LOG(n)^4+...) * n + (1+1/LOG(n)+...)+... taylorinfo(qt) => [[1/LOG(n),ZEROA,1],[n,INF,1]] taylorinfo(qdiff) => [[1/LOG(n),ZEROA,4],[n,INF,4]] The result should have been the same as: qdiffr: taylor(qratsimp(qt),n,inf,1) which gives (almost correctly, cf bug #774065) ZEROA*N + (ZEROA * LOG(N)  ZEROA + ...) +... i.e. 0+... Huh? First of all, the answer is not correct. The initial terms should have cancelled. Secondly, why did it calculate three more terms?  >Comment By: Barton Willis (willisbl) Date: 20070121 13:41 Message: Logged In: YES user_id=895922 Originator: NO With Maxima 5.11, I get (%i1) q:(LOG(n)n)/(LOG(n)1); (%o1) (LOG(n)n)/(LOG(n)1) (%i2) qt: taylor(q,n,'inf,1); `taylor' encountered an unfamiliar singularity in: LOG(n)  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=817516&group_id=4933 
From: SourceForge.net <noreply@so...>  20070121 10:09:25

Bugs item #1639678, was opened at 20070119 19:18 Message generated for change (Comment added) made by kirr 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: Kirill Smelkov (kirr) Date: 20070121 13:09 Message: Logged In: YES user_id=834496 Originator: YES So is this a bug or one should always use radcan?  Comment By: Raymond Toy (rtoy) Date: 20070119 20: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...>  20070120 08:36:04

Bugs item #1633108, was opened at 20070111 12:52 Message generated for change (Comment added) made by andrejv You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1633108&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 Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: infinite sums with simpsum : true Initial Comment: Should be inf, not inf  1: (%i2) sum(exp(k),k,minf,inf),simpsum; (%o2) inf1 I think 'und' is a better value for this sum: (%i3) sum(k,k,minf,inf),simpsum; (%o3) 0 Should be 'und', not 'undefined': (%i4) sum((1)^k,k,0,inf),simpsum; (%o4) undefined Again, should be 'und' (%i5) sum((1)^k,k,minf,inf),simpsum; (%o5) undefined1 At least limit(und1) > und, but limit(undefined1) > undefined1.  >Comment By: Andrej Vodopivec (andrejv) Date: 20070120 09:36 Message: Logged In: YES user_id=1179910 Originator: NO Compare the following (%i1) integrate(x, x, 0, inf); Integral is divergent  an error. Quitting. To debug this try debugmode(true); (%i2) sum(k, k, 0, inf), simpsum; (%o2) inf Since maxima is not very good with infinities (that is infinf = 0 and inf/inf=1), sum should signal an error instead of returning inf for divergent sums. Andrej  Comment By: Robert Dodier (robert_dodier) Date: 20070113 02:27 Message: Logged In: YES user_id=501686 Originator: NO Maybe 1argument limit should be called to clean up results of infinite summations. Although limit has its own problems so I am hesitant about that ...  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1633108&group_id=4933 
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 
From: SourceForge.net <noreply@so...>  20070118 15:48:30

Bugs item #1635372, was opened at 20070114 16:10 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1635372&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: specint returns expression containing internal Lisp variable Initial Comment: assume(p > 0, a > 0, b > 0); sin(a*t)*cosh(b*t^2)*%e^(p*t); radcan(specint(%,t)); => long expression containing failonf24p146test Not sure what's going on here, haven't looked into it.  >Comment By: Raymond Toy (rtoy) Date: 20070118 10:48 Message: Logged In: YES user_id=28849 Originator: NO Oh, it would be a Lisp special, internal to maxima, not exposed to Maxima and not intended for the general user. The default would be to return the noun form. For debugging, I would be to turn it on to enable the old behavior so I can track down the issues more easily.  Comment By: Robert Dodier (robert_dodier) Date: 20070118 10:21 Message: Logged In: YES user_id=501686 Originator: YES About the global variable, I guess I'm not opposed to that. Maybe it can be a Lisp special or maybe it can be in a new Lisp package :specint or something (in either case so it doesn't clutter the Maxima namespace).  Comment By: Raymond Toy (rtoy) Date: 20070117 20:46 Message: Logged In: YES user_id=28849 Originator: NO Since integrate doesn't call specint, I think it should be specint. The only thing preventing me from actually fixing this is that it makes it easy to figure out why specint failed. Now, it's pretty easy to find the cause. As a compromise, perhaps I'll add a global variable (yuck) to control whether the symbol or noun form is returned.  Comment By: Robert Dodier (robert_dodier) Date: 20070116 23:07 Message: Logged In: YES user_id=501686 Originator: YES Yes, I think returning a noun form is the right thing to do here. Not sure whether it should be an integrate noun or specint noun; maybe it doesn't matter too much.  Comment By: Raymond Toy (rtoy) Date: 20070115 19:42 Message: Logged In: YES user_id=28849 Originator: NO This means that maxima thought the integrand looked like t^(v1)*exp(t^2/8/a), but it didn't satisfy the requirements that Re(a) > 0 and Re(v) > 0. At this point it doesn't know how to proceed. I have not convinced myself that this Laplace transform exists. Perhaps we could just return the noun form. If we do that, the answer contains specint(%i/4*exp(b*t^2(p+%i)*t),t) + specint(%i/4*exp(b*t^2(p%i*a)*t)) which is equivalent to specint(exp(b*t^2p*t)*sin(a*t),t)/2.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1635372&group_id=4933 
From: SourceForge.net <noreply@so...>  20070118 15:43:32

Bugs item #1638731, was opened at 20070118 09:43 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=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.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1638731&group_id=4933 
From: SourceForge.net <noreply@so...>  20070118 15:37:21

Bugs item #1635370, was opened at 20070114 15:05 Message generated for change (Comment added) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1635370&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  Simplification Group: None >Status: Closed >Resolution: Fixed Priority: 4 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: absolute value of conjugate Initial Comment: We could make abs(conjugate(z)) > abs(z). (%i1) declare(z,complex); (%o1) done (%i2) abs(conjugate(z)); (%o2) abs(conjugate(z))  >Comment By: Barton Willis (willisbl) Date: 20070118 09:37 Message: Logged In: YES user_id=895922 Originator: YES Fixed in CVS  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1635370&group_id=4933 
From: SourceForge.net <noreply@so...>  20070118 15:36:46

Bugs item #1636926, was opened at 20070116 10:31 Message generated for change (Comment added) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1636926&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: Tests Group: None >Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: rtest16 #39 Initial Comment: Test 39 in rtest16 is: /* Bug 593344 */ limit(abs(infinity)); infinity; The correct answer is inf, not infinity. I believe.  >Comment By: Barton Willis (willisbl) Date: 20070118 09:36 Message: Logged In: YES user_id=895922 Originator: YES Fixed in CVS  Comment By: Barton Willis (willisbl) Date: 20070118 09:33 Message: Logged In: YES user_id=895922 Originator: YES Fixed in CVS.  Comment By: Robert Dodier (robert_dodier) Date: 20070116 22:36 Message: Logged In: YES user_id=501686 Originator: NO Agreed, should be inf.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1636926&group_id=4933 
From: SourceForge.net <noreply@so...>  20070118 15:35:43

Bugs item #1636789, was opened at 20070116 07:31 Message generated for change (Comment added) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1636789&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: Fixed Priority: 5 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Barton Willis (willisbl) Summary: conjugate & ratsubst Initial Comment: The simpconjugate function skips the simplification when the simp flag is true. This is a bug: (%i1) conjugate(log(1 + %i*a)); (%o1) conjugate(log(%i*a1)) (%i2) ratsubst(1,a,%); (%o2) conjugate(log(%i1)) < should be log(1%i) (%i3) conjugate(log(%i1)); (%o3) log(%i1)  >Comment By: Barton Willis (willisbl) Date: 20070118 09:35 Message: Logged In: YES user_id=895922 Originator: YES Fixed in CVS  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1636789&group_id=4933 
From: SourceForge.net <noreply@so...>  20070118 15:34:55

Bugs item #1636746, was opened at 20070116 06:37 Message generated for change (Comment added) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1636746&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  Simplification Group: Includes proposed fix >Status: Closed >Resolution: Fixed Priority: 4 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Barton Willis (willisbl) Summary: tellsimp and abs Initial Comment: (%i1) tellsimp(abs(a),a)$ (%i2) abs(5*a); (%o2) 5*abs(a) < should be 5 * a A user shouldn't have to resort to trickery: (%i3) expand(%,0); (%o3) 5*a  >Comment By: Barton Willis (willisbl) Date: 20070118 09:34 Message: Logged In: YES user_id=895922 Originator: YES Fixed in CVS  Comment By: Barton Willis (willisbl) Date: 20070116 06:39 Message: Logged In: YES user_id=895922 Originator: YES File Added: rtest_abs.mac  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1636746&group_id=4933 
From: SourceForge.net <noreply@so...>  20070118 15:34:24

Bugs item #1635322, was opened at 20070114 13:44 Message generated for change (Comment added) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1635322&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  Simplification Group: None >Status: Closed >Resolution: Fixed Priority: 4 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: abs of infinity, minf, ... Initial Comment: (%i3) abs(infinity); (%o3) abs(infinity) < could be inf (%i4) abs(minf); (%o4) inf < should be inf (%i5) abs(und); `sign' called on `und'. < could be und (%i6) abs(ind); (%o6) abs(ind) < could be ind  >Comment By: Barton Willis (willisbl) Date: 20070118 09:34 Message: Logged In: YES user_id=895922 Originator: YES Fixed in CVS  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1635322&group_id=4933 
From: SourceForge.net <noreply@so...>  20070118 15:33:36

Bugs item #1636926, was opened at 20070116 10:31 Message generated for change (Comment added) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1636926&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: Tests Group: None Status: Open >Resolution: Fixed Priority: 5 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: rtest16 #39 Initial Comment: Test 39 in rtest16 is: /* Bug 593344 */ limit(abs(infinity)); infinity; The correct answer is inf, not infinity. I believe.  >Comment By: Barton Willis (willisbl) Date: 20070118 09:33 Message: Logged In: YES user_id=895922 Originator: YES Fixed in CVS.  Comment By: Robert Dodier (robert_dodier) Date: 20070116 22:36 Message: Logged In: YES user_id=501686 Originator: NO Agreed, should be inf.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1636926&group_id=4933 
From: SourceForge.net <noreply@so...>  20070118 15:32:17

Bugs item #1635320, was opened at 20070114 13:40 Message generated for change (Comment added) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1635320&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 Group: None >Status: Closed >Resolution: Invalid Priority: 4 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: absolute value of CL array Initial Comment: (%i1) qq : make_array('any,5)$ (%i2) abs(qq); Maxima encountered a Lisp error: Should abs map over an array when listarith is true?  >Comment By: Barton Willis (willisbl) Date: 20070118 09:32 Message: Logged In: YES user_id=895922 Originator: YES I've decided that this is not really a bug. Someday, we might revise Maxima arrays. At that time, we should reconsider how functions interact with arrays.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1635320&group_id=4933 
From: SourceForge.net <noreply@so...>  20070118 15:31:43

Bugs item #1636823, was opened at 20070116 08:15 Message generated for change (Comment added) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1636823&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: Closed >Resolution: Invalid Priority: 4 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Barton Willis (willisbl) Summary: conjugate of an array Initial Comment: (%i1) f : make_array('any,2); (%o1) #(NIL NIL) (%i2) conjugate(%); Maxima encountered a Lisp error  >Comment By: Barton Willis (willisbl) Date: 20070118 09:31 Message: Logged In: YES user_id=895922 Originator: YES I've decided that this is not really a bug. Someday, we might revise Maxima arrays. At that time, we should reconsider how functions interact with arrays.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1636823&group_id=4933 
From: SourceForge.net <noreply@so...>  20070118 15:31:00

Bugs item #1636826, was opened at 20070116 08:18 Message generated for change (Comment added) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1636826&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 Group: None >Status: Closed >Resolution: Invalid Priority: 4 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Barton Willis (willisbl) Summary: max and min of an array Initial Comment: (%i1) f : make_array('any,2); (%o1) #(NIL NIL) (%i2) max(f,1); Maxima encountered a Lisp error: The same for min. Also, sign(f) > lisp error as well as ?csign(f).  >Comment By: Barton Willis (willisbl) Date: 20070118 09:30 Message: Logged In: YES user_id=895922 Originator: YES I've decided that this is not really a bug. Someday, we might revise Maxima arrays. At that time, we should reconsider how functions interact with arrays.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1636826&group_id=4933 