Hmm, minefield ahead.. But surely there must be a "correct" compromise?
(Even with a huge performance penalty.)
I'll just add that rwbarton had this comment earlier:
"Be aware (if you aren't already) that GHC does not do any management of
floating-point control registers, so functions called through FFI should
take care to clean up their floating-point state, otherwise the rounding
mode can change unpredictably at the level of Haskell code."
So, there're some FFI related issues even if we just leave the work to C.
I'll also note that the current implementation of arithmetic on
Double/Floats already has rounding mode issues: If someone does an FFI call
to change the rounding mode via C (fgetround/fsetround functions) inside
some IO block, then the arithmetic in that block cannot be "lifted" out
even though it appears pure to GHC. Perhaps that should be filed as a bug
too.
-Levent.
On Tue, May 5, 2015 at 8:07 AM, Carter Schonwald wrote: Irk. If libm is busted when changing rounding modes, that puts a nasty
twist on things. I do agree that even if that hurdle is jumped, setting the local rounding
mode will have to be part of every green thread context switch. But if
libm is hosed that kinda makes adding that machinery a smudge pointless
until there's a good story for that. On Tuesday, May 5, 2015, Edward Kmett On Tue, May 5, 2015 at 7:22 AM, Scott Turner <2haskell@pkturner.org>
wrote: On 2015-05-05 00:54, Levent Erkok wrote: I can see at least two designs: * One where the rounding mode goes with the operation: `fpAdd
RoundNearestTiesToEven 2.5 6.4`. This is the "cleanest" and the
functional solution, but could get quite verbose; and might be costly
if the implementation changes the rounding-mode at every issue. * The other is where the operations simply assume the
RoundNearestTiesToEven, but we have lifted IO versions that can be
modified with a "with" like construct: `withRoundingMode
RoundTowardsPositive $ fpAddRM 2.5 6.4`. Note that `fpAddRM` (*not*
`fpAdd` as before) will have to return some sort of a monadic value
(probably in the IO monad) since it'll need to access the rounding
mode currently active. Neither choice jumps out at me as the best one; and a hybrid might
also be possible. I'd love to hear any insight you gain regarding
rounding-modes during your experiment. The monadic alternative is more readily extensible to handle IEEE 754's
sticky flags: inexact, overflow, underflow, divide-by-zero, and invalid. This gets messier than you'd think. Keep in mind we switch contexts
within our own green threads constantly on shared system threads /
capabilities so the current rounding mode, sticky flags, etc. would become
something you'd have to hold per Thread, and then change proactively as
threads migrate between CPUs / capabilities, which we're basically
completely unaware of right now. This was what I learned when I tried my own hand at it and failed: http://hackage.haskell.org/package/rounding There found I gave up, and moved setting the rounding mode into custom
primitives themselves. But even then you find other problems! The libm
versions of almost every combinator doesn't just give slightly wrong
answers when you switch rounding modes, it gives _completely_ wrong answers
when you switch rounding modes. cos basically starts looking like a random
number generator. This is rather amusing given that libm is the library
that specified how to change the damn rounding mode and fixing this fact it
was blocked by Ulrich Drepper when I last looked. Workarounds such as using crlibm
http://lipforge.ens-lyon.fr/www/crlibm/ exist, but isn't installed on
most platforms and it would rather dramatically complicate the installation
of ghc to incur the dependency. This is why I've switched to using MPFR for anything with known rounding
modes and just paying a pretty big performance tax for correctness. (That
and I'm working to release a library that does exact real arithmetic using
trees of nested linear fractional transformations -- assuming I can figure
out how to keep performance high enough.) -Edward -Edward _______________________________________________
Libraries mailing list
Libraries@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries _______________________________________________
Libraries mailing list
Libraries@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries