<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, May 5, 2015 at 7:22 AM, Scott Turner <span dir="ltr"><<a href="mailto:2haskell@pkturner.org" target="_blank">2haskell@pkturner.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">On 2015-05-05 00:54, Levent Erkok wrote:<br>
> I can see at least two designs:<br>
><br>
>    * One where the rounding mode goes with the operation: `fpAdd<br>
> RoundNearestTiesToEven 2.5 6.4`. This is the "cleanest" and the<br>
> functional solution, but could get quite verbose; and might be costly<br>
> if the implementation changes the rounding-mode at every issue.<br>
><br>
>    * The other is where the operations simply assume the<br>
> RoundNearestTiesToEven, but we have lifted IO versions that can be<br>
> modified with a "with" like construct:  `withRoundingMode<br>
> RoundTowardsPositive $ fpAddRM 2.5 6.4`. Note that `fpAddRM` (*not*<br>
> `fpAdd` as before) will have to return some sort of a monadic value<br>
> (probably in the IO monad) since it'll need to access the rounding<br>
> mode currently active.<br>
><br>
> Neither choice jumps out at me as the best one; and a hybrid might<br>
> also be possible. I'd love to hear any insight you gain regarding<br>
> rounding-modes during your experiment.<br>
<br>
</span>The monadic alternative is more readily extensible to handle IEEE 754's<br>
sticky flags: inexact, overflow, underflow, divide-by-zero, and invalid.<br></blockquote><div><br></div><div>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.</div><div><br></div><div>This was what I learned when I tried my own hand at it and failed:</div><div><br></div><div><a href="http://hackage.haskell.org/package/rounding">http://hackage.haskell.org/package/rounding</a><br></div><div><br></div><div>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.</div><div><br></div><div>Workarounds such as using <a href="http://lipforge.ens-lyon.fr/www/crlibm/">crlibm</a> exist, but isn't installed on most platforms and it would rather dramatically complicate the installation of ghc to incur the dependency.</div><div><br></div><div>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.)</div><div><br></div><div>-Edward</div><div><br></div><div><br></div><div><br></div><div>-Edward</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class=""><div class="h5">_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org">Libraries@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
</div></div></blockquote></div><br></div></div>