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}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 


1
(1) 
2
(4) 
3
(2) 
4
(1) 
5

6

7
(5) 
8
(9) 
9

10
(2) 
11
(6) 
12
(12) 
13
(5) 
14
(7) 
15
(4) 
16
(4) 
17

18

19
(2) 
20
(7) 
21
(9) 
22
(7) 
23
(6) 
24
(5) 
25
(12) 
26
(12) 
27
(10) 
28
(4) 
29
(4) 
30
(5) 
31




From: SourceForge.net <noreply@so...>  20100325 22:44:35

Bugs item #2976744, was opened at 20100325 22:44 Message generated for change (Tracker Item Submitted) made by villate You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2976744&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  Plotting Group: None Status: Open Resolution: None Priority: 7 Private: No Submitted By: Jaime E. Villate (villate) Assigned to: Jaime E. Villate (villate) Summary: postscript terminal requires manual reset of default termina Initial Comment: Bug reported by Leo Butler in the Users list: When using the gnuplot_pipes plot format, the use of [gnuplot_preamble,"set terminal postscript ...] appears to require that subsequent calls manually reset the terminal to the default.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2976744&group_id=4933 
From: SourceForge.net <noreply@so...>  20100325 22:19:12

Bugs item #2976378, was opened at 20100325 11:48 Message generated for change (Comment added) made by alex108 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2976378&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  Solving equations Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Joerg (genkides) Assigned to: Nobody/Anonymous (nobody) Summary: Solver doesn't finish Initial Comment: I had the following equation typed into wxMaxima 0.8.4: 2000=1000*1.072^x Then calling the solver: solve([%], [x]) returned two messages: rat: replaced 1.072 by 134/125 = 1.072 [134^x=2*125^x] instead of the solution: log(2)/log(1.072)  Comment By: Aleksas Domarkas (alex108) Date: 20100326 00:19 Message: > simp:false; (%o15) false > eq:2000=1000*1.072^x; (%o16) 2000=1000*1.072^x > solve(eq); rat: replaced 1.072 by 134/125 = 1.072 (%o17) [x=log(2)/log(134/125)]  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2976378&group_id=4933 
From: SourceForge.net <noreply@so...>  20100325 19:42:12

Bugs item #2976657, was opened at 20100325 20:42 Message generated for change (Tracker Item Submitted) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2976657&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: Usage of gammagreek and %gammagreek Initial Comment: Maxima uses the different symbols %gammagreek and gammagreek for the same function. In hyp.lisp the symbol %gammagreek is used: (%i1) z^a/a*hgfred([a],[a+1],z); (%o1) %gammagreek(a,z) But in hypgeo.lisp the symbol gammagreek is used: (%i2) assume(s>0,a>0)$ The integrand with %gammagreek does not work: (%i3) specint(%gammagreek(a,t)*exp(s*t),t); (%o3) 'specint(%gammagreek(a,t)*%e^(s*t),t) Now we use the symbol gammagreek: (%i4) specint(gammagreek(a,t)*exp(s*t),t); (%o4) gamma(a+1)*s^(a1)/(a*(1/s+1)^a) I think we should use only the symbol gammagreek. It might be even better to introduce the symbol gamma_greek to be more consistent with the names of other functions related to the gamma function. Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2976657&group_id=4933 
From: SourceForge.net <noreply@so...>  20100325 19:07:48

Bugs item #2924831, was opened at 20100102 03:56 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2924831&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: Andrej Vodopivec (andrejv) Assigned to: Nobody/Anonymous (nobody) Summary: file_type is wrong for ccl on mac os x Initial Comment: clozure cl compiled files have the extension .dx64fls on mac os x. file_type thinks this are demo files since it only checks the first character of the extension. load therefore fails to load compiled files.  >Comment By: Raymond Toy (rtoy) Date: 20100325 15:07 Message: This is fine with me. I'll check it in shortly.  Comment By: Andrej Vodopivec (andrejv) Date: 20100311 03:48 Message: I think we can replace file_type in mload.lisp with (defun $file_type (fil &aux typ) (setq typ ($pathname_type fil)) (cond ((member typ (list "l" "lsp" "lisp") :test #'string=) '$lisp) ((member typ (list "mac" "mc" "demo" "dem" "dm1" "dm2" "dm3" "dmt") :test #'string=) '$maxima) (t '$object)))  Comment By: Raymond Toy (rtoy) Date: 20100204 08:05 Message: Perhaps file_type should be more explicit. So "max", "mac", "dem", and "demo" are maxima files; "l", "lsp", and "lisp" are lisp files, and everything else are object files. Maybe we can also let the user specify the association between the file extension and the file type?  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2924831&group_id=4933 
From: SourceForge.net <noreply@so...>  20100325 13:44:20

