This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFC: libm-test.inc with more accurate values


Geoff Keating <geoffk@geoffk.org> writes:

> These would be good as additional tests, but do we really want a libm
> testsuite where only the first few bits of each input value are ever
> set?

The problem at the moment is that we use as input e.g. 0.7 which is an
exact decimal but cannot be represented exactly as floating point
variable and therefore the results are not for 0.7 but for the
approzimation of 0.7.  Here're some lines from an email by Stephen
Moshier to libc-alpha with subject "some ldouble tests fixed":

} All of the numerical test cases that you quoted, that report many ulps
} error, appear to be suffering from insufficient precision in the given
} numbers for 128-bit floating point.  Here are the test points with
} more precise values filled in.
} 
} Some of the complex variable library functions might have other
} problems.  I have not had much success compiling them yet on a 32-bit
} Solaris sparc.  Can you check them against the higher accuracy numbers?
} 
} 
} (long double) 0.7L is 6.9999999999999999999999999999999996148140E-1L
} (long double) 1.2L is 1.1999999999999999999999999999999999614814E0L
} 
} tanhl(0.7L) = 6.0436777711716349630868718310382645056629E-1L
} sinhl(0.7L) = 7.5858370183953350345987464759276810580759E-1L
}  

I currently caluculate sin(0.7) exactly using maple.  Using e.g. 0.75
which can be represented exactly as float gets us away from the
decimal/floating point conversion problems.


I'm open to better solutions and would like to see solutions that work
with all floating point formats including the 128-bit ones.

Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]