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.