> <jussi.kallioko...@gmail.com> > wrote: > > That's just because ES has had no notion of bits for floating points before. > Other than that, ES NaN works like IEEE NaN, e.g. >
Some background about the latest GLS spec and IEEE NaNs from http://www.opengl.org/registry/doc/GLSLangSpec.4.20.11.clean.pdf Section 4.1.4 states "As an input value to one of the processing units, a single-precision or double-precision floating-point variable is expected to match the corresponding IEEE 754 floating-point definition for precision and dynamic range. Floating-point variables within a shader are also encoded according to the IEEE 754 specification for single-precision floating-point values (logically, not necessarily physically)." Section 4.7.1 goes on to provide a detailed list of reduced (from IEEE 754) precision requirements for single precision floats and then states the following: "The precision of double-precision operations is at least that of single precision." 4.7.1 also sets up the requirements of operations to produce NaNs as follows: " NaNs are not required to be generated. Support for signaling NaNs is not required and exceptions are never raised. Operations and built-in functions that operate on a NaN are not required to return a NaN as the result." So any statement that the GLS spec follows IEEE 754 treatment of double precision is only a statement about input values. - Rick -----Original Message----- From: es-discuss-boun...@mozilla.org [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Andreas Rossberg Sent: Tuesday, March 26, 2013 6:40 AM To: Oliver Hunt Cc: Mark S. Miller; Brendan Eich; es-discuss Subject: Re: Observability of NaN distinctions — is this a concern? I'm with Dave and Oliver. Worrying about the performance cost of NaN normalisation has a strong smell of premature micro optimisation. The one branch per float store, whose cost should be amortised by branch prediction when frequent, seems very unlikely to be measurable compared to everything else going on when executing JavaScript. As for the "this is not a common problem" argument, use cases should only trump principles if the cost is unbearable. /Andreas On 26 March 2013 09:29, Oliver Hunt <oli...@apple.com> wrote: > > On Mar 26, 2013, at 9:12 PM, Jussi Kalliokoski > <jussi.kallioko...@gmail.com> > wrote: > > That's just because ES has had no notion of bits for floating points before. > Other than that, ES NaN works like IEEE NaN, e.g. > > 0/0 === NaN // false > isNaN(0/0) // true > > > That's true in any language - comparing to NaN is almost always > defined explicitly as producing false. You're not looking at bit > patterns, here so conflating NaN compares with bit values is kind of > pointless. > > > > > >> >> >> >>> >>> >>>> >>>> We need to stop raising "this causes performance problems" type >>>> issues without a concrete example of that problem. I remember >>>> having to work very hard to stop WebGL from being a gaping security >>>> hole in the first place and it's disappointing to see these same >>>> issues being re-raised in a different forum to try and get them bypassed >>>> here. >>> >>> >>> Before saying security hole, please elaborate. Also, when it comes >>> to standards, I think change should be justified with data, rather >>> than the other way around. >> >> >> Done. > > > You'll have to do better than that. ;) > > > Ok, I'll try to go over this again, because for whatever reason it > doesn't appear to stick: > > If you have a double-typed array, and access a member: > typedArray[0] > > Then in ES it is a double that can be one of these values: > +Infinitity, -Infinity, NaN, or a discrete value representable in IEEE double > spec. > There are no signaling NaNs, nor is there any exposure of what the > underlying bit pattern of the NaN is. > > So the runtime loads this double, and then stores it somewhere, > anywhere, it doesn't matter where, eg. > var tmp = typedArray[0]; > > Now you store it: > typedArray[whatever] = tmp; > > The specification must allow a bitwise comparison of > typedArray[whatever] to typedArray[0] to return false, as it is not > possible for any NaN-boxing engine to maintain the bit equality that > you would otherwise desire, as that would be trivially exploitable. > When I say security and correctness i mean it in the "can't be remotely > pwned" sense. > > Given that we can't guarantee that the bit pattern will remain > unchanged the spec should mandate normalizing to the non-signalling NaN. > > --Oliver > > > > Cheers, > Jussi > >> >> >> >>> >>> >>> Cheers, >>> Jussi >>> >>>> >>>> --Oliver >>>> >>>> > Allen >>>> > >>>> > >>>> > >>>> > >>>> >> >>>> >> /be >>>> >> >>>> >> On Mar 25, 2013, at 4:33 PM, Kenneth Russell <k...@google.com> wrote: >>>> >> >>>> >>> On Mon, Mar 25, 2013 at 4:23 PM, Brendan Eich >>>> >>> <bren...@mozilla.com> >>>> >>> wrote: >>>> >>>> Allen Wirfs-Brock wrote: >>>> >>>>> >>>> >>>>> On Mar 25, 2013, at 4:05 PM, Brendan Eich wrote: >>>> >>>>> >>>> >>>>>> Allen Wirfs-Brock wrote: >>>> >>>>>>> >>>> >>>>>>> BTW, isn't cannonicalization of endian-ness for both >>>> >>>>>>> integers and floats a bigger interop issue than NaN >>>> >>>>>>> cannonicalization? I know this was discussed in the past, >>>> >>>>>>> but it doesn't seem to be covered in the latest Khronos >>>> >>>>>>> spec. Was there ever a resolution as to whether or not >>>> >>>>>>> TypedArray [[Set]] operations need to use a cannonical >>>> >>>>>>> endian-ness? >>>> >>>>>> >>>> >>>>>> Search for "byte order" at >>>> >>>>>> https://www.khronos.org/registry/typedarray/specs/latest/. >>>> >>>>> >>>> >>>>> >>>> >>>>> I had already search for "endian" with similar results. It >>>> >>>>> says that the default for DataViews gets/sets that do not >>>> >>>>> specify a byte order is big-endean. It doesn't say anything >>>> >>>>> (that I can find) about such accesses on TypedArray >>>> >>>>> gets/sets. >>>> >>>> >>>> >>>> >>>> >>>> Oh, odd -- I recall that it used to say little-endian. Typed >>>> >>>> arrays are LE to match dominant architectures, while DataViews >>>> >>>> are BE to match packed serialization use-cases. >>>> >>>> >>>> >>>> Ken, did something get edited out? >>>> >>> >>>> >>> No. The typed array views (everything except DataView) have >>>> >>> used the host machine's endianness from day one by design -- >>>> >>> although the typed array spec does not state this explicitly. >>>> >>> If desired, text can be added to the specification to this >>>> >>> effect. Any change in this behavior will destroy the >>>> >>> performance of APIs like WebGL and Web Audio on big-endian >>>> >>> architectures. >>>> >>> >>>> >>> Correctly written code works identically on big-endian and >>>> >>> little-endian architectures. See >>>> >>> http://www.html5rocks.com/en/tutorials/webgl/typed_arrays/ for >>>> >>> a detailed description of the usage of the APIs. >>>> >>> >>>> >>> DataView, which is designed for input/output, operates on data >>>> >>> with a specified endianness. >>>> >>> >>>> >>> -Ken >>>> >>> _______________________________________________ >>>> >>> 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 >>>> >> >>>> > >>>> > _______________________________________________ >>>> > 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 >>> >>> >>> >>> _______________________________________________ >>> es-discuss mailing list >>> es-discuss@mozilla.org >>> https://mail.mozilla.org/listinfo/es-discuss >>> >> >> >> >> -- >> Cheers, >> --MarkM > > > > > _______________________________________________ > 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 _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
