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

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





--- Comment #9 from dnovatchev@gmail.com  2010-07-05 17:15:06 ---
(In reply to comment #8)
> >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.
> Based on past experience:
> (a) Someone will submit a test together with the result that their
> implementation returns
> (b) If any other implementor gets a value that differs from this, they will
> argue about it until we are satisfied what the correct answer is, and either
> add a second permitted result or change the expected result accordingly.
> Because there are only two legitimate results, this process seems quite
> manageable. Verifying the correct answers needs access to a quad- or
> variable-precision trig library, there is surely one available somewhere.

So, the tester will rely on the correctness of the quad- or variable-precision
trig library, but will not prove themselves the correctness? How do we know in
the first place that the quad- or variable-precision trig library really
produces correct, according to the definition, result(s)? What if it was
insufficiently tested or the tests were not too representable?

I am trying to think of a more testable definition of the required precision of
the result. Can't it be something like the following:

"If for any given x the decimal fraction of the value of the mathematical
function is:

d1 d2 d3 ... dn d(n+1)...

then the returned result must have all of its k decimal digits equal to d1 - dk
and it should be impossible to represent the number .d1 d2 d3 ... dk d(k+1) as
a double precision number".

The "mathematical function value" should be taken from reputable sources such
as the Wolfram's mathworld site (http://mathworld.wolfram.com/).

-- 
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 17:15:09 UTC