From: Aldy Hernandez <aldyh@redhat.com>
To: Michael Matz <matz@suse.de>
Cc: Richard Biener <richard.guenther@gmail.com>,
Jakub Jelinek <jakub@redhat.com>,
GCC patches <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH] [PR68097] frange::set_nonnegative should not contain -NAN.
Date: Tue, 20 Sep 2022 16:58:38 +0200 [thread overview]
Message-ID: <CAGm3qMVs7o4gs_t5j=movkk8uzJ_yj3mQTqFLED5gDPcZhbK3w@mail.gmail.com> (raw)
In-Reply-To: <alpine.LSU.2.20.2209201246060.9510@wotan.suse.de>
On Tue, Sep 20, 2022 at 2:51 PM Michael Matz <matz@suse.de> wrote:
>
> Hello,
>
> On Tue, 20 Sep 2022, Aldy Hernandez wrote:
>
> > > 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
> >
> > I suppose this means -0.0 is not considered negative,
>
> It would be considered negative if the predicate is implemented like
> above:
> copysign(1.0, -0.0) == -1.0
>
> But really, that depends on what _our_ definition of negative_p is
> supposed to be. I think the most reasonable definition is indeed similar
> to above, which in turn is equivalent to simply looking at the sign bit
> (which is what copysign() does), i.e. ...
>
> > though it has
> > the signbit set? FWIW, on real_value's real_isneg() returns true for
> > -0.0 because it only looks at the sign.
>
> ... this seems the sensible thing. I just wanted to argue the case that
> set_negative (or the like) which "sets" the sign bit does not make the
> nan-ness go away. They are orthogonal.
>
> > > 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} .
> >
> > That was my understanding as well, and what my original patch did.
> > But again, I'm just the messenger.
>
> Ah, I obviously haven't followed the thread carefully then. If that's
> what it was doing then IMO it was the right thing.
This brings me back to my original patch :).
Richard, do you agree nonnegative should be [0.0, +INF] U +NAN.
Thanks.
Aldy
next prev parent reply other threads:[~2022-09-20 14:58 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-19 7:59 Aldy Hernandez
2022-09-19 8:14 ` Richard Biener
2022-09-19 12:51 ` Aldy Hernandez
2022-09-19 13:42 ` Richard Biener
2022-09-19 13:58 ` Michael Matz
2022-09-20 5:25 ` Aldy Hernandez
2022-09-20 12:51 ` Michael Matz
2022-09-20 14:58 ` Aldy Hernandez [this message]
2022-09-20 15:09 ` Jakub Jelinek
2022-09-20 18:08 ` Aldy Hernandez
2022-09-20 5:32 ` Aldy Hernandez
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAGm3qMVs7o4gs_t5j=movkk8uzJ_yj3mQTqFLED5gDPcZhbK3w@mail.gmail.com' \
--to=aldyh@redhat.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=jakub@redhat.com \
--cc=matz@suse.de \
--cc=richard.guenther@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).