W3C home > Mailing lists > Public > www-dom@w3.org > January to March 2012

Re: [DOM3 Events] Error between float vs. double of WheelEvent

From: Glenn Maynard <glenn@zewt.org>
Date: Sat, 17 Mar 2012 21:45:35 -0500
Message-ID: <CABirCh_cUffGoAhwpY02J1D+NdETHwXz4o5ueUzyAtM0OHj2MQ@mail.gmail.com>
To: Masayuki Nakano <masayuki@d-toybox.com>
Cc: "www-dom@w3.org" <www-dom@w3.org>
On Sat, Mar 17, 2012 at 8:57 PM, Masayuki Nakano <masayuki@d-toybox.com>wrote:

> E.g., following function returns false when I defined them as float.
> function () {
>  var event = new WheelEvent("wheel", { deltaX: 1.0 });
>  return (event.deltaX == 1.0);
> }
> because the deltaX becomes 1.000000xxxxxxxxx (x means random number) by
> the error.

(I'd expect this to happen with 0.1, but 1.0 is exactly representable by
both floats and doubles...)

Do any browsers actually implement WebIDL floats?  This logs
0.10000000000000000555 (a double) in Firefox, Chrome and Opera, even though
HTMLProgressElement.value is a float according to the spec:

<progress value=0.1 id=x>

If it was being rounded to a float, it would log 0.10000000149011611938.

I think that Gecko should define them as double for avoiding this bad
> behavior. Olli agreed with this idea at comment 6 in the bug.
> However, this can make incompatibility with other browsers because this
> really depends on the JS implementation. I don't know whether I should
> suggest to change the definition from float to double or not. Some
> implementation might have same problem if the definition is changed so...

All major desktop browsers seem to treat floating-point literals as
doubles, at least.  If an implementation didn't do that, it'd cause
interoperability problems that can't be fixed at this level...

(To be clear: the question of browsers implementing WebIDL floats, and the
precision of floating-point literals, are two entirely different questions.)

Glenn Maynard
Received on Sunday, 18 March 2012 02:46:04 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 10:46:19 UTC