This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug math/14473] Inaccurate CPOWF function on x86_32 and x86_64
- From: "joseph at codesourcery dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sources dot redhat dot com
- Date: Wed, 15 Aug 2012 15:22:55 +0000
- Subject: [Bug math/14473] Inaccurate CPOWF function on x86_32 and x86_64
- Auto-submitted: auto-generated
- References: <bug-14473-131@http.sourceware.org/bugzilla/>
http://sourceware.org/bugzilla/show_bug.cgi?id=14473
--- Comment #1 from joseph at codesourcery dot com <joseph at codesourcery dot com> 2012-08-15 15:22:55 UTC ---
Again, please give testcases that use hex floats rather than using type
punning, so that the test inputs can more readily be extracted for use
elsewhere.
cpowf, cpow, cpowl are generically inaccurate for all architectures and
floating-point formats - there's nothing x86-specific. They are also by
far the hardest complex functions to make accurate; the errors in this
example are tiny compared to those you can get with properly chosen
examples. In general for long double you need to compute log and atan2
results to over 16000 places to get good results for cpowl. Consider
cpowl (LDBL_MAX, I * LDBL_MAX) for example - you need to compute LDBL_MAX
* log (LDBL_MAX), reduced mod 2pi. Many cases will overflow or underflow
but you still need to determine the signs of zero or infinity in those
cases.
--
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.