Feature #9799

change behavior of Math::atan2 if y and x are both Float::INFINITY

Added by cremno phobia over 1 year ago. Updated about 1 year ago.

[ruby-core:62310]
Status:Closed
Priority:Normal
Assignee:-

Description

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

I think a domain error isn't desirable here. Is it even one? Other languages like Go, Python, Java or Javascript seem to return the expected result. .NET languages return NaN.

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.

http://golang.org/src/pkg/math/atan2.go
http://hg.python.org/cpython/file/62438d1b11c7/Modules/mathmodule.c#l516
http://docs.oracle.com/javase/7/docs/api/java/lang/Math.html#atan2%28double,%20double%29
http://www.ecma-international.org/ecma-262/5.1/#sec-15.8.2.5
http://port70.net/~nsz/c/c99/n1256.html#F.9.1.4
http://msdn.microsoft.com/en-us/library/system.math.atan2.aspx

f36b9cd63c8218d17a4ddf346a88b9d64a62f557.diff Magnifier (1.58 KB) cremno phobia, 05/03/2014 02:45 AM

Associated revisions

Revision 45805
Added by Nobuyoshi Nakada about 1 year ago

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]

Revision 45805
Added by Nobuyoshi Nakada about 1 year ago

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]

History

#1 Updated by Nobuyoshi Nakada about 1 year ago

  • Tracker changed from Bug to Feature
  • Category set to core

#2 Updated by Yusuke Endoh about 1 year ago

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.

x = Float::INFINITY
Math.atan2(x, 2 * x) #=> Math::PI/4, not Math.atan2(1, 2)

Yusuke Endoh mame@tsg.ne.jp

#3 Updated by Nobuyoshi Nakada about 1 year ago

  • Status changed from Open to Closed
  • % Done changed from 0 to 100

Applied in changeset r45805.


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]

#4 Updated by Nobuyoshi Nakada about 1 year 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
But Float::INFINITY == Float::INFINITY*2 also returns true, it doesn't feel worth to worry about.

#5 Updated by cremno phobia about 1 year 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 atan2(∞,∞) as π/4 indicates 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.

#6 Updated by Marcus Stollsteimer about 1 year ago

Wait, wait...

So you introduce mathematically wrong behaviour with the argument that there already is some other wrong behaviour???

#7 Updated by cremno phobia about 1 year ago

Marcus Stollsteimer wrote:

Wait, wait...

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

GNU Octave: https://www.gnu.org/software/octave/doc/interpreter/Trigonometry.html
NumPy: http://docs.scipy.org/doc/numpy/reference/generated/numpy.arctan2.html

Also available in: Atom PDF