Ray Brownrigg <[EMAIL PROTECTED]> writes today about the inaccurate
log1p() on NetBSD 1.6 and OpenBSD 3.2:
>> Well, the source which I have access to doesn't bear that out.
Interesting. Our NetBSD installation is pretty recent:
% uname -a
NetBSD netbsd.vm.math.utah.edu 1.6 NetBSD 1.6 (GENERIC) #0: Sun Sep 8
19:43:40 UTC 2002 [EMAIL
PROTECTED]:/autobuild/i386/OBJ/autobuild/src/sys/arch/i386/compile/GENERIC
i386 i386 Intel Pentium III (Katmai) (686-class) NetBSD
% ldd a.out
a.out:
-lm.0 => /usr/lib/libm387.so.0
-lm.0 => /usr/lib/libm.so.0
-lc.12 => /usr/lib/libc.so.12
% ls -lL /usr/lib/libm387.so.0 /usr/lib/libm.so.0 /usr/lib/libc.so.12
-r--r--r-- 1 root wheel 700411 Sep 8 2002 /usr/lib/libc.so.12
-r--r--r-- 1 root wheel 109910 Sep 8 2002 /usr/lib/libm.so.0
-r--r--r-- 1 root wheel 10091 Sep 8 2002 /usr/lib/libm387.so.0
% strings -a /usr/lib/libm.so.0 | grep -i log1p
log1pf
log1p
$NetBSD: s_log1pf.c,v 1.7 1999/07/02 15:37:43 simonb Exp $
$NetBSD: s_log1p.c,v 1.11 1999/07/02 15:37:43 simonb Exp $
On OpenBSD, where the same problem with log1p() exists, I have:
% uname -a
OpenBSD openbsd.vm.math.utah.edu 3.2 GENERIC#25 i386 Intel Pentium III
("GenuineIntel" 686-class, 512KB L2 cache) unknown OpenBSD
% ldd ./a.out
./a.out:
-lm.0 => /usr/lib/libm.so.0.1 (0x4001c000)
-lc.28 => /usr/lib/libc.so.28.5 (0x40030000)
% ls -lL /usr/lib/libm.so.0.1 /usr/lib/libc.so.28.5
-r--r--r-- 1 root bin 602889 Oct 3 2002 /usr/lib/libc.so.28.5
-r--r--r-- 1 root bin 85720 Oct 3 2002 /usr/lib/libm.so.0.1
% strings /usr/lib/libm.so.0.1 | grep -i log1p
$NetBSD: s_log1p.S,v 1.7 1995/05/09 00:10:58 jtc Exp $
$NetBSD: s_log1pf.S,v 1.4 1995/05/09 00:13:05 jtc Exp $
_log1p
_log1pf
Notice that the NetBSD version of log1p appears to be in C, while the
OpenBSD version is in assembly code.
I then visited http://www.netbsd.org/ and searched for s_log1p.S; this
led to a posting complaining about its inaccuracy for small arguments:
http://mail-index.netbsd.org/netbsd-bugs/2003/02/17/0017.html
I've not attempted to fetch the NetBSD or OpenBSD source trees to
investigate this further. The existence of the bug in installed
systems is, in my view, sufficient grounds to provide a workaround in
user code.
-------------------------------------------------------------------------------
- Nelson H. F. Beebe Tel: +1 801 581 5254 -
- Center for Scientific Computing FAX: +1 801 581 4148 -
- University of Utah Internet e-mail: [EMAIL PROTECTED] -
- Department of Mathematics, 110 LCB [EMAIL PROTECTED] [EMAIL PROTECTED] -
- 155 S 1400 E RM 233 [EMAIL PROTECTED] -
- Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe -
______________________________________________
[EMAIL PROTECTED] mailing list
https://www.stat.math.ethz.ch/mailman/listinfo/r-devel
