#8539: Data.Complex shouldn't use default implementation of (**) -------------------------------------+------------------------------------- Reporter: jjaredsimpson | Owner: Type: bug | Status: patch Priority: low | Milestone: Component: Prelude | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Incorrect result | Difficulty: Easy (less than 1 at runtime | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by Scott Turner): I don't know that (!**) is more special. Maybe we are talking about it because it has the rule {{{ x ** 0 == 1 }}} which is peculiarly effective. It does battle with another rule {{{ 0 ** x == 0 }}} and in the judgement of most numerical analysis, it wins the fight. I think the reason people aren't diving in to address how all the other operators handle complex infinities is that it's very ''complex''. Your patch handles a few cases well, but it doesn't come near to handling them all. For example, it doesn't take care of {{{ (infinity:+infinity)*(infinity:+infinity) == (NaN:+infinity) }}} which is poor because the result should be a plain infinite value. The same kind of thing can happen, even if one of the operands is finite. Then there are cases in which there's an intermediate overflow but the best result is not infinite. That's because {{{ (x:+y) * (x':+y') = (x*x'-y*y') :+ (x*y'+y*x') }}} subtracts after multiplying. The intermediate x*x' can be unrepresentable, while x*x'-y*y' is representable. It's all a lot of fun. It would be nice work if someone would pay us for doing it. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8539#comment:18 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler