Re: Observability of NaN distinctions — is this a concern?
allen at wirfs-brock.com
Wed Mar 20 14:47:53 PDT 2013
On Mar 20, 2013, at 2:38 PM, Kenneth Russell wrote:
> The typed array specification in its original form deliberately
> avoided specifying normalization of NaNs upon writes to Float32Array
> and Float64Array. Doing so has no practical value and only imposes a
> performance hit, which is unacceptable for applications trying to
> reach the highest possible performance.
> I hope that the ES6 integration of typed arrays will not require
> normalization of NaNs on write, even if other specification changes
> need to be made to avoid requiring it.
Here is the exact language that is in the current ES6 draft for storing a Number into a buffer as a Float64 (rawValue is the value that gets stored into the buffer):
Set rawValue to the 8 bytes that are the IEEE-868-2005 binary64 format encoding of value. If isBigEndian is true, the bytes are arranged in big endian order. Otherwise, the bytes are arranged in little endian order. If value is NaN, rawValue is may be set to any implementation choosen non-signaling NaN encoding.
>> _Incidentally_, I observe that normalization on read is not necessary except
>> as an implementation strategy. It may well be that all implementations will
>> find it expedient, but there is no need for the spec to require it, since
>> (as 8.1.5 specifically acknowledges) an implementation may choose to let the
>> NaN bits vary, as long as all operations on them (which includes
>> SetValueInBuffer by my above argument) treat them identically.
>> es-discuss mailing list
>> es-discuss at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss