Apache OpenOffice (AOO) Bugzilla – Issue 55735
Improve the accuracy of ERF/ERFC for large x value
Last modified: 2013-08-07 15:13:18 UTC
This issue is a spin-off of Issue 19991. The patch in Issue 19991 fixes incorrect ERF/ERFC values for large x values where the original algorithm produced erroneous results. However, the algorithm should be further improved to match the values computed by octave/gnumeric. The revised algorithm in Issue 19991, while it does a better job than the original algorithm, converges to 1 too quickly.
I have a calculation method in the paper 'Algorithms with guarenteed error bounds for the Error Function and Complementary Error Function - Walter Kramer and Frithjof Blomquist', read it here http://www.math.uni-wuppertal.de/org/WRST/preprints/prep_00_2.pdf Assuming that the results given by Gnumeric are correct then these algorithms match to better than 8 significant figures for -26.5<x<26.5 Note that there appears to be an error in the published algorithm for x>6 with a factor of 1/sqrt(pi) missing, in fact even with this correction extending the algorithm given for 2.2<x<6 to 2.2<x<26.5 gives a much better result at all points than the published algoritm The attached spreadsheet includes user functions myerf(x) and myerfc(x)based on the above and comparison with the Gnumeric results
Created attachment 30648 [details] implementation of erf(x) and erfc(x) in BASIC
Oh yeah, this is right on! I will work on integrating this algorithm into Calc as soon as I get a chance. Thanks for finding the algorithm. I tried previously, but I wasn't successful. Kohei
Created attachment 30998 [details] Erf Erfc comparison for -26.5 < x 26.5
This file contains values of erf & erfc calculated by Calc's new algorithm (pasted as values) in comparison to Gnumeric's. They match pretty darn well. Many thanks to stair for finding the algorithm reference! A proposed patch will follow.
Created attachment 31000 [details] Proposed patch
Setting target milestone to 2.0.1 and priority set to P3.
re-assigning it to Niklas.
kohei->nn: Niklas, can we possibly integrate this patch for 2.0.1, or is it too late?
Just to be clear, my patch is a clean implementation from the publication by Kramer and Blomquist. The discrepancies in the resulting values as stair mentioned were not present in the original algorithm. -Kohei
Per Niklas' comment on dev@sc.ooo, this issue is re-targeted for 2.0.2 (too late for 2.0.1), provided that the patch be good enough for integration. -Kohei
Nice work I'll put this in ooo-build temporarily. One small style/performance comment on the patch. Why use stl vectors for constants ? You would be better off using static const double qn[] = { ..... } rather than setting up the constants each time it's called. For the erfc0600 case jsut replicate the loop or use pointers to select which arrays to use.
Hi Jody, thanks for your commit and comment. You're right. It makes no sense to define constant for each call. I'll look into it shortly. -Kohei
Created attachment 31358 [details] Make pn/qn static variables
This patch reflects minor performance improvement per Jody's suggestion.
Created attachment 31370 [details] better patch
Perhaps this patch is better? This one declares the static variables outside those Erf(c) functions. The last patch was actually no better than the original, because the varialbes were still declared in each call.
Created attachment 31375 [details] The variant I used in ooo-build
Ah. So those static array declarations are not executed in the subsequent calls. I wasn't sure about that. Thanks!
declarations => initializations I got the terms mixed up. :P
I committed the last version (with Jody's changes) into the CWS "dr43". It will go into OOo 2.0.2.
back to QA for verification. re-open issue and reassign to oc@openoffice.org
reassign to oc@openoffice.org
reset resolution to FIXED
verified in internal build cws_dr43
closed because fix available in OOo2.0.2m156