On Wed, Aug 21, 2013 at 1:45 AM, Roland Scheidegger <srol...@vmware.com> wrote: > Am 21.08.2013 01:28, schrieb Roland Mainz: >> On Wed, Aug 21, 2013 at 1:12 AM, <srol...@vmware.com> wrote: >>> From: Roland Scheidegger <srol...@vmware.com> [snip] >> Can you check whether the new code supports -nan correctly, please >> (-nan is used by scientific software... we learned that the hard way >> when we had to fix this in ksh93 for Sun) ? >> > > This code is built to adhere to graphics apis, usually d3d10 (because it > tends to be more strict than opengl/glsl). > As such there's no rules (I think) as far as propagating "the right nan" > concerns, and there's no distinction really between negative/positive > QNaNs/SNaNs. The is_finite will catch all kind of nans (plus infs, > obviously), but the output will always be the same NaN in this case, > sign bits etc. will be lost (though IIRC sign bit, while possible with > nan's, doesn't really have much meaning anyway).
Erm... the issue is (as Sun learned the hard way) that programmers may use -nan and nan explicitly to pass error conditions down the arithmetic chain without "littering" the "hot codepaths" with if()/else (instead at the end the result is tested for -nan/nan to see where the code approximately failed). ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.ma...@nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;) _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
