Feature #9799
closed
- Tracker changed from Bug to Feature
- Category set to core
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
- 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 [ruby-core:62310]. [Feature #9799]
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.
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.
Wait, wait...
So you introduce mathematically wrong behaviour with the argument that there already is some other wrong behaviour???
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
Like0
Like0Like0Like0Like0Like0Like0Like0