Screenshot instructions:
Windows
Mac
Red Hat Linux
Ubuntu
Click URL instructions:
Rightclick on ad, choose "Copy Link", then paste here →
(This may not be possible with some types of ads)
From: SourceForge.net <noreply@so...>  20110317 15:02:21

Bugs item #3220118, was opened at 20110317 11:02 Message generated for change (Tracker Item Submitted) 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.  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: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 
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 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: SourceForge.net <noreply@so...>  20110329 02:41:08

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: 20110328 22:41 Message: Actually, the continued fraction http://functions.wolfram.com/06.06.10.0009.01 appears to converge faster and to be more accurate. The previously mentioned fraction has some issues for points near the negative real axis where the accuracy is not as good as we might expect.  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: SourceForge.net <noreply@so...>  20120817 17:05:51

Bugs item #3220118, was opened at 20110317 08: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: Closed >Resolution: Fixed 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: 20120817 10:05 Message: Appears to have been fixed some time ago.  Comment By: Raymond Toy (rtoy) Date: 20110328 19:41 Message: Actually, the continued fraction http://functions.wolfram.com/06.06.10.0009.01 appears to converge faster and to be more accurate. The previously mentioned fraction has some issues for points near the negative real axis where the accuracy is not as good as we might expect.  Comment By: Raymond Toy (rtoy) Date: 20110324 15: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 12: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 06: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 19: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 
Sign up for the SourceForge newsletter:
No, thanks