Hi Eike,
Eike Rathke schrieb:
Hi Regina,
On Saturday, 2010-05-08 21:02:45 +0200, Regina Henschel wrote:
I have notice a constraint "SinOverflow" (which is x>=134217728) in
analysishelper.cxx in scaddins. What is the special reason for it?
Having tried I confirm that Excel has that constraint, or more specific
x<134217728. I don't know adhoc why it is 2^27 though.
In other places with sin() the version ::rt::math::sin() is used to get
a guard for overflow. That would result in constraint
x<=9,22337203685478E+018, which is much larger.
See comment in sal/inc/rtl/math.hxx for isValidArcArg(). We rely on the
trigonometric functions being implemented such that radians up to 2^64
(=1.844e19) are supported. Re-thinking that, also per the comments
Leonarda gave, we should lower the limit to a value representable in
a double's (binary64) mantissa of 53 bits. For consistency with the
approx functions I suggest a constraint x<=2^48
I have scanned that area a little bit, using some integral numbers. The
accuracy is about 7-8 digits for x near to 2^48. For larger values, the
accuracy decreases dramatically to 0-1 digit. The accuracy for integral
numbers is 14-15 digits till 2^27.
But for non-integral numbers the situation is not so good. The function
sin() reacts very sensitive on rounding errors. Although the arguments
only differ in that digit, which is not displayed, the result might be
very different. This error is greater for large values and values near
multiples of PI. Some examples:
near 2^48, near multiple of PI
sin(281474976710656 + 0.1) = 2.52110962285532E-001
sin(281474976710656 + 0.4) = 4.83685841828820E-001
near 2^26
sin(109951164.00440 + 0,000001) = 9.99999998707539E-001
sin(109951164.00440 + 0,000004) = 9.99999998550774E-001
near 2^36
sin(109951164005.920 + 0.0001) = 9,99999640813644E-001
sin(109951164005.920 + 0.0004) = 9.99999844512272E-001
near 2^45
sin(49951164005923.8 + 0.01) = -9.94815019880560E-001
sin(49951164005923.8 + 0.04) = -9.97506946246269E-001
About the IEEE 754 specification mentioned there: Unfortunately I can't
find that 2^64 requirement, apparently the standard itself does not say
so, just checked. Maybe it did in an older public draft, as
a recommendation. Apparently C math libraries implement it such.
If there is no special reason, should I replace it, while I work on the
missing complex trigonometric functions?
Note that this SinOverflow() of the Analysis Add-In is used with IMSIN()
and IMCOS() only. However, in Excel also the SIN(), COS() and TAN()
functions are affected by the x<134217728 constraint, which we handle
using the ::rtl::math approach.
I think we can safely replace SinOverflow() with
::rtl::math::isValidArcArg() if we chose a better limit for that.
I have written all imaginary functions now in a way that
::rtl::math::isValidArcArg() is used. Doing that the imaginary functions
will give the same result as the normal real functions, when called with
a real argument.
Concerning the limit in ::rtl::math::isValidArcArg() I'm not sure, what
is the right way. Gnumeric does not limit the argument of sine and
results wrong values.
I too tend to use 2^48 as limit. Beyond that limit the result are
unusable. But in addition the descriptions in the Wiki should mention,
that the accuracy will only be good (= 9 to 15 digits) if the argument
is smaller than 2^27.
kind regards
Regina
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
