[armel] Function tgammal has precision issues in version 2.12.1-0ubuntu10.2 on ARM

Bug #713985 reported by Snark on 2011-02-06
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Linaro Toolchain Miscellanies
Fix Released
Undecided
Unassigned
eglibc (Ubuntu)
Undecided
Unassigned

Bug Description

Consider the following test program :
#include <stdio.h>
#include <math.h>

int
main (int argc,
      char* argv[])
{
  long double x = 6.0;
  printf("tgammal (%.20Lf)=%.20Lfn", x, tgammal(x));
  return 0;
}

When run on 2.12.1-0ubuntu10.2, the result is :
tgammal (6.00000000000000000000)=119.99999999999997157829
while when run on 2.11.2-11 (glibc's unstable), the result is :
tgammal (6.00000000000000000000)=119.99999999999999998612

The second result is acceptable, while the second isn't. This makes sage (http://www.sagemath.org) unhappy...

I forgot to say that it was on an ARM (little-endian) box!

summary: - Function tgammal has precision issues in this version
+ Function tgammal has precision issues in version 2.12.1-0ubuntu10.2 on
+ ARM
summary: - Function tgammal has precision issues in version 2.12.1-0ubuntu10.2 on
- ARM
+ [armel] Function tgammal has precision issues in version
+ 2.12.1-0ubuntu10.2 on ARM
Dima Pasechnik (dimpase) wrote :

The bug is in fact in lgammal, as tgammal(x) simply takes expl(lgammal(x));
namely, lgammal(6.0) produces 4.78749174278204581157 on armel,
while it should be closer to 4.7874917427820459942477, i.e. armel gives relative error of about 3.8e-17

Matthias Klose (doko) on 2012-01-09
tags: added: arm-porting-queue armel
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in eglibc (Ubuntu):
status: New → Confirmed
Dima Pasechnik (dimpase) wrote :

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).

Snark (julien-puydt) wrote :

This is still a problem with 2.13-24ubuntu4.

Will Newton (will-newton) wrote :

This seems to be fixed as far as I can tell building a static soft float binary with the Linaro toolchain (which incidentally no longer supports soft float from 4.9 onwards).

Changed in linaro-toolchain-misc:
status: New → Fix Released
Dima Pasechnik (dimpase) wrote :

It would be great to know in more details how to get the fix mentioned on an armhfl Ubuntu 12.10 (no, we cannot upgrade the system, unfortunately).

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers