This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: IEEE128 binary float to decimal float conversion routines
- From: Joseph Myers <joseph at codesourcery dot com>
- To: "Paul E. Murphy" <murphyp at linux dot vnet dot ibm dot com>
- Cc: "libc-alpha at sourceware dot org" <libc-alpha at sourceware dot org>, Steve Munroe <sjmunroe at us dot ibm dot com>, Tulio Magno Quites Machado Filho <tuliom at linux dot vnet dot ibm dot com>, Michael R Meissner <mrmeissn at us dot ibm dot com>
- Date: Tue, 17 Nov 2015 00:06:59 +0000
- Subject: Re: IEEE128 binary float to decimal float conversion routines
- Authentication-results: sourceware.org; auth=none
- References: <564A16D5 dot 3020105 at linux dot vnet dot ibm dot com> <alpine dot DEB dot 2 dot 10 dot 1511161803500 dot 30498 at digraph dot polyomino dot org dot uk> <564A6A90 dot 40607 at linux dot vnet dot ibm dot com>
On Mon, 16 Nov 2015, Paul E. Murphy wrote:
> Thanks for pointing that out. libgcc implements a subset
> of the API provided by libdfp. However, libdfp should have
> better compliance and optimization for powerpc targets. They
> take different approaches when converting formats, among other
> things.
Thanks for the explanation.
I don't know my way around libdfp, so may be looking at the wrong source
files that aren't actually used in practice. But it's not apparent to me
that e.g. base-math/trunctdsf.c would be correctly rounding; even if the
conversion to double were exact, _Decimal128 has enough precision that I'd
expect you to get double values exactly half way between two floats (but
not exactly equal to the original decimal value) with incorrect results
following from double rounding. (And hardcoding infinity and zero as
overflow and underflow results is obviously wrong in non-default rounding
modes.)
--
Joseph S. Myers
joseph@codesourcery.com