change behavior of Math::atan2 if y and x are both Float::INFINITY
The current behavior when y and x are either negative or positive infinity is:
Math.atan2(Float::INFINITY, Float::INFINITY) # raises Math::DomainError
The attached diff changes it to:
Math.atan2(Float::INFINITY, Float::INFINITY) # => 0.7853981633974483
ISO C99/C11 also does, if the implementation follows the normative Annex F. This isn't always the case, but there is already a special case when y and x are zero, so I think this one is acceptable, too.
math.c: C99-like atan2
- math.c (math_atan2): return values like as expected by C99 if both two arguments are infinity. based on the patch by cremno phobia in . [Feature #9799]
#3 Updated by Nobuyoshi Nakada 10 months ago
- Status changed from Open to Closed
- % Done changed from 0 to 100
#4 Updated by Nobuyoshi Nakada 10 months ago
Yusuke Endoh wrote:
Interesting. I'm not against the change since the proposed behavior looks prevailing, but I wonder if it is useful that the following case returns pi/4.
Yes, I wondered it too
Float::INFINITY == Float::INFINITY*2 also returns
true, it doesn't feel worth to worry about.
#5 Updated by cremno phobia 10 months ago
I've searched for a rationale. It can be found in http://www.open-std.org/jtc1/sc22/wg14/www/C99RationaleV5.10.pdf on the bottom of page 188 (or real page 181):
The specification of
π/4indicates the reasonable quadrant, preserving some information in preference to none.
Maybe it does make more sense for Ruby to raise. I'm not a mathematician and it also doesn't look useful to me. Also, some languages I've linked seem to lack a similar exception/error (Go or JS), but instead of returning NaN, they follow C's Ann. F and return a more meaningful result instead.
It is mainly curiosity (I've added
Math::DomainError to mruby)—I don't have a strong opinion on this.
#7 Updated by cremno phobia 10 months ago
Marcus Stollsteimer wrote:
So you introduce mathematically wrong behaviour with the argument that there already is some other wrong behaviour???
I don't consider it wrong for a programming language. Maybe these special cases make less sense than the other ones, but they exist in many other languages. Even in numerical ones. That is my argument. But as I've said I'd be okay with the uncommon choice of not having them.
Julia (a nice language, by the way):
julia> atan2(Inf, Inf) 0.7853981633974483 julia> atan2(BigFloat(Inf), BigFloat(Inf)) 7.853981633974483096156608458198757210492923498437764552437361480769541015715495 e-01 with 256 bits of precision