15233 2011-12-16 15:41:33 +0000 [QT3TS] math-exp10-004, math-tan-006, math-tan-007 2013-03-20 10:48:44 +0000 1 1 1 Unclassified XPath / XQuery / XSLT XQuery 3 & XPath 3 Test Suite Member-only Editors Drafts PC Windows NT CLOSED INVALID P2 normal --- 1 tim jim.melton andrew.eisenberg jim.melton mike oneil public-qt-comments oldest_to_newest 61664 0 tim 2011-12-16 15:41:33 +0000 Our implementation returns the following results which differ from the expected results by a single bit in their representation. math-exp10-004: 3.162277660168379 math-tan-006: 1.6331778728383844E16 math-tan-007: -1.6331778728383844E16 61669 1 mike 2011-12-16 15:50:36 +0000 Yes, we observed a similar effect with Saxon - the .NET library methods give slightly different results to the Java library methods. I haven't attempted to work out whether both are conformant to the IEEE spec, which is what we reference. 67839 2 oneil 2012-05-18 09:48:04 +0000 We need discussion on whether to accept these results. 68059 3 mike 2012-05-23 15:10:27 +0000 The first test is exp10(0.5), which means the same as sqrt(10), which Wolfram Alpha gives as 3.162277660168379331998893544432718533719555139325216826857504852792594438639238221344248108379300295187... This lies between the two candidate results of 3.162277660168379 and 3.1622776601683795. Note that for math-tan-006 and math-tan-007 the mathematical answer is infinity (and this is the value that Wolfram Alpha gives). So the test is close to a singularity in the function, which means that expecting high precision in the answer is unreasonable. If we accept pi = 3.141592653589793, we have two possible value for pi/2 depending on the rounding mode: 1.5707963267948966 and 1.5707963267948967. According to WA, tan(1.5707963267948966) is 5.1998506188720270660194741661226868475811544986... × 10^16, while tan (1.5707963267948966) is -1.238103706714353220651983005784184862681851980... × 10^16. So if we allow pi/2 to be rounded either way, the range of permissible values here is vast. In the spec we say "the preferred quantum is implementation-defined". I think this may be a misunderstanding of what the 'quantum' is. I suspect that by specifying that the operations are done in xs:double floating point, we have effectively defined the quantum. More pertinently to this bug, th IEEE spec says (in 4.3) there is a choice of "rounding direction", with options such as towards zero, towards positive, towards negative. We haven't said anything about this. We should probably say "The choice of rounding direction, and any mechanisms for influencing the choice of rounding direction, are implementation-defined." This means that the two results for sqrt(10) given above differ only in the choice of rounding direction, and both are therefore acceptable. Recommendation: (a) for math-tan-006 and math-tan-007, change the tests to avoid evaluating the function so close to a singularity, where there is a high sensitivity to legitimate implementation differences. (b) for math-exp10-004, accept both results (c) in the spec, change what we say about precision of results, to include the statement about rounding direction given above. 68283 4 mike 2012-05-29 22:38:23 +0000 The recommendations in comment 3 were accepted by the WG and have been implemented. 68387 5 tim 2012-05-31 10:11:31 +0000 For math-tan-006: math:tan(math:pi() div 4) I get the result 0.9999999999999999 For math-tan-007: math:tan(math:pi() div 4) I get the result -0.9999999999999999 68390 6 mike 2012-05-31 10:36:08 +0000 Those look identical to the results expected - I'm not sure what the problem is. 68400 7 tim 2012-05-31 12:05:27 +0000 The problem turned out to be an error in casting from decimal to double in the test harness. Note that the expected result is expressed as a decimal, whereas the actual result is a double. 84719 8 oneil 2013-03-20 10:48:44 +0000 *** Bug 18478 has been marked as a duplicate of this bug. ***