<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0cm;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
.MsoChpDefault
        {mso-style-type:export-only;}
@page WordSection1
        {size:612.0pt 792.0pt;
        margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
        {page:WordSection1;}
--></style>
</head>
<body lang="EN-GB" link="blue" vlink="#954F72" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal">Hi - thank you for this. I was unaware of the “constant folding” in GCC (and I’m surprised it works for functions like asinh), but I can see that it explains the difference in behaviour.</p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">So I think this is a (possibly minor) bug that Haskell inherits from mingw-w64. I guess I should raise a GHC issue – though I’m not sure whether it would be best to try to fix within Haskell or within mingw-w64.</p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Also, I think the <a href="https://gitlab.haskell.org/ghc/ghc/-/blob/master/testsuite/tests/numeric/should_run/FloatFnInverses.hs">
FloatFnInverses.hs</a> test doesn’t should be showing as a fail somewhere in the CI testing. (It doesn’t give the expected output when I run it on Windows). Do you know whether/where I can see that? (I don’t know what CI happens or how to view its output).</p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Thanks again,</p>
<p class="MsoNormal">David.</p>
<p class="MsoNormal"><o:p> </o:p></p>
<div style="mso-element:para-border-div;border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal" style="border:none;padding:0cm"><b>From: </b><a href="mailto:minorinoki@gmail.com">arata, mizuki</a><br>
<b>Sent: </b>03 September 2021 13:43<br>
<b>To: </b><a href="mailto:dj112358@outlook.com">David James</a><br>
<b>Cc: </b><a href="mailto:haskell-cafe@haskell.org">haskell-cafe@haskell.org</a><br>
<b>Subject: </b>Re: [Haskell-cafe] Trouble with asinh (c calls with Doubles) in Windows</p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-bottom:12.0pt">Hi David,<br>
<br>
If I understand correctly, GHC uses mingw-w64’s libc implementation on Windows.<br>
Since mingw-w64’s math functions are not of very good quality, it is likely that asinh returns NaN for a very large input.<br>
<br>
As to why `asinh(1.7976931348623157e308)` in CAsinh.c produces (seemingly-correct) 710.4758, it is probably because the C compiler (GCC) uses a different implementation of asinh when doing constant folding.<br>
As a note, you may get a different (compile-time computed) result for `asinh(x)` if you set a more aggressive optimization flag.<br>
<br>
Mizuki<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</body>
</html>