Bugs item #2974079, was opened at 20100321 08:45 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2974079&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: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Integration of sqrt(2*cos(t)+4*sin(t/2)^2+2) Initial Comment: Integration of function is not correct in (0,2*pi)  integrated function is 2^(5/2)*cos(t/2) in: integrate(sqrt(2*cos(t)+4*sin(t/2)^2+2),t); out: 2^(5/2)*cos(t/2) Maxima version: 5.20.1 Maxima build date: 21:25 12/14/2009 Host type: i686pcmingw32 Lisp implementation type: GNU Common Lisp (GCL) Lisp implementation version: GCL 2.6.8 Radim  >Comment By: Raymond Toy (rtoy) Date: 20100325 09:44 Message: This is caused by rischint. I don't know enough about it to say more than that.  Comment By: Aleksas Domarkas (alex108) Date: 20100321 16:27 Message: (%i1) S:'integrate(sqrt(44*cos(t)),t)$ correct: (%i2) factor(S); (%o2) 2*integrate(sqrt(1cos(t)),t) (%i3) ev(%, nouns); (%o3) 2*((sqrt(2)*cos(t)sqrt(2))*sin((t+%pi)/2)+sqrt(2)*sin(t)*cos((t+%pi)/2)) (%i4) trigreduce(%); (%o4) 2^(5/2)*cos(t/2) not correct: (%i5) ev(S, nouns); (%o5) 2^(5/2)*cos(t/2) ???  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2974079&group_id=4933 
From: SourceForge.net <noreply@so...>  20100325 13:32:55

Bugs item #2954472, was opened at 20100218 16:55 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2954472&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: Fixed Priority: 5 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: rectform with large floats gives bad answer Initial Comment: rectform(1e160/(1e160+%i)) => 0.0 (should be 1.0  1.0e160) We should probably specialcase the float case to give better precision by avoiding underflow.  >Comment By: Raymond Toy (rtoy) Date: 20100325 09:32 Message: This definitely needed to be fixed. That it doesn't work with gcl and ecl is a bug in gcl and ecl. The code basically calls (/ (complex x y)). If this overflows, it's a bug in gcl and ecl. Of course, we can do it portably, and my original version did this. These errors should be reported to gcl and ecl.  Comment By: Dan Gildea (dgildea) Date: 20100325 08:42 Message: This fix does not work with gcl (where rectform(1e160/(1e160+%i)) still gives 0.0) or with ecl (where it gives a floating point overflow lisp error). Bugs like this are hard to fix in a portable way  are they even worth worrying about?  Comment By: Raymond Toy (rtoy) Date: 20100322 19:46 Message: A special case is added to risplitexpt to compute 1/(x+%i*y) carefully. With this change, we now get 1.0  9.99988867182683e161 %i. See rpart.lisp, rev 1.32. Closing bug.  Comment By: Raymond Toy (rtoy) Date: 20100322 16:20 Message: Is this gcl? With cmucl, I get a floatingpoint overflow error. Not good, but better than returning 0.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2954472&group_id=4933 
From: SourceForge.net <noreply@so...>  20100325 12:42:22

Bugs item #2954472, was opened at 20100218 16:55 Message generated for change (Comment added) made by dgildea You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2954472&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: Fixed Priority: 5 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: rectform with large floats gives bad answer Initial Comment: rectform(1e160/(1e160+%i)) => 0.0 (should be 1.0  1.0e160) We should probably specialcase the float case to give better precision by avoiding underflow.  >Comment By: Dan Gildea (dgildea) Date: 20100325 08:42 Message: This fix does not work with gcl (where rectform(1e160/(1e160+%i)) still gives 0.0) or with ecl (where it gives a floating point overflow lisp error). Bugs like this are hard to fix in a portable way  are they even worth worrying about?  Comment By: Raymond Toy (rtoy) Date: 20100322 19:46 Message: A special case is added to risplitexpt to compute 1/(x+%i*y) carefully. With this change, we now get 1.0  9.99988867182683e161 %i. See rpart.lisp, rev 1.32. Closing bug.  Comment By: Raymond Toy (rtoy) Date: 20100322 16:20 Message: Is this gcl? With cmucl, I get a floatingpoint overflow error. Not good, but better than returning 0.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2954472&group_id=4933 
From: SourceForge.net <noreply@so...>  20100325 11:33:47

