[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] NaN handling in Typed Array spec
- To: email@example.com
- Subject: Re: [Public WebGL] NaN handling in Typed Array spec
- From: Kenneth Russell <firstname.lastname@example.org>
- Date: Tue, 8 Feb 2011 15:49:47 -0800
- Dkim-signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1297208990; bh=4XutvqkQzY/BvGbxzNjmXFPX/i8=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Content-Type:Content-Transfer-Encoding; b=lXkL9SdOxpCYZ4pbtfmi+zwhieQ5RawOkYsTe9S6/NG7FLgiag5VkCY12qzbSVuIJ TzoXfWJygdwu+VHaabKmA==
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type:content-transfer-encoding; bh=eUwUeSPYix25iAaMpNOnBn/RnUv34Yr94nhXI9WmM78=; b=Q0Mb1HHrxX1dsS8+J3lxolJC/VtTsCFuTm8Z1ZY4+ADaeKa0av29aVr29xzqNXFRKz rvjAJy5f4BMtkHfWWKwg==
- Domainkey-signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=jkaLK9dFMf1uOuGrXgsQ/ds42KeZU0qVuHsNScVsCaixVaS6QQ6NSA36UMowDfSacI MfDmF2axjRVHLPTJ/b8g==
- In-reply-to: <20110208044805.GG4785@wok.mcc.id.au>
- List-id: Public WebGL Mailing List <public_webgl.khronos.org>
- References: <AANLkTim3_kDOBp5OSBctY0jNYK_ZiXQjM5GKZwHmAe8s@mail.gmail.com> <20110208044805.GG4785@wok.mcc.id.au>
- Sender: email@example.com
On Mon, Feb 7, 2011 at 8:48 PM, Cameron McCormack <firstname.lastname@example.org> wrote:
> Kenneth Russell:
>> A bug was recently filed against WebKit's implementation of Typed
>> Arrays (https://bugs.webkit.org/show_bug.cgi?id=53598). The basic
>> issue is that the Web IDL specification defines the bit pattern
>> for the not-a-number (NaN) value. Ordinarily, it is not possible
>> for ECMAScript programs to examine this bit pattern, but with the
>> introduction of the Typed Array specification, it is possible to use
>> a Float32Array to store NaN and then read back the bytes using, for
>> example, a Uint8Array.
> The IDL float type is exactly an IEEE 754 single. When a JS Number
> value is converted into an IDL float (by assigning to a property
> corresponding to an IDL attribtue of type float, or by passing as an
> argument it to a method whose corresponding IDL operation argument is of
> type float), then a particular bit pattern is chosen for that IDL float
> value, yes.
> If it is defined that a Float32Array stores in the array exactly
> whatever value comes out of the “convert a JS value to an IDL float
> value” algorithm (which is what you would get without any special
> wording, if you just refer to the ‘float value’ argument of
> Flaot32Array::set()), and if a Uint8Array can be overlaid on that memory
> to read the bit pattern, then that’s the bit pattern you should get.
> If you want to define Float32Array such that assigning the JS NaN value
> to one of its array index properties instead stores a different NaN
> bit pattern in the array, that’s fine, but you just need to define that.
> The IDL float value that you get from converting the JS NaN need not be
> the same value that gets stored in the array – the value that is stored
> is whatever the definition of the Float32Array::set() operation says is
>> Some ECMAScript engines use multiple representations for NaN
>> internally, and forcing them to be canonicalized into a single bit
>> pattern would impose a significant performance penalty on all stores
>> into Float32Arrays. It is absolutely essential for WebGL programs that
>> loads from and stores into Float32Arrays remain as performant as
>> I would like to add a small, normative section to the Typed Array
>> specification indicating that the bit pattern for NaN values stored
>> using Float32Array, Float64Array and DataView is not specified, and
>> that implementations may utilize any of the legal NaN bit patterns
>> defined by the IEEE-754 specification. I do not believe that doing so
>> would introduce any significant ambiguity into the spec; this is a
>> small corner case.
> A requirement like that wouldn’t violate Web IDL, so it’s OK from that
Thanks, that's good to know.
I've added normative text on NaN handling to the Typed Array spec and
made the previous section on type conversion rules normative. These
two sections are now referenced from the documentation of the typed
array indexed getters and setters, as well as the get and set methods
Please post any comments to the list.
You are currently subscribed to email@example.com.
To unsubscribe, send an email to firstname.lastname@example.org with
the following command in the body of your email: