W3C home > Mailing lists > Public > public-qt-comments@w3.org > April 2016

[Bug 29408] [QT3] Precision in extvardeclwithouttype-18

From: <bugzilla@jessica.w3.org>
Date: Sun, 03 Apr 2016 23:50:25 +0000
To: public-qt-comments@w3.org
Message-ID: <bug-29408-523-M0Tb2aaVID@http.www.w3.org/Bugs/Public/>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=29408

Abel Braaksma <abel.braaksma@xs4all.nl> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |abel.braaksma@xs4all.nl

--- Comment #4 from Abel Braaksma <abel.braaksma@xs4all.nl> ---
I would like to push back on the proposed solutions in comment#2 and comment#3.

fn:avg((1,2,4)) is fn:sum((1,2,4)) div 3, which is xs:integer(7) div
xs:integer(3) resulting in xs:decimal with value of 7/3.

The spec mandates that minimally conforming processors support at least 18
total digits (XSD 1.0) or 16 total digits (XSD 1.1, see also Bug 29552) . That
means that:

2.33333333333333333 (Benito's processor, is correct: 18 digits)
2.333333333333333 (XSD 1.1 minimum, is correct: 16 digits)
2.333333333333 (alternative in current test is incorrect: 13 digits)
2.333333333333333333 (alternative in current test is allowed, but not required:
19 digits)

The solution in comment#2 allows wrong answers regardless of the precision, and
the solution in comment#3 allows too little precision. I suggest something like
any of the following three alternatives:

exact: 2.33333333333333333
exact: 2.333333333333333
regex: 2.333333333333333333+

Since rounding is not an issue here, any precision will always end with a
sequence of "3", so this will work as well and catches all mandatory and
optional precisions (preventing an implementation to allow, for instance, to
have 2.333300 or 2.33334 as valid answer):

regex: 2.333333333333333(33+)?

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
Received on Sunday, 3 April 2016 23:50:29 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:57:59 UTC