Bugs item #2953369, was opened at 20100217 03:56 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2953369&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: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Definite Integration of 1/(ab*cos(x)) wrong Initial Comment: Maxima 5.20.1 with wxMaxima. integrate(1/(ab*cos(x)),x,0,%pi); where a>0, 0<b<a yields 0.  >Comment By: Raymond Toy (rtoy) Date: 20100325 07:33 Message: dgildea's basic solution checked in. Closing bug.  Comment By: Raymond Toy (rtoy) Date: 20100324 22:05 Message: Yes, that works nicely. Need to make the second lambda also call asksign. And since the question is the same, it's nice to cache the answer from the first lambda.  Comment By: Dan Gildea (dgildea) Date: 20100324 05:32 Message: possible solution: (defun unitcir (grand var) (numden grand) (let ((result (princip (res nn* dn* #'(lambda (pt) (eq (let ((limitp nil)) ($asksign (m+ 1 (cabs pt)))) '$neg)) #'(lambda (pt) (alike1 1 (cabs pt))))))) (cond (result (m* '$%pi result)) (t nil))))  Comment By: Raymond Toy (rtoy) Date: 20100323 08:03 Message: The incorrect result comes from polelist failing to identify the locations of the poles. Since the integrand is even, we can integrate from %pi to %pi (or 0 to 2*%pi) and take half of the result. This integral is converted to the contour integral of 2/(b*yy^22*a*y+b) around the unit circle. This is evaluated by residues. We want to find the poles inside the unit circle and polelist is supposed to do that. The poles are correctly determined, but unfortunately for these poles, polelist cannot find the one pole that is in the circle. Therefore the function res thinks there are no poles in the unit circle and returns 0. When a and b are numbers, polelist does a better job and normally determines the pole that is within the unit circle. Perhaps the function that determines whether the pole is in the unit circle needs to be enhanced?  Comment By: Barton Willis (willisbl) Date: 20100226 01:45 Message: Notice how a float enters into the asksign: (%i4) integrate(1/(1a*cos(x)),x); Is a^21.0 positive or negative?neg; (%o4) (2*atan(((2*a+2)*sin(x))/(2*sqrt(1a^2)*(cos(x)+1))))/sqrt(1a^2)  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2953369&group_id=4933 
From: SourceForge.net <noreply@so...>  20100325 09:48:45

Bugs item #2976378, was opened at 20100325 10:48 Message generated for change (Tracker Item Submitted) made by genkides You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2976378&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  Solving equations Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Joerg (genkides) Assigned to: Nobody/Anonymous (nobody) Summary: Solver doesn't finish Initial Comment: I had the following equation typed into wxMaxima 0.8.4: 2000=1000*1.072^x Then calling the solver: solve([%], [x]) returned two messages: rat: replaced 1.072 by 134/125 = 1.072 [134^x=2*125^x] instead of the solution: log(2)/log(1.072)  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2976378&group_id=4933 
From: SourceForge.net <noreply@so...>  20100325 08:22:03

Bugs item #2976346, was opened at 20100325 08:22 Message generated for change (Tracker Item Submitted) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2976346&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: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: taylor expansion bug when mixing floats and rationals Initial Comment: When taylor encounters terms of the same order, one with float coefficient and the other one with rational coefficient, with nonminimal degree, it fails. Example: keepfloat:true; taylor(cos(x) + 1.0*x^2, x, 0, 2); Maxima encountered a Lisp error: Error in MACSYMATOPLEVEL [or a callee]: 1.0 is not of type INTEGER. while taylor(cos(x) + 1.0*x, x, 0, 2) works correctly, since there is no term of order 1 in cos(x), and taylor(cos(x) + 1.0, x, 0, 2) also works correctly.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2976346&group_id=4933 
From: SourceForge.net <noreply@so...>  20100325 02:20:59

