- From: <bugzilla@jessica.w3.org>
- Date: Mon, 05 Jul 2010 18:36:41 +0000
- To: public-qt-comments@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10073 --- Comment #11 from dnovatchev@gmail.com 2010-07-05 18:36:41 --- (In reply to comment #10) > >returned result must have all of its k decimal digits > A definition that relies on converting the result to decimal digits seems only > to add difficulty; it's better to define the double result without reference to > its decimal equivalent. I don't think there's a real problem with the > testability of the current definition. For example, consider sin(0.5e0) (for > which Java gives 0.479425538604203) > (a) Wolfram Alpha gives us the exact result > 0.4794255386042030002732879352155713880818033679406000675..., > (b) > xs:string(xs:double(0.4794255386042030002732879352155713880818033679406000675)) > is 0.479425538604203 which is a bit smaller > (c) the rules therefore also allow the next double greater than this, which we > can find by translating to the internal form 3fdeaee8744b05f0, adding one to > give 3fdeaee8744b05f1, and translating back to a double which displays as the > decimal 0.47942553860420306. The two acceptable answers for sin(0.5) are > therefore these two xs:double values, so we can write the test as > sin(0.5) = (xs:double(0.479425538604203), xs:double(0.47942553860420306)) > We can write the above as the test query and "true" as the expected result. > Of course the test results can be challenged if anyone believes that either the > Wolfram Alpha result or any of the subsequent inferences is wrong. I agree with this example of how testing is to be done correctly. Probably the current definition should be ammended to specify at least a hint of a testing approach, adding that the value of the "mathemathical function" is well approximated by well-known reliable resources such as Wolfram Alpha and .. (at least two need to be listed in order to avoid any bias or overreliance). -- 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 18:36:43 UTC