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}
(31) 
_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 



1
(1) 
2
(1) 
3
(2) 
4
(2) 
5
(2) 
6
(1) 
7
(1) 
8
(2) 
9
(1) 
10

11

12
(9) 
13
(1) 
14
(3) 
15
(4) 
16
(2) 
17
(5) 
18

19

20

21
(1) 
22

23
(3) 
24
(5) 
25

26
(3) 
27

28

29
(2) 
30
(1) 
31



From: SourceForge.net <noreply@so...>  20110324 22:17:34

Bugs item #3220118, was opened at 20110317 11:02 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3220118&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: Raymond Toy (rtoy) Assigned to: Nobody/Anonymous (nobody) Summary: erf(1+5*%i) not accurate Initial Comment: erf(1.0+5*%i) returns  2.7837671212125964e+9 %i  1.0786562260474622e+9 But the true answer (as given by Wolfram/Alpha) is  2.7837702922089653e+9 %i  1.0786931161985406e+9 Only about 4 digits are correct.  >Comment By: Raymond Toy (rtoy) Date: 20110324 18:17 Message: Here is an alternative method of computing gamma_incomplete: http://functions.wolfram.com/06.06.10.0007.01 There appear to be no restrictions on the range of validity of this continued fraction, so it can probably be used for other areas. I've tested this a bit (with oct), and it converges quickly for things on or near the negative real axis. The few tests I've done indicate that accuracy is good.  Comment By: Dieter Kaiser (crategus) Date: 20110324 15:06 Message: Hello Ray, you are right. The problem is the function gamma_incomplete. The continued fraction expansion of the function tends to converge to a wrong value for some ranges of the argument. In the past, I had searched for some hints in the literature to solve this problem more general. But I had not found a simple solution. Therefore, I had done a heuristic approach and checked several ranges for the arguments to achieve a better approximation of the function gamma_incomplete. I have to work again on this problem. Dieter Kaiser  Comment By: Raymond Toy (rtoy) Date: 20110324 09:27 Message: I think the inaccuracy comes from gammaincomplete, which is used to evaluate erf. For this particular argument, gammaincomplete uses the series. I think the test of when to use the series could be relaxed a bit. When I set *gammaimag* to 0.1, the continued fraction is used, which gives  2.7837770292209086e+9 %i  1.0786931161985383e+9 This is better. I've done some experiments using the continued fraction http://functions.wolfram.com/06.06.10.0005.01. This seems to work a bit better.  Comment By: Barton Willis (willisbl) Date: 20110317 22:51 Message: By the way: using a 1F1 representation for erf, the values agree with Wolfram  Alpha. But the hypergeometric code has to switch to bigfloats to do this: (%i11) my_erf(x) := nfloat(2*x*hypergeometric([1/2],[3/2],x^2)/sqrt(%pi),[]); (%o11) my_erf(x):=nfloat((2*x*hypergeometric([1/2],[3/2],x^2))/sqrt(%pi),[]) (%i12) load(hypergeometric)$ (%i14) my_erf(1.0+5*%i); (%o14) 2.783777029220896b9*%i1.078693116198541b9  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3220118&group_id=4933 
From: Mario Rodriguez <biomates@te...>  20110324 19:36:52

> These all appear to be caused by the adaptive plotter. It's getting > stuck because it thinks the curve is not smooth enough, which, I think, > is caused by some roundoff. This can be fixed by changing the threshold > to be a bit bigger. > > Not sure why we need the adaptive plotter if we're plotting explicit > points. Maybe we should also change the adaptiveplot depth to 1 > instead of the default of 5 or so? Hello, This change can be applied with option 'adapt_depth': draw2d(adapt_depth = 1, explicit(321.4567,x,0,1)); In the following simulation, variable 'tempos' stores execution times for 'adapt_depth' equal to 1 thru 7: tempos: [0.528033, 1.012063, 2.128133, 4.592288, 10.476654, 26.369647, 76.280767] $ draw2d(points_joined=true, points(tempos)) $  Mario 
From: SourceForge.net <noreply@so...>  20110324 19:06:28

