- From: Allen Wirfs-Brock <allen@wirfs-brock.com>
- Date: Mon, 13 Feb 2012 11:16:29 -0800
- To: Boris Zbarsky <bzbarsky@MIT.EDU>
- Cc: Sigbjorn Finne <sigbjorn.finne@gmail.com>, "public-script-coord@w3.org" <public-script-coord@w3.org>
On Feb 13, 2012, at 5:12 AM, Boris Zbarsky wrote: > On 2/13/12 3:34 AM, Sigbjorn Finne wrote: >> On Wed, Feb 8, 2012 at 5:28 AM, Boris Zbarsky <bzbarsky@mit.edu >> <mailto:bzbarsky@mit.edu>> wrote: >> >> The current WebIDL algorithm for long long says: >> >> Set x to sign(x) * floor(abs(x)). >> Set x to x modulo 2^64. >> If x is greater than or equal to 2^63, then set x to x − 2^64. >> If x < −(2^53 − 1) or x > 2^53 − 1, then throw a TypeError. >> >> This makes no sense. The justification is something about how your x >> might have lost precision and so you may not be hitting the 64-bit >> int you "wanted"... but in that case the check-and-throw should be >> done before reduction mod 2^64. Doing it after just means the result >> is somewhat random once your double is greater than 2^64. >> >> The purpose of the third step is to adjust sign, I'd say. > > Yes, of course. My point was that doing the fourth step after the second step is nonsensical. I agree, if you want that check it needs to be after step 2. But I think there may be more fundamental issues here. Does it really make sense to do mod 2^64 value wrap-around for values >2^64. Line 45 is intended to throw on integer that are possibly imprecise (low order bits rounded) values in the range 2^53..2^64-1. However, line 2 means that every value of x is possibly imprecise because of rounding in that step. It would seem that you either shouldn't do the wrap-around or you shouldn't throw on possibly imprecise values. Allen
Received on Monday, 13 February 2012 19:17:07 UTC