[ruby-core:28210] Re: Is Math module a wrapper of libm?

I also support the second option of a platform independent module (as
I stated in [ruby-core:26657] ).

Even if the first option was desired, Ruby can not be completely
faithful to libm because functions in libm have the dual effect of
returning a value (potentially NaN) and setting error flags at the
same time. Since obviously Ruby methods can either a value or raise an
error but not both, the current approach is not a direct wrap of libm.
This is particularly problematic in case of pole errors where libm
states that a mathematically valid result +/-Infinity should be
returned and the FE_DIVBYZERO error flag set [redmine:2189].

Especially now that we have Float::INFINITY (thanks Yui!), I hope we
can make Ruby mathematically sound on all platforms.

--
Marc-Andre Lafortune

On Wed, Feb 17, 2010 at 10:17 PM, Yusuke ENDOH <[e-mail]> wrote:
> Hi matz --
>
> I'd like to hear your opinion about the policy of Math module.
>
> I have considered Math module is just a wrapper of libm. =A0But
> current Math absorbs a part of platform-dependent behavior of
> libm:
>
> - in [ruby-core:7019] and r10626, you decided Ruby absorbed
> =A0FreeBSD's peculiar behavior for sqrt(-1) by explicit NaN
> =A0checking, in spite of (maybe) the FreeBSD's spec.
>
> - in [ruby-core:26647], you also rejected consistency against
> =A0Linux's bizarre behavior for atanh(1), in spite of the
> =A0Linux's *bug* (even written explicitly as bug in manpage)
> =A0http://www.kernel.org/doc/man-pages/online/pages/man3/atanh.3.html
>
>
> It is good to decide the policy of Math. =A0Please choice:
>
> 1) Math is still just a wrapper of libm
> 2) Math is (aims to be) platform-independent math module
> =A0 (though it is very similar to libm's API)
>
> If you choice #1, I think the NaN check of r10626 should be
> removed because it goes against the policy.
>
>
> BTW, recently I found that libm is not so portable; it has
> different behavior depending on platform. =A0Also, libm of
> glibc seems not to be stable enough yet; the above behavior
> of atanh(1) was changed (fixed?) in 2009-04-26:
> http://sourceware.org/cgi-bin/cvsweb.cgi/~checkout~/libc/ChangeLog?rev=3D=
1.11655.2.1&content-type=3Dtext/plain&cvsroot=3Dglibc
>
> So I prefer #2. =A0If Math is just a wrapper, users must know
> and care the difference. =A0For example, when atanh fails, it
> may return NaN or Infinity or raise Errno::EDOM or Errno::
> ERANGE. =A0Each user must check them manually to write portable
> Ruby script. =A0It is too cumbersome.
>
> To aim platform-independent math module, it is first needed
> to do explicit bound check to avoid the different exception
> raised. =A0It may need human-resource, but I think it is now ok
> only to decide the policy. =A0We can insert each check whenever
> someone registers bug tickets. =A0And we can refer SUSv3 etc.,
> so we don't have to worry what and how to check.
>
>
> What do you think?
>
> --
> Yusuke ENDOH <[e-mail]>
>
>