On Wed, Mar 20, 2013 at 2:24 PM, Kevin Reid <kpr...@google.com> wrote: > On Wed, Mar 20, 2013 at 1:57 PM, Allen Wirfs-Brock <al...@wirfs-brock.com> > 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.
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. -Ken > _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@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
