[Bug 10073] Problems with the definitions of the trigonometric functions (math:)

http://www.w3.org/Bugs/Public/show_bug.cgi?id=10073





--- Comment #7 from dnovatchev@gmail.com  2010-07-05 15:01:39 ---
(In reply to comment #2)

> 6, 7. I took input here from the Java and .NET specifications. Java states "The
> computed result must be within 1 ulp of the exact result. Results must be
> semi-monotonic". A ulp is defined as "The ulp of a specific real number value
> is the distance between the two floating-point values bracketing that numerical
> value". Apart from the requirement to be semi-monotonic, I believe my
> formulation is equivalent, and that it can be implemented by using the usual
> iterative-approximation approaches with a sufficiently small epsilon. I believe
> I also found some material on the precision guaranteed by the .NET methods, but
> I can't now find it. This input is probably what led me to the idea of offering
> a guaranteed precision only for inputs in some range; I suspect the original
> logic was to permit an implementation that started by taking the input value
> modulo 2*pi, and then getting the nearest value, despite the fact that this
> two-step approach may increase the error. I agree there's more work needed
> here.

The reason for raising problem 6. is that the current text will cause the
programmer to always obtain x modulo 2*pi() before passing it as argument,
believing that this will lead to result with increased precision. 

My understanding, confirmed by Michael Kay above, is that most implementations
in practice will always as a first step get the remainder of dividing the
passed argument value by 2*pi(). Therefore, having this done by the programmer
before they call the trigonometric function will duplicate the implementation,
will cause them loss of time, will be error-prone and will decrease the
readability and maintainability of their code.

Due to this reason I propose that the following text should be omitted in all
function definitions:

"If $è is in the range -2ð to +2ð then the result is the xs:double value
·either side of· the mathematical cosine of the angle; if it is outside this
range, then the precision of the result is ·implementation-dependent·."


For problem 7. I simply wonder how the requirement to return "the nearest
higher xs:double or the nearest lower xs:double" can be tested in practice. And
if this requirement most probably won't be tested, then nobody will ever know
whether this requirement has really been fulfilled. Therefore it is necessary
to provide a more easily testable description of the precision of the returned
result.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Monday, 5 July 2010 15:01:41 UTC