Hi Eike,
I'm back again :)
Eike Rathke schrieb:
If someone knows a solution that gives more accuracy with less
iterations, please let me know. I failed with the algorithm BASYM
from Didonato likely because of the needed erfc function.
It seems, that I can solve the erfc problem :) I need to learn about
"static methods" (see other thread).
Heh, that's an easy one :-)
Yes, I noticed it.
So again MSVC seems to be lacking a C99 mathematical function. Given an
erfc() function the BASYM algorithm would do fine?
I have implemented BASYM directly into ScTTT now. The accuracy is over
10 digits, sometimes up to 15 digits, same as the continued fraction. It
calculates with less then 1000 iteration. So the accuracy is about the
same as continued fraction, but with less iterations.
At least 10 digits accuracy sounds pretty good to me.
[... iterations ...]
What to do? Setting a lower limit?
We could do with a lower limit for OOo3.1 if indeed the 50000 iterations
are hit too many times and turn out to be a bottleneck, and once you
read the book ;) improve on the algorithm for OOo3.2
Using the function in a spreadsheet, I notice no performance problems
with that limit of iterations. But a real performance test would be
necessary to find an acceptable limit.
For a first attempt try with thousand and several thousand formula cells
depending on one value cell, place a SUM() function beneath that to
force calculation of all formula cells and change the value in the value
cell.
I've used a measurement with clock() now, calling the functions in a
10000-iterations loop. And I'm disappointed. Only for very large values
of alpha and beta (for example greater than 30000) and x very near to
mean p (for example x=0.99*p) the ASYM-algorithm is faster then
continued fraction. The accuracy is the same as for continued fraction.
For very, very large values (alpha,beta>100000) ASYM is faster with
factor 3 and more.
For very extreme values (beta=4e+12) the accuracy do not reach 10digits,
but I think we should not worry about that. Someone who needs such
extreme values shouldn't use a spreadsheet.
I have not yet written a performance test spreadsheet, I hope I can
spend some time on it next weekend.
Hopefully the results of the replacement function and different
compiler's built-in functions are nearly identical..
I cannot test that, I've only got MSVC Express.
I'll attach the version with BASYM to the issue, but it will take
some time until it is ready. I'll ask if I stuck.
The solution with ASYM is attached now. I've attached some testcases
too. The blue values are correct, so far as I got them from MuPad and
Mathematica. If you open the files in a current OOo version, you see the
improvement. But you see also that Gnumeric is still better and you see
the problems with x near 1 (for reasons we discussed already).
Nevertheless I think we should use this version (perhaps without ASYM,
if you think ASYM is not worth the afford), because I believe there will
be no better solution soon.
I want to give you every support I can, you're doing such a great work
on our functions' accuracy.
I'm glad if my work will help you.
kind regards
Regina
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
