W3C home > Mailing lists > Public > public-script-coord@w3.org > January to March 2012

Re: Conversion of ES Number to WebIDL long long and unsigned long long should not throw by default

From: Allen Wirfs-Brock <allen@wirfs-brock.com>
Date: Mon, 13 Feb 2012 11:16:29 -0800
Cc: Sigbjorn Finne <sigbjorn.finne@gmail.com>, "public-script-coord@w3.org" <public-script-coord@w3.org>
Message-Id: <A4830566-40BD-4A27-A3EF-D2ECBB767065@wirfs-brock.com>
To: Boris Zbarsky <bzbarsky@MIT.EDU>

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

This archive was generated by hypermail 2.3.1 : Wednesday, 8 May 2013 19:30:05 UTC