From: Marc-Andre Lafortune <ruby-core-mailing-list@...>
Date: 2010-02-18T14:19:55+09:00
Subject: [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 <mame@tsg.ne.jp> 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. �But
> current Math absorbs a part of platform-dependent behavior of
> libm:
>
> - in [ruby-core:7019] and r10626, you decided Ruby absorbed
> �FreeBSD's peculiar behavior for sqrt(-1) by explicit NaN
> �checking, in spite of (maybe) the FreeBSD's spec.
>
> - in [ruby-core:26647], you also rejected consistency against
> �Linux's bizarre behavior for atanh(1), in spite of the
> �Linux's *bug* (even written explicitly as bug in manpage)
> �http://www.kernel.org/doc/man-pages/online/pages/man3/atanh.3.html
>
>
> It is good to decide the policy of Math. �Please choice:
>
> 1) Math is still just a wrapper of libm
> 2) Math is (aims to be) platform-independent math module
> � (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. �Also, 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=1.11655.2.1&content-type=text/plain&cvsroot=glibc
>
> So I prefer #2. �If Math is just a wrapper, users must know
> and care the difference. �For example, when atanh fails, it
> may return NaN or Infinity or raise Errno::EDOM or Errno::
> ERANGE. �Each user must check them manually to write portable
> Ruby script. �It is too cumbersome.
>
> To aim platform-independent math module, it is first needed
> to do explicit bound check to avoid the different exception
> raised. �It may need human-resource, but I think it is now ok
> only to decide the policy. �We can insert each check whenever
> someone registers bug tickets. �And we can refer SUSv3 etc.,
> so we don't have to worry what and how to check.
>
>
> What do you think?
>
> --
> Yusuke ENDOH <mame@tsg.ne.jp>
>
>