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}
(27) 
_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 




1

2
(3) 
3

4
(4) 
5

6

7

8

9

10
(1) 
11

12
(1) 
13
(6) 
14

15
(13) 
16
(5) 
17
(5) 
18
(3) 
19
(3) 
20
(1) 
21
(2) 
22
(2) 
23
(3) 
24

25

26

27
(1) 
28

29

30

31
(1) 

From: SourceForge.net <noreply@so...>  20120816 16:30:44

Bugs item #3220078, was opened at 20110317 07:48 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3220078&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: Documentation Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Raymond Toy (rtoy) Assigned to: Nobody/Anonymous (nobody) Summary: gamma_expand not documented Initial Comment: gamma_expand should be documented (and mentioned in the docs for gamma_incomplete and friends). A nice feature enhancement would be allow gamma_expand to have a value so that gamma_incomplete(a,z) is expanded if a < gamma_expand.  >Comment By: Raymond Toy (rtoy) Date: 20120816 09:30 Message: This was fixed some time ago. ? gamma_expand gives documentation now.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3220078&group_id=4933 
From: SourceForge.net <noreply@so...>  20120816 16:29:34

Bugs item #3220128, was opened at 20110317 08:06 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3220128&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: Raymond Toy (rtoy) Assigned to: Nobody/Anonymous (nobody) Summary: gamma_incomplete(1/2, 24+10*%i) not accurate Initial Comment: Maxima says gamma_incomplete(1/2,20+10*%i),float is 4.93408396056858e+9 %i + 1.91200542673871e+9 Wolfram/Alpha says the value is 4.9341163e+9 + 1.911933e+9 Maxima's answer is only accurate to about 5 digits.  >Comment By: Raymond Toy (rtoy) Date: 20120816 09:29 Message: This was fixed sometime ago.  Comment By: Raymond Toy (rtoy) Date: 20120131 13:27 Message: Yes, this is a known bug with gamma_incomplete: it's totally wrong for large arguments. There's already a bug filed for that, I think.  Comment By: Dan Gildea (dgildea) Date: 20120131 13:18 Message: (%i6) i : integrate(sin(x)^2/x,x); (%o6) (2*log(x)+gamma_incomplete(0,2*%i*x)+gamma_incomplete(0,2*%i*x))/4 I think that the indefinite integral above is correct. However, if we evaluate it numerically: (%i7) i,x:10,numer,expand; (%o7) 1.129082636318599 (%i8) i,x:100,numer,expand; (%o8) 1.167036722342424e+67 we get something that does not match the result of numerical integration: (%i12) quad_qags(sin(x)^2/x,x,10,100); (%o12) [1.175691679966213,1.71048903216243e11,651,0] Not sure if this is a branch cut issue or what, but the results for gamma_incomplete here do not match wolfram alpha.  Comment By: Raymond Toy (rtoy) Date: 20120131 11:52 Message: Sorry. The description text is wrong. The subject line has the correct parameters for the gamma function: gamma_incomplete(1/2, 24+10*%i), float; 4.934116315504894e+9 %i + 1.911933769523827e+9 Wolfram alpha says 1.911933769523828402749347154173060427220404029989163... × 10^9 + 4.934116315504895269147935150892571896585283827123923... × 10^9 i So it looks like we are accurate to full precision now. Marking as pending/worksforme.  Comment By: Dan Gildea (dgildea) Date: 20120128 14:32 Message: Maxima 5.26.0_26_gc4216e7 http://maxima.sourceforge.net using Lisp CMU Common Lisp 20a (20A Unicode) (%i1) gamma_incomplete(1/2,20+10*%i),float; (%o1) 9.902410782885888e+7 %i + 3.4166055039087765e+7  Comment By: Raymond Toy (rtoy) Date: 20110324 06:32 Message: Setting *gammaimag* to .1d0 (so the region where we use the continued fraction is enlarged), improves the result to 4.93411631550489e+9 %i + 1.911933769523828e+9 Wolfram/Alpha gives 4.9341163155048952691479351508925718965852838271239234... × 10^9 i + 1.9119337695238284027493471541730604272204040299891632... × 10^9 Essentially full accuracy.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3220128&group_id=4933 
From: SourceForge.net <noreply@so...>  20120816 16:10:39

