From: Yusuke ENDOH Date: 2010-02-18T12:17:08+09:00 Subject: [ruby-core:28206] Is Math module a wrapper of libm? 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