fmax/fmin sNaN compatibility question

fmax/fmin sNaN compatibility question

[Ulrich Weigand]

Hi Joseph,

I'm trying (once again) to understand how fmin/fmax are supposed to
work in the presence of signaling NaNs, and find the various standards
to be a bit confusing on this topic; I was wondering if you could help
me out here :-)

You've made the following statement in glibc bugzilla 20947:

    Under TS 18661-1 semantics, if either argument is an sNaN then the
    result should be a qNaN [...]

and changed the glibc fmax/fmin implementations accordingly.

Now I've been looking at TS 18661-1 (either n1809 or n2314) and I don't
see where it defines the semantics in this way.

In fact, the clearest statement seems to be the sample implementation
in F.10.9.2, paragraph 3, which according to TS 18661-1 now should be:

{
  double r;
  r = (isgreaterequal(x, y) || isnan(y)) ? x : y;
  (void) canonicalize(&r, &r);
  return r;
}

But if this sample implementation is called with a sNaN and a
regular number (and traps are off), it will return the regular
number, not any NaN ...

Am I missing something here?

Thanks,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU/Linux compilers and toolchain
  Ulrich.Weigand@de.ibm.com

Re: fmax/fmin sNaN compatibility question

[Joseph Myers]

On Mon, 9 Dec 2019, Ulrich Weigand wrote:

> Now I've been looking at TS 18661-1 (either n1809 or n2314) and I don't
> see where it defines the semantics in this way.
> 
> In fact, the clearest statement seems to be the sample implementation
> in F.10.9.2, paragraph 3, which according to TS 18661-1 now should be:
> 
> {
>   double r;
>   r = (isgreaterequal(x, y) || isnan(y)) ? x : y;
>   (void) canonicalize(&r, &r);
>   return r;
> }

See the "Append to footnote 374): Note also that this implementation does 
not handle signaling NaNs as required of implementations that define 
FP_SNANS_ALWAYS_SIGNAL." in TS 18661-1.

fmax is the maxNum operation from IEEE 754-2008 that was removed in IEEE 
754-2019; see the table of operation bindings in TS 18661-1.  It is *not* 
the maximum or maximumNumber operation from IEEE 754-2019 (there's a 
separate proposal for C bindings for those operations, with different 
names; implementing those operations has its own complication that they 
require -0 to compare less than +0, which maxNum doesn't, although the 
choice of a decimal cohort member where both arguments are members of the 
same cohort with different quantum exponents is still unspecified).

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: fmax/fmin sNaN compatibility question

[Ulrich Weigand]

Joseph Myers wrote:
> On Mon, 9 Dec 2019, Ulrich Weigand wrote:
> 
> > Now I've been looking at TS 18661-1 (either n1809 or n2314) and I don't
> > see where it defines the semantics in this way.
> > 
> > In fact, the clearest statement seems to be the sample implementation
> > in F.10.9.2, paragraph 3, which according to TS 18661-1 now should be:
> > 
> > {
> >   double r;
> >   r = (isgreaterequal(x, y) || isnan(y)) ? x : y;
> >   (void) canonicalize(&r, &r);
> >   return r;
> > }
> 
> See the "Append to footnote 374): Note also that this implementation does 
> not handle signaling NaNs as required of implementations that define 
> FP_SNANS_ALWAYS_SIGNAL." in TS 18661-1.

Ah, this is what I missed.  Thanks!

So just to clarify: there was a sample implementation in C11, and now there
is a (different) sample implementation in TS 18661-1 / C2x, but the expected
behavior in FP_SNANS_ALWAYS_SIGNAL mode is neither of those, but rather the
behavior described by maxNum from IEEE 754-2008.  Right?

Do you know why the sample implementation was even updated then?
If FP_SNANS_ALWAYS_SIGNAL is false, shouldn't the C11 method then
still be OK?

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU/Linux compilers and toolchain
  Ulrich.Weigand@de.ibm.com

