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: Steven Munroe <munroesj at linux dot vnet dot ibm dot com>
- Cc: Christoph Lauter <christoph dot lauter at lip6 dot fr>, "Paul E. Murphy" <murphyp at linux dot vnet dot ibm dot com>, "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: Sat, 19 Dec 2015 13:15:09 +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> <564A53CE dot 8080500 at lip6 dot fr> <alpine dot DEB dot 2 dot 10 dot 1511162234340 dot 32387 at digraph dot polyomino dot org dot uk> <1450473096 dot 8390 dot 75 dot camel at oc7878010663> <alpine dot DEB dot 2 dot 10 dot 1512182118350 dot 11373 at digraph dot polyomino dot org dot uk> <1450501415 dot 8390 dot 111 dot camel at oc7878010663>
On Fri, 18 Dec 2015, Steven Munroe wrote:
> > > Joseph,
> > >
> > > Please do not assume the Decimal Floating carries all the sins of the
> > > much maligned IBM long double.
> >
> > I'm not assuming that - I'm comparing with support for *IEEE* binary
> > types, which also has plenty of deficiencies in GCC. I'm working from,
> > for example, the various open DFP bugs in GCC:
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43374
> Intel BID
"The tests also fail on powerpc64-linux" - just because a bug is reported
for one case doesn't mean it doesn't apply to other cases as well.
> I am not sure what you want from us here. Most of these are not my
> platform or bad test cases. We are fixing the TIMode issue as an
> oversite.
I don't know who you mean by "us". These examples are to illustrate the
basis for my impression of the state of DFP support in the GNU toolchain
as similar to that for (IEEE) binary floating-point, which is *not* based
on a comparison with IBM long double - they are not to request fixes.
What I want from *all* people in the glibc community is:
1. Assume good faith in other contributors - do not jump to conclusions
about motivations other than seeking to improve glibc, the GNU toolchain,
the GNU system and free software in general.
2. Pay sufficient attention to detail for the discussion in question.
When discussing algorithms for floating-point conversions, this means
understanding and taking into account relevant general issues around
rational approximation, worst cases for correct rounding, precision
extension techniques, avoiding spurious exceptions, etc. - a general
notion that rounding to odd might be relevant is not very helpful to such
a discussion without a good grasp of the uses and limitations of that
technique.
3. Work constructively with the community on reaching consensus.
4. See <https://sourceware.org/ml/libc-alpha/2015-07/msg00766.html>
regarding conflicts of interest.
> But you seem to be on some type of crusade that I do not understand the
> scope of.
I am not. See point 1 above.
> I am concerned that you trying to hold our efforts hostage to this
> crusade.
I am not. See point 1 above. Because glibc works by community consensus,
and subsystem (*including architecture*) maintainers just provide a
starting point for consensus in their areas rather than determining it,
it's not possible for one contributor to hold efforts hostage, as other,
unconnected contributors are free to speak up if they think someone is
being unreasonable or contrary to consensus.
As far as I'm concerned, what you do with decimal floating point cannot
block anything to do with float128. I explicitly said when first
mentioning the conversions issue in the GCC context that work on the DFP
conversions could be deferred.
But since you asked for advice, I looked at the existing code. And,
having noticed issues in that code that were extremely obvious given a
general understanding of the relevant floating-point issues, I pointed out
those issues for your information, as part of the general goal to improve
the quality of free software everywhere - and described, with appropriate
attention to detail, the considerations relevant to determining whether an
approach for implementing conversions is correct or not. (I'm sure you
know more about whether a particular approach is *efficient* on POWER
hardware - my comments were about *correctness*.)
> I am trying to establish boundaries that we can agree to.
See points 1, 2, 3 and 4 above. It's community consensus that ultimately
determines what goes into glibc.
It is very unlikely that large contributions - say, float128 libm
functions - can get into glibc without following those points
sufficiently. Saying this is not an attempt to hold efforts hostage; it's
simply advice about community expectations. People are of course free to
jump in with long patch series without sufficient attention to detail and
to obtaining community consensus at all stages, but doing so would be
setting oneself up for huge amounts of wasted work.
--
Joseph S. Myers
joseph@codesourcery.com