[Haskell-cafe] Re: Why 'round' does not just round numbers ?

Bertram Felgenhauer bertram.felgenhauer at googlemail.com
Thu Oct 30 17:21:39 EDT 2008


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/Numeric-IEEE-RoundMode.html

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


More information about the Haskell-Cafe mailing list