Hi Daniel,

you have to set the numberformat to scientific to or the decimal
places to 16 or so.

Prio was much to high (Prio 1 is a totally unusefull application) I've
corrected this one.

Frank

According to the roadmap of OpenOffice.org 1.1
(http://tools.openoffice.org/releases/Openoffice_org_1_x.html) this
issue has been scheduled for 1.1.2.

Fix is to risky for OOo1.1.2 => retargeted to OOo2.0

OC: Due to high workload this issue is retargeted to office.later

I looked at the source code in scaddins/source/analysis/analysishelper.cxx, and
the computation for Erf uses Taylor's series - this is almost sure to get large
rounding errors of the kind reported here.  (Indeed Erf(7) gives an answer of
about 1362.92 which is way way off the true answer.)

My suggestion is to simply copy the code for erf and erfc that comes with
Berkeley Unix (which comes with a very unrestrictive license).  For example,
look in the FreeBSD source code at lib/libm/common_source/erf.c.

I think it would be really helpful to fix this bug - today I converted a friend
from Excel to Openoffice because his version of Excel didn't have erf.

Created attachment 23673 [details]
Proposed patch

Ive done, whatz reqd. Please review and comment if any changed reqd.
The berkley code has a liscense and as per that ive included that liscense too.

A patch is attached to this issue.  Is anybody not going to review this for
inclusion?

Here here kohei.  I have to say that it is very disappointing that somemone has
taken the trouble to submit the patch and 6 months later it has still not been
accepted.

I appreciate that the OOO team has high workload and are doing a great job
however this kind of problem is complete showstopper for elements of the
engineering and scientific community that is the natural constituency for OOO

Sorry about the delay.
Code to be integrated into the main OOo tree has to be covered by a JCA, we
can't use other people's BSD-licensed code.

I think I've found a good algorithm for ERF that converges to 1 as x becomes
larger.  It's a clean-room implementation hence there will be no licensing issue
(the mathematical approximation formula used in the algorithm is from a
published source).

I'll upload a patch and a test program in a day or two.  Stay tuned.

Kohei

Created attachment 30194 [details]
test program

Compile and run the test program as follows:

[kohei@localhost Erf]$ g++ -Os -o erf erf.cxx
[kohei@localhost Erf]$ ./erf 5
<maclaurin>
erf:  1.000000000072773
erfc: -7.2773443412881e-11
<asymptotic>
erf:  0.9999999999984626
erfc: 1.537436844500917e-12

The maclaurin series expansion gives Calc's current answers for erf and erfc,
while the asymptotic series expansion (proposed new algorithm) give more
accurate answers.

You can also run this program with no arguments.  It will compute erf and erfc
using both the Maclaurin expansion (current algorithm) and the Asymptotic
expansion (new algorithm) for x between -10 and 10 incremented by 0.1.

[kohei@localhost Erf]$ ./erf
x       erf(x) <maclaurin>      erfc(x) <maclaurin>     erf(x) <asymptotic>    
erfc(x) <asymptotic>
-10     7.331381385975313e+21   -7.331381385975313e+21  -1      2
-9.9    -3.548111434363548e+19  3.548111434363548e+19   -1      2
-9.8    -1.744418020013381e+20  1.744418020013381e+20   -1      2
-9.7    -1.560844956904942e+19  1.560844956904942e+19   -1      2
<snip>
9.7     -7.659310690090643e+18  7.659310690090643e+18   1       0
9.8     3.709705234685252e+19   -3.709705234685252e+19  1       0
9.9     4.120589789696997e+20   -4.120589789696997e+20  1       0
10      9.970406838904948e+21   -9.970406838904948e+21  1       0

There is however one caveat; the original Maclaurin expansion is more accurate
for values of x up to 4 while the Asymptotic expansion performs terribly.  But
for x larger than 4 the Asymptotic expansion is more accurate.  Therefore, in my
proposed patch, which will follow soon, the original Maclaurin expansion is used
for 0 < x < 4 and the asymptotic expansion for x > 4.

I have also compared against the values of erf and erfc computed by octave,
gnumeric, and Excel 2003.  My proposed algorithm performs comparably, though not
identically, with octave and gnumeric (these two spit the identical numbers so I
assume they use the same algorithm), but it converges to 1 more quickly than
octave/gnumeric.  However, when compared with Excel 2003's values they were
almost identical, so much so that I'm pretty sure that Excel must use this same
algorithm internally!

The comparison table follows...

Created attachment 30195 [details]
Comparison table

Created attachment 30196 [details]
Proposed patch (SRC680_m130)

Setting target milestone to 2.0.1.  I hope there is still window for that
milestone. :-)

Kohei

References:

http://mathworld.wolfram.com/Erf.html
http://mathworld.wolfram.com/MaclaurinSeries.html

patch applied in SRC680/dr42 (OOo 2.0.1)

Thanks for your effort, Kohei :-)

Thanks for your efforts Kohei.

I would not propose reopening this issue any time soon but would suggest
examining this and other complex, approximated functions in the future to see if
they can be improved. For at least ERFC(x) this is as good as MS Excel but I
believe the ambition should always to be better.

It also happens I routinely use values of 'x' = 4 to 6 and sometimes bigger in
my work so I have an interest.

I am neither mathematician nor coder but I am willing to do some digging if teh
results will be used.

Finally, and this might seem a silly question, but why not borrow the code from
Gnumeric or Octave?

We can't use code from Gnumeric or octave because their codes are GPL'ed and
none of us are the original author of the ERF/ERFC code in octave/gnumeric.  GPL
wouldn't allow the OO.o code to be relicenced under a proprietary licence, which
Sun needs in order to release StarOffice.  Even less restrictive BSD licenced
code would not do.

If we can find out the mathematical formula used in octave (not the code), we
can devise our own code from it to produce the same result.  That's probably
what we would need to do if we wanted our ERF/ERFC to behave like octave.

Kohei

Thanks for the explanation, I did not understand the licensing issue for Sun.

I will see if I can find the algorithm

I've created Issue 55735 to handle the algorithm improvement.  Feel free to put
yourself in CC for those who are interested.

kohei->dr: Daniel, I recommend we process this issue as RESOLVED FIXED as it is
currently tagged, and use Issue 55735 for the improvement.

Kohei

kohei: Agreed.

back to QA

re-open issue and reassign to fst@openoffice.org

reassign to fst@openoffice.org

reset resolution to FIXED

found fixed on cws dr42 using Linux, Solaris and Windows build

Found integrated on master m142 using Linux, Solaris and Windows Build