This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
A number of test cases have decimal results with 18 digits of precision. F&O, in section 6.2, Operators on Numeric Values, says: "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." I will suggest that test cases support the following additional values: Test Case Existing value Additional Value op-numeric-divideintg2args-2 -0.830993497117024305 -0.830993497117 op-numeric-divideintg2args-4 -1.203378851301859738 -1.203378851301 op-numeric-dividedec2args-2 -0.61737519160851484 -0.6173751916085 op-numeric-dividedec2args-4 -1.619760582531006901 -1.619760582531 op-numeric-dividelng2args-2 0.51147847028770199 0.511478470287 op-numeric-dividelng2args-4 1.95511650654133906 1.955116506541 op-numeric-dividenint2args-2 0.297014075999096793 0.297014075999 op-numeric-dividenint2args-3 0.000000000000000001 0 op-numeric-dividenint2args-4 3.366843799022646172 3.366843799022 op-numeric-dividepint2args-4 0.00000000000000002 0 op-numeric-dividepint2args-5 0.000000000000000001 0 op-numeric-dividenpi2args-2 0.47568843727187049 0.475688437271 op-numeric-dividenpi2args-4 2.102216328265447024 2.102216328265 op-numeric-dividesht2args-3 -0.999969482421875 -0.999969482421 op-numeric-dividesht2args-5 -1.000030518509475997 -1.000030518509
Andrew: Thanks for the comment and looking into this. I added an extra outcome for the tests in question. Thanks, Carmelo
I am correcting two small items: - The alternate result for op-numeric-dividedec2args-4 was added with a leading space character. I have removed that character. - The alternate result for op-numeric-dividesht2args-3 that should have been added was -0.999969482421. The value added was -1.000030518509, copied from the wrong row. I'm correcting this.
I don't think this is a valid interpretation of the above two sentences. The first sentence must be read in the context of the second, which creates a relationship between the number of digits in the result of decimal division and the number of digits supported by the xs:decimal data type. The latter must be at least 18, and I believe that the result of division should therefore not truncate or round unless it requires more than 18 digits. Furthermore, it doesn't make sense to have just two results, one with 18 digits and one with 12, when the actual number of digits is implementation-defined.
Since we differ on our interpretation of the F&O rules, we will leave this bug report open for now and I will bring this issue to the XSL and XML Query WGs. The two expected results for these test cases will remain in the test suite until we have the resolution from the WGs.
Andrew: Thanks for the fixes. I will leave the bug as assigned to me, pending a resolution from the Working Group. Thanks, Carmelo
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