[Bug 6998] Test orderBy35 / values larger than 1.0E6

http://www.w3.org/Bugs/Public/show_bug.cgi?id=6998


Josh Spiegel <josh.spiegel@oracle.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |josh.spiegel@oracle.com




--- Comment #7 from Josh Spiegel <josh.spiegel@oracle.com>  2009-07-07 20:35:44 ---
I am having the same issues as Bogdan.  

It seems for a given value, there is one closest float value that approximates
it.  For example, take 1.0E17 mentioned by Bodan above.  The closest float
value to this is the one with exponent 183 and mantissa 11641532.  (i.e.
11641532 * 2 ^ (183-150) == 99,999,998,430,674,944).  Given that XQuery
implementations must conform to IEEE 754, all implementations should have this
same internal representation for 1.0E17.  

As mentioned above, the F&O spec does mention that when converting a float
value to a string that implementations may have different representations.  I
assume this is referring to the fact that when you round a value to a certain
precision, you must choose one of the rounding methods (i.e. nearest value)
from the IEEE 754 specification.  The F&O spec also throws in the phrase "inter
alia" ("Among other things" - sec 17.1.2)  in the context of reasons for
different string representations.  I am not sure what this is referring to...
Possibly differences that arise during floating point arithmetic?

Anyway, the spec clearly is implying that some kind of limited precision is
expected when converting a float value to a string.  However, I can not find
any specification of what the precision should be.  Did I miss it?

The XQTS test suite results seem inconsistent to me.  Many tests (about 72)
like casthcds17 seem to assume that the precision should be at least 7. 
However, in the orderBy tests (e.g. orderBy35) it seems the precision is less
than 7.  For example, 1.0E17 (100000000000000000) is represented as the string
"1.0E17" in the reference this result.  In order to get this string
representation for the float value, a precision of 6 or less would have had to
have been used.  With a precision of 7 it would have been "9.9999998E16" (see
the second paragraph of this comment).  Possibly the XQTS assumes that the
precision is lowered as much as possible without destroying the string->float
mapping back to the original value. 

Java's Float.toString works by picking a precision that is small as possible
without making adjacent float values in the value space appear the same.
Continuing the running example, java would pick a precision of "7" in this case
because with a precision of "6", 99,999,998,430,674,944 and its next biggest
value would both appear as 1.0E17 (try adding 1 from the mantissa to verify
this).  see
http://java.sun.com/javase/6/docs/api/java/lang/Float.html#toString(float)

Our implementation starts with Java's Float.toString() in the case that the
value is not in the range (1e-6, 1e6).  We then use a precision of 7 and round
to the nearest value.  This lets us pass the vast majority of XQTS test cases
where this could be an issue.  However, the following orderBy tests fail due to
the seemingly varying precision issue I mentioned above:

orderBy25,35,45,55
orderbylocal-25,35,45,55
orderbywithout-14,21,30,37

Simply adding more reference results may scale unless the float values outside
of the range (1e-6, 1e6) that are output are carefully selected.  For the test
that outputs  1.0E17 (99,999,998,430,674,944)  you would need more than 9
reference results to handle all cases (more than 9 due to the valid rounding
alternatives in IEEE 754).  

We will report these failures as successes anyway so we don't feel it is urgent
that this be addressed.  However, it seems it should be fixed somehow
eventually to save future implementers from unnecessary grief.

Full disclosure: I have only recently began to study floating points in order
to understand this issue.  I apologize in advance if I have overlooked or
misunderstood something. 


-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Tuesday, 7 July 2009 20:35:54 UTC