From: Run Paint Run Run <redmine@...>
Date: 2009-07-04T02:10:15+09:00
Subject: [ruby-core:24129] [Bug #1708] require 'complex' Causes Unexpected Behaviour

Issue #1708 has been updated by Run Paint Run Run.


Thank you for the explanation, matz. :-)

When I heard that Complex had been moved to core I assumed that _all_ Complex functionality had been translated, include the Math extensions. I imagine that this was a common reaction.

It would surely be optimal for the Math methods to seamlessly support Complex numbers. Let's take Math.cos for example. Passing it a Complex number without 'cmath':

    >> Math.cos(Complex(1,2))
    RangeError: can't convert 1+2i into Float
	from (irb):79:in `to_f'
	from (irb):79:in `cos'
	from (irb):79
	from /usr/local/bin/irb:12:in `<main>'

Passing it a Complex number with 'cmath':

    >> Math.cos(Complex(1,2)).inspect
    => "(2.0327230070196656-3.0518977991517997i)"

In this case, what would be the harm of including 'cmath' by default? Performance isn't affected for the common cases (non-Complex numbers), yet Complex arguments "do the right thing". Indeed, the majority of the methods in 'cmath' appear to be only act differently from the default if their argument is Complex (and, in some cases, positive, too). What is the benefit to the user of having a method raise an exception when it could produce the right answer? Or, what do we lose by integrating 'cmath'?

Unless there are serious incompatibilities or performance concerns, it seems more robust and well-rounded if Complex numbers work as one would expect.
----------------------------------------
http://redmine.ruby-lang.org/issues/show/1708

----------------------------------------
http://redmine.ruby-lang.org