This boils down to eglibc working with 8-byte floats on ARM, even if it's
declared long double.
To see this behaviour on x86, build and run the following:
#include <stdio.h>
#include <math.h>
int main ()
{
double x = 6.0;
printf("sizof(double)=%d\n",sizeof(double));
printf("lgamma (%.20f)=%.20f\n", x, lgamma(x));
printf("tgamma (%.20f)=%.20f\n", x, tgamma(x));
printf("exp(lgamma) (%.20f)=%.20f\n", x, exp(lgamma(x)));
return 0;
}
On eglibc you'll see:
sizof(double)=8
lgamma (6.00000000000000000000)=4.78749174278204581157
tgamma (6.00000000000000000000)=119.99999999999997157829
exp(lgamma) (6.00000000000000000000)=119.99999999999997157829
On a better libc (MacOSX 10.6 on x86_64):
sizof(double)=8
lgamma (6.00000000000000000000)=4.78749174278204492339
tgamma (6.00000000000000000000)=120.00000000000000000000
exp(lgamma) (6.00000000000000000000)=119.99999999999987210231
So eglibc does a bad job computing gamma() on double (i.e. on 8-byte
floats) in this range of values (around 6.0).
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/713985
Title:
[armel] Function tgammal has precision issues in version
2.12.1-0ubuntu10.2 on ARM
To manage notifications about this bug go to:
https://bugs.launchpad.net/linaro-toolchain-misc/+bug/713985/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
