Hello,
On Mon, 19 Sep 2022, Richard Biener via Gcc-patches wrote:
> > but I guess it's good we do the right thing for correctness sake, and
> > if it ever gets used by someone else.
> >
> > >
> > > That said, 'set_nonnegative' could be interpreted to be without
> > > NaNs?
> >
> > Sounds good to me. How's this?
>
> Hmm, I merely had lots of questions above so I think to answer them
> we at least should document what 'set_nonnegative' implies in the
> abstract vrange class.
>
> It's probably safer to keep NaN in. For example unfolded copysign (x, 1.)
> will return true for x == -NaN but the result will be a NaN.
FWIW, in IEEE, 'abs' (like 'copy, 'copysign' and 'negate') are not
arithmetic, they are quiet-computational. Hence they don't rise
anything, not even for sNaNs; they copy the input bits and appropriately
modify the bit pattern according to the specification (i.e. fiddle the
sign bit).
That also means that a predicate like negative_p(x) that would be
implemented ala
copysign(1.0, x) < 0.0
deal with NaNs just fine and is required to correctly capture the sign of
'x'. If frange::set_nonnegative is supposed to be used in such contexts
(and I think it's a good idea if that were the case), then set_nonnegative
does _not_ imply no-NaN.
In particular I would assume that, given an VAYRING frange FR, that
FR.set_nonnegative() would result in an frange {[+0.0,+inf],+nan} .
Ciao,
Michael.
