3528 2006-07-24 16:54:39 +0000 additional expected values for decimal operations, part 2 2006-08-03 20:35:30 +0000 1 1 1 Unclassified XML Query Test Suite XML Query Test Suite unspecified PC Windows XP RESOLVED FIXED P2 normal --- 3443 1 andrew.eisenberg carmelo public-qt-comments oldest_to_newest 10724 0 andrew.eisenberg 2006-07-24 16:54:39 +0000 In #3443, I reported a number of test cases for which I felt additional results were justified. I'd like to add to that list and suggest that test cases support the following additional values: Test Case Existing value Additional Value extvardeclwithouttype-18 2.333333333333333333 2.333333333333 extvardeclwithtype-18 2.3333333 2.33333 fn-avg-mix-args-009 -50.5000000000005 -50.5 10738 1 mike 2006-07-24 17:57:53 +0000 Concerning extvardeclwithouttype-18, this effectively returns the result of (7 div 3) (which is an xs:decimal). This is governed by the rule: For xs:decimal values the number of digits of precision returned by the numeric operators is ·implementation-defined·. If the number of digits in the result exceeds the number of digits that the implementation supports, the result is truncated or rounded in an ·implementation-defined· manner. Implementations are required to support at least 18 digits. My reading is that you have to take the two sentences together, and this means that the result of the division must be at least 18 digits. Therefore the result 2.333333333333 is wrong. On a more practical point, however, it's clear that there are an infinite number of correct results for this query. The simplest solution would therefore be to change the query so that instead of computing avg(4,2,1), it computes avg(8,4,2,1), which is incontrovertibly 7.5. Concerning extvardeclwithtype-18, the result here is the decimal value of (8 div 3) converted to a float. Similar considerations therefore apply. Concerning fn-avg-mix-args-009 teh query here is: fn:avg( ( ( xs:decimal("-1.000000000001"), xs:integer("-100")))) The correct answer to this can be expressed exactly in 15 decimal digits of precision, and since all products are required to support this number of digits, I do not think any answer other than -50.5000000000005 is acceptable. 10741 2 andrew.eisenberg 2006-07-24 20:45:47 +0000 Carmelo, please add these expected results to their associated test cases. We can remove them once we have a rulin gfrom the XSL and XML Query WGs. 10801 3 carmelo 2006-07-25 19:24:45 +0000 All: Added extra values and will leave bug open, pending a resolution of the Working Group. Thanks, Carmelo 10803 4 andrew.eisenberg 2006-07-25 22:00:40 +0000 Found one more of these Test Case Existing value Additional Value op-divide-dayTimeDuration-by-dTD-1 1.437834967320261 1.4378349673 10848 5 andrew.eisenberg 2006-07-27 16:52:30 +0000 I keep thinking that I've found the last of these, but ... Test Case Existing value Additional Value op-numeric-dividesht2args-5 -1.000030518509475997 -1.000030518509 op-divide-dayTimeDuration-by-dTD-1 1.437834967320261 1.4378349673 I've added the additional expected results to these test cases, so no further action is required until we get a ruling from the WGs. 11017 6 carmelo 2006-08-03 20:35:30 +0000 As per the working groups decison to allow arbitrary number of digits. 15 digits is acceptable for these types of decimal operations. I am marking this bug as closed. Any implementatin that differs from the given outcomes should provide those to the Task force. Thanks, Carmelo