
On 22-09-15 19:19, Christopher Allen wrote:
That's what I suggested might be the case and this makes sense. Thank you :)
On Tue, Sep 22, 2015 at 12:17 PM, Mike Izbicki
mailto:mike@izbicki.me> wrote: > My thoughts exactly, I think this would be *really* cool as an HLint-style tool.
The main problem with this is that numerically stable expressions are often very opaque. If you look at the first example in the README, I would definitely rather have:
w far near = -(2 * far * near) / (far - near)
in my code than
w near far = if near < -1.7210442634149447e+81 then (2.0 * near / (near - far)) * far else if near < 8.364504563556443e+16 then (2.0 * near) / ((near - far) / far) else ((2.0 * near) / (near - far)) * far
One of the reasons I use Haskell is because the code is "at the level of thought" and GHC translates this into awesome speed without the programmer needing to worry about the gory details in most cases. I want that same experience for numerical stability. _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org mailto:Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
-- Chris Allen Currently working on http://haskellbook.com
I'd love it if there was a way to (semi-)automatically add rewrite rules to the Haskell program source modules. That way, it is both automatically applied on subsequent compiles, consistent between builds, and transparent what is happening, which expressions are unstable and how to fix them manually if desired. (Although I understand that rewrite rules are not always triggered?) Thanks for pointing out this problem in (my) programs and automating a solution! kind regards, Arjen