Bugs item #2968173, was opened at 20100310 19:25 Message generated for change (Comment added) made by sfrobot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2968173&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: Invalid Priority: 5 Private: No Submitted By: Richard Hennessy (richardhennessy) Assigned to: Nobody/Anonymous (nobody) Summary: quad_qagi bug Initial Comment: Try (%i1) (gamma_incomplete(6/7,9*x^7)*xgamma_incomplete(1,9*x^7)/9^(1/7))/(7*9^(6/7))$ (%i2) quad_qagi(%,x,0,inf); (%i2) (gamma_incomplete(6/7,9*x^7)*xgamma_incomplete(1,9*x^7)/9^(1/7))/(7*9^(6/7)) ; 7 gamma_incomplete(1, 9 x ) 6 7   gamma_incomplete(, 9 x ) x 1/7 7 9 (out2)  6/7 7 9 (%i3) quad_qagi(%,x,0,inf); gamma_incomplete: continued fractions failed for gamma_incomplete(1.0, 4.3682654441477153E+19). 7 gamma_incomplete(1, 9 x ) 6 7   gamma_incomplete(, 9 x ) x 1/7 7 9 (out3) quad_qagi(, x, 0, inf, epsrel = 1.0E8, epsabs = 0.0, limit = 200) 6/7 7 9 (%i4) bug_report(); The Maxima bug database is available at http://sourceforge.net/tracker/?atid=104933&group_id=4933&func=browse Submit bug reports by following the 'Add new' link on that page. Please include the following information with your bug report:  Maxima version: 5.20.1 Maxima build date: 21:25 12/14/2009 Host type: i686pcmingw32 Lisp implementation type: GNU Common Lisp (GCL) Lisp implementation version: GCL 2.6.8 Rich Hennessy  >Comment By: SourceForge Robot (sfrobot) Date: 20100325 02:20 Message: This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker).  Comment By: Raymond Toy (rtoy) Date: 20100311 00:34 Message: I don't think this is a bug in quad_qagi. Look at the error message that says gamma_incomplete failed to compute the value of gamma_incomplete(1.0, 4.368e19). Marking as pending/invalid. I'll write up another bug report about gamma_incomplete.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2968173&group_id=4933 
From: SourceForge.net <noreply@so...>  20100325 02:05:38

Bugs item #2953369, was opened at 20100217 03:56 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2953369&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: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Definite Integration of 1/(ab*cos(x)) wrong Initial Comment: Maxima 5.20.1 with wxMaxima. integrate(1/(ab*cos(x)),x,0,%pi); where a>0, 0<b<a yields 0.  >Comment By: Raymond Toy (rtoy) Date: 20100324 22:05 Message: Yes, that works nicely. Need to make the second lambda also call asksign. And since the question is the same, it's nice to cache the answer from the first lambda.  Comment By: Dan Gildea (dgildea) Date: 20100324 05:32 Message: possible solution: (defun unitcir (grand var) (numden grand) (let ((result (princip (res nn* dn* #'(lambda (pt) (eq (let ((limitp nil)) ($asksign (m+ 1 (cabs pt)))) '$neg)) #'(lambda (pt) (alike1 1 (cabs pt))))))) (cond (result (m* '$%pi result)) (t nil))))  Comment By: Raymond Toy (rtoy) Date: 20100323 08:03 Message: The incorrect result comes from polelist failing to identify the locations of the poles. Since the integrand is even, we can integrate from %pi to %pi (or 0 to 2*%pi) and take half of the result. This integral is converted to the contour integral of 2/(b*yy^22*a*y+b) around the unit circle. This is evaluated by residues. We want to find the poles inside the unit circle and polelist is supposed to do that. The poles are correctly determined, but unfortunately for these poles, polelist cannot find the one pole that is in the circle. Therefore the function res thinks there are no poles in the unit circle and returns 0. When a and b are numbers, polelist does a better job and normally determines the pole that is within the unit circle. Perhaps the function that determines whether the pole is in the unit circle needs to be enhanced?  Comment By: Barton Willis (willisbl) Date: 20100226 01:45 Message: Notice how a float enters into the asksign: (%i4) integrate(1/(1a*cos(x)),x); Is a^21.0 positive or negative?neg; (%o4) (2*atan(((2*a+2)*sin(x))/(2*sqrt(1a^2)*(cos(x)+1))))/sqrt(1a^2)  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2953369&group_id=4933 