Sven, I'm one of those people who cares about numerical performance :-). Kinda been my obsession :-). My near term stop gap is writing some very high quality ffi bindings, but I'm very keen on Haskell giving fortran a run for it's money.  <div>
<br></div><div>Glad we agree the version that's easier to debug (IEEE, ie current ghc semantics) should be the default <br><div><br></div><div>There's much more meaningful ways we can improve floating point perf, like adding simd support more systematically to ghc (which I'm just now getting the ball rolling on that hacking, there's a lot of things I need to do before adding that mind you<span></span> ). </div>
<div><br></div><div>better constant propagation will help in a few cases, and should be explored. But deciding what the right relaxed rules should be isn't something we should do off the cuff.  We should write down the space of possible relaxed rules, add engineering support to ghc better experiment with benchmarking various approaches, and then if something has a good perf impact see about providing it exposed through a flag. <br>
<br>On Tuesday, January 14, 2014, Sven Panne  wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">2014/1/14 Carter Schonwald <<a href="javascript:;" onclick="_e(event, 'cvml', 'carter.schonwald@gmail.com')">carter.schonwald@gmail.com</a>>:<br>

> maybe so, but having a semantics by default is huge, and honestly i'm not<br>
> super interested in optimizations that merely change one infinity for<br>
> another. What would the alternative semantics be?<br>
<br>
I'm not sure that I understood your reply: My example regarding -0 was<br>
only demonstrating the status quo of GHCi and is IEEE-754-conformant.<br>
The 1/foo is only used to distinguish between 0 and -0, it is not<br>
about infinities per se.<br>
<br>
My point was: As much as I propose to keep these current semantics,<br>
there might be users who care more about performance than<br>
IEEE-754-conformance. For those, relatively simple semantics could be:<br>
Regarding optimizations, numbers are considered "mathematical"<br>
numbers, ignoring any rounding and precision issues, and everything<br>
involving -0, NaN, and infinities is undefined. This would open up<br>
optimizations like easy constant folding, transforming 0 + x to x, x -<br>
x to 0, x `op` y to y `op` x for mathematically commutative operators,<br>
associativity, etc.<br>
<br>
I'm not 100% sure how useful this would really be, but I think we<br>
agree that this shouldn't be the default.<br>
<br>
Cheers,<br>
   S.<br>
</blockquote></div></div>