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>