George Pollard wrote:
There's also the ieee-utils package, which provides an IEEE monad with `setRound`:
http://hackage.haskell.org/packages/archive/ieee-utils/0.4.0/doc/html/Numeri...
Hmm, this does not work well with the threaded RTS:
import Numeric.IEEE.Monad import Numeric.IEEE.RoundMode (RoundMode (..)) import Control.Monad import Control.Concurrent
main = withIeeeDo $ do replicateM_ 2 $ forkIO $ forever $ putChar '.' forkIO $ do runIEEE $ do withRoundMode Downward $ forever $ do IEEE . putStr . (++ "\n") . show =<< getRound threadDelay 1000000
When run with +RTS -N2 -RTS, the output randomly alternates between Downward and ToNearest - for me at least. The problem is that the setRound call will only affect one worker thread, while the RTS will sometimes migrate RTS threads from one worker to another. runIEEE really has to be executed in a bound thread (see forkOS documentation). Using `par` will also cause trouble - in fact even more. I think that conceptually, the cleanest approach is to provide separate data types for Double and Float in each of the rounding modes. This is quite expensive: basically, it means setting the rounding mode on each operation, and we would miss out on the code generator support for floating point math. (A primop for setting the rounding mode could help here, to some extent.) Maybe tracking the rounding mode per RTS thread would be a useful compromise between performance and usability for computations with mostly uniform rounding mode - this is what the Numeric.IEEE.Monad module seems to be aiming at. `par` would still be unusable with that approach though. Bertram