[Bug 8047] Reflecting floats: The rules for parsing floating point number values return an unlimited-precision (finite in base 10) number. How is it converted to limited-precision IDL attribute types? In particular, what rounding mode is used? and do very large valu

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


Philip Taylor <excors@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |excors@gmail.com
             Status|RESOLVED                    |REOPENED
           Keywords|                            |NE
         Resolution|FIXED                       |




--- Comment #3 from Philip Taylor <excors@gmail.com>  2009-10-25 10:10:14 ---
It seems clearer now, but weird, because it doesn't match how floats are parsed
in ECMAScript (or any other environments I'm aware of, though that's not many).

E.g. the string
  "1.00000000000000012"
in common ECMAScript implementations gets converted to the number
   1.0000000000000002
(and if you subtract 1 then you get 2.220446049250313e-16)
whereas HTML5 now just talks about "truncating", so it would end up with the
number 1.0 (being the next lowest representable number).

I don't see any reason to differ from ES, and doing so seems like it could make
implementations more complex (since they couldn't be based on existing
float-parsing code).

ES defines ToNumber as truncating after the 20th significant digit and then
(optionally) incrementing the 20th significant digit, and then doing
round-to-nearest with ties-to-even. But these are (32-bit) floats, not Numbers,
so HTML5 can't do exactly the same.

It might be better to copy the definition from
http://dev.w3.org/2006/webapi/WebIDL/#es-float , saying something like:

    "A number n is <dfn>converted to an IDL float value</dfn> by running the
following algorithm:
    1. Let S be the set of finite IEEE 754 single-precision floating point
values except &#8722;0, but with two special values added: 2^128 and
&#8722;2^128.
    2. Let V be the number in S that is closest to n, selecting the number with
an even significand if there are two equally close values. (The two special
values 2^128 and &#8722;2^128 are considered to have even significands for this
purpose.)
    3. If V is 2^128, return +&#8734;.
    4. If V is &#8722;2^128, return &#8722;&#8734;.
    5. Return V.

    ...

    If a reflecting IDL attribute is a floating point number type (float),
then, on getting, the content attribute must be parsed according to the rules
for parsing floating point number values, and if that is successful, the number
must be <a href>converted to an IDL float value</a>; and if the resulting value
is finite, then that value must be returned. If, on the other hand, the parsing
fails or the conversion returns an infinite value, ..."

(n can't be NaN or &#8722;0, so those cases aren't handled here.)

I doubt that is perfectly correct (perhaps n needs to be truncated before
rounding?), and it would be good if someone who understands floating point
parsing properly could suggest something better, but I think this is better
than what the spec says now.


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

Received on Sunday, 25 October 2009 10:10:19 UTC