Re: Observability of NaN distinctions — is this a concern?

Kevin Reid kpreid at
Wed Mar 20 14:24:42 PDT 2013

On Wed, Mar 20, 2013 at 1:57 PM, Allen Wirfs-Brock <allen at>wrote:

> On Mar 20, 2013, at 1:42 PM, Kevin Reid wrote:

 That normalization on read is is my case 1 above — it is necessary _for
>> that implementation_. A conformant implementation could use a different
>> strategy which does not normalize on Float64 read, and this would be
>> unobservable, so the spec should not bother to specify it.
>> However, lack of normalization on Float64 write _is_ potentially
>> observable (if the implementation does not normalize all NaNs from all
>> sources). Therefore, I argue, the spec should specify that normalization
>> happens on write; and it happens that an implementation can omit that as an
>> explicit step, with no observable difference, if and only if its
>> representation of NaN in JS values (from all possible sources, not just
>> typed arrays) is normalized.
> The buffer contents may have come form an external source or the buffer
> may be accessible for writes by an agent that is not part of the ES
> implementation.  The only thing that the ES implementation has absolute
> control over are its own reads from a buffer and the values it propagates
> from those reads.

I don't think we're disagreeing about any facts or principles (everything
in your paragraph above is true), but you're thinking about implementation
strategies and I'm thinking about observable behavior.

This is the important point: normalization on write _or
observably-equivalent behavior_ is implicitly mandatory because otherwise 8.1.5
may fail to hold (standard ES code can use standard ES tools to distinguish
NaNs, as demonstrated by my test results — the behavior I found does not
contradict the spec, to my knowledge). Therefore, the spec should not claim
that it is optional.

_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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list