[Bug 12220] Make sure rules for parsing a float are the same in HTML and in Javascript specifications

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

Aryeh Gregor <Simetrical+w3cbug@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |

--- Comment #9 from Aryeh Gregor <Simetrical+w3cbug@gmail.com> 2011-05-06 17:14:24 UTC ---
If the only problem is things like Infinity, why don't you invoke ParseFloat
from ES and then explicitly handle the Infinity/-Infinity/NaN cases?  That way
you don't risk any unexpected differences.

The step "Let rounded-value be the number in S that is closest to value,
selecting the number with an even significand if there are two equally close
values" in the current algorithm is particularly unreasonable.  That's not
algorithmic at all.  There's no obvious way to implement it, unless maybe
you're a lot more familiar with floating-point numbers than I am.

In particular, my inability to implement the spec's algorithm makes it hard to
rigorously test it.  I ran into this when doing the reflection tests.  If the
spec was based on parseFloat(), I could at least test that the parseFloat()
implementation matches the HTML floating-point parsing implementation, in
addition to testing various specific values to make sure they're correct.

-- 
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 Friday, 6 May 2011 17:14:40 UTC