Thanks again. I¡¯ve added a note to the issue, and raised a bug against mingw. (And also updated another related one.)

 

Is the right solution here to get it fixed in mingw? (And would that then be picked up in some future Haskell release?).

 

I¡¯m also still a bit confused about ming-w64 and GCC (which are all very new to me). Per Wikipedia ¡°Mingw-w64 includes a port of the GNU Compiler Collection (GCC)¡±. So why does it have two different implementations of asinh? ?C one for use by GCC (that gives good results), and one that is called at runtime (that gives bad results)?.

 

Thanks! David.

 

From: arata, mizuki
Sent: 04 September 2021 12:41
To: David James
Cc: haskell-cafe@haskell.org
Subject: Re: [Haskell-cafe] Trouble with asinh (c calls with Doubles) in Windows

 

FloatFnInverses is marked as ¡®expect_broken¡¯ on Windows:

https://gitlab.haskell.org/ghc/ghc/-/blob/922c6bc8dd8d089cfe4b90ec2120cb48959ba2b5/testsuite/tests/numeric/should_run/all.T#L44-45

And there¡¯s a relevant issue: https://gitlab.haskell.org/ghc/ghc/-/issues/15670

 

Mizuki



2021/09/04 18:46¡¢David James <dj112358@outlook.com>¤Î¥á?`¥ë:

 

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.

 

So I think this is a (possibly minor) bug that Haskell inherits from mingw-w64. I guess I should raise a GHC issue ?C though I¡¯m not sure whether it would be best to try to fix within Haskell or within mingw-w64.

 

Also, I think the FloatFnInverses.hs 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).

 

Thanks again,

David.

 

From: arata, mizuki
Sent: 03 September 2021 13:43
To: David James
Cc: haskell-cafe@haskell.org
Subject: Re: [Haskell-cafe] Trouble with asinh (c calls with Doubles) in Windows

 

Hi David,

If I understand correctly, GHC uses mingw-w64¡¯s libc implementation on Windows.
Since mingw-w64¡¯s math functions are not of very good quality, it is likely that asinh returns NaN for a very large input.

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.
As a note, you may get a different (compile-time computed) result for `asinh(x)` if you set a more aggressive optimization flag.

Mizuki