<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">Am Do., 7. Feb. 2019 um 17:22 Uhr schrieb Henning Thielemann <<a href="mailto:lemming@henning-thielemann.de">lemming@henning-thielemann.de</a>>:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">[...] What about calling into foreign code? If I call a BLAS routine and one <br>
element of the result vector is NaN, shall this be trapped? Or shall it be <br>
trapped once I access the NaN element?<br></blockquote><div><br></div><div>IMHO this is the biggest show stopper for some exotic NaN handling, as correct as it may be mathematically or aesthetically: The floating point environment is a thread-local (i.e. basically global) entity on most platforms, and most programming language runtimes expect a "default" environment, i.e. no traps when NaNs are encountered. So if Haskell wants to do things differently, the FPE has to be set/reset around foreign calls and for around every Haskell callback. I am not sure if this is really worth the trouble and the performance loss. For some special applications it might be OK or even important, but my gut feeling is that trapping NaNs is the wrong default in our current world...</div></div></div></div></div>