This is the mail archive of the 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: IEEE128 binary float to decimal float conversion routines

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:

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

3. Work constructively with the community on reaching consensus.

4. See <> 
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

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