Re: fmax/fmin sNaN compatibility question

[Joseph Myers]

On Mon, 9 Dec 2019, Ulrich Weigand wrote:

> So just to clarify: there was a sample implementation in C11, and now there
> is a (different) sample implementation in TS 18661-1 / C2x, but the expected
> behavior in FP_SNANS_ALWAYS_SIGNAL mode is neither of those, but rather the
> behavior described by maxNum from IEEE 754-2008.  Right?

Yes.

> Do you know why the sample implementation was even updated then?
> If FP_SNANS_ALWAYS_SIGNAL is false, shouldn't the C11 method then
> still be OK?

The canonicalize call is needed in general to avoid propagating 
noncanonical DFP encodings, though not relevant for binary FP.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: fmax/fmin sNaN compatibility question

[Ulrich Weigand]

Joseph Myers wrote:
> On Mon, 9 Dec 2019, Ulrich Weigand wrote:
> > Do you know why the sample implementation was even updated then?
> > If FP_SNANS_ALWAYS_SIGNAL is false, shouldn't the C11 method then
> > still be OK?
> 
> The canonicalize call is needed in general to avoid propagating 
> noncanonical DFP encodings, though not relevant for binary FP.

But it does change the behavior for binary FP as well, as far
as I can see: e.g. if both inputs are sNaNs, the C11 method
would return one of those sNaNs unchanged, while the C2x method
will return a qNaN (as the canonicalize call will quiet the
sNaN it receives as input), right?

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU/Linux compilers and toolchain
  Ulrich.Weigand@de.ibm.com

Re: fmax/fmin sNaN compatibility question

[Joseph Myers]

On Tue, 10 Dec 2019, Ulrich Weigand wrote:

> Joseph Myers wrote:
> > On Mon, 9 Dec 2019, Ulrich Weigand wrote:
> > > Do you know why the sample implementation was even updated then?
> > > If FP_SNANS_ALWAYS_SIGNAL is false, shouldn't the C11 method then
> > > still be OK?
> > 
> > The canonicalize call is needed in general to avoid propagating 
> > noncanonical DFP encodings, though not relevant for binary FP.
> 
> But it does change the behavior for binary FP as well, as far
> as I can see: e.g. if both inputs are sNaNs, the C11 method
> would return one of those sNaNs unchanged, while the C2x method
> will return a qNaN (as the canonicalize call will quiet the
> sNaN it receives as input), right?

The handling of sNaN is explicitly implementation-defined when 
FE_SNANS_ALWAYS_SIGNAL is not defined, so that example implementation 
should not be used to infer anything about how sNaN should be handled.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: fmax/fmin sNaN compatibility question

[Ulrich Weigand]

Joseph Myers wrote:
> On Tue, 10 Dec 2019, Ulrich Weigand wrote:
> 
> > Joseph Myers wrote:
> > > On Mon, 9 Dec 2019, Ulrich Weigand wrote:
> > > > Do you know why the sample implementation was even updated then?
> > > > If FP_SNANS_ALWAYS_SIGNAL is false, shouldn't the C11 method then
> > > > still be OK?
> > > 
> > > The canonicalize call is needed in general to avoid propagating 
> > > noncanonical DFP encodings, though not relevant for binary FP.
> > 
> > But it does change the behavior for binary FP as well, as far
> > as I can see: e.g. if both inputs are sNaNs, the C11 method
> > would return one of those sNaNs unchanged, while the C2x method
> > will return a qNaN (as the canonicalize call will quiet the
> > sNaN it receives as input), right?
> 
> The handling of sNaN is explicitly implementation-defined when 
> FE_SNANS_ALWAYS_SIGNAL is not defined, so that example implementation 
> should not be used to infer anything about how sNaN should be handled.

OK, got it.  I think it starts making sense now :-)

Thanks for your help!

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU/Linux compilers and toolchain
  Ulrich.Weigand@de.ibm.com