Bugs item #3479091, was opened at 20120124 10:55 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3479091&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: Pending >Resolution: Invalid Priority: 5 Private: No Submitted By: Ted Woollett (woollett) Assigned to: Nobody/Anonymous (nobody) Summary: realpart(1/e) # 1/realpart(e) case Initial Comment: Example in which e = sqrt ( sin (x) ) using gcl (%i1) fpprintprec:8$ (%i2) r1(x):= realpart(1/sqrt(sin(x)))$ (%i3) map('r1,[2,5,8,11,13]); (%o3) [1/sqrt(sin(2)),0,1/sqrt(sin(8)),0,1/sqrt(sin(13))] (%i4) float(%); (%o4) [1.0486897,0.0,1.0053637,0.0,1.5427268] (%i5) r2(x) := 1/realpart(sqrt(sin(x)))$ (%i6) map('r2,[2,5]); expt: undefined: 0 to a negative exponent. #0: r2(x=5)  an error. To debug this try: debugmode(true); (%i7) build_info()$ Maxima version: 5.26.0 Maxima build date: 22:48 1/15/2012 Host type: i686pcmingw32 Lisp implementation type: GNU Common Lisp (GCL) Lisp implementation version: GCL 2.6.8  >Comment By: Raymond Toy (rtoy) Date: 20120816 09:10 Message: What exactly is the issue? I expect 1/realpart(e) to give a divide by zero error for x=5 since sqrt(sin(5)) is purely imaginary.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3479091&group_id=4933 
From: SourceForge.net <noreply@so...>  20120816 16:06:01

Bugs item #3435971, was opened at 20111110 00:02 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3435971&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: Pending >Resolution: Invalid Priority: 5 Private: No Submitted By: https://www.google.com/accounts () Assigned to: Nobody/Anonymous (nobody) Summary: eigenvectors produces wrong results Initial Comment: [vals,vec]:eigenvectors(matrix([0.2273,0.0852],[0.193,0.1794])); rat: replaced 0.0164436 by 1134/68963 = 0.01644360019141 rat: replaced 0.1794 by 897/5000 = 0.1794 rat: replaced 0.2273 by 2273/10000 = 0.2273 rat: replaced 0.01644360019141 by 1091/66348 = 0.01644360040996 rat: replaced 0.1794 by 897/5000 = 0.1794 rat: replaced 0.2273 by 2273/10000 = 0.2273 rat: replaced 1.2057635497678905E12 by 1/829350000000 = 1.2057635497678905E12 rat: replaced 2.1637741760636258E+11 by 216377417606/1 = 2.16377417606E+11 rat: replaced 2.1637741760636258E+11 by 216377417606/1 = 2.16377417606E+11 (%o40) [[[0.07289999842889,0.33380000157111],[1,1]],[[[1,1.812206572769953]],[[1, 1.25]]]] However, the eigenvectors should be [0.62166748, 0.78328126] and [0.46864735,0.88338534].  >Comment By: Raymond Toy (rtoy) Date: 20120816 09:06 Message: The eigenvalues computed by maxima are correct. A : matrix([0.2273,0.0852],[0.193,0.1794]); A . vec[1][1]  vals[1][1] * vec[1][1] > matrix([0.0],[0.0]) A . vec[2][1]  vals[1][2] * vec[2][1] > matrix([0.2609],[.4728046948356808]) You were probably expecting the eigenvectors to be normalized to unit length. Eigenvectors are unique only up to a scale factor.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3435971&group_id=4933 
From: SourceForge.net <noreply@so...>  20120816 00:46:34

Bugs item #3558096, was opened at 20120815 17:46 Message generated for change (Tracker Item Submitted) made by jyoberle You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3558096&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: JeanYves (jyoberle) Assigned to: Nobody/Anonymous (nobody) Summary: to_poly_solve gives a wrong solution for cos(x)=sin(3x) Initial Comment: Hi, When doing: load(to_poly_solve); algexact:true; to_poly_solve(cos(x)sin(3*x),x); I get: to_poly_solve: to_poly_solver.mac is obsolete; I'm loading to_poly_solve.mac instead. %union([x=(4*%pi*%z0+%pi)/4],[x=(4*%pi*%z1+%pi)/8]) But I think that the first solution should be (based on hand solving): (4*%pi*%z0+%pi)/4 (no minus sign). For example: if we consider %z0 = 0 in the to_poly_solve solution, we get x=%pi/4 which is not a solution of the equation cos(x)sin(3*x). On the other hand, if we set %z0 = 0 in the hand found solution, we get x=%pi/4 which is a solution. The build_info is: build_info("5.27.0","20120508 11:27:57","i686pcmingw32","GNU Common Lisp (GCL)","GCL 2.6.8"). Best regards, JeanYves  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3558096&group_id=4933 