Bugs item #3220118, was opened at 20110317 16:02 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3220118&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: Raymond Toy (rtoy) Assigned to: Nobody/Anonymous (nobody) Summary: erf(1+5*%i) not accurate Initial Comment: erf(1.0+5*%i) returns  2.7837671212125964e+9 %i  1.0786562260474622e+9 But the true answer (as given by Wolfram/Alpha) is  2.7837702922089653e+9 %i  1.0786931161985406e+9 Only about 4 digits are correct.  >Comment By: Dieter Kaiser (crategus) Date: 20110324 20:06 Message: Hello Ray, you are right. The problem is the function gamma_incomplete. The continued fraction expansion of the function tends to converge to a wrong value for some ranges of the argument. In the past, I had searched for some hints in the literature to solve this problem more general. But I had not found a simple solution. Therefore, I had done a heuristic approach and checked several ranges for the arguments to achieve a better approximation of the function gamma_incomplete. I have to work again on this problem. Dieter Kaiser  Comment By: Raymond Toy (rtoy) Date: 20110324 14:27 Message: I think the inaccuracy comes from gammaincomplete, which is used to evaluate erf. For this particular argument, gammaincomplete uses the series. I think the test of when to use the series could be relaxed a bit. When I set *gammaimag* to 0.1, the continued fraction is used, which gives  2.7837770292209086e+9 %i  1.0786931161985383e+9 This is better. I've done some experiments using the continued fraction http://functions.wolfram.com/06.06.10.0005.01. This seems to work a bit better.  Comment By: Barton Willis (willisbl) Date: 20110318 03:51 Message: By the way: using a 1F1 representation for erf, the values agree with Wolfram  Alpha. But the hypergeometric code has to switch to bigfloats to do this: (%i11) my_erf(x) := nfloat(2*x*hypergeometric([1/2],[3/2],x^2)/sqrt(%pi),[]); (%o11) my_erf(x):=nfloat((2*x*hypergeometric([1/2],[3/2],x^2))/sqrt(%pi),[]) (%i12) load(hypergeometric)$ (%i14) my_erf(1.0+5*%i); (%o14) 2.783777029220896b9*%i1.078693116198541b9  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3220118&group_id=4933 
From: SourceForge.net <noreply@so...>  20110324 13:32:19

Bugs item #3220128, was opened at 20110317 11: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: Open Resolution: None 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: 20110324 09: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...>  20110324 13:27:50

Bugs item #3220118, was opened at 20110317 11:02 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3220118&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: Raymond Toy (rtoy) Assigned to: Nobody/Anonymous (nobody) Summary: erf(1+5*%i) not accurate Initial Comment: erf(1.0+5*%i) returns  2.7837671212125964e+9 %i  1.0786562260474622e+9 But the true answer (as given by Wolfram/Alpha) is  2.7837702922089653e+9 %i  1.0786931161985406e+9 Only about 4 digits are correct.  >Comment By: Raymond Toy (rtoy) Date: 20110324 09:27 Message: I think the inaccuracy comes from gammaincomplete, which is used to evaluate erf. For this particular argument, gammaincomplete uses the series. I think the test of when to use the series could be relaxed a bit. When I set *gammaimag* to 0.1, the continued fraction is used, which gives  2.7837770292209086e+9 %i  1.0786931161985383e+9 This is better. I've done some experiments using the continued fraction http://functions.wolfram.com/06.06.10.0005.01. This seems to work a bit better.  Comment By: Barton Willis (willisbl) Date: 20110317 22:51 Message: By the way: using a 1F1 representation for erf, the values agree with Wolfram  Alpha. But the hypergeometric code has to switch to bigfloats to do this: (%i11) my_erf(x) := nfloat(2*x*hypergeometric([1/2],[3/2],x^2)/sqrt(%pi),[]); (%o11) my_erf(x):=nfloat((2*x*hypergeometric([1/2],[3/2],x^2))/sqrt(%pi),[]) (%i12) load(hypergeometric)$ (%i14) my_erf(1.0+5*%i); (%o14) 2.783777029220896b9*%i1.078693116198541b9  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3220118&group_id=4933 