From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: Date: Thu, 22 Aug 2013 15:25:02 +0100 Message-ID: From: Charles Forsyth To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=089e0122805842e19604e48a0ece Subject: Re: [9fans] comparisons with NaN Topicbox-Message-UUID: 73f8e432-ead8-11e9-9d60-3106f5b1d025 --089e0122805842e19604e48a0ece Content-Type: text/plain; charset=UTF-8 > it would be reasonable to try to follow the standard, unless it's stupid, > > ill-advised, or impossible (or all three). > I was a little ambiguous. I meant that statement in general, but I in the particular case of floating-point, being fundamental, probably should work as now defined, and I didn't think NaNs satisfied the last bit of being stupid, ill-advised or impossible. Looking at the code generated, I'd have thought that it was the use of FCOM instead of FUCOM that mattered, not the integer unit comparison that's subsequently used. --089e0122805842e19604e48a0ece Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

=
> it would be reaso= nable to try to follow the standard, unless it's stupid,
> ill-advised, or impossible (or all three).

I was a little ambiguous. I meant that statement in general, but I in = the particular case of floating-point, being fundamental, probably should w= ork as now defined,
and I didn't think NaNs satisfied the last b= it of being stupid, ill-advised or impossible.

Looking at the code generated, I&#= 39;d have thought that it was the use of FCOM instead of FUCOM that mattere= d,
not the integer unit comparison that's subse= quently used.
--089e0122805842e19604e48a0ece--