This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Section 2.3.2 of Xml Schema Part 2: Datatypes Second Edition states: Note: All ·minimally conforming· processors ·must· support decimal numbers with a minimum of 18 decimal digits (i.e., with a ·totalDigits· of 18). However, ·minimally conforming· processors ·may· set an application-defined limit on the maximum number of decimal digits they are prepared to support, in which case that application-defined maximum number ·must· be clearly documented. However in the test op-numeric-dividesht2args-5, which contains the following query: xs:short("-32768") div xs:short("32767") suggests the result should be "-1.000030518509", which only contains 13 decimal digits. Although the number of digits returned from arithmetic operations are implementation defined, if the results are not quoted as if they were calculated with the full 18 decimal places of accuracy, the number of decimal places used in the test suite documentation. Another similar issue occurs in the following tests: op-numeric-divideintg2args-2 op-numeric-divideintg2args-4 op-numeric-dividedec2args-2 op-numeric-dividedec2args-4 op-numeric-dividenint2args-2 op-numeric-dividenint2args-4 op-numeric-dividenpi2args-2 op-numeric-dividenpi2args-4 These tests all have the following form: fn:round-half-to-even(___ div ___),18) However the results quoted all only have 12 decimal places. These tests should probably be changed to the following form: fn:round-half-to-even(___ div ___),12) and the tests op-numeric-dividesht2args-3 and op-numeric-dividesht2args-5 should be changed to this form.
I'm not sure I completely understand you. The test case op-numeric-dividesht2args-5 accepts two results, -1.000030518509475997 and -1.000030518509. We discussed and resolved this issue within the XQuery and XSL WGs in http://www.w3.org/Bugs/Public/show_bug.cgi?id=3529. We decided that operations on xs:decimal values can return fewer than 18 disgits of precision. If an implementation returns a value with a different number of digits for some of our test cases, then we will add additional expected results.
Olvier: I think Andrew is correct. Do you have extra results?, otherwise, I will mark this bug as "FIXED". Thanks, carmelo
this is a dup of Bug #3529, but before they are both closed, could one of the entries be updated with the text changes to the spec. The resolution is rather surprising, and clearly requires a spec change. Just how few digits of precison are going to be allowed? David
Well, there's clearly an influential WG member who wants 12 digits... In fact (regrettably) the spec has always been this way. A conformant implementation can return 3.3 as the result of 10 div 3. It can also return 3.3 as the result of 1.1111111111111111111 + 2.22222222222222222. The 18-digit limit has always been a rule about the value space, not about the results of operations. Caveat emptor.
>A conformant implementation can return 3.3 as the result of 10 div 3 By the same reasoning it can presumably also return 42. I admit that you probably don't want to get into specifying exact numerical behaviour (as seen recently with overflow behaviour for average, it's hard to tie these things down) but I think that any natural reading of the spec would lead one to assume that div does do division to the accuracy supported by the underlying datatype, which in this case is at least 18 digits. Otherwise you are saying that (apart from market forces and the common sense of implementors) there is no guarantee that it does division at all: 0 places of accuracy being conformant behaviour, so as long as I return some number so it type checks, that is OK.
There was a bug in our test runner - it was only showing us the last result that didnt match, not all the results, and so I missed the primary results. It seems that the expected results are indeed as I expected, and so the bug is in fact not a bug.